[[user-comments:evergreen-admin:policies:usergroups|User Comments]]


==== User Groups and Group Permissions ====

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.

  * **NOTE** -- You __MUST__ select a Permission Depth (the "At Depth" column) in order to save edited permissions.  If you would like the group to have a permission globally, then choose Consortium (or the equivelant if you have adjusted the Organizational Unit Types).

----


==== Group Application Permissions ====

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:
<code>
User
  Patron
    Outreach
    Trustee
  Staff
    Circ
    Cat
    Admin
      Library Manager
      Local Admin
      Global Admin
</code>

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

  * group.application.patron
  * group.application.patron.trustee
  * group.application.staff
  * group.application.staff.circ
  * group.application.staff.cat
  * group.application.staff.admin
  * group.application.staff.admin.lib_man
  * group.application.staff.admin.local_admin
  * group.application.staff.admin.global_admin

After creating these permissions we attach them to each group that needs to be treated in a special way, like this:

<code>
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
</code>

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.