fix(nostr): always publish tickets_available, zero is not unlimited
Some checks failed
lint.yml / fix(nostr): always publish tickets_available, zero is not unlimited (pull_request) Failing after 0s
Some checks failed
lint.yml / fix(nostr): always publish tickets_available, zero is not unlimited (pull_request) Failing after 0s
Omitting the tag used to mean "unlimited capacity". Nothing else in the codebase agreed: `api_get_event` and `api_ticket_create` both treat `amount_tickets < 1` as sold out. So a zero-capacity event advertised "Unlimited tickets" on the card while the detail page and the purchase both returned 410. Observed on aio-demo — three approved, listed, free events in that state. For `PKBVuusKikfJFU4PYGtBTW`: relay tickets_available absent -> webapp renders "Unlimited" GET event 410 "Event is sold out." POST ticket 410 "Event is sold out." The admin form was advertising it too (`min="0"`, `hint="0 = unlimited"`), so organizers were being invited into the broken state. Now the tag is always emitted and zero reads as sold out, which is what every other part of the system already believed. Clients that must handle an absent tag — a NIP-52 event from another publisher — are unaffected, since we simply never omit it. Scoped to removing the contradiction. Making capacity a *required* field is the other half of #34 and is blocked on the webapp: its create dialog uses a falsy check (`if (formValues.amount_tickets)`), so a 0 omits the field entirely and a server-side `ge=1` would 422 it. Refs #34
This commit is contained in:
parent
68a11bb50e
commit
adfd4529f5
3 changed files with 67 additions and 8 deletions
|
|
@ -614,9 +614,9 @@
|
|||
dense
|
||||
v-model.number="formDialog.data.amount_tickets"
|
||||
type="number"
|
||||
min="0"
|
||||
min="1"
|
||||
label="Amount of tickets"
|
||||
hint="0 = unlimited"
|
||||
hint="Total tickets on sale"
|
||||
></q-input>
|
||||
</div>
|
||||
<div class="col">
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue