collective-cmfopenflow Mailing List for The Plone Collective

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

>
>in  "Auto push application" section.
>If you tie an activity with an "auto push application" the workflow engine
>call it with the correct parameter (included workitem id) when it forward a
>workitem to the another one. This is the rigth way to assign a workitem, the
>other one is to do it ttw with the worklist action 'push'.

Thanks that worked. What I had tried to do was this

I created a script which tried to assign it like this.

oftool = container.portal_openflow

instance=oftool[instance_id]
workitem = getattr(getattr(oftool, instance_id),workitem_id)
username = instance.getProperty('DriverName')
oftool.assignWorkitem(instance_id, workitem_id, username)
oftool.activateWorkitem(instance_id,workitem_id, username)


For some reason this did not work. I modified the script to return the 
username and assigned it to the push and it did work.


:wq
Tim Uckun
US Investigations Services/Due Diligence
  http://www.diligence.com/

Alle 01:14, sabato 3 gennaio 2004, hai scritto:
> >1 - extract from the workflow Instance the workitem related to task
> >(activity)
> >using the activity id attribute (or you can query the catalog with
> >appropriate index: meta_type=3D'Workitem', instance_id, process_id,
> >acitivity_id) and so call the push method. This work only if you have =
one
> >workitem for one activity.
>
> I don't think I can be guaranteed that there is only workitem can I?
>

The model of workflow must not have loop.

> >2 - Create a 'push' application (see dev manual: www.reflab.it/communi=
ty).
> >Store the user in a property, and use the 'push' app to assign the
> > workitem.
>
> I create the instance like this.
> oftool =3D container.portal_openflow
>
> instance_id =3D oftool.addInstance(process_id=3D container.pd_name ,
>                                   customer=3Duser,
>                                   comments=3D"New Driver",
>                                   title=3D"",
>                                   activation=3D0)
>
> How do I get the workitem ID so I can push it? Or maybe you are saying =
I
> don't need the workitem ID if I store the user as a property of the
> workflow... Is that right?
>
> :wq

Refer to=20
www.reflab.it/community/Openprojects/CMFOpenflow/Reflow.docs/Reflow_Manua=
l/Reflow_manual/view
in  "Auto push application" section.
If you tie an activity with an "auto push application" the workflow engin=
e=20
call it with the correct parameter (included workitem id) when it forward=
 a=20
workitem to the another one. This is the rigth way to assign a workitem, =
the=20
other one is to do it ttw with the worklist action 'push'.
--=20

                                               Riccardo Lemmi

>
>1 - extract from the workflow Instance the workitem related to task 
>(activity)
>using the activity id attribute (or you can query the catalog with
>appropriate index: meta_type='Workitem', instance_id, process_id,
>acitivity_id) and so call the push method. This work only if you have one
>workitem for one activity.

I don't think I can be guaranteed that there is only workitem can I?

>2 - Create a 'push' application (see dev manual: www.reflab.it/community).
>Store the user in a property, and use the 'push' app to assign the workitem.

I create the instance like this.
oftool = container.portal_openflow

instance_id = oftool.addInstance(process_id= container.pd_name ,
                                  customer=user,
                                  comments="New Driver",
                                  title="",
                                  activation=0)

How do I get the workitem ID so I can push it? Or maybe you are saying I 
don't need the workitem ID if I store the user as a property of the 
workflow... Is that right?



:wq
Tim Uckun
US Investigations Services/Due Diligence
  http://www.diligence.com/

Alle 08:40, venerd=EC 2 gennaio 2004, tim ha scritto:
> Hello all.
>
> I have been trying to implement a very simple workflow for demonstratio=
n
> purposes. What I want to do is the following.
>
> 1) USer A fill out a form and enters information about user B.
> 2) The application then creates user B in zope, assigns the user to the
> porper group, initiates a workflow and then asigns the task to user B.
>
> I have created a application using the ticket tracking example and can
> initiate a workflow but I don't know how to get the workitem_id so I ca=
n
> assign it to the user.
>
> Can anybody help me.
>
>

Hi,
there are at least 2 way to do it:

1 - extract from the workflow Instance the workitem related to task (acti=
vity)=20
using the activity id attribute (or you can query the catalog with=20
appropriate index: meta_type=3D'Workitem', instance_id, process_id,=20
acitivity_id) and so call the push method. This work only if you have 
workitem for one activity.=20

2 - Create a 'push' application (see dev manual: www.reflab.it/community)=
=2E=20
Store the user in a property, and use the 'push' app to assign the workit=
em.

--=20

                                               Riccardo Lemmi

Hello all.

I have been trying to implement a very simple workflow for demonstration 
purposes. What I want to do is the following.

1) USer A fill out a form and enters information about user B.
2) The application then creates user B in zope, assigns the user to the 
porper group, initiates a workflow and then asigns the task to user B.

I have created a application using the ticket tracking example and can 
initiate a workflow but I don't know how to get the workitem_id so I can 
assign it to the user.

Can anybody help me.

2 test
--=20

                                               Riccardo Lemmi

test
--=20

                                               Riccardo Lemmi

On Tuesday 29 April 2003 01:20, you wrote:
> Hi,
>
> I'm trying to use Reflow for a workflow that has many different activit=
ies,
> each with one or more UI forms. Based on my limited understanding of Pl=
one,
> it seems like it would make sense to use the portal_form tool to help
> handle the forms. I'm wondering why portal_form wasn't used in the Refl=
ow
> example product? Or do you have plans to somehow integrate Reflow with
> Formulator, in order to help automate form creation and validation? Tha=
nks.

Hi! you are right, it does make sense to use portal form. Unfortunately i=
t is=20
still faster to not use it if you have "very custom" forms i.e. reuse of =
the=20
validation, etc. does'nt worth it.

As you can see the Reflow demos are rought from the UI point of view :-(
and it would be better to use both portal_form and plone-like forms (with=
 no=20
tables, with i18n tags, etc.) of course.

Right now we are moving to deeper interaction/interation between DCworkfl=
ow=20
(portal_workflow) and Reflow and between Reflow and contents (portal=20
documents, files, etc.).

IMHO Reflow can be used well with Formulator without any integration; =20
Riccardo developped a very large application with a lot of activities and=
=20
forms with Formulator, you can ask him for details if you need to develop=
=20
something similar.=20

What we are trying to understand now is the opportunity of storing workfl=
ow=20
relevant data (generally stored in the wf Instances or DB) into CMF/plone=
=20
contents.

A Reflab customer will probably sponsor this. We think it's a very very=20
interesting possible evolution of Reflow! :)
=20
cheers,
francesco.

> Michael

CMFTask is a simple task manager for Plone that uses CMFOpenflow. It has =
been
developed during the Plone sprint in bern and it is now available on
www.reflab.it/demo/PloneTaskManager

Anyone interested in some testing? :-)

10x ,
francesco

=2E.....................................................
Francesco Ciriaci @ Reflab
Cell. (+39) 333 4284675
http://www.reflab.it

Hi sorry for the big delay.

Adrian van den Dries wrote:

>Hi there!  Hope you're enjoying Switzerland... ;-)
>
>I have some questions and ideas for CMFOpenreFlowTool or whatever it's
>called these days. ;-)
>
>What is the containment hierarchy?
>
> - WorkflowEngine
>   - Process
>     - Activity
>     - Transition
>   - Instance
>     - Workitem
>
>i.e. Activities and Transitions belong to one and only one Process,
>and Workitems belong to one and only one Instance, which in turn
>refers to a Process (or Processes?).
>
>If this is true, should we have separate containers for Instances and
>Processes?
>
>What happens to completed Instances?  Do they just hang around until
>some poor schmuck manager decides to delete them?  Perhaps it is
>better to partition the instances into active and completed
>collections (folders for now).  Then we can archive the completed
>instances for reporting purposes without them affecting the
>performance of the engine for active instances.
>  
>
Yes, we should think about that, it seems to be a really nice scenario, 
but it will have a big impact on the system and I don`t know how we can 
handle backward-compatiblitiy.

>I am not very familiar with the operations of the ZCatalog, but it
>seems to me to be overkill for what you need.  If we partition the
>object types into their own container and access them by id (this
>seems to be the most common operation on the ZCatalog), would that
>render the ZCatalog redundant?  I expect so.
>  
>
Using the catalog simplify a lot the creation of UI for your workflow 
apps, you often don`t need to access a specific instance but have to 
deal with instances and workitems that matches some paramenters and the 
catalog helps a lot in that.

>There seem to be many methods that accept more than one id argument,
>which seems to me to be redundant also.  If the object are organised
>into the above scheme and carry references to the objects they are
>really related to, then we can drastically simplify the API by only
>having to pass the relevant id.  Does this make sense?
>  
>
Yes this is absolutely true but the impact of the changes you propose 
can quite big, we have to evaluate that with care.

>If the workflow engine itself does not depend on the CMF (I would
>expect not) then can we have a non-CMF class (WorkflowEngine) that can
>be used outside of the CMF, and then subclass it (CMFWorkflowTool)
>that uses the CMF mixins?  I am not very familiar with the CMF, but
>this seems to be a more flexible way of doing things.
>
>And while we have the freedom to change names etc. please, please,
>*please* can we rename the classes and modules? ;-)
>
>  WorkflowEngine
>  CMFWorkflowTool
>  Activity
>  etc.
>  
>
Yes we have to do that !! :)

>and then I would be extremely happy!  Perhaps if you need to support
>the old lowercase names we can have backward-compatible modules.  I
>have made the changes to the class names and they seem to work... I
>just need to create a compat package to keep the modules out of the
>way of each other (because they would just differ in case - and
>Windows doesn't like that!)
>  
>
We can support backward-compatibility in the python modules I think, 
IMOit will be easyer than use other modules.

>Do people like interfaces?
>
What do you mean ?

Thank you very much for the interest and the suggestions,
    Vincenzo.

Hi there!  Hope you're enjoying Switzerland... ;-)

I have some questions and ideas for CMFOpenreFlowTool or whatever it's
called these days. ;-)

What is the containment hierarchy?

 - WorkflowEngine
   - Process
     - Activity
     - Transition
   - Instance
     - Workitem

i.e. Activities and Transitions belong to one and only one Process,
and Workitems belong to one and only one Instance, which in turn
refers to a Process (or Processes?).

If this is true, should we have separate containers for Instances and
Processes?

What happens to completed Instances?  Do they just hang around until
some poor schmuck manager decides to delete them?  Perhaps it is
better to partition the instances into active and completed
collections (folders for now).  Then we can archive the completed
instances for reporting purposes without them affecting the
performance of the engine for active instances.

I am not very familiar with the operations of the ZCatalog, but it
seems to me to be overkill for what you need.  If we partition the
object types into their own container and access them by id (this
seems to be the most common operation on the ZCatalog), would that
render the ZCatalog redundant?  I expect so.

There seem to be many methods that accept more than one id argument,
which seems to me to be redundant also.  If the object are organised
into the above scheme and carry references to the objects they are
really related to, then we can drastically simplify the API by only
having to pass the relevant id.  Does this make sense?

If the workflow engine itself does not depend on the CMF (I would
expect not) then can we have a non-CMF class (WorkflowEngine) that can
be used outside of the CMF, and then subclass it (CMFWorkflowTool)
that uses the CMF mixins?  I am not very familiar with the CMF, but
this seems to be a more flexible way of doing things.

And while we have the freedom to change names etc. please, please,
*please* can we rename the classes and modules? ;-)

  WorkflowEngine
  CMFWorkflowTool
  Activity
  etc.

and then I would be extremely happy!  Perhaps if you need to support
the old lowercase names we can have backward-compatible modules.  I
have made the changes to the class names and they seem to work... I
just need to create a compat package to keep the modules out of the
way of each other (because they would just differ in case - and
Windows doesn't like that!)

Do people like interfaces?

I will be on IRC today (tonight Sydney time) if you would like to
discuss these issues further.

a.

-- 
 Adrian van den Dries                           ad...@fl...
 Development team                               www.dev.flow.com.au
 FLOW Communications Pty. Ltd.                  www.flow.com.au

Hello.

Is this the place to send patches?

Attached is a patch to remove Applications from the ZMI.  There is no
need for the engine to maintain an application registry: it just
complicates things.

It looks like there is a problem with callAutoPush: it calls
getApplicationUrl with the wrong parameters.

a.

-- 
 Adrian van den Dries                           ad...@fl...
 Development team                               www.dev.flow.com.au
 FLOW Communications Pty. Ltd.                  www.flow.com.au