Meta value _tribe_tickets_attendee_user_id incorrectly set

[Andras]

After successfully paying for a woocommerce-based ticket, the attendee (post type tribe_wooticket) will be set an incorrect value of 0 (zero) for the meta value _tribe_tickets_attendee_user_id. This causes the user making the purchase not seeing his/her tickets when clicking on the “View My Tickets” link.

[Cliff]

Hi, Andras.

Sorry you’re experiencing this.

Is the purchaser logged in to a WordPress account at the time of purchase or checking out as a guest?

Please also share your System Information. That will give me a lot of extra information to help diagnose the problem.

[Andras]

The user is logged-in as a normal user at the time of purchase.

We have reported this issue before, including a proposed bug fix. With the code change, the issue seems to be corrected.

We have enabled automatic sharing of our system information as per your request.

[Cliff]

Hi, again, Andras.

Of course, I’m disappointed that this bug is affecting your site so much. I’m hopeful a fix will be coming soon now that we’ve tracked it down a bit.

However, I didn’t find where you previously shared code for a proposed bug fix. Could you link me to that, please?

[Andras]

I posted a solution at 23rd of Februari in this thread: https://theeventscalendar.com/support/forums/topic/custom-field-values-for-attendees-not-saved-to-cart/

But here is a copy of the text, including clarifications on where it is located in the code.

While checking for this, I found another issue in the generate_tickets() function for WooCommerce tickets. When using a payment plugin (DIBS for WooCommerce in this case) to make a payment, the generate_ticket() generates tickets with an incorrect user_id meta value of 0 (the tribe_wooticket post also has a post_author of 0), and as a result, the user cannot see his/her tickets on the order_tickets page (which is based on a user_id filter to get all orders/attendees).

I seems that when some callbacks are received from payment gateways there is no current/logged-in user, hence the value 0. In class Tribe__Tickets_Plus__Commerce__WooCommerce__Main method generate_tickets() function on row 645 the call

$this->record_attendee_user_id($attendee_id)

will get the current logged-in user (=0) and set user_id for each ticket to this value. I changed this call to

$this->record_attendee_user_id($attendee_id, $order->customer_user)

to always connect the attendee/ticket to the order purchaser user. This should be logical and seems to work correctly. The logged-in user can now see all his/her tickets.

[Cliff]

Thank you.

That thread was regarding meta details not saving when multiple types of tickets were purchased at once.

Not having the user able to see their own tickets is a completely different subject (not saying it’s totally unrelated) so maybe that’s how it got missed.

Anyway, at first glance, your suggestion looks good; thank you for sharing it.

Is this issue specific to using the DIBS payment gateway? If not, what other gateways have you experienced this on so I can try to replicate the issue?

[Andras]

We have only tested this för the DIBS payment gateway.

After today’s maintenance release, ET 4.4.5 / ETP 4.4.4, the issue with user_id set to zero still exists.

If you refer to my previous thread, I never stated that it was “multiple types of tickets purchased at once”. I mentioned “a couple of fields” in a ticket. I have previously only tested exactly one ticket type in a single purchase, nothing else, when I encountered the attendee field issues.

[Andras]

And to be clear, I realize these are separate issues, I will keep separate issues in separate threads from now on.

[Cliff]

Andras, thanks for clarifying.

I know it can be a chore, but we would ask for you to create a brand new site running only our plugins, WooCommerce, and DIBS and see if you can replicate it there.

If it does continue happening, maybe try replicating it with a different payment gateway so as to test if it is specific to DIBS.

Thanks for your efforts here.

[Andras]

We have created a completely new instance of our site and copied/reinstalled all plugins, leaving only your plugins active, along with the plugins for woocommerce and DIBS payment gateway. The issue still exists.

We have tested this with the “Pay with check” payment gateway, and the issue does not occurs using that gateway. But the “pay with check” gateway does not leave the site. The DIBS payment gateway visits an external payment window.

[Cliff]

Andras, we surely appreciate your effort here! Thanks for the detailed reply.

If I correctly understood what you wrote previously, it sounded like you knew of other payment gateways that experience this issue as well. Could you please specify which other ones you’re able to reproduce this issue with?

[Andras]

We have only tested this with our current payment gateway, DIBS for WooCommerce.

We updated to the latest release ET/ETC 4.4.6, and this issue still remains.

To help you, we generated a backtrace by catching the event_tickets_woocommerce_ticket_created action called just before the attendee user id meta value is set in Tribe__Tickets_Plus__Commerce__WooCommerce__Main::generate_tickets().

[22-Apr-2017 13:12:15 UTC] 
Action: event_tickets_woocommerce_ticket_created
Args: attendee_id=1650, order_id=1649, product_id=1326, order_attendee_id=0
Current state: current_user_id=0, backtrace=
- /wp-content/themes/lemans1954/functions.php at line 536: ::lemans1954_debug_backtrace
- (unknown file) at line ?: ::lemans1954_event_tickets_woocommerce_ticket_created
- /wp-includes/class-wp-hook.php at line 298: ::call_user_func_array
- /wp-includes/class-wp-hook.php at line 323: WP_Hook::apply_filters
- /wp-includes/plugin.php at line 453: WP_Hook::do_action
- /wp-content/plugins/event-tickets-plus/src/Tribe/Commerce/WooCommerce/Main.php at line 671: ::do_action

- (unknown file) at line ?: Tribe__Tickets_Plus__Commerce__WooCommerce__Main::generate_tickets
- /wp-includes/class-wp-hook.php at line 300: ::call_user_func_array
- /wp-includes/class-wp-hook.php at line 323: WP_Hook::apply_filters
- /wp-includes/plugin.php at line 453: WP_Hook::do_action
- /wp-content/plugins/woocommerce/includes/class-wc-order.php at line 306: ::do_action
- /wp-content/plugins/woocommerce/includes/class-wc-order.php at line 214: WC_Order::status_transition
- /wp-content/plugins/woocommerce/includes/class-wc-order.php at line 120: WC_Order::save

- /wp-content/plugins/dibs-for-woocommerce/includes/gateways/class-dibs-factory.php at line 167: WC_Order::payment_complete
- /wp-content/plugins/dibs-for-woocommerce/includes/class-dibs-extra.php at line 46: WC_Gateway_Dibs_Factory::successful_request
- (unknown file) at line ?: WC_Gateway_Dibs_Extra::check_callback
- /wp-includes/class-wp-hook.php at line 298: ::call_user_func_array
- /wp-includes/class-wp-hook.php at line 323: WP_Hook::apply_filters
- /wp-includes/plugin.php at line 453: WP_Hook::do_action
- /wp-settings.php at line 449: ::do_action
- /wp-config.php at line 95: ::require_once
- /wp-load.php at line 37: ::require_once
- /wp-blog-header.php at line 13: ::require_once
- /index.php at line 17: ::require
- request: /woocommerce/dibscallback/?

At the top, the arguments to the action are shown (with correct values), and the current state shows that the current user id is 0 (returned by get_current_user_id()).

If we follow the backtrace from the bottom of the list, the entrance request is a callback to “dibscallback” created and handled by the payment gateway. A successful payment results in a call to WC_Order::payment_complete inside WooCommerce.

Next block is WooCommerce handling the order saving and status transition from pending to processing. This is eventually picked up by __WooCommerce__Main::generate_tickets() by the action woocommerce_order_status_changed.

The last block is the action event_tickets_woocommerce_ticket_created picked up by our own theme (lemans1954) helper function to generate this backtrace. This action is called just before the function record_attendee_user_id() is used in generate_tickets() and called with one argument. The second argument, user_id, will have default value of null, and therefore uses the get_current_user_id() function to get a user id. But as we have seen before, this call originated from a callback without a logged-in user, and the end result is that the _tribe_tickets_attendee_user_id meta value for the ticket is set to 0.

As a general rule, code that is dependent on global state, like the current logged-in user in this case, is dangerous, and must be sure that any global state value that is accessed is correct in all contexts it is called.

The function generate_ticket() already has needed values available in the current order object, where the customer user id is stored. Retrieve it by $order->get_customer_id() and send it as the user_id argument to the function record_attendee_user_id(). We have made this change and this solves this issue on our site.

[Cliff]

Thank you so much for those details. I’ve passed your report on to our developers.

I’ll mark this ticket as Pending Fix, which means this thread should receive a reply once the applicable fix has been released. I cannot guarantee when it will be fixed as it’s in the development team’s hands now. They need to assign it, code it, test it, and schedule it for release.

I apologize for this issue and appreciate your understanding and patience.

[Nico]

Hey,

Just wanted to share with you that a new maintenance release (for the Week of 26th June 2017) is out, including a fix for this issue ?

Find out more about this release → https://theeventscalendar.com/maintenance-release-week-26th-june-2017/

Please update the plugins and let us know if the fix works for your site,
Best,
Nico

[Andras]

We installed the latest release ET/ETC 4.5.1 from 26th of June, and it fixes this issue. Thank you!

[Author]

Posts