Split out email functionality into separate submodule(s)

Just some thoughts...

B): What do we need for it to work?
Currently the global template is stored in the {signup} table with nid = 0.
Does it make sense to have an additional table (called {signup_templates}) to store the default template and node-type specific templates?
This wouldn't be a exact copy of {signup} because nid should be replaced by a string value (content type name or an empty string for the global template) and subject and addresses are stored additionally.

CREATE TABLE IF NOT EXISTS {signup_templates} (
                node_type varchar(32) NOT NULL default '',
                forwarding_email varchar(64) NOT NULL default '',
                email_from varchar(64) NOT NULL default '',
                send_confirmation int(2) NOT NULL default '0',
                confirmation_subject varchar(255) NOT NULL,
                confirmation_email longtext NOT NULL,
                send_reminder int(2) NOT NULL default '0',
                reminder_days_before int(4) unsigned NOT NULL default '0',
                reminder_subject varchar(255) NOT NULL,
                reminder_email longtext NOT NULL,
                close_in_advance_time int(10) unsigned NOT NULL default '0',
                close_signup_limit int(10) unsigned NOT NULL default '0',
                PRIMARY KEY (node_type)
            )

{signup} then only stores signup data and no templates.

C): "modify global templates" and "modify templates per node type" would be two permissions to start.
Do you think it would be useful to have one permission per node type? There could be a need for admins to grant the "modify template" permission for one node type to a user but not for other types. How to handle this (could become a very long list of permissions)?
Ah, and of course "modify template per signup enabled node".

subscribing

could we also add a "thank you for coming" email?

It would be good if these sub modules could work with signup status module so that emails could be sent out only to those who have certain statuses (such as those who have attended that they will attend). Some of this could be done by just overriding or replacing the functionality in signup status, but it'd be nice if we could reuse as much as possible, perhaps using hooks to filter the recipient list.

Moving this on to 6.x-2.

also, would it be worthwhile to have it work with messaging framework and notification. OG is moving in that direction. That way you could take advantage of the various features that are available in those modules including sending via SMS.

I think #7s suggestion is a really good idea. I've dabbled a bit with notfications/messaging before, and although the API is a bit intimidating at first, it's a very nice abstraction to not have to deal with message delivery etc., and it's a real nice way to go, since it gives a lot more control to community sites.

I'd like to take a stab at it, if you don't mind.

Subscribing +1

+1 for integration with messaging and notifications frameworks. seems great to let those modules do what they are designed to do and let this module concentrate on core functionality of user signups.

Hmm, I've gotten some work done, and I've come across a bit of a conundrum.

If we want to separate the signup_mail stuff from the main signup module, it follows that we should remove the e-mail-related columns from the signup table. But before they are removed, we should make sure to migrate the data away into the new signup_mail table. But how do we make sure that has happened before we drop the columns, since the migration should probably happen in signup_mail.install and the dropping in signup.install…

To my knowledge, there's no way to guarantee that the upgrade hooks run in any specific order.

Here's the work I've done so far. The data migration works, but the code for dropping the old columns have been commented out until we can find a way to drop them safely.

I've also started moving the code out of the signup module, but that is far from done.

Sorry for my asking, does the patch work with 5.x-2.7?

Thanks

+1 for #4: You have this nice "attended" feature, but there not a single blessed thing you can do with that information, that I've been able to discover. Am I wrong about that? What's it for? How can you use it? Follow-up emails would be the next obvious step, and relates to this thread/issue.

Even better, though I daresay a completely new feature request, would be the ability to select all those who attended and assign them a new role.

Subscribing. I'm very interested in a solution that works with notifications/messaging. Will probably test and help with module(s) for this. Is the patch in #14 for the D6 version?

Subscribing

I tried the patch, which failed, and then I realized it was against the aborted 6.x-2.x-dev version.

But I very, very much want this.

Not having cancellation notification is a deal-breaker for my users. Signup Status doesn't help, because it only takes one site-wide set of addresses.

I tried the hacks: Rules, Form Rules. Didn't help.

Guess I need to sit down and learn PHP, because I don't understand why signup notification is automatic, but cancellation notification is a big hairy deal. And I could help. Also.

hi,

is signup module allow user/member to set their own X number of days before event start?

No, those are set by the administrator/author of the event and apply across the board to all signups.

Subscribing....

I still need this one: #118794: Using Event author for "send signups to" address

So if that's been deferred to this effort, is this effort still live?

Subscribing for e-mail attachments like pdf files

subscribing

subscribing

Yikes! Two years old...

subscribing.

subscribing.

Some month ago I started rewriting signup to use http://drupal.org/project/messaging instead of sending the mails on its own.
The attached file is a rough start and just a reminder for me to work on this again in the near future.

I was looking for a way if attaching an application form to the signup confirmation and ended up here.
Seems like a good idea to split the e-mailing out in other modules.
A'm an able programmer and currently co-maintains FAQ_Ask.
How can I contribute and where to start?

@stenjo:
If you have lots of time you could try to redo my previous work and use http://drupal.org/project/messaging for sending mails from signup.

Building a patch for this would be a great step to remove the email functionality from "core" signup module.

subscribing

Definitely would like to see this - also, would it be possible to have notifications of signup based on roles rather than specific users?

Subscribing

subscribe. I highly suggest someone take stBorchert's work in #30 and expand on integration with the messaging framework. With 18018 sites using the messaging framework signup would likely only see a boost in usage as a result. Personally, my company is not building a single site without the messaging and notifications modules.

The official signup module thread for messaging and notifications handling of outgoing mail/messages is here: http://drupal.org/node/369637#comment-4086116

So - this was a while ago - and fully aware the 2x branch is no longer active.

However, to get the ball rolling again, I merged and made a patch from #30 -- against the snapshot stBorchert was working on (took a bit to find which one! For my ref, it was git reset --hard 17832bd3f95a0e2ddf6edaa0f0a4e52865ab88df).

There's no way this is going to apply cleanly to 1.x yet, but it's a start

straight git-formatted patch against 1.x

I wonder what this will break...