Add FORCE_VISIBILITY config value to force new repos to be public or private

[codefritzel]

This PR adds the feature to configure repositories as force public like force private. See #24059
The value FORCE_VISIBILITYhas been added. The key type is a string, that is used similar to DEFAULT_PRIVATE.

FORCE_VISIBILITY can take the following values:
public - new repos must be public and existing ones cannot be switched to private
private - new repos must be private similar to previous FORCE_PRIVATE=true
off - new repos can be private or public

For compatibility reasons ForceVisibility = private is set if FORCE_PRIVATE=true is configured. FORCE_PRIVATE was marked as deprecated.

• closes FORCE_PUBLIC: force every Repository to be public #24059

[KN4CK3R]

Why would you want to enforce public repos? I think it would be better to add a (per user/org) setting with a maximum of private repos as some kind of billing feature.

[codefritzel]

Hi @KN4CK3R,
in my use case there is a requirement to force public. For our purpose, we take an open code / source approach. Everyone who has access to our Gitea instance, apart from the restricted users, should be able to see every repository. The aim is to create transparency between the teams.

I think this option would be interesting for companies. Everyone in the company should see all repositories, as there are no secrets between employees and teams.

There is the possibility to configure force private, so why not force public as well?

[techknowlogick]

Thanks for this PR! This will break existing configs (true/false paradigm wouldn't work anymore), this however can be solved. Instead of using the force_private config, you could add a new config value of FORCE_VISIBILITY, where you have the off/public/private logic you currently have, and then for backwards compatibility you could have "if force private == true, then set force visibility = private", and set force visibility as deprecated.

[codefritzel]

Thanks for this PR! This will break existing configs (true/false paradigm wouldn't work anymore), this however can be solved. Instead of using the force_private config, you could add a new config value of FORCE_VISIBILITY, where you have the off/public/private logic you currently have, and then for backwards compatibility you could have "if force private == true, then set force visibility = private", and set force visibility as deprecated.

Hi @techknowlogick,
Thanks a lot for your feedback!

I prefer the parameter name FORCE_VISIBILITY much better than FORCE_PRIVATE. I have not thought of the config break unfortunately...
I assume you mean that FORCE_PRIVATE is defined as deprecated and not FORCE_VISIBILITY?
I will try to modify it like this. See 132bb83

[techknowlogick]

I assume you mean that FORCE_PRIVATE is defined as deprecated and not FORCE_VISIBILITY?

yes, that's correct. Thanks for making those changes :)

[svenzimmermann]

"Force Visibilty private" is particularly important for our use case. We need a Git environment for the school, which means that repositories are created here by minors. For reasons of copyright and data protection, it is therefore important that the content of user repositories is not published without being checked by a teacher.
For projects students should work together in organizations and teams. Here repositories set to "internal" are better conform to the requirements.

However for personal repositories "Force Visibilty private" should be permanent and not just during creation.
Is there a chance to introduce an "always private" setting for user repositories?

[codefritzel]

Hi @svenzimmermann,
this already works now if FORCE_PRIVATE=true or in future with FORCE_VISIBILITY=private is set. In the settings of the repository then only an admin can set a private repo to public. However, already published repos are not automatically set to public with this setting.

[svenzimmermann]

@codefritzel: Thanks for the hint, my mistake. I just tested FORCE_PRIVATE=true again.
Works with all new repos. But it should work with all personal repositories only, not organizational ones.
The publication rights in organizational repositories can already be fine tuned by authorized persons. So it doesn't really make sense there.