gitea
gitea copied to clipboard
go-gitea
API endpoint `/repos/{owner}/{repo}/teams` does not support `page` and `limit` queries
Description
The API documentation indicates that the /repos/{owner}/{repo}/teams endpoint does not support page and limit queries which is surprising because all other repos/{owner}/{repo}/* seem to implement this mechanism.
I do not know if this is a bug or "a feature" ?
Gitea Version
1.21.2
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
Linux Mint, EndeavourOS
How are you running Gitea?
Official binaries, and running from systemd and command-line
Database
SQLite
https://github.com/go-gitea/gitea/blob/7047df36d4c39fefa6464b713c66302aa0038123/models/organization/team_list.go#L100-L108
There are no page and limit queries in the implement
So, all teams of the repository will be returned right ? Would it make sense to add the page/limit mechanism in this endpoint too ? If not, there is no need to keep this issue open I guess
I doubt there is a real requirement to get a pagination for the repository's team? How many teams is there on this repository?
Sorry for the late reply o(x_x)o
I work at a cybersecurity school which uses Gitea and a custom CI/CD backend to allow students to be corrected automatically (and the correction report is displayed in the action section).
But since we do not want students to do anything with their deposits (like cheating by cloning other student's repository), we need to ensure that:
- Year groups are represented as an Organisation
- Each student should see only their repositories
- Each student should not be able to edit the configuration of the repository
- Each student should not be able to create release since releases are used as a “final” project report
- Only “administrator” can archive or unarchive repository
- … and some other constraints that don’t matter here
To do the “student isolation”, I have created an unique team with only “code writing” access for each students (we have ~200 students per year group) (I use team since the default collaborator interface does not provide the same granularity in configuration as the team interface (?)). This allows us to create a repository and add the targeted student as a team that can only modify the source code of the project. Moreover, if students go to their year group’s organisation they will only see their repositories (which prevents easy cheating).
But, we may request to have special repositories with resources for specific classrooms, which may include dozens of students. And in this case we may need to have pagination for the repositories' team… But I think that it seems to be very specific to our needs and absolutely non critical for now.
So, this issue can be closed if no one needs this feature. This message is only here to give an example of why we may have many teams in a repository.
OK. I understand your requirements. I think 200 returned records is not a big deal for API requests and you can also reduce requests because paginations?
Theoretically yes, the pagination may help to reduce API requests in some cases, but it's just subtle details that are really not important for now. We can close this issue.
The thing is that API endpoints that do not support query parameters such as teams (e.g /repos/{owner}/{repo}/teams?page=X) or release assets (e.g. /repos/{owner}/{repo}/releases/{id}/assets?page=X) always return success status (200) with empty data which can be counter intuitive. Maybe return 202 or 204 status instead to add more explicit context ?
We close issues that need feedback from the author if there were no new comments for a month. :tea:
