Workflow driven framework
Having a workflow driven framework brings us lots of benefits regarding the following :
1. More flexible and powerful security policy.
2. Consistent model dealing with content types and placefulness and thus easier configuration.
3. More powerful way of controling the policy on content object actions and attributes through
the workflow (i.e : edit for instance)
4. Dynamic local roles distribution with the use of participants instead of the linear default one. (i..e : stacks within CPSWorkfow)
Using a factory
What we thought about is a process content object factory replacing the standard Zope3 factory you may use with your content objects. (i.e : zcml directive) which can basically launch a document creation process while asking for the creation of a given content object. Like this we can control basically all the objects after their creations.
The idea is to register a callable for a given content type and this callable will request a process utility that will launch a process and then ask the process to create the object. (we will see later on how the association will be made to select the process).
Or using a subscriber
An alternative to the registred factory creating the content objects with associated processes, that we described above, is to use a subscriber reacting on the ICreatedObject event and then checking the mappings content object on process definition type. (we will go in details on this a little bit later in this document). If the content object is within the mapping then fine we create the process associated.
Pros and cons
The factory option is interesting because the creation itself can be done within the process scope but the cons are the fact that we need to write a dedicated factory.
On the other hand, the subcriber option is pretty easy and is defined as a hook called after the content creation but can’t control the creation itself.
Workflow security policy layer and specific checkers
The ecmworkflow will add a security policy layer to the default Zope3 security policy.
One the one hand we could define suscribers reacting on transitions that could change the
permission maps on the objects themselves according to some configuration mappings defined on the process instance as it was the case with DCWorkflow, but on the other hand we have Zope3 and a much more powerful security framework that can allow us to interact at much more lower level without touching the object itself at transition time and by simply using the pluggable possibilities of the Zope3 security policy.
Basically, we will need to register our new security policy and then when an object will be hooked on a process then put a process checker as default checker on the object. The checker will ask the process first about the roles / permissions maps and eventually request the old checkers.