`config` app: Allow managers to configure `Plugin` settings via GUI

[jwindeck]

Rationale / Begründung

At the moment, plugin settings in RDMO can only be configured by administrators through server-level changes.

Providing managers or editors with a GUI to configure plugins directly would increase flexibility and reduce dependency on administrators. This should cover activation/deactivation, catalog assignment, and adjusting plugin-specific settings (e.g., mappings via .toml files).

Affected

• Managers or Editors (to be discussed)
• Admins

Minimal functionality

• option for site-managers to activate/deactivate plugins for their site
• option for site-managers to assign plugins to specific catalogs
• Simple form element for additional plugin configuration, e.g. an editor for .toml files used by the plugins (similar to views editor)

Nice-to-have functionality

• instead of plain text editor for .toml files, provide a key-value pairs UI (or similiar) for easier configuration
• Support for plugin customization (e.g. endpoints, queries) to allow broader generalization of plugins). Ecample: allow users to add several instances of the same plugin to query different databases
• a project-level page for users to activate/deactivate plugins for a project and it's sub-projects

References / Verweise

[MyPyDavid]

In a new config (or rdmo_config) app with a Plugin model, so that later also the settings may be migrated to a db model.
Initially UI via /admin only. A choice field for "plugin", the same plugin can be selected for multiple instances.

Each plugin can be provide their own config (either with settings, a toml, json etc). How should we store it in the db? As a JSONField? How to validate it, if with pydantic then the plugin needs to define this model? As only valid Django types? However, it should also not be a hard-requirement for each plugin to define their config model.

Updating this config should not result in a 500 error, otherwise it is not fixable anymore by the site manager/editor and only by the system admin.

[jochenklar]

It would be good to have a specific "getter" for those plugin settings, which can not fail for obvious misconfigurations like missing keys. This would also prevent ugly hasattr and getattr clauses in the plugin code.

[MyPyDavid]

I have a question for the overall feature. Should the current plugin configuration via the settings be kept in-place and compatible as-is? So that the available plugins will be retrieved from both the settings and the db plugin instances.

In that case, I could add some helper management command that can convert the plugin settings into the plugin db instances. And how to handle/identify 'duplicate' entries from settings and db?

[jochenklar]

PLUGINS = [
    'rdmo.projects.exports.RDMOExport',
    'rdmo_re3data.exports.Re3DataExport'
]

[MyPyDavid]

the current rdmo settings for specific plugins (see, https://rdmo.readthedocs.io/en/latest/plugins/index.html) should become deprecated. One disadvantage of the current way is that the translations for the plugin labels need to be configured via the .po files.

EXAMPLE_PLUGIN_SETTINGS = [
    # key,        label,      python path
    ('example', _('Example'), 'module.module.module.Plugin'),
    ...
]

So, the following settings should be deprecated and removed:

PROJECT_EXPORTS = [...]
PROJECT_IMPORTS = [...]
# new in 2.3
PROJECT_SNAPSHOT_EXPORTS = [...]

OPTIONSET_PROVIDERS = [...]

# and also??
PROJECT_ISSUE_PROVIDERS = [...]

The specific plugin's own settings (the plugin config, like ZENODO_PROVIDER or GITHUB_PROVIDER) should be kept compatible with either the settings from django or the db Plugin.plugin_settings JSONField. In addition, I would say, that they should be mergable with each other so that you can get the secret settings from somewhere else and define other fields of the config in the db.

An upgrade/helper script should be defined for the transition from the then 'legacy' settings to the db settings. For example,
manage.py setup_plugins --from-settings or manage.py setup_plugins --from-xml??