Owner / Username Association Issues

[clintjb]

Describe the bug There are two topics linked to owners roles and the usernames being associated. Firstly after logging in and associating the username with an owner its impossible to remove that username after its been accepted by an admin. Secondly if a user is configured as an admin within the deployment configuration its still possible to remove the admin rights (it seems to ignore the deployment configuration)

Set up ODD Platform on K8s (23.1) utilizing HELM deployment

Steps to Reproduce

• Here you will see the logged in user (which is configured as an admin in the deployment config) associates themselves an owner (John Doe in this case)
• The owner you see has three roles (one of which is administrator)
• The user can than remove the admin role from that owner (you will see its successfully updated)
• After logging back in you will see there's no further access to create owners / edit etc which seems to imply the username configured within the deployment config is now being ignored.
• Please see images below for more details

Expected behavior

• Admins shouldn't be able to remove their own access / deployment config should remain
• On the edit owner tab a list of associated usernames should be shown and accordingly removable

Screenshots

[Vladysl]

Hi @clintjb Many thanks for you feed back,

On the edit owner tab a list of associated usernames should be shown and accordingly removable

We will investigate this and try to find a suitable solution.

Regarding ,

if a user is configured as an admin within the deployment configuration its still possible to remove the admin rights

This is expected because this user is an admin and can do anything. In case you cannot bring back your admin rights and you have access to your DB, I can suggest to you that you perform the following: 

1. Take a look at the administrator policies in the policy table, you need to find the administrator policy ID.
2. Check which role binded to admin policy in role_to_policy table
3. If there are no roles bound to the admin policy, you need to create one. (Select which role from the role table will be admin and add it to the role_to_policy table.)
4. Take a look at the roles in the role table; you need to find which role is bound to the administrator policy ID
5. Check which owner is bound to the admin role in owner_to_role table
6. If there is no owner bound to the admin role ID, you need to create one. (Select which owner from the owner table will be admin and add it to the owner_to_role.)
7. Take a look at the owners in the owner table; you need to find which owner is bound to the administrator role ID
8. Now you need to bind the user, which will be admin, with the owner ID. You need to take your username(take a look at screenshot) and add it to the user_owner_mapping table. Where owner_id = admin owner, oidc_username = your username, provider = provider, which used to login(google, github, cognito etc)

Once again, many thanks for your feedback

[clintjb]

Thanks very much for the clarification, regarding the second point, luckily we have no issues as we had multiple admins so could reassign over the GUI - we just felt it was potentially strange behavior as admins had the means to be locked out altogether.

The first point during our testing was potentially a larger issue as if people were accidentally assigned / authorized an owner role there was no easy way to remove it / or identify which username was assigned (without touching the DB) - look forward to seeing the proposal here - thanks!

[RamanDamayeu]

Proposed functionality:

Three tabs on "Associations"

1. New Requests 1.1 User - Owner - Role - Provider 1.2 Functionality to Accepted/Declined requests 1.3 Create Association
2. Active Associations 2.1 User - Owner - Role - Provider - Resolved by - Resolved At 2.2 Functionality to unlink existing associations
3. History (note, Read only) 3.1 User - Owner - Role - Provider - Resolved by - Resolved At

User Flows:

1. User wants to create an association to be linked to a specified Owner: 1.1 If Admin Accepts the request --> the record is added to "Active Associations" --> the record is added to "History" with status Accepted 1.2 If Admin Rejects the request --> the record is added to "History" tab only with status Declined
2. Admin wants to unlink the existing Association 2.1 On the "Active Associations" calls unlink functionality for a record --> Record disappears from "Active Associations" --> record is added to "History" with status Declined
3. Admin wants to create a new Association 3.1 On the "New Requests" tab Admin call the functionality to create an association --> the record is added to Active Associations --> the record is added to History with status Accepted
4. Admin wants to change Association for a given user 4.1 On the "New Requests" tab Admin call the functionality to create an association for the same user with a different Owner --> The system automatically unlinks existing Association --> record is added to History with the information that the Association has been Declined --> the record is added to Active Associations with the new owner assigned --> the record is added to History with the new association and status Accepted

@clintjb are you ok with this suggested implementation to create/update/delete associations between Users and Owners?

[Vladysl]

implemented in https://github.com/opendatadiscovery/odd-platform/pull/1638