The permissions system in CWIS determines who can create, edit, and view resources.
In CWIS, 'Authoring' refers to the creation of new resources, 'Editing' refers to the modification of existing resources, and 'Viewing' refers to the display of resources.
This system works in two levels: Schema permissions and field permissions. The schema permissions establish minimum requirements that apply to all fields. Field permissions can be used to provide additional restrictions for specific fields beyond what the schema requires. Note that for each field, CWIS first evaluates the schema permissions and only if those requirements are satisfied does it proceed to check the field permissions.
For your reference, schema permissions are repeated on the Editing page for each metadata field, along with an 'edit' button to modify the schema permissions. Any changes to schema permissions will apply to all fields, not just to the field you were editing when the 'edit' button was clicked.
Each authoring/editing/viewing permission is made up of a series of conditions, combined with a logical operator, which must be satisfied to perform the corresponding action. Each condition may be either a check against resource field values, a check of user privilege flags, or a condition subgroup containing its own logical operator. Conditions that check resource field values are skipped in contexts where there is no one specific resource that can provide values to use in the condition. For example, on the Advanced Search page, no resources are displayed at all, and so a condition like "Language is English" will be skipped because it does not have any one specific resource to look at to decide if the Language field is in fact "English".
There is also a special 'Checking resource' condition, which is true when permissions are being evaluated for an individual resource (e.g., on the Full Record page) and false when they are being evaluated without a resource to provide field values (e.g., on the Advanced Search page).
An examination of the default Viewing permissions illustrates how the system works:
Top level logic: OR | Conditions will all be ORed together (satisfying any one of them is sufficient to satisfy the requirements). |
Current user has Master Resource Administrator privilege | All users having 'Master Resource Administrator' are able to view all fields, unless the field specifies further restrictions. |
Release Flag is true | All fields on any resource marked as released should be viewable, unless the field specifies further restrictions. Note that this check is skipped when there is not a specific resource to check (e.g., on the Advanced Search page). |
Checking Resource is false | By default, we should also display all fields on any page that doesn't refer to any one specific resource (e.g., Advanced Search). |
( Top level logic: AND | Begin a new privilege subgroup where conditions are ANDed together (all conditions are required in order to satisfy the subgroup). This subgroup allows all users having Personal Resource Administrator to view any field on resources for which their user account is the value of the 'Added By Id' metadata field. |
Current user has Personal Resource Administrator privilege | |
Added By Id is Current User | |
) | End the privilege subgroup. |
Suppose you manage a collection to be used for both public resources and private instructional materials. There are two kinds of private instructional materials, assignments and answer keys, along with three kinds of users: students, teaching assistants, and instructors. Students should only be able to view the assignments, teaching assistants should be able to view both types, and instructors should be able to edit answer keys and assignments but not public resources.
To accomplish this, you'll first create Custom Privilege Flags for each of your three user types. Then, you'll use Edit Option Lists to update Resource Type to include your material types (i.e. assignment and answer key) along with 'Public'.
Then, configure the following Schema-level viewing privileges:
The corresponding schema-level editing privileges would then be: