Ability to signup for a friend

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-)

Syntax error:

    $form['signup_seats'][$key] = array('#value' => $signed_up_user->seats),

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:

-    $this->value_options = array(1 => t('Attended'), 0 => t('Did not attend'));
+    $this->value_options = array(1 => t('Attended'), 0 => t('Did not attend', 2 => t('2 Attended'), 3 => t('3 Attended'), 4 => t('4 Attended'));

...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?

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 :)

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

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... :)

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

As far as I can tell, this feature isn't in yet.

I'd love to get it in, and have started on a "Signup guests" module to:

• Allow privileged users to specify a number of guests.
• Support default signup status for guests (similar to signup_invite).
• Tallies the guests in the total signups.
• Support max guests / user configuration.

What say you, DWW? Are you also working on signup a friend?

+1 for a "guest(s)" feature. I'd definitely be willing to test and/or help code this. How far along are you with this?

I'm also working on a feature to allow users to claim multiple "seats" when they sign up. For my application, it would be someone claiming spots for their family, and so I don't need the same registration info for each of the "guests" as for the primary registrant, and the whole registration shares one "status".

My feature will allow event organizers to define several "ticket types" and designate which count toward the total signup limit.

kentr-- the impression I get is that in your module, someone would be able to add additional registrations for other people, much like someone with permission to administer signups can, but each registration would only claim one "seat". Is that correct?

kentr-- the impression I get is that in your module, someone would be able to add additional registrations for other people, much like someone with permission to administer signups can, but each registration would only claim one "seat". Is that correct?

Each person would occupy one seat - guests and primary registrants alike. Guests would count toward total number of allowed attendees. My usecase requires that guests / sponsors have independent statuses.

I haven't gotten very far on my implementation... Have only started exploring the form alter mechanism with a shell module ("signup_status_guest"). I can provide that if helpful.

Hey guys,

Our implementation allows a number of seats per signed up user (something like RSVP +4 guests functionality).

I just scanned #359412: Move code for signup limits per status per node into a submodule which seems to promise the sub-module approach would now be the best way. It doesn't say the feature is built, but that the feature now *can* be built (hopefully) without patching Signup every time there's an upgrade.

That's great news for us because our implementation (the patches farther above) probably no longer apply to the latest version so we'd need to re-roll/re-think them anyway.

Not sure exactly when we'll get to this but I will definitely keep you posted here :)

There seem to be two ways to handle this.
You can have a single signup record able to optionally represent several people.
Or you can have a single submission of the signup form create several signup records.

My feeling is that the second -- expand the form, create several signup records -- is the better approach. Though this may depend on the use case and the sort of data you are recording for participants.

If your event is community theatre, then you might want to take a name and phone number, but that would be okay for the whole group booking -- you only need one contact, and in fact, if you need only phone one person in that group then so much the better.
If your event is a conference, then you need one signup per person to record each individual.
And it's not even a split between formal and informal events, as if my even were a party I was booking a restaurant for, I might want to know who is vegetarian, which means one signup per person.

I wonder whether the way to cover both cases would be go with the second method, but to allow that some signup fields can be group-wide, and so only appear once even when you expand the form.

Like this:

- phone (for all signups):
- signup 1:
-- name
- signup2:
-- name

joachim wrote:

There seem to be two ways to handle this.
You can have a single signup record able to optionally represent several people.
Or you can have a single submission of the signup form create several signup records.

''

I would argue that the first option would be better stated:
You can have a single signup record able to claim multiple signup slots.

Removing the requirement that each signup be attached to a different name makes the module a lot more flexible, IMO, as it could be used to claim table space at craft fair, or parking spaces, or tickets to a charity dinner (where people often buy the tickets first and then figure out who they'll bring along). Actually I think it's fairly common for people to claim a couple tickets for a social event, and then start looking around for a friend or date to bring along. And most of the time, the event planner only needs to know how many tickets they need to give to whomever when they show up, a complete list of names is unnecessary.

There are situations where each signup needs a separate record, for example, a conference, where each registrant needs to choose where they will be for sessions A, B and C, and whether they want to buy a bag lunch, and the organizer needs to provide an itinerary for each registrant. But I'm not sure that this is the type of event for which the signup module is most commonly used.

There are other situations, like the community theater example, where requiring a name for every person that's coming is going to make the signup process tedious and may feel invasive. It would be MUCH simpler if the registering member could just select the number of tickets they need, and this would provide all the information the event planner needed. I would argue that your dinner example could go either way-- you might like to know the names of any vegetarians ahead of time, but it would probably be perfectly adequate to know that Mary is bringing a group of 10 and 4 of them are vegetarians, and it would allow Mary to fill out a much simpler form.

I see the attraction of trying to find one solution that will work for all signups, but I think it's more important for the form the registrant sees to be appropriate for the event, and not a kluge intended for a different kind of event. Maybe the best way to do this is by having two modules, one for conferences and one for other things.

My ideal signup form:
Registering adult's name
contact phone number

Number of [type A] tickets (i.e. Adults-- this description would be easily customizable by the node author)
(optionally, if the organizer chooses, the appropriate number of name/age/whatever fields should appear below the select box)
Name
Adult 1
Adult 2
Number of [type B] tickets (i.e Children)...
Name Age
Child 1
Child 2
Child 3

Number of [type C] tickets...
.
.
.

My priority is that it needs to be very simple and obvious for an organizer to customize the signup form, and it needs to be very clear to the registrant when they see the form that they can signup multiple people, and how to do that. There are people who will not enter anything into a form if it appears to them at first glance that it will only accept 3 names, and they need to sign up 4 people. Instead of trying they will panic and complain to the organizer about how difficult the website is.

The event organizer needs to be able to easily generate a list that tells them from whom they should expect payment and how much. The ability to generate a list of all participants for name tags might be useful, but its less important than letting them easily be able to see that Mary is bringing 10 people.

No real time for this today (I'm working on http://3281d.com/2009/12/28/d7-update-manager-code-sprint instead) but a quick note based on skimming the last few comments. I'm more interested in this issue to solve the "one signup record == N slots" problem, basically what ln282 is saying at the top of #38.

To solve the other problem, what joachim is talking about, we should avoid making it too complicated. I think there could just be a new permission, something like "allow signing up other people", and anyone with that perm basically gets access to the existing admin UI to signup other people. And, for both this new perm and the existing admin UI, it'd probably be a good idea to add a new column to {signup_log} like "signup_created_by_uid" (obviously with a better name). But, e.g. record the fact that UID 12 signed up user 38 for nid 2333 in signup ID 235. Then, you could easily do stuff like "show me all the signups for nid 2333 that uid 12 created", which seems like it would solve all the concerns about an office coordinator signing up a group of people for an event, and Bob being the contact person.

Also, since all the signup limit stuff is now done, and there's an active patch for the fields question, I think this issue is active again. ;)

"one signup record == N slots" doesn't feel like good data storage to me.
I completely agree with ln282's use cases in #38, but I think that should nonetheless result in N signup items, even if no extra data, such as name, is collected for the extra tickets (so all those except the first are rather bare entries in the table).
The UI can still be as ln282 lays out -- I'm just talking about the data.

It just feels like an unnecessary complication for things like counting how many slots are taken. It feels like we are solving two related problems with completely different systems, whereas they could instead just differ in their UI.
(And another reason is if eventually we want to have allocation of specific resources such as seat numbers.)

@joachim: We already have a "how many slots does this signup record count as?" field in the code due to signup_status integration. It's just a question of making that available to users.

In terms of complication in the code, I'm worried about "dww + 3 guests" == 4 records in {signup_log} that require a lot of special-cases to avoid treating those as separate signups. If you *actually* need all the power of full-blown records, you could do that as I described in #39. But for a lot of people, all they care about is "dww +3", and that'd be a lot easier with a single record in {signup_log} where count_towards_limit is 4.

I threw together a simple add-on module that allows users to signup guests for a project I'm working on.

@dww and others: Let me know if this is useful or whether it's something you'd prefer to incorporate into the signup module itself. If you'd prefer to keep it a separate module, i can commit it to CVS.

I don't have time to test your module right now (sorry), but I did scan your code, and I think there's a small change you might want to make.

Signup_Status has a feature where the admin can decide whether or not signups with each status counts toward the limit. To implement this, the signup_status module changes count_toward_limit to either 0 or 1. For the guest module to work properly with signup_status (which would be ideal, IMO), one of the modules needs to check to see if the other has already changed count_toward_limit.

@dww: I've seen some of the weird special cases you mention while working on the multiple fields patch. My gut feeling is still that if it's a choice between special-casing data storage or output, then it's output that should bend to data and not the other way round -- but you're way more familiar with this code than I am, and most of the log stuff I've barely looked at :)

Here's a scenario I thought of:

My site has a signup node that allows signup for a friend.
User Alex comes along and signs himself up + 3 friends.
(This creates a single signup record, marked as counting for 4 places).

But a week later Alex remembers that Brian's girlfriend is a vegetarian -- in other words, his one signup needs to be changed to say it's 3 non-veggies + 1 veggie.

What happens next?

On my site, for that event, there would be 2 ticket types for the event, vegetarian and non-veggie. Alex's initial signup would be for 4 non-veggie tickets, and 0 veggie tickets. The correct signup would be for 3 non-veggie tickets and 1 veggie ticket. Both signups claim the same number of signup slots-- the distinction between the two ticket types is only to allow the event organizer to plan.

In your scenario, if Alex has permission to edit his own signup, he would go to the event and edit his initial signup to make it correct. If he has permission to cancel his signup, he might cancel the incorrect registration and enter a correct one. If he doesn't have permission to edit or cancel his signup, he'd email the event organizer with the change request, and if it was an acceptable request (i.e. he's not trying to do it 5 minutes before the dinner starts), the organizer would go in and edit the signup.

Ellen

@dww I'm starting to think that count_towards_limit isn't well-shared by signup_status. Changing signup_status so that it either sets counts_towards_limit to zero or leaves it unchanged (as opposed to having it hard-wired to set it to 1) is simple, however, once signup_status sets count_towards_limit to zero, the data for how many signup slots the record has claimed is lost until the form is processed again. This is a problem if the status is changed from, say, "waiting list" to "confirmed" using VBO.

I'm posting this here because it seems like the best place to put it, but if it should be posted elsewhere, please let me know.

@setvik:

Post it as a separate module, with the condition that you'll deprecate it if something better comes along from the others in this discussion or DWW wishes to roll it into the main packages.

I've taken your work and added some stuff:

• Setting for default max guests per content type.
• Translatable strings.
• Bug fix to make the per-node setting form element reflect the actual stored value for the node.
• Config option to use the signup_status default status for guests & integration with with signup_status_limit (in progress).

In the meantime, here's a branch of Setvik's work. It handles most of the issues discussed above:

You can have a single signup record able to optionally represent several people.
Or you can have a single submission of the signup form create several signup records.
My feeling is that the second -- expand the form, create several signup records -- is the better approach. Though this may depend on the use case and the sort of data you are recording for participants.

As Joachim mentioned, in some usecases it would make things easier if records were separated. In my case, I needed independent statuses.

I chose a mixed solution: one signup_log record for the user who's executing the transaction, and one record for the guests (aka parent / guest records). IIRC, the primary impetus for this was easier integration with signup_status.

My site has a signup node that allows signup for a friend.
User Alex comes along and signs himself up + 3 friends.
(This creates a single signup record, marked as counting for 4 places).

But a week later Alex remembers that Brian's girlfriend is a vegetarian -- in other words, his one signup needs to be changed to say it's 3 non-veggies + 1 veggie.

What happens next?

The architecture in this implementation will eventually allow for mixed statuses among guests: I'm thinking each set of guest statuses for a user will get a new record in signup_log. This would require a status select element alongside the number of guests option. Fairly easy to include, I think -- I've turned it over in my head and planned it into the code a bit.

To allow output flexibility for different cases, there are views fields for:

• Total signups per user including guests.
• Total guests per user.
• Total guests per status per user.
• To filter out guest records, a "Is parent?" or somesuch field can be easily added to the views options. I'll probably do this anyway because it seems pretty useful.

It would be MUCH simpler if the registering member could just select the number of tickets they need, and this would provide all the information the event planner needed.

Agreed. In this implementation, the user only needs to choose the number of guests, and the Name field for guest signups currently defaults to "Guest(s) of [parent signup name]". Perhaps for maximum flexibility, down the road a webform could be attached so side admins can add whatever fields they like, and the data will be serialized into form_data.

To work with signup_status, there is a site-wide defaut status config for guests under the signup_status admin screen. Probably some usecases will need per-content-type or per-node settings, but mine doesn't so I haven't included them.

To solve the other problem, what joachim is talking about, we should avoid making it too complicated. I think there could just be a new permission, something like "allow signing up other people", and anyone with that perm basically gets access to the existing admin UI to signup other people.

Done, but not the admin UI. The node signup form is altered.

And, for both this new perm and the existing admin UI, it'd probably be a good idea to add a new column to {signup_log} like "signup_created_by_uid" (obviously with a better name). But, e.g. record the fact that UID 12 signed up user 38 for nid 2333 in signup ID 235. Then, you could easily do stuff like "show me all the signups for nid 2333 that uid 12 created",

A new field would work. I used a new table to represent parent / child relationships between signup_log records. The primary motivation was need for a working solution before you made that new field part of signup_log, and I didn't think of just altering signup_log in the installation process of signup_guests until now.

But, from a theoretical standpoint, I see benefit in keeping the primary signup architecture separate from add-on features.

[Edit] There's already a "signup_created_by_uid" field... The guest record gets a standard signup entry, with uid same as that of the parent record. To me, this is logical, since the idea is to relate several signup slots to a given user. Screenshots of examples attached to following comments.

The new table also has a count field to store the number of guests separate from count_towards_limit in order to address this problem:

I'm starting to think that count_towards_limit isn't well-shared by signup_status. Changing signup_status so that it either sets counts_towards_limit to zero or leaves it unchanged (as opposed to having it hard-wired to set it to 1) is simple, however, once signup_status sets count_towards_limit to zero, the data for how many signup slots the record has claimed is lost until the form is processed again.

I also snuck the guest count past signup_status to reassign count_towards_limit when necessary (taking signup_status's settings into consideration).

Still missing:

• Proper observation of varioius limits when signing up guests. I think it inherits some limit checking, but still fails in some cases. In this version, guest signups are created directly with signup_save_signup(), so I'm guessing limit-checking needs to happen in a new validation handler for the form.
• Any sort of waitlist feature. Thinking this may be in another module's scope.

Screenshots of database entries corresponding to above sample. I didn't include an example with a status that doesn't modify signup count.

Works pretty well. Comment on the patch that the ability to sign up a friend does not work for existing nodes (fine for new nodes).

Thanks for contributing! Love the views integration!

Having signup entries that represent more than one person will mean the same thing will translate to Views: you'll get items in your view that represent a varying number of people. Just saying :)

Having signup entries that represent more than one person will mean the same thing will translate to Views: you'll get items in your view that represent a varying number of people. Just saying :)

I think my usecase tolerates the patch's architecture, maybe even prefers it -- so the design was biased :-). The intention with the various Views fields was to provide listing options to accommodate other usecases, but no doubt there will be some that it doesn't accommodate.

The code that creates the guest entries is fairly modular, so it would be easy to have a loop that creates individual entries. There could be a configuration option...

It can certainly be modified or improved. I'm hoping for a baseline that others can get behind.

@nagiek:

Comment on the patch that the ability to sign up a friend does not work for existing nodes (fine for new nodes).

Have you tried setting the allowed # of guests for an existing node after enabling signup_guests?

If that makes it work for existing nodes, then there's a question of how to build this in. Currently, there's a table that stores the allowed guests / node as it's set on the node edit form. I think it's better for nodes to inherit the content type settings by default, and this field / table would only be used to override for individual nodes.

Thoughts?

@kentr

That's exactly what I did and it worked fine. I thought that existing nodes would automatically inherit the default (they don't, default to zero instead).

I agree that "inherit default" should be a selection.

subscribing, will test soon.

Has anyone figured out how an Admin can sign people up for an event? I know there is an old issue for this, but I'm wondering if anyone found a work-around? If an Admin can sign people up, it temporarily takes care of the signup for a friend.

Thanks,

#59 much agreed, here, kwgossett. admin signup feature (would/should) handle this in most cases, quite smartly.

#59 much agreed, here, kwgossett. admin signup feature (would/should) handle this in most cases, quite smartly.

Not at all. This is for the (many) cases that Admin signup won't handle, such as for events where you want your attendees to be able to signup their own guests.

is this feature in the signup module dev release already?

Admin signup is a distinct item (event) from users signed up (property). There clearly is call for multiple users/seats/registrants being associated with a single "signup".

@62 admin *can* sign up user(s) in the current stable release akaik. not exactly "friend" signup, but much the same process imho.

Coming late to the party but it might be worth highlighting that for conferences it's often the case that someone who is not coming to the conference does the coordination..

If it's only one person that's coming then it's almost always a secretary making the booking, and they masquerade as the attendee; they usually have full access to the email of the attendee.

But when it's a group booking then the person making the booking doesn't have full access to the mail of all the attendees. So the first thing to highlight is that in this case it's not the coordinator and 3 friends, it's just the 3 friends.

@Joachim. My custom implementation of a booking system had records for each attendee, like you suggest.

In practice it's often the case, even in paid-for events, that when the booking is made the co-ordinator doesn't know the details of the attendees when they make the booking. It's only close to the time of the event when this is resolved.

So as far as the UI goes, it's better to allow coordinators to give the details of attendees at their leisure.

In that custom system I kept the db consistent using empty records, but actually it turned out that then I ended up doing management of those records in code to distinguish between the people the system really knew about and those that were placeholders. I tilt now towards only entering attendee info where you actually have it but I haven't yet done an implementation like this, so I haven't found the pain points.

Subscribing, greetings, Martijn

@kentr: thanks for patch #49. It works great for me except some minor issues.

1. The info file should reflect dependencies like so:

dependencies[] = signup
dependencies[] = signup_status

2. The first line of the info file should be changed to the following. Otherwise the module name doesn't show up on the module list.

;$Id$

3. If there are no signup statuses setup, you get a warning message for the following line in signup_guests_alter_signup_status_admin_settings_form:

array_unshift($element['#options'], t('Same status as parent signup'));

This can be fixed by testing $element like so just after the first line of this function:

$element = _signup_status_status_form_element();

    if (!empty($element)) {
      ...

Any reason why this can't be submitted as a contrib module? I would guess that this feature won't get rolled into signup any time soon as signup has 200+ issues in its queue. Many are more critical than this one.

It would be good to be able to version the code and have an issue queue attached to it.

@larskleiner:

Thanks for the feedback. No reason on my end why it can't be submitted as an independent module. I can't support it much right now because the project for which it was created has been postponed.

Are you interested in being a maintainer?

@kentr:

I can setup the new contrib project and commit your/setvik's code. I'll be working on an event booking project during the next couple of weeks for which I'll be using the signup_guests functionality. Not sure if I'll be able to spend much time once my project is completed but I'm happy to get it started.

Hi Lars,
Just a suggestion to use booking api for your project. It is a Summer of code project, and some extra love would be great I think. I am not involved in it for your information, but saw your post.

greetings, Martijn

@Martijn:

Thanks for your suggestion. We had a look at booking api but we found signup does most of the things we need and seems to see wider use within the community.

Also we are going to integrate our event reservation system with Ubercart so the fact that we'll be able to use uc_signup seems like the way to go.

Thanks for your feedback. Booking api is a summer of code project, don't know what the scope will be when it is finished. great you are going to integrate with Ubercart. Hopefully you can build an install profile from it in time. Greetings, Martijn

@larskleiner: if you want signup/ubercart integration, look at #29568: Flexible number and type of fields.

I would love to see this submitted as a contrib project.

@kentr @larskleiner: I would like to help out to start this as a contrib project as well, just let me know if there's something I could do!

Subscribing

Subscribing

Is there any active work still being developed on this patch?

I'm looking for a way for Parents to sign children up for events.

My thinking is to use the ucreate module(http://drupal.org/project/ucreate) to allow parents to create an account for the children and profile_role (http://drupal.org/project/profile_role) to limit the childrens roles.

This patch may help with the signup part.

please share any ideas or suggestions.

Thank you.
Ian

@jochim and dww
Do you think the direction/design in patch #49 right direction? If you bless the direction and suggest missing pieces , we can try to get those details finished. But if you don't, please suggest which way you would like this to end up.

I am trying to make the patch in #49 work, but not having any luck. The select box appears on the content type setup page with the "Maximum number of guests users are allowed to signup?:" question, but the option does not appear on the node itself.

This code is a year old now and might have issues with the latest builds of drupal and/or one of the signup modules. Can someone who has it working please post the version numbers of the signup and signup status modules, and their drupal version?

Is there any active work still being developed on this patch?

I'm not actively working on it. The project it was for was put on hold.

Where's the link and repo for the most current code? I may want to take this up, since I basically need to make it anyway for our project.

Thanks!

Where's the link and repo for the most current code? I may want to take this up, since I basically need to make it anyway for our project.

Comment #49. No repo.

I would assume that the best place to start would be the cvs repo for this module.
http://drupal.org/node/29351/cvs-instructions/DRUPAL-6--2
Also have a look at:
http://drupal.org/handbook/cvs/quickstart
If you are unfamiliar with drupal.org and cvs.

subscribe

subscribe

I've picked up this project and created a sandbox for it (http://drupal.org/sandbox/mausolos/1102042), with props to kentr and larskleiner (anyone I might have left out in credits, let me know and I'll reference you as well).

This is a mission-critical module for us, so I would have to work on it just for us, anyway. Might as well put it out there for everyone, right? If anyone is interested in taking co- or full maintainership of it, let me know. I don't really need to own it, per se, just to fix some bugs and get it working.

I plan to devise some way of integrating it into the sandbox project http://drupal.org/sandbox/meichr/1077134, or vice-versa, or just getting the two talking together somehow. My end goal is to have a system where a change to a primary status/list can cause parties (registrant + their guests, if any) to get bumped from a secondary list to the primary list automatically.

Hi mausolos!

I am already testing the meichr's sandbox project, i will do the same with your sandbox module :)

I will try my best to help (^_^)

I made a new issue in your sandbox project mausolos :)

Hi Ian,

Did you find a solution for doing this ?

I'm looking for the same kind of feature...

Thx,

Nico

Nico,

After testing several options, subuser (http://drupal.org/project/subuser) looks like the best solution for what I want to do at this point.

Unfortunately I had to put that project on the back burner because of time constraints.

if you like I can show you what I have so far.

Ian

Hey Ian,

I would be interrested in looking at your stuff.

I'm at the moment working on a setup using pageref (for children content types) and "cck signup" module (for event signup)...

Is there any way I can put it on a D7 installation? (or, a similar hack?) thanks