Task 1: Make a Plan
Before you begin creating security elements in Horizon, SirsiDynix recommends that you first plan out what you need on paper. You need to think about how responsibilities are (or should be) divided among library staff and how you will define security elements in Horizon accordingly. Who should be given access to what? What passkeys, roles, and groups are needed? Will you implement record ownership? This section gives you some guidelines for creating a plan and discusses issues that may affect how you define security elements. Note that your plan does not need to be exhaustive, and that you can always make changes after you start creating the elements in Horizon.
This section explains these topics:
Planning Users
|
1
|
Write down a list of users who need access to Horizon. |
In general, you need a user definition for each member of your library staff. However, you may want to use a single user definition for a group of people who share the same basic tasks, such as circulation clerks. (For example, you might create a user called “circdesk1” and always use this user for workstation #1 at the circulation desk. This prevents circulation staff from having to log in separately and change users frequently when doing circulation tasks.)
|
2
|
Note the security level you want for each user. |
Planning Passkeys
|
1
|
Write down a list of passkeys you need based on the passkey privileges you need to grant to users. |
As you create your list, review your list of users and the list of passkey privileges (see Passkey Privileges) to help you determine what passkeys you will need. You can finish the specific assignment of privileges to passkeys when you create the passkeys in Horizon. Right now, you just need a pretty good idea of what passkeys you need.
Keep in mind that you can assign a passkey to more than one user, but a user cannot have more than one passkey. This means a user’s passkey must include all the passkey privileges he or she needs access to, and that you can use the same passkey only for staff members who require the exact same set of passkey privileges.
|
2
|
Note the passkey you will assign to each user. |
Planning Roles and Groups
|
1
|
Write down a list of roles you need based on the roles that exist in the library and the sets of rights you want to be able to assign to groups. Note the security level you want for each role. |
To help you determine what roles you will need, think about the roles that exist in the library. Keep in mind that a role may be applicable across multiple staff positions. Also review the list of role privileges (see Role Privileges). You can finish the specific assignment of privileges to roles when you create the roles in Horizon. Right now, you just need a pretty good idea of what roles you need.
|
2
|
Make a note of roles that will require CRUDO settings to grant cataloging privileges to users. |
It may be helpful to create one or more roles that define CRUDO settings only (no role privileges). You can then assign these roles to groups as necessary. Note that you can vary the CRUDO settings from role to role to provide different sets of rights (for example, read-only rights, limited editing rights, or full rights).
|
3
|
After you have an initial list of roles, write down a list of groups and note the users and roles you will assign to each group. You may need to make several changes as you refine your plan. Also note that security level you want for each group. |
As you create your list of groups, keep in mind that groups generally correspond to staff positions (for example, cataloger, cataloging supervisor, circulation clerk, or circulation supervisor). Groups let you combine roles according the various combination of privileges you need for your users.
Define your roles and groups carefully to minimize the number of times you must assign a privilege to more than one role. In general, keep your roles small and as applicable to as many groups as possible. Keep in mind that a user can have multiple roles. (Specifically, you can assign multiple roles to a group, and you can assign a user to multiple groups.) This means that roles, unlike passkeys, can define sets of rights that are common across different positions. Instead of duplicating the same privileges in many roles, you can often assign privileges to one role and then assign the role to multiple groups as needed. (For examples, see Figure 5-1.)
Planning Ownerships
|
1
|
Decide whether or not you will use record ownership to restrict users’ rights to specific sets of bibs, authorities, or workforms; or user, role, or group records. |
If you decide not to use record ownership, simply use the default owner of “Unowned” for records that require an owner. Also, use Unowned when you assign a role to a group. As long you do not assign any other owners to your records, rights will be granted to users for all records.
|
2
|
If you decide to use record ownership, write down a list of owners you will use based on the sets of records whose access you want to restrict. |
Define owners carefully. Keep in mind that defining too many ownerships may create confusion and add a lot of overhead for maintaining ownership assignments and for granting rights by ownership.
Also be aware that the software does not provide any context for the owners you define. For example, suppose a user is changing the owner assigned to a bib record. The Owned By drop-down list in the control record for the bib shows all of the owners (for which the user has rights), including owners you may have defined for use with other record types. Consequently, it may be unclear which owners are applicable for bib records.
In these cases (where ownerships are different by record type), you may want to provide the context in the owner descriptions (for example, “Library A - Bib Records”). You should also establish policy and train staff members as needed.
Include the Unowned owner in your list of owners. You will need to use this owner for records that you do not assign to any other owner. The Unowned owner functions like any other owner. You must grant access to records of this ownership they same way you do for records of other ownerships (through role/owner pair assignments).
|
3
|
Using the list of roles you created earlier, write down a list of role/owner pairs for each group according to how you want to restrict rights by ownership. |
For examples, see Example 2: Using Record Ownership. Remember that a user’s rights are restricted by ownership according to the role/owner pairs that are assigned to the groups to which he or she belongs.
Remember to define role/owner pairs that include the Unowned owner, as needed, to grant access to records assigned to the Unowned owner.
Be aware that rights are restricted by ownership only for Horizon processes that use record ownership. Many processes do not use record ownership. (For example, searching does not use record ownership. All users can search on all bib records, unless you have restricted access using the Staff Only setting; however, a user’s ability to edit those bib records may be limited by ownership.)
Currently, record ownership is used for these cataloging and security processes:
© 1998-2017 Sirsi Corporation