Model Configuration

The Alfred Desktop Backend module needs to be configured for your dictionary model. The intent is similar to the share-config-custom.xml. It allows the administrator to define how you want the client application to represent (custom) metadata. When you apply the Alfred Desktop Backend amp
(alfred-desktop-backend-addon-alfresco-BB-C.D-XX.YY.ZZ.AA.amp), a sample file with minimal configuration is generated to get started quickly. It is located at:

$TOMCAT/webapps/alfresco/WEB-INF/classes/alfresco/templates/webscripts/eu/xenit/config/
config.js.sample

To get started, copy config.js.sample to this location (and remove the .sample extension):

$TOMCAT/shared/classes/alfresco/extension/templates/webscripts/eu/xenit/config/config.js

This folder structure needs to be created manually, since it does not exist in a default Alfresco installation. You can also choose to update the file with the desired configuration. For more details please consult with the Alfred Desktop Administration Guide. Once config.js is in place, go to the Web Scripts Home1 and refresh the webscripts.

Note: Accessing the Web Scripts Home requires an admin account

Minimal Configuration

The minimal config.js.sample configuration file uses the standard Alfresco content-model. All new documents will have the type cm:content.

$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" : companyhome.nodeRef.toString()
        },
};

The default configuration namespaces section is left empty, which means it does not know about custom content models. You have to add the namespace of your custom module to the namespaces section so that Alfred Desktop is aware of your model and can display your custom metadata.

This document only covers the installation steps. Please consult section “Basic Configuration” of the Alfred Desktop Administration Guide for more in-depth coverage.

Other Backend Amps

There are 3 other backend amps for Alfred Desktop that can optionally be installed. They are extension modules on the standard backend amps.

Metadata Injection Module Package

The Metadata Injection amp contains functionality to inject metadata into office documents.

Configuration

The metadata injector requires a configuration section in the module-context.xml file and the alfresco-global.properties file.

The module-context.xml file can be found at:

$TOMCAT/webapps/alfresco/WEB-INF/classes/alfresco/module/xenit-metadata-injection/
module-context.xml

You should not make any changes to this file directly, since all changes will be undone when the alfresco.war file gets re-extracted (ex. when a new amp is applied). Instead, you should create a metadata-injector-context.xml file at $TOMCAT/shared/classes/alfresco/extension. This file is used to override the Spring beans inside the original module-context.xml file. For an example the configuration file we refer to in section “Metadata Injector” in the Alfred Desktop Administration Guide. The alfresco-global.properties file can be found at $TOMCAT/shared/classes. In this file you need to add the following line: eu.xenit.alfresco.metadata.injector.enabled=true

Incomplete Node Tagger Module Package

By default, Alfred Desktop is quite liberal in what a user does with the metadata in Alfresco. Alfred Desktop asks the user to enter/edit the metadata when he/she uploads a new document, but doesn’t really enforce this.

Organizations that would like to enforce a stricter company-policy on metadata can enable the incomplete-metadata-policy. This policy will apply the xmd:incompleteaspect to documents that don’t have all mandatory metadata properties set or to a document where the type is one of the eu.xenit.incomplete.invalidTypes types. This allows Alfred Desktop/Alfresco to keep track of which user introduced a document into the repository and who is responsible to provide the metadata for a specific document

You can enable this functionality on a folder(-substructure) by applying the (configurable) validation-aspect on said folders. The Incomplete Node Tagger amp comes with a dictionary model that contains the aspect xmd:validate to do just that, but you can use any other aspect you’d like to use, including from your own dictionary model.

In practice, this means if a user uploads a document in a folder-structure that has
the metadata-validation-marker set, the user is “required” to select a specific node-type and has to provide all mandatory metadata on this document. The document is marked in Alfresco as metadata-incomplete and the user that uploaded the document is the metadata-owner.

Using the property deepMarkerSearch you can configure this policy to look only at its direct parent or walk up the folder hierarchy to see if any of the parent folders has the validation-marker set.

Incomplete Node Tagger Configuration

To configure the incomplete metadata policy add the following lines in the alfresco-global.properties file:

eu.xenit.policy.metadata.incomplete.enabled=false|true
eu.xenit.policy.metadata.incomplete.markerAspects=aspect-qname
Example value: xmd:validate
eu.xenit.policy.metadata.incomplete.excludeAspects=aspect-qname
Example value: xmd:ignore
eu.xenit.policy.metadata.incomplete.invalidTypes=type-qnames
Example value: cm:content
Example value: cm:content, myCorp:document
eu.xenit.policy.metadata.incomplete.deepMarkerSearch=true|false
eu.xenit.policy.metadata.incomplete.propertiesToIgnore=property-qnames

Set the enabled property to true to enable the incomplete metadata policy. In the markerAspects you can insert a comma-separated list of QNames that are marker aspects. Folders that have this marker aspect will be scanned for incomplete metadata. This includes subfolders of the folder that has the marker aspect. To prevent a subfolder from being scanned, you can mark it with an exclude aspect. The invalidTypes property is a comma-separated list of node-types that are too abstract and should be flagged as incomplete. To check the entire parent hierarchy for a marker aspect, set the deepMarkerSearch to true. Mandatory properties that need to be ignored can be added to the propertiesToIngnore list.

Note: QNames can be short or fully qualified.

For further optional configurations settings we refer sections “Incomplete Metadata Policy” and “Client Configuration” in the Alfred Desktop Administration Guide.

Alfred Desktop Records Management Module Package

If you have Records Management installed, Alfred Desktop supports some Records Management specific operations (declaring nodes as records, archiving nodes to a record folder, etc.). To be able to use this functionality, the Alfred Desktop Records Management amp has to be installed.

This module package requires no further configuration. Just installing it will enable all its functionality.

Reporting a Problem

When a problem occurs, you can report it to your local IT helpdesk or support@xenit.eu. The XeniT Alfred Desktop team will be able to assist you more quickly if you are able to provide the following information:

  • A description of your desktop environment: Windows version, application version
  • The Alfred Desktop version
  • A description of the problem
    • A screenshot is very helpful
  • Log files: you can find the log files by clicking on “Files” and then “Open settings location”
    • A list of log files appears. Attach the log files fred-logging to your report

Help Context Menu

To help the user report a problem, a ‘Report A Problem’ command has been added to the Help menu. Clicking this command will open your default email application and attach the log files to it. You need to complete the description of the issue before sending it to your local IT desk or the XeniT Alfred Desktop team.

Report A Problem Command

  1. Web Scripts Home https://my.alfresco.com/alfresco/service/ [return]