On Thursday, May 17, 2012 9:37:46 AM UTC-4, Cliff wrote: > > Ross, > > I understand your reasons for attaching approvals to the workflow. I do > it the other way because if a deliverable needs approval by six parties, > putting six additional steps in the flow makes things a little cluttered. > If you add six people as performers of an approval step, does that mean > that any one of the six can approve or must all of them? >
If you were to put all of them in a group and add the group as part of the workflow, any one of them can approve. For cases when you need all 6 to approve, then you would add all 6 of them as steps in the workflow. I don't know of a good, clean, and understandable way to do that otherwise. > > I very much like your workflow object table. > > I'm still debating over whether to use auth to handle the roles. I think > auth needs a table called auth_role, actually a group of groups, to collect > permissions. It would be nice to have a 'has_role' decorator for it. > > Authorization is the only thing in this I'm having trouble wrapping my head around. Previously, I had the objects the workflows were attached to handle their own security with minimal restrictions on the workflow side. It worked out great because the documents were tightly integrated with the workflow system. The major problem being that only documents could participate in the workflows. So I'm still having trouble figuring out how to do this in a more general way without making it so complicated that no one would use it. I am definitely open to suggestions on this one.
