| Age | Commit message (Collapse) | Author |
|---|
|
In particular, make it possible to show the bulk payment invoice
directly from the registration page, if one exists.
|
|
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.
|
|
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 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
|
|
|
|
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.
|
|
If there are more than two votes, then one copy each of the highest and lowest
scores is removed before averaging.
|
|
|
|
This allows us to return 304 not modified for speaker photos, as they
change very infrequently. Actual etag is maintained as an md5() of the
contents, by a database trigger the same way we do for util/storage
fields.
|
|
Without this, if a provider goes from active -> inactive when there are
existing posts, we'd crash the view of the existing ones.
|
|
|
|
This hasn't been new style for many many years, and there is only one
style supported anyway. (Change only to help text)
|
|
This makes possible to optionally restrict how many submissions someone
can make to a conference call for papers.
Fixes #70
|
|
This includes both direct attendee emails, and also those that are for
example sent to speakers of a session. This also removes the support for
sending such emails *without* storing them as attendee emails, as that
wouldn't leave us with a way to track what's been sent and what hasn't.
Fixes #90
|
|
|
|
This is deprecated in newer Django, and will be removed in 5.0. We're
using only very little of the library functionality directly, and the
rest of it's already i django, and since Django 4.2 switched the primary
library, we switch as well for it.
|
|
This allows downloading a json/yaml file with all the claimed benefits
(including information on if they are confirmed or not).
This also adds a tool called fetch_sponsorfiles.py that will parse this
data and be able to download related files, such as "Logo for the
website" benefits.
The details being provided probably need some more going over with some
reasl world experience, so for now this should be considered
experimental.
|
|
In passing, this adds support for YaML format downloads of all token
based data.
The token data will generate json or yaml with information about all
sponsorship levels and benefits created in the system. The idea being
this can be pulled into a context file and thereby guaranteed to be the
same in the static and dynamic parts of the site. We'know from
experience these can easily get slightly out of sync.
|
|
We don't want two regtypes with the same name at a single conference,
that's just.. wrong. So enforce it with a constraint.
|
|
With the increased importance of hashtags in the Mastodon world, make
the support more efficient and useful. This adds the ability to flag a
hashtag as "auto add", in which case it will be automatically added at
the end of all posts giong out to twitter/mastodon as a result of news
posts (this was not possible at all before). Additionally, it will also
get pre-filled in on manual posts made both using the backend interface
and the mobile webapp.
To control the order of appearance of the hashtags, a sortkey field has
been added to the table as well. Existing hashtags will just be sorted
alphabetically.
|
|
|
|
When this is enabled (default is off), any session listed as Pending
will be include din the schedule, but have it's title replaced with TBD
and have the speaker information removed. This can be used to help "pad"
schedules in the early stages.
|
|
This term is used in the docs and were used for most of the transitions,
but not all. This is specifically the state where the speaker initiates
something, so it should be consistently clear.
|
|
Sometimes a speaker withdraws before the cfp voting is finished, and if
this happens it's incorrect to set it to Not accepted. Thus, allow this
new state transition.
|
|
The object __str__() is not used very often on sessions, but if it is,
including the time as None wasn't very pretty.
|
|
|
|
For recorded sessions, this lets us store things like youtube video ids,
later to be used on the schedule.
To store this, a jsonb object is added to each session. The list of
available providers can be configured on the conference, and a field to
enter the link data appears automatically. No validation of the data is
supported, so care has to be taken when adding. More logic around this
can be added later.
In passing, update the backend form for sessions to use field sets to
look nicer, and thereby re-ordering a few fields to match.
|
|
We need a unique constraint on (conference, session, attendee), so each
attendee can't end up with more than one entry. This can't be done in
the UI, but with a quick reload or a network blip could happen.
We also need to wrap the view in a transaction to avoid it happening in
the future (but there are still cases where it can happen, so we want both this
and the index)
|
|
We don't use the __str__() call very often on volunteer slots, but we do
when generating notifications from API operations...
|
|
The idea behind this is to add secondary "stations" at a conference
checkin which can off-load the main check-in. Typical example can be a
desk for handing out t-shirts separate from the registration.
Each checkin-field is tied to one of the dynamic reporting fields
implemented earlier, and once the "store" button is clicke on the
checkin dialog, the date of it being done is stored in the field.
Unlike regular check-in, this the check-in field scanning is done off
the *badge* not the ticket. This makes it more like the sponsor badge
scanning, and therefor we have to add a new landing page that can handle
the case when the same person is both a sponsor scanner and a check-in
scanner. It will then just prompt the user for which one.
This merges the two separate but extremely similar web scanner apps used
for checkin and badge scaninng into one, that is driven by parameters.
There's enough complexity there that we don't want two independent
ones...
In passing, support for old-style tokens (prior to 074e324b, almost a
year ago) is removed to simplify the code. That means that tickets or
badges issued before 074e324b was deployed can no longer be scanned, but
given how long ago it is this should not happen.
Per original idea from Vik Fearing with input from several more people
over time.
|
|
|
|
This compares the strings to each individual provider and warns, so the
user can edit the post if necessary to truncate it manually.
In passing this also fixes the cache handling in the tweet queue which
was completely broken and thus didn't actually prevent the extra queries
at all.
|
|
Instead of requiring registration transfer invoicing to be full manual,
create a new object that represents a pending transfer. So instead of
transfering, the admin will create a pending transfer and have it
auto-generate an invoice. That's left as pending until the invoice is
paid, at which point the transfer is automatically completed.
|
|
|
|
This allows an attendee to mark which session are their favorites in a
way to "build a personal schedule". UI idea is the standard "stark-mark
some sessions". No actual UI is included at this point though, it's juat
an API endpoint that's to be used from the frontend websites. Given
nobody (hopefully) uses the old-style scheule that's in the core repo
there's not much point to build an implementation there, so we'll build
it elsewhere and then eventually backport it into the system once we
have a complete example.
This prodvides the foundation for collecting the information and for
viewing it in the backend (there's a report for top session and the
session count shows up in the schedule builder).
Starts work on #89, but it's far from complete as it's still pending
custom ical, generating notifications etc.
|
|
As 4ab83bb5 noted, on permanent error (such as when twitter has blocked
your account...), we got stuck in an endless loop in the daemon. Even
worse, after a second retry the cronjob would get killed on the 120
second timeout, and the cycle start over...
Instead, implement an error counter and an exponentially longer backoff
for retries until 10 retries have been made after wihch we give up.
|
|
This allows the core of the system to differentiate and post the same
post with different content to different social networks, for example a
different content to Twitter and Mastodon. This is primarily intended
for things like campaigns where speaker social media handles are
highlighted - the handles are different on different networks, and you
don't want to post a mastodon handle on twitter and vice versa.
The campaign system (which currently only has one type of campaign,
which is the confirmed sessions campaign) is extended to handle this and
be able to highlight the correct handle, using a new jinja filter
introduced.
Speaker profiles are extended to not only collect twitter names, but
instead collect all social networks that are supported on the instance.
The implementation supports the generic idea of "messaging provider"
that we've had for a while, and is thus already ready for if support is
added for more providers in the future. All the old hard-codings to
twitter are removed from speakers and from the core system, but remains
on registrations (where we just collect the twitter name and don't do
anything with it) and sponsors (room for improvement here).
NOTE! This changes the format of the news.json output when social media
posts are included. I've not been able to find anybody actually using
this functionality yet, so I just went with breaking the old format so
as not to have to drag legacy around forever.
|
|
|
|
It's a json field and blank then means {}. Commit 6249ecb1 misthought
this, and made it impossible to edit a registration in the django admin
mode which includes this field. Since that's the "emergency way out", it
should be allowed, so allow the field to be blank.
|
|
It's easier to decide if you want to allow a sponsor to scan your badge
when you know exactly which data they will get access to.
|
|
|
|
|
|
Including the event date on the invoice is required in some
jurisdictions and it's easiest to just do it in the title.
In passing, adjust it so the title of single registration invoices
created directly and single registration invoices created through
the "register for somebody else" are now the same. This removes
the email address from the invoice title of a register-yourself
attendee. But since it's still included in an invoice row, it should
not matter (I believe having it in the title in the first place dates
back to when we didn't have invoice rows).
|
|
We need to prefetch the VAT rate information so we don't end up querying
it in a loop.
|
|
|
|
This allows each conference to define zero or more dynamic properties
for attendees, each which can hold a string value. These properties can
be used to filter reports, same as any other string value. Storage in
the system is backed by a jsonb field.
This can be used to for example track which registrations have had their
badges printed, by declaring a field that holds a "badge batch" and then
filter based on that.
|
|
This optional feature requires all attendees to confirm that they will
follow the conference policy (as specified in the skin) before they are
issued a ticket.
Fixes #102 (indirectly, the actual text needs to be defined by the conference)
|
|
The currency format patch accidentally set the price for regtypes to
have the currency format applied twice, which of course didn't work.
|
|
|
