user roles

[linas@linas.org]

It's been rumoured that David Merrill said:
> On Wed, Jan 03, 2001 at 08:36:48PM -0600, linas@linas.org wrote:
> > There is a generalization of groups & acl's called 'workflow'
> 
> It is an interesting question for UI design, though. We need to decide
> whether "workflow", "group", "role" or something entirely different
> will be the most natural and intuitive for users. But that is entirely
> a client decision.

Let me start by saying that, right now, for a multi-user solution, a
basic login with basic access controls is better than what we have.
So let me not confuse that issue.


In a standard workflow system, you have a 'business analyst' who
knows how some given company operates, and comes in and designs a
workflow for that company.  And that's that.

>From the GUI/client point of view: users log in, and they see a to-do
list.  Phone calls to make, orders to approve, bugs to fix, whatever.
And they try to clear off thier todo-list (haha, impossible).
A good workflow system will allow them to search, sort, rank thier
list(s).  e.g. for a sales-force automation, you could sort by 
'size of wallet', date of last call, or urgency of last conversation.

What I don't have much of a clue is how that fits in with a financial
system.  Hmm.

Employee comes back from business trip, fills in 'travel expense
report' with filight numbers, hotel, and the $$$ spent on meals.
(problem 1: gnucash has no way of designing custom forms).  Then
they hit the submit button, which puts it on bosses todo list. 
Who either approves, or bounces it back.  (problem 2: boss just 
hits a approve/no buttton; we don't need a register gui or guppi 
pie chart for that).  It then gets routed to accounting, for 
reimbursement processing. Only then, maybe, does someone actually 
use a register ... 

So while I advocate high acl flexibility, I can't say that there is
any immediate, pressing reason for it.

--linas