[Zope-PTK] CMF Workflow Request Tickets

[Kent Polk]

On 18 Mar 2001 23:45:01 -0600, Ken Manheimer wrote:
>> Tres Seaver wrote:
>> > 
>> > Ken Mannheimer is actively slavering for the opportunity
>> > to refactor his Tracker as a set of CMF content objects and
>> > workflow policies.
>
>It looks like this is a real possibility.  I'll have to wait to get to it
>after some DC consulting obligations - probly not before late april.  I'm
>thinking i'm going to need the event channel (
>http://cmf.zope.org/rqmts/proposals/events_tool ) and some basic
>OrganizationObject ( http://cmf.zope.org/Members/klm/OrganizationObjects )
>services.  Then we'll be able to tailor content documents collections as
>entities with behavior.  Better yet - as objects with *attitude* :-)

That's all I need - objects with an attitude :^)

Ken, would you consider pointing out areas of interest that Michael
and I could start working on, and possibly provide feedback as we
go? Let us help give you a headstart?

Yes, I'm still having trouble grokking the CMF 'True Path' to
implementing CMF objects, but maybe if you could diagram how you
think you might implement this, we could start, and not be too far
off from where you intended to go.

One question I'm struggling with is how to tie requests (request
tickets) with the creation of a response or acceptance object.

 Jimbo:
 Request
   Recipient : Fred
   meta_type = 'Chapter Request Item'
   Text      : Please create Chapter 3 - "Object Posture"
   Parent Id : (wouldn't be required if workflow objects were
               folderish...)
     -> discussion reference : Do you mean 'Object Posturing'?)

Each Request Meta Type could have it's own view method. For a
Chapter Request Item, the view method could expose the discussion
object as well as wrap the acceptance/creation method for Chapter
3, thereby controlling the environment in which Chapter 3 is created.

 Fred:
   (Parent ? / context?)
   meta_type = 'SubDocument'
   construct : (use meta_type constructor)

Again, if workflow objects are folderish, they could simply acquire
parental information. However, this presents a potential ownership
problem, which I think could be dealt with by exposing the objects
via a search method instead of just following the object folders.
Where would the root objects exist - in the folder of the person
who created the root workflow object, or a separate group repository?

Or would it be better to use the current user folder to store
objects which users create and link them to their parent object -
sounds nasty and not at all Zopish.

-----

I will say that one thing I really appreciate about the CMF is the
clear comprehension of the power of "Everything is a query". If we
simply continue to build support for cataloging meta-data adequately,
"Everything is a query" has a chance to actually work here.