Switch from Flag to Signup for personal session schedule

I am +1 on this. Signup functionality seems much more useful.

Just need to bear in mind that sometimes people add two concurrent sessions to their schedule because they're undecided, so signup numbers won't be an accurate count *but* if those signed up are getting emails, then they might cancel their 2nd signup.

+1 from me... flags doesn't compile the list of attendees via views, even with relationships... I had to add the Flag Vista modules in order to compile a solid attendance list (of flagged users per session item). Works like a charm, but if signup will does this out of the box, let's use it.

Also, if signup will make each session selection/scheduling mutually exclusive, awesome! Hate to have folks register for multiples b/c they are undecided and "lock out" others b/c they create full sessions.

I'm not convinced this should replace the flag yet because of the complexities and assumptions Signup makes (such as sending a notification upon signup, and closing signups X hours before, etc). #152659: Signup toggle link can probably handle most of those, but moving to Signup here adds config management. I'd like to think on this more and finish the Signup link issue.

Signup has a global default that can be configured, and overridden on a per-node basis.

That is true for the email that is sent upon signup, but not for the reminder email. If the session node type does not have a date field associated for signup there should be no reminder though, correct?

Edit: I wouldn't define "trivial" to include code-level changes , which in this case there will at most have to be a form alter to keep the "Send confirmation" checkbox unchecked for all new session nodes, and at least a strongarmed variable. Or perhaps we leave it on?

Ok, so the reminder email setting on the node only exists if the content type has been configured with a date to use. I think by default we should not use the time slot noderef (if we even could).

I see the concern about adding this to cod. We need to keep things super simple if we want them to be easy to use and signup is not historically all that simple in terms of the configuration screens.

That said, it seems like there's a lot of benefits to using signup and we can "just make signup simpler" like that link issue you mention which seems at least 90% ready to commit.

Our current alternative is "use flag and views and maybe some glue code" which doesn't feel all that much simpler.

So far the commenters on this issue are almost entirely in favor. I feel like we should move forward with it.

Signup writes the confirmation boolean to true in signup_save_node(), called from signup_nodeapi(). It looks like we can't hook in before it's written, the bool is taken from the default record in the signup table. Perhaps we could make the confirmation configurable per content type as part of Signup itself?

Ezra, please look at the code, I don't see how we can set a property of the node object that will override the send_confirmation bit. We'll have to do it afterwards or alter Signup. We also can't use hook_form_alter because the signup admin page would have to be saved, which is not in the std workflow of session submitters.

@giftsketcher: Could you describe how you use Flag Vista to compile a list of users per session? Do you think it can be used to compile a list of attendees for a specific event too? Thanks.

The user stories for the request have been resolved in one form or another in the 7.x version.