Hi team, first Kudo's, the new centralised notification system is a lot more configurable for developers and actually fairly easy to extend with custom functionality.

The only area I felt was a little disappointing was that there were no callbacks/implementation points that would allow the developer to extend the interface shown to the user when they're creating a new notification.

(Or at least, none that i could find, so if i'm missing a trick then please let me know)

e.g recipient classes such as the third party recipient can't show new form elements to the user when selected.

I understand that in most cases, the recipient is contextual and pulled from information stored elsewhere (e.g configuration in the module, or similar).

However the use case I was thinking of, was specifically around the third party recipients. Seminar implements this via storing the third party recipients as a configuration on the seminar.

One of our clients quite liked this functionality to enable workflows on their site by triggering emails to relevant people and asked us to look into implementing it for other notification types.

I eventually implemented it for course module completion notifications, by adding customisations that injected a third party recipients form element into the common module elements of the core module forms (and stored it in a local plugin), and then referring to this data later when calculating the recipients based on the passed in course module instance.

This was quite easy to achieve with minimal core customisation, which again speaks to the quality of the API here.

But I can't help feeling that this functionality could be made much more powerful, if when the user selected the recipient option in the notifications customisation form, we could inject extra form elements (e.g you could imagine enabling third party recipients for all types of notification by allowing collection of third party recipients right in the notifications interface).

I wouldn't mind handling the data storage and cleaning etc manually myself, so it would only need to be some hooks to inject relevant TUI templates and data into that form and then get a hook callback to handle your form elements.

Perhaps there is a mechanism to do this already and I missed it, but otherwise I think it's worth considering for your future roadmap if one exists.