UX in Security tool

What UX options are in the Security tool? Our foundation IBM® TRIRIGA® Security Manager enables you to define security groups, where a "group identifies a set of user IDs and the access that the group has to records and what can be done with the records". You can also take advantage of predefined IBM TRIRIGA security groups. Within this foundation tool, you can select a UX option such as the Models option.

Contents

I. Models

To support our UX framework, you can open the Models tree from a security group, and assign permissions to a UX model. In effect, a user will inherit the model permissions from all of the security groups to which that user belongs. Also, the permissions for a model will apply to all of the data sources associated with that model.

II. Model access

Here are the basic steps to define Models access for a group:

  • Open the Security Manager tool.

  • Open a security group. Select the Access tab.

  • ​Select the Access Configuration sub-tab.

  • In the Object panel, expand the Models node. Select the model.

  • Select the permissions for model access and model action access.

  • Save the security group.

For convenience, the Access tab has an Access Summary sub-tab that lists all of the available permissions for the security group. The Access Controls panel lists the permissions for tools, modules, and forms, while the UX Model Access Controls panel lists the permissions for UX models.

a. Security Manager > Group > Access Configuration sub-tab

Security Manager > Group > Access Configuration sub-tab

b. Security Manager > Group > Access Summary sub-tab

Security Manager > Group > Access Summary sub-tab

III. Model permission

Our foundation TRIRIGA Security Manager operates on the database table APP_OBJECT_PERMISSION which stores TRIRIGA module-level and form-level permissions. But as part of the UX framework, the System module introduces a triModelPermission business object which will store instance-level permissions for each individual UX model.

If a permission record exists for a security group on a model, and the triServiceIdNU field value is not equal to 1 (No Access), then the group has access to the model. Otherwise, if the triServiceIdNU field value equals 1 (No Access), or no permission record exists, then the group has no access.

If a permission record exists for a security group on a model action, then the group has access to the model action. Otherwise, if no permission record exists, then the group has no access to the model action.

a. Definition of triModelPermission BO

Field Description
triModelIdNU Integer. This field points to the model to which permission is assigned. It contains the model ID, which is the SPEC_ID field value from the related T_TRIMODELMETA table.
triActionIdNU Integer. This field points to the model action to which permission is assigned. It contains the action ID, which is the SPEC_ID field value from the related T_TRIDSACTIONMETA table. If its field value is blank, the permission is applied to the model, not an action.
triGroupIdNU Integer. This field points to the security group to which permission is assigned. It contains the group ID, which is the SPEC_ID field value from the related T_GROUP table.
triServiceIdNU

Integer. This field defines the access level for the model. It uses the same SERVICE_ID field values from the APP_OBJECT_PERMISSION table:

  • 1 – No Access
  • 10 – Read
  • 20 – Read and Update
  • 30 – Read, Update and Create
  • 40 – Read, Update, Create and Delete

Its field value is blank, if ACTION_ID is not blank.
triCreatedDateTimeSY System Read-Only. This field shows the date and time when this permission was created.
triCreatedBySY System Read-Only. This field shows the ID of the user who created this permission.
triModifiedDateTimeSY System Read-Only. This field shows the date and time when this permission was last modified.
triModifiedBySY System Read-Only. This field shows the ID of the user who last modified this permission.