Hi, Wow. This looks very complicated, quite involved, and a pain in the butt to administer. And my suggestions will probably make it worse...
I'm not seeing anything wrong with the list, but I'm wondering about what's missing. What comes to mind are contact management things, like associating contacts with employees, customers, vendors, etc -- seems like you wouldn't want someone who can create a customer to create an employee. Mainly things around the HR functionality, stuff we would want to extend for Payroll. The other suggestion I have is to have some sort of group functionality, so we don't need to configure every single user with each associated right. I'm thinking of groups such as "cashier", "shipping/receiving", "AP", etc, which can be associated with sets of rights. Then can add users to these groups and override individual permissions only if necessary. Maybe this is already planned? Cheers, -- John Locke "Open Source Solutions for Small Business Problems" published by Charles River Media, June 2004 http://www.freelock.com Chris Travers wrote: > Some information is presumed public (meaning user-accessible), such as > the structure of the CoA but not necessarily the balances or > transactions. We could add permissions on these somewhere in 1.4 as > well but the dependencies are likely to take a while to sort out. > > I: Contact Management: > create_contact > edit_contact > read_contact > contact_all_rights (member of all of the above) > <snip> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
