Rest API invalid output compared to UI

[sgabenov]

Description

Hi all,

The Gitea REST API {{baseUrl}}/repos/:owner/:repo/branch_protections/:name returns invalid output compared to the data that is shown in UI.
For instance, we have a repo with protected branch "master". Initially we have added several users for "merge_whitelist_usernames" with user "vasiliy.chipizhin" included into this list. Then this user was retired and we have deleted his account from "merge_whitelist_usernames". It was done several month ago and we have already restarted gitea instance since that time. In Gitea UI i do not see this user account in the whitelist section. But when i use REST API to get list of users, i do see this user account "vasiliy.chipizhin" in API respoce

Postman responce:
"vasiliy.chipizhin" account is presented

Gitea UI:
"vasiliy.chipizhin" account is absent

Gitea Version

1.20.0

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

docker

Database

PostgreSQL

[sgabenov]

The auth source is LDAP. Users are created automatically by cron sync with ldap

[edwardzhanged]

That's possible. When the backend of API and web both return the same user IDs, API just looks up the usernames in db with those IDs and then returns them but the web frontend adds the para is_active=1 and then queries them. So a possible reproduction procedure: deactivate the user but not delete the user from the whitelist. Will fix it later. (with some tests)

I can't seem to find any is_active=1 parameter in the frontend logic. Here's what I've discovered:

• Frontend logic: It renders the merge_whitelist_users from Users, while users are queried from getUsersWithAccessMode with a readAccess condition. Then, it renders the whitelisted user corresponding to the userIds from the protected_branch table.
• Backend logic: It directly queries the protected_branch table and uses GetUserNamesByIDs to fill the whitelist usernames into the API response.

I suspect the root cause may be that LDAP downgraded the user's permission to 0 (Can LDAP do that?), or the admin manually changed the user's permission to unread. ( @sgabenov, could you confirm this please?) . This might be causing the frontend to fail to retrieve all the users.

I'm not certain if this issue should be labeled as a bug. According to GitLab documentation about deactivated user

When you deactivate a user, their projects, groups, and history remain.

However, it might be better for the backend API to find the whitelist users with a readAccess condition as well. This would unify the logic for both the backend and frontend.

Happy to provide a pr for that.

[lunny]

That's possible. When the backend of API and web both return the same user IDs, API just looks up the usernames in db with those IDs and then returns them but the web frontend adds the para is_active=1 and then queries them. So a possible reproduction procedure: deactivate the user but not delete the user from the whitelist. Will fix it later. (with some tests)

I can't seem to find any is_active=1 parameter in the frontend logic. Here's what I've discovered:

* Frontend logic:  It renders the `merge_whitelist_users` from `Users`, while users are queried from `getUsersWithAccessMode` with a readAccess condition. Then, it renders the whitelisted user corresponding to the userIds from the protected_branch table.

* Backend logic:  It directly queries the protected_branch table and uses `GetUserNamesByIDs` to fill the whitelist usernames into the API response.

I suspect the root cause may be that LDAP downgraded the user's permission to 0 (Can LDAP do that?), or the admin manually changed the user's permission to unread. ( @sgabenov, could you confirm this please?) . This might be causing the frontend to fail to retrieve all the users.

I'm not certain if this issue should be labeled as a bug. According to GitLab documentation about deactivated user

When you deactivate a user, their projects, groups, and history remain.

However, it might be better for the backend API to find the whitelist users with a readAccess condition as well. This would unify the logic for both the backend and frontend.

Happy to provide a pr for that.

Thank you for the contribution.