Managing User Access

Overview of User Security

Following are the components of user security for Oracle Retail Brand Compliance Management Cloud Service:

Access rights are defined in the Permissions Rules spreadsheet.
Authority Profiles are grouped into Authority Profile Groups.
A role is comprised of Authority Profiles which assign the access rights.
A user is assigned roles.
A user may also be assigned individual Authority Profiles.

The system differentiates between internal (retailer) users and external (supplier) users, and controls the respective access to data and functionality based on implicit rules and configurable permissions rules. The permissions and implicit rules are applied wherever data or functionality is accessed: access to records, contents of list views and embedded lists, pick-list contents, wizard screens, and so on.

Implicit Rules

The system has a set of hard-coded rules that control fundamental access to data and functionality, such as, a supplier can only access their own data and the retailer has visibility to all suppliers' data.

Permissions Rules

The actual rules for each Authority Profile's access to the system (create, read, update, delete) are defined in the Permission Rules spreadsheet. The permissions can be defined at record, page, field-set, or field level, allowing access to be granted to entire records down to a more granular field-level where necessary. The permissions are also applied to grant access to menu options and actions, and can be set to take records' status into account.

Retailer users with the Oracle Authorized Administrator authority profile have access to the Permissions option within the Admin - Roles & Permissions menu.

Amending Permissions

The Permissions spreadsheet can be amended using the following steps:

Note:

It is recommended that Oracle be consulted before making changes to the Permissions spreadsheet.

Open the Roles & Permissions / Permissions page in the Admin area.
Select the active permission row in the list view.
Click Download Spreadsheet and save the XLS file locally.
Edit the Permissions.XLS file using a spreadsheet editor such as Excel and save the changes.

The spreadsheet is organized with a separate tab for each record type. Each page contains the following columns:
- Authority Profile - This is the grouping for which the access rights are provided. Authority Profiles are assigned to users, either grouped together as Roles, or individually. They collectively grant the user the appropriate level of access to the system. This column must contain an entry that is present in the Authority Profiles glossary. The remaining columns specify the profile's access rights for the type of record.
- Menu Option and Sub Menu Option - These columns are used to assign access rights to menu options and sub menu options.
- Action - This column is used to assign access rights to actions such as buttons or table actions.
- Record - This column identifies the record that the permission rule applies to.
- Page, Field Set, and Field - These columns identify individual pages, field sets, or fields within the page which are to have access rights that differ to the overall level of access to the record. For example, an Authority Profile may be assigned edit access to a record in general, but specific pages, field sets, or individual fields may be overridden to have read-only access.
- Status (Record and Parent Record) - This column can be used to apply rules specific to the status of the record and/or its parent record.
- User Mode - This column can be used to apply a separate set of rules for a restricted level of access. It will usually be set to NORMAL.
- Access Level - This column defines the level of access to be granted. The options are:
  - R - Read: Read-only access (also allows the Print action where the option is available).
  - W - Write: Write access (also assumes Read access).
  - C - Create: Ability to create a new record (also assumes Read and Write access).
  - D - Delete: Ability to delete a record (also assumes Read and Write access).
  - F - Full Access: Full access to a record (Read, Write, Create, and Delete access).
  - N - No Access: No access to the record, item, or action.
  - Y - Access Permitted: Ability to access an action.
Click Upload Permissions Spreadsheet and locate the spreadsheet. Add a comment and click Ok.
Select the uploaded entry in the list view and click Process Selected. The permission changes will become effective to users the next time they log in.

Setting Permissions for Product Records

An example of using the configurable Permissions rules to apply specific access rights to a certain type of user is where it may be desirable to prevent Supplier users from creating new Product Records, and restricting which fields they may edit within the record:

The permission rules have to be set up separately for Produce and non-Produce Product Records. An override approach, where a rule might be set up for all specification types and then overridden for Produce, has not been adopted because of the complexities of resolving rule precedence in the Authority Profile hierarchy.
If permissions for the Produce Product Records need to be the same as for non-Produce Product Records, duplicate the Action and Field Access rows in the Product sheet of the permissions spreadsheet:
1. Copy all of the rows with an entry in the Record column (column F). Rows where this column is blank can be ignored because they define list view menu options which do not check the state of the record, and therefore Produce or Non-Produce is an irrelevance.
2. Update the Record column (column F) by prefixing the values with "Produce " or "Produce_" or "PRODUCE " accordingly; the case does not matter.
If permissions for the Produce Product Records differ from the non-Produce permissions, set them up as required, but ensure that all Action and Field Access rows, as set up for non-Produce Product Records, are accounted for:
- For example, to configure the Permissions spreadsheet so that specific fields in the non-Produce Product Record are read-only for supplier users (those with the Supplier Product Editor authority profile):
- Or to configure the Permissions spreadsheet so that specific fields in the Produce Product Record are read-only for retailer users (those with the Retailer Product Editor authority profile):

Authority Profiles

Authority Profiles are the lowest form of control over functionality. Authority Profiles are sets of permissions that together set a level of access to specific areas of the application, both data and functionality, and can be set at the function, record, page, field-set, or field level. The permissions for each Authority Profile are defined in the Permissions Rules spreadsheet.

Each Authority Profile record has a unique name, unique code, and a mandatory default description. A description can also be provided for each of the supported languages. The system comes with default sets of retailer and supplier authority profiles.

An Authority Profile record also includes a field called "Control" which can be used to describe what the authority profile does. This becomes useful to an Administrator when using the Display effective permissions button within a user record because, as the cursor hovers over an Authority Profile within the dialog box, a tool tip will display whatever has been entered in the Control field. As text for the field can be entered in all supported languages for the portal, the system will be able to show the text in the language of the user using the system.

One or more Authority Profiles are assigned to a role to define its access rights. This enables new roles to be introduced without having to change the Permissions Rules spreadsheet.

The following are examples of Authority Profiles:

Configuration Editor
Audit Administrator
News Administrator
Library Reader

Authority Profile Groups

Authority profiles are grouped to set an order of precedence so that if a user has a number of conflicting authority profiles, such as Audit Reader and Audit Editor, the user is always assigned the highest level of access.

For example, the Product Technologist role may contain the News Reader authority profile as standard. If a particular Product Technologist user is granted the News Administrator role to give the user the rights to also publish news items, there would be a resulting clash between News Reader and News Administrator when the system determines the permissions. Authority profile groups therefore facilitate giving the News Administrator precedence over News Reader.

Retailer users with the Oracle Authorized Administrator authority profile have access to the Authority Profile Groups option within the Admin - Roles & Permissions menu.

Roles

Roles are constructed from Authority Profiles that define different levels of access to data and functionality within each area of the system, such as, Audit Reader, Audit Editor, and News Administrator. Users may also be assigned individual additional Authority Profiles to grant them specific privileges, such as granting a particular Product Technologist the ability to publish news items.

Note:

If a user is assigned individual additional authority profiles, the user's overall access to the system also takes into account the authority profiles associated to any roles the user has been assigned.

A user role is made up of one or more authority profiles. Each role has a unique name and a list of authority profiles. A role has a predefined level of access to the system determined by its associated Authority Profiles.

Each user is assigned one or more roles appropriate to that user's use of the system. Roles are configurable and a number of standard roles are supplied with the system for the common types of user, such as, Product Technologist. These may then be amended to reflect retailer-specific terminology or business processes as required. Any number of additional roles can be created to enable alternative types of users.

Roles are user classifications that relate to a job title, such as:

Product Technologist
Assistant Technologist
Product Development Manager

Roles can be created to build common variants, for example, a Trainee Assistant Technologist where the level of access is restricted to read-only.

Common User Roles

The system comes with a predefined set of common user roles which can then be amended or extended as necessary. Table 2-1 describes the internal roles.

Table 2-1 Internal (Retailer) Roles

Role Name	Description
Account Administrator	Enables access to orders generated from the supplier registration process.
Assistant Technologist	Enables the user to work with Product Technologists and perform some tasks on their behalf. Therefore, the user by default has the same level of access as a Product Technologist.
Auditor	May be internal (retailer) or external (third-party audit house/certification body) users. The users carry out supplier site audits on behalf of the retailer, so the users can create and complete audits and visits.
Restricted Auditor	For internal (retailer) or external third-party audit house/certification body user who needs only to have limited visibility of audits. This user role is expected to utilize the same authority profiles as the Auditor user role but replaces the Auditor authority profile with a new Restricted Auditor authority profile.
Buyer	Enables access to supplier information. The level of access is generally restricted to read-only, such as read access to supplier details.
Laboratory	External users. Initially just basic access to news and documents.
Power User	Allows the configuration of product specification mandatory fields and field locking rules.
Product Development Manager	Involved in the early stages of the product's lifecycle. The level of access is generally restricted to read-only.
Product Technologist	Main users of the system. These users have access to most areas of the system and work in collaboration with the suppliers of products, carrying out site visits and audits.
Project Administrator	Enables the configuration of templates for projects and their activities.
Project Manager	Enables the creation and management of projects.
Retailer Supplier Administrator	Can be given to a retailer user to enable the user to edit the name, address, and contact details of supplier and site accounts.
Site Inspector	Initially, just basic access to news and documents. The user eventually accesses product information for quality assurance purposes.
Surveillance Laboratory User	Given to external testing laboratory users to allow them to access the portal for the upload of test results, and to run predefined reports.
System Administrator	Provides access to the configuration and administration features.

Each supplier has their own account within the system, comprising a single supplier (head office) record plus a site record for each of their manufacturing or packing locations. Supplier users have their own individual user accounts. Supplier users are either a supplier level user associated to the head office and all its sites, or a site level user associated to one or more sites within the organization and may be granted administration rights. Table 2-2 describes the external roles.

Table 2-2 External (Supplier or Site) Roles

Role Name	Description
Supplier Administrator	A supplier level user with permission to administer supplier and site users and addresses and contacts, that is, Supplier and Site records and their Contacts.
Supplier User	A supplier level user with access to all sites for that supplier including any new sites that are created. This user type can be a contact for the supplier and for any site.
Site Administrator	A site level user with permission to administer site users for their sites only and address and contacts for those sites they have access to, that is, Site Records and their contacts.
Site User	A site level user with access to specified sites. As new sites are added, they do not have access to those sites unless specifically granted by an administrator. They can be a site contact, but not a supplier contact.

Users

Each user of the system is assigned an individual password-protected user account identified by a personal user name and email address. Most transactions made within the system are recorded in time-stamped audit trail logs, identifying the user responsible for the transaction.

Designated administrators, within the retailer and supplier organizations, create and manage their users and access rights. Individual users can then maintain their own contact details, preference settings, and passwords.

User records are assigned one or more roles to set their default level of access. Authority Profiles can also be assigned directly to a user to give them specific access rights.

The User record includes flags to control whether the user is to appear in the drop-down lists of Product Technologist, Assistant Technologists, Auditors, and so on.

IDCS or OCI IAM Integration for Authentication

From release 18.2, the authentication of user and external system identity for access to Oracle Retail Brand Compliance Management Cloud Service is managed by Oracle's Identity Cloud Service (IDCS) or Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) identity management service. This strategic initiative is a move towards most Oracle Retail Cloud Service applications using IDCS or OCI IAM for authentication, thus paving the way for single sign-on across the product range. In the meantime, Brand Compliance will implement IDCS or OCI IAM as a standalone means of identity authentication.

Note:

When IDCS or OCI IAM integration is implemented, it becomes the sole means of authentication for users and external systems. In the event of the IDCS or OCI IAM tenant not being available to perform authentication, access to Brand Compliance will not be permitted.

The key features of the IDCS or OCI IAM authentication for Brand Compliance are as follows:

All users and external systems log in to Brand Compliance using an individual IDCS or OCI IAM profile.
Each Brand Compliance portal instance has dedicated IDCS or OCI IAM tenants, for its production and staging/UAT environments.
New users are created in Brand Compliance, which automatically triggers creation of an IDCS or OCI IAM profile.
User roles map to groups in IDCS or OCI IAM to control users' level of access.
All maintenance of passwords and email addresses is carried out by the user in IDCS or OCI IAM.
The user maintains all other account details in Brand Compliance.
An hourly batch job automatically synchronizes changes between Brand Compliance and IDCS or OCI IAM.
External systems accounts, used to access the Brand Compliance APIs, are treated the same as users.

Note:

User documentation for IDCS can be found at the Oracle Identity Cloud Service Help Center:

https://docs.oracle.com/en/cloud/paas/identity-cloud/

User documentation for OCI IAM can be found at the Oracle Cloud Infrastructure Identity and Access Management Documentation:

https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm

Provisioning a New System

When a new Brand Compliance portal is implemented, the necessary IDCS or OCI IAM tenant will be installed and configured to include an IDCS or OCI IAM Administrator profile for the on-going administration by a retailer administrator.

Once the IDCS or OCI IAM tenant has been configured, its environment variables will be visible in the System Parameters page.

Migration of Users

When provisioning a new Brand Compliance portal, a migration process can be used to automatically create the IDCS or OCI IAM profiles. This facility allows accounts to be provisionally created in Brand Compliance, then enabled as part of the launch. External System accounts are also migrated.

The key features of the migration tool are as follows:

The migration tool is run by Oracle Application Management Services (AMS) as part of the portal upgrade process. It may be run multiple times during the deployment.
All Brand Compliance users and external systems have an IDCS or OCI IAM user profile created (excluding the Root user account, and any without a valid email address).
The login id becomes the unique reference that links the Brand Compliance and IDCS or OCI IAM accounts.

Users are assigned to the appropriate IDCS or OCI IAM access control groups based on their Brand Compliance access rights.

The core set of roles is as follows:

RETAILER_ROLE	RGBU_BCCS_%s_Retailer
EXTERNAL_SYSTEM_ROLE	RGBU_BCCS_%s_ExternalSystem
AREA_ROLE	RGBU_BCCS_%s_Retailer_%s
SUPPLIER_ROLE	RGBU_BCCS_%s_Supplier]
ARTWORK_ROLE	RGBU_BCCS_%s_Artwork
REPORTING_ADMIN_ROLE	RGBU_BCCS_%s_Reports_Admin
REPORTING_READER_ROLE	RGBU_BCCS_%s_Reports_Reader
REPORTING_USER_ROLE	RGBU_BCCS_%s_Reports_User
TEST_ROLE	RGBU_BCCS_%s_Test
TEST_AREA_ROLE	RGBU_BCCS_%s_Test_%s

The migration process can create IDCS or OCI IAM profiles at either activated or deactivated status. The flag in Brand Compliance that disables the login has no effect on the IDCS or OCI IAM profile, however access to Brand Compliance is prevented if the account has been set as disabled.
During the migration, the automated emailing of notifications to new users from IDCS or OCI IAM will be temporarily disabled, to prevent users attempting to access prior to launch. The notification emails may be manually sent from IDCS or OCI IAM, post migration.
After migration, the client administrator user has the ability to configure and enable/disable the individual IDCS or OCI IAM email templates.
Once the portal is deployed, creating a new user in Brand Compliance will trigger the automatic creation of a corresponding IDCS or OCI IAM profile. An hourly scheduled job thereafter synchronizes any changes to email address or user roles.
The migration tool can also be used to create the IDCS or OCI IAM user profiles when refreshing a staging/UAT environment with data from the production environment.

As the linking of the Brand Compliance accounts to their IDCS or OCI IAM profiles is by the login id, when a portal's staging/UAT environment has its data refreshed with that from another environment, accounts that have a corresponding profile in the staging/UAT environment's IDCS or OCI IAM tenant should authenticate without the need to create new profiles. Otherwise new accounts will need to be created in Brand Compliance, which will automatically create the corresponding IDCS or OCI IAM profiles.

Managing Authority Profiles

The descriptions in the supported languages can be changed for the Authority Profiles. Select Authority Profiles from the left pane. The Authority Panels page opens. Select the Edit action. The page opens in edit mode. Make any changes and save the updates.

Managing User Roles

Select User Roles in the left panel. The List Roles page opens. For each role, the code, user type (Retailer, Site, Supplier), and description is shown.

Adding a User Role

To add a new user role:

Select the New User Role action. The Role Details page appears.

Figure 2-1 New User Role Page

Enter the details for the role and select the Save action.

Table 2-3 New User Role Page Details

Details	Description
Code	Enter a unique code for this user role. Mandatory field.
User Type	Select the type of users for which this role is intended: Retailer Supplier Retailer and Supplier Site
Description	Enter the description for this role in the supported languages. The description for the default language is mandatory
Authority Profiles	Click the icon and select the Authority Profiles that define this role.
Grant Roles	Click the icon and select the roles that a user assigned this new role can assign to other users.

Editing a User Role

Select the role and select the Edit action. The Role Details are displayed in edit mode. The Code, User Type, and Default Description, and any descriptions entered for a supported language cannot be edited. Descriptions for additional languages can be added.

List Configuration

List configuration enables the auto-selection of users into a list. These lists can be filled with the names of users that have the selected roles for the list.

Select the List Configuration option in the left pane. The List Configuration page opens.

Figure 2-2 List Configuration Page

This figure shows the List Configuration page.

For each list configuration, the roles assigned for that list are shown.

To edit a list configuration, select the entry and then the Edit action. The Details page for the selected list appears.

Figure 2-3 List Configuration Details Page

This figure shows the List Configuration Details page.

Select the icon in the Roles panel to see the list of available roles. The Select User Roles dialog box appears. Select the roles you want for this list configuration and select Ok.

Figure 2-4 Select User Roles Dialog Box

This figure shows the Select User Roles dialog box.

Managing Contact Roles

To access contact roles, select the Contact Roles option in the left pane. The Contact Roles page opens. For each contact role, the description is shown and a column for each of the following with a Yes/No status for each role:

Is Supplier Role?
Is Mandatory Supplier Role?
Is Site Role?
Is Mandatory Site Role?

Adding a Contact Role

To add a new contact role:

Select the New Contact Role action. The New Contact Role page opens.

Figure 2-5 New Contact Role Page

Enter the details and select the Save action.

Table 2-4 New Contact Role Page Details

Details	Description
Code	Enter a unique code for this user role. Mandatory field.
Description	Enter the description for this role in the supported languages. The description for the default language is mandatory.
Supplier Level	Check if this is a supplier level contact role.
Supplier Level Mandatory	Check if this is supplier level contact role is mandatory. If a role is mandatory, a contact must be assigned to that role for a supplier record to be approved. A role may also be mandatory if it is required to automatically notify the relevant users when an action is required.
Mandatory Supplier Types	Click the icon and select the mandatory supplier types for this role.
Site Level	Check if this is a site level contact role.
Site Level Mandatory	Check if this site level contact role is mandatory. If a role is mandatory, a contact must be assigned to that role for a site record to be approved. A role may also be mandatory if it is required to automatically notify the relevant users when an action is required.
Mandatory Site Types	Click the icon and select the mandatory site types for this role.

Editing a Contact Role

To edit a contact role, select the role in the Contact Roles page and select the Edit action. The contact role record opens in edit mode in a new tab. The Code, Default Description, and any descriptions entered for a supported language cannot be edited. Descriptions for additional languages can be added.

Managing Users

To access the users, select Users from the Company menu. The Company Users tab opens. The list of users is displayed. For each user, the user name, login ID, and email address are shown. If available, a phone number and mobile phone number are also shown.

Creating a User

To create a new user, select the New User action. The New User page appears. Figure 2-6 shows the format of the page when a retailer user is being created. Figure 2-7 shows the format when a supplier user is being created.

Figure 2-6 New User Page for a Retailer User

This figure shows the New User page for a Retailer user.

Enter the information in the following sections for the new retailer user:

Details

The Name, Email, Login Id, and Language fields are mandatory.

Area only appears if the Restrict Access by Area system parameter has been set. Assigning a user to an Area, or Areas, limits the user's visibility of Supplier information to just those that are assigned to that Area or Areas.
Address
Roles and Permissions:
- User Roles is a mandatory field.
- If this user should appear in a list configuration, check the box.
- Additional Authority Profiles can be selected for this user.
- Restricted Audit Access determines if the user has limited access to Audits.
Clicking Display effective permissions shows the authority profiles that provide this user's highest level of access, based on their assigned roles and authority profiles.

Figure 2-7 New User Page for a Supplier User

This figure shows the New User page for a Supplier user.

Enter the information in the following sections for the new supplier user:

Details

The Name, Email, Login Id, and Language fields are mandatory.
Address
Roles and Permissions

The list of available roles for this user is dependent on the user type selected. User Roles is a mandatory field.

Clicking Display effective permissions shows the authority profiles that provide this user's highest level of access, based on their assigned roles and authority profiles.

Validation will prevent the account being created if another User or External System record has the same login id. The Login Id Disabled flag has no effect on the status of the IDCS or OCI IAM profile, however if set, it will prevent access to Brand Compliance.

Validation also ensues the last part is at least two alphabetic characters, as required by IDCS or OCI IAM. For example, a@b.cd is valid; a@b.c, a@b.c-d, and a@b.cd1 are invalid. Any leading or trailing spaces are automatically stripped from the email address

Use the Save & Exit action to create the account (the Save action does not appear until the account has been created).

When the User record is saved, the creation of a corresponding IDCS or OCI IAM profile is triggered (see Synchronization with IDCS or OCI IAM). An email message is automatically generated and sent to the user, instructing them to set the password of their IDCS or OCI IAM profile. The administrator can resend the emails from within IDCS or OCI IAM.

Note:

The user must be assigned at least one role or authority profile.

Editing a User

To edit a user, select the user on the Company Users page and select the Edit action.

The user record opens in edit mode in a new tab. The Login Id and Email Address cannot be changed. The user maintains their password and email address in IDCS or OCI IAM. Changes to the Email Address and User Roles are synchronized between IDCS or OCI IAM and Brand Compliance (see Synchronization with IDCS or OCI IAM).

The IDCS Profile Created flag is set if the corresponding IDCS or OCI IAM profile has been successfully created.

Use the Save or Save & Exit action to apply the changes.

Synchronization with IDCS or OCI IAM

When a new user or external system is created (whether manually, as part of a bulk upload, or by the Users API), a corresponding user profile is automatically created and activated in IDCS or OCI IAM. The IDCS or OCI IAM profile is automatically assigned to a group that represents its Brand Compliance user role access rights.

Note:

Brand Compliance and IDCS or OCI IAM use different formats for storing names: Brand Compliance has a single name field; IDCS or OCI IAM has three separate fields. Therefore, there is no synchronization of the name fields.

When the IDCS or OCI IAM profile is created, the First Name field is populated with the full name from Brand Compliance; the Middle Name and Last Name fields are set to blank or a dash. The user can subsequently change these in IDCS or OCI IAM, without affecting the name in Brand Compliance.

The user maintains their password and email address in IDCS or OCI IAM; changes to the email address are automatically synchronized with Brand Compliance, where the email address is read-only. The rules for password strength and reuse are configured in IDCS or OCI IAM.

The synchronization between Brand Compliance and IDCS or OCI IAM is performed by an hourly ORBC-IDCS User Synchronization scheduled batch job. When the job runs, it updates the Identity Cloud Service Last Synchronisation timestamp system parameter.

Note:

The job checks for any users updated in Brand Compliance and immediately updates the user in IDCS or OCI IAM. It also checks for user profiles updated in IDCS or OCI IAM and, for each, submits a further batch job to update the Brand Compliance User record. If an IDCS or OCI IAM profile was manually created before the Brand Compliance user account was created, assuming the login id is the same, the job will link to the existing IDCS or OCI IAM profile. Users will always be initially created in Brand Compliance.

In the event of the IDCS or OCI IAM tenant not being accessible when a new user account is created, the IDCS or OCI IAM profile will be subsequently created automatically on completion of the next hourly synchronization job.

If the IDCS or OCI IAM profile is subsequently deactivated, the user will receive an email notification, and access to Brand Compliance is revoked; if reactivated, the user will receive an email notification, and access is reinstated. The user's password is unaffected by the profile being deactivated, so if reactivated, it will remain valid (subject to password expiry rules).

If a User/External System record is deleted in Brand Compliance (subject to it not having been referenced by any records), the corresponding IDCS or OCI IAM profile is automatically deleted.

Disabling a User

A user can be prevented from logging in the next time the user tries to log in. You must have the required permissions to be able to disable a login. To disable a user from logging in:

Select the user on the Company Users page.
Select the Edit action. A tab is opened with the user record in edit mode.
Check the Login id Disabled field. The field is found in the Details section. See Figure 2-6.
Save the changes.

Deleting a User

Note:

When the User record is deleted, the corresponding IDCS or OCI IAM User Profile is not automatically deleted. It must be dealt with manually within IDCS or OCI IAM if it is no longer required.

To delete a user:

Select the user in the Company Users page.
Select the Edit action. A tab opens with the user record in edit mode.
Select the Delete action. The Confirm Delete User dialog box appears.
Click Ok. If the user has enabled their account by completing the self-registration and setting their initial password, the system will not permit deletion of the account. In this case, a dialog box appears, preventing the deletion; click Ok.

Note:

If deletion is not permitted, and an alternative is to deactivate the account, see Disabling a User. You may also wish to reduce the roles and permissions to the minimum permitted.

If deletion is permitted, the corresponding IDCS or OCI IAM profile is also deleted, automatically.

Upload Retailer User Data

Retailer users with the Upload Administrator authority profile have access to the Upload Data option within the Admin menu for the upload of retailer users.

To upload new retailer user records:

Select the Import action from the Product Records List View actions menu. The Data Upload dialog box opens.

Figure 2-8 Data Upload Dialog Box
Click Browse to search for the upload file.
Enter any comments to describe the reason for the upload.
Select whether the system is to automatically send email to each newly created user on successful completion of the upload. The email will invite the user to register on the portal. The default is No, which will not send an email.
To upload the file, select either the Submit or Submit Go to Manage Batch Jobs action. At this point, the system will create a background job to process the spreadsheet. The spreadsheet used to upload the data will be stored within the Attachments tab of the batch job.

Note:

As part of the user account creation, the corresponding IDCS or OCI IAM user profile is automatically created and activated. The user will receive an email notification from IDCS or OCI IAM.

Validation will prevent the user account being created if another User or External System record has the same login id.

An email will be sent to the job submitter if the data within the upload file fails validation.

Download Retailer User Upload Spreadsheet

Retailer users with the Upload Administrator authority profile also have access to the option to download a blank spreadsheet.

To download the latest version of the upload spreadsheet:

Select the Download Blank Spreadsheet option in the Users List View menu. An operating system specific dialog box opens with the option to either open or save the file.
Select the save option to download the ZIP file to your desktop.

Note:

The ZIP file contains a spreadsheet workbook with the first tab used to upload the data. The second tab contains guidance notes and the remaining tabs contain the valid glossary values.

The column heading text shown on the first tab is in the user's language. If translations are not present for the user's language in the system, the portal's default language is substituted. An asterisk (*) will be shown in a column heading if an entry is mandatory.

Managing External Systems

External systems can access Oracle Retail Brand Compliance Management Cloud Service through its suite of web service APIs. In order for an external system to access an API, it must be granted permission with a login ID and password. Similar to user accounts, an external system account must be created and a password assigned, along with the rules for which services may be accessed.

To access the external system options, select the Roles & Permissions option from the Admin drop-down list and select External Systems in the left pane. A list of existing external system accounts appears, showing the login IDs and whether the accounts are active or disabled.

Figure 2-9 External Systems Page

This figure shows the External Systems page.

Creating an External System

To create a new external system, select the New External System action. The New External System page appears.

Figure 2-10 External System Details Page

This figure shows the External System Details page.

Enter the required information for the external system:

The Login Id is mandatory and must be unique.
The account can be disabled by checking Login Id Disabled.
The days before password expires will start with the system's default value.
Additional information about the external system can be entered in the Comment field.
Select the Services and/or the individual Endpoints the external system is to be granted access to.

The user maintains the password and email address in IDCS or OCI IAM.

Validation will prevent the account being created if another User or External System record has the same login id. The Login Id Disabled flag has no effect on the status of the IDCS or OCI IAM profile, but will prevent access to Brand Compliance if it is set.

Use the Save & Exit action to create the account (the Save action does not appear until the account has been created).

Editing an External System

To edit an external system, select the external system on the External Systems page and then select the Edit action. The external system record appears in edit mode in a new tab. The Login Id and Email Address cannot be changed.

When the record is saved, the creation of a corresponding IDCS or OCI IAM profile is triggered (see Synchronization with IDCS or OCI IAM). An email message is automatically generated and sent to the associated user, instructing them to set the password of the IDCS or OCI IAM profile. The administrator can resend the emails from within IDCS or OCI IAM.

The IDCS Profile Created flag is set if the corresponding IDCS or OCI IAM profile has been successfully created.

The record opens in edit mode in a new tab. The Login Id and Email Address cannot be changed. The user maintains their password and email address in IDCS or OCI IAM. Changes to the Email Address and User Roles are synchronized between IDCS or OCI IAM and the Brand Compliance (see Synchronization with IDCS or OCI IAM).

Use the Save or Save & Exit action to apply the changes.

Note:

As the external system's IDCS or OCI IAM profiles are not aligned with an individual, in order to allow for their passwords to be reset, retailer User Administrator users will be assigned the IDCS or OCI IAM User Administrator role, providing them the ability to change all users' passwords (regardless of EAC groups if the portal has the Enhanced Access Control facility applied).

Other users (including all supplier users) will only have the ability to change their own passwords.

Disabling an External System

An external system can be prevented from accessing Oracle Retail Brand Compliance Management Cloud Service. To disable an external system:

Select the external system on the External Systems page.
Select the Edit action. A tab is opened with the external system record in edit mode.
Check the Login Id Disabled checkbox.
Save the changes.

An alternative to disabling the account is to deselect the services and endpoints, or to deactivate the corresponding IDCS or OCI IAM profile.

Deleting an External System

To delete an external system:

Select the external system on the External Systems page.
Select the Edit action. A tab is opened with the external system record in edit mode.
Select the Delete action. The delete confirmation dialog box appears.
Click Ok. The external system and its corresponding IDCS or OCI IAM profile are deleted.

Expiring Passwords

The external system's password will automatically expire if it is not reset in accordance with the system parameter rules. The rules are configurable by the administrator, within IDCS or OCI IAM.

Note:

IDCS or OCI IAM does not issue email notification prior to a password expiring, so in order to ensure continued access to the Brand Compliance APIs, plan for the external system passwords to be changed periodically.

Managing Endpoints

Endpoints define the individual methods of the web services that are available through the portal's APIs. Endpoints cannot be manually created or deleted, and should only be edited to activate or deactivate the endpoint.

Figure 2-11 Endpoint Access Page

This figure shows the Endpoint Access page.

To enable or disable an endpoint:

Select the endpoint on the Endpoint Access page.
Select the Edit action. A tab opens with the endpoint record in edit mode.
Check the Active checkbox to activate the endpoint; un-check the checkbox to deactivate the endpoint.
Save the changes.

Figure 2-12 Endpoint Access Details Page

This figure shows the Endpoint Access Details page.

Note:

Deactivating an endpoint prevents it from being selected as part of a service, it does not stop the endpoint being accessed in existing services. To prevent an external system accessing an endpoint, deselect the endpoint and/or service in the External System record.

Managing Services

Services define the web services that are available as the portal's APIs. Services cannot be manually created or deleted, and will usually only be edited to activate or deactivate the service.

Figure 2-13 Service Access Page

This figure shows the Service Access page.

To edit, disable or enable a service:

Select the service on the Service Access page.
Select the Edit action. A tab is opened with the service record in edit mode.
Check the Active checkbox to activate the service; un-check the checkbox to deactivate the service.
Select the endpoints to be made available through this service.
Save the changes.

Figure 2-14 Service Access Details Page

This figure shows the Service Access Details page.

Note:

Deactivating a service prevents it from being granted to an external system, it does not stop the service being accessed where it has already been granted to an external system. To prevent an external system accessing a service, deselect the service in the External System record.

System Parameters

To manage the parameters for users, select the System Control option and then System Parameters. Table 2-5 describes the available parameters.

Table 2-5 System Parameters Used to Manage Users

Subtab	Parameter	Description
Log On	Site Details Update Reminder	Used for supplier login. Number of working days when a reminder is shown in a user's UIM when the user has logged in. It is used to ensure that Mandatory Contact details are kept up to date on both the supplier and sites. Default is 90 days. When the first supplier user logs in, they see an entry in the UIM drawing their attention to this. If they use the Confirm Details action, this stamps the date onto the record so that the next time a user logs in, the system checks if the current date is greater than the stamped date.
Log On	Open the system in new window	If set to Yes, the system opens in a new browser window after valid login credentials are entered. If set to No, the system opens in the current browser window. Default is Yes.
Log On	User Ts&Cs Active	If set to Yes, a new user will have to accept the Terms and Conditions before completing login. If set to No, the user is not prompted to accept Terms and Conditions. Default is Yes.
Global	Default Language	Determines the default language used by the system once the user is logged in. Default is English. Note: Once set, the default language cannot be changed.
Global	Enable user preference option for the auto refresh of list views	If checked, users will have an option in their user preferences to set whether the contents of list views automatically refresh each time the user returns to it, rather than each time it is initially opened. If unchecked, the user will not have the preference option, and list views will only refresh when initially opened, or the Refresh action is manually selected. This parameter is used to reduce the amount of processing time spent on automatically refreshing list views, a potential performance overhead. For new installations the default is unchecked (no auto refresh); for portal upgrades, the default is checked (individual users choose to enable auto refresh). This is only editable by users with the Oracle Authorized Administrator authority profile.
Global	Number of days to keep Web Service Logs	Controls how long entries in the Web Service Log are retained for (number of days). A daily scheduled batch job purges any entries from the Web Service Log that are older than the specified number of days. The default value is 30 days. Only whole days can be specified (any decimals are stripped); there is no upper limit. If a value of zero is entered, all entries in the log will be removed each time the job is run (daily); a negative value is treated as zero. If no value is entered, no purging will be applied, so the log entries will be retained indefinitely.
Global	Identity Cloud Service URL	The URL of the IDCS or OCI IAM tenant associated to the Brand Compliance portal. This read-only parameter is set when the IDCS or OCI IAM tenant is deployed; it cannot be edited.
Global	Identity Cloud Service Client ID	The ID of the IDCS or OCI IAM tenant associated to the Brand Compliance portal. This read-only parameter is set when the IDCS or OCI IAM tenant is deployed; it cannot be edited.
Global	Identity Cloud Service Last Synchronisation	The date and time of the last synchronization of user details between Brand Compliance and its IDCS or OCI IAM tenant. This read-only parameter is set when the IDCS or OCI IAM tenant is deployed; it cannot be edited.
Global	Identity Cloud Service Environment	The code that identifies the Brand Compliance portal environment (such as a production or staging/UAT environment) for the coding of groups within IDCS or OCI IAM. This read-only parameter is set when the IDCS or OCI IAM tenant is deployed; it cannot be edited.
Global	Identity Cloud Service Brand Compliance App ID	The code that uniquely identifies the Brand Compliance portal for integration with its IDCS or OCI IAM tenant. This read-only parameter is set when the IDCS or OCI IAM tenant is deployed; it cannot be edited.
Global	Base URL	Base URL of the portal.
Global	Reporting Server URL	URL of the Reporting server.
Global	Rest API Path	URL path of the REST APIs.
Global	Artwork Application URL	URL of the Artwork application.
Global	Portal Name	Description of the portal. Primarily used when part of a Global Network Bus multi-portal installation.
Urgent Items	Show missing mandatory user details	If set to Yes, when a user logs on and if there are any mandatory user details missing from the user's user record, an entry is shown in the UIM. Default is Yes.
Static Settings	Show Base Language Translation	This parameter is used in portals that have changed the base/default language from English (British) to another language, in which case additional translation fields are required to be displayed. This parameter is set during the release upgrade process in any portals that it is applicable for. Note: The Static Settings page is only visible to Oracle administrators, and the contents are read only.

Note:

The parameters that control the password format and strength can only be edited by the Oracle authorized Administration logon. Changing these parameters results in all users' passwords being automatically expired, forcing each user to reset their password the next time they log in.

If the password parameters are changed, the following message is displayed. Click Ok to continue.

A change made affects the strength of the required passwords. Click Ok to immediately Expire All User Passwords.

Note:

The Brand Compliance timeout is not configurable, but is set to 8 hours, to match the IDCS or OCI IAM default.

To manage the parameters for external systems, select the System Control option and then System Parameters. Table 2-6 describes the available parameter.

Table 2-6 System Parameter Used to Manage External Systems

Subtab	Parameter	Description
Log On	User T's & C's Active	If set to Yes, users must accept the portal's terms and conditions when they first log on. Default is Yes. This parameter can only be seen and maintained by users with the Oracle Authorized Administrator authority profile.

Subtab

Parameter

Description

Log On

User T's & C's Active

If set to Yes, users must accept the portal's terms and conditions when they first log on. Default is Yes.

This parameter can only be seen and maintained by users with the Oracle Authorized Administrator authority profile.

Below is an example of the use of the password expiry and grace period parameters, showing that if the expiry period is 8 days and the grace period 2 days, the password will expire at the start of the ninth day following the last reset of the password (including that day); and from the start of two days prior to the expiry day, a reminder to change the password will be issued (until the password is reset or expiry is reached).

This graphic shows an example of password expiration.