[Zope-PTK] Member Publishing

[Shane Hathaway]

Kent Polk wrote:
> >  - all protected actions on an object, including those that don't
> >change the object's workflow status, were protected by transitions
> >rather than permissions.  (Otherwise the number of necessary permissions
> >explodes quickly.)
> 
> Agreed, but could you please explain a bit more about 'transitions'
> in this context.

In a finite state machine there are fixed transitions entering and
leaving each state.  On a diagram, transitions are represented by the
arrows.  Some transitions move to another state while others stay in the
same state.

Currently the PTK restricts what you can do according to (1) user
permissions and (2) the list of available transitions filtered through
user permissions.  All of the actions in the first category are
operations within the current state.

However, what if you want to allow users in a given role to edit a
document when it's in the "new" state but not when it's in the
"submitted" state?  Either you need two permissions instead of one or
you need to be able to remap permissions according to the current
state.  This gets real hairy, real fast.

But there's another option: move all actions in the first category into
the second category.  In other words, make it so the "edit" action
corresponds to a transition that doesn't change the state.  This moves
the problem to the state machine setup and shields the designer from
having to create new Zope permissions.

> These items indicate precisely the sort of workflow that we are
> trying to design now, even down to the subworkflows. How do we sign
> up to help work on this?

It would be very helpful if someone could create UI mockups of a state
machine creation and editing interface.  We need to know whether state
machines of this kind are simple enough to express on web pages.  If
they are too complex, we can simply create an API and the state machine
would be generated by Python calls to the API.

Shane