Ross,
I like the workflow monitor table, though I think it should be tied to the
template rather than individual workflows. Since each stage knows the id
of its parent workflow and the workflow knows the id of its template, it
would be a simple matter to get the monitors and ping them when there's a
state transition.
I think approvers need to be tied to specific stages. Again I'm thinking
of things like large software development project where the sales jocks
have veto power on the product specifications but no input to the
acceptance test plan. There could be a flag in the monitor table to
indicate that certain members have approval at every stage, I suppose.
Likewise the comments should be tied to stages. I'm assuming that the
workflow status of some system object would be accessible through links on
the object page, or via a tab on the page. The comments could be pulled
together and displayed there.
Reviewers rights should be limited to comments.
Here is my current thinking WRT the data model:
db.define_table('wf_template',
Field('name', length=64, required=True, notnull=True),
Field('comment', length=254),
)
db.define_table('wf_state',
Field('template_id', db.wf_template, requires=IS_IN_DB(db,
'wf_template.id', '%(name)s')),
Field('name', length=64, required=True, notnull=True),
Field('objective', length=254,),
Field('past_tense', length=64, required=True, notnull=True),
Field('max_duration', 'decimal(6,2)',
requires=IS_EMPTY_OR(IS_DECIMAL_IN_RANGE(0, None)),
label = 'Maximum duration',
comment = 'Hours. Considered late if takes longer. Optional',
),
)
query = ((db.auth_user.is_active==True) &
(db.auth_user.tenant_link==tenant_link_default))
db.define_table('state_user',
Field('user_id', db.auth_user, 'auth_user.id', requires=IS_IN_DB(
db(query), 'auth_user.id',
'%(first_name)s %(middle_name)s %(last_name)s %(generation)s'
)
),
Field('user_role', requires=IS_IN_SET(['Performer', 'Approver on
entry',
'Approver on exit','Reviewer', 'FYI', ]),
),
Field('notify_on', requires=IS_IN_SET(['Entry', 'Completion',
'Change',
'Comment',]),)
)
db.define_table('state_link',
Field('from_state_id', db.wf_state, requires=IS_IN_DB(db,
'wf_state.id', '%(name)s')),
Field('to_state_id', db.wf_state, requires=IS_IN_DB(db,
'wf_state.id', '%(name)s')),
)
On Wednesday, May 16, 2012 11:22:46 AM UTC-4, Ross Peoples wrote:
>
> Cliff,
>
> Thanks for putting this into a spec. My current code follows most of what
> is in there. I still haven't finished writing (or testing it), but I do
> have some thoughts on implementation for one or two of the items listed at
> the end:
>
> I imagine a "workflow_monitor" table that has the fields: user_id,
> workflow_id. By default, when a workflow is started, the user that started
> gets added to this table along with the workflow they started. Using this,
> an application can design an interface that shows two lists: one listing
> workflows waiting on the user, and another listing workflows being
> monitored by the user. Templates should have to ability to set a default
> list of users or groups that automatically get added as monitoring the
> workflow. This would be great for managers to see a birds-eye view of
> everything going on for every person they manage.
>
> Approvers should be part of the workflow, since it should not continue
> unless approved.
>
> I'm not sure how to handle reviewers, since they don't really have any
> control over the workflow. Maybe reviewers can be marked as "monitoring",
> and when they need to comment on something, they just leave a note. For
> this, I see a "workflow_comment" table that has these fields: workflow_id,
> user_id, event_date, is_active, comment. The is_active field will be set to
> True by default. Once the comment / issue has been addressed, is_active
> gets set to False.
>
> I could also imagine a high-level list of goals that need to be
> accomplished with the workflow, sort of like a checklist, that users mark
> as completed as the workflow moves through the system. This would probably
> satisfy a use case that exists in my current company. They currently use a
> page within a document as a "sign off" page to make sure everyone inspected
> their section of the document. Having this workflow checklist would remove
> the need for this extra page within the document.
>
> Thoughts?
>
> Thanks, Ross
>
