On 8/9/07, John Locke <[EMAIL PROTECTED]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>
-------------------------------------------------------------------------
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
