user roles

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


On Tue, Jan 02, 2001 at 04:40:26PM -0500, Derek Atkins wrote:
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > - 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?
> 
> No.  I still think there are times when someone might have permission
> to create an entry, but not delete it (even if they "own" it).  The
> problem is that a malicious user could go and destroy a lot of work,
> requiring a lot of time and effort to recover.  Whereas we can prevent
> it in the first place with a little more work on our shoulders.

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.

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!

> > 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.
> 
> Being able to recover data is a good thing.  However, it would be nice
> to not have to depend on spending time recovering data when
> "unauthorized" changes are made.  I'd rather have the changes fail in
> the first place (or perhaps be flaged with "unauthorized").

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?

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

Under the full moon light we dance
Spirits dance, we dance
Joining hands, we dance
Joining souls rejoice!
		-- Karen Beth