Make it easier to extend and customise Hypha for other implementors

[frjo]

Let us discuss how to make it easier for other implementors to extend and customise Hypha.

Goals is to allow adding and modifying things without touching existing code as far as possible. This is to avoid merge conflicts and similar issues when keeping up to date with core Hypha releases.

[frjo]

From a dev group meeting:

1. You can already add a custom template directory to override any templates in Hypha.
2. We can collect a list of classes that implementor commonly want to override and add settings for them. Then an alternative class can be created and used by changing a setting value.

[kfogel]

See also related Zulip conversation: Make it easier to extend and customise Hypha.

[frankduncan]

@frjo That sounds like a good path forward. We're still booting up the process of getting entry points. Two to start your thinking off are:

• Extending the form widgets. Two instances that we'd want to be able to write ourselves are:
  • Complex datatypes - kind of like the Location widget, but allowing multiple ones
  • More complex branching logic
• Different registration process. This will be submitted as an issue for you guys to thumbs up/down, but one of our needs that we've implemented is having an applicant register before filling out the full application.

More to come!

[frankduncan]

I wanted to follow up here, even though I know this is a general issue that anyone might join. For the ardc project where we've diverged some, we're moving on the following steps:

• Create Issues/PRs here for legacy, already complete items after a thorough audit (the code is good, it's not already fixed in production, that it's a good candidate for general use, etc).
• Analyze the diff between upstream main and our main
• Create PRs for things we didn't necessarily have an issue for. Because it may not have been client driven, the issue may have less context than the ones from the previous step
• Create extension points for things not deemed good to incorporate into mainline, or things that seem too specific to our clients use. This is the main push having to do with this issue
• For any new feature requests from the client, if they are of general use, we'll create the feature request/bug issue in our system, and also here. Then we'll create a PR here with the changes. If not deemed good for upstream, we'll move the commits to our mainline. If it is, we'll just merge in as soon as the merge is done here.

The idea is to iterate on this until we hit a stable point.

If this comment is more appropriate somewhere else, I can put it there and delete it here :)