| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
Instead, give a proper error message.
|
|
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 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.
|
|
|
|
|
|
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.
|
|
|
|
The fractional VAT patch did not properly handle the case when the field
could actually be NULL.
|
|
|
|
Move the backwards-compatibility checks for fitz over to this new file
as well, instead of having them spread out through the code.
|
|
Pyjwt 2.0 made some incompatible changes in how a signature is verified,
so we need to support both the old and the new one.
For cleanliness, create a util/versionutil.py that wraps these version
specific things. There are clearly more.
|
|
This allows the reconnection on an exisitng account. Unable to test this
full workflow until an account actually has expired, but hopefully it's
good...
|
|
We must pass a unique reference to gocardless and if our existing one
expired we cannot re-use the one. So add a random uuid to the reference
string and hope that solves it.
|
|
We made two api calls but checked the status of the first one twice.
|
|
Allow fractional tax rates, up to 6 decimal places.
Author: Steve Singer, with some fixes from me
Fixes #164
|
|
The contents of the dropdown in the filter was taken from the conference
they are being copied *to*, but the contents of the list is the objects
from the conference being copied *from*. This mostly shows up when
copying sessions, when filtering by track or room makes most sense --
and would be wrong if the track/rooms didn't exist in the new
conference.
|
|
|
|
|
|
|
|
When creating a new message provider we can't compare the
username/password to an existing one because it doesn't exist yet..
|
|
This adds Bluesky as a messaging provider to the system. For the time
being it only supports making broadcast posts (similar to the linkedin
provider).
This support should be considered alpha or beta at this time.
|
|
This could cause a divide-by-zero in some cases. Instead render the text
"NO DATA". Normally, the entire svg would be exluded in this case, but
in case it's not this will at least work.
|
|
The qrencode library we've been using is basically dead (and has been
for a while), so add support for the newer pure-python qrcode library.
We keep support for the qrencode one around, so we don't break things
on existing installs, but consider it deprecated and should eventually
be removed.
Fixes #123
|
|
Noted by Karen Jex
|
|
|
|
|
|
|
|
|
|
This caused an error in the view when setting up a new oauth client
(such as a linkedin page). It happened *after* the actual configuration
was completed, so one just had to reload for things to work, but it
still shouldn't error like that.
|
|
|
|
This uses (partially) the pgweb code for loading previewable HTML into
an iframe sandbox.
|
|
|
|
As of 45b8e2e9, we update the sent column to be True while leaving
unsent providers in the linked table (so we can keep track of which
succeeded and which failed). The nagios check never got the memo about
that one, so it didn't check the sent column, only the linked table,
when in fact it's now enough to *just* check the sent column. So do
that.
|
|
|
|
|
|
Anything to find a pattern.
|
|
Perhaps it's the use of multiple parallel persistent connections that
breaks mastodon.social? Who knows, but it's worth a try since we don't
really make any useful use of the persistent connections anyway.
|
|
They provide a service similar to Plaid but better layed out for small
organisations (in Europe at least) for now. Let's see how long that
lasts, but for now here's a basic provider that works very similar to
the Plaid one, except it does not support webhooks.
|
|
|
|
The providers themselves would catch some exceptions and turn them into
proper error messages, but for the cases where they don't, we want the
loop in the sender to do so for us and just log the exception message.
|
|
It seems at leaast mastodon.social may have implemented rate limiting at
the TCP level (afaict). To work aroud this, implement a 15 second rate
limit for Mastodon API calls to individual providers (allow other calls
to go quicker). As this is done per-process it only affects batch jobs,
but those are also the only ones with the issue.
Uncertain if this will actually work since the limit isn't documented
(unlike the http level limit), but it's worth a try.
|
|
If a URL is *really* invalid, we could crash with an exception instead
of showing a form error.
|
|
|
|
|
|
This was clearly missed when Mastordon support was added, and is pretty
trivial to do - we just need to try to fetch our own account info (like
we already do on twitter)
|
