Using Event author for "send signups to" address

+1 for this feature please!

I have taken a VERY brief look at the code, and a fix seems to be easy.
I've attached a first - quick - hack.

The idea is simple, if you put %eventowner as the email address, you get the user email of the person creating the signup event.

There seemed to be 2 places in the code that looked like they were doing this, but only one seemed to make a difference! - So - clearly I didn't follow all the code, but then, I only had 1/2 an hour to look at it!

So, if this is the right sort of thing, I'd appreciate it if somebody who has a better knowledge of the code made sure I've done it right... And then, possibly updated the GUI to let people know about this functionality.... If you want me to do some of this, then just let me know :-)

The patch is against a "signup.module.old" as I dont have the CVS checked out....

Thanks for doing this - looking forward to testing it out.

i'll try to take a look in the near future, but the critical bugs are my higher priority.

thanks for the patch,
-derek

+1 (worth waiting for :)

this patch is all wrong, sorry... global $user is the user currently viewing the page. i think you're trying to get it so the *author* of the current node gets the notification emails. this patch only works if you only test everything as a single user. ;) also, using a token for this seems weird from a UI perspective. i think i'd rather have a set of radio buttons for this. something like:

(the "event" part would be replaced automatically with the appropriate human-readable node type during form creation).

i'll put this on my list of things to consider as i get ready to do some major new work on this module, but i personally don't use these email notification features, so i'm not too interested in writing this myself.

(edited to fix a broken HTML code tag on 2008-03-31 by dww)

Oh, I will have to look again!

The plan is though that you create an event type (in this case the signup event) as an admin, but it's the user that creates an instance of this event that you want emails to go to...

So - in this case, "user" seems to be exactly what I want?
It's the user who is creating the event.
anyway - for me (with a few test users) it kind-of-seems-to-work?

Of course they COULD have put their email address in themselves, but the point is to make it easy for them :-)

As for the radio buttons - I agree.... ideally the UI should be radio buttons OR a text field (i.e. if you select the radio buttons, the text field should disappear) - which was getting beyond my care-about threshold :-)

point is, this will be confusing and wrong if, for example, someone with administer nodes comes to edit someone else's event node. if you want %event_owner to map to the author of the event node, you have to grab that value directly, not rely on the currently logged in user. also, the whole approach for this token is weird. the admin puts the token in the admin settings page. the user (if they're not confused) leaves the token alone when creating the event node. then, on submit, it gets re-mapped to the author, and stored in the DB that way. what if the event changes ownership? the notifications will still go to the original author. in a way, it'd be better to just store it in the DB as %event_owner and then when we're actually sending the notifications, if we see this magic token, we do the replacement *then*, with whomever the current owner is...

re: radios vs. text field -- my ascii mock-up maybe wasn't clear. i see 3 buttons. inline with the last one is a text field (which is only looked at during form submit processing if that radio was selected). yes, in 5.x we could use some jQuery magic to hide that text field unless that particular radio was selected, but i'm not sure it's important enough to worry about.

also, keep in mind that this patch isn't going to apply at all as soon as i commit http://drupal.org/node/49007 (which will happen any day now). that's got some initial jQuery goodness in it, in fact. ;) so, if you're serious about getting this working, i'd start from a fresh checkout from HEAD with the latest 5x-specific patch from there, and work from there.

cheers,
-derek

Would this UI work ?:

1. There is only one text field for emailing notifications to.
2. On Node Create, the text field's $value is not set, so a Signup module function pre-fills it with the creator's = current user's email address from their UID ... (if anon user, leave blank)
3. The creator/editor can edit the email address as required, but this default seems like a pretty good guess.
4. On Submit, the $value is stored in the database.
5. On Re-Edit, (by anyone) the $value is called back from the database and may be edited manually.
6. On Re-Submit, whether edited or not, the $value is re-saved in the database.

Does that make sense to everyone else ? Have I missed something ?

well, it doesn't work for what you have now: the admin can define a site-wide default where signup notifications are sent. maybe they have another system integrated with their event management stuff that wants to get these notification emails. in that case, the site admin just wants to set this address once, and does *not* want it to get sent to the owner of the node.

so, i guess you could have the global admin setting as a radio:

or something. that'd be the site-wide setting at admin/settings/signup. then, the per-node form works mostly as JohnG describes above, except the default is empty if the site-wide radio is "None" and the default is whatever the admin defined if the radio is "Other"...

just brainstorming here. ;)

well that seems like a pretty good brain to go storming in ... ;)
one thing though, if the site-wide radio says [None], I would interpret/expect that to mean 'disable Notification emails' altogether ... likewise with Confrimation and Reminder emails ... ? maybe not a bad thing ?

that's exactly what i have in mind for all of them, yes... on my site, we don't use any of those email features. my copy just has the code removed, but i'd rather make it an admin option in the UI.

sorry, I was asleep :-)
I get the point about User now - that would show up as whoever last edited the event, which would not necessarily be the initial author, as you say....

I like the 3 radio button, single field idea....

My buring desire for this functionality has wained somewhat - but I guess dww, yours rests at zero.... do you want me to take another shot at this, or do you think you may have time yourself?

Cheers

Mark.

for future reference: if i plan to actively work on anything, i assign it to myself. the fact this issue is "unassigned" means i won't be working on it anytime soon (if ever), beyond arguing about how it'd have to work for me to consider committing it. ;)
please have at it, if you're so inclined...

p.s. my ideas on the future of the signup.module: http://groups.drupal.org/node/3430

Was about to have a look at this again, but in (re) testing it, I discovered that things are not quite as broken as I had thought!

First, thinking about the UI:
The strange %eventowner thing is only used by the person setting up the event type. ... Typically this person is an admin. They are, in essence, setting up a system wide default for emails to be sent to regarding this type of event. In my case, I think I might like to see the "traffic" so, actually I want the string me@my.address, %eventowner. In other words, the "radio" buttons become a single additional check box for the event owner. As they might want to send to other addresses as well....

However, the principle problem I thought the code had was that the user who adds an event would see %eventowner, and would be somewhat confused. further more, if an admin then edited the event, and the did nothing else, then they would "clobber" the mail back to the event owner by overwriting it with "admin".

Actually, this isn't the case. The user sees their own email address when they create the event. This is, as far as I am concerned, perfect. I do not want them to see anything else but a single field with their (registered) email address in it. They could change the address to send the mail somewhere else - I can choose if I want to let the UI give them this possibility or not (possibly using form-filters or some such).

However, I dont need, or want them to be presented with the check button saying "send to the event owner" because, for them, this makes less sense than simply seeing a field with their email in it !

Further more, when the admin edits the event, they see the email of the person who created the page... they could change that (of course), but they dont see %eventowner. So, I dont think this is a problem either.

In the end, especially as it means the users interface is simple, I think this idea of %eventowner is not so bad. Probably more by luck than good management, it seems to be processed at exactly the right time, so the new event gets the right email address in it.

We could replace the %eventowner with a checkbox, that would work fine, but then I think the check box should be removed from the user's UI which is probably more hassle than it's worth?

So, for now I'm leaving it as it is, but I'll help put the checkbox in if that would really make a difference?

Cheers

Mark.

Mark I've been trying to get this patch to work on D5.1.

1. When I put %eventowner into the notification email box on the signup module settings page and submit, sure enough, the token is replaced by my (admin) email address. If I resubmit, my email admin address is used as the value - ie it overwrites the %eventowner token, and this becomes the default value in the node-edit form.

(so I reset it to the token and then ...)

2. When I login as User2, create a signup event, go to the signup node settings, the box shows the %eventowner token and on submit it just stays that way. I double-checked the db field value using a view: it lists %eventowner as the 'notification email' value, not User2's email address. I suspect %eventowner is being used as a string not a token at the crucial point ?

The token is not being substituted in the right place. Where it works (module-settings) it is actually confusing ... and then it doesn't work where it's needed (node-edit). The behaviour you describe in #15 sounds great ... but it's not what I'm getting :(

Please could you check that the eventowner.patch posted at the top of this thread actually corresponds to your code changes ... the patch modifies the function _signup_admin_form right ... ?

doh DOH DDDOOHH!!!!!!

dww was ABSOLUTELY right.... and although I tested it, I didn't quite test it enough!
My test was to log in as one user, alter the site-wide signup event default email, and then create an event, log in as a different user and see what happened.... well - it all works... the minor problem is that I didn't change user between setting the default and creating the event !!!

So - this patch is, as dww has said, about as helpful as a chocolate tea pot.

No guarantees, but I will try and repair the thing.....

I had a little play
Accepting that I haven't put a check box in place, and simply used the %eventowner thing, which is not nice, but I think DWW you're going to make changes to the UI, so I've left it as it is for now, then the only bug I could find is that the %eventowner gets replaced on the admin settings page as well as on the normal event creation page.

Again, this isn't necessarily the right or proper way of doing this, but I have simply passed down an extra parameter to determine if this is in the settings menu or in the event creation page.

For _me_ it seems to work.

I have included a patch to be run over my previous patch (since John mentioned that he had already used that, then I hope this makes his life as easy as possible)

Cheers

Mark.

+1 getting this into the official release. I had been experimenting with the Prepopulate module to accomplish this functionality.

Unfortunately, it would seem this patch doesn't work on 5.x-2.4. Is that correct, or am I just doing something wrong?

Any help is much appreciated, as I would desperately like to have this functionality, but am rapidly learning that I do not possess the skill set to make the modifications on my own :(

FYI: see also #237986: Default/Per Node Confirmation which is sort of related.

Subscribing.

I think the basic concept articulated in this feature request is a good one.
However, I believe the whole email functionality of this module is weird and needs rethinking.
Therefore, this is hereby postponed in favor of #290305: Split out email functionality into separate submodule(s).

I just installed/configured this excellent module for a client and they couldn't be happier EXCEPT the notification sender email address is the site administrator, not the one defined on the signup admin page (admin/settings/signup) OR the node author as suggested in this thread.

This design decision is not very practical as often the site administrator and volunteer coordinator are two different users.