user roles

[David Merrill]

On Tue, Jan 02, 2001 at 05:10:14PM -0500, Derek Atkins wrote:
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > As long as they can do anything at all to data they have *just* entered,
> > I can live with that. I don't want a user to be unable to back up two
> > transactions and correct a typo without calling a manager for
> > approval. That is just not acceptable. And allowing a user to edit or
> > delete something they have just edited is not a security or data risk.
> > A malicious user would have very limited ability to cause damage.
> 
> I have no objections to that.

Cool.

> > Will transactions be saved immediately upon entry, or upon user
> > request? If upon request, we're fine because the user can do anything
> > they want up until they save their work. If it is saved immediately,
> > we need some way of determining whether or not the record is still
> > editable by that user, although they don't have edit permissions. I'm
> > open to suggestions!
> 
> I was under the impression that data was "saved" when the user hit
> "commit".

Good, that makes things easier - both on the client and on the server.
 
> > Okay, so the permissions are:
> > 
> > - System Administration (manage entire system)
> > - Corporate Administration (manage one set of books)
> > - Account Administration (manage a single account)
> > 	(includes the ability to reconcile the account)
> > - Account Data Management (manage all transactions in the account)
> > - Account Data Entry (add/delete/update your own records only)
> > - Restricted Data Entry (add permission only)
> > 
> > Now does *this* work for everybody, or are there further needs
> > unaddressed?
> 
> This works, but I think for simplicity you might want to just
> enumeratate the operations.  Instead of grouping access as you've
> done, you can have permissions like:
> 
> 	administer
> 	add
> 	update
> 	delete
> 	reconcile?
> 	chown?
> 
> Then you can apply these operation permissions to each object:
> 	1) the database
> 	2) a set of bookes
> 	3) an account
> 	4) a split or a transaction

Yep, that's what I'm planning.

> This implies that each object would have an accociated ACL, and each
> ACL would have a list of entries that look something like this:
> 
> 	<name>	<list of perms>
> 
> This allows the greatest flexibility in terms of editing ACLs and
> controlling data access.

I'm planning to define permissions within the database itself. I want
the database to be aware of these permissions so they can be enforced
at that level. They could be exported to the server in any format you
want, including the <name> <list of perms> you suggest.

I am allowing for an arbitrary number of "role" records to be
defined, each of which can be assigned any set of permissions. Each
user is then assigned one or more of these roles, and inherits all the
permissions provided by any of them.

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                dmerrill@lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

Whenever you have need of anything,
Once in the month, and better when the moon is full,
You shall assemble in some secret place
And adore the spirit of Me
Who is Queen of all the Wise.
		-- from The Charge of the Goddess, Doreen Valiente