user roles

[Eugene Tyurin]

On Tue, Jan 02, 2001 at 04:02:24PM -0500, Derek Atkins wrote:
> David, a good start...
> 
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > We need to determine what level of granularity we want to provide for
> > user permissions. Here is a simple set of permissions to start with.
> > Tell me what I've missed:
> > 
> > - system administration (manage entire system)
> > - corporate administration (manage one set of books)
> > - account administration (manage a single account)
> > - account data entry (add/delete/update records in an account)
> 
> 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.

Now,  this is  the dark  forest we  get into  when we  start playing
"enterprise class" database-backed software.

1. Nothing  can  be  *deleted*.   Entries  can  only  be  voided  or
superceded,  but  they  have  to  remain in  the  database  for  the
audit/logging purposes.

2. All database  entries (even  superceded ones) must  be associated
with the userid  and time of creation.   This way a user  can give a
date to the  program and obtain an exact snapshot  of the books.  

-- 
ET.