David Merrill <[EMAIL PROTECTED]> writes:
> 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.
I have no objections to that.
> 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!
I was under the impression that data was "saved" when the user hit
"commit".
> 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?
This works, but I think for simplicity you might want to just
enumeratate the operations. Instead of grouping access as you've
done, you can have permissions like:
administer
add
update
delete
reconcile?
chown?
Then you can apply these operation permissions to each object:
1) the database
2) a set of bookes
3) an account
4) a split or a transaction
This implies that each object would have an accociated ACL, and each
ACL would have a list of entries that look something like this:
<name> <list of perms>
This allows the greatest flexibility in terms of editing ACLs and
controlling data access.
-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
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
