Hypha plugin architecture

[frjo]

We are experimenting with DJP: Django Plugins in #4201

What would this solution allow plugins to do, and what would it not solve?

[frjo]

Some things current Hypha with DJP would allow you to do:

1. By placing a copy of a template in templates_custom directory you can override the original. With DJP a plugin can override any setting and e.g. add additional directories where Hypha look for templates. That would allow a plugin to ship with templates that override default ones.
2. With DJP ability to override any setting a plugin can add stuff to INSTALLED_APPS, MIDDLEWARE etc.
3. DJP allow a plugin to add any urls it needs.
4. The env var DJP_PLUGINS_DIR can be set to make DJP look for plugins in a local directory.

What parts are missing for you all to build the plugins you need?

[frankduncan]

When we look at #4150, we need the ability to tell hypha to "not send emails if it's configured in our plugin" and "please send the email we specify rather than the one you were going to send". As I understand it, using plugins, we would need to build and maintain a whole new activity implementation that accomplishes the same thing as the email adapter, and slack adapter, and would need to be consistently updated as the underlying hypha application changes how it uses adapters in general.

When we look at #4149, we need the ability to introduce a new field on the hypha user class, or specify a new user class that has different objects on it. We then need to introduce a single line in a few templates relating to those user classes. Under the plugin, we would need to duplicate and maintain the various templates that hypha uses for those pages (no matter the size of them, or the size of the change), and if hypha changes those underlying templates, which it does pretty regularly, we will not get any of those changes. We would also need to have hypha use our new user class in all of the related models that link to User.

Just for templates alone, our changes across our fork would mean that we would be duplicating many templates (currently git diff --name-only v5.15.0 | grep template | wc -l gives a result of 64), without git telling us that there's a conflict as we upgrade the underlying.

And I chose two of easiest extensions to start with. Some of the other changes we have are much more invasive. The number of hooks we'd need from within hypha to call out to our code to get all of our changes into extensions is substantial.

I mean, consider the Project Approval Form vs Project Form change that went on. What is the overhead in developing and maintaining that as a DJP plugin if the upstream hypha project had decided that it needed to continue to use the Project Approval Form with no affordances to it being turned off and supplanted with another model?

[frjo]

64 edited templates, that is a lot. Can you trim that down by using the translation feature to just update the text?

Instead of doing {% hook 'wagtail_user_edit' %} could we do {% include "users/includes/extra_create.html" %} and have that as an empty template in core Hypha?

Regarding turning notification on/off, that we should have a settings page for in Hypha (#4205).

[frankduncan]

We have a lot of changes in the localization files as well. That part isn't so challenging.

It's more like the changes here: #3967 (As an aside, implementing and maintaining that change as a DJP plugin seems like a challenge)

As for doing {% include "users/includes/extra_create.html" %} rather than {% hook 'wagtail_user_edit' %}, that seems a bit more invasive in hypha's codebase. I felt having hooks was more clean than having an include each place, as it clearly indicates "This is a place where you can insert code" and you can do things like register multiple implementers of those hook.