Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API: allow list collaborators for users with Read access to repo #9956

Closed
lkraider opened this issue Jan 24, 2020 · 8 comments
Closed

API: allow list collaborators for users with Read access to repo #9956

lkraider opened this issue Jan 24, 2020 · 8 comments
Labels
type/enhancement An improvement of existing functionality
Milestone

Comments

@lkraider
Copy link

lkraider commented Jan 24, 2020

This is a request to allow org team users with read access to repos to get the list of collaborators via API from that repo.

Details below:

API response: 403 | Error: Forbidden

Description

A user with Read access to a repo is unable to GET the list of collaborators.

This request is required by the Gitea Jenkins Plugin to process the PRs automatically.

It is currently an open issue there as well: https://issues.jenkins-ci.org/browse/JENKINS-60017
Also related to this issue on Jenkins-X: jenkins-x/jx#432

@zeripath
Copy link
Contributor

The problem lies here:

gitea/routers/api/v1/api.go

Lines 644 to 649 in f6067a8

m.Group("/collaborators", func() {
m.Get("", repo.ListCollaborators)
m.Combo("/:collaborator").Get(repo.IsCollaborator).
Put(bind(api.AddCollaboratorOption{}), repo.AddCollaborator).
Delete(repo.DeleteCollaborator)
}, reqToken(), reqAdmin())

The get collaborators list should be available to reporeaders I guess.

@davidsvantesson
Copy link
Contributor

I think the reasoning for the access has been that in the UI only repo admin can see who is collaborator. But I think it would make sense other collaborators can see it.

I don't know why the Jenkins plugin need this information, but another problem is there is no option to include also team members with access in the API response.

@lafriks lafriks added the type/enhancement An improvement of existing functionality label Feb 27, 2020
@lafriks lafriks added this to the 1.12.0 milestone Feb 27, 2020
@gruo
Copy link

gruo commented Mar 10, 2020

In my opinion Jenkins queries the collaborators for determining trust of the particular PR of forks.

@keeakita
Copy link

keeakita commented Mar 29, 2020

FWIW for the Jenkins plugin, this can be "worked around" by granting admin permissions to the Gitea user that jenkins is authenticating as. But this is awkward to have a service user be so privileged.

Would it be possible to add a granular permission for listing collaborators? I can see in the UI when granting read permissions there are toggles for specific resources (wikis, issues, etc). It'd be nice to have an extra checkbox here for collaborators.

@guillep2k
Copy link
Member

I agree with @davidsvantesson: "collaborators" is not even useful if the access is managed through teams. We should know more about this requirement and make a better suited solution. In the long term we should have profiles specifically designed for robots, plugins, etc. (e.g. read access to most of the info, write access to only a subset).

@lunny
Copy link
Member

lunny commented May 2, 2020

Didn't #9995 resolved this one?

@keeakita
Copy link

keeakita commented May 5, 2020

I'm not sure how version strings are managed, but on the latest Docker image with version string 1.12.0+dev-266-gd9de58bee, I can confirm that I'm now able to use the Jenkins plugin with a read-only user. So I believe #9995 did in fact fix this.

Though it may be worth keeping this issue open (or maybe opening a new one?) to track the long term work of rethinking how/why the plugin is listing collaborators in this way in the first place.

@guillep2k
Copy link
Member

I'll close this for the time being. Feel free to reopen it if you find it's actually not fixed by 1.12.0. 😄

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/enhancement An improvement of existing functionality
Projects
None yet
Development

No branches or pull requests

8 participants