[Zope-PTK] CMF Workflow Request Tickets

Tres Seaver tseaver@digicool.com
Sat, 17 Mar 2001 00:06:41 -0500


Kent Polk wrote:
> 
> Is anyone working on a request ticket object for CMF?

Ken Mannheimer is actively slavering for the opportunity
to refactor his Tracker as a set of CMF content objects and
workflow policies.

> I am looking at developing one and I need it to tie into other CMF
> workflow objects.
> 
> Basically, I am trying to develop a workflow system that is
> request->accept based,  where a request ticket can be issued to
> one or a group of individuals, who can then accept the ticket.
> Accepting it creates another workflow object which is owned by the
> acceptor. The acceptor workflow objects can be existing CMF objects
> for all I care :^) and would be tracked separately by the object's
> metadata via a workflow object status viewer.

CMF currently models workflow as a set of states, which form the
lifecycle of a content object;  an alternate implementation, which
moves the workflow state out of the content object altogether, is
possible (e.g., we anticipated that some users might wish to store
worflow history in SQL tables).
 
> This gets us back to heirachical objects - containerable object,
> somewhat as with discussions:
> 
> http://cmf.zope.org/Members/jens/howto/discussion_upgrade/view
> 
>   A new object of class DiscussionItemContainer will be "injected"
>   into a content item once people start "replying" to it and creating
>   discussion items. This object will store all replies and implement
>   the interface formerly provided by the Discussable base class.
>   This also means that content items no longer subclass from
>   Discussable.
> 
> Back to request tickets, As far as I can tell, a request ticket
> system can probably exist as just another class of CMF objects,
> with a base object just supporting a textual request.

If you don't need e-mail notification, you could do this with
existing CMF stuff, with no "real" programming involved.  The steps
would be, loosely:

 1. Define a new type object, 'RequestTicket', based off of
    CMFDefault.Document.  You could either make it a factory-based
    type object (easier, but less flexible) or a script-based one
    (which would let you add initial content on creation, for
    instance).

 2. Add additional skin methods for your new type to the site;
    wire them up to the actions tab of the type object.

 3. Subclass or reimplement the WorkflowTool, and implement the
    states you think are important for your request tickets.

 4. Replace the existing workflow tool with an instance of your
    new class.

 5. Begin adding and accepting tickets.

Except for #3, this can all be done through-the-web;  we don't
(yet) have TTW-configurable workflow.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver@digicool.com
Digital Creations     "Zope Dealers"       http://www.zope.org