Task 6: Set Up Roles
Using the list of roles you defined in task 1, follow the steps in this task to set up the roles in Horizon. You will assign the roles to groups later in task 7. This task consists of two parts: first, creating the role and adding privileges, and second, adding CRUDO settings to include cataloging rights, if necessary.
Task 6.1: Create Role and Add Privileges
|
1
|
Start the Role Manager process. |
The default location of this process is the Administration\Security Menu folder on the navigation bar.
Horizon displays the Role Manager window.
|
2
|
Click New to display the Role window. |
Here is an example of a completed window:
|
3
|
Complete these fields in the window: |
Role Name
|
Enter a name for the role.
Choose a name that describes the general responsibilities of the role (such as “Cataloging Basic”).
|
Security Level
|
Choose the security level you want for the role.
A role’s security level determines which privileges can be assigned to the role. You can choose from these levels, shown in order of most access to the least access:
|
•
|
Local Admin. Privileges with a security level of Local Admin or lower are available to assign to the role. |
|
•
|
Supervisor. Privileges with a security level of Supervisor or lower are available to assign to the role. |
|
•
|
Staff. Privileges with a security level of Staff or Guest are available to assign to the role. |
|
•
|
Guest. Only privileges with a security level of Guest are available to assign to the role. |
The Sys Admin security level is not available for a role since users with this security level are given full rights automatically.
Lowering a role’s security level may restrict privileges already assigned to the role. If so, Horizon tells you that the change will cause privileges to be removed. If you still want to make the change, click Yes; otherwise, click No.
Raising a role’s security level may restrict groups to which the role has already been assigned. If so, Horizon tells you that the change will cause the role to be removed from some groups. If you still want to make the change, click Yes; otherwise, click No.
|
Role Owned By
|
Choose an owner for the role.
Access to the role definition is restricted to users who have the Role Manager privilege for the owner you choose (based on the role/owner pairs assigned to groups). If your library is not using record ownership for roles, use the default Unowned owner. (For information about owners and record ownership, see Ownerships and Planning Ownerships.)
|
|
4
|
Click Add to display the Add Privileges window. |
This window shows the privileges you can assign to the role based on the role’s security level. Privileges that you have already assigned to the role, if any, are not shown.
|
5
|
Follow these steps to assign privileges to the role: |
|
a
|
Highlight the privileges you want to add to the role. |
Highlight only privileges that you want to add under the same permission. (You can repeat these steps later to add a different set of privileges under the other permission.) Use the SHIFT and CTRL keys as necessary to highlight multiple items in the list. Press CTRL+A to highlight all the items in the list.
|
b
|
Under Permission, choose the permission you want for the privileges: |
|
•
|
Full. Grants the privilege to users without any restrictions. |
|
•
|
Approval Required. Requires users to get permission before they are given access to the privilege. If the user attempts to access the privilege, Horizon prompts the user for a user name and password. Another user with full rights to the privilege must then enter his or her password before access is given. Horizon displays this prompt each time the user attempts to access the privilege, even if permission was granted previously in the same session. |
Horizon adds the privileges to the role with the permission you specified.
|
d
|
Repeat these steps if you want to add a different set of privileges under the other permission. |
|
6
|
Click Close to close the Add Privileges window. |
|
9
|
Click Close to close the Role window. |
|
10
|
Repeat steps 2 through 9 for each additional role you want to create. |
Task 6.2: Add CRUDO Settings to a Role
For roles that require cataloging privileges, complete this task to add rights for creating, reading, updating, and deleting bibs, authorities, and workforms, and for changing the owner assigned to these records. You can apply CRUDO settings at the record, tag, and subfield levels. You first define rights for the entire record and then define exceptions for individual tags and subfields as needed.
The rights you define at the record level apply to all tags and subfields unless you define exceptions for specific tags and subfields. Many libraries will need to define rights at the record level only; however, some libraries, such as academic libraries or multi-branch libraries may use tag- and subfield-level exceptions to restrict rights to specific tags (such as authority-controlled tags or local tags).
In general, rights at the tag level are inherited from the rights at the record level, and rights at the subfield level are inherited from the rights at the tag level. This diagram shows how rights are inherited from one level to another:
The Read right at the record level grants or restricts Read rights for all tags and subfields, unless you define exceptions for individual tags or subfields. The Update right at the record level grants or restricts Create, Update, and Delete rights for all tags and subfields, unless you define exceptions for individual tags and subfields.
The Read right at the tag level grants or restricts Read rights for all subfields, unless you define exceptions for individual subfields. The Update right at the tag level, grants or restricts Create, Read, Update, and Delete rights for all subfields, unless you define exceptions for individual subfields.
The Create, Delete, and Owner rights at the record level apply to the record only. The Create and Delete rights at the tag level apply to the tag only.
Note that the Update right does not automatically set the Read right. There may be cases when you want to grant Update rights but not Read rights at the record or tag level. (For example, suppose you want to give users read and update rights to only a handful of tags. To do this, you can grant Update rights, but deny Read rights at the record level. You can then turn on Read rights for only those tags you want the user to update, instead of granting Read rights at the record level and defining many tag-level exceptions to turn off read rights for all of the tags you do not want the user to see.)
Note that you can display information for which users have read-only rights in a different color in the MARC Editor. (For instructions, see “Choosing Field Options” in the “Customizing MARC Editor” chapter of the Cataloging Guide.)
To add CRUDO settings to a role
|
1
|
Start the Role Manager process. |
The default location of this process is the Administration\Security Menu folder on the navigation bar.
Horizon displays the Role Manager window.
|
2
|
Highlight the role to which you want to add CRUDO settings. |
|
4
|
Click the Cataloging tab. |
|
5
|
In the Record Type drop-down list, choose the record type for which you want to define privileges: |
|
•
|
For authority records and authority workforms, choose auth. |
|
•
|
For bib records and bib workforms, choose bib. |
|
6
|
Mark the rights you want to grant for records of the specified record type (You can define exceptions to these privileges for specific tags and subfields in the next steps). |
Important: Mark each right you want to grant. Marking one right does not automatically grant another, related right. (For example, marking Update does not grant read rights. To allow the user to update the record, you must grant both Read and Update rights.)
|
•
|
Read. Mark this box to allow users to view records of the specified type. Marking this box allows users to view all the tags and subfields within the record, unless you enter exceptions for specific tags or subfields. Clear this box to prevent users from viewing records of the specified type. Clearing this box prevents users from viewing any tags or subfields within the record, unless you enter exceptions for specific tags or subfields. |
|
•
|
Create. Mark this box to allow users to create records of the specified type. Clear this box to prevent users from creating records of the specified type. |
|
•
|
Update. Mark this box to allow users to make changes to records of the specified type. Marking this box allows users to add, update, or delete any of the tags or subfields within the record, unless you enter exceptions for specific tags or subfields. Clear this box to prevent users from making changes to records of the specified record type. Clearing this box prevents users from adding, updating, or deleting any of the tags or subfields within the record, unless you enter exceptions for specific tags or subfields. |
|
•
|
Delete. Mark this box to allow users to delete records of the specified type. Clear this box to prevent users from deleting records of the specified record type. |
|
•
|
Ownership Change. Mark this box to allow users to change the owner assigned to records of the specified type. Clear this box to prevent users from changing the owner assigned to records of the specified type. |
|
7
|
If you want to define an exception for a tag, do these steps: |
|
a
|
Click inside the Tag field. |
|
b
|
Choose the tag from the drop-down list. |
|
c
|
Mark the rights you want to grant for the tag (You can define exceptions to these rights for specific subfields in the next step). |
|
•
|
Read. Mark this box to allow users to view the tag. Marking this box allows users to view all subfields within the tag, unless you enter exceptions for specific subfields. Clear this box to prevent users from viewing the tag. Clearing this box prevents users from viewing any of the subfields in the tag, unless you enter exceptions for specific subfields. This setting overrides the record-level setting for the tag. |
|
•
|
Create. Mark this box to allow users to add the tag. Clear this box to prevent users from adding the tag. |
|
•
|
Update. Mark this box to allow users to make changes to the tag. Marking this box allows users to add, update, or delete any of the subfields within the tag, unless you enter exceptions for specific subfields. Clear this box to prevent users from making changes to the tag. Clearing this box prevents users from adding, updating, or deleting any of the subfields within the tag, unless you enter exceptions for specific subfields. This setting overrides the record-level setting for the tag. |
|
•
|
Delete. Mark this box to allow users to delete the tag. Clear this box to prevent users from deleting the delete the tag. |
|
d
|
Repeat these steps for each tag-level exception you want. |
|
8
|
If you want to define an exception to a tag-level setting for a specific subfield, do these steps. |
|
a
|
Highlight the tag you want to define an exception for. |
|
b
|
Click inside the Subfield field and choose the subfield from the drop-down list. |
|
c
|
Mark the rights you want to grant for the subfield: |
|
•
|
Read. Mark this box to allow users to view the subfield. Clear this box to prevent users from viewing the subfield. This setting overrides the tag-level setting for the subfield. |
|
•
|
Create. Mark this box to allow users to add the subfield. Clear this box to prevent users from adding the subfield. |
|
•
|
Update. Mark this box to allow users to change the data in the subfield. Clear this box to prevent users from changing the data in the subfield. This setting overrides the tag-level setting for the subfield. |
|
•
|
Delete. Mark this box to allow users to delete the subfield. Clear this box to prevent users from deleting the subfield. |
© 1998-2017 Sirsi Corporation