Here you will find a tree of the current User Groups that exists in the Open-ILS installation. By clicking on the labels in the tree you can bring up an individual Group for edit or removal. You can rename the Groups, adjust permissions and add child Groups using the forms in the right hand pane.
Permissions in Open-ILS are applied to a specific portion of the Library (Organizational Unit) Hierarchy based on the Home Library (home_ou) of the user in question. The user will only have that permission within the scope provided by the "At Depth" field in relation to his Home Library.
The default permissions and groups supplied with Open-ILS should be sufficient to get you going, but it's a good idea to familiarize yourself with this admin interface.
Evergreen provides Group Application permissions in order to restrict which staff members have the ability to assign elevated permissions to a user, and which staff members have the ability to edit users in particular groups. These permissions are created, attached to groups, and assigned by the a global administrator. Perhaps the best way to explain this concept is by way of an example.
First, we will posit a group hierarchy:
User Patron Outreach Trustee Staff Circ Cat Admin Library Manager Local Admin Global Admin
Take, for instance, the case of a volunteer circulation staff member who is responsible for registering and updating patron accounts. They necessarily need to be able to assign a user to one of potentially several patron-type groups. However, they should not be able to assign this new patron-type user to a staff group. In this case, the circ staff member in question needs to be restricted in such a way that they can assign the user to Patron or Outreach, but not Trustee, which will have lower max fines.
First, we use the Permission Editor in the bootstrapping interface to create a set of permissions which we will use to restrict the use of specific groups. This is a local addition to the set of permissions, and must be managed by a global administrator that has access to the bootstrapping interface. Permissions that we will need in this example are
After creating these permissions we attach them to each group that needs to be treated in a special way, like this:
User Patron == group.application.patron Outreach Trustee == group.application.patron.trustee Staff == group.application.staff Circ == group.application.staff.circ Cat == group.application.staff.cat Admin == group.application.staff.admin Library Manager == group.application.staff.admin.lib_man Local Admin == group.application.staff.admin.local_admin Global Admin == group.application.staff.admin.global_admin
At this point, only the admin account, or other accounts that have been given the EVERYTHING permission or marked as a superuser, can assign users to any group other than the User group or edit users other than those in the User group. In order allow other staff members to assign users to protected groups and edit users in those groups we must give the appropriate staff members the correct permissions.
In this example we need to allow the circulation user to put other users into the Patron and Outreach groups, so we give the Circ group the group.application.patron permission. These permissions cascaded down into subgroups that do not have their own Group Application permission, such as Outreach in this case, but subgroups that do have their own permission require that the editing staff member have that permission, such as in the case of Trustee. These Group Application permissions, just like all other permissions, can be given to individual users as well as to groups.
In this way, each group can be protected from unauthorized edits and additions by managing which users have the right to edit users in, move users to, or register users with specific groups.