user roles

David Merrill dmerrill@lupercalia.net
Tue, 2 Jan 2001 16:16:04 -0500


On Tue, Jan 02, 2001 at 04:02:02PM -0500, Derek Atkins wrote:
> David, a good start...
> 
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > We need to determine what level of granularity we want to provide for
> > user permissions. Here is a simple set of permissions to start with.
> > Tell me what I've missed:
> > 
> > - system administration (manage entire system)
> > - corporate administration (manage one set of books)
> > - account administration (manage a single account)
> > - account data entry (add/delete/update records in an account)

- restricted data entry (add/delete/update your own records only)

> I would think that add, delete, and update might be split into three
> different sets of permissions.  I may give a secretary permission to
> add entries, but I dont want him/her to be able to change or even
> worse delete entries.

I'm not convinced of the need for this. It sounds like one of those
"would be nice" features programmers think up that users don't care
about. Of course I know I could be completely wrong.

But a user could have separate permissions for their own data (data
they added) and other folks' data. So s/he can edit a mistake s/he
made, but can't change another user's records. I can't see any reason
for preventing a user from editing data they put in in the first
place.

And ownership does not change when somebody else makes an edit. If you
created the record, you own it forever, at least in this context.

Does this address your concern adequately?

> Perhaps we might want a "can perform these operations but commitment
> requires the approval of someone else".  I.e., they can try to update
> a record, but I need to approve the change before it is committed.

This seems to be made unnecessary by the audit trail and the ability
to undo changes, which will not be in initial release but probably the
next one. Of course, a halfway capable db administrator can do an undo
anyway; there just won't be any support for it in the client or engine
in the first release. The audit trail really minizes the risk to which
your data is exposed by a malicious or incompetent clerk.

Or if not made unnecessary, it is at least made less important. And it
would be decidedly nontrivial to implement. I'm trying to keep things
simple, remember? ;-)

This is another reason why I think separating add and delete/update
permissions is not needed.

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

By the Earth that is Her body
By the Air that is Her breath
By the Fire of Her bright spirit
By the Waters of Her living Womb,
The circle is cast.
		-- Traditional Circle Casting