Mass Maintenance

Incorporate the Security View into Request Processing

This section provides an example of implementation of Org Units.

NOTE: Org Units should only be used by advanced users, such as Syniti Consultants, who are familiar with Stewardship Tier Development.

NOTE: If the data entry table does not exist when the template is generated, the security view will not be automatically generated. This situation can occur when the template is a custom template with custom data entry pages.

NOTE: If the value entered in TEMPLATE COLUMN on the Template (Org Units) page does not exactly match a column in the data entry table, that Org Unit will be excluded from the generated security view. To add the Org Unit, the security view will have to be manually modified to include a join from the TemplateColumn name in the Org Unit table to the appropriate column in the data entry table.

Once a request with Org Units has been saved, there is no automatic connection between the Org Unit security and request data on the Data Entry pages. This connection must be made manually behind the scenes by a Template Administrator as described in this section.

A Template Administrator must modify the horizontal view for Data Entry page(s) so that only users with security for the record (as in, only users who are assigned to the Org Unit Values that are used on the request) can see the record on the Data Entry page.

NOTE: For requests with Org Units that use a mass change, if the Horizontal View of the Data Entry page has been modified to include the security view and boaUserID, only the records to which the user has access will be updated when mass change is executed.

The horizontal view contains only the Data Entry table. Add the security view and join on RequestID and ID, as in the example below. Select boaUserID for output.

 

Security can be further customized so that users can only edit and delete records for which they have security; others will be visible but will not allow updates.

To further customize security:

  1. The delivered DCV views do not include boaUserID, so both ttUserTemplateRole and the security view must be added to the delivered DCV. Note the outer joins in the example below.
  2. Select ttUserTemplateRole.UserID and alias as "boaUserID."
  3. Modify delivered boaEdit logic to take into account the security view. See the example below.
  4. Add boaDelete logic. See the example below.

 

To modify boalogic as mentioned in step 3 above:

 

ISNULL((SELECT 0 AS Expr1 WHERE (dbo.ttChangeMaterial.LockReject = 1) AND (cMass.dbo.ttTemplateRole.RoleType = 'Review')), 1) * ISNULL((SELECT 0 AS Expr1 WHERE (dbo.webChangeMaterial1SecuritySel.boaUserID IS NULL)), 1) as boaEdit

 

To add boalogic delete logic as mentioned in step 4 above:

:

ISNULL((SELECT 0 AS Expr1 WHERE (dbo.webChangeMaterial1SecuritySel.boaUserID IS NULL)), 1) as boaDelete

Once these changes have been made, subsequent requests submitted for the template will follow the security settings configured here.

Refer to Updates to Finishing a Data Role for Templates with the Security View and Add the Org Unit Security View to Template Role Validation Rules for more information.

Add the Org Unit Security View to Template Role Validation Rules

Role validations allow for template-specific data standards to be applied at both the role and the request level. Mass Maintenance runs validations registered for roles when a user assigned to that role enters a record for the request, or when a user clicks Validate for a role on the Request (Roles) page.

NOTE: Role validations are views stored in a data source, typically the cMass_Data database. The view must exist before the role validation can be added to the template.

Adding the Org Unit security view to template role validation rules is not required for Org Units to work, but is required if a template uses template role validation rules.

A Template Administrator must add the security view to a Template Role validation rule so that Org Unit security can then restrict validation failures to records associated with Org Unit Values, and users will only see validation failures for records they can access. 

For example, a template with Org Units assigned has two users with two different Org Unit Values assigned. User A is assigned to Plant A. User B is assigned to Plant B.

A Template Administrator adds a Template Role validation rule to the template and adds the Org Unit security view to that validation rule.

If a record with data from Org Unit value Plant A fails the validation rule, User A will see the validation failure and User B will not.

If the Template Administrator had not added the security view to the Template Role validation view, User A and User B would both have seen the failure, even though User B did not have access to the record that caused the failure.

Updates to Finishing a Data Role for Templates with the Security View

The Data role is finished differently if:

  • The template uses Org Units and

  • Users have been assigned to different Org Unit Values and

  • The Org Unit security view has been added to the template.

In this case, the Finish button will not dither and the Data role will not be finished until the Data role for all Org Unit Values has been finished. In other words, a user assigned to each Org Unit Value must finish the Data role for the request before the request can move to the Review role. Until this condition is met, the Finish button will be active.

For example, a template has the Org Unit North American Plants assigned. User A is assigned to Plant A. User B is assigned to Plant B. User C is assigned to Plant C and Plant D.

A Template Administrator adds the security view and boaUserID to the Horizontal View of the Data Entry pages, and creates a request based on the template. The Template Administrator reviews the Org Units assigned to the request, and removes the Org Unit Value Plant D from the request. Once the Org Units are confirmed, the request is active.

User A enters data manually for Plant A, then clicks Finish on the Request (Roles) page.

The Finish button remains active, and the Data role is not finished.

User B enters data and clicks Finish on theRequest (Roles) page.

The Finish button remains active, and the Data role is not finished.

User C enters data for Plant C and clicks Finish on the Request (Roles) page.

The Finish button is disabled, and the Data Role is finished. The request moves to the Review role.

NOTE: If a Template Administrator does not add the security view to the template, when a user clicks Finish for the Data role on the Request (Roles) page, all requests for all Data roles will be marked as finished and the request will move to the Review role. Continuing the example above, if the Template Administrator had not added the security view to the Horizontal View for the Data Entry pages, when User A clicks Finish on the Request (Roles) page, requests for Plant B and C would also be marked as finished and move to the Review role, even though User B and User C had not entered data for their Org Unit Values.

Org Unit Security in Action

Once the security view has been incorporated into request processing, Org Units can be used to restrict data on the Data Entry page and restrict which updates are performed in a mass change. Additionally, once the security view has been added to a Template Role validation rule (if the template uses validation rules), template role validation failures will be limited to records associated with the current user’s Org Unit values.

To understand how the security could work, consider this example.

A Template has the Org Units Plant and SalesOrg assigned.

Users have been assigned to the following Org Unit values for the template:

  • JSmith is assigned Plant A, SalesOrg 1, SalesOrg 2
  • HMartin is assigned Plant A, SalesOrg 2
  • RJones is assigned Plant A, SalesOrg 3

A user creates a request based on the template. The request is assigned the following Org Units and Org Unit values.

  • Plant A
  • SalesOrgs 1 & 2

Data records for the request are:

  • ID 1, Plant A, SalesOrg 1
  • ID 2, Plant A, SalesOrg 1
  • ID 3, Plant A, SalesOrg 2

After configuring security manually using the security view and updating the template role validation rule:

  • JSmith has security for record IDs 1, 2 & 3 and will see validation failures related to records from these Org Unit values. If JSmith performs a mass change, only records from these values will be updated.
  • HMartin has security for record ID 3 and will only see validation failures related to records from this Org Unit value. If HMartin performs a mass change, only records from this value will be updated.
  • RJones does not have security for any of the data records