Please add render() and submit() methods to Issue Providers

Rationale / Begründung

Project provider plugins offer developers full flexibility in terms of defining what users see, usually a form created with the plugin's render() method, and how the user data is processed using the submit() method.

Issue providers do not offer as much flexibility. Instead of defining the whole integration form with a render() method, these providers let the developer define only the attributes of form input fields (https://github.com/rdmorganiser/rdmo/blob/main/rdmo/projects/forms.py).

The equivalent of the submit() method for project providers is the send_issue() for issue providers (https://github.com/rdmorganiser/rdmo/blob/main/rdmo/projects/views/issue.py). Once again, the issue provider plugin only lets the developer define certain aspects, with no way of adding additional elements, such as extra context / session data or preprocessing information, before sending the issue.

Affected

Plugin developers

Minimal functionality

It would be great if one could define a render() and a submit() method for issue providers too. This would provide full flexibility, for example enabling the use of different widgets for the form's fields or offering the users multiple GitLab instances to choose from.

References / Verweise

• In our forked repos of rdmo-plugins-github and rdmo-plugins-gitlab we added the following, and we would like to include these changes for the corresponding issue providers:

• radio buttons to select the repository to export issues to (instead of a text field)
• multi-instance functionality for GitLab plugins, enabling users to select the instance they want to export issues to from a set of supported instance providers.

Start by comparing project provider render() and submit() behavior with the issue provider form definitions in rdmo/projects/forms.py and send_issue() in rdmo/projects/views/issue.py. Review the referenced rdmo-plugins-github and rdmo-plugins-gitlab forks for the radio-button and multi-instance use cases. Done means issue providers can define render() and submit() with equivalent flexibility.