Ability to signup for a friend

Here's what I did to enable a user to sign up for a few of their mates as well as themselves. You will have to already have the seat limit patch.

1. Add an integer field called "seats" to the signup_log table, make default value "1" so existing signups aren't affected.

2. Change every declaration of $total_signups to the following:

It adds total reserved seats rather than total rows in the table.

3. Find form_submit(t('Sign up')) and then in the "IF" statement just above it add this as the last line:

4. Amend the following lines in "function signup_user_signups_form":

And that's it! Users can now reserve multiple seats to an event.

Hehe I almost forgot the most important bit - need to insert the new data into the table.

Find this in the module (around line 515) and amend:

where is this mysterious user seat limit patch??

i'm looking at the ever-growing amount of feature requests for this module, and two things are becoming apparent:

1. there are lots of use cases for it, and lots of people interested in using it
2. it's poised to become a spaghetti mess of code if we don't come up w/ a solid core/plugin approach

thus, i'm postponing the addition of any new features until i've had a chance to think this through and talk w/ some other developers. i've scheduled a meeting at the upcoming conference w/ the co-creator of signup module, and hopefully we can hash most of this out soon.

:)

There's nothing resembling a patch in here. ;) This is "active", meaning -- "need to figure out how it should work and someone has to write a patch"...

actually - there is no patch yet (d'oh!) - one coming soon...
gotta catch up on HEAD, and make our changes applicable to 6.x-2.x...

Edit: dww beat me to it ;) -- gotta remember to refresh my browser before posting comments!

Hi dww,
Here is a stab - patch against HEAD (6.x-2.x-dev) attached.
Marking as 'needs work' cause I *know* it doesn't quite work properly yet ;)
But it does do some things correctly already, and accounts for things not included in the initial code above (and of course Signup has changed a lot since 2006).
...the problem comes when I try to visit signup admin form @ node/N/signups the screen is blank white :p
To be honest, I'm not sure what I must be overlooking - I've checked for typos and obvious blunders and can't find it yet. So I'm posting an unfinished patch here assuming that another pair of eyes will help track it down 8-)

Attachment	Size
signup-seats.patch	6.93 KB

Syntax error:

That's not in the middle of an array definition, it's just a free-standing line. It needs to be terminated with ; not ,.

I strongly encourage you to configure your test site to display errors to the log and the screen. ;) I didn't get a completely blank screen, I got this:

Parse error: syntax error, unexpected ',' in /.../sites/all/modules/signup/includes/node_admin.inc on line 67

Which took me right to the problem...

p.s. Your patch doesn't apply cleanly anymore, due to #346810: Fix invocation of hook_signup_cancel() so that the record in {signup_log} is still there and other recent changes...

hi dww,
re #9: yep! that was it - so it was an obvious thing after all :D

re #10:
* For the hook_signup_cancel() part (#346810), this is just a matter of remaking the patch against the current HEAD, so the line numbers match cleanly (don't need to change anything else to account for this), right?
* For the 'other recent changes' part, this is going to take more work, 'cause I just started to get my head around the Signup2 changes since the day before! This is really great though, and I'm glad progress is moving so rapidly...

One thing I want to ask you about relating to the recent changes, before spending too much time:
It seems to me this patch should now probably also adjust the attendance tracking, to allow for 'number attended' rather than just yes or no. The table column is already an integer, so this should not be a problem, but the value options in signup_handler_filter_signup_user_attended.inc should probably change to allow multiple numbers. Something like this:

...up to 10, matching the proposed options above. But this seems kind of inelegant (what if someone wants to allow only 2, or up to 20 seats per signup)? Maybe this number could be configurable, either in the sitewide Signup configurations or per node, rather than being hard-coded to allow options for 10 seats. Does this seem plausible?
If so, this would then need to be updated in:
1. signup.views.inc (specifically the $data['signup_log']['attended']),
2. and the function theme_signup_attended_text at the bottom of node.admin.inc,
3. and the $form['operation'] in node_admin.inc should then change from 'attend_yes' or 'attend_no' to 'number attended' as well.
4. am I missing anything else that pertains to updating attendance tracking for multiple seats?

Another thing I want to ask opinions on is whether the multi-seat option should be permission-based (for instance, to not allow anonymous users to 'signup multiple seats'... following the logic that 'sign up for content' is something that is a permission setting even though signup status can also be enabled per node). Not adding that yet, but would be good to hear if adding yet another permission sounds reasonable or not.

I'm working on an updated patch to address comment #s 9 & 10 above – but it'd be good to hear feedback on my question about whether the configurable seat number direction is viable before I work on that part :)

hi dww, here's 2nd patch. Again, I'm missing something, and once again I can not see what just yet... I have tried to account for the above (though the 1-10 seats is still hard-coded I would think this should work for now but it doesn't quite). So I'm keeping the issue as 'needs work' but I hope it's getting closer?

Attachment	Size
45248_signup_seats_2.patch	11.62 KB

Meta: I'm not sure how this feature should work in light of the big discussion we had in #drupal-signup in IRC this morning about signup_status, signup fields, webform, etc. It's not all resolved yet, but it seems like this is a good candidate for something that should just be handled by that whole system instead of being hard-coded. At least it needs more thought before I'll actually commit this. That said...

A) Yes, this patch should impact the attendance stuff. However, if attendance becomes a full int, not just a bool, that whole view filter needs to change from being a boolean operator to an int. That'll avoid the weirdness you're doing trying to hard-code N different "4 attended" choices, etc.

B) {signup_log}.attended needs to allow NULL and default to NULL so we can distinguish between "no on recorded attendance yet" (NULL) and "this person didn't show up" (0).

C) theme_signup_attended_text() can use format_plural(). Actually, if it's just "1 Attended", "2 Attended" ... "N attended", you can just use return t('@number Attended', array('@number' => $attended));.

D) So long as theme_signup_attended_text() is working, I don't see how this would matter for signup.views.inc and signup_handler_field_signup_user_attended.

E) I'm not sure about recording attendance via the existing UI given this potential change. :( Part of me says "you record the signup as attended or not, and that includes all the seats". However, I know that's not reality. :( You might signup as "dww + guest" and then your date doesn't show up, and of course you want to record that information so you can shame dww with a view of events they attended where they signed up with guests that didn't show. ;) So, this gets nasty. The UI would be unworkable if you had separate "operations" for "mark as 1 attended" vs. "mark as 3 attended" etc. :( Probably the default from that bulk update UI is mark as attended == everyone attended, and then provide a way to individually edit the attendance for a specific signup so you could handle these edge cases where you signed up for 5 slots and only used 3, etc.

F) This: drupal_set_message(t('Signup to !title confirmed. %signup_seats seats have been reserved.' also needs format_plural().

G) I'm not crazy about using "seats" for the UI, schema, variables, etc for this feature. I'd want to give that more thought. Not every event has "seats", and not every use of signup is for events, even. Maybe "slots" would be better, but that might be too generic to be useful. Anyway, better ideas welcome on this front.

Thanks for the feedback dww, and the discussion on IRC (the upcoming changes will be a real improvement).

So it looks like there will be a completely different way of doing this in a month or so, but I needed this functionality in the meantime so still want to resolve this patch - and will be happy to upgrade once those upcoming changes are in place.

Ok, so till then, here's another version that addresses A, B, C, D & F.
* Because of the above caveat, I kept E for the meantime, because allowing 1-10 seats per signup covers my needs and it works :)
* I also left G ('seats') for the meantime - but I agree that 'slots' genericizes this to cover other cases which would also affect calculating totals - so if this is still relevant by the time the new direction is decided next month, we should probably change the column and function names to 'slots' then.

The one thing I can see now that doesn't work perfectly yet is there's nothing preventing users from signing up 10 users when we are only 9 away from the signup limit. It will appropriately close the signup and say that it has reached it's limit... but it would be better if this was factored into the form validation so the user must select 9 or less seats in that case before the signup will go through. If anyone has ideas about the validation - that would be great :)

Attachment	Size
45248_signup_seats_3.patch	14.87 KB

Patch updated for current 6.x-1.x-dev, which was tested & committed as 6.x-1.0-rc3.
Happy holidays!

Attachment	Size
45248_signup_seats_4.patch	13.25 KB

I don't think we should add this feature until the following issues are better understood:
#29568: Flexible number and type of fields
#359411: Add a hook to allow modules to alter the total signup count

I'd argue that even if we go ahead with both of those options, how many slots/seats/whatever a single signup has allocated is probably still a core piece of data. So while a lot of different UIs and uses of that data can be implemented in other module with hooks, we would still need this data to be stored.

mikl: Nope. If we have a real solution for signup_fields, this is just another field, and it doesn't need to go into {signup_log}.

Okay, "need" was probably the wrong word in this context. Sorry for that.

I think he best solution for the arbitrary fields problem is fields in core, which we won't see until Drupal 7 comes out. And even then, I think some of the most common fields should be kept in the core signup tables for performance reasons.

I think the current model is a good compromise, and the only reason I'm not satisfied with just sticking this data into form_data with all the other interesting stuff we collect is that the number of seats is used for automatic closing of signups etc., so I'd still have to hack the signup module, even if I didn't change the database table. In addition to that, creating an aggregate of the number of seats taken/available is a very complex (ie. slow) operation that involves grabbing all the signups from the database and deserialising them and adding them together in PHP, which is a bit of a performance hassle if you have a site with a lot of signups.

Hi guys, this is pretty minor compared to finding a solution... but in case anyone's making use of this feature in the meantime, here is an updated js file that actually works. This replaces signup_form.js added by the patch in #15.
For anyone who cares to use this, you'll also have to remove the js-hide classes I added in signup_form.inc (also through patch in #15), since that method is no longer used in the new js file.
Any feedback on how to do the JS in a more 'drupalish' way, it would be great to hear... :)

Attachment	Size
signup_form.js_.txt	903 bytes

sub

Hi,

(@#20) I haven't understood how to use this js and why.

The patch in #15 (signup_form.inc modifications) doesn't describe any impact on a .js file.

@ Alex72RM: You're so right (d'oh!). The js file in #20 was actually meant for this issue: #349228: Signup anonymous users without email. Good catch! I was wondering why I didn't get any feedback on that js file yet.

Any chance that a mulitple-seat signup patch will be ported down to D5? I could definitely use the ability to let users sign up for seats for the whole family, and moving to D6 is not an option for me right now.

@brianbrarian: Not unless you can hire me to do the work and maintain/support it in the future... 5.x-2.* is in code freeze now, and I have no intention to start a 5.x-3.* series for new features unless someone is paying for it. ;)

What can I do to help get this in? I need this for a project as well.

In the meantime, I'll apply the patch and test.

Edit: Ok, maybe not. The is obsolete, I see.

Ok, I'm thinking the feature at http://drupal.org/node/349228 is actually more what I need. I'm going to look at that and see if I can get it into a module so it doesn't require repeated patching.

Thanks so much for the patch! I"m hoping someone out there might help me tweak it some (or understand why I can't).

My site is for families, and different events are limited differently-- i.e. some allow an unlimited number of adults but a limited number of kids, some are limited by the total number of attendees, sometimes really little kids don't count toward the limit, other times they do, etc...

I have been customizing the signup forms per node within the theme, and I'd like to code the total for signup_seats per node too, instead of having a separate pull-down that is essentially asking people to sum two or more numbers they just entered into a computer (sadly people seem to get it wrong fairly regularly, not sure if it's a reading comprehension issue, or one of arithmetic.)

I'm very very new at programming w/Drupal & object oriented php, and it's not obvious to me which variables can be accessed by which files-- can I define the value of signup_seats as a function of entries into the signup form (i.e. have people submit how many adults are coming, and how many kids are coming, and then define signup_seats as adults+kids or whatever)? If I can, in which file would I make the change?

Thanks for any help,

Ellen

Note: this is mostly going to be fixed for real via the changes I'm currently working on for #359412-6: Move code for signup limits per status per node into a submodule.

Awesome-- Thanks!

subscribing