Data access security process

In this topic ShowHide

About this help page

This help page explains how the system applies the data security access defined in a User record to display core records to a user.

User level and data access security

You can control access to specific types of records in RME core by defining data access security in the user's record. This is not applicable for a Connection User account.

In a User record, you assign data security access in a tiered configuration at the following levels.

1) Administrative Organisational Unit (AOU):

• All Level User to provide access to records from all Org. Unit regardless of role  - usually for RME Administrators and Research Office members

    OR

• User Org. Units related item, to define access to records based on the user's organisation unit/s, which includes its child units

2) Filter records by one or more defined codes in separate related items:

Significant Events can also be filtered for Roles. See Role Significant Event Access

Exception

A Connection Account is an account that is used for external services, such as APIs, feeders or integration services, by IT system administrators when installing or maintaining RME or running scheduled tasks. This type of User account cannot log into RME via the front-end user interface. It is designed to connect in the back-end for these types of services. As such, data access security is not applicable.

For eForm template and report access security, see: eForm access and permissions and Report access security process.

How the system determines what core records to display

When a user logs into the RME, the pages they can see is controlled by Page Views that are assigned to them. For example, to be able to view the Projects search page in the Projects module, the user would need to be assigned the Page View for PRO001.

Page Views are commonly assigned to a role in the User Role Allocation related item. A role in RME is like a template with a set of defined Page Views, eForm templates, reports, and core Significant Events to suit a user profile or position, such as an Ethics Admin or Research Output Data Entry. Some system roles have been set up for you ready to use based on common positions used in institutions.

In some rare cases, Page Views can be assigned to a user directly in the User record, User Page Views related item but as this requires more maintenance it is not recommended as a common method. If the User record also has one or more defined roles, these additional Page Views will be added to the Page Views already defined for the role/s.

When a user searches for records in RME, the system goes through a process in the background to determine the records to display to the user. There are two branches in this process based on the setting in the All Level User? field in the User record.

If All Level User? = Yes, go to All Level User record access process

If All Level User? = No, go to Non All Level User record access process

a) All Level User record access process

These steps apply when the All Level User? field in the User record is Yes.

1.     The system includes records for all organisational units. This is what All Level User means.

2.     It checks specific access based on codes defined in the access security related items for the user, and filters all the records collected in step 1 based on these:

•        Project Access Security

•        Ethics Category Access

•        Contract Access Security

•        Fund Scheme Access Security (applied when the user selects a Fund Scheme lookup in any relevant module)
All Level Users always have access to fund schemes they created, including fund schemes with an Activity Type that is blank or Not Specified.

If a user has not been given access to a defined code, such as a particular Project Type code, records with this code will be filtered out and the user will not see them in search results or be able to access them. In dropdowns, the item for the code will not appear in the list for selection.

3.     It then adds any records that the user created to the filtered records from step 2.

4.     It adds any records that the user is linked to, for example, as a supervisor.

5.     The search results include records that match the user's search criteria, filtered by the process above.

b) Non All Level User record access process

These steps apply when the All Level User? field in the User record is  No.

1.     The system checks the Org. Units the user is linked to, as defined in the User Org. Units related item in the User record. It only includes records that match the user's Org. Unit or a child of the user's Org. Unit/s.
If no Org. Unit is linked, it will move on to step 2.

2.     It checks specific access based on codes defined in the access security related items for the user, and filters all the records collected in step 1 based on these:

•        Project Access Security

•        Ethics Category Access

•        Contract Access Security

If a user has not been given access to a defined code, such as a particular Project Type code, records with this code will be filtered out and the user will not see them in search results or be able to access them. In dropdowns, the item for the code will not appear in the list for selection.

3.     It then adds any records that the user created to the filtered records from step 2.

4.     It adds any records that the user is linked to, for example, as a supervisor.

5.     It checks access based on fund scheme Activity Type defined in the Fund Scheme Access Security (applied when the user selects a Fund Scheme lookup in any relevant module) for the user. It filters all the records collected thus far based on these. It will not include fund schemes with the Activity Type of blank or Not Specified.  

If the user's access to a particular fund scheme Activity Type is removed, the user will not be able to access Fund Scheme records they created. This is a unique rule applied to non-All Level Users only.

6.     The search results include records that match the user's search criteria, filtered by the process above.

Click to view or hide: Process diagram - how RME determines what records to display to a user

Data_access_security_process.htm