user roles

linas@linas.org linas@linas.org
Wed, 3 Jan 2001 20:37:10 -0600 (CST)


Hi all,

Allow me to poke my nose into this discussion as well, if that's OK.

There is a generalization of groups & acl's called 'workflow'
that wouldn't be inappropriate for this system.  I won't argue that
'it must be done', but would like to ask you to take a moment & 
understand what its about & how it works.  In many ways, its 
*a lot* like acls, but introduces an additional and very powerful
abstraction.  I think the earlier emails catch *most* of the idea,
without actually mentioning the word 'workflow'.

For a fuller picture, see http://www.linas.org/linux/workflow.html
and the links it points to.  I'll try to put it in the gnucash
framework below (but I'm kind of glossing over some details here):

A 'role' is a collection of acl's on different objects. 
For example, lets define the 'order_entry_role':
This role can create, delete and edit entries in the 'Purchase Orders'
account.  This role can also view transactions/splits 
in the 'Shipping Dock' account, but cannot change them.
Similarly, the 'loading_dock_worker' role can add/change/delete
transactions in the 'Shipping Dock' account, but can only view 
'Purchase Orders'.  Thus, a 'role' is a named list of pairs 
(account, acl).  To find out if a user has permissions to 
perform an action on an account, we crawl through the list,
trying to match what the user wants to do to one of the pairs.

You can deal with 'groups' in several ways.  You could say
a user can play one of more roles (thus, associated with
each user is a list of roles they can play).  Alternately,
you could say 'this group contains these users, and this group is
allowed to play one and only one role'.   Six of one, half-dozen of
the other.

Hmmm.... maybe my treatment is too simplistic ... I'm not sure I
brought anything new to the discussion after all.  Workflow systems
tend to be glorified bug-tracking systems, which can be infinitely
customized.  In a bug-tracking system, any user can report a bug,
but only a programmer is allowed to change the status to
'working-on-it', and only the cvs tree maintainer can change 
the status to 'code-has-been-checked-into-cvs', and only the 
tester-QA person (or the original user) can change the status 
to 'fixed'.  Virtually all bug-tracking systems 'hard-wire'
the states, roles, and permissions; they're not configurable.

A workflow system is basically a generalization, an 'un-hard-wiring'
of the bug-tracker idea.  The names of the states are customizable, 
and who has what permissions to do what things is customizable.
Underlying it all is the 'document' (bug report), which accumulates
notes, dates, signatures, approvals, etc as it makes the rounds.

For a real business accounting system, you have to marry the
notion of workflow to the notion of double-entry.  You want to 
route the purchase order is if it were a bug report, but instead
of it being a text document, its a series of transactions 
spanning a number of accounts. 

Hmm. I know this is vague ... 


--linas





It's been rumoured that Derek Atkins said:
> 
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> [snip]