Add setting to set default and global disabled repository units.

[davidsvantesson]

This would fix #3336.
This replaces #7032. I have tried to make a more generic approach.

• App.ini setting to set default units when new repo is created. MustRepoUnits is always default and external wiki/tracker can't be set as default for now (as require additional setting)
• Any unit which is not in MustRepoUnits can be disabled (anyone that can be disabled per repo)
• Disabled units are removed from DefaultRepoUnits (so they will not be on new repositories)
• "Global unit pages" (Issues and Pull request overview) is disabled if corresponding unit is disabled
• Existing repo units is "hidden", i.e. it is as they are not active on the repository. If the disabling is removed, the unit will be active on the repository again. Exception is if a contradicting unit is activated (internal vs external units), then the other is removed even if disabled.

[guillep2k]

What's the exact use case? From the original issue I was under the impression that some users expected to globally re-enable them later (e.g. @ve3 "enable/disable pull request system wide please."). Maybe they wanted something temporary?

I've been thinking lately in having a paginated list of repositories with columns of features to enable/disable and an "Apply" button in batch mode. Similar to GMail select feature. Then, a lot of repositories can be changed at once (or all of them). May be this idea could apply to this.

[davidsvantesson]

It is definitely tricky to make up something that fits every use (and even know what it is). The temporary deactivation use case was something I didn't read from the original issue. Is that really a common case? I think a common case is "corporate use cases" where the organization have decided to not use certain features of Gitea, e.g. using other issue tracker system and wiki. If it is a big organization you want to make sure nobody activates and start using these features.

So I think below are the three main features needed by most people. If someone see a need for it maybe it could be separated into different settings.

• Deactivate global pages for corresponding unit (issues and pr overview)
• Don't activate unit by default for new repositories (the most irritating part imo)
• Don't allow users to activate the unit

My main problem with the previous PR was that it didn't differentiated between internal and external issue/wiki (even if you don't use internal issue tracker you might want to integrate with an external). Also I wanted to try to make something that had smaller code impact (fit into current structure of units).

Although I think the normal case would be to set which units to disable at installation, the "corner cases" needs to be considered. If someone deactivates a unit on an existing installation, it is probable he also want existing repo units to be removed. However I think it is best of the application to not try to be "smart" and do things for the user in background that might not be wanted. The units can easily be deactivated by e.g. a sql query. Similar if the unit is later globally activated again. I don't think it would be expected to automatically see the unit activated on all existing repositories (maybe you only want to start using it on new repositories).

I've been thinking lately in having a paginated list of repositories with columns of features to enable/disable and an "Apply" button in batch mode.

That sounds like a good idea, in the admin panel then? I think maybe also the repo units could have a database column 'active' as well. Then you could deactivate and activate a unit and get back the settings you had before.

[guillep2k]

If that's your use case, then I think it's probably better to have:

• The ability to turn off default "on" for those features (as you said).
• Turn off the existing features (e.g. "remove" issues from the view).
• Or turn off the ability to create new items in those features, while still being able to access the already created data (akin to archived repos).

The latter can be implemented another time, of course.

The "admin panel" can be something that's not just for the admins; e.g. it could be useful for repo owner/organizations to quickly change all of their repos. Same functionality, but only for those repos that you own. It can be paginated and/or have a search/filter function on top.

Regarding you current PR, you could add a "[ ] Force current repositories to adhere to this restrictions now" checkbox, so the admin doesn't need to use SQL to do that (it's easier for us than for him).

[6543]

@davidsvantesson can you resolve convlicts

[davidsvantesson]

We need to reach a conclusion regarding settings of existing repositories when this setting is changed. Shall it be hidden for any repository that already uses e.g. issues?

[6543]

good point ...

[6543]

@davidsvantesson you could make a poll as I did : #9286 (comment)

[davidsvantesson]

@6543 I put it in the original issue.

[davidsvantesson]

Teams...
The easiest is to allow setting team unit access even if the unit is globally disabled. Otherwise there is the same question what shall be the default access. On the other hand it is a bit confusing the setting is there when the unit is global disabled. Any opinions?

[davidsvantesson]

Another comment is that I only disable the settings in the repository (with a note on hover), not hiding it completely. I think it is more clear for the user if he expected the section, but I have no strong opinions about it.

[guillep2k]

Teams...
The easiest is to allow setting team unit access even if the unit is globally disabled. Otherwise there is the same question what shall be the default access. On the other hand it is a bit confusing the setting is there when the unit is global disabled. Any opinions?

What about a comment next to the unit? (see Wiki):

== Allow Access to Repository Sections
[ ] Code
[ ] Issues
[ ] Pull Requests
[ ] Wiki _(currently disabled by the site administrator)_
[ ] Ext. Wiki
[ ] Ext. Issues

[davidsvantesson]

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@6b2e4eb). Click here to learn what that means.
The diff coverage is 44.6%.

@@            Coverage Diff            @@
##             master    #8788   +/-   ##
=========================================
  Coverage          ?   42.32%           
=========================================
  Files             ?      604           
  Lines             ?    79116           
  Branches          ?        0           
=========================================
  Hits              ?    33482           
  Misses            ?    41511           
  Partials          ?     4123

Impacted Files	Coverage Δ
services/mailer/mail.go	46.52% <0%> (ø)
routers/repo/milestone.go	0% <0%> (ø)
cmd/dump.go	0% <0%> (ø)
modules/markup/markdown/goldmark.go	66.37% <0%> (ø)
modules/notification/action/action.go	35.65% <100%> (ø)
modules/notification/base/null.go	65.62% <100%> (ø)
modules/notification/notification.go	76.29% <100%> (ø)
modules/notification/mail/mail.go	24.63% <100%> (ø)
routers/api/v1/repo/pull.go	34.6% <100%> (ø)
services/pull/check.go	56.64% <100%> (ø)
... and 15 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6b2e4eb...9f07275. Read the comment docs.

[6543]

nice - lgtm

[zeripath]

Looks like the github downloader keeps timing out during tests.