| Oracle® Retail Brand Compliance Management Cloud Service Administration Guide Release 18.1 F18525-02 |
|
 Previous |
 Next |
| Oracle® Retail Brand Compliance Management Cloud Service Administration Guide Release 18.1 F18525-02 |
|
Previous |
Next |
This chapter describes how user access to Oracle Retail Brand Compliance Management Cloud Service is managed. Retailer users who are assigned the User Administrator Authority Profile can create and edit users.
The following topics are covered in this chapter:
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.
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.
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.
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.
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:
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.
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 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 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 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.
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. |
|
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. |
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.
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.
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.
To add a new user role:
Select the New User Role action. The Role Details page appears.
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:
|
|
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. |
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 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.
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.
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.
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?
To add a new contact role:
Select the New Contact Role action. The New Contact Role page opens.
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. |
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.
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.
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.
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.
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.
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.
When the User record is saved, an email message is automatically generated and sent to the user. The user is invited to register and set an initial password.
The administrator can send a reminder email message to any users who have yet to complete their registration. To send the reminder, select the Re-send new User Notification list view action. The email message is not sent if the user has already registered.
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 cannot be changed. If the user has User Administrator rights, the Login id Disabled and Password Expired fields can be changed.
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.
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. |
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.
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: An email will be sent to the job submitter if the data within the upload file fails validation. |
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. |
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 System Control 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.
To create a new external system, select the New External System action. The New External System page appears.
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 Change Password action can be used to set the password once the account has been saved.
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 cannot be changed. If the user has Password Administrator rights, the Login Id Disabled, Comments, Service Access, and Endpoint Access fields can be changed.
Select the Change Password action to set the password.
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.
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's password will automatically expire if it is not reset in accordance with the system parameter rules (see Table 2-6).
When an external system's password becomes due to expire (based on its grace period), an entry will appear in the Task and UIM (Urgent Item Manager) apps for administrators with the authority profiles specified in the system parameter rules.
When an external system's password expires, an entry will appear in the Task and UIM (Urgent Item Manager) apps for administrators with the authority profiles specified in the system parameter rules. These users will also receive notification of the expiry in an email that is automatically generated by a batch job.
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.
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.
|
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. |
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.
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.
|
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. |
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 |
Min Length of Password |
Minimum length required for a password. Default is 8. Cannot be less than 8. |
|
Log On |
Max Length of Password |
Maximum length required for a password. Default is 15. |
|
Log On |
Min Letters in Password |
Minimum number of letters required in a password. Default is 2. |
|
Log On |
Min Digits in Password |
Minimum number of digits required in a password. Default is 1. |
|
Log On |
Min Uppercase Characters in Password |
Minimum number of uppercase characters required in a password. Default is 1. |
|
Log On |
Min Lowercase Characters in Password |
Minimum number of lowercase characters required in a password. Default is 1. |
|
Log On |
Password must begin with a Letter |
If set to Yes, the password must begin with a letter. Default is No. |
|
Log On |
User Password History |
Number of past passwords the user has defined. This prevents a user from setting the password to a previous password. Default is 24. |
|
Log On |
Password Minimum Life |
This can be used to stop a user from quickly changing their password. Default is 1. |
|
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 |
Password Expiry Limit (days) |
Number of days a password can be used before it must be changed. Default is 180. Must be between 1 and 180. |
|
Log On |
Password Grace Period (days) |
Number of days before the Password Expiry Limit is reached when the system starts prompting a user to change the password. Default is 21. Cannot be greater than Password Expiry Limit (days). |
|
Log On |
Max Login Attempts |
Sets the number of times a user can enter an incorrect password before being locked out. This field is ignored if blank. Default is 5. |
|
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 |
Session Timeout (mins) |
Number of minutes a session can remain idle before it times out and logs off the user. The countdown starts from the last save or refresh action. Default is 90. |
|
Global |
Session Timeout Warning (mins) |
Number of minutes prior to the session timeout that a warning message is issued to prompt the user to save any work because the session has been idle and will time out after the set number of minutes. Default is 5. Cannot be greater than Session Timeout (mins). |
|
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. |
|
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. |
|
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. |
To manage the parameters for external systems, select the System Control option and then System Parameters. Table 2-6 describes the available parameters.
Table 2-6 System Parameters Used to Manage External Systems
| Subtab | Parameter | Description |
|---|---|---|
|
Log On |
Min Length of Password |
Minimum length required for a password. This value must be at least 8. Default is 8. |
|
Log On |
Max Length of Password |
Maximum length required for a password. Default is 15. |
|
Log On |
Min Letters in Password |
Minimum number of letters required in a password. Default is 2. |
|
Log On |
Min Digits in Password |
Minimum number of digits required in a password. Default is 1. |
|
Log On |
Min Uppercase Characters in Password |
Minimum number of uppercase characters required in a password. Default is 1. |
|
Log On |
Min Lowercase Characters in Password |
Minimum number of lowercase characters required in a password. Default is 1. |
|
Log On |
Password must begin with a Letter |
If set to Yes, the password must begin with a letter. Default is No. |
|
Log On |
User Password History |
Number of past passwords the external system has defined. This prevents setting the password to a previous password. Default is 24. |
|
Log On |
Password Minimum Life |
Minimum number of days the password must be set before being changed. Default is 1. |
|
Log On |
Password Expiry Limit (days) |
Number of days a password can be used before it must be changed. Default is 180. |
|
Log On |
Password Grace Period (days) |
Number of days before the Password Expiry Limit is reached when the system starts prompting to change the password. Default is 21. |
|
Log On |
Max Login Attempts |
Sets the number of times an incorrect password can be submitted before the external system is locked out. This field is ignored if blank. Default is 5. |
|
Log On |
Notify Authority Profiles |
Sets the authority profiles of users to be notified (through the Task App, UIM, and email) of the expiry of an external system's password. At least one authority profile must be selected. Default is Password Administrator. |
|
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).
