I’m sorry if this is not the best place to ask this question, and even more so if this question has been answered before or is documented somewhere. My googling skills didn’t yield the answers I needed.
I want to use gitea to only
release and host opensource code.
track issues submitted by our opensource and paying users.
Gitea does #1 splendidly well. However, I’m not sure how (or if) I can make gitea do #2. The issue is that new users can also create new repositories and organizations. I want to restrict any new user to only opening issues and replying to them.
My questions can be stated as follows:
Is it possible to configure Gitea to only grant limited privileges to new users? At least restricting them from creating new repositories and organizations.
Assuming there is, can such users’ privileges be later expanded by an admin?
(tangentially related) Some code hosting solutions allow the submission of new issues by anonymous/unregistered users. Does Gitea support a scheme like this?
Again, I apologize if this was not the right place to post these questions.
Going over /custom/conf/app.ini.sample, it seems that I can use DISABLE_REGULAR_ORG_CREATION (and/or DEFAULT_ALLOW_CREATE_ORGANIZATION?) to prevent users from setting up new organizations. So that one issue that has a resolution. This only leaves the issue of controlling repositories.
MAX_CREATION_LIMIT : -1 : Global maximum creation limit of repositories per user, -1 means no limit.
This implies that disabling the creation of repositories for users is possible by setting that value to 0. This also implies (by the use of the word “Global”) that there is a local, per-user setting. Where can I configure the per-user repository limit?
Where can I find documentation about Gitea’s user interface and admin options in general? https://docs.gitea.io doesn’t seem to document this aspect of Gitea at all.
It seems that per-user repository limits can be set in a special page that is accessible from the “User Accounts” page: You can navigate to it by first navigating to the administration page. Then there are two horizontal rows of links at the top of the page. The usual one and a new additional one with admin links and one I somehow did not notice until now.
Click on “User Accounts” and then click the small blue note+pen icon on the right of any user. This will give you a page where you can set limits and restrictions on a per-user basis!
I’ve included a picture where these links are located:
So in summary, I ended up ding the following to restrict new users to issues:
In the app.ini file under [admin], Set DISABLE_REGULAR_ORG_CREATION to true
In the app.ini file under [service], Set DEFAULT_ALLOW_CREATE_ORGANIZATION to false
In the app.ini file under [repository], Set MAX_CREATION_LIMIT to 0
For every user you want to allow creating new repositories, go to user settings page mentioned earlier in this post, and set “Maximal Number of Repositories” to -1.
I may still have missed something, but from what documentation I could find about this, the steps above should result in issue only users by default.
Gitea is good software but sorely needs better (any) documentation. If it exists, new users are not finding it.
me too have same opinion, as always gitea documentation are very poor, i dont understand why developers implements the features and do not document that features property!
@mckaygerhard I’d be lying if I said it wasn’t infuriating at times, but I wouldn’t be too hard on them for not maintaining proper documentation. This is a non-commercial project where members work on it during what I assume is their own personal time. 3000 USD annually isn’t much for a single technical writer, let alone an entire project like gitea. I can’t imagine many people would be willing to volunteer writing documentation in their spare time.
I also think another contributing factor to the poor state of gitea’s documentation is that the devs got a bit lazy. Most of the user-facing UI is a 1:1 clone of github. This in itself isn’t normally a bad thing. However, this laziness becomes a major (even deal-breaking) problem when people need to interact with gitea in a gitea-specific manner like administration.
The Rust project, another open source project I’m intimately familiar with, has a really good policy of not releasing any new feature until it is sufficiently documented (usually by the person who developed it). Other open source projects have similar policies. Perhaps gitea would benefit from instating a similar policy?
PS: Thank you for voicing your opinion though. It’s really nice to have someone else contributing to this discussion instead of just replying to myself like a crazy person. Much appreciated!
is that the devs got a bit lazy. Most of the user-facing UI is a 1:1 clone of github. This in itself isn’t normally a bad thing. However, this laziness becomes a major (even deal-breaking) problem when people need to interact with gitea in a gitea-specific manner like administration.
This is a non-commercial project where members work on it during what I assume is their own personal time. 3000 USD annually isn’t much for a single technical writer, let alone an entire project like gitea. I can’t imagine many people would be willing to volunteer writing documentation in their spare time.
there’s no excuses, here in Venezuela the salary are less than 100$ and many developers when make contributions property added documentation!
also in some other countries there’s same behaviour for commits, releases and more!
a really good policy of not releasing any new feature until it is sufficiently documented (usually by the person who developed it). Other open source projects have similar policies. Perhaps gitea would benefit from instating a similar policy?
that should be the policy! here then developers are some lazy inclusivelly when their incomes/salary are much better than those of other countries with devalued currencies.
Perhaps I’m misunderstanding your point (and apologies if I am), but I don’t think the best way to get other people to do unpaid work is to berate them or criticize them. If anyone cares about improving gitea, it’d be the developers who work on it. I think it’s far more productive to point out any deficiencies you notice and suggest solutions to them. If you can, perhaps even contribute a solution too.
For my part, I can’t make any promises but I’m thinking about contributing to gitea’s documentation if I end up going with gitea. It seems like a good project that needs all the help it can get. I’m just not sure what form it should take. Also, as apparent as it might have been, English is not my strong point. This is usually fatal for english documentation, but I think badly-written (but correct) documentation is better than no documentation at all.
Perhaps I’m misunderstanding your point (and apologies if I am), but I don’t think the best way to get other people to do unpaid work is to berate them or criticize them. If anyone cares about improving gitea, it’d be the developers who work on it
if I don’t get criticism when I can see if I’m doing things right!?
I think it’s far more productive to point out any deficiencies you notice and suggest solutions to them. If you can, perhaps even contribute a solution too.
I pointed the problem and the solution! PROBLEM: miss of documentation, SOLUTION: minimal docs on each feature push, with proper explanation contributors like me that are not core developers of gitea can make and enhanced the documentation.
For my part, I can’t make any promises but I’m thinking about contributing to gitea’s documentation if I end up going with gitea.
we really need your apport… great! BUT of course you cannot understand nothing if developers does not paste minimal referrences or documentations… also the languaje are a big wall here!
It seems like a good project that needs all the help it can get.
yeah but too many upgrades at time… its a pain for administrators when i just put a release updates 1.7.3 then a new just come out 1.7.4 and then just another and i past too many time upgrading event working! currently there’s 1.7.5 but for sure 1.8.0 will need golang upgrade and so then and then and we now are like M$ !!!
I both understand your frustration and emphasize with you’re points, but I can’t see being rude and making demands of an over-encumbered group of developers leading to any sort of satisfactory outcome for anyone involved. Remember that they are not under any obligation to document this project, moral or otherwise.
eat! BUT of course you cannot understand nothing if developers does not paste minimal referrences or documentations… also the languaje are a big wall here!
Even if no documentation exists, the source code still does. If you’re like me, someone who doesn’t know golang yet, you can always experiment until you have some grasp of how a feature works. For example, discovering how to restrict new users to only issues took me about 3 days-worth of personal time to figure out. It’s not optimal, It’s (very) frustrating, and it’s very inefficient use of my private time, but it’s a trade-off I need to make if I want to understand and use gitea.
I, and I expect many others, would be very happy if gitea devs decided to better document their project, but if they don’t then that’s their prerogative. We are restricted to our own abilities. We must make due with what we have. At least, that’s how I like to think about this situation.
My plan for now is to thoroughly document solutions to issues that I’ve come across while evaluating gitea just as I have in this thread. I post these solutions here in this forum both so that the devs can correct me if I’m wrong, and so that this thread can serve as makeshift documentation to help others who face this issue.
Is this a substitute for proper documentation? no, but it’s what I can personally do to better the current situation.
Sorry for the long wordy post and cheers!
PS: By criticism, I meant nonconstructive criticism. Apologies for not being sufficiently clear in my last post.
I’ve followed your instructions but it is not working. In my case no one is able to create a repository, even those of I set “Maximum Number of Repositories” to 20 - only me as the root user.
I had no option, so I’ve revert the app.init MAX_CREATION_LIMIT to -1 and continue the tedious task of the changes per user in the interface.
Have you seen this problem?
