Alfresco target connector

The Alfresco target connector uses the Alfresco REST API that is supported by Alfresco 4.2 and higher. Permissions are set using an update on a node and versions are uploaded using an update on the content of a node. Both endpoints are supported by Alfresco 5.2 and newer versions.

Features

• Node creation (including versions for documents). A node represents folders and documents in Alfresco.
• Custom content types.
• Custom properties/aspects.
• Permissions

Settings

mongoConnection

The Mongo connection string including the database name to connect to.

alfrescoUsername

The Alfresco REST API username.

alfrescoPassword

The Alfresco REST API password.

alfrescoUrl

The Alfresco base URL.

Example: http://localhost:8080

Model

The Alfresco metadata is populated from the Content Store. Below we describe the schemas with an explanation of how the fields are translated to the Alfresco fields.

{
  "migration" : {
    // REQUIRED | BOOLEAN | DESCRIPTION: Only objects where this value is set to 'true' will be created in Alfresco
    "migrate" : true
  },
  "target" : {
    // All the Content Store required fields + optional ones if required. Fields will be mapped to their Alfresco counter part automatically.
    // For example target.contentType.systemName will be mapped to nodeType, target.description will be mapped to cm:description and target.created.principal.systemName will be mapped to cm:creator
    "properties" : {
      // Any additional properties, using their technical property names defined in Alfresco
      // To find out about the technical names, use the Alfresco Model manager under Admin Tools
    }
  }
}

Versions for documents are uploaded from oldest to newest version. In Alfresco, versions all get back the same node ID. Therefore, only the migration.id of the current (latest) version is set, once all versions are uploaded. Permissions for nodes in Alfresco must be set with existing and valid group or user names (principals). These names are taken from the ACLs target.principals array. Each principal object in this array is expected to hold at least a systemName field, Each node can hold one other permission option that is taken from the node itself:

• isInheritanceEnabled: holds a boolean that can disable (or re-enable) inherited permissions. This is taken from the node's migration.flags.isInheritanceEnabled, defaults to true if not set.

It is also possible to set per ACL (permissions set) if the groups or users within the target.principals array that have these permissions are granted (ALLOWED) or denied (DENIED).

• accessStatus: allowed values are ALLOWED or DENIED. This value is taken from the ACL properties.accessStatus. Defaults to ALLOWED if not set.

note

For each principal, a separate ACL object should be created but it's not required. If multiple principals are set for the same ACLs, all permissions from the ACL will be set for each principal for the node. This might give unwanted permissions to groups or users that are not expected to have permissions.