Online Software Help Manual

BookmarkIndexPrint
Contents
Display Legacy Contents

Data Access Control

Data Access Control represents the other fundamental part of the softwares security system. Permission schemes and data access control allow full control over the users options to use and access the software and the data handled with it. Permission schemes handle the access control to the applications commands and menus, whereas data access control handles the users rights to view, copy, modify and delete the data used in the application. Similar to the permission schemes the access control for the data is organized in levels - the so called "roles", which allow the assignment of access rights to the users. Data access roles are designed to be hierarchical, granting only a few rights to the lowest level (role) and full rights to the highest level (role).

Data Access Control works best for data contained in projects.
The applications project format is ideal for handling data in a data access control environment. Single spectra and data from libraries may also be signed/used in a data access control context but exporting/converting to other formats will remove the data access control settings from the object.

Data Access Roles

The data access roles will be set up by using the Data Access Control Wizard which may be invoked automatically after the initial security setup or manually by selecting the command "Setup Data Access Roles" in the Security Menu. The administrator of the software may create any number of roles but the software initially defaults to 4 access roles. An overview is most easily given by an excerpt of the Data Access Role Manager which guides the administrator in setting up the access control system:

This picture nicely demonstrates the four hierarchically organized access roles. The default role names reflect the roles position in the hierarchy. The supervisor role has complete control of all data, the chemist may not delete data, the operator may only view data and the guest has no rights at all.

All roles are subordinate roles to the top-level role. Because of this individual access rights for a user to an object may differ depending on the "highest" role signature the data object was signed with. The above picture represents the access rights for an object that was signed with the top-level role, the "Supervisor" role. If an object has not been signed by a superior role yet, the access rights may differ. This is illustrated by the access rights view for the "Operator" role:

As long as the object is signed with the "Operator" role as the highest role the user may also copy/modify spectra and projects.  After signing the object with a role superior to the "Operator" role, these rights will be revoked as can be seen in the first picture. This system represents the general "bottom to top" workflow (the operator records a spectrum and passes it on to the chemist/supervisor) as well as the "top to bottom" access hierarchy.

The administrator may completely customize the role names, the number of roles and the individual access rights. This may be done with the Data Access Control Wizard or the command "Edit Data Access Roles" in the Security Menu.

Role Signature

Simply assigning a role to a user will not affect his access rights to regular data objects that have not yet been signed. The actual data access control starts with signing an object which will "tag" the object with the users role. This is done by opening the object and selecting the command "Sign Object" from the Tools menu. The object now resides on the access level corresponding to the signing role. Higher levels may now still have full access, where as lower level will have very limited access. Signing an object usually prepares it to be moved to the next higher level of the hierarchy. This can be illustrated by a simple workflow:

  1. The operator records a spectrum and prepares it for the further workflow. He will sign the spectrum to "approve" it for the next level.

  2. The chemist checks the spectrum and maybe modifies it further. He will sign the spectrum to "approve" it for the next level. This will revoke the copy and modify rights for the lower "Operator" level and will prepare it to be processed by the higher levels.

  3. The spectrum will be processed by the next higher level and so on...

Signatures are always permanent and can not be revoked. If, for any reason, a lower level role needs to have access rights again that have been revoked by a higher signature, the object needs to be released from the normal data access hierarchy by a "release signature". This will remove any data access restrictions from the object.

Signatures are permanent and can not be removed!
Once a signature has been issued it is permanent and can not be removed from the object again! If a lower level access - which normally would be prevented by a higher level signature - needs to be enabled again, the object has to be released from the data access hierarchy by a release signature.

Signature Comments

The actual signature can be accompanied by a signature comment to express workflow related information. In the default setup for example, the operator may choose between the comment "Accepted" or "Measurement failed" when signing objects. All signature comments may be customized by using the command "Manage Signatures" from the Security Menu.