On Tue, Jan 02, 2001 at 03:48:13PM -0600, Richard Wackerbarth wrote:
> >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.
That would be great, but it's too ambitious for the first release. I
will make a note of it, though.
--
Dr. David C. Merrill http://www.lupercalia.net
Linux Documentation Project [EMAIL PROTECTED]
Collection Editor & Coordinator http://www.linuxdoc.org
Finger me for my public key
Hoof and Horn, Hoof and Horn
All that dies shall be reborn
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
