[Zope-PTK] Member Publishing

[Kent Polk]

On 15 Dec 2000 10:20:00 -0600, Renato De Giovanni wrote:
>covered. Than state 3 above, could encapsulate another workflow - that would be an example
>of a sub-workflow. But, as Michael Bernstein pointed (and I agree with him), any possible
>sub-state-machine could emerge into its parent state-machine, so we could always represent
>any situation with only one workflow.
>
>And, yes, after all I must agree with Shane and all of you that the sub-workflow feature
>gives us more flexibility. It will require a high level of abstraction to implement it...
>state interface may provide a way to define one or more sub-workflows to itself and in
>which conditions each one should be used, states from sub-workflows may offer the
>possibility to select an "emerging" next state (from the parent workflow), and
>sub-workflows interface may somehow define which state should be used as a beginning state
>according to specific conditions... a lot more to think!

Maybe not all that complex if (as Michael mentions) you use acquisition.
Here's a little attempt.


Workflow ideas

- A workflow item is created by some request for action by an actor
  (requestor).   A list of requestees to act on the item would be
  specified. (option for one of the above our all of the above to
  take action could be specified?)

- A sub-workflow item is created as a workflow of some other request
  (workflow item). Otherwise it is likely identical to an initial
  workflow.

- A workflow item is seen via a status view of the portal and is
  viewable by the action requestor and requestee.

- Sub-workflows *may* have restricted (private) status components
  which are only viewable by the item requestor and the requestee.
  This is to keep pertinent information in proper context (privacy).

- Sub-workflow items would be children of their parents. I.e. a wf
  item would be folderish.

- Roles (state machines) could inherit from a base class and massage
  current state/transition.

- Items could be moved from one state machine to another and one
  state machine could handle multiple states that apply to a
  particular role. (How would items be associated with a particular
  state machine?)


Workflow Components:

---------------------------
Roles: (state machines)
 
 Base Class

  - 'Build' current item's state
         provide for human build process 
          or perform a programmed build

     list possible actions (transitions)
          or perform programmed action
...

---------------------------
Items:

 Attributes
 ----------
   id
   title
   owner (creator)
   current role (state machine)
   current actor
   ...

 Methods
 -------
   save data associated with item (document)
   retrieve data associated with item (document)

---------------------------
Portals: Workflow Item Publisher 
         Publishes an individual's view of workflow items

 View Status:

        item name   status                 actor
    [+] Obj 1       Received  12/15/2000    jfk 
    [+] Obj 2       Requested 12/14/2000    gwb
    [-] Obj 3       Received  12/14/2000
     [+] Obj 4      Completed 12/15/2000    ---  (limit sub-wf view)
     [+] Obj 5      Received  12/16/2000    ---
     [+] Obj 6      Rejected  12/15/2000    ---

 View Item :

   Select item name to interact with item
   (form to view/operate on workflow item)

 Create new Item:  available inside top-level objects and 
                   possibly at outer level if permission allows

A portal view of an item would basically map the Item and the
current State Machine on top of each other (merge polarized objects).