Access Control

Access control provides a way for your organization to limit or classify record information by “plant,” varying work locations, or work functions. For example, you may have asset types that are only used at your northern location, so you would designate those asset types as restricted to that location. In the same way, you can leverage access control to prevent users in the southern location from accessing work orders related to the northern location (and vice versa). This is referred to as “row level security” in the application framework.

Each location represents an access group and objects in the application may be owned by a specific access group. Access groups are defined in the Access Group portal and are assigned to records as an Owning Organization.

Refer to Row Security in the Oracle Utilities Application Framework documentation for more information on data access roles and how they work with access groups.

Note: This functionality is optional and not enabled by default. If your implementation needs to restrict access by owning organization, you will need to explicitly enable it as described below.

The following points describe the functionality at a high level:

  • Some entities are directly secured by being assigned an owning organization value on the entity itself. For example, the work order entity is directly secured and therefore its owning organization field is populated.

  • Some entities are indirectly secured by association to another related entity that is directly secured. Entities secured this way are not assigned an owning organization. For example, work activities are secured indirectly by association to their work order. If a user is allowed to view a work order they are also allowed to view all its work activities. There is no owning organization data security for individual activities.

  • All other entities do not support this type of security. For example, operation and technical entities are not used by business users and as such should not be subject to data restrictions. A system administrator needs to be able to review all the data in these entities, unfiltered by owning organization, to properly address issues and exceptions. 

The following sections further describe concepts related to data security by owning organization.

Which Entities Are Secured?

Not all entities support this type of data security. The following business entities directly support security by owning organization:

  • Asset

  • Compatible Unit

  • Crew

  • Location. This includes all classes of locations stored in the "Node" maintenance object, for example, asset locations, storerooms, and so on.

  • Purchase Order Header

  • Purchase Requisition Header

  • Template Work Order

  • Work Design

  • Work Location

  • Work Order

  • Work Request

The following business entities indirectly support security by owning organization via association:

  • Work Activity. Secured via association to work order

  • Activity Reconciliation. Secured via association to work order

  • Design Element. Secured via association to work design.

  • Expedite Purchase Order. Secured via association to Purchase Order Header.

  • Invoice Header. Secured via association to Purchase Order Header.

  • Material Request Header. Secured via association to Storeroom (Node).

  • Material Return Header. Secured via association to Storeroom (Node).

  • Measurement. Secured via association to Asset.

  • Physical Inventory Header. Secured via association to Storeroom (Node).

  • Warranty. Secured via association to Asset.

The following administrative entities directly support security by owning organization:

  • Activity Type

  • Approval Profile

  • Asset Type

  • Business Unit

  • Checklist Type

  • Cost Adjustment Type

  • Cost Center

  • Distribution Code

  • Expense Code

  • Labor Earning Type

  • Location Type. This includes all classes of location types stored in the "Node Type" maintenance object, for example, asset location types, inventory location types, and so on.

  • Planner

  • Service Category

  • Service Class

  • Service Code

  • Service History Question

  • Service History Type

  • Specification

  • Work Category

  • Work Class

Shared Access

Security by owning organization is optional but when it is enabled the application assumes every record on a directly secured entity is assigned with an owning organization value.

When records are missing a value, the application cannot enforce data restriction and therefore lets these records be accessible to all. While the application treats these records as unrestricted, it assumes they are only temporarily unrestricted until a user or some default rule assigns them with a value.

The correct approach for intentionally sharing records across owning organizations is to designate one or more shared access groups and assign those to appropriate users. For example, if some entities are to be shared between the north and south owning organizations you may want to designate a “north-and-south” owning organization, assign shared entities to this owning organization, and allows users from both locations to have access to it.

Default Owning Organization Assignment Rules

When owning organization security is enabled, entities that are directly secured need to have their owning organization field populated either by the user or process that created them or in absence of an explicit value by a default rule. The application leverages an Audit algorithm configured on the entity’s business object to assign it with a default value. While a common default rule for administrative entities is to default the owning organization from the user’s default access group, more complex rules are called for when assigning values for master and transactional entities. To find the rule used for a directly secured entity, find the corresponding audit algorithm configured on its business object.

When creating a new administrative entity that is directly secured by owning organization, the user’s default access group is presented on the user interface prior to saving the record, allowing the user to change the value if needed before creating the record. Note that if the user deliberately clears the defaulted value the application still enforces the default rule and the record would be saved with the user’s default access group.

Default rules for master and transactional objects are more complex and as such need to support a way for your organization to customize them to meet your business requirements. Therefore, the user’s default access group is intentionally not defaulted on the user interface before creating such an entity, allowing the business object audit rule to populate the value as needed.

By default, product provided algorithms for defaulting an entity’s owning organization only resort to using the user’s default access group when a record is created. However, they all support an algorithm parameter that you may configure to enforce defaulting from the user’s default access group also when existing records with no owning organization value populated are updated.

Note: If after applying the default rules of any object an assignment has not been made, i.e. the record still has an empty owning organization field, the application is not able to restrict access to this record and therefore leaves it allowed to all. This should not be confused with a configuration that intentionally associates entities with a shared owning organization.

Explicit Owning Organization Assignment Rules

There are times when the appropriate owning organization value can not be determined by the entity’s default rule. In these unique situations, the process that creates the secured entity pre-populates it with the appropriate owning organization value when adding it. The following are examples of such processes:

  • When generating preventive maintenance work orders, the application inherits their owning organization from the asset they are created for. The asset is referenced on the activity and therefore a default rule for the work order would not have access to the asset at creation time.

  • When generating or interfacing other direct charges, the application inherits their owning organization from their activity’s work order. Here too, the activity is only referenced at the detail record and not available when the charge header record is created..

  • When generating follow-up work orders based on service history type configuration, the application inherits their owning organization from the service history’s activity’s work order.

Refer to the relevant algorithms associated with such processes for more information.

Creating Entities via Integration or in Batch

Typically, the user used to process web service calls or execute batch processes is a common user record that is not affiliated with any owning organization. As such , entities created by this common user should not rely on the user record’s default access group for a proper owning organization assignment. For that reason, these common users should not have any default access group defined for them, yet they should be allowed access to all access roles.

Directly secured objects created via web services or in batch are designed to have their value explicitly provided and not rely on the user’s default value. For example, a user creates an asset online they can either explicitly populate the asset owning organization or let the application default it to the user’s default access group. However, when assets are interfaced from an external system their owning organization should be explicitly populated.

Filtering By Owning Organization

Secured entities, either directly or indirectly, may support an owning organization filter on their respective query portals. The filter allows the user to review data that belongs to a specific owning organization, yet this should not be confused with data restriction. When security by owning organization is enabled, the application restricts the data the user can access to regardless of whether they have used the filter or not. If the user has access to more than one owning organization then a filter may be useful to narrow down the results to a selected group. However, when security by owning organization is not enabled, data is unrestricted and the user may access any record.

Enabling Data Security By Owning Organization

The following points highlight the overall steps needed to enable data security by owning organization customers:

  • Design and configure access groups and access roles to meet your business requirements. If some entities should be shared across all owning organization, define a customer shared access group that is linked to all access roles. 

  • Associate users with access groups and roles:

    • All user records for individuals accessing the application must be assigned with a default access group and may belong to one or more access roles. This access group is used as the default value assigned to some secured objects by various business rules.

    • All user records used for integration and batch processes should not be associated with a default access group but must have access to all access roles. This way data created by these shared user records are not stamped with an arbitrary owning organization yet all data is accessible to these processes.   

  • For upgrading customers, make sure existing records in the primary tables of directly secured entities have the correct value in the owning organization field. Depending on the volume of each table and the number of records that may need correction in each table you may choose to make these updates online or via a custom plug-in driven batch process.

  • Run the Apply Access Group VPD Policy (W1APLVPD) batch process to enforce row level security on master and transactional objects that are directly secured by owning organization. Refer to the batch control definition for more information about this batch process.