On 8/9/07, John Locke <..hidden..> wrote:
Hi,
Wow. This looks very complicated, quite involved, and a pain in the butt
to administer. And my suggestions will probably make it worse...
It is replacing the "hide menu options" buttons.
I think we should probably add some summary roles too which allow one to provide broad permissions across modules instead of having to create them all. Furthermore, we should be able to extend this (maybe in 1.4) to be able to define custom roles with certain permissions. Nothing is likely to prevent people from doing this themselves in
1.3, however.
Any suggestions on summary roles are appreciated, however.
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.
Yeah, we will need separate permissions for employees. Thanks. Will add (see the power of peer review?).
Something like:
EMPLOYEE:
create_employee (member of create_contact)
edit_employee (member of edit_contact)
an ability to list employees is currently considered available to all users unless there are objections.
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?
These will use DB roles, so permission is always cumulative.
I don't think an easy way to add groups through the interface will be available in
1.3, probably will in 1.4, but I would expect it to be fairly easy in the implementation stage to add additional group roles for this version.
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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel