Teams shown as &#34;Undefined&#34; after added by API, can&#39;be used as branch protection rule #14630

@ara-arowana commented on GitHub (Jun 23, 2025):

I am encountering the same problem, but not using the API but the Web UI. I can only add a team to a branch protection rule, if I gave it "Administrator Access". Granting "General Access" and ticking "write" for every row in the permission table is not enough.

I guess, either "Code" or "Projects" write access should be enough to add a team to a branch protection rule.

The issue seems to be, that the branch protection looks for the "authorize" field in the team database table. Changing the permission table does not mutate that field, only granting the team Administrator access sets the value to 4.

One can "upgrade" a team by executing update team set authorize=2 where id=<id>; (2 is sufficient, 3 or 4 work as well).

This seems undocumented or buggy to me, but should be an easy fix.

@ara-arowana commented on GitHub (Jun 23, 2025): I am encountering the same problem, but not using the API but the Web UI. I can only add a team to a branch protection rule, if I gave it "Administrator Access". Granting "General Access" and ticking "write" for every row in the permission table is not enough. I guess, either "Code" or "Projects" write access should be enough to add a team to a branch protection rule. The issue seems to be, that the branch protection looks for the "authorize" field in the team database table. Changing the permission table does not mutate that field, only granting the team Administrator access sets the value to 4. One can "upgrade" a team by executing `update team set authorize=2 where id=<id>;` (2 is sufficient, 3 or 4 work as well). This seems undocumented or buggy to me, but should be an easy fix.

GiteaMirror commented

@smoslinux commented on GitHub (Jun 23, 2025):

  # Add teams to repo
  curl -X 'PUT' \
    "https://git..com/api/v1/repos/projects/${REPO_NAME}/teams/${REPO_NAME}-leads?access_token=${API_TOKEN}" \
    -H 'accept: application/json'

  curl -X 'PUT' \
    "https://git..com/api/v1/repos/projects/${REPO_NAME}/teams/${REPO_NAME}?access_token=${API_TOKEN}" \
    -H 'accept: application/json'


  curl -X 'POST' \
    "https://git..com/api/v1/orgs/projects/teams?token=${API_TOKEN}" \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -d '{
    "can_create_org_repo": false,
    "description": "'${REPO_NAME}'-leads",
    "includes_all_repositories": false,
    "name": "'${REPO_NAME}'-leads",
    "permission": "write",
    "units": [
      "repo.code",
      "repo.issues",
      "repo.ext_issues",
      "repo.wiki",
      "repo.pulls",
      "repo.releases",
      "repo.projects",
      "repo.ext_wiki"
    ]
  }'

    curl -X 'POST' \
    "https://git.dsstaging1.com/api/v1/orgs/projects/teams?token=${API_TOKEN}" \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -d '{
    "can_create_org_repo": false,
    "description": "'${REPO_NAME}'",
    "includes_all_repositories": false,
    "name": "'${REPO_NAME}'",
    "permission": "write",
    "units": [
      "repo.code",
      "repo.issues",
      "repo.ext_issues",
      "repo.wiki",
      "repo.pulls",
      "repo.releases",
      "repo.projects",
      "repo.ext_wiki"
    ]
  }'

@smoslinux commented on GitHub (Jun 23, 2025): ``` # Add teams to repo curl -X 'PUT' \ "https://git..com/api/v1/repos/projects/${REPO_NAME}/teams/${REPO_NAME}-leads?access_token=${API_TOKEN}" \ -H 'accept: application/json' curl -X 'PUT' \ "https://git..com/api/v1/repos/projects/${REPO_NAME}/teams/${REPO_NAME}?access_token=${API_TOKEN}" \ -H 'accept: application/json' curl -X 'POST' \ "https://git..com/api/v1/orgs/projects/teams?token=${API_TOKEN}" \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "can_create_org_repo": false, "description": "'${REPO_NAME}'-leads", "includes_all_repositories": false, "name": "'${REPO_NAME}'-leads", "permission": "write", "units": [ "repo.code", "repo.issues", "repo.ext_issues", "repo.wiki", "repo.pulls", "repo.releases", "repo.projects", "repo.ext_wiki" ] }' curl -X 'POST' \ "https://git.dsstaging1.com/api/v1/orgs/projects/teams?token=${API_TOKEN}" \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "can_create_org_repo": false, "description": "'${REPO_NAME}'", "includes_all_repositories": false, "name": "'${REPO_NAME}'", "permission": "write", "units": [ "repo.code", "repo.issues", "repo.ext_issues", "repo.wiki", "repo.pulls", "repo.releases", "repo.projects", "repo.ext_wiki" ] }' ```

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 23, 2025):

Which page is it from?

@wxiaoguang commented on GitHub (Jun 23, 2025): <img alt="Image" width="253" src="https://private-user-images.githubusercontent.com/19647960/457379664-17472936-fe60-49e2-995d-68a150781642.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NTA2OTQxNjAsIm5iZiI6MTc1MDY5Mzg2MCwicGF0aCI6Ii8xOTY0Nzk2MC80NTczNzk2NjQtMTc0NzI5MzYtZmU2MC00OWUyLTk5NWQtNjhhMTUwNzgxNjQyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA2MjMlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNjIzVDE1NTEwMFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTVkNWY5YzIwZGJkMjRjYWMwMTBhZDAwY2FkZmE4OGQzZTA0N2M3ZDk1ZGNiNDdlOTM0NDEzOTFjODcxMDFhMDgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.CEiFwtl7RG__jL0BDztaHyoFmy8uBddzt0F8_6r2kYg"> Which page is it from?

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 23, 2025):

I think I know the problem now, will take a look.

One can "upgrade" a team by executing update team set authorize=2 where id=<id>; (2 is sufficient, 3 or 4 work as well).

Curious: according to my test, setting it to 1 (read) works. But I think it shouldn't be 3 (admin) or 4 (owner)

@wxiaoguang commented on GitHub (Jun 23, 2025): I think I know the problem now, will take a look. > One can "upgrade" a team by executing `update team set authorize=2 where id=<id>;` (2 is sufficient, 3 or 4 work as well). Curious: according to my test, setting it to `1` (read) works. But I think it shouldn't be 3 (admin) or 4 (owner) <details> ![Image](https://github.com/user-attachments/assets/5faf61ad-1514-4923-a85a-4be9bcf9ac4c) </details>

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 23, 2025):

I think this fix will make the result right: Fix querying teams by permission #34827

(A temp workaround can be update the "team.authorize=1" in database .....)

@wxiaoguang commented on GitHub (Jun 23, 2025): I think this fix will make the result right: Fix querying teams by permission #34827 (A temp workaround can be update the "team.authorize=1" in database .....)

GiteaMirror commented

@smoslinux commented on GitHub (Jun 23, 2025):

I am encountering the same problem, but not using the API but the Web UI. I can only add a team to a branch protection rule, if I gave it "Administrator Access". Granting "General Access" and ticking "write" for every row in the permission table is not enough.

I guess, either "Code" or "Projects" write access should be enough to add a team to a branch protection rule.

The issue seems to be, that the branch protection looks for the "authorize" field in the team database table. Changing the permission table does not mutate that field, only granting the team Administrator access sets the value to 4.

One can "upgrade" a team by executing update team set authorize=2 where id=<id>; (2 is sufficient, 3 or 4 work as well).

This seems undocumented or buggy to me, but should be an easy fix.

It was version 1.23.X, not the latest. After I upgraded to the latest version quickly, I had a similar issue like this one haha.

@smoslinux commented on GitHub (Jun 23, 2025): > I am encountering the same problem, but not using the API but the Web UI. I can only add a team to a branch protection rule, if I gave it "Administrator Access". Granting "General Access" and ticking "write" for every row in the permission table is not enough. > > I guess, either "Code" or "Projects" write access should be enough to add a team to a branch protection rule. > > The issue seems to be, that the branch protection looks for the "authorize" field in the team database table. Changing the permission table does not mutate that field, only granting the team Administrator access sets the value to 4. > > One can "upgrade" a team by executing `update team set authorize=2 where id=<id>;` (2 is sufficient, 3 or 4 work as well). > > This seems undocumented or buggy to me, but should be an easy fix. It was version 1.23.X, not the latest. After I upgraded to the latest version quickly, I had a similar issue like this one haha.

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 23, 2025):

Sorry for the regression ... the "team permission" system has some legacy problems.

By the way, do you know which page is it ? https://github.com/go-gitea/gitea/issues/34793#issuecomment-2997013682 I can't remember or find it ..... I'd like to double-check it to see whether #34827 fixes the "Undefined" problem.

@wxiaoguang commented on GitHub (Jun 23, 2025): Sorry for the regression ... the "team permission" system has some legacy problems. By the way, do you know which page is it ? https://github.com/go-gitea/gitea/issues/34793#issuecomment-2997013682 I can't remember or find it ..... I'd like to double-check it to see whether #34827 fixes the "Undefined" problem.

GiteaMirror commented

@lunny commented on GitHub (Jun 23, 2025):

I can reproduce it.

2025/06/23 16:45:54 HTTPRequest [I] router: completed GET /repo/search?sort=updated&order=desc&uid=1&team_id=undefined&q=&page=1&limit=15&mode=&archived=false for [::1]:58545, 200 OK in 3.7ms @ repo/repo.go:459(repo.SearchRepo)

@lunny commented on GitHub (Jun 23, 2025): I can reproduce it. ```log 2025/06/23 16:45:54 HTTPRequest [I] router: completed GET /repo/search?sort=updated&order=desc&uid=1&team_id=undefined&q=&page=1&limit=15&mode=&archived=false for [::1]:58545, 200 OK in 3.7ms @ repo/repo.go:459(repo.SearchRepo) ```

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 24, 2025):

I can reproduce it.

2025/06/23 16:45:54 HTTPRequest [I] router: completed GET /repo/search?sort=updated&order=desc&uid=1&team_id=undefined&q=&page=1&limit=15&mode=&archived=false for [::1]:58545, 200 OK in 3.7ms @ repo/repo.go:459(repo.SearchRepo)

@lunny I don't understand how could it be related. I am asking about the UI, the "Undefined" teams list UI https://github.com/go-gitea/gitea/issues/34793#issuecomment-2997013682 . Your comment is just a backend URL which returns JSON response.

@wxiaoguang commented on GitHub (Jun 24, 2025): > I can reproduce it. > > ``` > 2025/06/23 16:45:54 HTTPRequest [I] router: completed GET /repo/search?sort=updated&order=desc&uid=1&team_id=undefined&q=&page=1&limit=15&mode=&archived=false for [::1]:58545, 200 OK in 3.7ms @ repo/repo.go:459(repo.SearchRepo) > ``` @lunny I don't understand how could it be related. I am asking about the **UI**, the "Undefined" teams list **UI** https://github.com/go-gitea/gitea/issues/34793#issuecomment-2997013682 . Your comment is just a backend URL which returns JSON response.

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 24, 2025):

OK, I found it, this page. The translation is not right here.

The problem is that in old days, there was only "team permission".

But later, Gitea started to use "team unit permission" and deprecated the "team permission".

Then "team permission" isn't able to be correctly display at some places, will try to fix.

Update: also fixed now:

@wxiaoguang commented on GitHub (Jun 24, 2025): OK, I found it, this page. The translation is not right here. The problem is that in old days, there was only "team permission". But later, Gitea started to use "team unit permission" and deprecated the "team permission". Then "team permission" isn't able to be correctly display at some places, will try to fix. ---- Update: also fixed now: <details> ![Image](https://github.com/user-attachments/assets/7a87b09f-f55b-49c9-8a37-7c9da3b4a1e1) </details>

GiteaMirror commented

@smoslinux commented on GitHub (Jun 24, 2025):

Yup. Thanks!

@smoslinux commented on GitHub (Jun 24, 2025): Yup. Thanks!

GiteaMirror commented

@KarenArzumanyan commented on GitHub (Jun 24, 2025):

"team.authorize=1" - for read acess
"team.authorize=2" - for write acess

Now i fix in Database and wait new version Gieta.

Thanks.

@KarenArzumanyan commented on GitHub (Jun 24, 2025): "team.authorize=1" - for read acess "team.authorize=2" - for write acess Now i fix in Database and wait new version Gieta. Thanks.

GiteaMirror commented

@wxiaoguang commented on GitHub (Jun 24, 2025):

~~The 1.24 nightly build is ready (it is a stable release and will be 1.24.3. soon), it contains the backport:~~ Fix team permissions (#34827) #34836

Update: Oops, not ready yet ... there are other pending PRs ......

To track the nightly build, follow the 1.24 branch: https://github.com/go-gitea/gitea/commits/release/v1.24 , when new commit gets 3/3 success status, then they are ready .....

(sorry for bothering)

@wxiaoguang commented on GitHub (Jun 24, 2025): ~~The 1.24 nightly build is ready (it is a stable release and will be 1.24.3. soon), it contains the backport:~~ Fix team permissions (#34827) #34836 * https://dl.gitea.com/gitea/1.24-nightly/ * https://hub.docker.com/r/gitea/gitea/tags?name=1.24-nightly ---- Update: Oops, not ready yet ... there are other pending PRs ...... To track the nightly build, follow the 1.24 branch: https://github.com/go-gitea/gitea/commits/release/v1.24 , when new commit gets 3/3 success status, then they are ready ..... (sorry for bothering)

GiteaMirror commented