Plugin-Registry and Project-level Plugin Settings

[jankapunkt]

Since we build a comprehensive plugin architecture, we need to have a way to manage/configure them. I see two levels of management here:

global plugin management (only for Administrators)

• apply settings that affect everyone, might be security, performance, permissions related
• API keys and secrets, if the plugin is an external service

project-level plugin management (everyone)

• enablig / disabling a specific plugin for the current project
• user-specific config for certain plugin-behaviour, if supported

// CC @alessandrobelli

[kadewe]

Well, probably we need both.
Global plugin management is needed always for a deployment – and this sets the plugin-options for the site. The admins should be in charge, which plug-ins are available to projects on a deployment site and if they are activated by default or not, because to many plug-ins may make the interface to complicated.
Then on a project-basis it should be possible to activate or de-activate plugins. E.g. if you have a project following qualitative method workflow A it would be beneficial to de-activate workflow B-Z, or if you are not working with images and videos, you can deactivate multimodal importing, coding and analysis plugins.