Release Notes 3.2.27

Publication Date: March 3rd 2019

The following are the new features, enhancements and fixed issues for Cloud CMS 3.2.27 release.

Upgrade from 3.1.x

For Docker on-premise customers and for customers who've built custom modules, we recommend reviewing the [Cloud CMS 3.2 Migration Documentation](https://www.cloudcms.com/documentation/docker/maintenance/upgrades.html).

Cloud CMS API

• Moving a node now properly re-indexes the node within the FileFolderService for some edge cases
• Changes to parental path relationships are now propagated to the target during deployment
• Added a missing title for the "deployNode" action in the actions drop down

Cloud CMS User Interface Server

• When viewing a document, the "type" link has now been corrected to point to the correct place
• The "Selected..." dropdown now respects access control rights on individually selected items to reflect whether actions are enabled or disabled. If permissions are not granted for the selected item(s), they will be disabled.
• When performing UI extensions, custom region overrides now push their configuration down into custom JS gadget implementations
• Users with the Project Manager authority can now view and utilize the "Release Immediately" button (no need for a separate authority)
• The Delete and Edit Attachment buttons for Document Attachments now enable or disable basedon the current user's authorities
• The Delete and Change Password buttons for users at the Platform level now enable or disable based on the current user's authorities
• On the Document Versions page, the Changeset Link (to admin console) only appears for Project Managers
• Fixed a bug so that Project Owners can now see the Manage Project button (and no longer need separately

have the Project Manager authority assigned)

• Fixed a bug so that Project Managers can add users to Projects as intended (without the need for a separate authority grant)

Cloud CMS Application Server

• Updated to the latest `cloudcms-server` node module
• Now checks for the existence of a local `custom.js` file on startup and, if available, calls an `init()` function to allow for easy extension of the server (including registration of custom Dust functions, routes and more).