- Status changed to Closed: won't fix
over 1 year ago 1:37am 11 December 2023 - πΊπΈUnited States john.oltman
This can be done with an Event subscriber in a custom module that works similarly to the subscriber in the registration_confirmation submodule.
- π¨πΏCzech Republic milos.kroulik
I need this, so I'm going to code it. Would you consider incorporating it as a submodule? I believe others might expect this feature - for example I've used https://www.drupal.org/project/social β before, where this works out-of-the-box.
- πΊπΈUnited States john.oltman
Thanks @milos - if you are going to code it, should it be incorporated as an addition to the existing registration_confirmation submodule? That would make more sense to me than a new submodule. Basically it would add an admin email field to the existing form, above the subject field, perhaps with a description like "Send a copy of the confirmation to this email address". Maybe there would be a checkbox for "Send a copy to the author of the host entity" as well.
- π¨πΏCzech Republic milos.kroulik
Thanks for the answer and suggestions. I agree that it makes sense to extend registration_confirmation submodule.
I believe that admin confirmation could be different from the one sent to the user quite often - on our site it contained info entered by the user into the form (whereas we sent further instructions to the user). So I'm going to create a separate message field for it. Perhaps there should be a checkbox (by default checked), allowing to send either a copy of the user confirmation message or a separate message?
This can become unwieldy - perhaps the long-term solution could be integration with https://www.drupal.org/project/message β and its ecosystem? Or maybe https://www.drupal.org/project/workbench_email β , given that there's support for workflow?
- πΊπΈUnited States john.oltman
Agree that an admin needs a different confirmation vs. the registrant. Also agree this is getting too big and unwieldy - the modules you mentioned look interesting. Let me look into those and see if maybe an integration submodule, rather than more code in registration_confirmation, is a better approach. I'll research and get back on this issue within a day or two.
- πΊπΈUnited States john.oltman
Looked into those modules and they are not suitable in my view - the integration paths are difficult and each has issues. For example sm has a very small install base, and message requires too many other modules as dependencies. Workbench works with content and adapting for registration would be a major effort. In short I think the best way forward for this particular need is either in a custom module, or adding to the confirmation and waitlist submodules of registration. I am comfortable with any decision you make - custom is probably slightly easier so I understand if you go that path. I promise if you do decide to take on the changes to confirmation and waitlist that I will review quickly and get your code merged as soon as practical after you submit an MR. Thanks @milos.
Perhaps there should be a checkbox (by default checked), allowing to send either a copy of the user confirmation message or a separate message?
I agree with this.
- πΊπΈUnited States wattdesigns
This is a feature I'd LOVE to have and am currently working to use Rules to supplement this.
HOWEVER, maybe the solution is a little easier than this whole new module system. Could you please just add a CC field on the two pre-built e-mail notifications? It works great sending the e-mails to the users now, so just add a CC or even BCC field to the configuration to allow for a copy of the user e-mail to go to the admin (or whoever you wanted).
Could that work?
- πΊπΈUnited States john.oltman
Thanks @wattdesigns, the new submodule concept is out. What is on the table is the CC you suggest - and @milos would also like the option to have a different message to an admin. If/when he submits this work, your CC will be in there, so you'll be covered. The extra message field does not complicate things so much that it puts this beyond reach.
- πΊπΈUnited States wattdesigns
That's great! Glad you like my idea! Thanks!
- π¨πΏCzech Republic milos.kroulik
I spent some time studying the module design, so that my code fits in.
And I have some questions:
It seems to me, that notification code triggered by registration to waitlist currently present in registration_waitlist module might make more sense in event subscriber placed in registration_confirmation module (subscribing to
RegistrationWaitListEvents::REGISTRATION_WAITLIST_WAITLISTED
event). This would centralize all notification code in this module.I also think it makes sense to introduce a
MailNotification
class in registration_confirmation module, so we can easily reuse the code now placed in RegistrationEventSubscriber for both use cases and keep things clean.What do you think about this, please?
- πΊπΈUnited States john.oltman
What you are proposing would create dependencies between the confirmation and waitlist submodules that we don't want, forcing users to always enable both. We can't do that, they have to be separate, waitlist functionality must go completely in the waitlist submodule and confirmation similarly completely in its submodule. Regarding sharing - they both already share an action - I'm not sure how much more can be shared. If you want to add another method to Notify/RegistrationMailer.php (already exists) that would serve both modules, that can work. Thanks for looking into this!
- π¨πΏCzech Republic milos.kroulik
What you are proposing would create dependencies between the confirmation and waitlist submodules that we don't want, forcing users to always enable both. We can't do that, they have to be separate, waitlist functionality must go completely in the waitlist submodule and confirmation similarly completely in its submodule.
Alright, I will modify both modules then. Moving all confirmation code to registration_confirmation module would mean, that user could easily enable/disable all confirmation functionality by enabling/disabling that module, registration_waitlist itself would not be dependent on it (if i understand it correctly).
- πΊπΈUnited States john.oltman
The confirmations are separate. So disabling registration_confirmation only disables the "registration completed" email. Disabling registration_waitlist disables the "you were put on the waitlist" email. They are intentionally completely separate, and should remain separate.
Moving all confirmation code to registration_confirmation module would mean...
You aren't moving anything. You are adding new functionality (admin notification) to both submodules. The functionality is similar in both, and if you want to add some code to the core module in Notify/RegistrationMailer.php that the new functionality can share, that is fine. But don't move any code around. Just add similar code to both submodules.
- Merge request !151Draft: Adjust configuration schema to allow for admin confirmations. β (Open) created by milos.kroulik