A better CMFworkflow (was: Re: [Zope-CMF] Re: Our CMF-CMS Demo .. needs a workflow)

[Ulrich Eck]

Hi seb,

I have talked a lot with kent polk about a better workflow for Zope/CMF.

A Content Management System as well as any other larger CMF-Site
will benefit from a better workflow.

>
> > - workflow with more than one object
>
> I presume you mean, for example, the ability to publish a group of
> items at the same time.  Can you give an example of when you might
> need to do this?  I'm thinking there are various scenarios where it's
> desirable, and they might have different possible solutions.
>


we have collected a few scenarios:

Workflow example 1
---------------------

Simple CRM Task/Document Workflow for an Customer Service:

1. Office Worker gets a supportcall from some customer and registers this in
the SupportTask List
2. OW needs to collect some support information and finds out who can handle
this support call
3. OW redirects/delegates the SupportTask to an Engineer
4. Engineer calls back the customer and hopefully finishes the SupportTask
otherwise it could be delegated to another person
4.a. if the problem could not be solved via hotline .. a Service-Task is
created
and there is a new workflow


Workflow example 2
---------------------

Kent's workflow example for laboratory-staff

- Create Project
  (P.I. creates/manages)

  - Create Pedigree Set (fill out data to be stored in sql table)
    (R.I. creates/manages)

    - Create MasterRack (fill out tabular data, etc)
      (head project genotyper creates/manages)

      - Create Panels (n number of panels)
        (genotyper pool personnel creates/manages)

        - Create n number of samplesheets for each panel
          (genotyper pool personnel creates/manages)

        - process each samplesheet

      - build processed Panels
        (genotyper pool personnel)

      - submit for approval to genotyping database
        (genotyper pool personnel/ lab manger approves)

The nested heirarchy of the project items needs to be maintained.

Workflow example 3
---------------------

One could use such a workflow for applications as well, here an
example for my ongoing network-documentation-project:

Aim:  employees of an university that do inventory of network-hardware and
manages lines, rack-space, etc.

Workflow:
Register a new Component into a existing Subnet:

1. User creates Component

2. User selects Manufacturer/Model, if not existant:
                    allow to create both within workflow

3. User must add at least one physical port to that device
(or more e.g. a switch)

4. User must define at least one logical port for each physical port
    (an ip-address)
    this logical port must match the subnet it is in
    (otherwise let the user create a new subnet)

5. After all he needs to define where the component will be
    installed an who's responsible for it
    and again be able to create all that doesn't exist.

Within this workflow there can start new workflow parts (e.g. when adding a
Subnet, you need a line for that, which is usualy leased from a ISP,
so that needs to be handled when user creates a new subnet)
In such a workflow there could be several people/roles involved.


All these scenarios need a workflow that need more than one object involved.
Object Relations ( defined in meta_data and OrganisationObjects ) would
make things easier.


> > - higher-level publish/review workflow with several People involved
>
> Do you mean some kind of routing / ticketing mechanism?
> e.g. Fred approves It, then it goes to Lisa to be approved, then
> Denise can edit it, then Fred publishes it.
>
yepp

> > - workflow needed for group-ware functionality
>
> Not sure what you mean here.  There have been discussions elsewhere
> about using workflows with local roles to manage groups, did you read
> them?
>
see examples

> > I think about to implement an optional replacement for portal_workflow.
>
> I don't think the correct implentation would put all this
> functionality in a workflow tool: much of it could be accomplished by
> incorporating new tools / structures into the existing workflow
> framework, or even writing a new Workflow (not a new WorkflowTool).
>

I have looked at the code and the basic functionality of the CMFWorkflow.

There is a thight binding of Portal-Type <-> Workflow which does not
represent
real-live-workflows (an object of a certain type is probably member of
serveral
different workflows in his lifetime or at the same time if possible ..)

The mapping portal_type -> workflow is made by the workflow tool ..
This won't work if an object could participate in more than one workflow ..

And there comes the next point .. I not the object type defines the workflow
..
it probably should be defined by a template that is repuested and filled out
with the actual values of the participating objects and workflow-session has
begun ..
now there are several objects in several states with several possible
transistions
and participating users/roles.

I know .. this is a real workflow-engine .. but that's probably the tool
that I (we)
would like to have :-)

what do you think about that??

Ulrich Eck
net-labs