participant name of membership can be None, can't buy ticket

[felixrindt]

Problem and impact

I created a shop with a "non-entry" product granting a subscription to a customer. When buying this subscription product, the user did not provide a participation name. Therefore no participant name was saved to to the subscription.

When trying to use the subscription to buy an entry-product in another shop, a participant name is required, but the fields are disabled (as the subscription is configured to me non-transferable). I cannot proceed with checkout at this point.

Expected behaviour

I expect pretix to force customers to provide a participant name when the subscription is bought (for non-transferable subscriptions). Maybe

• show the participant name question for products granting a non-transferable subscription even when it's not configured otherwise
• force subscription-granting products to be an entry-product? even though that doesn't guarantee the name question being shown right? it can still be disabled
• allow to set a name when using the subscription for the first time if the stored name ist None (if you want to allow the name to be None)

Steps to reproduce

1. create an organizer with a subscription type (non-transferable)
2. create a "shop" where customers can buy the subscription. Default settings, make the product non-entry.
3. buy a subscription through that shop. There should be no participant name question.
4. Create a second event where customers can buy an entry ticket that requires the subscription.
5. Try to buy a ticket to the event with the subscription. See screenshots on the problem there.

Screenshots

The fields are disabled, empty, and required.

The subscriptions stored name is None.

Link

No response

Browser (software, desktop or mobile?) and version

No response

Operating system, dependency versions

No response

Version

b4a73696423566d3793948fec1c78a480136800e

[raphaelm]

I expect pretix to force customers to provide a participant name when the subscription is bought (for non-transferable subscriptions).

It's unfortunately not that simple: If the membership is used for a non-admission product, there would not be a problem. It's therefore possible to have non-transferable memberships on non-admission products in some situations.

Asking the user for the name on first usage would be a solution. The most simple "solution" would be to issue a warning in the backend if the case is likely to occur with a given configuration

[raphaelm]

I included a validation for the most common reasons of this in #2990