CiviCRM Community Forums (archive)

Dave,

Thanks again for your hard work - this is very nice!

It could be nicer ...

• The words "(including yourself)" and "your registration information" don't apply in the context where a person is registering on behalf of someone else. I've tried to think of alternate wording but the options are more complex and would probably be more confusing. Unless a word-smith can do better i suggest we stick with this wording (people can always edit their template!)
• When I went to the sandbox the event had been reset to not allow multiple rego. You may consider changing the sandbox refresh script to make this permanent (it's a nice feature which would be good to showcase)

Having said that, this is a significant improvement,

Ken

Aha!  I just discovered this thread and the issue filed for 3.1.  I have also played around with the new feature in the sandbox.

I would be tremendously interested in taking this one step further.  If the event is set up to allow multiple registrations with the same email, it would be great if all the registrations could be created all at once.  The total price would be the number of participants in the drop-down times the selection in the price set.  And the user would not have to worry about entering names or emails in additional pages for the additional participants.

I imagine a checkbox on the Online Registration tab for "Allow multiple registrations all at once?" below and inset from the "Allow multiple registrations from the same email address?"

The point to this would be the use-case of selling tickets to events where the social norm is that you do not need to give the names or email addresses of your guests.  Like every theatre and movie box office you know.

I have been in discussion with the folks from webaccess to do some customization that would give us similar functionality, but the changes going into 3.1 seem to take us halfway there already.  We would interested in sponsoring a change like this for future versions of civiEvents.

Beyond mentioning it to the guy I've been talking to at webaccess, what does one *do* to sponsor a change?

Anyone else out there interested in this?

Two issues with option 1:

1. We need not only number of tickets, but at different price points.

2. Counting available seats and avoiding selling beyond capacity.  Because participant records are already used to count against maximum participants, we have been pursuing the second option ("N participant records tied to a single contact record").  

This also results in a participant list that has Jane Doe listed N times -- which isn't the most efficient use of paper perhaps, but is easy to find/understand at the door.  "Here are your N tickets Ms Doe."

That would be awesome - and solve two issues in one swipe (my box office issue and the individual/table issue you mention).

In the price set solution, I would also need a new kind of price field.  Although it would work to have:

[    ] Number of Tickets ($12.50 each)
[    ] Number of Tickets ($25.00 each)
...etc.

This is not ideal for us.  If someone buys 4 tickets, 99.5% of the time, they'll want to sit together and have one price.  So I would also need:

[    ] Number of Tickets               

Choose Price: 
O $12.50 each
O $25.00 each
...etc.

This is similar to what I was discussing with webaccess before I learned of the improvements in 3.1 -- with the exception that 'counting' the price set resulted in multiple participant records (to solve the maximum participant issue.)

I need some kind of solution to this in the next two months, and I would love for whatever it is to have the support of the community and eventually join the official releases.

I am completely new to civi and open-source in general.  Please let me know what I can/should do to help this along.
               

Thank you for your helpful response.  There are a couple of things I want to say up front.

First, I believe that our use-case involves several aspects that would be generally useful to a number of civi users and may also include some aspects that are peculiar to us.  I am willing to concede that a new price field may fall into the second category, but I would not want that to interfere with incorporating the more useful bits into the core system.

Secondly, as someone who knows nothing about the coding involved, it seems to me that price fields are a pretty modular part of the big picture.  A new price field would be useful to some (perhaps small) number of users, and easily ignored by everyone else.

All that said, here's the thinking behind a new type of price field.

ANY price field that works as I've suggested:

[  ] Number of tickets
Choose an option:
O - option 1
O - option 2
...

CAN be generalized using an existing price field:

[  ] Number of tickets option 1
[  ] Number of tickets option 2
...

The difference is not any new functionality, but just a simplicity for the buyer based on likelihood of someone buying tickets at different prices.

Our immediate interest in this is something that is very specific to us.  We have recently instituted a "Pay What You Can" ticket policy for all regular performances.  So we imagine a price set that looks like this:

[  ] Number of tickets
Choose option:
O - I want to help out by buying a ticket for someone less fortunate - $50 per ticket
O - I know what it really costs to produce live theatre - $35 per ticket
O - I don't like pay-what-you-can. Just tell me what the ticket costs - $25 per ticket
O - I’m not sure what I’m getting into but I love a great bargain - $15 per ticket
O - Things are tight for me now but I don’t want to miss out - $10 per ticket
(Or you can set your own price at the door.  If you are really hurting, and we have seats available, you can even see the show for nothing – just get us back the next time and remember who helped you out when you were down.)

But it is not hard at all to imagine other use-cases where this would be useful:

[  ] Number of tickets
Choose an option:
O - priority seating (like airline priority boarding)
O - standard seating

Is anyone ever going to see a show with 3 friends, but leave 2 of them to stand in the longer line?

Or:

[  ] Number of tickets
Choose an option:
O - show only
O - show and champagne reception

It would be important to TRACK the number for the reception, but the hard limit (max participants) would be for the show itself.  It would be possible to do this by adding a separate 'reception' option with a participant count of 0:

[  ] Tickets to show
[  ] Tickets to champagne reception

But again, would anyone leave some of their guests out of the reception?  And how would you prevent buying tickets to the reception only?


We do NOT need to track capacity at the section level.  (In a long-term plan whereby civi eventually becomes something like a traditional box office solution, this would be a logical next step - followed by season tickets, date swapping, and finally assigned seating).

Thanks again.  I hope this wasn't too long-winded.

Ok, that makes sense.  I recognized that this suggestion might be far less useful to the community at large than the more basic change to counting participants.

Dave's proposal works within the current implementation, where a Price Set is just that, a set of price fields. Fields require users to either make a choice or specify a count.
...
The new type "nests" a set of Choice fields within a count field. The database would need to manage these links between price set options. The price set becomes harder to set up and test.

This is the piece I did not understand before.  Thank you for explaining it.

I still wonder if there might not be a way (with a custom patch of some sort) to just make this:

[2] Number of tickets
O - price 1
• - price 2
O - price 3

be an alternate UI that populates a currently implemented price set like this:

[  ] price 1
[2] price 2
[  ] price 3

But I suppose that's a thought for another thread.

Kudos - great addition!