Branch protection user/team dropdowns do not list everyone #20083
Comments
|
Could you confirm all of the 9 members have read permissions to that repository? |
Yes. So here is a Team permissions: |
Fogapod
changed the title
|
|
|
I've looked into the issue and the code for this is correct and straightforward. But it's likely that you didn't add the teams to the repository(otherwise other issues would arise if this is already the case). Also for the 404's it's not reproducible for me. |
|
it has access to that repository. it is the only team that grants write access. we wouldn't be able to push code if it wasn't the case. people have write and read access because they are in team but they are not listed: today i've got 4 different users shown in that list. still not everyone: |
|
Is the list scrollable? |
|
unchecking any of these results in 3 people shown, not scrollable. i can reliably reproduce this by switching any permission. i have a similar issue with package registry: #19986 |
- Currently when a Team has read access to a organization's non-private repository, their access won't be stored in the database. This caused issue for code that rely on read access being stored. So from now-on if we see that the repository is owned by a organization don't increase the minMode to write permission. - Resolves go-gitea#20083
|
So it seems like the code was correct, however the code to store the access information into the database wasn't. Fixed by #20275 |
- Backport go-gitea#20275 - Currently when a Team has read access to a organization's non-private repository, their access(in the `access` table) won't be stored in the database. This cause issues for code that rely on read access being stored, like retrieving all users who have read permission to that repository(even though this is confusing as this doesn't include all registered users). So from now-on if we see that the repository is owned by a organization don't increase the `minMode` to write permission. - Resolves go-gitea#20083
Backport #20275 Currently when a Team has read access to a organization's non-private repository, their access(in the `access` table) won't be stored in the database. This cause issues for code that rely on read access being stored, like retrieving all users who have read permission to that repository(even though this is confusing as this doesn't include all registered users). So from now-on if we see that the repository is owned by a organization don't increase the `minMode` to write permission. Resolves #20083
- Currently when a Team has read access to a organization's non-private repository, their access won't be stored in the database. This caused issue for code that rely on read access being stored. So from now-on if we see that the repository is owned by a organization don't increase the minMode to write permission. - Resolves #20083
- Currently when a Team has read access to a organization's non-private repository, their access won't be stored in the database. This caused issue for code that rely on read access being stored. So from now-on if we see that the repository is owned by a organization don't increase the minMode to write permission. - Resolves go-gitea#20083
Description
I tried setting up whitelists for branch protection but dropdowns only list 4 out of 9 org members. Text search only searches among these 4.
Similar thing happened to teams - one of the teams wasnt showing. It worked after team recreation.
I noticed that each of these 4 members is on top of user list of some team. Membership from top to bottom for 1st screenshot:
Gitea Version
1.17.0+rc1
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
Locally compiled binary
Database
PostgreSQL
The text was updated successfully, but these errors were encountered: