The following table shows how different combinations of field security and field visibility affect On-Screen Rules and Workflow processing.
The answer to all three questions will be the same so this column gives the answer that can be applied to all. Note that a particular rule action that does not run will not prevent other rule actions from running successfully in the same rule.
- Field 'Permission' Property – The field property called Permissions with possible values Required(R), Optional(O), Read Only(RO), and Hidden(H)
- Role Permission – The field permission setting on the user's Container Role with possible values View(V), Edit(E), and No(N)
- On Form – Whether or not the Administrator puts the field on the form
- Hidden by Rule – Whether or not there is an On-Screen Rule that hides the field
- Visible? – Whether or not the field is visible to the user
- Does Rule Run? – Answers the questions:
- Will the rule run if the field is part of the criteria of the rule?”
- If the field is part of a rule action, will the field be saved to the database?
- If the field is part of the defining criteria of a workflow, will it enforce the workflow on screen?
The following scenarios can help provide additional understanding of how to fix On-Screen Rules or Workflows that might not be working as intended after upgrading FootPrints.
|Field 'Permission' Property||Role Permission||On Form||Hidden By Rule||Visible?||Does Rule Run?|
- A Workflow uses 'Status' as the State field with choices [1, 2, 3, 4] and is linear (that is, start->1->2->3->4->end).
- It has a defining criteria based on field Department='IT'.
- User 'Customer1' has role permission for field 'Department' set to 'No'.
- User 'Agent1' has role permission for field 'Department' set to 'Yes'.
- User 'Agent1' creates the ticket, sets field Department='IT'
- Workflow is applied and only one choice is available in field Status, '1'. Ticket is saved.
- Then user with permissions for all fields edits it and changes Status to '2'.
- User ‘Customer1’ needs to edit the ticket. When he opens the 'Status' field shows full list of choices despite the applied workflow. If user tries to save ticket with a transition not allowed by workflow the system shows an error and lets them know that only 2 or 3 are valid Status values.
The value of the 'Department' field is sent to the browser only for users that have their Role Permission for this field set to 'Edit' or 'View'. If 'Customer1' has either of these Role Permissions, he/she will be able to see all possible choices for 'Status'. When 'Customer1' saves the ticket, Workflow is applied on the server but only values '2' or '3' will be allowed according to the Workflow configuration.
- Set field 'Department' available to 'View' for roles for which to allow Workflow on screen.
- Avoid building workflow criteria on fields that are not allowed for all roles. Note: The 'Department' field could be hidden in the Customer form via the field property "Permission" but its value will not be secured, just hidden from view.
- An On-Screen Rule is based on 'Priority'=Critical and 'Notify Manager'=Yes with an action to display a message on the informing the user to notify their manager.
- Nobody should see the 'Notify Manager' field as it is only a placeholder for this rule and is set by some other After Save rule.
- Agent1 has access no Access to this field via their Role permission.
In 12.1.02, Agent1 would see the message once they set the Priority to Critical. In 12.1.03, they will not see the message as the rule will not run because it has no access to the 'Notify Manager' field.
- If the desire is to not allow any user to see or update the field 'Notify Manager', then set the field's property permission to 'Hidden' and its Role Permission to 'View'. The user still will not see it, but the data will be available to the rule.
- If the desire is to allow Agents to see or edit the field but not allow Customer users to see it...
- Set the field property permission to something other than ‘Hidden’
- Set all customer roles to view
- Set all agent roles to view or edit.
- Use an On Page Load rule to hide these fields from Customer users. The rule will run correctly since the data will be available at the browser.
- There is currently no solution for On-Screen Rules to run correctly if the desire is to secure access to the field’s data for some users but allow others view it and/or modify it.
How to detect if On-Screen Rules are not working correctly
- An On-Screen Rule is set with an action to set the 'Priority' field to Critical if the 'Impact' and 'Urgency' are set to 'High'.
- Customer1 has his/her Role Permission for the 'Priority' field defined as 'View' or 'No'.
If the user has 'View' access, the value of the field will be available for display and for On-Screen Rules to use it. The On-Screen Rule will not be able to save changes to the value for 'Priority' because the user Role has insufficient rights to do so.
- Set Customer1's Role Permission for the 'Priority' field to 'Edit' and hide the field using an On Page Load rule or by setting the field property on the form to 'Hidden'. This way the rule will set the value without the user seeing it.
- Use an after save rule to set the value.
To detect if On-Screen Rules are affected by a change in Role Permissions, temporarily enable the sending of browser client errors to the FootPrints application log in:
On-Screen Rules that have configurations that leverage fields with restricted access will generate error log entries if they could not execute successfully.
-> System Management
-> Server Configuration
-> Logging Configuration
-> Send browser errors to the server log.
Example error log entry:
- |CLIENT||User 'agent1' encountered error|
The On-Screen Rule [Rule Name] ID=27679 was not fully applied to the record [New Ticket] ID=0 because the user [agent1] ID=303 does not have permission to access the field [custom_field_11] ID=27657|