Pass context about medium to allow_ticket_download signal

[BenBals]

tl;dr Pass a parameter to allow_ticket_download specifying if the current call is used to render the order page or to send an email.

Use Case

We issue special tickets (in our case tickets for angels) as well as normal tickets. For normal tickets, we want people to be able to instantly download their tickets from the order page as soon as they've paid (particularly if they pay via stripe instead of via bank transfer). For the special tickets however, we only want to send tickets via email or show them on the order page after the email has been verified (i.e., Order.email_known_to_work is set). This is because, in our plugin, we use the email address to verify if a user is eligible to buy the special ticket (in our case we've patched an API route into our Engelsystem that tell us if the user has at least one shift).

Current solution

You will hate this, but here we go: Look at the call stack to see if the signal is called from an order page or from an email task.

def allow_ticket_download_helper(event, order):
    config = get_config(event)
    # Only enforce this setting on customer facing order pages, not for emails
    is_from_order_page = any(map(lambda frame: frame.function == 'get_context_data', inspect.stack()))
    if config.get('engel_ticket:allow_ticket_download_without_email_verification'):
        return True
    if order.email_known_to_work or (not is_from_order_page):
        return True

    return filter(lambda position: not position_is_engel_ticket(event, position), order.positions.all())

Proposed solution

Add a new optional argument to the allow_ticket_download to indicate if the current call is related to an order page or to an email (if there are other sources, of course those as well).

[raphaelm]

Add a new optional argument to the allow_ticket_download to indicate if the current call is related to an order page or to an email (if there are other sources, of course those as well).

Hmm. Yes, it would work and it would be doable, but I don't think it is a really good solution. It opens a number of new failure modes. For example, pretix contains a mechanism that prevents tickets from being attached to an email if they are to large, and there is no way to prevent that. So someone implementing the plugin signal would need to be quite careful to not build a situation where you lock users out from getting their tickets at all. Also, it makes Order.positions_with_tickets a function instead of a property and I'm not sure that additional complexity is worth it.

Wouldn't just generally setting ticket_download_require_validated_email for your event be a sufficient compromise? Plenty of events use it, I think the UX for the "non-special tickets" is still quite okay.

[BenBals]

So someone implementing the plugin signal would need to be quite careful to not build a situation where you lock users out from getting their tickets at all.

Isn't that already the case? If I don't return anything here, users don't get their tickets or am I missing something here?

[BenBals]

Wouldn't just generally setting ticket_download_require_validated_email for your event be a sufficient compromise? Plenty of events use it, I think the UX for the "non-special tickets" is still quite okay.

Unfortunately not, that's why we built this feature in our plugin in the first place. We want users to be able to order things onsite and instantly have access to their tickets. A "skip the line at checkout by ordering your [thing] online!" isn't really that attractive if it means people having to search through their email instead of just getting the ticket at the end of checkout.

[BenBals]

An alternative solution (at least for our use case) would be moving the ticket_download_require_validated_email setting to individual products. (Or allowing an overwrite on a per product basis.)

[raphaelm]

We've discussed this internally and we do not want to make a change here and recommend that you keep your hack. We don't want to make the signal more complex and we don't want to introduce the complexity of moving the download requirement to product level.

[BenBals]

Sure, I get that :)

Feel free to keep the general idea in hand that we have a number of use cases that requires more nuanced trust levels (see also #3980 (reply in thread) which is from the same organisation). We maintain a number of plugins in that direction and are always happy about more core features that makes these semi-internal events better supported.