API endpoint `/repos/{owner}/{repo}/teams` does not support `page` and `limit` queries

[YannMagnin]

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

[CaiCandong]

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

[YannMagnin]

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

[lunny]

I doubt there is a real requirement to get a pagination for the repository's team? How many teams is there on this repository?

[YannMagnin]

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.

[lunny]

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?

[YannMagnin]

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 ?

[GiteaBot]

We close issues that need feedback from the author if there were no new comments for a month. :tea: