Tags:
workflow2Add my vote for this tag create new tag
, view all tags
Just an idea ...

For the moment I assume that WorkFlow means that we would like that some work flows through a series of steps, performed by different users with different privileges (see UserAuthorizationSchemes).

I think that this would be easily obtained with a simple addition to the current system. If you notice, whenever for a topic a category is chosen, the topic is not automatically added to the category topic.

If, instead, the selection of a category for a topic would add the page to the category page, we would have a very simple kind of workflow.

By restricting the access to the category page with the <Location> directive we would enforce a loose access control ("loose" because people can use other ways to find a page).

To be able to specify a strict access control, the category assignment step should also move the page under a different directory (a different Wikiweb ). This way we would also gain the fact that at different WorkFlow steps we can associate different category tables.

PS. what if the wikiweb has a structure with more than 2 levels? Suppose we have TWiki.Codev.WorkFlow.Step1, TWiki.Codev.WorkFlow.Step2 and so on ...

-- AndreaSterbini - 08 Oct 1999

I have just tried in my home TWiki installation to create subdirectories inside a TWiki web ... it works!!! for any depth!!!

Suppose you create the directories Codev/WorkFlow/Step1 and Codev/WorkFlow/Step2, you can view/create topics in each one. E.g. you can create Codev/WorkFlow/Step1/DocumentOne.

To look for changes in that web you add a slash at the end, e.g. ...changes/Codev/WorkFlow/Step1/

We just need a way to refer to topics in lower levels ... what if we just allow dotted lists as Codev.WorkFlow.Step1.DocumentOne ?

[ _follows in MultiLevelWikiWebs _ ]

-- AndreaSterbini - 15 Oct 1999

We could simplify the above idea removing the topic "movement" step, at the price of some more coding (just a little, the category system is already there):

  • define each step in a workflow process as a category,
  • the category menu will depend on the step reached (i.e. it shows only the allowed "next steps")
  • check for user authorization on edit, based on the current topic workflow category

This way:

  • RCS keeps a clean story of the topic flow
  • it is independent on the structure of the webs

-- AndreaSterbini - 17 Aug 2000

I like the idea of using the category system for a workflow system. How about not showing only next steps allowed, but showing all steps? When a person edits a topic, the system could change the category item to the next logical step, but the user could set it to some other step in case needed.

Many times a workflow is not composed of linear steps, it is rather a flowchart. Something like this for example:

  1. Create an expense report form using a template.
  2. Fill out the form.
  3. Forward form to manager.
    • If manager is out of the office it can be sent to another manager.
  4. Manager does:
    • Approve the expense report, or
    • Reject the expense report, thus sends it back to the start.
  5. If approved, send form to accounting.
  6. Accounting does:
    • Approve the expense report, or
    • Reject the expense report.
  7. If approved:
    • Pay employee.
    • Close expense report form.
  8. If rejected:
    • Send it back to the employee.

Each step can be represented by an item in the category table. Sample workflow steps: WorkFlowSteps : StepInit , StepManagerApproved , StepManagerRejected , StepAccountingApproved , StepAccountingRejected , StepEnd .

Open questions:

  • How to define a specific workflow
  • How to guide users through the defined workflow.
  • How to create a workflow form from a template. The system probably should generate a topic name automatically, i.e. ExpenseReport00001 , ExpenseReport00002 .
  • How to inform the person about workflow forms that are waiting to be processed.
  • Useful to have some database connectivity? At the end of a workflow form it could make sense to store some data in a database, i.e. insert the expense report into the accounting system.

-- PeterThoeny - 17 Aug 2000

If the category table depends on the current category and shows all the categories reachable from the current one, then we can design any workflow graph. To make the category table depend on the current category we could change the file names (e.g. the category table files could be named twikicatitems.item1.tmpl, twikicatitems.item2.tmpl)

In each file we show the following logical steps AND the needed backup steps. We, instead, don't show the steps the user is not allowed to take. (anyway ... we are completely free to design a workflow without constraints or a workflow that show only the true path to enlightenment smile )

-- AndreaSterbini - 19 Aug 2000

Let me think to some of the open questions:

First let assume the workflow is implemented with multiple webs (with movement of topics from web to web):

  • How to define a specific workflow
    • We need a ScriptToCreateNewWebs
    • We could define a variable (e.g. %WORKFLOWNEXT%) to define the steps of the workflow and use it in the templates to show a proper menu.
  • How to guide users through the defined workflow.
    • The templates of each single web could INCLUDE (or just link to) a small topic that explains the steps that follows/precede.
    • The %WORKFLOWNEXT% variable shows ONLY the steps allowed
  • How to create a workflow form from a template. The system probably should generate a topic name automatically, i.e. ExpenseReport00001 , ExpenseReport00002 .
    • Is'nt the creation of templated topics already a feature of TWiki?
    • We could add a %LASTTOPICNUM% variable and use it in the template to make the new topic name.
  • How to inform the person about workflow forms that are waiting to be processed.
    • By web: just look at the WebChanges page of the subweb
    • By mail: subscribe to the WebNotify page of it
  • Useful to have some database connectivity? At the end of a workflow form it could make sense to store some data in a database, i.e. insert the expense report into the accounting system.
    • Last step can be a template that contains a form and a button to insert the topic in the database ....

Now let assume the workflow is implemented with categories :

  • How to define a specific workflow
    • We need a category editor to handle the category structure (we can either use multiple category item files or augment the syntax)
  • How to guide users through the defined workflow.
    • the category menu should show ONLY information on the steps that follows/precede.
  • How to inform the person about workflow forms that are waiting to be processed.

-- AndreaSterbini - 25 Aug 2000

You might also like to consider:

  • Some workflows have parallel tasks for the single job. I mean not a step 1 -> step 2 -> step 3 workflow as above but more of a branching one where you have a single job, say something to be approved, it moves to step 1 then it could be broken up into tasks that must run in parallel by different actors say step 1a, 1b and 1c. All steps must be completed before moving onto step 2. How should parallel tasks be handled?
    • Perhaps a job should not be only one page. How about one page for the job as a coversheet and then one for eash task in the workflow? The coversheet might show the next stage as links ready to be created, the actor clicks the "?" and composes the task document. The completed workflow's coversheet shows all the links to the tasks, the incomplete workflow's coversheet shows some links and some not yet composed.

  • Workflows can have one actor who's role is that of an overseer for the whole process and as such s/he assigns the steps to different actors. How should task assignment be handled?
    • The overseer could compose the task pages and make sure only the authorised users can edit those pages.. a way of assigning (those users would need to be notified of course)

  • If some steps require approval how does the approval get authenticated?
    • Is there a case for TwikiPageSigning ? By this I mean like PGP signing. If one of the task pages above was an approval ,the authorised user could compose the approval page and then sign it. Any further modification to the page would destroy the signature of course.

What do you think?

-- AndrewTetlaw - 10 Nov 2001

How about we look for an existing perl Workflow package and integrate that? Otherwise it is yet more for us to maintain.

-- MartinCleaver - 12 Nov 2001

I have reviewed the topic of workflow at length, and have read the standards forwarded by the Workflow Management Coalition. Despite my familiarity with their standards, I don't think it is wise to attempt to support their standards at this point in the development of TWiki, as their standards are mostly for the interaction of differing workflow management systems. Also, the concept of workflow, as implied by the discussion above, is somewhat more simplistic than the top-heavy results of those standards bodies.

Instead, I would like to suggest that the following building blocks would provide a sufficient infrastructure to handle most dialog-based workflow. We need a means to:

  1. allow entry through forms that will validate the data to various standard data types, require that some fields are completed. See ImprovedDatatypesInForms for some similar discussion about data types.
  2. allow custom and arbitrary data validation. Many times, the data in a form will have complex data validation requirements such as "require the zip code if the country is US or CA, otherwise make it optional".
  3. return to the same form and complain when data is not entered properly.
  4. update data somewhere other than the current topic such that state can be maintained for a given session. This could be in some other topic file, but such files would probably not need to be searchable, and may need to be completely hidden. A database is a common way to handle this, but there are many other approaches, and the CGI::Session facility may be a good approach to maintain the session data. Still, we need to be able to modify some other files other than the current topic, as the current topic must be reused for multiple uses. TopicObjectModel style variable manipulation may be sufficient.
  5. Perform arbitrary processing of the data. I think some additional security would be required if topics have arbitrary processing capability, such as to evaluate arbitrary perl expressions. Yet, this is an easy way to provide a ton of functionality without having to define very much. For example, if the Directive %EVAL{ arbitrary Perl expression }% were supported, then this may be enough to facilitate most processing. However, you can't provide this function to just anyone as it is a blank check for hacking.
  6. Facilitate the question "what next" when the form is completed. It must be possible to branch to various other dialogs based on the results of validation of the current dialog, including which button is pressed.

I have implemented a dialog system such as this in the past using Perl and I think that it may be fairly easy to "port" it to TWiki if we decide such an approach is a good idea.

-- RaymondLutz - 02 Dec 2003

Please see that WorkFlowAddOn as an example of a work flow imposed by associating a sequence of form (a possibly different form for each step of the work flow) with a topic.

The WorkFlowAddOn just manages the work flow on a single topic. The creation of an item to be sent through the work flow is considered a separate issue (albeit PeterThoeny above described that as part of the work flow). In WorkFlowAddOn you associate a work flow with a topic (by using the "Add Form" button, from then on the "Change Form" button is replaced by the ability to move the topic to the next step in the work flow. The work flow is represented by a state machine captured in a table topic. This state machine relates the current step in the work flow with action that could be taken and the resulting next step in the work flow (if any). It also allows to control who is able to perform a given action (users not able to perform an action are not given that option).

-- ThomasWeigert - 01 Aug 2004

Thomas - I know it took you a while to update this for Beijing and now the code base has left your undoubtedly-good yet unfortunately-rotting patch again, but could you possibly update it for Cairo? Given that Walter has said on PostCairoDevelopmentModel that he is happy to host it in parallel to the Dakar maintainence tree on the Subversion tree the finalisation of the development branch is surely Peter's top priority now. I'm holding my breath on this one: Its great to at last see some sparkle, life and excitement in TWiki's development again.

I'd love to see WorkFlow as a system in the core: I need something to orchestrate the pathways through my RegisterCgiScriptRewrite.

-- MartinCleaver - 06 Oct 2004

Just FYI I am still on Athens in our own system... but I agree with you that I should go ahead an upgrade the WorkFlowAddOn to Cairo. Alas, an addon is so much harder to maintain, and this just isn't a plugin as the infrastructure is missing. My motivation level would be so much higher if there was an indication that this could go into TWiki proper...

I'll do my best to get to this soon...

-- ThomasWeigert - 07 Oct 2004

I understand the being-stuck-on-athens viewpoint. You might find using the TWikiReleaseTrackerPlugin useful: it will give you a summary of everything you've modified from the base installation, and then allow you to see for each file how that file changed in Beijing (not much!) and Cairo (quite a bit!).

I fully appreciate the motivation re: doing so much work to pull something forward only for it to not make a release. Without an indication from those in control its a jeopardy problem: do I risk doing the work? From their side its: can I make this fit cleanly? Do I understand this? The scenario only happens because the controls are placed too early. That's why the Development/Maintenance track is so crucial - it'll shift the responsibility back on the owning contributor bringing his/her intellectual property into TWiki to ensure that it fits. Only once the work is completed does it go into a review cycle.

In short, our best short-term effort would be to help Peter and Walter implement the branch mechanism. We also need for a PeterPleaseComment nod-in-the-general-direction of the WorkFlowAddOn: Peter must have some questions about both the idea and the structure of the integration.

-- MartinCleaver - 07 Oct 2004

Moved the WorkFlowAddOn to Cairo...

-- ThomasWeigert - 11 Mar 2005

I propose this is a feature needed as standard in Edinburgh.

-- MartinCleaver - 22 Oct 2005

IMO, it's better to implement Workflow capabilities in a plugin instead of adding more stuff to the core (I'm a micro-kernel fanatic). Actually, I would prefer to move several things (some not-so-used TWikiVariable support, Forms support, Attachment suppport, and some others) to plugins. I bet that with Dakar that can be done without affecting performance (and perhaps actually improving it).

Regarding Workflow support, with the recent enhancements in META handling and direct save in Dakar is pretty easy to do. I hacked very simple (And somehow crude) WorkflowPlugin for our intranet, and I'm attaching it to this topic. I don't want to release it "as is" to the Plugins web as I don't want to pollute the Plugins namespace with a half-backed solution (there are too many of those already). Everybody, feel free to use it and comment on it (and perhaps pick it up for development. My hands are too full ATM)

-- RafaelAlvarez - 23 Oct 2005

I agree it should not be in the core.

I believe it should be a contrib. In addition I think we need to look at the CPAN workflow module. My belief is that that project will attract enough eyeballs to produce something with enough well-rounded features for it to be considered complete.

-- MartinCleaver - 24 Oct 2005

hmm... if the CPAN module could be enhanced to retrieve the workflow from a topic in another format... hmm..

-- RafaelAlvarez - 24 Oct 2005

See http://www.cwinters.com/talks/workflow_pgh_pm.pdf - slide 37 - for programmatic access to workflows.

-- MartinCleaver - 21 Nov 2005

Consilient: Workflow Among Peers

-- WillNorris - 05 Mar 2006

Topic attachments
I Attachment History Action Size Date Who Comment
Compressed Zip archivezip WorkflowPlugin.zip r1 manage 5.6 K 2005-10-23 - 22:10 RafaelAlvarez A very simple and crude Plugin for workflow support
Edit | Attach | Watch | Print version | History: r26 < r25 < r24 < r23 < r22 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r26 - 2008-10-28 - JohnLundin
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.