We have just released our latest Fast-Track version - Nuxeo Platform FT 9.1 and it’s available for download on our website. This release adds some powerful new features and enhancements to the platform to help you maximize the value of your digital assets. Some highlights of the release include:
- Full MongoDB support: This means you no longer need an additional RDBMS when using MongoDB for the repository database.
- Improved search: We have added APIs that will improve your search experience by highlighting the search results. This feature will be leveraged later this year by the Web UI.
- Elasticsearch security: You can now use Elasticsearch Shield to protect your Elasticsearch server.
But the most noteworthy feature of this release is the policy-based versioning. This new feature enables automated document versioning and removes the need for users to determine if they should version a document or change the state. Let’s take a detailed look at this feature.
Centralised Automated Release Policies
With FT 9.1, you can contribute rules that dictate the versioning behaviour of documents, depending on their type, property, as well as the user’s properties. These rules will be applied to any interface used for modifying a document: API, Web UI, Drive, JSF Application, Default Automation Operations and even custom code. For instance, you can create rules for scenarios like: “Each time a case report is modified, a version that includes the modification is created with a minor upgrade” or “A version is created each time a user who is not an admin updates the document.” It could also be something like “Specification documents should be versioned systematically when modification is made by someone from the the group ‘External Contractor’”.
Contributions Using Extension Point
Rules are contribute to the “policies” extension point of the versioning service:
<policy id="note-as-wiki" beforeupdate="true" increment="MINOR" order="50"><filter-id>note-filter</filter-id></policy>
BeforeUpdate determines whether we version before or after a modification. increment can be NONE, MAJOR or MINOR and defines which version number has to be updated. order is used when several rules are applied and defines in which order the policies should be taken into account (they are taken in ascending order). The filter part defines the conditions under which the document should be versioned.
You can read the versioning documentation and the extension point documentation for more information.
Collaborative and Wiki Style Schemes
By default, we have added the following automated versioning schemes in the platform:
collaborative-save: Each time someone updates an asset that was created or updated by someone else, it makes a version of the asset prior to the modification to avoid any information loss inadvertently. (The prerequisite is that the document must have the file schema).
note-as-wiki: For Note document type, a version is made after each save action.
More Consistency
We prioritized this evolution to maintain consistency in the versioning behavior. Some of our customers observed different versioning behavior for Drive and for drag’n drop in the user interface. Each of these interfaces had different but great ideas implemented for versioning and it just made sense to standardise the behaviour and centralise the definition!
If you don’t like this new behaviour though, compatibility solutions exist! Old configurations are still considered by the platform, and we made sure that the migration would be as seamless as possible. Also, since this is the Fast-Track version we have plenty of time to get your feedback and improve before releasing the next Long-Term Support version.