user roles

[Richard Wackerbarth]

>On Tue, Jan 02, 2001 at 04:02:02PM -0500, Derek Atkins wrote:
> > 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.

In the "real world" business situation, there is often a requirement 
for the ability to allow one person to make entries that are then 
reviewed and approved by a superior. The act of approving the entries 
would cause the "ownership" of those entries to be changed.

One useful technique in doing this is to associate the "ownership" 
with a role rather than a person and permit certain individuals to 
alter the ownership property.

Often the policy will require that this ability be data sensitive.

----------------------------------------------------
Richard Wackerbarth		The Digital Dataplex
rkw@DATAPLEX.NET		8801 Camelia Ln
(512) 345-7941			Austin, TX 78759