Re: Adding Roles

System - Admin Users menu option lets you assign permissions ("groups") to an existing user. There's no "Add Role" button or menu option currently in the LedgerSMB front-end; it must be implemented in the back-end. Examples of roles would include sales rep, warehouse, cashier, etc.

Here are some instructions Chris wrote up for adding roles.

2.4 Creating Custom Groups
Because LedgerSMB uses database roles and naming conventions to manage permissions it is possible to create additional roles and use them to manage groups. There is not currently a way of doing this from the front-end, but as long as you follow the conventions, roles you create can be assigned to users through the front-end. One can also create super-groups that the front-end cannot see but can assign permissions to groups of users on multiple databases. This section will cover both of these approaches.

2.4.1 Naming Conventions
In PostgreSQL, roles are global to the instance of the server. This means that a single role can exist and be granted permissions on multiple databases. We therefore have to be careful to avoid naming collisions which could have the effect of granting permissions unintentionally to individuals who are not intended to be application users.  The overall role consists of a preﬁx and a name. The preﬁx starts with lsmb_ to identify the role as one created by this application, and then typically the name of the database. This convention can be overridden by setting this in the defaults table (the setting is named ’role_preﬁx’) but this is typically done only when renaming databases. After the preﬁx follow two underscores.  So by default a role for LedgerSMB in a company named mtech_test would start with lsmb_mtech_test__.  To create a role for LedgerSMB all we have to do is create one in the database with these conventions.

2.4.2 Example
Suppose mtech_test is a database for a ﬁnancial services company and most users must have appropriate permissions to enter batches etc, but not approve them.  A role could be created like:

CREATE ROLE lsmb_mtech_test__user;
GRANT lsmb_mtech_test__all_ap,
            lsmb_mtech_test__create_batch,
            lsmb_mtech_test__read_contact,
            lsmb_mtech_test__list_batches,
            lsmb_mtech_test__create_contact,
            lsmb_mtech_test__all_gl,
            lsmb_mtech_test__process_payment
TO lsmb_mtech_test__user;

Then when going to the user interface to add roles, you will see an entry that says "user" and this
can be granted to the user.

As an aside, contact types are stored in the entity_class table. Chris wrote this about contact types:

Currently the database can handle arbitrary classifications of contacts.  The default table is:

  lsmb14test=# select * from entity_class;
 id |  class   | country_id | active
----+----------+------------+--------
  1 | Vendor   |            | t
  2 | Customer |            | t
  3 | Employee |            | t
  4 | Contact  |            | t
  5 | Lead     |            | t
  6 | Referral |            | t
(6 rows)

I would probably leave 5 for generic leads and add 7 for hot leads and
8 for cold leads.  Then we'd just add menu items for adding these, and
the 1.4 search routine will be able to find them.

Thanks.
Brian

Brian Wolf

Phone: 410.367.2958

Email: ..hidden..

Try out Activus Secure Payments™, our recurring payments application.

Demo at http://demo.activustech.com

On 11/03/2012 09:09 AM, Robert James Clay wrote: