Defining Content Constraints for Workflows

Defining Content Constraints for Workflows

Scrivito’s workflows not only let enterprises specify the teams for creating working copies and publishing them. Furthermore, you can define constraints to restrict the website area or the kind of content the teams should work on. If a workflow doesn’t have such constraints, the teams simply aren’t restricted and can add or delete or change whichever piece of content they deem appropriate.

Constraints are expressed as a JSON array whose elements, the permits, are again arrays made up of conditions.

A workflow’s content constraints consist of a list of permits. Any number of permits can be specified, and every additional permit broadens the scope of actions the teams can take.

A permit consists of one or more attribute-related conditions a CMS object must meet to be editable in the context of the workflow. If more than one condition is specified in a permit, all of them must be met for the permit to be effective. Optionally, a condition can be negated.

Here are some examples:

PermitThe workflow makes a CMS object editable if …
[[{ "field": "_site_id", "operator": "equals", "value": "international" }]]… its _siteId object attribute equals international.
[[{ "field": "lang", "operator": "equals", "value": ["en", "de"] }]]
… its lang attribute equals en or de.
[[{ "field": "lang", "operator": "equals", "value": ["fr", "it"], "negate": true }]]
… its lang attribute equals neither fr nor it.
[[{ "field": "multilang", "operator": "equals", "value": "yes" }, { "field": "lang", "operator": "equals", "value": "en" }]]… its multilang attribute equals yes and its lang attribute equals en.

As the field of a condition, the built-in attributes _obj_class, _path and _site_id as well as all custom attributes of the string, stringlist, enum and multienum types can be specified.

Next to the equals operator, starts_with and is_inside_subtree_of are available, but only in connection with the _path attribute. starts_with checks whether a CMS object is located directly or indirectly underneath a specific parent object, i.e. belongs to a specific section of the page hierarchy. is_inside_subtree_of does the same but expects the value to be an object ID, not a path prefix.

Permit The workflow makes a CMS object editable if …
[[{ "field": "_path", "operator": "starts_with", "value": "/product" }]] … its _path attribute value starts with /product.
[[{ "field": "_path", "operator": "is_inside_subtree_of", "value": "2b2883c23aca09da" }]]
… its _path attribute value starts with the _path attribute value of the object whose ID is 2b2883c23aca09da.

If, in the second and last example above, the object with the specified ID doesn’t have a path, is_inside_subtree_of is true for this object only.