Who is this article for?

Ideagen EHSQ Enterprise or Decani Admins or Module Developers

A Module Developer license and Area access is required to change configuration settings.

An object gathers information from various modules by utilizing the rules and field behaviors settings. These settings determine how data is collected and organized, ensuring that the information presented is exactly what a user requires to successfully complete an assignment. 

Objects are also referred to as a record within a solution. This terminology emphasizes their role as individual entries or units of data that exist within the broader system, each representing a specific piece of information or a particular instance within the solution.

Record Access Control (RAC) rules govern who is eligible to see an object. These custom rules determine a list of persons or teams with access, and all others will be denied access.

To learn more about RAC configuration see the Module Developer Guide.

RCA Capabilities

RCA helps to maintain flexibility and control over record access without compromising data security. Some additional features include: 

• Access to individual records with a custom access list (e.g., those with a "need to know")
• Populate access lists with people and groups either automatically or manually
• Add or remove record access and update the restrictions within minutes
• Define custom text to show the access/security level of the record (e.g., "Official Use Only", "Confidential", etc.)
• Display custom access-level text on-screen, including on the open record, printed PDF's, and on reports
• Automatically include all assigned users in the access list
• Optionally, provide record access to all users who have certain roles
• Optionally, provide record access to all alternates of all users who have access
• Record access includes searching for and viewing records - existing field visibility and editing controls are not affected

The Classic UI My Assignments Folder
Please note that the My Assignments link, within the Assignments folder on the Dashboard panel, does not show any data from modules with access control rules defined, to avoid showing potentially sensitive data to users. In that case, an information message appears suggesting that users should instead use the standard Search feature. The My Assignments link has been deprecated in Miramar and replaced with standard grid searches.

RAC Dataset Support

RAC rules support Datasets but not out-of-the-box. A module developer must make the following changes:

1. The USE_ACCESS_CONTROL_IN_DATASETS Feature Flag needs to be enabled for each subscriber area
2. Regenerate module's views, to add the _AccessControlWhitelist column
3. Add a field to the Dataset called _AccessControlWhitelist that contains the data in that column (new Datasets will automatically have this column if the Feature Flag specified in (1.) is enabled)
4. Add a _ClassifiedInformationLabel field to the Dataset, to see the red text on search results that marks something as "Official Use Only" or "Confidential", for example

With those changes in place, the usual Record Access Control restrictions will apply to the data in the dataset.

RAC Frequently Asked Questions

1. What is meant by “Access” to a record? Access means being able to search for and open a solutions, even when it is not assigned to you.

2. As a module builder, do I have to do anything if I don't want to use record access control? No, by default, the role property that drives access control (Access all objects) is automatically checked for every role, meaning that all users will have the access they need by default. If, for a role, you need to remove the role property that allows that role to Access all objects, you may remove it as needed and it will behave as it always has, which is to allow users to have access to anything they are or have been assigned to.

3. When is the access list fed into the database and the search engine? On Save (or Complete). When changes are made to the access list (or it is first created), the record must be saved before the changes can be committed to the database and fed through the search engine.

4. Will access control settings stop a record from being manually or automatically assigned to someone who does not have access? No, records will only fail in workflow due to a user not having a role or reporting authority that would give them access. If the configuration did not anticipate it, it would be possible for someone to receive an assignment for a record they are not authorized to access (along with getting assignment emails with data they should not see).

5. Could someone potentially access a record who is not in the access list? Yes. Using the Allow alternates to access objects role property would give access to all alternates of every person in the access list. This could be difficult to track down.

6. Will access control allow assignment of records across Reporting Authorities (RAs), meaning to a user without the RA the record is in? No, access control only works within the existing RA structure. It would be possible for a user to be in the access list and still not have access if they do not have the correct RA.

7. Is it possible for a situation to occur where no users have access and a record is inaccessible? Yes, assuming an access list with entries for only Persons and/or Teams, if the rules associated with the entries are TRUE, but the DXL expressions return no valid PersonIDs or TeamIDs, then no one with those restricted roles would have access. Further assume there are only restricted roles. In this case no users would have access.

8. Is it possible to have an access list set up without anyone in it and for users to still have access? Yes. Assuming an access list with entries for only Persons and/or Teams, if the rules associated with the entries are FALSE, the record would still be accessible to all assignees.

9. Access Control has many nuances. What do you suggest to customers who want to use it? They should use it. Maintaining simplicity in the setup is helpful to avoiding issues. They should be aware of the nuances and, if possible, set up access-specific test scripts to support their internal SQA process.

10. If a user has a role that allows them to access all objects then there is no need to use access control as they can already see everything. Isn't that true? You would only use this to allow users to see what that currently can't see, correct? Correct. You can use it to grant access to those who currently can't access it and who have a need to know.

11. As a customer I don't have data security requirements that would cause me to use this, but for one application I do want to grant access to users to certain categories of items (e.g. one user wants to be able to see records related to "Equipment" and wants to be granted access by an admin). Can I use record access control for that? Yes. While access control is specifically a security feature, it can be used for granting people who "need to know" access to records one-by-one or en masse (whether someone has a "need to know" is often a judgement call made by someone of proper authority). In fact, it is specifically designed to meet this need. It can also be used to segregate records between groups (e.g. Group A does not want other groups to have access to Group A records). Again, use of record access control can have far-reaching implications, so it should only be used when there is a strong business case and only after thorough testing.

Object Permission Table: When testing access rules, it’s more efficient to reference the access list stored within the Object Permission table (e.g., vXXXX_ObjectPermission) as opposed to logging in and out of the system.

• Effective Date and Expiration Date: These columns in the Object Permission table indicate when the access rules have been applied to the object and when the access rules have been removed. If the Expiration Date is blank, then this means that the access rule is still applied to the object and the Person/Team still can view the record but if the Expiration Date is populated, then the Person/Team can no longer view the record.

• All Assignees, Person and Teams Access Types: These access types will populate the PersonID and TeamID columns in the Object Permission table. If either column has a -2 then this means that the DXL expression defined for the access rule returned NULL or was invalid.

  ObjectID verses Person or Team IDs

  The permission table is expecting PersonIDs or TeamIDs from an Access Expression and will not error when saving the module definition. If passed an ObjectID, the entry will not work. This condition is exposed in the query below when the PersonID or TeamID has a value (the ObjectID) but can't find a matching Person or TeamName on the join.

• All Access Type: For this access type, both the PersonID and TeamID columns will be blank in the Object Permission table.

The following query can be used in Query Builder to view the current permissions of an object where XXXX is the Subscriber prefix, and ####### is the ObjectID of the record.

SELECT OP.ObjectPermissionID, 
    OP.PersonID as PersonID, 
    P.LoginID as Person, 
    OP.TeamID as TeamID, 
    T.Name as TeamName, 
    OP.EffectiveDate, 
    OP.ExpirationDate
FROM vXXXX_ObjectPermission OP
    LEFT JOIN vXXXX_TEAM T
    ON T.TeamID = OP.TeamID
    LEFT JOIN vXXXX_Person P
    ON P.PersonID = OP.PersonID
WHERE OP.ObjectID = #######

RAC and Reporting Authority Rules

It is important to understand the relationship between Record Access Control rules and Reporting Authorities rules. 

Record Access Control rules only operate within the context of the record's reporting authority. 

What this means is that, when it comes to accessing a certain record, the logged in user's Reporting Authority takes precedence in determining access. Although a user may have a valid role to access a record and record access control settings would otherwise allow their access, if they do not have a reporting authority for that record their access would be blocked.

For additional access and security information visit Getting started with security.