External Document Storage

> Administration > Account Management > External Document Storage

If the enterprise has an external Content Management System (CMS), the platform can use it for Document Storage for File Fields and Image Fields of AgileApps Live.

Caveat

This functionality is highly recommended to be used by only new tenants after 10.6 upgrade. Enabling it in existing tenants created before 10.6 version will make the File and Image fields usage unavailable.

Configuration

Configuration to Content Management System can be set by users with 'Manage Company Capabilities' enabled in their access profile. Configuration can be set by clicking on the Gear icon --> Administration --> Account Management --> External Document Storage Following fields are available for providing connection and authentication information to CMS

• Enabled (Checkbox to enable External Document Storage)
• AtomPub URL (e.g., Alfresco AtomPub URL is http://{host}:{port}/alfresco/cmisatom)
• Username
• Password
• Repository Id
• Root Folder Id

If External Document Storage is enabled, URL, Username, Password and Repository Id are required fields. Root Folder Id is not a required field and if dedicated root folder is not provided for this tenant, Repository's root folder will be used to store the documents.

Platform Behavior, User Experience and Administration

When a user logs in, the platform carries out the following sequence of activities:

• If their User record was created in the platform, they log in with those settings.
• If the user is not known to the platform, the LDAP directory is searched for a matching entry.

• If none is found, access is denied.
• If a matching entry exists, a new LDAP-enabled User record is created.

• Thereafter, when the user logs in, their password is validated against the LDAP directory.
• At the same time, any changes made to the user's LDAP settings are synchronized with the platform.

As far as the user is concerned, therefore, they simply log in to the platform using the same credentials they use everywhere else.

And as far as admins are concerned, user information is maintained in one place--the LDAP server. Any changes made there are automatically seen by the platform.

Effect on User Profiles

When a user has an entry in an LDAP directory, most of their profile information is maintained in the LDAP server. The platform reads that information from the server. It can no longer be modified in the platform. The exception is profile information that is specific to the platform.

In particular:

• In the initial dialog a user sees when they log in, the Reset Password option is disabled.
• In the user's Personal Settings page, only the user's Team affiliation and default Application can be modified. Other settings can be viewed, but not changed.
• In the admin's Access Management > Users page:

• The option to Reset Password is disabled for LDAP users.
• The user's Team affiliation and default Application can be modified. Other settings can be viewed, but not changed.

LDAP Address Expressions

In its simplest form, LDAP can be thought of as a hierarchy of directories, each of which contains entries for users and other entities. But instead of using a URL to address those directories, you use a combination of syntax elements.

For example, consider the URL http://yourCompany.com/united_states/california/users/yourLDAPdata.
That path is specified in LDAP elements using the elements below:

• DC (Domain Controller) Used to specify the LDAP domain.

For example: DC=yourCompany, DC=com, which corresponds to yourCompany.com in the URL.

• OU (Organizational Unit) A group that can contain other groups. (Effectively, an "intermediate" group.)

For example: OU=california, OU=united_states, which corresponds to the URL path /united_states/california.

• CN (Common Name) A group that can contain individual entries, but which cannot contain subgroups.

For example: CN=users, which corresponds to the final directory in the URL.

Within that directory, the entry yourLDAPdata can be found.

Considerations and Limitations

• Active Directory is currently supported.
• A single LDAP server is supported, for now.
• The search for a matching user does not yet span multiple groups, so a CN entry must be included either in the specification of the search directory, in the user or group directory designation, or in one of their filters. The search path cannot terminate at an Organizational Unit (OU) directory, as that would require searching the multiple subdirectories it contains.
• The user's Team cannot currently be configured using LDAP attributes. The default team is always used for a new user.
  (The team setting can be changed in the platform after the user logs in.)
• Similarly, to give a user access to multiple applications, or to change the user's initial application modify the Application Access settings after the user has logged in to the platform.

Working with LDAP

Configuring LDAP

1. Examine the configuration settings below to see which individual-user attributes can be populated from LDAP.
2. If desired, create attributes for those settings in your LDAP server.

   (If all users will have the same settings, this step is not necessary. They'll use the default settings you configure below.)

3. Go to > Administration > Account Management > LDAP Configuration
4. Fill in the configuration settings
5. Click [Save]

Configuration Settings

• Server Type - The type of LDAP server. Active Directory is the default.
• Server URL - The server domain and optional portal. Secure portal #636 is the default.

For example: our.LDAPserver:998

---

• Login DN - The Distinguished Name of a user that has admin privileges.
• Password - The admin user's password.

---

• Starting Search Directory

A comma-separated list of DC and OU expressions that leads to the start of the search path.

Optionally, include a CN directive as well, to completely specify the directory to be searched.

---

• User DN - Optional. An LDAP expression that designates a path to an LDAP user directory, starting from the initial directory.
• User DN Filter - Optional. An expression that limits the LDAP entries that will be examined.

For example, use a setting like this one to exclude disabled users: !(userAccountControl=514)

Note: The (objectCategory=person) and (objectClass=user) parameters do not need to be specified. They are included automatically.

---

• Group DN - Optional. An LDAP expression that designates a path to an LDAP "group" (distribution list) directory, starting from the initial directory.
• Group DN Filter - Optional. An expression that limits the LDAP entries that will be examined.

For example, use a setting like this to exclude entries that include the word "test": !(mail=*test*)

Note: The (objectCategory=group) parameter does not need to be specified. It is included automatically.

---

---

• Default Team - A new user's default Team.

The team assignment can be changed in the platform after the user logs in.

The user can change it in their Personal Settings. An admin can do so in the Users page.

---

• Default Access Profile - A new user's default Access Profile.

The user's access profile is fully determined by the configuration.

• LDAP Attribute for Access Profile - The name of the LDAP attribute that designates the user's access profile.

The attribute must contain an access profile's record ID.

To get a record ID:

a. Go to > Access Management > Access Profiles

b. Modify the view to display Record IDs, and copy the ones you need.

---

• Default Application - The initial Application the user sees when they log in.

That setting can be changed in the platform after the user logs in.

The user can change it in their Personal Settings. An admin can do so in the Users page.

To grant access to additional applications:

a. When the user logs in, a User record is created for them in the platform.

b. You can then use the Application Access page to specify the applications the user can access.

• LDAP Attribute for Application - The name of the LDAP attribute that designates the user's application.

The attribute must contain the application's record ID.

To get a record ID:

a. Go to > Access Management > Application Access

b. Modify the view to display Record IDs, and copy the ones you need.

---

• Default Role - The new user's Role in the application.

That setting can be changed in the platform after the user logs in.

The user can change it in their Personal Settings. An admin can do so in the Users page.

• LDAP Attribute for Role - The name of the LDAP attribute that designates the user's role in the application.

The attribute must contain the role's record ID.

To get a record ID:

a. Open the application, if it is not already running.

b. Go to > Customization > Application Roles

c. Modify the view to display Record IDs, and copy the ones you need.

Overview Ability to connect to an external Content Management System for document storage for File Fields and Image Fields of AgileApps Live. Please Note: This functionality is highly recommended to use only in new tenants after 10.6 upgrade. Enabling it in existing tenants (before 10.6) will make the File and Image fields usage unavailable. Configuration Configuration to Content Management System can be set by users with 'Manage Company Capabilities' enabled in their access profile. Configuration can be set by clicking on the Gear icon --> Administration --> Account Management --> External Document Storage Following fields are available for providing connection and authentication information to CMS Enabled (Checkbox to enable External Document Storage) AtomPub URL (e.g., Alfresco AtomPub URL is http://{host}:{port}/alfresco/cmisatom) Username Password Repository Id Root Folder Id If External Document Storage is enabled, URL, Username, Password and Repository Id are required fields. Root Folder Id is not a required field and if dedicated root folder is not provided for this tenant, Repository's root folder will be used to store the documents. Functionality After the configuration has been set, files and images uploaded to the File Fields and Image Fields are stored in the CMS. The path used to store the documents is in the format {objectId}/{recordId}/{fieldTableColumn}/FileName under the root folder. Clicking on file field and image field values in the record page, downloads the files from CMS server and shows it to the user. Files from CMS are deleted when a file/image is removed from the AAL record by editing the record and removing it an object record with file/image fields is deleted forever from Recycle Bin. a file or image field is deleted from the Object Fields page (Customization in setup). an object is deleted forever from Recycle Bin (Customization in setup) When a tenant is deleted and if the Root Folder Id is set in the configuration, then the given root folder and its contents are removed from CMS. If root folder Id is not specified then the files are not deleted when deleting tenant. This approach is used to not accidentally delete the files in case if the default repository root folder is used for many tenants.