user roles

[Derek Atkins]

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.

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

-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