| Age | Commit message (Collapse) | Author |
|---|
|
Commit c2816116 accidentally removed the confirm link for pending and
pending reserve sessions. Add it back!
|
|
|
|
Output of the markdown filter always includes its own <p>.
|
|
Copy/paste error
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Make sure the warning is actually shown in all cases, so one doesn't
accidentally click through a sponsor that's actually waiting for a
contract.
|
|
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.
|
|
There can be multiple managers of a sponsorship, so for all of them to
be able to view (and pay) the invoice, we need to use the secret-url
link rather tha th eone expecting the user to be the same one as the one
who created it.
Spotted by Cornelia Biacsics
|
|
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
|
|
Fixes #176.
|
|
|
|
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.
|
