Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to hide unpurchasable tickets #644

Open
icewindow opened this issue Nov 15, 2023 · 1 comment
Open

Option to hide unpurchasable tickets #644

icewindow opened this issue Nov 15, 2023 · 1 comment

Comments

@icewindow
Copy link

Issue description

An option to hide tickets with a purchase time frame, which has not yet been reached or has already passed.

Motivation

In setups with lots of purchasable tickets it can get rather confusing with all tickets being presented at the same time, even when some of the tickets can not be purchased yet or anymore.

Possible implementation

There should be a flag "Hide non-purchasable tickets", which when activated hides all tickets with purchase periods in the past or future. The decision needs to be made then where to save the flag.

One option is to have the ticket save the flag. This would control each ticket individually.

Another option is to have the flag be located in the event itself, with all tickets obeying the flag from the event.

A third option would be to combine both: The ticket has three options:

  • "Always show", works as before
  • "Hide if not purchasable", hides each ticket individually if needed
  • "Let event decide", hides all tickest based on the event's settings if needed

The event then has the same flag as above.

Considerations

Option 1 and 2 are about the same difficulty to implement.
However, option 1 is probably more flexible. Each ticket can be hidden if needed or always been shown. Setting multiple tickets up could be somewhat cumbersome though if the setting differs from the default.
Option 2 will be the easiest settings-wise, but will not allow great flexibility.

The most convenient for bulk changes is probably the third option, however setting the tickest up with an option that differs from the default can be again cumbersome.

Ultimately, option 1 seems to be the best in most scenarios

@Apfelwurm
Copy link
Member

I will think about it and comment on it in the next few days :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants