All Nuxeo CMF documentation versions

Nuxeo Case Management Framework (CMF) 5.5
Nuxeo Case Management Framework (CMF) 1.x

Case Management 5.5

This documentation relates to an old version of the Nuxeo Platform (5.5). You may want to check the User Guide for the latest version of the Nuxeo Platform.

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Adding metadata to the route

When running a route, we might want to use the result of an action of a step in another step. We can persist some metadata in the route so they can be used by all steps. A typical example would be:

  1. first step is a validation step on a document by a user,
  2. second step will publish this document in a section, if the document was approved.

The result of whether the document was validated or not needs to be persisted in the route document so it can be used by the second step. To add metadata to a route we need to:

  1. add a schema with the added metadata,
  2. create a new type of document that has the DocumentRoute facet and the document_route_instance and document_route_model model schemas.
Tip

When creating a new type of DocumentRoute, you should not forget to update the ecm type contribution so the new type of document is available to the user for creation.
You can have a look at the DocumentRoute contribution and document_route_instance and document_route_model model schemas as an example.

Content Routing security

When a user validates a Route, an instance is created in a restricted part of the repository. It is created with an unrestricted session (as Administrator). So afterward, if we want a user to validate or refuse a step or modify the route, we need to give him the rights to do it.

All steps of the route are always running using an unrestricted session, with the possible exception of setting the step to "Done state". If the step doesn't need user interaction, "Done" state will be set with an unrestricted session. If it needs the user to do an action, we use the user's sessions. So a user only needs Validate rights on the step to validate/refuse a task, even if the validation of the step leads to other steps to be validated.
Each step of the route will throw events that will allow to modify the security on the route and steps. This implementation provides for highly customizable security: you can disable a listener and create your own listener according to your security needs. 

Because the Route is not aware of what happens when a step is run (it doesn't know what is inside the operation chain), it is the responsibility of the operation chains to modify the step if needed. Typically, if an operation chain assigns a task to a user, the operation chain should also give the correct validating rights to this user for the step.

The security of a route is based on the security of the documents. Rights on Route and Step are mapped to the rights on the underlying document:

Security of Document Routing

Security implementation

comment

Can create a Route Model

user can create a DocumentRoute document type

everyone should be able to do it. If you need to customize it, you can override the typesTool seam component. Look at CMF code for an example where only routeMangers can create a DocumentRoute

Validating a Route Model

users belonging to the group routeManagers 

you can add filters to the action to modify who can access the button

Creating a Route instance

If a user can access a document and a route, he can run an instance

the group routeManagers can modify the rights on DocumentRoute to give rights only to people who can start instances of it

Validating a step

user can follow transition on the Step document

 

Updating a step

user has write permissions on the Step document

 

Deleting a step

user has delete permissions on the Step document

 

Adding a step

user can add children on the parent document

 

RELATED TOPICS
Document types
Events and Listeners
Content Automation
Security management in a Nuxeo Repository