|
Emoni
|
January 31, 2014 at 4:44 am
Hi
My client always has to manually add a certain number of attendees to every event for whatever reason (people sending in cheques etc). Going through a payment or invoice gateway automatically provides the purchased ticket type under the option field in the attendee overview but manually added members simply say ‘admin’.
They need to export this data to their CRM system and want the ticket purchased type to show – I’ve looked at the edit attendee and it shows the correct ticket type but I can’t see why that isn’t transferred.
Thanks
|
|
Emoni
|
January 31, 2014 at 5:01 am
I shouldn’t keep answering my own questions but I’ve found that if I change from Default Pricing to Member Pricing and select the ticket type that is then saved.
This is a bit of a bug because the default pricing might have ticket types that aren’t identical to member pricing.
|
|
Tony
|
January 31, 2014 at 5:27 am
Hi Nicholas,
If you edit the attendee and just click ‘Update Record’, that should update the ticket to the one currently selected, you shouldn’t need to change the Pricing Option.
I’ve opened a ticket to discuss this with a note to update this thread with the outcome.
|
|
Emoni
|
January 31, 2014 at 5:35 am
Ok, so simply clicking on ‘update record’ does work – I think it just looks as though that is already selected. I will advise the client of the procedure, thanks a lot.
|
|
Emoni
|
January 31, 2014 at 6:03 am
As I suspected, the client is whining that this is now a two-stage process and why can’t this be on one page when adding the attendee. Any ideas?
|
|
Tony
|
January 31, 2014 at 6:08 am
I noticed an issue whilst testing this with Multi Attendee Registrations that I think is worth noting for yourself.
If an Admin adds multiple attendees to a registration (an event with at least Personal Information Required for additional attendees). The price input for the Paid amount on the registration then applies to all of those attendees. When the ticket is Admin, it shouldn’t effect anything, but if you do the above and then Update the price on the registration, the price will be calculated incorrectly for that registration.
This does NOT apply if this is a single registration with multiple ticket quantity. (events that do NOT require additional attendee info)
We have a ticket for this to be looked into further by a developer.
|
|
Tony
|
January 31, 2014 at 6:28 am
As I suspected, the client is whining that this is now a two-stage process and why can’t this be on one page when adding the attendee. Any ideas?
Currently not unfortunately.
I’ll investigate and see what we can do.
|
|
Emoni
|
January 31, 2014 at 6:42 am
What they want is to see the ticket types at the ‘add attendee’ stage. It does make sense but whether it’s possible, thanks for looking into it
|
|
Sidney Harrell
|
February 4, 2014 at 11:57 am
You might be able to take advantage of the post-save-attendee hook to modify the saved attendee if it was created by the admin to a default ticket type. Take a look at what I did here: https://gist.github.com/sidharrell/7163075, but instead of checking for is_primary, you would check for ‘payment’ == ‘Admin’, and if true change the price_option to some default value.
|
|
Sidney Harrell
|
February 4, 2014 at 12:58 pm
I took a little deeper look at how the attendee is added by the admin, and was able to take advantage of a quirk in the code. The following is a guide to adding what you are looking for. Take note of the comments, as they are instructions for where to add the bits of code:
|
|
Emoni
|
February 6, 2014 at 8:05 am
thanks, would it work to drop the code into a new custom_functions.php file that I add to the EE folder? I’m pretty good on the old CSS but don’t get involved in coding (just yet). Thanks
|
|
Tony
|
February 6, 2014 at 8:57 am
Hi Nicholas,
That’s the best place for that function 🙂
The actual function starts at line 21 to the end of that gist, place that in the custom_functions.php file.
You could actually add all of it as the first few lines are comments describing how to add the check the overrides the original function to core but either way you need to perform the first steps outlined or you will receive a fatal error stating you can not re-declare a function.
Hope that helps.
|
|
Tony
|
February 6, 2014 at 9:00 am
Think I maye have misread your question.
Create a file called custom_functions.php in wp-content/uploads/espresso/ and add the function there, if you already have that file just add the function to the end.
|
|
Emoni
|
February 6, 2014 at 4:08 pm
so there is nothing else I need to do besides add the function code to the file or are any additional modifications required?
|
|
Sidney Harrell
|
February 6, 2014 at 9:24 pm
I put in the comments at the top the only modifications that you need to make to core. You’ll need to add:
if (!function_exists('add_new_attendee')) {
to the top of plugins/event-espresso/includes/admin-reports/add_new_attendees.php
and a closing brace:
}
to the end of it. Then the rest of that code, which is the customized version of that function, can be added to uploads/espresso/custom_functions.php.
|
|
Emoni
|
February 7, 2014 at 5:55 am
Am I right in thinking that I’ll have to add that line of code to the core after every update?
|
|
Tony
|
February 7, 2014 at 7:49 am
Hi Nicholas,
For the time being yes, however we have created a ticket to include this within future versions of Event Espresso.
|
|
Emoni
|
February 16, 2014 at 12:48 pm
Thanks, I managed to get this to work and the ticket types now appear in a drop down whilst in the ‘add attendee’ area
|
|
Dean
|
February 17, 2014 at 4:24 am
Hi Nicholas,
Can this thread be marked as resolved?
|
|
Emoni
|
February 17, 2014 at 4:26 am
Hi Dean, yes you can mark resolved, it’s working ok
|
