| Age | Commit message (Collapse) | Author |
|---|
|
This change allows the currency format to be configured in the
instance. This allows us to use alternate symbols (e.g. £), and
to format amounts using the format required in different
jurisdictions.
The currency format is set to Euro by default.
Note that this change requires an update to any Jinja templates
that use the currency_format tag. This must be changed to
format_currency.
|
|
This is complained about more loudly in newer versions of pycodestyle,
and it's a bad idea in general. So rename them all to something more
readable.
|
|
|
|
This changed the same way as is_authenticated in django 2.2, but was
missed in the migration.
|
|
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.
|
|
pycrypto is not being maintained, and pycryptodome is theoretically a
drop-in replacement (in practice, it seems it was close)
|
|
At least all email addresses being input by end users should be
confverted to lowercase to avoid duplicates.
Update existing users, registrations and election candidates to be
lowercase, and add constraints to them
For things like conference contract addresses that are only set by
superusers, we skip the constraints part and let the user take some more
responsibility.
|
|
|
|
One spotted by Guillaume, the other by grep
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Unfortunately, withdrawals can't be tested in Trustly test, because they
simply don't exist there..
|
|
This also adds a new scheduled job to fetch withdrawal transactions from
the Trustly ledger, running once per day.
|
|
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.
|
|
Trustly payments can remaining pending state for quite a long time, due
to banks being closed over weekends etc. In this case, bad things
happened when the invoice was automatically canceled.
However, unlike iban payments we know that the likelihood of the payment
actually being completed is very high. So instead of giving up, have the
system automatically extend the invoice cancel time when this happens.
This is done in two stages:
1. Immediately as the payment arrives it's made certain that the invoice
has a lifetime of at least 2 hours left. This extension is done
silently (except logged of course)
2. A cronjob designed to run hourly (to make sure it runs before an
invoice extended by 2 hours expires) will extend it in steps of 24
hours if it remains in pending state. If this happens a notification is
sent, so the admin can make a decision on whether to cancel or not.
Do this by implementing the functionality generically in the
InvoiceManager so it can also be used by other payment methods in the
future, but Trustly being the only one it's implemented for right now.
|
|
|
|
|
|
|
|
When a Trustly transaction is refunded in a non-default currency the
actual refund is listed in that currency and not the primary one, which
makes it not match up in the accounting.
To deal with that, fetch the ledger rows for the day of the refund and
try to locate the actual amount there. If found, use this amount to
calculate "fake fees" (as the amount normally doesn't match perfecly due
to currency rates changing between payment and refund). This should
hopefully lead to a balanced accounting entry.
|
|
|
|
Zero is not more than one. This clearly never worked, on account of us
not being able to test refunds on Trustly testing system due to a vendor
bug.Fix trustly withdrawal fetching
Zero is not more than one. This clearly never worked, on account of us
not being able to test refunds on Trustly testing system due to a vendor
bug.
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
Many of these were masked with the using of tabs, but were basically
incorrect all the time. It's all in places where whitespace doesn't
actually matter, but let's try to match up to PEP8.
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
System skinning allows a "merged view" of the core code with that of a
"skin". A skin represents the local deployment, such as "PostgreSQL
Europe". Individual conferences are still skinned individually on top
of this.
As part of this, remove all PGEU website specific content, as that is
now moved to the PGEU specific skin. Also removes the cmutuel
application module as nobody outside PGEU needs this.
Update the global templates to remove mentions of PostgreSQL Europe,
and let PGEU override those templates as necessary. Front page
template just becomes an empty placeholder, and is expected to always
be overridden.
Makes several more modules configurable by setting ENABLE_NEWS,
ENABLE_MEMBERSHIP and ENABLE_ELECTIONS (we already had
ENABLE_BRAINTREE).
And finally, update the devsetup to be a bit more correct and also to
set up an uwsgi ini file to use for local testing.
Still lacking documentation and a few small parts are still PGEU
hardcoded, so some follow-up patches to come.
|
|
This will be required in future Django versions, and currently throws
deprecation warnings.
|
|
Importing from django.core.urlresolvers is deprecated in favor of django.urls.
|
|
|
|
|
