| 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.
|
|
Transferwise re-invented interest and call it cashback (it's the same as
interest..), and we already knew how to classify these transactions. So
instead of leaving them as pending, automatically book them against a
predefined account.
|
|
In particular, make it possible to show the bulk payment invoice
directly from the registration page, if one exists.
|
|
|
|
Due to the new transferwise restrictions, creating payouts would crash.
This change attempts to make it complete the parts that work and leave
the rest for a manual approval in the transferwise web interface,
hopefully keeping the rest of the system working.
When half way complete, send a notification to the user to go complete
it manually.
|
|
Signwell have implemented a size limitation that no fields can have a
height bigger than 34px. Unfortunately, their own GUI editor allows the
creation of fields that are larger than this, and once one has done that
they can no longer be loaded for editing or sent through the API (it
appears the limitation is only in the public API and not their internal
ones).
So to make signing work at all, when editing a contract enforce the
limit to 34px (with a warning). Things might not look very nice anymore
but they should at least work.
Support case has been opened with Signwell to see if this was actually
intentional (the max size in the UI editor appears to be 74), and if so
if they are planning to align the UI with the API. This commit goes in
pending a possible change on their side and we can revert if if we end
up not needing it permanently.
|
|
Turns out we need to do this both for primary ands secondary amounts
(which makes sense). Clarify the comment a bit further after more
research that still shows Wise API returns that incoming payments are
actually outgoing. Sigh.
|
|
It's just for display and they're easier to identify this way.
|
|
Clearly missed one field in the update, that was still referencing the
old API structure.
|
|
So remove the scheduled job that handles them, as well as the database
table that stores them.
|
|
Unfortunately, Wise decided one is no longer allowed to access
information about ones own transactions when in Europe, unless
registered as a European payment provider. This is of course stupid, but
what can we do.
Attempt to re-implement the transferwise support over their new
activities API.
Unfortunately there are likely bugs still hiding around, since for
example amounts are now returned in some self-invented html-like markup
like '<positive> 2,000 EUR</positive>' instead of as a number like
before (and sometimes they are returned as <positive> with a negative
number inside). But we have to start somewhere...
Unfortunately, it seems there's a permanent loss of funcionality in that
the account number (IBAN) of the sender is no longer available anywhere
in the API. This means that in practice, automatic refunds of transfers
are no longer possible. (This information appears to also no longer be
available on their website). We keep the refund functionality itself in
the system for now, as we might want to extend it later with the ability
to refund while manually specifying an IBAN number.
|
|
|
|
Click-through contracts makes it easier for most, but some sponsor
organisations require an actual contract at these levels as well. To
handle this, add an option during contract/address verification to
request an explicit contract, which can then be either manual or
digital, and will both prevent the clickthrough contract and invoice to
be sent until thsi contract has been completed.
|
|
Instead, give a proper error message.
|
|
When an image uploaded as a sponsor benefit was broken (unparseable), we
would incorrectly still show the "confirm preview looks ok" checkbox
below the error message. If the user confirmed that the preview (which
was non-existant and replaced with an error message) looked OK, we would
store an empty image in the database and consider the benefit OK.
Instead, we're of course not supposed to show the preview checkbox at
all if the image uploaded is broken.
|
|
If the clickthrough fields were added to a contract, we'd include the
text even if the level wasn't clickthrough. This can happen when fields
are copied between contracts, thereby ending up with clickthrough fields
on non-clickthrough contracts.
|
|
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.
|
|
Linkedin killed off 202405 as an API version. Try a blind update to
202505 and hope they didn't change any of the (very few) API calls we
use :)
|
|
|
|
|
|
This allows explicit specification of "No contract, Click-through
contract or Full contract", instead of the definitely-hard-to-grok
combination of whether a contract existed and if the checkbox was set or
not.
|
|
This generates an actual contract for click-through ("instantbuy with
contract") levels, replacing the signature with a static text saying
"Click-through agreement".
|
|
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
|
|
|
|
Do this by removing the word "prepaid" from the title of the invoice to
make it more likely to fit. Instead, add it to the individual invoice
rows where there should be more space available.
|
|
The default expiry is 24 hours. That means that if an invoice was due to
be canceled in say 4 hours, and the user clicked the payment link they
would be able to use that one past when the invoice was actually
canceled, thereby causing errors. This happened at least once, where the
user forwarded the Adyen link (instead of the invoice link) to the
person who was supposed to do the payment, and that person made the
payment after the invoice was expired.
So, if the invoice is set to be canceled in <24 hours, we set the
expiresAt flag when creating the payment link, so Adyen will reject that
payment.
Reviewed-By: Daniel Gustafsson
|
|
Once a contract is digitally sign we normally (unless something goes
wrong) store a copy of the PDF of the signed contract. This was already
visible on the admin page, but there is no reason not to let the sponsor
view their own contract as well.
Fixes #173
|
|
If a payment method that had bank info on it was added to an invoice, we
would include the bank data on the PDF even if the method was not marked
as active. It would still not show on the webpage of available methods,
but if someone forwarded the PDF alone for payment, they would get the
bank info for an inactive method. So fix that.
|
|
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..)
|
|
This was clearly not quite completed whent he Bluesky support was added.
Reported by Andreas Scherbaum
|
|
|
|
|
|
Apparently this is done automtatically in some versions of requests, and
not others.
|
|
Turns out bluesky doesn't actually shorten URLs if they are posted
through the API even if they have a matching "facet", and the example
code they have ignores this. So we have to implement our own that
basically shortens the "inside" of a facet to an appropriate length.
We'll re-use the twitter-url-shortener-length to make things predictable
between providers.
|
|
|
|
|
|
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
|
|
|
|
Since Linkedin doesn't support wildcards, having the providerid in the
URL required whitelisting individual URLs which was very annoying.
Instead overload it into the state field and use a shared URL.
In passing, fix the redirect after attaching linkedin to a shared news
provider. The attachment worked fine but the redirect went to the wrong
page.
|
|
|
