[Phpgroupware-developers] Re: How to implement a workflow in phpGroupWare

[totschnig . michael]

Hello Ralf,

When thinking about your outline of how workflows could be implemented
in phpGroupWare, I got the impression that conceiving a workflow as a
separate app is only one part of the story. It would be equally
important to have a mechanism of hooking each step of a workflow into
objects and actions of other applications, so that it would be easy to
understand how the adding of a file in a specific filemanager
directory, relates to writing an email from a specific template to a
specific adress, adding entries or modifying data in other
applications. In other words, I am wondering, if it would be necessary
that applications are made "workflow enabled" with some system of hooks
that automatically articulates them in some way.
just a thought.
regards,
Michael

Ralf Becker <address@hidden> a écrit:

> 3. How to implement a WorkFlow system in phpGroupWare
>
> The first thought might be thats a taff task and LotusNotes? is very much 
> advanced from
> phpGroupWare and the other OSGroupWare projects.
>>
>> I (ralfbecker) see a change to implement a system like that in a 
>> overviewable range of time
> within phpGroupWare:
>>
>>
>
>    1.  WorkFlow's in phpGroupWare have to be own apps and db-tables, 
> generated automaticaly by
>      the WorkFlow app. In the first step u have to add general data like name 
> of the WF and
>      db-table, a description and other stuff we usualy have in the apps 
> setup.inc.php.
>    2.  Adding views / stati to the WF: The WF app calls the eTemplate editor 
> and u can define
>      the view, with all fields you need. Each field have label, type and 
> (unique) name.
>    3.  If a view is completed the WF app generates a new lang-file, a
>      eTemplate-distribution-file and a list of new fields in this view.
>    4.  This fields are added to the list of column of the WF's db-table. 
> eTemplate's (db-Tools)? 
>      generate automaticaly a tables_update.inc.php (db-independent update 
> script) which gets
>      installed as update by setup
>    5.  Further views / steps in the workflow can be added, by starting again 
> at 2.
>
>> What has to be implemented for such a system / the WorkFlow app:
>>
>>
>
>    o the WF app has to steer the above discript process and decrement 
> version-numbers (of the
>      app and db-definition) for each new step.
>
>>
>
>    o some new field / widget types need to be implemented for eTemplate:
>         1.  selectboxes with extendable selections (controled by an ACL) to 
> contain the status
>           and other categori like information (standard phpGW cats can 
> already be used)
>         2.  field which allow to link or even embed parts of other app, eg. 
> to enter / edit the
>           contact information which is then stored in the AddressBook and the 
> WF's table has
>           only the id stored. That way these informations are availible for 
> other standard apps
>           like (email)? or TimeTrack?.
>         3.  the nextmatch widget need to allow to endable / disable certain 
> cols and save with
>           predefinable defaults (save with the eTemplate) and user-changeable 
> settings saved in
>           his prefs. Like mozillas listwidget when u click on the icon above 
> the scrollbar
>           (top-right).
>         4.  a fixed relation from the eTemplate's widget type and optional 
> fields like size to a
>           column-definition of a table
>         5.  the file-upload widget has to be extended to store the file in a 
> blob in the WF's
>           db-table of the VFS and show a link to that object and a possiblity 
> to update the
>           file. This is needed to store binary file (eg. an offer or concept) 
> like LotusNotes? 
>           does it in the db-table.
>
>>
>
>    o some common code which is copied from the WF app into the app which 
> represents the WF. This
>      code should allow to:
>         1.  list and select an entry of the WF, based on the defined status, 
> other fields or
>           search criteria
>         2.  call (ACL restricted) status dependable view or edit dialogs 
> based on the eTemplate
>           defined in 2. inserted in the WF's or WF apps standard application 
> eTemplate (which
>           defines eg. app-header or common UI-elements like searches).
>
>>
>
> 4. What's next
>
>    o Please give me your thoughts and comments, to develop the concept further
>    o How much changes do you see for or how much do you need a WorkFlow 
> application?
>    o Do you know any customers who would like to pay / sponsor the 
> development of such an app?
>
>> ralfbecker
>>
>>
> -----------------------------------------------------------------------------------------------
>
>> Please enter your comments here or mail them to phpgroupware-developers at 
>> gnu.org:
>>
>>
>
>    o the db setup classes could to support multiple databases (this has been 
> a long time feature
>      request anyway) so that, like LotusNotes?, WF could actually create a 
> database for each
>      workflow. I'd imagine it wouldn't be hard to "trick" setup into ignoring 
> version numbers
>      and just runt he updates, or even to trick it so each run is a new app 
> in its logic. -- cw
>         o the stuff to support tables on other db's is already on the agenda 
> for setup
>         o of cause should the WF app create / update the table right away, 
> without haveing the
>           user to call setup ralfbecker
>           >
>           >
>    o ...