Provide cc option to admin for registration confirmation

Created on 30 July 2014, over 10 years ago
Updated 11 June 2023, almost 2 years ago

Hey,

I'm exploring Redhen and Entity Registration as alternative to CiviCRM.

One feature that is currently lacking for me is an automatic e-mail alert (both to the person who registers as to the person who has created the event) whenever a new person registers.

I know that I can create this with Rules, but to have a nicely done e-mail with a summary of the registration details out of the box would be fantastic.

Or is there any other way to do this easily?

Simon

✨ Feature request
Status

Active

Version

3.0

Component

Registration Confirmation

Created by

πŸ‡¨πŸ‡­Switzerland simon147

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Status changed to Closed: won't fix over 1 year ago
  • πŸ‡ΊπŸ‡Έ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
  • πŸ‡ΊπŸ‡Έ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.

  • Pipeline finished with Failed
    14 days ago
    Total: 700s
    #472843
  • Pipeline finished with Failed
    14 days ago
    Total: 615s
    #473204
  • Pipeline finished with Failed
    11 days ago
    Total: 633s
    #475814
  • Pipeline finished with Failed
    11 days ago
    Total: 632s
    #475945
  • Pipeline finished with Failed
    11 days ago
    Total: 546s
    #476022
  • Pipeline finished with Failed
    3 days ago
    Total: 729s
    #482270
Production build 0.71.5 2024