Access Control Settings

From CollectiveAccess Documentation
Jump to: navigation, search

[Valid for v1.3]

Access Control Settings

In order to manage workflow and ensure the safety of your data, CollectiveAccess employs access control tools. Reached through Manage > Access Control and only available to administrators, this page allows you to create logins, determine which users have access to what parts of the site, and assign specific roles, such as “cataloguer” or “researcher,” to users.

User Logins

In order to create a login for a new user, go to Manage > Access Control and then select “User Logins” from the top of the left-hand navigation. Select the green “+” from the top right of this screen.

Creating User Logins

CreatingUserLogins.png

This arrow will bring you to a form where you will define settings for this new user. Enter basic info about your user (name, email, password, etc.) and choose the “user class” from the drop-down list below “name.” The different user classes are: full-access (which means the ability to work both in the front and back end of the system), public-access (which enables front-end access only), or “deleted,” which is only to be used in the case of a former user whose user logs you may want to see.

New Login Form

New login form.png

  • Be sure to check the “account is activated?” checkbox.

You will also notice two boxes on the new user form; “Roles” and “Groups.” Each login should have a role assignment, such as “cataloguer” or “researcher.” Groups allow you to lump users together for the purpose of sharing forms, sets, and displays. A login does not necessarily have to be associated with a group, but if you wish to share information with only a specific project team, for example, you will want to define that group and populate it with users.

User Groups

So how do you create and define the user groups that appear on the “User Logins” page? Navigate to “User Groups” on the left-hand side. You will see a screen with already-defined user groups, which you can edit, as well as a green “+” on the top right to create brand-new groups.

User Groups

User groups.png

New User Group Form

New user group form.png

Once your groups are defined, you may begin to add users. Then, if you have created a set, for example, such as a slideshow (as discussed in the quick start for cataloguers guide), you can share it with the group working on that project.

Access Roles

Just as with User Groups, the Access Roles that you assign to users must be defined in a separate screen. Click on “Access Roles” in the left-side navigation and you will see a screen that allows you to edit or add roles.

Defining Access Roles
Defining access roles.png


To view the permissions set for a given role, click the edit icon. There are two components to roles: Actions and Metadata access. These are represented in two tabs on the Access Roles screen. “Actions” define various types of system privileges, such as whether or not a user has permission to manage displays. “Metadata access” defines whether a user has “no access”, “read-only access” or “read/edit access” on a per-field basis. This is useful if there is a particularly sensitive field that you want a cataloguer or researcher to be able to see but not change. Access Roles can prevent certain users from deleting records, changing preferences or using certain plug-ins. You may define as many Access Roles as you wish and your users can be assigned as many roles as are appropriate. As you are creating your access roles, should you find that you’re unsure of the purpose of any of the fields, you can hover your mouse over it to get a definition. This holds true for actions throughout the database.

New Access Roles Form: Actions Tab

Access roles a form.png

When a user account is created from Pawtucket they are by default given only actions listed under "Pawtucket Actions." They are: Can Download Media, Can Share Objects via Email, Can Share Objects via Facebook, and Can Initiate Replication of Object Media to External Repositories

New Access Roles Form: Metadata Tab

Access roles m form.png

Record-Level Access

(Note that this feature is disabled by default. To enable, set perform_item_level_access_checking to 1 in app/conf/app.conf). You can also control access settings on a record-by-record basis. When you are within a record, click on “Access” in the left-side navigation. This will bring you to a screen containing two boxes, “Global Access” and “Exceptions.”

  • Use “Global Access” to define general settings for the record in question. The options are: “can edit and delete,” “no access,” “can read,” and “can edit.” Unless you set exceptions, this will determine the accessibility of your record for all users in the back-end system.
  • Use “Exceptions” to narrow the terms set in “Global Access.” If, for example, you wanted to restrict access for most users to “can read,” but you wanted to allow a certain group to read and edit, you would type the title of that group (already defined in the system, of course) into the lookup field, and then choose “can edit” from the drop-down list. Similarly, if you wanted to give a specific user more (or less) access than the general user community, you could define that here.

Record-Level Access

Record level access.png

These record-level access definitions only apply to the back-end of the database. In other words, you are only restricting (or granting) access to users who are working within the database. If you wish to apply restrictions to public access, you can use a drop-down on the Basic Info page of a record.

Public Access Settings

Public access settings.png

This will limit what visitors to a public website can view, but it won’t affect access within the back-end.

Namespaces

Variants
Actions
Navigation
Tools
User
Personal tools