| Age | Commit message (Collapse) | Author |
|---|
|
Most of the system won't be using this, but it's still good to have for
completeness sake.
|
|
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.
|
|
|
|
The initial code for policy assumed this scenario could never happen and
threw an exception. However, it can happen - when an admin chooses to
send a new welcome email before the policy has been accepted. This is
done for example when a registration was done with an invalid email
address (which can't be done directly, but it can be done when
registereding for somebody else, this being the loophole missed in the
initial commit) that was later fixed.
Instead, just send the policy email, because once the policy is accepted
that will trigger the welcome email automatically.
|
|
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)
|
|
|
|
|
|
It's just the cleaner place to have it...
|
|
This adds the support for registering more than dejavu fonts to the
system, and tries to do so in a backwards compatible fashion. That means
the old FONTROOT setting remains but now instead means the root for the
DejaVu fonts only. Further fonts can be added in local_settings.py
specifying botht he name of the font and the full path to the ttf file.
|
|
Add a field to the registration log that will contain the previous and
new values of any field that is changed, to get a full audit log of what
is being changed, to make it easier to properly debug registration
issues.
Fixes #43
|
|
When a registration is canceled, rmeove it from any signups it has
responded to (and log that). It is not possible to add a canceled
registraiton, and it's not included in the list of registrations
awaiting signup, but it would still be included in the summary of
numbers and responses, which makes no sense.
Fixes #75
|
|
This could already be done but only by changing the jinjadirectory
parameter to be empty. Instead, add a boolean to the conference saying
if templates should be on or off, which can then safely be configured by
a non-superuser (whereas the jinjadir parameter of course has to remain
restricted to superusers only for security reasons)
|
|
The preview of VAT totals for conference registrations (and related
things like additional options) used a slightly different order of
calculation vs the invoice system, which could lead to differences in
the last decimal between the preview and the actual invoice.
Fix taht by centralizing the multiple different places that sued a
different method into one function, and change that function to work the
same way as the invoice system.
|
|
|
|
This allows an external site to integrate with the conference
registration system. All things around registration and possible
payments can be done on the regular site. An URL is then exposed where a
lgoged in user can get a token which in turn can be used by an external
app to request a signed JWT with information about the registration.
|
|
|
|
* Remove the hard-coded twitter implementation and replace it with an
infrastructure for pluggable implementations.
* Separate out "social media broadcasting" (public twitter posts) from
"private notifications" (DMs) and invent "private broadcasting"
(notifications sent only to attendees of a conference) and
"organisation notifications" (sent to organisers).
* Add the concept of a Messaging Provider that's configured on a
Conference Series, which maps to a twitter account (or similar in
other providers). Replace "incoming twitter active" flag on a
conference with a setting on this messaging provider for "route
messages to conference". This way the messaging doesn't have to be
reconfigured for each new conference in a series, and we also
automatically avoid the risk of having two conferences getting the
same input.
* For each conference in a series, the individual Messaging Providers
can be enabled or disabled for the different functionality, and
individual channels be configured when applicable.
* Add implementations of Twitter (updated, social broadcasting and
private messaging support), Mastodon (social broadcasting and private
messaging) and Telegram (attendee boadcasts, private notifications,
and organisation broadcasts)
* Add webhook support for Twitter and Telegram, making for much faster
reactions to incoming messages.
* Hardcoded news twitter post accounts, and replaced with
MessagingProviders per above that are not attached to a conference.
* Add a daemon that listens to PostgreSQL notifications and sends out
broadcasts and notifications for quicker action (if not enabled, a
scheduled task will send them out every 10 minutes like before)
* In making broadcast posts, add support for the fact that different
providers have different max length of posts (e.g. Twitter currently has
280 and Mastodon 500), and also roughly account for the effects of
URL shorterners on posts.
* Add a button to registration dashboards to send DMs to attendees that
have configured notification.
* Send "private broadcasts" ahead of any talks to keep people posted of
talks. For now this is always enabled if a channel is set up for
private broadcasts, we may want to consider making it more
configurable in the future.
There are still a lot of tables and files referring Twitter in the tree,
and some of those will be renamed in a future commit to make tracking of
changes easier.
Fixes #29
Fixes #13
|
|
Break it out into separate functions, one for rendering a template and
one for sending from a string.
|
|
Switch the system to properly use django and postgres timezone support,
by allowing each conference to render all date related information in a
conference specific timezone (using the one that has already been
specified on the conference, per a previous commit).
All non-conference parts of the system keep using the default timezone
as specified in settings.TIME_ZONE.
This includes a migration that updates the existing sessions, session
slots and volunteer slots based on what timezone has been configured
for the conference (since previously everything was stored in the
wrong timezone if the conference was in anything but the default
one).
In order to make this work for non-django-orm queries, a context
manager that swaps the timezone to the conference and back out is
introduced, and related to that a way to get a cursor that turns off
django's protection against doing exactly this.
This finally removes the very ugly "timediff" column on the conference
which was a quick hack back in the days to support ical feeds using utc.
In passing, this also:
* Fixes ical feeds to include all required fields (uid and dtstamp
were missing on schedule entries)
* Fixes xml feed to use conference local time (fixes #8)
* Clarify what "valid until" and "active until" means in the help text
on discount codes and registration tpes.
* Don't duplicate dates in schedule xml feeds (seems others don't, and
there is no clear spec anywhere that I can find)
|
|
This will work differently for conferences and non-conferences once we
add proper timezone support, so abstract it out into a separate couple
of functions. For now they both return the same thing, but this will
change in a later commit.
In passing, fix missing datetime.now() -> timezone.now() conversions.
|
|
If a registration was never confirmed, the attendee may not know they
were ever added (because someone may have just done it in error), and
would thus just get confused by the message, so don't send it.
If the attendee added themselves, then keep sending the notifications of
course, and likewise if they were ever confirmed.
|
|
Tracking of canceled registration broke the deletion of registrations
that were *not* paid, because it tried to flag it as canceled even
though not paid. As we don't care about the history of registrations
that have never been paid, just delete the record completely when this
happens instead (same as it worked before we started tracking
cancellations).
|
|
This adds a basic log to each registration of activity that happens on
it, from creation until possible canceling.
More details can be added as we go, but tihs is a good start.
One big improvement needed is to track exactly *which* fields changed
and to/from what when making changes to a registration (that would help
with support cases).
|
|
Instead of deleting a registration when it's canceled, track when it was
canceled in a new field, canceledat. This makes it possible to keep
track of who the speakers are and potentially email them in the future.
There are two main things that need to get done that are not included in
this commit:
1. Reports need to be adjused. Some are, but all need to be summarized.
In particular, time reports need to be properly taught about it and
probably given the option to actually graph it.
2. Cross-conference email need to be given the option to include or not
include canceled registrations.
|
|
get_conference_or_404(urlname) basically does a get_object_or_404() on the
Conference object with the specified urlname, and for now that's all it
does. But this will later be used to control the per-conference timezone
settings.
|
|
As a step on the way to better timezone support, use the django function
timezone.now() instead of datetime.now(). As long as we haven't enabled
timezones globally this becomes a no-op and does exactly what it did
before, but once timezones are enabled it will generate datetimes that
are aware of this.
No functionality change but gets a lot of boiler-plate out of the way
making the verification of the rest of the timezone work easier.
|
|
|
|
|
|
This only failed if a conference had no skinning at all.
|
|
Instead of doing the [Conference] prefix at every sending point (and
getting it inconsistent), do so in the new send_conference_mail()
function which takes care of almost every case of sending.
|
|
This removes hardcoded strings from the code and moves it into jinja
templates. Both a cleaner place to put it, but also makes it possible to
override in a skin.
|
|
Moving these templates, which are mostly simple textfile, into jinja
makes it possible to override the contents of these emails on a
per-conference basis, just like any other templates.
|
|
Mostly pep8-incompatible imports generated by 2to3, many of which
weren't used anyway. Also some indentation errors caused by 2to3.
|
|
|
|
|
|
py3 changes the / operator from current integer division (floor
division) to instead be true division (float division). The // operator
exists in both py3 and py2 and always performs floor division.
Most of our important calculations already use Decimal with explicit
number of decimal points which is safe against this. But for some cases
like calculating pixels in pdfs and reports make sure that we explicitly
use the // so we don't risk a change in behaviour when we eventually
switch to py3.
|
|
Sibling imports should be prefixed with a period. Good idea in py2, will
eventually become required in py3, so another small step.
|
|
Create a special notification address that is used for all admin
notifications, instead of contactaddr (defaults to the same one for old
conferences). This also updates all existing calling points that sent
from contacddr->contactaddr to instead use the notificatino address, but
the old contact address is still used as the sending one when sending
*to* attendees.
Make it configurable on a per conference basis to get registration
notifications. If enabled, the notify address will get an email whenever
somebody registers or cancels a registration (on cancel including the
reason).
In passing, re-order and re-group some of the fields on the conference
configuration page to make it more readable as it's growing.
|
|
|
|
Basically reverse the flow - instead of having the invoice system
refund an invoice and trigger an action in the attached systems (such
as confreg or membership) to remove something, have the actual end
systems like confreg handle the cancelation and just tell the invoice
system what the refund is.
This makes the system a lot more flexible and makes it possible to
handle things like multi-attendee invoices that get partially refunded
more than once.
Other than the order-reversal:
1. Each invoice can now have multiple refund notes. In doing this, the
view of "refunded invoices" has also been retired, as it makes less
sense now.
2. Refund notices now include a "previously refunded" section if they
are anything except the first refund note, to track across multiple
refunds. This creates a breaking change in the API for PDF
generation, but recent other updates to the skinning broke them all
anyway.
3. For confreg, implement "refund patterns". This is a set of rules
with "refund x% minus fees of y" rules that can be applied when
canceling a registration. They are applied to the individual costs
being refunded. They can also be given a start/end date during
which they should be used, which is used as a hint in the UI.
|
|
Since this is used for both badges and tickets now, it shouldn't have
badge in the name :)
While at it, update the documentation with information about the
tickets.
|
|
This adds a system for generating tickets and using those tickets when
the attendees check into the conference. Fundamentally this consists
of a number of things:
* A webapp for checking in users, including support for both QR code
scanning of tickets and manual searching/checking in.
* Generating tickets as PDFs, making them available on the
registration page, and sending them with the welcome email. Tickets
are generated using the same kind of JSON template that badges
already did, from a file called tickets.json. A basic sample ticket
is included, but should normally be skinned per conference.
* Tickets can be enabled/disabled on a per conference basis, which
turns on the availability of all those things.
* The check-in process is enabled/disabled on a per conference basis
when the confernce starts and is shut down after it's finished, and
controls just the checkin app.
* Check-in processors are assigned on a per conference basis to
registered users. Those are the users that will use the app to
perform checkins. (Need to be a bit careful about handing out that
permission since it can access a lot of information about attendees)
* The exact time of a checkin is tracked along with who checked the
attendee in. Reporting can be added for this later, to track things
like peak times more efficiently.
* Support is added for the concept of "queue partitioning". This is
wen the queues at checkin are split into separate ones, such as
"A-F", "G-S" etc. This is done as part of the ticket system as we
can then print the suggested queue already on the ticket, so there
is no ambiguity.
* The actual queue partitions can be decided at conference time when
it is known how many there will be. A new reports allows for
automatic calculation of where the partitions should be to get as
even as possible queues.
This adds two new tokens to each registration, an "idtoken" which is
the secret token used on the ticket in order to look up the
registration (we don't want to use the regtoken here, as that one is
even more secret and allows the modification of a registration), and a
"publictoken" which can be printed on badges for public lookup. The
public token is not currently used at all, but it's easier to make it
available at the same time.
|
|
* Add the ability to track emails against individual attendees and not
just registration classes.
* Add the ability to track emails to users who are not yet registered
(but they must have a user account as that's what we track against).
These emails gets automatically attached to the registration once the
user registers.
* Add support to the registration dashboard listing for ticking of
attendees to send email to, and to send it.
* Add generic support to the admin backend for the same, and enable this
support for sessions (more can be adde din the future).
* Change the admin list of emails to collapse when there are many emails
sent, and not overflow the screen. This as it's more likely that many
emails are sent now.
Create a file called admin.js for this -- more should probably be
migrated over to this file instead of living in individual HTML files,
but that's for a later commit.
|
|
These can/should be used for other things than confreg, so move them
there.
We break the abstraction by actually continuing to keep things like
conference specific filtering in them. We may break that out into
something pluggable in the future when actual needs arise from
other modules.
|
|
This gets rid of a somewhat nasty circular import in backendviews.
|
|
Embarassing mistakes for a database developer...
|
|
|
|
|
|
Surprisingly many of these were pure copy/paste errors from the same
source...
|
|
|
