[jira] [Commented] (RANGER-5623) UI Inconsistency: Groups tab userlist fails to reflect updated user-group mapping after successful PUT /xusers/groupusers request

["Krishna Chaitanya Muttevi (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RANGER-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18085159#comment-18085159 ] 

Krishna Chaitanya Muttevi commented on RANGER-5623:
---------------------------------------------------

While investigating, I also noticed that the {{PUT /service/xusers/groupusers}} endpoint lacks backend validation to check if the target group mentioned in payload actually exists. Instead of properly updating the relational link to a valid group entity, the API seems to blindly overwrite the group name string within the user's group list. This missing validation allows users to be associated with nonexistent groups.

> UI Inconsistency: Groups tab userlist fails to reflect updated user-group mapping after successful PUT /xusers/groupusers request
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: RANGER-5623
>                 URL: https://issues.apache.org/jira/browse/RANGER-5623
>             Project: Ranger
>          Issue Type: Bug
>          Components: Ranger
>    Affects Versions: 3.0.0
>            Reporter: Krishna Chaitanya Muttevi
>            Priority: Major
>
> When updating an existing user-group relationship via the {{PUT /service/xusers/groupusers}} API, the backend processes the change successfully. The UI's "Users" tab correctly reflects the updated group association for the user. However, the "Groups" tab fails to update and displays stale data, keeping the user listed under the old group and omitting them from the new group.
> This indicates a localized state management or caching issue specifically within the "Groups" tab component of the web interface.
> h3. *Steps to Reproduce:*
>  # *Create a new user-group relation (User 17 to 'opensearch'):*
>  
>  {{curl -iu admin:***** -X POST 'http://localhost:6080/service/xusers/groupusers' \  -H 'accept: application/json' -H 'Content-Type: application/json' \ -d '\{"name":"opensearch", "userId": 17}' }}
> _Backend returns 200 OK, creating relation_ {{{}id: 52{}}}{_}.{_}
>  # *Update the existing relation to a different group (User 17 to 'ranger'):*
>  
>  {{curl -iu admin:***** -X PUT 'http://localhost:6080/service/xusers/groupusers' \   -H 'Content-Type: application/json' \   -d '\{"id": 52, "name": "ranger", "userId": 17}'}}
> _Backend returns 200 OK, confirming the update._
>  # *Verify backend state via GET:*
>  
>  {{curl -iu admin:***** -X GET 'http://localhost:6080/service/xusers/groupusers/52'}}
> _Backend correctly returns_ {{{}{"id":52, ... "name":"ranger","userId":17}{}}}{_}.{_}
>  # *Observe the UI behavior:*
>  * Navigate to {*}Settings > Users/Groups/Roles{*}.
>  * Check the *Users* tab: User 17 is correctly shown under the {{ranger}} group.
>  * Check the *Groups* tab: Inspect the user lists for both the {{opensearch}} and {{ranger}} groups.
> h3. *Expected Behavior:*
> Both the "Users" tab and the "Groups" tab should remain synchronized with the backend. In the "Groups" tab, User 17 should be removed from the {{opensearch}} user list and added to the {{ranger}} user list immediately.
> h3. *Actual Behavior:*
> The "Users" tab reflects the correct backend state, but the "Groups" tab does not. The "Groups" tab UI retains stale data, ignoring the {{PUT}} mutation until a hard refresh or application cache invalidation occurs.
> Here the ranger group’s user list not updated:
> !https://media-cdn.atlassian.com/file/09ff5aaf-d3a1-4be5-a747-4d3d9f2be930/image/cdn?allowAnimated=true&client=b47d7f8e-a692-4580-bc50-5af50f9cf45a&collection=&height=125&max-age=2592000&mode=full-fit&source=mediaCard&token=eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJiNDdkN2Y4ZS1hNjkyLTQ1ODAtYmM1MC01YWY1MGY5Y2Y0NWEiLCJhY2Nlc3MiOnsidXJuOmZpbGVzdG9yZTpmaWxlOjA5ZmY1YWFmLWQzYTEtNGJlNS1hNzQ3LTRkM2Q5ZjJiZTkzMCI6WyJyZWFkIl0sInVybjpmaWxlc3RvcmU6ZmlsZTo1ZGFhN2I0Mi01MjQ4LTRhMWQtYTkzZC1iMjUyZDhhYzVkOGYiOlsicmVhZCJdLCJ1cm46ZmlsZXN0b3JlOmZpbGU6MzM2NjYzMDItOWI2Ni00YjdkLTgwMGMtOWQ1YmM1YTJiMGEzIjpbInJlYWQiXSwidXJuOmZpbGVzdG9yZTpmaWxlOmM1ODgzZjc4LTU4MDgtNDk0YS05OWI3LTAyZjU1NzJkZjMyNCI6WyJyZWFkIl19LCJleHAiOjE3ODAzMDUzMTgsIm5iZiI6MTc4MDMwNDQxOCwiYWFJZCI6IjcxMjAyMDpkZTVlNDE1Mi1mYmU2LTRkZWMtYmI4Yy1lNjhmZmMyMzIwZTEiLCJodHRwczovL2lkLmF0bGFzc2lhbi5jb20vYXBwQWNjcmVkaXRlZCI6ZmFsc2V9.i0KbzpEqJNL2zC3Q9mUyh771l6BlLHZ312P6c14ywvk&width=687#media-blob-url=true&id=09ff5aaf-d3a1-4be5-a747-4d3d9f2be930&clientId=b47d7f8e-a692-4580-bc50-5af50f9cf45a&contextId=&collection=!
> But om’s groupList is updated correctly.
> !https://media-cdn.atlassian.com/file/33666302-9b66-4b7d-800c-9d5bc5a2b0a3/image/cdn?allowAnimated=true&client=b47d7f8e-a692-4580-bc50-5af50f9cf45a&collection=&height=125&max-age=2592000&mode=full-fit&source=mediaCard&token=eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJiNDdkN2Y4ZS1hNjkyLTQ1ODAtYmM1MC01YWY1MGY5Y2Y0NWEiLCJhY2Nlc3MiOnsidXJuOmZpbGVzdG9yZTpmaWxlOjA5ZmY1YWFmLWQzYTEtNGJlNS1hNzQ3LTRkM2Q5ZjJiZTkzMCI6WyJyZWFkIl0sInVybjpmaWxlc3RvcmU6ZmlsZTo1ZGFhN2I0Mi01MjQ4LTRhMWQtYTkzZC1iMjUyZDhhYzVkOGYiOlsicmVhZCJdLCJ1cm46ZmlsZXN0b3JlOmZpbGU6MzM2NjYzMDItOWI2Ni00YjdkLTgwMGMtOWQ1YmM1YTJiMGEzIjpbInJlYWQiXSwidXJuOmZpbGVzdG9yZTpmaWxlOmM1ODgzZjc4LTU4MDgtNDk0YS05OWI3LTAyZjU1NzJkZjMyNCI6WyJyZWFkIl19LCJleHAiOjE3ODAzMDUzMTgsIm5iZiI6MTc4MDMwNDQxOCwiYWFJZCI6IjcxMjAyMDpkZTVlNDE1Mi1mYmU2LTRkZWMtYmI4Yy1lNjhmZmMyMzIwZTEiLCJodHRwczovL2lkLmF0bGFzc2lhbi5jb20vYXBwQWNjcmVkaXRlZCI6ZmFsc2V9.i0KbzpEqJNL2zC3Q9mUyh771l6BlLHZ312P6c14ywvk&width=687#media-blob-url=true&id=33666302-9b66-4b7d-800c-9d5bc5a2b0a3&clientId=b47d7f8e-a692-4580-bc50-5af50f9cf45a&contextId=&collection=!



--
This message was sent by Atlassian Jira
(v8.20.10#820010)