Sanity Check: Using Workflow Transitions To Manage Behaviours

Please check my assumptions before I head down a wrong development path:

Use case: I have an object (content type) that should have several custom Behaviours, but some of those Behaviours only make sense at certain States in the WorkFlow (also custom).

The way I am reading the documentation it sounds like I can activate/deactivate behaviours on an object (instance) by adding/removing a Marker Interface that is registered with each Behaviour for that content type... and that I could therefor use WF Transitions to make those changes to an object's Marker Interfaces.

It sounds like I could use this to create a content type that becomes increasingly sophisticated as it progresses through a workflow.

Am I reading this correctly? Will that work? Are there Gotchya's I need to be aware of?

Behaviors are global per content-type but not to individual content-types instances.

https://github.com/collective/collective.instancebehavior might be of help

Flaky and not really working with 5.2 and Python 3

Ah, in which case you'll have to extend/override https://github.com/plone/plone.dexterity/blob/242a6272043e344a4fdc38ee5ebcd76f7669cc22/plone/dexterity/behavior.py to allow/dissallow certain behaviors

Hmmm. Okay thank you!
~ Ian

Ian F. Hood
Offices: 1 (360) 450-5900 (US)
Twitter, Skype, FB & LinkedIn as: IanFHood
Google+ 103220441876580461422

As already told, the default behavior of behaviors are static and only per content type.

The behavior framework allows implementing custom behavior activation rules, but that could lead to reduced performance, depending on the use case.

Yet, if your all behaviors are custom, then you could probably implement them as “always on behaviors”, but check on each request if the behavior should do something or not. Eg. the form fields provided by a behavior could be implemented to be conditional on the workflow state.

1 Like

Behaviours fields have read permission, so you can for example deny read to field based on workflow status/Role. Here an example with Roles, should be possible to use the workflow state:

https://docs.plone.org/external/plone.app.dexterity/docs/behaviors/providing-marker-interfaces.html

To a more interesting example, here is a behavior from a project that lets content authors with particular permissions (iz.EditOfficialReviewers and iz.EditUnofficialReviewers), nominate the “official” and any “unofficial” reviewers for a given content item.

So conditions should be "inside" the behaviour (check for the workflow state, read/write permission on fields), not outside ( the behaviour cannot be applied on the context, interfaces are applied by the framework automatically on every object with the behaviour).

2 Likes

That's a very good point, Yuri. This is the same example I had been looking
at, but I got distracted by the marker interfaces. Thank you.
~ Ian

Ian F. Hood
Offices: 1 (360) 450-5900 (US)
Twitter, Skype, FB & LinkedIn as: IanFHood
Google+ 103220441876580461422