21.11 Bidder Impact
Unifier 21.11 brings in feature enhancements with regards to the way bidders' passwords are stored and managed. The feature enhancements are in support of on-premises deployments where password management is handled by Unifier. This standardization impacts ‘username' creation for Cloud customers as explained in the relevant sections below. Customers should evaluate the information below, before upgrading.
What has changed?
- Bidders must access the bidder portal through the regular Unifier URL. The Bidder URL field in the Company Properties page has been removed.
- The old URLs will still work. If existing bidders use the old bidder portal URL, they will be redirected to the regular Unifier login URL.
- The landing page seen post login, is based on the user type in Unifier. When a user logs in and if the login username is an email address, then the system will check for user type associated with the username. If the username is tied to a vendor account in the Master Vendor List, then the bidder landing page will be seen.
Why was this change made?
- To meet enhanced security compliance standards
- To standardize and simplify the login process for password management and user authentication
- Ease of use – Bidders can now change their passwords on their own without having to rely on the bid package requestor
Who is affected?
- Unifier 21.11 requires unique “login usernames” across bidder users and standard users for authentication purposes
- The potential list of bidders known as Vendors, for a given company is stored in the Master Vendor List BP (Vendor) at the Company level. For bidders who are participating in a bid, the “login username” is same as the email address entered in the data element: uuu_user_id in Vendor BP at the company level
- The below table lists the possible scenarios where usernames are not unique
SCENARIO | IMPACT | RESOLUTION | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Applicable to both Cloud and On-Premise customers If the same email address is used in the uuu_user_id field of multiple Vendor records of the Master Vendor List. Existing behavior for Cloud customers – The vendor gets created as a bidder in Primavera Administration only when the vendor is invited for the very first time through an RFB process in the Proposal Management tab. There is no change to this behavior. | The vendor that was created first as a bidder, will be able to login to the bidder portal. Example:
When abc@company.com logs in to Unifier, the user is a member of C1_IN and not C1_US | Ensure that the vendor emails (data element: uuu_user_id) for all vendor records are unique. | ||||||||||||||||||||
Company Name | uuu_user_id | Vendor Record Creation Date | Invited as bidder on | |||||||||||||||||||
C1_US | abc@company.com | Jan1 2020 | Jan 31st 2020 | |||||||||||||||||||
C1_CN | abc@company.com | Jan1 2020 |
| |||||||||||||||||||
C1_UK | abc@company.com | Jan1 2020 |
| |||||||||||||||||||
C1_IN | abc@company.com | Jan1 2020 | Jan 15th 2020 | |||||||||||||||||||
If a Standard, Collaborator or Portal user is created first and then a vendor with the same username is invited to bid for the first time. Pre-21.11 behavior for Cloud customers – Primavera Administration will not create a bidder. Pre-21.11, such a user could login to the bidder portal using the same login credentials through the dedicated Bidder portal URL. Existing On-premise customers – Unifier sends a different password that can be used to login to the bidder portal. | For Cloud and on-premise customers – Since the bidder portal has been removed, the user will always be taken to the standard Unifier landing page. | If a user needs to be able to login as a Standard, Collaborator or Portal user as well as be able to respond to bids as a bidder, then the email addresses used for login must be different. The email address used in login username field of User Properties must be different from the one used in ‘uuu_user_id' field of the Vendor record.
|
Is there an easy way to find login usernames that are same between regular Unifier users and Vendors?
To access the article, go to "My Oracle Support" (https://support.oracle.com/portal/) and refer to the following knowledge management article: Enhancement on How Unifier Handles Bidder Passwords (Doc ID 2819828.1)
Is there any potential solution when email address cannot be changed?
Some email servers allow aliases in the email address. As an example, both abc@company.com and abc+1@company.com may be associated with a user “abc”. This user will receive emails when either of
the email address is used.
In Unifier, these are treated as two different usernames. As a result when email addresses are used as login usernames, the system will allow such logins.
Suggested action - Consult your company's IT administration to check if the above is a feasible solution.
What about issues post upgrade?
The below table lists the possible scenarios that may cause issues to the enhancement and how Unifier handles such situations:
SCENARIO | IMPACT | RESOLUTION |
---|---|---|
Creating a new vendor record with existing email address. | Once the user tries to save/submit a vendor record, Unifier checks if the entered email exists as the username for any other vendor and for any other Unifier user. If the entered email already exists, Unifier does not allow the user to save/submit the record. | User must change the email (data element: uuu_user_id) and resubmit the record. |
Creating a new company user or partner user. | If an Administrator tries to create the username with existing username (across regular users and bidder emails), then Unifier checks for any duplicates and does not allow the creation of a new user. | User should ensure to use a unique username for every user. |
What are the other changes?
Bidder credentials
Bidders can still use the existing credentials to log into Unifier bidder portal.
Send Password Functionality (Applicable only for on-premises and not for Cloud customers)
With 21.11, bidders will be allowed to manage passwords by themselves.
Since bidders can now reset their own passwords, bid package requestors (RFB record owners) need not send passwords to bidder users. Hence, Send Password functionality will be removed from these places in RFB record: Proposal Management tab-Action menu options and in the Record Details tab of the Comparison sheet.
Send password: Pre-21.11 on left and Post 21.11 on the right
Comparison Sheet: Pre-21.11 on left and Post 21.11 on the right
Last Published Thursday, December 14, 2023