* 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
* 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
* Add testmode-support-flag to SalesChannels
* Make saleschannels/testmode-warnings even more dangerous!
* Add warning for payment-methods that do support testmode but are being used in a non-testmode order caused by a saleschannel in a testmode-shop.
* Remove redundant testmode_supported-flag for WebshopSalesChannel
* Raise error on API when sales_channel does not support testmode
* Tests
* Fix style issue after merge
* Autocheckin data model/cosmetics
* Expose automatically checked-in OrderPositions
* Expose automatically checked-in OrderPositions in CSV/PDF Exports
* Fix some tests, try to fix MultiStringField/CheckboxSelectMultiple
* Actually fix MultiStringField/CheckboxSelectMultiple.
(Not pretty, but it works)
* Fix more tests
* Squash migration
* Also fix CSV/nameparts-test
* Changes for Autocheckin code-review
* Perform Auto-Checkins through new core plugin
* Update config-doc to reflect also checkinlists
* Explicitly output AutoCheckin Yes/No for CSV-Export (+ fix test)
* Move autocheckin from plugin to service
* API-doc
* Fix API-doc spelling
* Checkinlist-API and autocheckin order tests
* Performance improvement when reading checkinlists for autocheckin
Co-Authored-By: Raphael Michel <michel@rami.io>
* Autocheckin test for order created through API
* Resolve migration conflict
* Initial work on seating
* Add seat guids
* Add product_list_top
* CartAdd: Ignore item when a seat is passed
* Cart display
* product_list_top → render_seating_plan
* Render seating plan in voucher redemption
* Fix failing tests
* Add tests for extending cart positions with seats
* Add subevent_forms to docs
* Update schema, migrations
* Dealing with expired orders
* steps to order change
* Change order positions
* Allow to add seats
* tests for ocm
* Fix things after rebase
* Seating plans API
* Add more tests for cart behaviour
* Widget support
* Adjust widget tests
* Re-enable CSP
* Update schema
* Api: position.seat
* Add guid to word list
* API: (sub)event.seating_plan
* Vali fixes
* Fix api
* Fix reference in test
* Fix test for real
* Change semantics of changing orders
This basically does two things to the "Change products" view of orders and the
OrderChangeManager program API:
1) It decouples changing items or subevents from changing prices.
OrderChangeManager.change_item() and .change_subevent() no longer
touch the price of a position. Instead .change_price() needs to be
called explicitly. However, a client-side JavaScript component now
*proposes* a new price based on the changed item or subevent.
2) The user interface now exposes the possibility of doing multiple
things at the same time, i.e. changing the item, subevent and price
in the same operation. OrderChangeManager already allowed this
before.
(1) is basically a consequence of (2), while (2) is a prerequesite for
e.g. the `seating` branch, where changing the subevent will always
require changing the seat.
* Add tests for price calculation API
- [x] Provide data model and configuration toggle
- [x] Allow to delete individual test orders
- [x] Add tests
- [x] Add a prominent warning message to the backend if test mode orders exist (even though test mode is off), as this leads to wrong statistics
- [x] Decide if and how to generate invoices for test orders as invoice numbers cannot be repeated or should not have gaps.
- [x] Decide if and how we expose test orders through the API, since our difference pull mechanism relies on the fact that orders cannot be deleted.
- [x] Decide if and how we want to couple test modes of payment providers?
- [ ] pretix.eu: Ignore test orders for billing
- [ ] Adjust payment providers: Mollie, bitpay, cash, fakepayment, sepadebit
- [x] Data model
- [x] display in order view in backend
- [x] review all usages of OrderPositions.objects
- [x] review all usages of order.positions
- [x] review all other model usages
- [x] review plugins
- [x] plugins backwards-compatible API?
- [x] decide on way forward for REST API
- [x] need to cancel fees
- [x] tests
- [ ] plugins
- [ ] gdpr
- [ ] reports
- [x] docs
- [x] Data model
- [x] Enforce constraint
- [x] Filter order list
- [x] Set channel on created order
- [x] Products API
- [x] Order API
- [x] Tests
- [x] Filter reports
- [x] Resellers
- [ ] deploy plugins
- [ ] posbackend
- [ ] resellers
- [ ] reports
- [x] Ticketlayouts
- [x] Support in pretixPOS
