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

@coreyjewett commented on GitHub (Feb 27, 2018):

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

@coreyjewett commented on GitHub (Feb 27, 2018): I was hoping to disable wikis system wide, but using an entry in the ini configuration.

GiteaMirror commented

@lunny commented on GitHub (Feb 28, 2018):

That's not very difficult.

@lunny commented on GitHub (Feb 28, 2018): That's not very difficult.

GiteaMirror commented

@ve3 commented on GitHub (Jan 18, 2019):

enable/disable pull request system wide please.

@ve3 commented on GitHub (Jan 18, 2019): enable/disable pull request system wide please.

GiteaMirror commented

@stale[bot] commented on GitHub (Mar 19, 2019):

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.

@stale[bot] commented on GitHub (Mar 19, 2019): 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.

GiteaMirror commented

@jpicht commented on GitHub (May 23, 2019):

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

@jpicht commented on GitHub (May 23, 2019): I am currently working on implementing this over [here](https://github.com/jpicht/gitea/tree/issue_3336). It is currently work in progress, but I hope to finish it tomorrow.

GiteaMirror commented

@tech-alchemist commented on GitHub (Jul 25, 2019):

Any hope? or shud we click fork ? 😯

@tech-alchemist commented on GitHub (Jul 25, 2019): Any hope? or shud we click fork ? :hushed:

GiteaMirror commented

@jolheiser commented on GitHub (Jul 25, 2019):

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

@jolheiser commented on GitHub (Jul 25, 2019): The above referenced PR has had activity within the last few days.

GiteaMirror commented

@davidsvantesson commented on GitHub (Nov 3, 2019):

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 commented on GitHub (Nov 3, 2019): 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.

GiteaMirror commented

@davidsvantesson commented on GitHub (Jan 2, 2020):

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 commented on GitHub (Jan 2, 2020): 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 `. [![](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Show%20existing)](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Show%20existing/vote) [![](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Delete%20all)](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Delete%20all/vote) [![](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Delete%20all%20and%20enable%20all)](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Delete%20all%20and%20enable%20all/vote) [![](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Hide%20existing)](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Hide%20existing/vote) [![](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Hide%20existing%2C%20still%20add%20as%20default)](https://api.gh-polls.com/poll/01DXKK3Z1J7N8SXTJ1E9HZWQQZ/Hide%20existing%2C%20still%20add%20as%20default/vote) 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.

GiteaMirror commented

@davidsvantesson commented on GitHub (Jan 2, 2020):

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.

@davidsvantesson commented on GitHub (Jan 2, 2020): 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.

GiteaMirror commented

@guillep2k commented on GitHub (Jan 2, 2020):

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.

@guillep2k commented on GitHub (Jan 2, 2020): 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.

GiteaMirror commented

@davidsvantesson commented on GitHub (Jan 2, 2020):

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.

@davidsvantesson commented on GitHub (Jan 2, 2020): 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.

GiteaMirror commented

@guillep2k commented on GitHub (Jan 2, 2020):

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?

@guillep2k commented on GitHub (Jan 2, 2020): > > > 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?

GiteaMirror commented