UI preventing org repo creation as well if user org limit is reached #12712

New Issue

GiteaMirror · 2025-11-02T10:18:50-06:00

GiteaMirror commented

2025-11-02 10:18:50 -06:00

Originally created by @DrMaxNix on GitHub (Mar 22, 2024).

Scenario

On our instance we have MAX_CREATION_LIMIT = 0 to prevent random new users from spamming our instance
There is an org which has a few members, which is being used for a collaborative project. These members should only be able to create repos inside this org, but not under their user account.
Users have been put into a team Dev which has Create repositories enabled

Problem

On the repo create page, the submit button Create Repository is disabled in case CanCreateRepo == false: 5c91d7920f/templates/repo/create.tmpl (L212)
CanCreateRepo checks whether the user already has too many personal repos: 5c91d7920f/models/user/user.go (L240-L251)
But the submit button will be disabled for all available repo owners; Personal and also Orgs!
This means the UI will not allow users to create org repos even though they have the Create repositories permission in their org!
EDIT: This problem also affects repos which are created from migrations (this however is a backend issue!)

Solutions

This is only a UI bug, the backend validation works as expected (I have tested this by removing the previously mentioned disable check from the template to force the button to be always enabled)
The CanCreateRepo value should only influence creation of a personal repo
Repo limit of the org is only checked after the form is submitted, this would be a good quick-fix for this issue (removing the disabled button check and the error banner from the template)
For a long term solution we could hide the personal user account in the owners list the same way orgs are hidden when their limit is reached. This would make the disabled submit button and the banner completely obsolete, as the user is forced to select an owner that is allowed to have more repos created

Note that I was not able to reproduce the issue on the demo instance, because there is no repo count limit and also it seems like you can't create orgs there..

Screenshots

Trying to create a new repo testrepo45 under testorg organization, note the banner telling me there is a limit:

Submit button is disabled:

Repo create works anyway when enabling the submit button by hand:

Gitea Version

v1.21.9

Originally created by @DrMaxNix on GitHub (Mar 22, 2024). ## Scenario - On our instance we have `MAX_CREATION_LIMIT = 0` to prevent random new users from spamming our instance - There is an org which has a few members, which is being used for a collaborative project. These members should only be able to create repos inside this org, but not under their user account. - Users have been put into a team `Dev` which has `Create repositories` enabled ## Problem - On the repo create page, the submit button `Create Repository` is disabled in case `CanCreateRepo == false`: https://github.com/go-gitea/gitea/blob/5c91d7920f4aff08768e274269e211e926aa3d36/templates/repo/create.tmpl#L212 - `CanCreateRepo` checks whether the user already has too many personal repos: https://github.com/go-gitea/gitea/blob/5c91d7920f4aff08768e274269e211e926aa3d36/models/user/user.go#L240-L251 - But the submit button will be disabled for all available repo owners; **Personal and also Orgs!** - This means the **UI will not allow users to create org repos** even though they have the `Create repositories` permission in their org! - EDIT: This problem also affects repos which are created from migrations (this however is a backend issue!) ## Solutions - This is only a UI bug, the backend validation works as expected (I have tested this by removing the previously mentioned disable check from the template to force the button to be always enabled) - The `CanCreateRepo` value should only influence creation of a personal repo - Repo limit of the org is only checked after the form is submitted, this would be a good quick-fix for this issue (removing the disabled button check and the error banner from the template) - For a long term solution we could hide the personal user account in the owners list the same way orgs are hidden when their limit is reached. This would make the disabled submit button and the banner completely obsolete, as the user is forced to select an owner that is allowed to have more repos created Note that I was not able to reproduce the issue on the demo instance, because there is no repo count limit and also it seems like you can't create orgs there.. ## Screenshots Trying to create a new repo `testrepo45` under `testorg` organization, note the banner telling me there is a limit: ![Screenshot from 2024-03-22 23-19-41](https://github.com/go-gitea/gitea/assets/38893656/30d1b1fd-565c-4eeb-aa67-83bc1ce6bec0) Submit button is disabled: ![Screenshot from 2024-03-22 23-19-29](https://github.com/go-gitea/gitea/assets/38893656/5b5f4720-56e5-4d39-ba57-fe71a62df2fe) Repo create works anyway when enabling the submit button by hand: ![Screenshot from 2024-03-22 23-19-56](https://github.com/go-gitea/gitea/assets/38893656/b93eebfe-5c23-4874-a2f8-3af3d55d0bb7) ## Gitea Version v1.21.9

GiteaMirror added the type/proposal label 2025-11-02 10:18:50 -06:00

GiteaMirror closed this issue

2025-11-02 10:18:50 -06:00

GiteaMirror commented

2025-11-02 10:18:51 -06:00

@a1012112796 commented on GitHub (Apr 1, 2024):

I has try fix it in https://github.com/go-gitea/gitea/pull/15924, but sadly looks no one think it's a bug :( . maybe need a beter design about how to limit repository number for org. or repo number limit will looks meaningless if all user can create orgs.

@a1012112796 commented on GitHub (Apr 1, 2024): I has try fix it in https://github.com/go-gitea/gitea/pull/15924, but sadly looks no one think it's a bug :( . maybe need a beter design about how to limit repository number for org. or repo number limit will looks meaningless if all user can create orgs.

GiteaMirror commented

2025-11-02 10:18:51 -06:00

@DrMaxNix commented on GitHub (Apr 1, 2024):

This is definitely a bug! The validation on the frontend does not match the validation in the backend!
If the behaviour of the ui is actually wanted (which would be really weird), the backend validation would be wrong, which would not only still be a bug, but also a security problem!!!

@DrMaxNix commented on GitHub (Apr 1, 2024): This is definitely a bug! The validation on the frontend does not match the validation in the backend! If the behaviour of the ui is actually wanted (which would be really weird), the backend validation would be wrong, which would not only still be a bug, but also a security problem!!!

GiteaMirror commented

2025-11-02 10:18:51 -06:00

@DrMaxNix commented on GitHub (Apr 7, 2025):

Partially fixed by #34030, Migrations still affected

@DrMaxNix commented on GitHub (Apr 7, 2025): Partially fixed by #34030, Migrations still affected

GiteaMirror commented

2025-11-02 10:18:51 -06:00

@wxiaoguang commented on GitHub (Apr 8, 2025):

Yes, it is a bug, and thank you very much for finding the fix!

ps; although #15924 was also proposed, but it is incomplete and didn't persuade others to really understand the problem ......

@wxiaoguang commented on GitHub (Apr 8, 2025): Yes, it is a bug, and thank you very much for finding the fix! ps; although #15924 was also proposed, but it is incomplete and didn't persuade others to really understand the problem ......

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#12712