Many different members of your staff will use your Evergreen system to perform the wide variety of tasks required of the library.
When the Evergreen installation was completed, a number of permission groups should have been automatically created. These permission groups are:
Each of these permission groups has a different set of permissions connected to them that allow them to do different things with the Evergreen system. Some of the permissions are the same between groups; some are different. These permissions are typically tied to one or more working location (sometimes referred to as a working organizational unit or work OU) which affects where a particular user can exercise the permissions they have been granted.
To grant a working location to a staff user in the staff client:
The Evergreen community uses two different approaches to deal with managing permissions for users:
The advantage to this approach is that you can maintain the permissions entirely within the staff client; a drawback to this approach is that it can be challenging to remember to add a new permission to all of the groups. Another drawback of this approach is that the user profile is also used to determine circulation and hold rules, so the complexity of your circulation and hold rules might increase significantly.
Permissions and profiles are not carved in stone. As the system administrator, you can change them as needed. You may set and alter the permissions for each permission group in line with what your library, or possibly your consortium, defines as the appropriate needs for each function in the library.
In this section, we'll show you in the staff client:
In the staff client, in the upper right corner of the screen, click on Admin > Server Administration > Permissions.
The list of available permissions will appear on screen and you can scroll down through them to see permissions that are already available in your default installation of Evergreen.
There are over 500 permissions in the permission list. They appear in two columns: Code and Description. Code is the name of the permission as it appear in the Evergreen database. Description is a brief note on what the permission allows. All of the most common permissions have easily understandable descriptions.
Two panes will open on your screen. The left pane provides a tree view of existing Permission Groups. The right pane contains two tabs: Group Configuration and Group Permissions.
In the left pane, you will find a listing of the existing Permission Groups which were installed by default. Click on the + sign next to any folder to expand the tree and see the groups underneath it. You should see the Permission Groups that were listed at the beginning of this chapter. If you do not and you need them, you will have to create them.
First, we will remove a permission from the Staff group.
Now, we will add the permission we just removed back to the Staff group.
While the ability to assign a user to multiple permission groups has existed in Evergreen for years, a staff client interface is not currently available to facilitate the work of the Evergreen administrator. However, if you or members of your team are comfortable working directly with the Evergreen database, you can use this approach to separate the borrowing profile of your users from the permissions that you grant to staff, while minimizing the amount of overlapping permissions that you need to manage for a set of permission groups that would otherwise multiply exponentially to represent all possible combinations of staff roles.
In the following example, we create three new groups:
Then we add three new users to our system: one who needs to perform some cataloging duties as a student; one who needs perform some circulation duties as a student; and one who needs to perform both cataloging and circulation duties. This section demonstrates how to add these permissions to the users at the database level.
To create the Student group, add a new row to the permission.grp_tree table as a child of the Patrons group:
INSERT INTO permission.grp_tree (name, parent, usergroup, description, application_perm) SELECT 'Students', pgt.id, TRUE, 'Student borrowers', 'group_application.user.patron.student' FROM permission.grp_tree pgt WHERE name = 'Patrons';
To create the Student Cataloger group, add a new row to the permission.grp_tree table as a child of the Staff group:
INSERT INTO permission.grp_tree (name, parent, usergroup, description, application_perm) SELECT 'Student Catalogers', pgt.id, TRUE, 'Student catalogers', 'group_application.user.staff.student_cataloger' FROM permission.grp_tree pgt WHERE name = 'Staff';
To create the Student Circulator group, add a new row to the permission.grp_tree table as a child of the Staff group:
INSERT INTO permission.grp_tree (name, parent, usergroup, description, application_perm) SELECT 'Student Circulators', pgt.id, TRUE, 'Student circulators', 'group_application.user.staff.student_circulator' FROM permission.grp_tree pgt WHERE name = 'Staff';
We want to give the Student Catalogers group the ability to work with MARC records at the consortial level, so we assign the UPDATE_MARC, CREATE_MARC, and IMPORT_MARC permissions at depth 0:
WITH pgt AS ( SELECT id FROM permission.grp_tree WHERE name = 'Student Catalogers' ) INSERT INTO permission.grp_perm_map (grp, perm, depth) SELECT pgt.id, ppl.id, 0 FROM permission.perm_list ppl, pgt WHERE ppl.code IN ('UPDATE_MARC', 'CREATE_MARC', 'IMPORT_MARC');
Similarly, we want to give the Student Circulators group the abillity to check out copies and record in-house uses at the system level, so we assign the COPY_CHECKOUT and CREATE_IN_HOUSE_USE permissions at depth 1 (overriding the same Staff permissions that were granted only at depth 2):
WITH pgt AS ( SELECT id FROM permission.grp_tree WHERE name = 'Student Circulators' ) INSERT INTO permission.grp_perm_map (grp, perm, depth) SELECT pgt.id, ppl.id, 1 FROM permission.perm_list ppl, pgt WHERE ppl.code IN ('COPY_CHECKOUT', 'CREATE_IN_HOUSE_USE');
Finally, we want to add our students to the groups. The request may arrive in your inbox from the library along the lines of "Please add Mint Julep as a Student Cataloger, Bloody Caesar as a Student Circulator, and Grass Hopper as a Student Cataloguer / Circulator; I've already created their accounts and given them a work organizational unit." You can translate that into the following SQL to add the users to the pertinent permission groups, adjusting for the inevitable typos in the names of the users.
First, add our Student Cataloger:
WITH pgt AS ( SELECT id FROM permission.grp_tree WHERE name = 'Student Catalogers' ) INSERT INTO permission.usr_grp_map (usr, grp) SELECT au.id, pgt.id FROM actor.usr au, pgt WHERE first_given_name = 'Mint' AND family_name = 'Julep';
Next, add the Student Circulator:
WITH pgt AS ( SELECT id FROM permission.grp_tree WHERE name = 'Student Circulators' ) INSERT INTO permission.usr_grp_map (usr, grp) SELECT au.id, pgt.id FROM actor.usr au, pgt WHERE first_given_name = 'Bloody' AND family_name = 'Caesar';
Finally, add the all-powerful Student Cataloger / Student Circulator:
WITH pgt AS ( SELECT id FROM permission.grp_tree WHERE name IN ('Student Catalogers', 'Student Circulators') ) INSERT INTO permission.usr_grp_map (usr, grp) SELECT au.id, pgt.id FROM actor.usr au, pgt WHERE first_given_name = 'Grass' AND family_name = 'Hopper';
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.