[feature] Ability to enable/disable wiki system and issue tracking for all repositories

[kumlali]

• Gitea version (or commit ref): 1.3.2
• Git version: 2.9.3
• Operating system: Red Hat Enterprise Linux Server release 7.4
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • [x ] SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • [x ] Not relevant
• Log gist:

Description

It would be nice to have a configuration option that allows administrators to enable and disable wiki system and issue tracking of all repositories.

I could manage to disable issue tracking(not wiki system) of all the repositories by executing following SQL statements:

DELETE FROM repo_unit WHERE type=2;
UPDATE repo_unit SET config='{}';

P.S.: Similar request for Gogs: gogs/gogs#3738

[coreyjewett]

I was hoping to disable wikis system wide, but using an entry in the ini configuration.

[lunny]

That's not very difficult.

[ve3]

enable/disable pull request system wide please.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.

[jpicht]

I am currently working on implementing this over here. It is currently work in progress, but I hope to finish it tomorrow.

[tech-alchemist]

Any hope? or shud we click fork ? 😯

[jolheiser]

The above referenced PR has had activity within the last few days.

[davidsvantesson]

There seem to be need of some discussion and consensus on what this feature exactly shall do. Most of the use-cases can be handled by scripts using the API and/or template adoptions, but that is not very user-friendly for a common case.

I would like to see the repo units as different features (buildin or plugins) of Gitea that should be possible to install and uninstall (if it is included in the gitea executable is not important here). It should also be possible to select which features (units) are default for new repositories. What should happen if you "uninstall" a unit, shall all data be removed? And the same if you "install", shall it be default be added on existing repositories. To handle that option and be able to give warnings, the install/uninstall procedure should preferable be in the admin UI rather than in app.ini.

If plugin system and site configuration storage needs to be discussed for this issue, I'm afraid it will take some time before it can be merged.

[davidsvantesson]

As proposed by @6543 lets have a vote on the different options. Sorry for the many options, I found quite many possibilites to solve this.
Read Delete all as Disable unit for all repos .

Delete means to delete/disable the unit setting so it has to be manually enabled again, not the content of issues etc. Enable all means it the unit is globally enabled again, it will be enabled on all repositories if it is a default unit. In the last option, repositories created while the unit was disabled will have it if enabled again.

[davidsvantesson]

The Delete all and enable all option will not be easy to handle through the ini configuration, as it requires to keep track when the setting is changed. However it would make sense if units is enabled/disabled as modules from the command line or via the admin web interface.

[guillep2k]

Sorry, I've found the poll options very confusing. Is it perhaps the case that part of the discussion was held elsewhere?

Anyway, when globally disabling something as important as PRs or wiki, I would not disable them repo by repo but only at the global level, and existing data should be kept. Then, I'd add a tool ("the Doctor" or admin option) to remove all unnecessary data in case the admin really wants it removed. If the features are enabled again, those repos that had it enabled will regain it, and those that didn't won't.

This should work for cases when the admin needs to temporarily disable something e.g. for maintenance reasons but intends to enable them after a short while.

[davidsvantesson]

Honestly I don't like this poll toll, adding very long poll options didn't work. I think use reactions for different poll options work better...

From your comment it seem you propse "Hide existing". I should clarify that data will not be deleted in any case, it simply means to disable the units for all repositories. So you have to enable the unit manually again, but all data will be there.

I don't really see the maintenance case, the unit will disabled for the site administrator as well. I think of these as different modules or plugins which can be installed or uninstalled, even if these are built-in. So I actually think all existing units shall be disabled, but I am afraid it will not be clear enough when changing something from app.ini. The problem I see with hiding is that it might give unexpected results if activating the unit again, which units that have the unit activated might seem random.

[guillep2k]

I don't really see the maintenance case

I'm not saying it will be a common case, but if we can support disabling the units temporarily to re-enable them later, I don't see why not; notice that even if the data is never deleted (e.g. wiki repos), I propose to leave the unit enabled at the repo level, so those that had it enabled should "remember" that when wikis are enabled again. My thinking is that admins should be able to "test" the feature and be easily go back for whatever reason. At the UI level the "enable wiki" setting should appear grayed-out with a "disabled by administrator" notice.

The problem I see with hiding is that it might give unexpected results if activating the unit again, which units that have the unit activated might seem random.

If two years passed in-between, yes, it will seem random. But if days or hours have passed, that will be the expected result.

Could you provide some example of other features (external plugins) that may benefit from this mechanism in the future?

[davidsvantesson]

The Kanban feature?
Any additional per-repo (stand-alone) feature someone wants to add.

[davidsvantesson]

The poll is not conclusive, but I think it is not a good idea that an app.ini setting permanently change things in db (the two delete options). And since my original implementation didn't get any vote, I think "Hide existing" will be the way forward.

Implementation-wise it is rather tricky to handle the settings. The disabled/hidden units shouldn't change when user update repo settings. But then if the user activates a contradicting unit (e.g. external issues when issues was activated before) you can end up with both units activated.