| Age | Commit message (Collapse) | Author |
|---|
|
This is one never seen before and seems to be used for shipping labels.
Bring it in and treat it like any other.
Noted by Christophe Pettus, but not his patch - going for a minimalistic
one. This code may need some further refactoring down the road.
|
|
Apparently some bank withdrawals are "General Withdrawal - Bank account"
and others are "Withdrawals initiated by user".
|
|
Seems paypal sometimes can give back transactions without an email
address even if the email address is mandatory. Because why not. When
this happens, just fall back to our treasurer email from the config -
it's almost guaranteed to be the wrong but but it is also guaranteed to
exist, so the treasurer will just have to clean up the records manually
in accounting later.
|
|
|
|
|
|
Now a separate code for donations made using a mobile device, as if we'd
care...
|
|
This code was copy/pasted between several different places, so
centralize it into the InvoiceManager class to reduce the risk of
furhter off-by-one mistakes when editing.
|
|
Unsure exactly what this is, but they have no sender and no receiver,
and they don't show up in the Paypal UI, so they can most likely be
ignored. If not, it'll have to be dealt with manually.
|
|
It seems PayPal now has an API to get balances again, so use that one
instead of the previous ugly hack to figure out the balances. With luck
this means no multi-day wait for balances to match up.
|
|
|
|
|
|
This is a direct-bank-deposit, such as when doing an IBAN payment to
ones own account. There are no details at all available in the message
from paypal, so just make one up and fake the email, like we do with
paypal withdrawals.
|
|
This was already done once in 8289e05cd but had not been properly
maintained.
|
|
This should always be set to todays date, so set it in the function
instaed.
This changes the behaviour of the paypal plugin to actually use todays
date rather than a date parsed out from the notification. In theory this
could change the accounting entry date in case the notification is so
delayed it ends up on a different day, but either one could be argued to
be equally correct in this case, and using the date of creation of the
transaction makes tracking things a lot easier.
While at it, clean up some imports that have been missed earlier.
|
|
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.
|
|
|
|
|
|
|
|
Seems there are also cases where there is no name on the paypal
transaction (again inconsistently). So if we have exchausted all known
ways to find the name, just fall back and set it to the email.
|
|
Seems code T1106 *sometimes* has an email address, and sometimes not,
attached to it. It's not documented when these differ, so just try to
get it and if it fails fall back to our own email address.
|
|
For historical reasons (pre-accounting-system, really) we treated
payments we didn't know what they were as errors, *except* if they were
sent with a completely empty string.
This changes them to instead be treated the same as the empty ones,
which means create an open accounting entry and let the operator deal
with it (but through the nicer interface, not through having to
hack the backend tables). It does this by separating out the "did not
match regexp" as a separate return value, and using that. Any other
errors in processing (such as actually finding the pattern with an
invoice number in it, but then not finding the invoice) is still treated
as an error like before.
|
|
Yet another event code that started appearing. Previously, chargebacks
were posted as refunds.
|
|
|
|
They may look similar in some places, but are different in others.
|
|
Apparently you get "subscriptino payments" from people even if you don't
support subscriptions. It shows up if somebody voluntarily sets up for
example a monthly donation (as far as I can tell, I can't find any
documentation about it)
|
|
Trap errors and show them instead of just crashing with a json key
lookup error. In passing, also store the tokenscope in a member variable
on the API in case it's needed later.
|
|
One spotted by Guillaume, the other by grep
|
|
The API we've been using has been deprecated for a while, and they've
now apparently started randomly dropping parts of it. So bite the bullet
and migrate to the new one. This is a bit cleaner for some things, lots
of things are missing, and transactions take several hours before they
show up in the reporting parts of it. Luckily, those parts are only used
in cronjobs running every few hours anyway...
There are new transaction codes for everything, so there are probably
some missed. There are also new and fancy inconsistencies in the
different ways that transaction texts can be reported, so there are most
likely some missed cases, but the common ones are covered.
Regular payment information is still using the PDT system (which is
independent of both APIs) and should not be affected. Only the fetching
of transactions, balances and issuing of refunds are.
NOTE: This requires reconfiguration of all paypal integrations. Instead
of api user/password/signature, an OAuth client and secret is used, and
the app itself has to be registered on each account. Instructions are in
the documentation.
|
|
|
|
|
|
It seems Paypal no longer includes the currency for Transfer records in
the old API. This API is deprecated so we should switch to a newer one,
but for now just make sure we don't crash and just give the same error
as we would if the wrong currency was used.
|
|
This adds the scheduling metadata to all the existing management
commands.
In passing, also makes the description nicer on a couple of them,
since it is now shown in the admin web.
|
|
This is a major refactoring of how the payment method integrates, with
the intetion of making it more flexible and more easy to use.
1. Configuration now lives in the database instead of local_settings.py.
2. This configuration is edited through the /admin/ interface, which
makes it a lot easier to add constraints (and instructions), thus
preventing misconfiguration.
3. Invoice payment methods are now separate from invoice payment
implementations. That means there can be multiple instances of the
same payment method, such as multiple different paypal accounts,
being managed.
4. All payment method implementations are now available in all
installations, including Braintree and Trustly. This retires the
x_ENABLED settings in local_settings.py. The code won't actually run
unless there are any payment methods defined with them.
5. On migration, all payment methods that are marked as inactive and
have never been used are removed. Any payment method that has been
used is left around, since there are old invoices connected to it.
Likewise, any payment method that is selected as available for any
sponsorship level (past or future) is left in the system.
XXXXXX manual action needed on production systems XXXXXX
1. Settings for payment methods should be migrated automatically, but
should of course be verified!
2. The template for Manual Bank Transfer is *not* migrated, since it
wasn't in settings.py, but in a template and overriden downstream.
Migrate the contents of the template invoices/banktransfer.html to the
database using the /admin/ interface. When this is done, the template
can be removed.
3. Notification URLs in Adyen must be updated in the Adyen backoffice to
include the payment method id in the url (adding a /n/ to the end of the
URL, with n being the id of the payment method).
4. Notification URLs in Paypal must be updated the same way.
|
|
|
|
2to3 doesn't do this automatically, probably because weird things can
happen if you had both. We know we didn't, so just do a straight
replacement.
|
|
|
|
|
|
A long time ago the string was made non-hardcoded, but the length of the
string was not.
|
|
It may look worse, but it makes pep8 happy
|
|
|
|
|
|
It's a lot cleaner API than urllib2, and will be easier once we port
version.
Hopefully this doesn't break something. Probably it does break encoding
somewhere, because py2.
|
|
Sibling imports should be prefixed with a period. Good idea in py2, will
eventually become required in py3, so another small step.
|
|
Python 2.6 introduced the better syntax, Python 3 removes the old one,
so one small step towards py3.
|
|
It has been deprecated, and instead we should use "in" and "not in", so
make that change across the board.
|
|
Disencouraged by pep8 due to hard-to-read
|
|
|
|
In passing remove some comments that were pointless
|
|
Mostly not important, but getting rid of the PIP warnings will help
catch errors in the future.
|
|
Surprisingly many of these were pure copy/paste errors from the same
source...
|
