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:
- first step is a validation step on a document by a user,
- 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:
- add a schema with the added metadata,
- create a new type of document that has the
DocumentRoutefacet and the
When creating a new type of
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
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
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