| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Since we *know* if the user has submitted more than one session, we can
easily adapt the notification emails to exclude the part about "if you
have made multiple submissions" if they haven't.
|
|
In particular, make it possible to show the bulk payment invoice
directly from the registration page, if one exists.
|
|
|
|
Fixes #183
|
|
In the list of open sponsorships we stopped listing sponsors once the
conference was started. But if one had saved away the URL for the signup
form it still worked. Make those two be in sync.
For registrations there were some places that would still list it and
others wouldn't, but the form would still work. So make the same fix
here, except trigger it on the *end* date of the conference so walk-up
registrations still work.
|
|
These sessions aren't listed in the session list or schedule, but if
they are linked to externally we would allow them and then crash later
when checking the starttime. So instead of crashing, just disallow the
feedback form on sessions that shouldn't have it.
|
|
In particular, when publishing a schedule we'd use the server default
timezone when showing the difference (reported in #180) and also when adding
new sessions.
Fixes #180
|
|
|
|
This is the number of registrations that would be completed if *all*
entries on the waitlist are offered and accepted. This can be helpful
when projecting venue size increasing.
|
|
When we send "you haven't paid yet" reminders, log it to the
registration page so we can see when someone was last reminded.
|
|
We normally don't have session on the schedule with no room, but if we
do the XML schedule still shouldn't crash. (regular schedule and ical
were fine..)
|
|
Noted by Melanie Plageman
|
|
Somehow it ended up with half the listing in dynamic and half in static,
which sometimes crashes.
|
|
Since we have the list of actual user accounts used for talkvoters, we
can trivially create a special registration type that lets those people
register automatically, without having to deal with vouchers etc.
|
|
This is an optional field that can be turned on/off on a per-conference
basis. It is collected primarily so that it can be displayed on badges,
but it's of couse up to each conference exactly what they do with it.
Pronouns are aggregated and purged as part of the "purge personal data"
step.
Per request from the PostgreSQL Europe Diversity Committee
|
|
The VAT refund fields on anything should be driven off whether there's
actual VAT on the invoice, not off the EU_VAT setting. In particular,
when using taxes and not being in the EU, EU_VAT should be turned off,
but we must still be able to refund the VAT...
Diagnosed by Steve Singer
|
|
Commit a2d79c1e missed that there is a separate codepath that updates
the average values during voting (for just the specific session that's
being voted on), so the value listed could become wrong until the page
was reloaded (the stored value was always correct and a page reload
would refresh all numbers).
|
|
Commit eaea411f forgot to update the old migration.
|
|
ABy requiring a voucher to use a specific registration type, it can
become an "invite only" regtype. The cost set for it doesn't matter, it
can still be zero, but the attendee needs to be in posession of a
voucher to complete the registration. Not as convenient as using the
auto-approving ones like speaker or staff, but a lot more flexible.
|
|
|
|
This has been deprecated for a while and even before that (since 2.5) it
was just an alias, so switching our import should make no difference
other than working on jinja2 3.1.
|
|
Apparently this was only properly tested with 3.0 :/
|
|
|
|
The refund patterns are defined as between days,so when copying from
another conference we should do so by number of days and not by a
timedelta including hours.
|
|
Fist, turn the output into a proper list which makes it a lot easier to
read than a long text. Second, explicitly show the timezones on both the
souce and target timestamp, so that the timestamps are actually useful
at all when the conferences are in different timezones.
Fixes #135
|
|
When there is a limit to the number of submissions a speaker can make to
a conference, don't include withdrawn sessions in the calculation.
|
|
Commit f128188bd back in 2018 made it impossible to change the cost of a
registration type if it had been used. This apparently also broke
creation of new registration types that had a cost from the first save,
which apparently hasn't really been used since. (It would not break
copy-from-other-conference, so maybe that's what people used)
|
|
If a provider that already had something posted using it was removed,
the backend view would crash when trying to show it. Instead, just don't
show the results posted on that provider.
|
|
We'd list that we would use telegram for private broadcast even if ther
ewas no channel configured to broadcast to, as long as the checkbox was
enabled. Update it so we need both before we tell the user it's going to
work.
|
|
This must be an old copy/paste, because we want to list all regclasses
not just the cases where there's more than one.
|
|
Commit afe20375 was supposed to remove individual-attendee emails, but
instead removed regclasses-emails.
|
|
The list of "all attendeemails" can get very long if we included
individual ones sometimes sent. So don't do that. Only include them if
they are sent to a group, or if there is >1 individual on it.
|
|
Jinja2 v3.0 renamed contextfilter to pass_context. Put some code in that
handles both the v3 and v2 name at the same time, as a first step
towards supporting jinja2 v3.
|
|
The qrencode library we've been using is basically dead (and has been
for a while), so add support for the newer pure-python qrcode library.
We keep support for the qrencode one around, so we don't break things
on existing installs, but consider it deprecated and should eventually
be removed.
Fixes #123
|
|
|
|
|
|
|
|
|
|
This could happen when an admin goes through the backend interface to
reach the volunteer schedule, which would create entries that otherwise
are incomplete.
|
|
Do this only for POSTs, but without that if the user clicks the confirm
button twice in a row Really Fast, there's a race condition whereby two
invoices can be created for the same registration, which is not
supported elsewhere in the system.
This probably likely exists in other places as well, but it becomes a
lot more apparent when it comes to creating invoices as the generation
of the PDFs take some time.
|
|
|
|
And default it to the autocancel for the conference, but allow the admin
creating the invoice to override if needed.
|
|
|
|
If there are more than two votes, then one copy each of the highest and lowest
scores is removed before averaging.
|
|
|
|
|
|
|
|
|
