user roles

[Derek Atkins]

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.

> 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".

> 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

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.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available