Component Security - jlbcontrols/Flintium GitHub Wiki

User input components can be enabled or disabled based on the current user's role. This is a familiar concept in Ignition, and Flintium has a standard way of implementing it. All user input is handled by custom templates instead of built-in components. For instance, instead of using a regular checkbox, a template called "StdCheckbox" is used. The input templates include logic to enable/disable based on the user's roles.

Two types of roles are required: an employee type role (permission based on the type of employee), and an area role (user permission for a specific area).

Employee Type Role Requirement

Each user input template has a dataset property called "componentRoles" that specifies which employee type roles may provide input. In general, this is bound to a property on its parent faceplate, called "componentRoles0". Most components on a given faceplate require the same roles, so this provides a common location to specify them. If a faceplate panel contains components that accept different sets of roles, another property is added to the faceplate called "componentRoles1".

Area Role Requirement

The area role is read from the UDT instance for the device faceplate that is being used (which references the Cfg_Area tag for the underlying Logix AOI). The user must be a member of the specified area role to provide input.

Role Logic

Role logic is placed in a project script so that it may be changed easily, project wide. Each input component calls the function:

flintiumscripts.security.isAllowed(instancePath,componentRoles)

which simply returns a boolean to signal if user passes component security. Flintium's standard implementation of isAllowed uses the instancePath to read an area tag, which must be one of the user's roles, and also checks if any of the user's roles matches any of the componentRoles.