On 8/9/07, John Locke <[EMAIL PROTECTED]> wrote:
>
>
> Chris Travers wrote:
> >
> > 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 thinking (partial list): "AP", "AR", "Cashier",
> "Shipping/Receiving", "Bookkeeper", "Accountant", "HR", "Employee",
> "Manufacturing", "Sales". That's what comes to mind...
> >
> > 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.
> Hmm. I have worked in places where they don't want people to be able to
> look up home numbers/addresses of other employees... Also possibly for
> outsourced bookkeepers... I would think inheriting the read_contact
> right should cover this case, maybe?
Ok. We may need to think about this some more. Certainly getting a list of
names, id's, of employees is required by a surprising set of application
functionality and we may not be able to address this in 1.3 using db-level
permissions.
>
> > 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.
> Sounds good!
We may or maynot have group functionality for 1.3 depending on how much gets
done :-) Either way, I would expect it for 1.4....
Best Wishes,
Chris Travers
Cheers,
>
> --
> John Locke
> "Open Source Solutions for Small Business Problems"
> published by Charles River Media, June 2004
> http://www.freelock.com
>
>
> -------------------------------------------------------------------------
> 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
