Record level access

Application Administrators will find more about the following in the Axiell Designer Help:

The Axiell Collections access rights and permissions model is comprehensive and granular and access rights can be assigned to individual fields, records and data sourcesClosed The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on., as well as to functions such as record creation, editing and deletion. The model is based on roles (also called user groups), and an unlimited number of roles can be configured in the application. Roles can be linked to almost any part of Axiell Collections, both to database components (up to individual fields and records) and to functions such as record creation and editing, deletion of records, location management and reporting.

The Standard Model (Model Application 6.0) introduces a user management model out-of-the-box with a base set of predefined roles / groups and permissions governing access to advanced and administrator functionality, as well as access to fields containing sensitive data and personally identifiable information (PII), such as personal address fields and email fields.

All new implementations of Axiell Collections now include the standard permissions model with groups such as the Data reader (able to view records in most data sourcesClosed The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. but not edit them), the Data writer (able to view and edit records in most data sources), and Data administrator (with super-user access). Where appropriate, the base set of permissions has already been applied to application objects; for example, the source.email (se) field in acquisition.inf already has read access rights for the PII reader group, write access for the PII writer group, full access for the Data administrator and no access rights for everybody else.

This approach simplifies the permissions model, tightens security by requiring users to be a member of at least one predefined role in order to access Axiell Collections, and eliminates the need to build a permissions model from the ground up as has been the case in the past.

More details about the permissions model in the Standard Model can be found here.

The access rights system is typically managed by an Application Administrator using Axiell DesignerClosed A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc. to specify who is assigned to what role and what data and functions a user / group has access to.

Tip: You can check which role or roles have been assigned to you from the Main menu by selecting Account>Information.

It is worth emphasising that it is generally unnecessary to assign access rights at the individual record level as the right to create, edit and view records is controlled by the permissions assigned to a group / role: if you are a member of Group A, you can view records but not edit them; if you are a member of Group B, you have full access rights to all records, and so on.

However there may be good reason to assign record level access permissions, and authorized users are able to do so within Collections itself (and subject to the permissions set by Application Administrators in Axiell Designer).

Note: Administrators with access to Axiell DesignerClosed A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc. are able to assign permissions at all levels of the Collections system (from individual fields to entire data sources) and the decisions they make when configuring permissions can impact the expected behaviour of record level access permissions.

Authorized users are:

  • the record's owner, named in Owner (record_access.owner (OW)) on the Management details panel (called Notes and description control in the Archives catalogue and Accessions data sources); and
  • users assigned to the $ADMIN role.

They assign access permissions to the current recordClosed The record currently displayed in Record details View or highlighted (with a solid background) in Result set View or Gallery View for instance. on the Management details panel. Here we see the panel in the Catalogue in the Standard Model:

Management details - Standard Model

Note: It is also possible on the Management details panel to specify whether the record is publicly discoverable and whether it is read only (full details about the panel can be found here).

Introduced with the Standard Model, the Read only (record.read_only (zz)) checkbox is used to make a record read-only, allowing it to be read but no longer edited.

In most data sourcesClosed The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on., the Read only checkbox is found on the Management details panel (typically under a Record access heading):

In some data sources (Archives catalogue and Accessions for instance) it is found on a Notes and description control panel:

You would mark a record as read-only when a final record Status (current_status (sS)) has been assigned and there is no longer a reason to alter it: records for a past exhibition, deaccessioned objects, cancelled acquisitions, and the like.

Once a record has been marked as read-only it can only be edited by Application Administrators (anyone with $ADMIN access); for everyone else a message will pop-up indicating that the record cannot be edited. For Application Administrators a pop-up will give them the option to re-enable editing of the record:

Tip: A response must be provided within 10 seconds (a count down is shown in the No button); if a response is not provided, the pop-up disappears and the record remains uneditable.

Record level access permissions provide control over who can do what to a record on a per user / group basis. For the user / group named in User / group, four access rights can be assigned in the Rights drop list:

Management details

User / group and Rights are repeatable, making it possible to add permissions for multiple users / groups:

  1. Enter the name of a user / group, e.g. Data reader, in User / group.
  2. Select the appropriate permission from the Rights drop list.
  3. Save the record to apply the record level access permission(s).

Field

Details

User / group / record_access.user (UR)

Text field. Enter the name of a user / group, e.g. Data reader.

Note: The name must be entered exactly as specified in Axiell DesignerClosed A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc. or Active Directory.

Rights / record_access.rights (RQ)

Drop list. Select the access right to be assigned to the user / group. Options include:

None

The record will not be discoverable by the user / group.

Read

The record is discoverable by the user / group but it cannot be edited or deleted.

Write

The record is discoverable by the user / group and it can be edited but not deleted.

Full

The record is discoverable by the user / group, it can be edited, and deleted.

When a user is member of a group, it is not possible to assign record level permissions to the user that are greater than those assigned to their group: it is only possible to take away permissions.

For example, if user Fred is member of the Data reader group, which is able to read records but not edit them, it is not possible to assign user Fred the Write permission. You could however assign the None permission, effectively hiding the record from user Fred.