| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
When a registration transfer invoice is completed, if they payment
confirmation notification hits before the user clicks onwards, we can't
find the transfer record because it's been removed. In this case, just
redirect the user back to the invoice so they get something other than a
crash.
|
|
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.
|
|
fec92794 fixed so that we tried to properly unlik prepaid vouchers when
invoices expired on regular invoices as well, and not just on bulk
invoices. But this also exposed another bug whereby it could fail on
registrations with discount codes and not prepaid vouchers (this bug
existed for bulk payments as well, but seems to have slipped under the
radar, but once we had the same code for regular registrations it
happened more often)
|
|
ConferenceRegistration is a table with many fields, so avoid saving all
of it during invoice procesisng, when only 2-3 fields are actually
modified.
|
|
Normally an invoice with a prepaid voucher is never generated, but if
the user *also* adds an additional option, it can be. And if this
invoice was then canceled (or expired), the voucher field would be
cleared from the registration, but not actually unlinked from the user
and therefor listed as used if viewed from the voucher list, and not
reusable.
It was correctly unlinked if a bulk payment was used, but not for an
individual registration. So copy the method from the bulk invoice
processor.
|
|
This was previously built to use the generic function for expiring
additional options. But since the cancelation of the invoice itself
would update the lastmodified field on the registration, this would
never work -- the expiry would be based on the current time instead,
mening it would never trigger.
Instead do the expiry directly in the invoice cancelation handler. As a
bonus, this means the attendee doesn't get multiple emails saying they
were canceled, just one.
|
|
The effect is the same as when the waitlist entry expires, which does
send a notification, so make sure we send a notification in both cases.
|
|
|
|
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.
|
|
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.
|
|
Previously they were just date, whereas both the invoices and individual
registrations tracked by datetime. Fix this inconsistency. For old
entries they will show up as time 00:00:00.
These fields were almost unused in the code -- they are only used to
show the status of a bulk payment, and not actually used in any
processing.
|
|
The code previously removed the code linking which dealt with the number
of codes available, but missed to remove the code from the reg itself.
That resultet in the later step failing to find that discount voucher.
|
|
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.
|
|
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.
|
|
Caused exception on cancelled bulk payment invoices (which was luckily
very uncommon).
|
|
Add a list of the created multiregs for a conference to the dashboard.
Also update the invoice system to properly link back to this page when
going back (makes it much easier to find)
|
|
This is replaced with the new style multi-registrations that have turned
out to be a lot closer to what the people using them actually wanted.
Internally the concept of bulk payments still exist, and the data models
remain unchanged.
The user visible interface for "bulk payment" is simply removed, and all
references to it in user-facing messages are replaced with
"multi-registration".
|
|
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.
|
|
|
|
Surprisingly many of these were pure copy/paste errors from the same
source...
|
|
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
When there is no way to automatically remove something because of a
refund, don't block the refund completely. Instead allow it to go
through and leave it up to the operator to manually verify.
|
|
|
|
For registrations that have a single invoice *and* are eligible for a
refund, we already had working cancelation. But it did not work for bulk
invoices or non-refundable cancelations, which both required manual work
through /admin/ to cancel them. This still does not automate bulk
invoice refunding, but at least provides the ability to perform such
refunds as two-step operations, and it fully supports canceling without
refund.
This also adds sending of email on all cancelations, both those that are
done without refund, and those that are done with a refund like before.
Previously, attendees of those would only receive an invoice refund
notice. We now also send an explicit "your registration has been
canceled" email, if welcome emails have been enabled for the conference.
|
|
This was very uncommon before, but now that we use bulk invoices for
multi-reg processing it becomes more common, and this case shows up more
often. We need to mark the vouchercodes as unused in the system,
otherwise we will fail to generate a new invoice for the same
registration once one has been canceled.
|
|
|
|
In yet another attempt to make it easier for the cases where either
somebody wants to register for multiple colleagues, or just for a single
colleague who cannot register themselves.
This separates out the registrator role from the attendee role in the
database. Regular registrations still work the same way, and sets
registrator and attendee to the same. But it's now also possible to,
using a separate form for each one, make multiple registrations for
other people, by filling out all their details (including email). These
registrations will then automatically generate a bulk invoice.
When the bulk invoice is paid, the registrations attached to it will get
marked as confirmed by the system. They will then also be attached to
the community account of the attendee, if one exists. If one does not
exist, and email is sent to the attendee with a link using the secret
registration token, that makes it possible to attach this registration
to a different account. This means that the user can sign up for an
account (especially easy now that we have oauth logins available) after
the registration has been created, or they can attach it to a different
account if they already have one but it has a different email address
than used on the registration.
|
|
This commit changes almost every confreg URL in the system, from using
the pattern /events/action/conference to using
/events/conference/action. E.g. /events/register/someconf/ to
/events/someconf/register/.
The reason for this is that all pages that belong to one event now live
under /events/eventname/, making it more predictable and enablinge some
easier changes in the future as well.
Redirects are implemented for all the older URLs (except there is of
course likely something missed somewhere...).
|
|
|
|
|
|
|
|
If we do a partial refund on a bulk payment, we don't want to cancel
all registrations. Instead, just generate a notification email, and
handle the actual cancellation of the registrations manually.
|
|
This introduces the function of the same name from the pgweb code base
(though it isn't identical, to be clear). This function is to be used
when rendering a text file into an email. There is a helper function
template_to_string() which is also added and can be used if a string
result is needed.
The primary different here is that the variables set in
util/context_processor:settings_context are included in the hash
automatically, so those settings do not need to be explicitly set by
the callers and the templates can expect them to be available.
Using that, this change also includes changes to move away from
hard-coded values like 'PostgreSQL Europe' in favor of using the
variables set in settings.py/local_settings.py in the text templates.
This will allow others to re-use the exisitng templates and not have
to develop and maintain their own going forward.
|
|
Previously we just unconfirmed them, which made sense before we had
reminders. But now that we have reminders, somebody who canceled their
attendance and had the invoice refunded would end up getting reminders
to complete their registration.
|
|
Previously if somebodys early bird invoice was canceled, it would still
eat up a "slot" for the discount codes.
|
|
1. When a registration gets added to a bulk payment invoice, send
an email to the attendee about this, including information about
who did it, and that they can no longer modify their registration.
2. When a bulk payment invoice is canceled (manually or automatically),
notify all the attendants on in that it happened and that they are
NOT confirmed for the conference, and whom to contact.
3. Same for refunded invoices when their registration is also
canceled.
|
|
Instead, as of now we run all content over https always. The enforcment of this is
placed in the webserver, which makes it impossible to miss it on some feature.
This retires the setting SITEBASE_SSL, and changes SITEBASE to be https.
It also retires DISABLE_HTTPS_REDIRECTS, which has no use anymore.
And finally, SESSION_COOKIE_SECURE is now set by default, and needs to be turned
off in local development environments.
|
|
Registrations that don't have invoices or bulk paymens still "lock" additional
options from others. And some attendees never complete their registrations
at all.
With this new cronjob enabled, those will also respect the "invoice autocancel hours"
parameter from the additional options, and be removed after that time. As there is
no actual registration, the only thing that happens is that the current registration
is edited and the additional option removed, the rest of it remains. And as long
as nobody else manages to register in between, the attendee can go back and re-register
for it as long as it's still available.
Expiry also happens automatically when an invoice is cancelled, as it makes more
sense to do that right away rather than waiting for the next cronjob to run, for
consistency.
This adds a "lastmodified" field to all conference registrations, which is used to
track this and other changes. So we only track the changes on the level of the
whole registration, and thus won't catch people who go in and edit their address
for example, without modifying the options. But the target with these removals
are those that have completely abandoned their registration, which will be
properly handled.
|
|
This allows a maximum number of attendees before waitlist to be
specified on the conference record. Once this number is reached,
people trying to register will automatically be given the option
to sign up on the waitlist instead. They can then be approved one
by one off the waitlist with a limited time offer to finish the
signup. If the time expires, they get moved back to the bottom of
the waitlist, and then we repeat the process.
The limit should normally be set a bit below the actual limit of
the venue, so that we can control who gets the last signups. For
example, we might need to reserve some for a speaker or a sponsor.
|
|
Also update the registration dashboard to show some interesting
details about the registration, instead of just a placeholder.
This makes it possible to order things like training even if the main
registration has completed, to help people who change their mind.
This will also automatically upgrade the reservation to one that is
required by the options, if necessary. If the upgraded registration
type is more expensive than the current one, automatically add the
cost difference to the invoice.
To control this, implement the option "upsellable" for each additional
option, without which an option cannot be added, and an option
"upsell_target" on a registration type, without which a registration
cannot be changed to that type.
|
|
For each conference it's now possible to define a message text
that will be sent out to all attendees once their registration
is confirmed (either by invoice payment, bulk invoice payment,
no invoice needed, or manual processing). This should help with
the complaints from people who are used to getting this (the
status was already visible on the website), as well as give
a chance to include some extra information.
With this we can now replace the mailman integration with builtin
emails whenever needed.
|
|
|
|
This will for example remove a conference registration automatically,
but most importantly it let's us keep track of our actual invoice
payments properly.
|
