Brand Compliance Cloud Service Permissions

6 Brand Compliance Cloud Service Permissions

In Brand Compliance Cloud Service, role-based permission security is implemented to control:

Access to navigational links/tasks in the application. The role associated with the user (for example a Technologist or Buyer) determines the set of links visible in the task pane.
Access to various UI widgets in the screens such as buttons, menu items, LOVs, Panels, and so on. The role determines if the UI widgets are to be shown or hidden and if shown whether they need to be enabled or disabled.
How the screens will be opened, such as in an edit or view only mode based on the role the user belongs to and the permissions mapped to that role.

Roles and authority profiles are assigned to users to define their permissions, or access rights, to data and functionality within the application (including workflow, actions, screens, and in some cases specific fields). Roles are logical groupings of authority profiles that permit a user to perform a complete task to fulfill responsibilities within the context of their job. Authority profiles are associated to a set of permissions which provide different access rights. In this manner, an application role becomes the container that grants permissions to its members to access the application tasks, screens and the functionality within. The default configuration includes a number of default roles.

Authority profiles are intended to build on one another and work in a hierarchical manner. The example in Table 6-1 illustrates how this works using Audits as an example. The most basic level of access is Audit Reader, which grants the user permission to search and view audits. The next level of access is Audit Editor, which grants the user the ability to search and view audits, but also to create, maintain, and approve them. The final level of access in this example is Audit Administrator, which grants the user the access right of Audit Editor, but with the additional rights to delete audits (subject to other business rules), plus the administrative rights for maintaining the different types of audit templates, and supporting glossaries and configuration settings.

Table 6-1 Authority Profiles and Permissions

Authority Profile	Permissions
Audit Reader	Search Audits View Audits
Audit Editor	All Privileges of Audit Reader Create Audits Maintain Audits Approve Audits
Audit Administrator	All Privileges of Audit Editor Delete Audits Maintain Audit Templates & Glossaries

Permissions are essentially what actions that a user can perform, and on what data - controlled by collections of roles and authority profiles. The system determines the best case level of access based on the user’s allocated authority profiles For example, if a user possesses both Audit Reader and Audit Editor authority profiles, the system will grant the user edit access over read access. The predefined permissions associated to each authority profile may be customized by configuring the Brand Compliance Permissions rules.

Roles and authority profiles are assigned to a user by another user with User Administrator access rights and the permission to grant those roles or authority profiles. A user cannot assign their own permissions.

While the configurability of roles and permissions allow for custom levels of access to be defined, the Brand Compliance application also applies various implicit permissions rules which cannot be overridden through configuration. For example, hard-coded security rules ensure that a supplier user does not have access to data of other supplier organizations, and that only retailer/portal owner users (with the necessary access rights) have access to the Administration and Reporting modules, and so forth.

Roles

Also referred to as User Roles, roles align with titles or jobs within an organization, such as a Technologist or Buyer. Roles are used to classify users based on job responsibilities and actions to be performed in the application. One or more roles as well as additional individual authority profiles, if desired, are assigned to each user. When a user logs into the application, based on the authority profiles assigned to the user, the system determines which permissions have been granted to the user and the system features are enabled accordingly.

For example, within Brand Compliance, a Technologist may have the ability to create and progress Audits, but not the ability to create new Audit templates. Specific users who have the responsibility for maintaining the templates will be granted an additional Audit Administrator authority profile that provides them with the necessary level of access to maintain the Audit templates.

Roles Provided at Initial Setup

A default security configuration is provided with the application during installation and is intended to be used as a starting point as you define the roles that align for your business and users. The provided roles can be modified by adding or removing authority profiles to adjust the access granted to the role, or the roles can be deleted completely. Additional roles can be created and mapped to the desired authority profiles. Administrator users can maintain the roles, authority profiles and permissions in the Brand Compliance Admin area.

Details about how to manage these application security policies are available in the Managing User Access chapter in the Oracle Retail Brand Compliance Management Cloud Service Administration Guide.

These roles are provided in the default security configuration:

Assistant Technologist - Assists the Technologist in collaborating with suppliers for the on-going management of supplier sites and their products. Similar level of access as Technologist.
Auditor - Carries out site audits and visits. May be a third-party user.
Buyer - Develops business strategies and seasonal assortment for a brand. Similar access as Technologist, but typically read-only.
Laboratory - Third-party users with basic level of access for reading documents and alerts.
Oracle Authorized User - An administrator with the highest level of access to the configuration of the system. Has full access to the Admin area, including system parameters, custom fields, permissions and system text.
Power User - An administrator with similar access as System Administrator, plus the ability to maintain system text and delete unused supplier and site accounts.
Process Administrator - A retailer/portal owner with the administration responsibility for configuring templates for process projects, their activities and teams.
Process Manager - A retailer/portal owner user with responsibility for scheduling and progressing projects and their activities.
Restricted Auditor - An auditor who is restricted to accessing the audits and visits of only specific supplier sites. May be a third-party user.
Retailer Supplier Administrator - A retailer/portal owner with the ability to administer additional supplier account information on behalf of the supplier, such as their users and contact details.
Site Administrator - A user at a supplier site with responsibility for managing accounts for other users and contacts at the site.
Site Inspector - A user responsible for quality assurance. Has a basic level of access.
Site User - A user at a supplier site who collaborates with the retailer/portal owner in the on-going management of the site and its products.
Supplier Administrator - A user at a supplier with responsibility for managing accounts for other users and contacts at the supplier and its sites.
Supplier User - A user at a supplier who collaborates with the retailer/portal owner in the on-going management of the supplier’s sites and its products.
System Administrator - An administrator with responsibility for maintaining glossaries, users and documents.
Technologist - Evaluates new suppliers and has general due diligence responsibility for the safety and quality aspects of the supplier’s sites and products. Accesses most areas of the system.

For further information on the default set of roles, see the Appendix: Roles and Appendix: Authority Profile to Role Mappings.

Authority Profiles

Authority profiles grant access to specific tasks, links, and actions within the application. The access controlled by a particular authority profile is fixed and can only be changed by an enhancement to the application. You can control the functions and features to which a user has access by grouping the desired authority profiles into roles, or can assign individual authority profiles in addition to roles.

An authority profile may be part of a set that provides varying degrees of access to an area, for example Audit Reader, Audit Editor, and Audit Administrator as described in the Table 6-1 example. Alternatively, an authority profile may just control a specific feature, which is granted to individual users who perform the related function. For example, the Library Administrator authority profile is granted to individuals who have the responsibility of publishing documents in addition to their main role.

Authority profiles are classified as being for a retailer/portal owner user or for a supplier/site user; they can therefore only be granted to the relevant types of users.

Authority profiles are coded into the system to control the related behavior. Therefore it is not possible to configure new authority profiles in the same way that new roles can be created. The supplied set of authority profiles are can be renamed, but cannot be deleted.

A user’s best case level of access is determined by Authority Profile Groups, where related authority profiles are grouped in a hierarchy (for example Audit Administrator, Audit Editor, Audit Reader). If through the user’s allocation of roles and authority profiles they have conflicting access right (for example Audit Editor and Audit Reader), the system will grant the highest level of access (for example edit rights) based on the hierarchy.

For the full list of Authority Profiles, see the Appendix: Authority Profiles. For the full list of Authority Profile Groups, see the Appendix: Authority Profile Groups. For the mapping of Authority Profiles to Roles, see the Appendix: Authority Profile to Role Mappings.

Permissions

The rules for what data and functionality each authority profile has access to is defined in the Brand Compliance Permissions rules. The rules are configurable and are maintained by a spreadsheet download/upload facility within the Admin area.

The Permissions spreadsheet consists of a page for each module or area, containing a matrix of the access permitted to data and functionality elements by authority profile.

The data elements can be defined for an entire record type, or for specific pages, sections or individual fields within the record. The functionality elements are defined for menu options, actions and buttons.

The available levels of access are:

R - read access
W - write access
C - record creation
F - full access
Y - access permitted
N - access not permitted

The matrix can therefore be configured in a way that gives an authority profile full access to a data record and its functionality, or more granular access rights, such as to only view or edit certain aspects of a record, with a specific set of actions available.

By default, no access to data and functionality is assumed. Access must be specifically grated to the appropriate authority profiles, by defining Permissions rules.

Figure 6-1 shows an example of the Brand Compliance Permissions spreadsheet.

Figure 6-1 Permissions Spreadsheet

This image shows an example of a Permissions spreadsheet.

For further details on the Brand Compliance Permissions and configuring the spreadsheet see the Managing User Access chapter in the Oracle Retail Brand Compliance Management Cloud Service Administration Guide.

Various implicit permissions rules are hard-coded into the Brand Compliance security model and cannot be overridden through the configurable permissions rules. These include the segregation of data to ensure that a supplier users only have access to the data of their own organization.