Note: I still believe the issues described in https://github.com/pretix/pretix/issues/1378
are a problem, and I'm still not keen on adding settings properties to
the API until we have a proper design for it. However, I'm making an
exception here since the list of events can't be used in a very useful
way with not access to the timezone.
* Data model changes
* Fix test failures
* Adjustments
* Some tests and API support
* Check when extending orders
* Make things more deterministic, fix style
* Do not apply negative discounts
* Update price_before_voucher on item/subevent changes
* Add tests for price_before_voucher in combination with free price
* Fix InvoiceAddress.DoesNotExist
* Expose help texts on questions' API
* Update questions docs to show help_text
* Update questions.rst
Co-authored-by: Raphael Michel <mail@raphaelmichel.de>
* Remove check password for event deletion, instead require recent login.
* Reauthenticate for backends using authentication_url.
* Require recent login for data shredder and prompt slug instead of password.
* Fix tests for recent login required on event delete and data shred.
* Pull request remarks for recent login required for event delete and data shred.
* Remove unused imported check_password.
* Allow to import orders
* seats, subevents
* Plugin support
* Add docs
* Warn about lack of quota handling
* Control interface test
* Test skeleton
* First tests for the impotr columns
* Add tests for all columns
* Fix question validation
* Event creation: Add option to select existing team instead of provisioning.
* Event creation: disallow event team provisioning on organizer level.
* Event team provisioning: update default setting location and display strings.
* Update src/pretix/control/views/main.py
Co-Authored-By: Raphael Michel <mail@raphaelmichel.de>
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.
* Basic functionality
* API
* Do not delete seats with vouchers
* Show seat in list of seats
* Validate availability of seats
* Fix invalid logic in Seat.is_available
* Show voucher name in edit form
