Metadata Configuration

Introduction

Alfred Desktop presents “forms” with data & metadata in views and panels. Alfred Desktop has extensive configuration possibilities for displaying and working with the metadata in your Alfresco system.

The style of configuration is heavily inspired on the Share Forms configuration in Alfresco. Alfred Desktop comes with a default configuration set for metadata and works straight out of the box, but you might want to configure how your custom dictionary model is displayed and used.

Where are forms used ?

Forms are used in the following components of Alfred Desktop:

View & Edit Metadata

The metadata panel is a dynamic panel that evaluates the selected document or folder, looks at the document type, available aspects and properties and generates a customized form. This panel supports three different modes: (1) view mode – the default; (2) edit mode – to edit metadata; and (3) create mode – when creating new documents from a document template.

Metadata panel in Edit-Mode

Search Properties

The list of properties in the search-dropdown (both in the quick-search as in the second tab) can be configured using a forms-configuration, which simply lists all the properties you would like to have available in the dropdown.

Search Properties

Columns in the Folder View

In the folder view, the user can select properties to display or hide in a column in the view. This menu can be fully configured, including support for submenus.

Columns in Folderview

Terminology

The forms can be configured in specific YAML files. See paragraph 5.5.

Properties Definition

In these YAML files, the following terms can be found:

  • Forms Configuration Collection
  • Form Configuration
  • Field / Field Set

Form Collection Properties Definition

A configuration file is referred to as Forms Configuration Collection. It consists of:

Parameter Name Remarks Type Description
Id required {required} string {type} Used to identify the forms configuration collection
Version required {required} int {type} Version of the configuration model
Evaluator required {required} string {type} Possible values are: task-type, node-type, aspect and string-compare.
Forms required {required} FormConfiguration[] {type} A collection of form configurations that apply for the specified evaluator.

Form Configuration Properties Definition

Each individual form configuration has:

Parameter Name Remarks Type Description
Fields required {required} Field[] {type} A collection of sub-fields or sub-field-sets.

Field Properties Definition

A field can be either Field or Field Set. A field that contains sub-fields or sub-field-sets. If the Field collection property is empty, the object is considered a regular field. Field sets groups fields together under a section (with an optional template). Multi-layered field sets are typical for Columns or Column Set configuration. All other configurations (metadata forms configurations) are limited to 1 layer of field sets (top level field or field set and the underlying first layer of fields), other layers are ignored and not displayed.

Field Properties

Here is a list of properties that define a field.

Parameter Name Remarks Type Description
Id required {required} string {type} Used to identify the individual field (potentially field set if it contains fields)
Template optional string {type} The template serves to describe a specific predefined UI control feature. For additional information, see Template description below.
RenderMode optional string[] {type} Describes the different states in which the field is available. Possible values are: create, edit, view and hidden. Also, the hidden mode overrides the other definitions and can be overridden with the force property of the field (see below).
ReadOnly optional bool {type} Limits the possibility to edit the field in any RenderMode.
Text optional string {type} Free text for the label of the field.
Description optional string {type} Free text for the description text (on hover) of the field.
ForegroundColor optional string {type} This property is a System.Drawing.Color. It can be configured in two manners: ARGB (See https://docs.microsoft.com/en-us/dotnet/api/system.drawing.color.fromargb?view=netframework-4.5) OR Color Name (See https://docs.microsoft.com/en-us/dotnet/api/system.drawing.color.fromname?view=netframework-4.5)
Parameters optional Dictionary<string,string> {type} A key-value store (Dictionary {type}) of a variety of custom configuration options, such as height, width, autocomplete parameters, etc.
Field Set Properties

Here is a list of properties that define a field set.

Parameter Name Remarks Type Description
Id required {required} string {type} Used to identify the individual field (potentially field set if it contains fields)
Template optional string {type} The template serves to describe a specific predefined UI control feature. For additional information, see Template description below.
Appearance optional string {type} Possible values are: title, section, submenu and none. Submenu is for columns only!
RenderMode optional string[] {type} Describes the different states in which the field is available. Possible values are: create, edit, view and hidden. Also, the hidden mode overrides the other definitions and can be overridden with the force property of the field (see below).
Text optional string {type} Free text for the label of the field.
Description optional string {type} Free text for the description text (on hover) of the field.
Fields optional Field[] {type} A collection of sub-fields or sub-field-sets.
Parameters optional Dictionary<string,string> {type} A key-value store (Dictionary {type}) of a variety of custom configuration options, such as height, width, autocomplete parameters, etc.
Template Description

The template serves to describe a specific predefined UI control feature.

The Template property for field sets supports the following values:

  • gui.controlfactory.fieldset.centered - the default field set in the metadata panel
  • gui.controlfactory.fieldset.group - draws a border to ‘group’ fields together.
    • Parameter collapsible: true|false
    • Parameter start-collapsed: true|false
    • Parameter centered: true|false
  • gui.controlfactory.fieldset.1-column
  • gui.controlfactory.fieldset.2-column
  • gui.controlfactory.fieldset.3-column

The centered-field-set is the default. It right-aligns the field-labels and left-aligns the field-values around the center. The group-field-set draws a border around the Fieldset, with an optional title provided by the Label attribute. The column-variants put fields in 1 or more columns.

The Template property for fields supports the following values:

  • gui.controlfactory.property.textbox - general purpose textbox control
  • gui.controlfactory.property.label - read only control
  • gui.controlfactory.property.textarea - multi-line textbox control
  • gui.controlfactory.property.listconstraint - dropdown - only applicable for properties that have a ListConstraint
  • gui.controlfactory.property.datetimepicker - date picker control - only applicable for data-type d:date or d:datetime
  • gui.controlfactory.property.categorypicker - category picker control - only applicable for data-type d:category
  • gui.controlfactory.property.checkbox - checkbox control
  • gui.controlfactory.property.currency - display number as currency - only applicable for data-type d:int and d:long
  • gui.controlfactory.property.size - displays file size - only applicable for data-type d:content
  • gui.controlfactory.property.mimetype - displays file mime type - only applicable for data-type d:content
  • gui.controlfactory.property.authority - people picker control - only applicable for data-type d:text
    • Parameter key-type: name|reference
    • Parameter authority: user|group|both

The textbox template will give a textbox as input field. The list constraint template will display a combo box as input field. The typeahead template will give a text box with type ahead function enabled. The text area template will give a large text area.

Sample Configuration

A sample of the form configuration template looks as follows:

  - Id: default-node
    Version: 1
    Evaluator: string-compare
    Forms:
      - Fields:
          - Fields:
              - Id: cm:name
              - Id: type
              - Id: template-name
          - Id: type
          - Id: auditable
          - Id: auto
            Fields:
              - Id: cm:content
                RenderMode:
                  - Hidden
              - Id: cm:source
                RenderMode:
                  - Hidden
              - Id: cm:destination
                RenderMode:
                  - Hidden
              - Id: xenit-hash:schemeId
                RenderMode:
                  - Hidden
              - Id: xenit-hash:hash-value
                RenderMode:
                  - Hidden
          - Id: rm
          - Id: aspect-picker-set
            Fields:
              - Id: aspect-picker

Skeleton Configuration

The skeleton of the form configuration template looks as follows:

  - Id: string
    Version: int
    Evaluator: string
    Forms: # FormConfiguration[]
      - Id: string
        Fields: # Field[]
          - Id: string
            Appearance: string
            Template: string
            RenderMode: string[]
            ForegroundColor: string
            Text: string
            Description: string
            Fields: # Field[]
              - Id: string
                Appearance: string
                Template: string
                RenderMode:  string[]
                ForegroundColor: string
                Text: string
                Description: string
                ReadOnly: bool
                Parameters: Dictionary<string,string>
            Parameters: Dictionary<string,string>

Legacy sample: Terminology JSON Sample

JSON to YAML Configuration Conversion

In order to make the transition from JSON to YAML smoother, Xenit developed a configuration converter tool that will transform existing JSON forms configuration to YAML forms configuration.

CMD> ConfigConverter.exe --help
Xenit.Fred.Tools.Config 1.0.0.0

  -i, --input      Required. Input path with JSON configuration to be
                   converted.

  -o, --output     Required. Output path for the converted  product - Yaml
                   configuration.

  --help           Display this help screen.

Example:

  • ConfigConverter.exe -i json_input_folder\ -o yaml_output_folder\
  • ConfigConverter.exe -i old-forms-config.json -o new-forms-config.yaml

You can also find the default configuration for Alfred Desktop in: - C:\Program Files (x86)\Xenit Solutions\Alfred Desktop\Xenit.Repository.Alfresco

Configuring Forms

Configuration Files

In Alfred Desktop the following form configurations are available by default.

Filename Scope
metadata-forms-config.yaml View/Edit Metadata
columns-forms-config.yaml Columns in the detail pane
working-copy-columns-forms-config.yaml Columns in the detail pane
column-sets-forms-config.yaml Columns in the detail pane
search-columns-default-forms-config.yaml Search / Quick Search

These files are written to work with a default alfresco installation. To create your own configuration file, you can choose any file name as long as it ends with forms-config.yaml. If you want to override a forms configuration of the default file, you have to use the same id in the main properties (see 5.3.1). After you have created your custom configuration file, you have to insert it in the Company Home/Data Dictionary/Fred/Forms folder. Alfred Desktop will automatically download this file on startup and override all the default configuration that are specified in your file.

Examples

The syntax of the form configuration will be explained by two examples.

Forms Configuration of a Type

Let’s create a form for a custom type xenit:mytype. We create a file named xenitCustomType-forms-config.yaml. Note that any file name will do, as long as it ends with forms-config.yaml and if it is placed in the Company Home/Data Dictionary/Fred/Forms folder in your alfresco.

  - Id: xenit:mytype
    Evaluator: node-type
    Version: 1
    Forms:
      - Fields:
          - Id: title
            Fields:
              - Id: cm:name
                RenderMode:
                  - View
                  - Edit
                  - Create
          - Id: auditable
          - Id: auto
            Fields:
              - Id: cm:categories
                RenderMode:
                  - View
                  - Edit

Legacy Sample: Forms Configuration of a Type JSON Sample

The id of the forms configuration is the same as the name of the type. The evaluator attribute tells Alfred Desktop under which condition the configuration must be used. The following values are supported:

  • string-compare: the condition is matched when the id attribute equals the given one.
  • node-type: the condition is matched when the type of the selected node equals the id attribute.
  • aspect: the condition is met when the selected node has an aspect specified using the id attribute.

In the field visibility we define which fields need to be displayed if the evaluator condition is met. In our example the field cm:name will be displayed in all three modes (View, Edit and Create) and the field cm:categories will only be displayed in View and Edit mode.

The cm:name field will be displayed in the title set. Next to the title set there are two sets visible. The most important one is the auto set. The “auto” set will be a container for all the fields for which there is no forms configuration. If you have a custom property and there is no forms configuration that puts the corresponding field into a set, the field will be added to the “auto” set.

By Type vs by Aspect

A good practice is to configure fields using an aspect evaluator. (when applicable) This allows you to set default configuration for aspect properties while still enabling specific configuration for some document types that require a different rendering of a property.

For instance, specify a configuration for cm:titled, but override this for cm:folder to hide the field.

  - Id: cm:titled
    Evaluator: aspect
    Version: 1
    Forms:
      - Fields:
          - Id: auto
            Fields:
              - Id: cm:title
  - Id: cm:folder
    Evaluator: node-type
    Version: 1
    Forms:
      - Fields:
          - Id: auto
            Fields:
              - Id: cm:title
                RenderMode:
                  - Hidden

Legacy sample: By Type vs by Aspect JSON Sample

Order of Metadata Fields

The order of metadata fields can be configured. Let us have a look at an example:

  - Id: xenit:mytype
    Evaluator: node-type
    Version: 1
    Forms:
      - Fields:
          - Id: basic
            Fields:
              - Id: cm:name
              - Id: type
          - Id: aspecttitled
          - Id: auto
            Fields:
              - Id: cm:content
                RenderMode:
                  - Hidden
              - Id: cm:source
                RenderMode:
                  - Hidden
              - Id: cm:destination
                RenderMode:
                  - Hidden

Legacy sample: Order of Metadata Fields Type JSON Sample

This configuration will determine the order of the field sets for nodes with type “xenit:mytype”. The evaluator is set to “node-type”.

Under “Sets” you can see that there are 3 field sets: “basic”, “aspecttitled” and “auto”. The “basic” set contains 2 fields. The order of these fields is determined by the order in which they are defined in the set. This means that in this case the “cm:name” property will be followed up by the “type” property in the metadata panel. The “titleaspectset” set is configured as follows:

  - Id: cm:titled
    Version: 1
    Evaluator: aspect
    Forms:
      - Fields:
          - Id: aspectTitled
            Fields:
              - Id: cm:title
                RenderMode:
                  - Hidden
              - Id: cm:description
                RenderMode:
                  - Hidden

Legacy sample: Order of Metadata Fields Aspect JSON Sample A

There are 2 fields defined in the “aspectTitled” set. “cm:titled” will be followed up by the “cm:description” property in the metadata panel. The “aspectTitled” set follows the “basic” set in the metadata panel. The “auto” set, which contains all fields that are not added to a specific set, is shown at the bottom of the metadata panel, after the other sets.

In this example the “aspectTitled” set is only used for properties of the cm:titled aspect. However, properties of multiple aspects can also be part of the same set. Please have a look at the following example:

  - Id: cm:titled
    Evaluator: aspect
    Version: 1
    Forms:
      - Fields:
          - Id: title
            Fields:
              - Id: cm:title
              - Id: cm:description
  - Id: cm:author
    Evaluator: aspect
    Version: 1
    Forms:
      - Fields:
          - Id: title
            Fields:
              - Id: cm:author

Legacy sample: Order of Metadata Fields Aspect JSON Sample B

In this example we see that fields for cm:titled, cm:description and cm:author are all part of the “title” field set. The order of the fields cannot be determined unambiguously. The field for the cm:description property will always follow the field for the cm:titled property but the field for cm:author can be above or below those 2 fields. It depends on which aspect (cm:titled or cm:author) is loaded in first in Alfred Desktop.

Configuration of the aspect picker

By default, the aspect picker (edit mode) will display all aspects that are defined in the models which are referred to by their namespace in the config.js file (see Custom Default Configuration section). However, you might want to put a restriction on the available aspects in the aspect picker. Document models can contain technical aspects that are not supposed to be viewed by the user or some aspects might be irrelevant for certain types. It is possible to restrict the aspects shown in the aspect picker by configuring it in the forms-configuration.

You can specify a static list of aspects to that extend on a node-type or aspect basis, just like you configure the visibility of node properties. Let’s limit the aspect picker to cm:titled for all nodes with aspect cm:versionable.

  - Id: cm:versionable
    Version: 1
    Evaluator: aspect
    Forms:
      - Fields:
          - Id: aspect-picker-set
            Fields:
              - Id: aspect-picker
                Parameters:
                  aspect.1: cm:titled
          - Id: auto
            Fields:
              - Id: cm:title

Legacy sample: Configuration of the aspect-picker JSON Sample

Configuration of the Controls

Label Colors

If you want certain controls to be more striking you could change the label colors or add a field set with a legend.

To change the label color of a control add the property “ForegroundColor” to a field. The following code snippet also adds a field set with legend “Info” and wraps around the cm:name and type property.

  - Id: default-node
    Evaluator: string-compare
    Version: 1
    Forms:
      - Fields:
          - Template: gui.controlfactory.fieldset.group
            Text: Info
            Fields:
              - Id: cm:name
                ForegroundColor: DarkOrange
              - Id: type
                ForegroundColor: DarkOrange
            Parameters:
              centered: true
              collapsible: false
              start-collapsed: false

Legacy sample: Label colors JSON Sample

Date Picker

Default when a date property is empty it will stay empty, although this can be configured. When a date property should always be the date of today, we can add the parameter “override-default-value” and set the value to “today”. Static dates are also supported (format: DD/MM/YYYY).

  - Id: default-node
    Evaluator: string-compare
    Version: 1
    Forms:
      - Fields:
          - Id: example-set
            Fields:
              - Id: fred:exampleDate
                Parameters:
                  override-default-value: today

Legacy sample: Date Picker JSON Sample

People Picker

Default the people picker will search for users but this can be configured. It is configurable by adding the parameter “authority” to the “gui.controlfactory.property.authority” template. The value of this parameter can be set to “user”, “group” or “both” to search for users, groups or both respectively.

  - Id: people-picker-example
    Evaluator: aspect
    Version: 1
    Forms:
      - Fields:
          - Id: example-set
            Fields:
              - Id: fred:examplePeople
                Template: gui.controlfactory.property.authority
                Parameters:
                  authority: group

Legacy sample: People Picker JSON Sample

Size & mimetype

Show content properties like size and mime type in the metadata-panel.

  - Id: default-node
    Evaluator: string-compare
    Version: 1
    Forms:
      - Fields:
          - Id: example-content-props-set
            Fields:
              - Id: sizeProperty
                Template: gui.controlfactory.property.size
                Text: Size
                Parameters:
                  type: property
                  qname: cm:content
              - Id: mimeTypeProperty
                Template: gui.controlfactory.property.mimetype
                Text: Mimetype
                Parameters:
                  type: property
                  qname: cm:content

Legacy sample: Size & mimetype JSON Sample

Configuration of the document-type picker

The types that are visible in the document type picker of the metadata panel can be configured in the config.js file (see Custom Default Configuration section).

The visible types in the document type picker con be further specified via forms configuration. Consider the following example:

- Id: default-node
  Evaluator: string-compare
  Version: 1
  Forms:
    - Fields:
        - Fields:
            - Id: cm:name
            - Id: template-name
              RenderMode:
                - Create
            - Id: type
              Parameters:
                doctype.1: cm:content
                doctype.1.1: prefix:docType1
                doctype.1.2: prefix:docType2
                doctype.1.2.1: prefix:docType3
                doctype.1.3: prefix:docType4
                doctype.2: cm:folder
        - Id: title
        - Id: auditable
        - Id: auto
          Fields:
            - Id: cm:content
              RenderMode:
                - Hidden
            - Id: cm:source
              RenderMode:
                - Hidden
            - Id: cm:destination
              RenderMode:
                - Hidden
            - Id: xenit-hash:schemeId
              RenderMode:
                - Hidden
            - Id: xenit-hash:hash-value
              RenderMode:
                - Hidden
            - Id: sys:cascadeCRC
              RenderMode:
                - Hidden
            - Id: sys:cascadeTx
              RenderMode:
                - Hidden
        - Id: rm
        - Id: aspect-picker-set
          Fields:
            - Id: aspect-picker
              RenderMode:
                - Edit
                - Create

In this example, for documents there will only be 5 different node types available in the document type dropdown: cm:content, prefix:docType1, prefix:docType2, prefix:docType3, prefix:docType4.

├── cm:content
    ├── prefix:docType1
    ├── prefix:docType2
    │   ├── prefix:docType3
    ├── prefix:docType4

For folders there will only be 1 node type available: cm:folder.

├── cm:folder

Configuration of autocomplete dropdown based on source file

It is possible to add an autocomplete metadata field where the results are based on the contents of a source file.

In edit mode you can start typing in the text box and based on the values in a source file it will suggest all possible values. Multi-value properties and single-value properties are both supported.

Dropdown control for a single-value property

Dropdown control for a multi-value property

This feature is similar to a list constraint (defined in the model) on a property but the list has the advantage of being fully editable. You do not have to make changes to the document model. you only need to change the list in the source file.

To enable this feature you will need 2 custom made webscripts. The first web script is responsible for searching a value in the source file. The second web script is responsible for looking up a key in the source file and resolving it to the corresponding value.

Both webscripts should return a json result that looks like the following the following output:

  [
    {
        "guid":"1",
        "label":"Colette"
    },
    {
        "guid":"2",
        "label":"Alfredo"
    },
    {
        "guid":"3",
        "label":"Drew"
    },
    {
        "guid":"4",
        "label":"Fidelia"
    },
    {
        "guid":"5",
        "label":"Gary"
    },
    {
        "guid":"6",
        "label":"Rickie"
    },
    {
        "guid":"7",
        "label":"Nickolas"
    },
    {
        "guid":"8",
        "label":"Vivien"
    },
    {
        "guid":"9",
        "label":"Dominique"
    },
    {
        "guid":"10",
        "label":"Billi"
    }
  ]

The following configurations are also required:

  - Id: repo.resources
    Evaluator: string-compare
    Version: 1
    Forms:
      - Fields:
          - Id: guid
            Fields:
              - Id: lookup
                Parameters:
                  endpoint: '{url:base}/service/resource/csv/translate?id={0}&format=json&alf_ticket={auth:ticket}'
                  resource-key: guid
                  resource-value: label
                  resource-error: error
              - Id: query
                Parameters:
                  endpoint: '{url:base}/service/resource/csv/search?property={parameter:qname}&query={0}&format=json&alf_ticket={auth:ticket}'
                  resource-key: guid
                  resource-value: label
                  resource-error: error

Legacy sample: Configuration of autocomplete dropdown based on source file JSON Sample Query

Note: {url:base} syntax is described in URL Addressability

Under “Fields” you can see 2 objects. The first object is the “lookup” object. This object is used to show the property value in view mode. The “endpoint” is the url to the webscript that is responsible for the lookup. The second object is the “query” object. This object is used to search for all possible values for the property in edit mode. The “endpoint” is the url to the web script that is responsible for querying.

Now you also need to configure the dropdown control for the metadata panel. You can do this in the following way:

  - Id: sample:myAspect
    Evaluator: aspect
    Version: 1
    Forms:
      - Fields:
          - Id: dropdown-set
            Text: Dropdown Data
            Fields:
              - Id: sample:myProperty
                Template: gui.controlfactory.property.dropdown
                Text: My property value
                Parameters:
                  type: property
                  qname: sample:myProperty
                  resolver: repo.resources.guid
                  max-display-result: 10
                  min-input-length: 1

Legacy sample: Configuration of autocomplete dropdown based on source file JSON Sample Form Configuration

The template that has to be used is the “gui.controlfactory.property.dropdown” template. The “type” parameter has to be kept the same as in this example. The “qname” parameter value has to be set toe the qname of the property. The “resolver” parameter value points to the id of the field set containing the lookup object and the query object (see previous configuration snippet). If you use that configuration snippet, this value can be kept the same as in the example configuration. The “max-display-result” can be set to a value of choice. This is the max amount of items that are suggested when querying all possible property values in the metadata panel. By default this value is set to 500. Lower values will result in better performance. The “min-input-length” is the minimum amount of characters needed in the property input field before it starts querying for all possible values. By default this is set to 0. For larger source lists it is recommended to change this to a higher number like 2 or 3 to increase performance.

Forms Column Configuration

Users can select which columns they want to view in Alfred Desktop’s folder view.

Alfred Desktop comes with 2 sets of configuration that define how users can select different columns:

  • column lists allow the user to add or remove a single column
  • column sets allow the user to use a (forms-config) predefined set of columns or his own saved set of columns

Forms Column Configuration

Column List Configuration

The syntax to define the list of columns a user can select:

  - Id: default-column-list
    Evaluator: string-compare
    Version: 1
    Forms:
      - Fields:
          - Id: System
            Text: System Properties
            Appearance: section
            Fields:
              - Id: Format
              - Id: Location
              - Id: Info
              - Id: WorkingCopy
                Appearance: submenu
                Fields:
                  - Id: cm:workingCopyOwner

Legacy sample: Column List Configuration JSON Sample

Note that Id can either by “default-column-list” of “column-list”.

The former will replace the whole list of built-in column-properties under “System Properties”. The latter will prepend the forms-config-defined list to the “System Properties”

Using the Appearance option, a subsection can be rendered as either a section or a submenu.

Column Color Configuration

The color of one or more columns can be changed through forms configuration. You can change the text and/or the background.

The text color can be changed by adding the “foreColor” parameter. If you want to change the background color of a column you will need the “backColor” parameter.

In this example we change the text color to red (RGB value of “255,0,0”) and the background color to blue (RGB value of “0,0,255”) for the column containing the property with QName sample:property.

      - Id: SubmenuID
        Appearance: submenu
        Text: Submenu
        Fields:
        - Id: sample:property
          Text: Sample Property
          Parameters:
            foreColor: "255,0,0"
            backColor: "0,0,255"

It is also possible to change the background color and the text color of a column based on the value of the cell. In order to change the text color you need to use the “foreColorOverrides” parameter. To change the background color you need to use the “backColorOverrides” parameter.

In this example we change the text color and background color of the column with QName sample:property. If the cell has “value1” as content the text color is black (RGB value of “0,0,0”) and the background color is a kind of blue (RGB value of “66,223,244”). If the cell has “value2” as content the text color is black (RGB value of “0,0,0”) and the background color is green (RGB value of “0,255,0”). If the cell has “value3” as content the text color is black (RGB value of “0,0,0”) and the background color is a kind of orange (RGB value of “244,155,66”).

       - Id: SubmenuID
        Appearance: submenu
        Text: Submenu
        Fields:
        - Id: sample:property
          Text: Sample Property
          Parameters:
            foreColorOverrides:
              "value1": "0,0,0"
              "value2": "0,0,0"
              "value3": "0,0,0"
            backColorOverrides:
              "value1": "66,223,244"
              "value2": "0,255,0"
              "value3": "244,155,66"

In this configuration, individual fields represent the columns in a set (and are not rendered in the menu). The sections are the column-set menu items.

Configuring Search Facets

The configuration of search facets used to be part of the forms configuration. Starting from Fred 3.5 this configuration is no longer supported.

Available search facets in Alfred Desktop are now configurable through the Facet Manager of Alfresco Share. You can access the Facet Manager following this url:
http://{hostname}:{port}/share/page/dp/ws/faceted-search-config. Adding a facet here will also make it available in Alfred Desktop.

URL Addressability

The concept of URL addressability was introduced in Alfred Desktop to increase configuration flexibility and reduce the maintenance required to maintain the configuration across different Alfresco servers.

Supported Components and Parameters

Components supporting this functionality:

  • Web browser component
    • Show in Browser (makes use of the web browser)

Supported parameters:

{url:schema}
{url:host}
{url:port}
{url:context}
{url:base}
{url:share}
{data:id}
{data:kind}
{node:name}
{node:ref}
{node:ref:id}
{node:ref:storeprot}
{node:ref:storeid}
{node:propertyPrefix:propertyLocalName}
{auth:ticket}
{username}
{user:name}
{user:node:ref:id}
{settings:lang}

Example

Given the following arguments:

  • Alfresco server URL http://www.xenit.eu:8080/alfresco
  • Node name TestName
  • The node has a property cm:title with value set to “title”
  • Parameterized URL {url:base}?repo={node:name}&nodeTitle={node:cm:title}
    &id={auth:ticket}

The expected result should look like this:

http://www.xenit.eu:8080/alfresco?repo=TestName&nodeTitle=title
&id=TICKET_1ae81ec51a2264e8eddde248c6e89372d3fdfea6

The node has property cm:title set to “title”. In the parameterized url {node:cm:title} is replaced by the value of the cm:title property. Of course, other properties are also supported. If you have a property with short qname “prefix:localName” you just add the following parameter to the url: {node:prefix:localName}

To expand {url:base} to the full syntax, here is the piece-by-piece parameterized URL:

{url:schema}://{url:host}:{url:port}/{url:context}?repo={node:name}&id={auth:ticket}

Creating Documents from Templates

To create documents from document templates in the Alfresco repository, you have to add the templates to the folder ‘Node Templates’ in Data Dictionary.

Document Templates in Data Dictionary

All the documents that are inserted in this folder will be shown under “New Document” in the context menu.

Creating a new document from a Template

Within the “Node Templates” folder you can also create subfolders and put your document templates in it to group them together.

You can configure which templates will be available for which user or group by setting permissions on the templates in the Document Template folder. So you can attribute a template to the finance department.

Column Set Configuration

It can be useful to group properties together in such a way that the user can instantly select the group or set of properties.

Forms Column Set Configuration

This can be defined via the column set configuration:

  - Id: default-column-sets
    Evaluator: string-compare
    Version: 1
    Forms:
      - Fields:
          - Id: AuditSet
            Text: Who / When
            Fields:
              - Id: cm:author
              - Id: cm:modified
          - Id: ByApsectsSets
            Text: By Aspects
            Fields:
              - Id: AuditableAspect
                Text: Auditable
                Fields:
                  - Id: cm:creator
                  - Id: cm:created
                  - Id: cm:modifier
                  - Id: cm:modified

Legacy sample: Column Set Configuration JSON Sample

In this configuration, individual fields represent the columns in a set (and are not rendered in the menu). The sections are the column-set menu items.

Changing behaviour of the metadata panel for specific node types

By default, in the metadata panel, every field will be added to the auto field set unless there is a custom forms configuration that adds it to another field set ( see section Forms configuration of a type).

This behaviour can be slightly changed. For node type specific forms configurations it is possible to only allow fields to be shown that are part of a field set, except for the auto field set. Fields will no longer be added automatically to the auto field set.

This change in behaviour can be achieved by adding parameter forms.fieldsets.auto.show-all-fields to the extended section in that config.js file and setting its value to false.

path:
$tomcat/shared/classes/alfresco/extension/templates/webscripts/
eu/xenit/config/config.js

    var configByGroup = {
        "default": {
            "namespace"     : "",
            "rootdoctype"   : "{http://www.alfresco.org/model/content/1.0}content",
            "rootnoderef"   : (this.companyhome != null)?companyhome.nodeRef.toString():"",
            "extended"      : {
                "forms.fieldsets.auto.show-all-fields" : "true"
            }
        },
    };

The default value of forms.fieldsets.auto.show-all-fields is true.