* Add company and address fields to attendees
* Update src/pretix/control/templates/pretixcontrol/event/settings.html
Co-Authored-By: Martin Gross <gross@rami.io>
Co-authored-by: Martin Gross <gross@rami.io>
* Upgrade Django to 3.0 and other dependencies to recent versions
* Fix otp version contsraint
* Remove six dependency
* Resolve some warnings
* Fix failing tests
* Update django-countries
* Resolve all RemovedInDjango31Warnings in test suite
* Run isort
* Fix import
* Update PostgreSQL version on travis
* Drop support for maindomain_urls/subdomain_urls in plugins
* Allow to use a custom domain per event
* Fix bug when manually saving domains
* Fix custom domains in debugging
* Fix middleware
* Fix middleware again, update docs
* Statistics on sold and unsold seats, as well as potential profits
* Rework of seats-stats
* Fix crash when all seats are assigned
* Update src/pretix/plugins/statistics/views.py
Co-Authored-By: Raphael Michel <michel@rami.io>
* Update src/pretix/plugins/statistics/views.py
Co-Authored-By: Raphael Michel <michel@rami.io>
* Update src/pretix/plugins/statistics/views.py
Co-Authored-By: Raphael Michel <michel@rami.io>
* Fix count of sold seats
Co-authored-by: Raphael Michel <mail@raphaelmichel.de>
Co-authored-by: Raphael Michel <michel@rami.io>
* Optional MOTO-Flagging for Reseller Scheme-TXs
* Update src/pretix/plugins/stripe/payment.py
Co-Authored-By: Raphael Michel <michel@rami.io>
* Update src/pretix/plugins/stripe/payment.py
Co-Authored-By: Raphael Michel <michel@rami.io>
* Manually rebase again...
* Fix a single whitespace for style...
Co-authored-by: Raphael Michel <mail@raphaelmichel.de>
* Add more Stripe Payment Methods, simplify forms
* Revert accidential commit of boxoffice control renderer...
* Use existing QR-Code encoding in presale
Negative transactions are never matched automatically, which does not
change. However, when matching them manually, a negative payment was
created, which does not make much sense. Now, if a negative payment is
manually matched, the system checks whether:
a) There is a manual refund in pending state. In this case, the refund
will be marked as done.
b) There is a bank transfer payment of the same amount, in which case
this is handled like a credit card chargeback (i.e. notification on
the dashboard, ...)
c) Otherwise, an error will be returned asking the user to create a
refund object manually.
* Always call render_invoice_text - even if order is already paid
* Print PayPal payment ID on invoice if available and invoice is paid
* Also display Sale ID on invoice
* try/except for paymentId/SaleId
