[Zope-PTK] the workflow in the sample "Portal (new)"

Shane Hathaway shane@digicool.com
Tue, 27 Feb 2001 10:26:45 -0500


Michael McLay wrote:
> The list may be missing a few key items.  Here are some additional thoughts
> for your consideration.

Thank you for your feedback.  It's readily apparent that the community
has a lot of knowledge on the subject of workflow.  It's really helpful.

> The web portal work flow is a nice demonstration case for workflows but it is
> only a minor side show in the workflow problem domain.  Governments and
> businesses spend huge amounts of money on managing the status of documents
> (and information in genreral) flowing through the organization.  A delay in
> the workflow can have a significant impact on productivity and
> time-to-market.  A couple new bullets for your list show up when some
> examples that are typical of financial and engineering workflows are examined.

I agree that the web portal workflow is really a very simplistic case. 
That's why in the new architecture, the simple portal workflow has been
refactored into a single class.  There used to be bits of the simple
workflow strewn all about; now it's destined to become a simple
Zope-manageable object that can be configured or replaced.  You'll be
able to plug in different workflows.

I can't claim, of course, that the first revision of the new
architecture will give everyone what they want, and there will likely be
significant revisions.  But it will give people an idea of how to make
pluggable workflow happen in Zope.  It will also educate us on the
subject of workflow in general.

> A digital signiture will be required in virtually any workflow signoff cycle.
> For instance, if a travel report with an associated expense report the travel
> report is traveling through a workflow it has to be initialed by my
> supervisor, but the expense report needs to be signed by me and my
> supervisor, and then initialed by their supervisor and then reviewed and
> stamped by someone in our laboratory's budgeting office and then finally
> approved and entered by someone in accounting.

The second bullet is intended to address precisely that.  Repeating:

> >       - Users' rights to manipulate an object should depend not only on
> >         the set of roles and permissions granted to them, but also
> >         on the workflow status of the object.

As each person in the organization signs off, the workflow status of the
expense report changes in some way.  The workflow has the ability to
dictate that accounting doesn't see and interact with the expense report
until the proper signatures are in place.  Zope security settings are
manipulated according to workflow status.

> In a typical engineering environment a design will advance from a preliminary
> design on through various levels of completion.  At each stage in the process
> details become locked and making changes require higher levels of signiture
> authority.  The Zope CMF could be used for tracking the state of the objects
> in this environment, if it was possible to add multiple dated signitures to
> specific objects.  With each signiture the state of some objects within the
> "document" would be changed.  For instance, when a parts manager signed off
> on a circuit design the devices in the circuit would no longer be editable by
> the engineers without reapproval by the parts manager.

I'd like to continue this discussion once I've been able to release the
new architecture.  I'll be able to use more specific examples to
demonstrate that we are striving to address these needs.

> My organization has a project underway to develop a digital signiture
> process.  The workflow user interface that was developed was for the pilot
> project was awkward and slow to use compared to signing a paper form.
> Modifying the flow of the document through the process was also difficult to
> manage.  You touched on this issue in bullet three above.  Getting the UI to
> work efficiently is key to success in this process.

Certainly.  In fact, I think I did not fully address the UI
considerations in the bullets.  The workflow must be able to provide a
UI that weaves seamlessly with the object views.  Currently the only way
the workflow can directly influence the UI is by providing actions to
the "actions box".  This policy may evolve.

Shane