Creating a Role
As mentioned in the Concepts section, the security roles are defined in the designer and not in the application itself. The security roles are static parts of the application, and only the selection of roles in each user record should change frequently.
To create a new role, go to WorkflowFirst, select your application record and drilldown to the 'Roles' list (using the hamburger icon). There click '+' or 'Create New':
The Name and Description of the role should describe the security role.
You can also set the 'Is Default' field. If you set this to 'Yes' then it will be added automatically to all users in the system, except those that are administrators.
Below that click 'add Permissions' to add and attach a permission to the role. Any number of permissions can be added to a role.
Each permission defines access to a specific area of the data model. The following fields can be entered:
Specify the field definition within the data model that this permission applies to.
Apply to Sub-Types
Indicates whether this permission will also apply to all descendents of the selected field in the data model.
An optional, advanced option. Allows an XPath to be specified instead of selecting the field. This allows for more advanced options, such as specifying something like “*/TypeName” to specify all areas of the data model using the specified type name. You can also enter in paths of specific records in here, if the XPath to that record is known. This allows permissions to be set up that are specific to existing records in the database.
Allow / Deny
Each permission either enables or disables the specified access. This entry indicates whether this permission will allow (enable) or deny (disable) the given access.
For example this permission may deny deletes. In that case this will be set to 'Deny' and 'Delete' will be set to 'Yes', meaning that the permission affects deletes, and it should deny them.
Indicates if this permission action (or allowing or denying access) refers to viewing records.
Indicates if this permission action (or allowing or denying access) refers to changing (updating) records.
Indicates if this permission action (or allowing or denying access) refers to creating new records.
Indicates if this permission action (or allowing or denying access) refers to deleting existing records.
Indicates if this permission action (or allowing or denying access) refers to allowing write access to records the current user created. (Note: In WorkflowFirst v1.0 this is not supported).
Approval Workflow Exclusion
Indicates if this permission refers to the approval workflow exclusion. By default all users are excluded from approval workflow, meaning they can freely change the database without having to get approval from another user. However by denying the approval workflow exclusion, this means that the user no longer has free access and all changes with this permission applied will be routed through the user group that has workflow governance over the area being changed. If no group has governance, the change goes through directly.
Enables applying a read filter to all requests in this area of the data model, so that only results with this filter applied will ever be returned for users with this permission active. This can be used to restrict access to a specific user area, for example. The Filter Field specifies the field name that will be used in the filter that will be applied. The field can also include field tags, of the form Field:tagName, such that all fields with the same tag name will be OR'd in the filter. Fields can also include sub-fields (also referred to as sub-refs) of the form Field/SubField, to only show records that have at least one sub-list entry with the specified field and value.
If filtering is employed, specifies the value to filter with.
As an alternative to Value above, you can specify certain calculated expressions in here. Currently the expression value must be either 'UserID', which gets the ID of the user record and applies that to the value, or the name of any field in the User record, which will be retrieved from the currently logged-in user. You can also specify * to refer to the path of the user record (for links), and Today() to refer to the current date.
For more information on filter permissions, see the next section.
Next Topic: Restricting Individual Record ...
Up Since 2/15/2019 12:59:20 PM