note: bezahlcode encoding changed slightly due to actually url-encoding all parameters (comma is now encoded as %2C). i tested with ING app, it accepts both.
before: 'bank://singlepaymentsepa?name=Verein%20f%C3%BCr%20Testzwecke%20e.V.&iban=DE37796500000069799047&bic=BYLADEM1MIL&amount=123,00&reason=TESTVERANST-12345¤cy=EUR'
after: 'bank://singlepaymentsepa?name=Verein%20f%C3%BCr%20Testzwecke%20e.V.&iban=DE37796500000069799047&bic=BYLADEM1MIL&amount=123%2C00&reason=TESTVERANST-12345¤cy=EUR'
* Update pretix logo to new version
* Make favicon transparent
* Update src/pretix/static/pretixcontrol/scss/main.scss
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Update src/pretix/static/pretixcontrol/scss/main.scss
Co-authored-by: Richard Schreiber <schreiber@rami.io>
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Fix not allowing program times on event series (API/copy)
* Return 400 when reading endpoint in event series
* add docs program times not available on event series
* fix isort
* Auto-verify user email addresses on accepting invites
* Update src/pretix/control/views/auth.py
Co-authored-by: Richard Schreiber <schreiber@rami.io>
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Product list: Show number of items currently in cart
* Apply suggestions from code review
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Add display property
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Add program times for items
* Fix frontend date validation
* Add ical data for program times [wip]
* Improve ical data for program times
* Remove duplicate code and add comments
* Adjust migration
* Remove program times form for event series
* Add pdf placeholder [wip]
* Improve explanation text with suggestion
Co-authored-by: Raphael Michel <michel@pretix.eu>
* Fix import sorting
* Improve ical generation
* Improve ical entry description
* Fix migration
* Add copyability for program times fot items and events
* Update migration
* Add API endpoints/functions, fix isort
* Improve variable name
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Remove todo comment
* Add documentation, Change endpoint name
* Change related name
* Remove unnecessary code block
* Add program times to item API
* Fix imports
* Add log text
* Use daterange helper
* Add and update API tests
* Add another API test
* Add program times to cloning tests
* Update query count because of program times query
* Invalidate cached tickets on program time changes
* Reduce invalidation calls
* Update migration after rebase
* Apply improvements to invalidation from review
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* remove unneccessary attr=item param
* remove unnecessary kwargs for formset_factory
* fix local var name being overwritten in for-loop
* fix empty formset being saved
* Use subevent if available
* make code less verbose
* remove double event-label in ical desc
* fix unnecessary var re-assign
* fix ev vs p.subevent
---------
Co-authored-by: Raphael Michel <michel@pretix.eu>
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Allow to round taxes on order-level
* Rename get_cart_total
* Persist rounding mode with order
* Add general docs
* Order creation API
* Update fee algorithm
* Rounding on payment method change
* Round when splitting order
* Fix failing tests
* Add settings page
* Add tests
* Replace algorithm
* Add test case for currency rounding
* Improve order change
* Update flowchart
* Update discount logic (more hypothetical, we don't store rounding on cart positions atm)
* Rename internal method
* Fix typo
* Update help text
* Apply suggestions from code review
Co-authored-by: luelista <weller@rami.io>
* Order rounding refactor (#5571)
* Add RoundingCorrectionMixin providing before-rounding-values as properties
* Use gross_price_before_rounding in more places
* Update doc/development/algorithms/pricing.rst
Co-authored-by: Martin Gross <gross@rami.io>
* Allow to override on perform_order
* Rebase migration
* Fix event cancellation
---------
Co-authored-by: luelista <weller@rami.io>
Co-authored-by: Martin Gross <gross@rami.io>
* Event cancellation: Add safety and security checks
When cancelling an event, a large sum of money might be refunded
instantly. This PR adds safety features around this by
- doing a dry-run first that shows a preview of the expected refund sum
- sending a confirmation mode via email for any automatic refunds of more than 100 currency units
- keeping a more detailed log of the settings this was executed with
* Update src/pretix/control/views/orders.py
Co-authored-by: luelista <weller@rami.io>
---------
Co-authored-by: luelista <weller@rami.io>
* Use the transmission info transformation methods
Use form_data_to_transmission_info and transmission_info_to_form_data to convert between database representation and form data
* Only store transmission email address if invoice receiver is a business
* Fix default implementation of form_data_to_transmission_info
* Update src/pretix/base/forms/questions.py
* Remove explicitly specified width for formset-forms
With that style, all formset rows were a fix pixels less wide than surrounding content
* Set select2 width to 100% so they adapt when browser window is resized
* Run exporters in repeatable read by default (Z#23173095)
* Update src/pretix/helpers/database.py
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Rename parameter, add test
* Do not run during tests
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* datasync: add immediate parameter to enqueue_order
* interactive argument for order_placed signal
The ``interactive`` argument specifies whether the order was
placed interactively, by a customer (as opposed to via a bulk
import or the REST API).
* use bulk=True instead of interactive=False to mark bulk imports
* Fix waitingDialog being shown on browser history back
* Revert "Fix waitingDialog being shown on browser history back"
This reverts commit 1f56d97c69.
* Use pageshow-event as suggested by luelista
* Event calendar: Only show "waiting list" if products allow it
* Add a simple test
* Review notes
* Update src/pretix/base/models/event.py
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Update src/pretix/base/models/event.py
Co-authored-by: Richard Schreiber <schreiber@rami.io>
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Fix unhandled not found error when manually managing sync jobs
* Improve info text (suggestions from code review)
Co-authored-by: luelista <weller@rami.io>
---------
Co-authored-by: luelista <weller@rami.io>
* Flexible invoice transmission
* UI work
* Add peppol and output
* API support
* Profile integration
* Simplify form for individuals
* Remove sent_to_customer usage
* more steps
* Revert "Bank transfer: Allow to send the invoice direclty to the accounting department (#2975)"
This reverts commit cea6c340be.
* minor fixes
* Fixes after rebase
* update stati
* Backend view
* Transmit and show status
* status, retransmission
* API retransmission
* More fields
* API docs
* Plugin docs
* Update migration
* Add missing license headers
* Remove dead code, fix current tests
* Run isort
* Update regex
* Rebase migration
* Fix migration
* Add tests, fix bugs
* Rebase migration
* Apply suggestion from @luelista
Co-authored-by: luelista <weller@rami.io>
* Apply suggestion from @luelista
Co-authored-by: luelista <weller@rami.io>
* Apply suggestion from @luelista
Co-authored-by: luelista <weller@rami.io>
* Apply suggestion from @luelista
Co-authored-by: luelista <weller@rami.io>
* Apply suggestion from @luelista
Co-authored-by: luelista <weller@rami.io>
* Make migration reversible
* Add TransmissionType.enforce_transmission
* Fix registries API usage after rebase
* Remove code I forgot to delete
* Update transmission status display depending on type
* Add testmode_supported
* Update src/pretix/static/pretixbase/js/addressform.js
Co-authored-by: luelista <weller@rami.io>
* Update src/pretix/static/pretixbase/js/addressform.js
Co-authored-by: luelista <weller@rami.io>
* Update src/pretix/static/pretixbase/js/addressform.js
Co-authored-by: luelista <weller@rami.io>
* New mechanism for non-required invoice forms
* Update src/pretix/base/invoicing/transmission.py
Co-authored-by: luelista <weller@rami.io>
* Declare testmode_supported for email
* Make transmission_email_other an implementation detail
* Fix failing tests and add new ones
* Update src/pretix/base/services/invoices.py
Co-authored-by: luelista <weller@rami.io>
* Add emails to email history
* Fix comma error
* More generic default email text
* Cleanup
* Remove "email invoices" button and refine logic
* Rebase migration
* Fix edge case
---------
Co-authored-by: luelista <weller@rami.io>
* Webhooks: Add vouchers (Z#23203072)
This also requires more consistent usage of webhook types to avoid
vouchers not being known to the external system.
* Update src/pretix/api/webhooks.py
Co-authored-by: luelista <weller@rami.io>
* Fix shredder test
---------
Co-authored-by: luelista <weller@rami.io>
* Allow users to run sync jobs immediately
* Transactional safety for manual handling of sync jobs (#5355)
* Fix indentation
---------
Co-authored-by: Raphael Michel <michel@rami.io>
* Orders API: Add check_quotas to orders/change and PATCH/POST orderpositions query params
* Refs #5323: Checkstyle fix
Forgot tu run fkale8 after implementing unit tests oops
* Refs #5323: Fix unit tests and fix of the previous ones
* Refs #5323: PR review
Add a registry for datasync providers and an associated sync queue, to be used by
plugins that transfer data from pretix orders to external systems.
Additionally, provide a generic data mapping interface to be used in settings pages
of such plugins, to let users configure which information from pretix to fill into
which data fields of the external system.
---------
Co-authored-by: Raphael Michel <michel@rami.io>
* Add a system-wide style for admin-only things
* change stripe-color to a red-ish tone
* add stripes to button end-admin-session
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Add Spanish (LatAm) and improve how we count language coverage
* Apply suggestions from code review
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Fix license header
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Widget: limit max-width, make mobile overlay bigger
* overlay in fullscreen for small screens
* re-add topbar for close-button on mobile
* tweak close button-top on mobile
* invert color to make close-button a filled circle again
* Widget: deprecate v1 and redirect to v2
* Make redirect permanent
* remove v1 files
* do not redirect, just serve version_min
* add version-comment to delivered css/js-file
* fix tests
* Widget: fix loading spinner not showing while API-request
* remove not needed showModal as it is handled be frame_loading-watcher
* add double check if dialog is open before closing it
* Add support for versioning widget.js
* add versionable css
* add version deprecation + redirect
* use dynamic template_path instead of dynamic css_path
* remove dummy code from widget.v1.scss
* fix typo
* [A11y] fix input border & focus style (#5149)
* [A11y] fix input border & focus style
* Fix double semi-colon
* [A11y] make collapse-indicator a button (#5150)
* Fix source order for cart-exists-message (#5152)
* [A11y] underline links (#5151)
* [A11y] Move modal-dialogs to HTMLDialogElement (#5147)
* [A11y] move widget/iframe to html-dialog
* make lightbox a dialog
* move error-alert to dialog
* re-add crossorigin
* fix esc-handling and move animation to icon to enable focusing the button
* fix code-style issues
* block canceling loading iframe
* Escape/cancel blocking fix for Chrome
* add round focus-outline when dialog is loading
* Widget v2: change voucher-link to hash-based link (#5161)
* Fix variants toggle-button being submit-button
* Widget v2: make single-item-select button and always show custom-spinners (#5165)
* Widget v2: make single-item-select=button default
* remove native-spinners and single_item_select
* Stop suggesting old parameter
---------
Co-authored-by: Raphael Michel <michel@rami.io>
* Widget v2: add filter button to events metadata-filter (#5162)
* Widget v2: do not underline events in list and calendar (#5163)
* Fix checkbox button missing border radius (#5158)
* Widget v2: turn add-to-cart-button into resume-button if cart-exists and no items selected (#5160)
* Widget v2: make cart-alert live=polite
* Add resume-button if cart-exists and no items selected
* fix error handling with new-tab and later returning to old window
* Fix cart-message button being full height
* fix amount_selected recalc
* Fix broken v-model
* fix merge
* Widget v2: Remove link from variation-product title (#5159)
* Remove link from variation-product, focus associated input
* open variations onclick on product-title
* clickable elements should be focussable and interactive, so better remove click-handler on product-title
* Widget v2: Fix calendar events color contrast (#5164)
* Widget v2: Fix calendar events color contrast
* fix status-bubbles in list-view
* fix color in mobile
* add striped-background to calendar and week
* improve display of calendar for super small screens
* Fix meta-filter legend not being screen-reader accessible
* update version_default to 2
Co-authored-by: Raphael Michel <michel@rami.io>
---------
Co-authored-by: Raphael Michel <michel@rami.io>
* Allow to add declaration of accessibility
* add fallback for empty accessibility_title
* unify label format (not "Title for")
* move title to top and set helptext before text
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* async_task: deduplicate response handling code
* extend cart without full page reload
* update dialog markup
* fix error response from CartExtend
* refactor asynctask, make sure waitingDialog.show() re-initializes dialog contents
* add cart expiry notification
* add aria references to other dialogs
* improve error handling
* fix error if max_extend=None
* different message for expiring soon and expired carts
* refactor dialog css
* add classes to further dialog elements
* switch extend-cart-dialog and loadingmodal to <dialog>
* Backport simple_block_tag from Django 5.2
* Use simple_block_tag for {% dialog %} tag
* add alertdialog role
* Update src/pretix/static/pretixbase/scss/_dialogs.scss
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* fix mobile dialog styles not being overwritten
* asynctask dialog: prevent close by escape on chrome
* remove dynamic aria-live from #cart-deadline
dynamic aria-live is generally not well supported and as we have the dialog now anyways, we can remove it
* move continue-button to right
* Update src/pretix/static/pretixpresale/js/ui/cart.js
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Fix CSS for old-style dialog
* fix heading display/level
* align dialogs at the top as they originally were
* fix </div> from merge-conflict
* fix missing grow for dialog-content
* improve cart-extend-button ui
* do not show cart-extend-dialog onload
* improve message if 0 minutes
* do not save messae in session if ajax_dont_redirect
* add ajax_dont_redirect to async_task_check_url
* improve draw_deadline to only update #cart-deadline if necessary
* add renew-confirmation-message
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
Co-authored-by: Raphael Michel <michel@rami.io>
* [A11y] move lightbox to native dialog
* fix width-sizing-issue
* move button label to aria-label
* increase padding for lightbox, so button does not overlay image
* Remove unused JS
* add close on backdrop-click
---------
Co-authored-by: Raphael Michel <michel@rami.io>
* [A11y] move timezone info inline instead of tooltip
* Update text as suggested from code review
Co-authored-by: Raphael Michel <michel@rami.io>
* Rebase migration
* Delete src/pretix/base/migrations/0280_event_is_remote.py
---------
Co-authored-by: Raphael Michel <michel@rami.io>
* add templatetag {% dialog %} using <dialog> tag
* new dialog style
* show dialog when empty add-to-cart instead of disabling the button
* update cookieconsent-modal to use new template tag
* [A11y] fix calendar nav dropdown
* update organizer calender
* keep cal-nav on one line
* simplify html
* unify calendar layouts
* fix rounding issue with .input-group select+button
* add comment to explain complex css
* fix calendar dropdown due to too broad css-selector
* reduce spacing of top-nav
* fix input-group-btn double line through rounding issue
* Metrics: Fix Content Type header
Now it follows the PrometheusText1.0.0 ContentType header specified from their code: 32d306854b/config/config.go (L516-L529)
* Update src/pretix/base/views/metrics.py
---------
Co-authored-by: Raphael Michel <mail@raphaelmichel.de>
* [A11y] add skip-link to main content
* fix contrast for skip-link
* fix overlay with back-to-organizer-link
* add fallback if no main-element
* update nav-label
* Product list: Show icon for seated products
* Use updated seat icon
* Update src/pretix/static/pretixbase/scss/_theme.scss
Co-authored-by: Richard Schreiber <schreiber@rami.io>
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* [A11y] add min/max as help_text to date/time inputs
* update text
* Fix help-text (suggestions from code review)
Co-authored-by: Raphael Michel <michel@rami.io>
---------
Co-authored-by: Raphael Michel <michel@rami.io>
* Questions: validate that min < max
* Update src/pretix/base/models/items.py
Co-authored-by: Richard Schreiber <schreiber@rami.io>
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
If two discounts match the same products, the first one wins. Therefore,
the one we want to win in the test must always come last, otherwise the
test is not actually testing anything. In this case, this is highlighted
by the fact that the test does not pass in diffrent orders of discounts
unless we subtract a second from the date, because we compare with <=,
not <.
* Show link to stripe payment receipt in backend (Z#23187178)
* Revert "Show link to stripe payment receipt in backend (Z#23187178)"
This reverts commit 4a261ac1ac.
* Show link to stripe payment receipt in backend payment details (Z#23187178)
When selecting revoked devices and using bulk edit on them, the edit was performed
either *on all active devices* or not at all. This commit fixes that behaviour so that the
selected devices are edited.
* Add event date fields, add preliminary range check
* Remove function, use filtered queryset for subevent id limit
* Improve and fix date range check
* Add formfields
* Add tests
* Improve tests
* Add new fields to API and documentation
* Add migration
* Change description according to suggestion
* Change discount apply signature, remove unnecessary query
* Rename new fields, simplify range check
* Rename fields in template
* Apply suggestions from code review
Co-authored-by: Raphael Michel <michel@rami.io>
---------
Co-authored-by: Raphael Michel <michel@rami.io>
The 'offsetting' payment method includes a clear description specifying
which order the offsetting applies to, but the associated refund does
not. This commit ensures refunds use the same message as payments,
making the associated order explicit.
* Show links to plugin views and settings in plugin list and in success message after activating a plugin
* Fix menu highlighting in payment provider settings
* Specify settings_links and navigation_links for built-in plugins
* Add link to payment plugins from payment settings
* Add client-side search and "View only active plugins" for plugins page
* PDF editor: Allow Alt+Arrow for small adjustments (Z#23186382)
* Update src/pretix/static/pretixcontrol/js/ui/editor.js
Co-authored-by: Richard Schreiber <schreiber@rami.io>
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Fix Exception when displaying mail_history
Log entries of type pretix.plugins.banktransfer.order.email.invoice had type(invoices) == int instead of list
* Update src/pretix/control/views/orders.py
Co-authored-by: Richard Schreiber <schreiber@rami.io>
---------
Co-authored-by: Raphael Michel <michel@rami.io>
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* SMTP config: Do not accept non-ASCII passwords
Python's SMTP implementation can't seem to handle non-ascii passwords,
so let's not let people enter them.
* Update src/pretix/control/forms/mailsetup.py
Co-authored-by: Mira <weller@rami.io>
---------
Co-authored-by: Mira <weller@rami.io>
* Pass widget_data to new tab even if 3rd-party cookies are disabled (Z#23176995)
* Perform cookie check earlier
* Deduplicate redirect code
* Don't forget the subevent id
* We still need to pass thru the widget_data parameter
because for an empty cart, take_cart_id will do nothing.
* pass through "consent" as GET-param as well
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* API: Allow to add a fee to an order (#4806)
* Fix example in docs
* Consistent order of examples
* Add create_fees to example
* docs: None -> null
* docs: update fee_type options
---------
Co-authored-by: Mira Weller <weller@rami.io>
* Allow ticket QR code colour to be configured
This commit introduces a feature enabling users to customise the QR
code colour in the ticket editor.
* Remove redundant argument from `Dict.get` call
Co-authored-by: Raphael Michel <mail@raphaelmichel.de>
---------
Co-authored-by: Raphael Michel <mail@raphaelmichel.de>
* Prioritize widget-provided cookie consent information over localStorage
* Hide cookie-consent-reopen link if external consent info from widget present
* Do not apply vouchers on "free price" items where more than minimum price is selected
* Do apply vouchers on "free price" items if exactly the minimum price is selected
* Update cart.py
* Add test cases, fix bug in adjacent test
* Fix code style
---------
Co-authored-by: Raphael Michel <michel@rami.io>
* Allow plugins to add data to the order API (Z#23179688)
* Update src/pretix/api/serializers/media.py
Co-authored-by: Richard Schreiber <schreiber@rami.io>
* Fix failing test
---------
Co-authored-by: Richard Schreiber <schreiber@rami.io>
When dates are ambiguous, use the event's locale to infer whether the
day or month comes first. Since regions follow certain date format
conventions, this helps make more accurate guesses.
- Fix link in pretix.event.order.changed.split
- Add link to existing order in pretix.event.order.changed.split_from
- Fix display of checkin entries without datetime in data
- Add additional info for admins (action type, linked content object)
2025-02-07 11:53:17 +01:00
1366 changed files with 561403 additions and 351403 deletions
"message": "Hey there! :) Thank you very much for offering a contribution to pretix! For legal reasons, we need you to sign a Contributor License Agreement in order to be able to merge the code. Sorry for the hassle :( Please download the agreement from https://pretix.eu/about/en/cla and send a signed copy to support@pretix.eu. Feel free to also contact us there or via comments here if you have any questions!",
"message": "Hey there! :) Thank you very much for offering a contribution to pretix! For legal reasons, we need you to sign a Contributor License Agreement in order to be able to merge the code. Sorry for the hassle :( Please download the agreement from https://pretix.eu/about/en/cla and send a signed copy to support@pretix.eu. Feel free to also contact us there or via comments here if you have any questions!\n\nFeel free to ignore me on documentation changes, translations, and trivial PRs like typo fixes (and similar single-line changes) – we can merge these without a CLA as well.",
* We've got a contributors guide in [our documentation](https://docs.pretix.eu/en/latest/development/contribution/) together with notes on the [development setup](https://docs.pretix.eu/en/latest/development/setup.html).
* We've got a contributors guide in [our documentation](https://docs.pretix.eu/dev/development/contribution/) together with notes on the [development setup](https://docs.pretix.eu/dev/development/setup.html).
* Please note that we have a [Code of Conduct](https://docs.pretix.eu/en/latest/development/contribution/codeofconduct.html) in place that applies to all project contributions, including issues, pull requests, etc.
* Please note that we have a [Code of Conduct](https://docs.pretix.eu/dev/development/contribution/codeofconduct.html) in place that applies to all project contributions, including issues, pull requests, etc.
* Before we can accept a PR from you we'll need you to sign [our CLA](https://pretix.eu/about/en/cla). You can find more information about the how and why in our [License FAQ](https://docs.pretix.eu/en/latest/license/faq.html#) and in our [license change blog post](https://pretix.eu/about/en/blog/20210412-license/).
* Before we can accept a PR from you we'll need you to sign [our CLA](https://pretix.eu/about/en/cla). You can find more information about the how and why in our [License FAQ](https://docs.pretix.eu/trust/licensing/faq/) and in our [license change blog post](https://pretix.eu/about/en/blog/20210412-license/).
If you discover a vulnerability with our software or server systems, please report it to us in private. Do not to attempt to harm our users, customer's data or our system's availability when looking for vulneratbilities.
If you discover a vulnerability with our software or server systems, please report it to us in private. Do not to attempt to harm our users, customer's data or our system's availability when looking for vulnerabilities.
Please contact us at security@pretix.eu with full details and steps to reproduce and allow reasonable time for us to resolve the issue before publishing your findings. If you wish to encrypt your email, you can find our GPG key [here](https://pretix.eu/.well-known/security@pretix.eu.asc).
We're not large enough to run a formal bug bounty program, but if you find a serious vulnerability in our service, we will find a way to show our gratitude.
Please also see our [Responsible disclosure policy](https://docs.pretix.eu/trust/security/disclosure/).
## Version support
@@ -18,3 +18,5 @@ subscribe to our [newsletter](https://pretix.eu/about/en/blog/) in the "News abo
category, we will also send you an email on security issues.
Past security issues are listed [on our website](https://pretix.eu/about/en/security).
Please also see our [Release cycle](https://docs.pretix.eu/trust/lifecycle/release-cycle/) documentation.
The name of this installation. Default: ``pretix.de``
``url``
The installation's full URL, without a trailing slash.
``currency``
The default currency as a three-letter code. Defaults to ``EUR``.
``cachedir``
The local path to a directory where temporary files will be stored.
Defaults to the ``cache`` directory below the ``datadir``.
``datadir``
The local path to a data directory that will be used for storing user uploads and similar
data. Defaults to the value of the environment variable ``DATA_DIR`` or ``data``.
``logdir``
The local path to a directory where log files will be stored.
Defaults to the ``logs`` directory below the ``datadir``.
``plugins_default``
A comma-separated list of plugins that are enabled by default for all new events.
Defaults to ``pretix.plugins.sendmail,pretix.plugins.statistics``.
``plugins_exclude``
A comma-separated list of plugins that are not available even though they are installed.
Defaults to an empty string.
``plugins_show_meta``
Whether to show authors and versions of plugins, defaults to ``on``.
``auth_backends``
A comma-separated list of available auth backends. Defaults to ``pretix.base.auth.NativeAuthBackend``.
``registration``
Enables or disables the registration of new admin users. Defaults to ``off``.
``password_reset``
Enables or disables password reset. Defaults to ``on``.
``long_sessions``
Enables or disables the "keep me logged in" button. Defaults to ``on``.
``ecb_rates``
By default, pretix periodically downloads currency rates from the European Central Bank as well as other authorities
that are used to print tax amounts in the customer currency on invoices for some currencies. Set to ``off`` to
disable this feature. Defaults to ``on``.
``audit_comments``
Enables or disables nagging staff users for leaving comments on their sessions for auditability.
Defaults to ``off``.
``obligatory_2fa``
Enables or disables obligatory usage of two-factor authentication for users of the pretix backend.
Can be ``True`` to make two-factor authentication obligatory for all users or ``staff`` to make it only
obligatory to users with admin permissions. Defaults to ``False``.
``trust_x_forwarded_for``
Specifies whether the ``X-Forwarded-For`` header can be trusted. Only set to ``on`` if you have a reverse
proxy that actively removes and re-adds the header to make sure the correct client IP is the first value.
Defaults to ``off``.
``trust_x_forwarded_proto``
Specifies whether the ``X-Forwarded-Proto`` header can be trusted. Only set to ``on`` if you have a reverse
proxy that actively removes and re-adds the header to make sure the correct value is set.
Defaults to ``off``.
``trust_x_forwarded_host``
Specifies whether the ``X-Forwarded-Host`` header can be trusted. Only set to ``on`` if you have a reverse
proxy that actively removes and re-adds the header to make sure the correct value is set.
Defaults to ``off``.
``csp_log``
Log violations of the Content Security Policy (CSP). Defaults to ``on``.
``csp_additional_header``
Specifies a CSP header that will be **merged** with pretix's default header. For example, if you set this
to ``script-src https://mycdn.com``, pretix will add ``https://mycdn.com`` as an **additional** allowed source
to all CSP headers. Empty by default.
``loglevel``
Set console and file log level (``DEBUG``, ``INFO``, ``WARNING``, ``ERROR`` or ``CRITICAL``). Defaults to ``INFO``.
``request_id_header``
Specifies the name of a header that should be used for logging request IDs. Off by default.
Locale settings
---------------
Example::
[locale]
default=de
timezone=Europe/Berlin
``default``
The system's default locale. Default: ``en``
``timezone``
The system's default timezone as a ``pytz`` name. Default: ``UTC``
Database settings
-----------------
Example::
[database]
backend=postgresql
name=pretix
user=pretix
password=abcd
host=localhost
port=3306
advisory_lock_index=1
disable_server_side_cursors=0
sslmode=require
sslrootcert=/etc/pretix/postgresql-ca.crt
sslcert=/etc/pretix/postgresql-client-crt.crt
sslkey=/etc/pretix/postgresql-client-key.key
``backend``
One of ``sqlite3`` and ``postgresql``.
Default: ``sqlite3``.
``name``
The database's name. Default: ``db.sqlite3``.
``user``, ``password``, ``host``, ``port``
Connection details for the database connection. Empty by default.
``advisory_lock_index``
On PostgreSQL, pretix uses the "advisory lock" feature. However, advisory locks use a server-wide name space and
and are not scoped to a specific database. If you run multiple pretix applications with the same PostgreSQL server,
you should set separate values for this setting (integers up to 256).
``disable_server_side_cursors``
On PostgreSQL pretix might use server side cursors for certain operations. This is generally fine but will break in
specific circumstances, for example when connecting to PostgreSQL through a PGBouncer configured with a transaction
pool mode. Off by default (i.e. by default server side cursors will be used).
``sslmode``, ``sslrootcert``
Connection TLS details for the PostgreSQL database connection. Possible values of ``sslmode`` are ``disable``, ``allow``, ``prefer``, ``require``, ``verify-ca``, and ``verify-full``. ``sslrootcert`` should be the accessible path of the ca certificate. Both values are empty by default.
``sslcert``, ``sslkey``
Connection mTLS details for the PostgreSQL database connection. It's also necessary to specify ``sslmode`` and ``sslrootcert`` parameters, please check the correct values from the TLS part. ``sslcert`` should be the accessible path of the client certificate. ``sslkey`` should be the accessible path of the client key. All values are empty by default.
.._`config-replica`:
Database replica settings
-------------------------
If you use a replicated database setup, pretix expects that the default database connection always points to the primary database node.
Routing read queries to a replica on database layer is **strongly** discouraged since this can lead to inaccurate such as more tickets
being sold than are actually available.
However, pretix can still make use of a database replica to keep some expensive queries with that can tolerate some latency from your
primary database, such as backend search queries. The ``replica`` configuration section can have the same settings as the ``database``
section (except for the ``backend`` setting) and will default back to the ``database`` settings for all values that are not given. This
way, you just need to specify the settings that are different for the replica.
Example::
[replica]
host=192.168.0.2
.._`config-urls`:
URLs
----
Example::
[urls]
media=/media/
static=/static/
``media``
The URL to be used to serve user-uploaded content. You should not need to modify
this. Default: ``/media/``
``static``
The URL to be used to serve static files. You should not need to modify
this. Default: ``/static/``
.._`mail-settings`:
Email
-----
Example::
[mail]
from=hello@localhost
host=127.0.0.71
user=pretix
password=foobar
port=1025
tls=on
ssl=off
``host``, ``port``
The SMTP Host to connect to. Defaults to ``localhost`` and ``25``.
``user``, ``password``
The SMTP user data to use for the connection. Empty by default.
``tls``, ``ssl``
Use STARTTLS or SSL for the SMTP connection. Off by default.
``from``
The email address to set as ``From`` header in outgoing emails by the system.
Default: ``pretix@localhost``
``from_notifications``
The email address to set as ``From`` header in admin notification emails by the system.
Defaults to the value of ``from``.
``from_organizers``
The email address to set as ``From`` header in outgoing emails by the system sent on behalf of organizers.
Defaults to the value of ``from``.
``custom_sender_verification_required``
If this is on (the default), organizers need to verify email addresses they want to use as senders in their event.
``custom_sender_spf_string``
If this is set to a valid SPF string, pretix will show a warning if organizers use a sender address from a domain
that does not include this value.
``custom_smtp_allow_private_networks``
If this is off (the default), custom SMTP servers cannot be private network addresses.
``admins``
Comma-separated list of email addresses that should receive a report about every error code 500 thrown by pretix.
The secret to be used by Django for signing and verification purposes. If this
setting is not provided, pretix will generate a random secret on the first start
and will store it in the filesystem for later usage.
``secret_fallback0`` ... ``secret_fallback9``
Prior versions of the secret to be used by Django for signing and verification purposes that will still
be accepted but no longer be used for new signing.
``debug``
Whether or not to run in debug mode. Default is ``False``.
..WARNING:: Never set this to ``True`` in production!
``passwords_argon``
Use the ``argon2`` algorithm for password hashing. Disable on systems with a small number of CPU cores (currently
less than 8).
``profile``
Enable code profiling for a random subset of requests. Disabled by default, see
:ref:`perf-monitoring` for details.
.._`metrics-settings`:
Metrics
-------
If you want to fetch internally collected prometheus-style metrics you need to configure the credentials for the
metrics endpoint and enable it::
[metrics]
enabled=true
user=your_user
passphrase=mysupersecretpassphrase
Currently, metrics-collection requires a redis server to be available.
Memcached
---------
You can use an existing memcached server as pretix's caching backend::
[memcached]
location=127.0.0.1:11211
``location``
The location of memcached, either a host:port combination or a socket file.
If no memcached is configured, pretix will use redis for caching. If neither is configured, pretix will not use any caching.
..note:: If you use memcached and you deploy pretix across multiple servers, you should use *one*
shared memcached instance, not multiple ones, because cache invalidations would not be
propagated otherwise.
Redis
-----
If a redis server is configured, pretix can use it for locking, caching and session storage
to speed up various operations::
[redis]
location=redis://127.0.0.1:6379/1
sessions=false
sentinels=[
["sentinel_host_1", 26379],
["sentinel_host_2", 26379],
["sentinel_host_3", 26379]
]
password=password
ssl_cert_reqs=required
ssl_ca_certs=/etc/pretix/redis-ca.pem
ssl_keyfile=/etc/pretix/redis-client-crt.pem
ssl_certfile=/etc/pretix/redis-client-key.key
``location``
The location of redis, as a URL of the form ``redis://[:password]@localhost:6379/0``
or ``unix://[:password]@/path/to/socket.sock?db=0``
``sessions``
When this is set to ``True``, redis will be used as the session storage.
``sentinels``
Configures redis sentinels to use.
If you don't want to use redis sentinels, you should omit this option.
If this is set, redis via sentinels will be used instead of plain redis.
In this case the location should be of the form ``redis://my_master/0``.
The ``sentinels`` variable should be a json serialized list of sentinels,
each being a list with the two elements hostname and port.
You cannot provide a password within the location when using sentinels.
Note that the configuration format requires you to either place the entire
value on one line or make sure all values are indented by at least one space.
``password``
If your redis setup doesn't require a password or you already specified it in the location you can omit this option.
If this is set it will be passed to redis as the connection option PASSWORD.
``ssl_cert_reqs``
If this is set it will be passed to redis as the connection option ``SSL_CERT_REQS``.
Possible values are ``none``, ``optional``, and ``required``.
``ssl_ca_certs``
If your redis setup doesn't require TLS you can omit this option.
If this is set it will be passed to redis as the connection option ``SSL_CA_CERTS``. Possible value is the ca path.
``ssl_keyfile``
If your redis setup doesn't require mTLS you can omit this option.
If this is set it will be passed to redis as the connection option ``SSL_KEYFILE``. Possible value is the keyfile path.
``ssl_certfile``
If your redis setup doesn't require mTLS you can omit this option.
If this is set it will be passed to redis as the connection option ``SSL_CERTFILE``. Possible value is the certfile path.
If redis is not configured, pretix will store sessions and locks in the database. If memcached
is configured, memcached will be used for caching instead of redis.
Translations
------------
pretix comes with a number of translations. All languages are enabled by default. If you want to limit
the languages available in your installation, you can enable a set of languages like this::
[languages]
enabled=en,de
Some of the languages them are marked as "incubating", which means
they can usually only be selected in development mode. If you want to use them nevertheless, you
can activate them like this::
[languages]
allow_incubating=pt-br,da
You can also tell pretix about additional paths where it will search for translations::
[languages]
path=/path/to/my/translations
For a given language (e.g. ``pt-br``), pretix will then look in the
specific sub-folder, e.g. ``/path/to/my/translations/pt_BR/LC_MESSAGES/django.po``.
Celery task queue
-----------------
For processing long-running tasks asynchronously, pretix requires the celery task queue.
For communication between the web server and the task workers in both direction, a messaging
queue and a result backend is needed. You can use a redis database for both directions, or
an AMQP server (e.g. RabbitMQ) as a broker and redis or your database as a result backend::
[celery]
broker=amqp://guest:guest@localhost:5672//
backend=redis://localhost/0
broker_transport_options="{}"
backend_transport_options="{}"
RabbitMQ might be the better choice if you have a complex, multi-server, high-performance setup,
but as you already should have a redis instance ready for session and lock storage, we recommend
redis for convenience. See the `Celery documentation`_ for more details.
The two ``transport_options`` entries can be omitted in most cases.
If they are present they need to be a valid JSON dictionary.
For possible entries in that dictionary see the `Celery documentation`_.
It is possible the use Redis with TLS/mTLS for the broker or the backend. To do so, it is necessary to specify the TLS identifier ``rediss``, the ssl mode ``ssl_cert_reqs`` and optionally specify the CA (TLS) ``ssl_ca_certs``, cert ``ssl_certfile`` and key ``ssl_keyfile`` (mTLS) path as encoded string. the following uri describes the format and possible parameters ``rediss://0.0.0.0:6379/1?ssl_cert_reqs=required&ssl_ca_certs=%2Fetc%2Fpretix%2Fredis-ca.pem&ssl_certfile=%2Fetc%2Fpretix%2Fredis-client-crt.pem&ssl_keyfile=%2Fetc%2Fpretix%2Fredis-client-key.key``
To use redis with sentinels set the broker or backend to ``sentinel://sentinel_host_1:26379;sentinel_host_2:26379/0``
and the respective transport_options to ``{"master_name":"mymaster"}``.
If your redis instances behind the sentinel have a password use ``sentinel://:my_password@sentinel_host_1:26379;sentinel_host_2:26379/0``.
If your redis sentinels themselves have a password set the transport_options to ``{"master_name":"mymaster","sentinel_kwargs":{"password":"my_password"}}``.
Sentry
------
pretix has native support for sentry, a tool that you can use to track errors in the
application. If you want to use sentry, you need to set a DSN in the configuration file::
[sentry]
dsn=https://<key>:<secret>@sentry.io/<project>
traces_sample_rate=0.5
traces_sample_token=xyz
``dsn``
You will be given this value by your sentry installation.
``traces_sample_rate``
Sample rate for performance monitoring.
``traces_sample_token``
If this token is found in a query string, a trace will always be sampled.
Caching
-------
You can adjust some caching settings to control how much storage pretix uses::
[cache]
tickets=48 ; Number of hours tickets (PDF, passbook, …) are cached
Secret length
-------------
If you are really paranoid, you can increase the length of random strings pretix uses in
various places like order codes, secrets in the ticket QR codes, etc. Example::
[entropy]
; Order code needs to be < 16 characters, default is 5
order_code=5
; Ticket secret needs to be < 64 characters, default is 32
ticket_secret=32
; Voucher code needs to be < 255 characters, default is 16
voucher_code=16
External tools
--------------
pretix can make use of some external tools if they are installed. Currently, they are all optional. Example::
..warning:: The guides are maintained by the community and not by the pretix core team. If you encounter any issues with the guides, please report them to the maintainers of the guides. The pretix core team can not provide support for installs using these guides.
Kubernetes
----------
- Helm Chart by techwolf12 - A Helm chart for deploying pretix on Kubernetes. The chart documentation is available on `ArtifactHub <https://artifacthub.io/packages/helm/techwolf12/pretix>`_ and the source code is available on `GitHub <https://github.com/Techwolf12/charts/tree/main/pretix-helm>`_.
Docker
------
- `docker compose setup <https://github.com/ZPascal/pretix-docker-compose>`_ by ZPascal
This guide describes the installation of a small-scale installation of pretix using docker. By small-scale, we mean
that everything is being run on one host and you don't expect thousands of participants trying to get a ticket within
a few minutes. In this setup, as many parts of pretix as possible are hidden away in one single docker container.
This has some trade-offs in terms of performance and isolation but allows a rather easy installation.
..warning:: Even though we try to make it straightforward to run pretix, it still requires some Linux experience to
get it right. If you're not feeling comfortable managing a Linux server, check out our hosting and service
offers at `pretix.eu`_.
We tested this guide on the Linux distribution **Debian 11.0** but it should work very similar on other
modern distributions, especially on all systemd-based ones.
Requirements
------------
Please set up the following systems beforehand, we'll not explain them here (but see these links for external
installation guides):
*`Docker`_
* A SMTP server to send out mails, e.g. `Postfix`_ on your machine or some third-party server you have credentials for
* A HTTP reverse proxy, e.g. `nginx`_ or Apache to allow HTTPS connections
* A `PostgreSQL`_ 12+ database server
* A `redis`_ server
We also recommend that you use a firewall, although this is not a pretix-specific recommendation. If you're new to
Linux and firewalls, we recommend that you start with `ufw`_.
..note:: Please, do not run pretix without HTTPS encryption. You'll handle user data and thanks to `Let's Encrypt`_
SSL certificates can be obtained for free these days. We also *do not* provide support for HTTP-only
installations except for evaluation purposes.
..warning:: By default, using `ufw` in conjunction will not have any effect. Please make sure to either bind the exposed
ports of your docker container explicitly to 127.0.0.1 or configure docker to respect any set up firewall
rules.
On this guide
-------------
All code lines prepended with a ``#`` symbol are commands that you need to execute on your server as ``root`` user;
all lines prepended with a ``$`` symbol can also be run by an unprivileged user.
Data files
----------
First of all, you need to create a directory on your server that pretix can use to store data files and make that
directory writable to the user that runs pretix inside the docker container::
# mkdir /var/pretix-data
# chown -R 15371:15371 /var/pretix-data
Database
--------
Next, we need a database and a database user. We can create these with any kind of database managing tool or directly on
our database's shell. Please make sure that UTF8 is used as encoding for the best compatibility. You can check this with
the following command::
# sudo -u postgres psql -c 'SHOW SERVER_ENCODING'
For PostgreSQL database creation, we would do::
# sudo -u postgres createuser -P pretix
# sudo -u postgres createdb -O pretix pretix
Make sure that your database listens on the network. If PostgreSQL on the same same host as docker, but not inside a docker container, we recommend that you just listen on the Docker interface by changing the following line in ``/etc/postgresql/<version>/main/postgresql.conf``::
listen_addresses = 'localhost,172.17.0.1'
You also need to add a new line to ``/etc/postgresql/<version>/main/pg_hba.conf`` to allow network connections to this user and database::
host pretix pretix 172.17.0.1/16 md5
Restart PostgreSQL after you changed these files::
# systemctl restart postgresql
If you have a firewall running, you should also make sure that port 5432 is reachable from the ``172.17.0.1/16`` subnet.
Redis
-----
For caching and messaging in small-scale setups, pretix recommends using redis. In this small-scale setup we assume a
redis instance to be running on the same host. To avoid the hassle with network configurations and firewalls, we
recommend connecting to redis via a unix socket. To enable redis on unix sockets, add the following to your
``/etc/redis/redis.conf``::
unixsocket /var/run/redis/redis.sock
unixsocketperm 777
Now restart redis-server::
# systemctl restart redis-server
In this setup, systemd will delete ``/var/run/redis`` on every redis restart, which will cause issues with pretix. To
prevent this, you can execute::
# systemctl edit redis-server
And insert the following::
[Service]
# Keep the directory around so that pretix.service in docker does not need to be
# restarted when redis is restarted.
RuntimeDirectoryPreserve=yes
..warning:: Setting the socket permissions to 777 is a possible security problem. If you have untrusted users on your
system or have high security requirements, please don't do this and let redis listen to a TCP socket
instead. We recommend the socket approach because the TCP socket in combination with docker's networking
can easily become an even worse security hole when configured slightly wrong. Read more about security
on the `redis website`_.
Another possible solution is to run `redis in docker`_ and link the containers using docker's networking
features.
Config file
-----------
We now create a config directory and config file for pretix::
# mkdir /etc/pretix
# touch /etc/pretix/pretix.cfg
# chown -R 15371:15371 /etc/pretix/
# chmod 0700 /etc/pretix/pretix.cfg
Fill the configuration file ``/etc/pretix/pretix.cfg`` with the following content (adjusted to your environment)::
[pretix]
instance_name=My pretix installation
url=https://pretix.mydomain.com
currency=EUR
; DO NOT change the following value, it has to be set to the location of the
; directory *inside* the docker container
datadir=/data
trust_x_forwarded_for=on
trust_x_forwarded_proto=on
[database]
backend=postgresql
name=pretix
user=pretix
; Replace with the password you chose above
password=*********
; In most docker setups, 172.17.0.1 is the address of the docker host. Adjust
; this to wherever your database is running, e.g. the name of a linked container.
host=172.17.0.1
[mail]
; See config file documentation for more options
from=tickets@yourdomain.com
; This is the default IP address of your docker host in docker's virtual
; network. Make sure postfix listens on this address.
host=172.17.0.1
[redis]
location=unix:///var/run/redis/redis.sock?db=0
; Remove the following line if you are unsure about your redis' security
Our recommended database for all production installations is PostgreSQL. Support for MySQL/MariaDB has been removed
in newer pretix releases.
In order to follow this guide, your pretix installation needs to be a version that fully supports MySQL/MariaDB. If you
already upgraded to pretix 5.0 or later, downgrade back to the last 4.x release using ``pip``.
..note:: We have tested this guide carefully, but we can't assume any liability for its correctness. The data loss
risk should be low as long as pretix is not running while you do the migration. If you are a pretix Enterprise
customer, feel free to reach out in advance if you want us to support you along the way.
Update database schema
----------------------
Before you start, make sure your database schema is up to date. With a local installation::
# sudo -u pretix -s
$ source /var/pretix/venv/bin/activate
(venv)$ python -m pretix migrate
With a docker installation::
docker exec -it pretix.service pretix migrate
Install PostgreSQL
------------------
Now, install and set up a PostgreSQL server. For a local installation on Debian or Ubuntu, use::
# apt install postgresql
Having the database server installed, we still need a database and a database user. We can create these with any kind
of database managing tool or directly on our database's shell. Please make sure that UTF8 is used as encoding for the
best compatibility. You can check this with the following command::
# sudo -u postgres psql -c 'SHOW SERVER_ENCODING'
Without Docker
""""""""""""""
For our standard manual installation, create the database and user like this::
# sudo -u postgres createuser pretix
# sudo -u postgres createdb -O pretix pretix
With Docker
"""""""""""
For our standard docker installation, create the database and user like this::
# sudo -u postgres createuser -P pretix
# sudo -u postgres createdb -O pretix pretix
Make sure that your database listens on the network. If PostgreSQL on the same same host as docker, but not inside a docker container, we recommend that you listen on the Docker interface by changing the following line in ``/etc/postgresql/<version>/main/postgresql.conf``::
listen_addresses = 'localhost,172.17.0.1'
You also need to add a new line to ``/etc/postgresql/<version>/main/pg_hba.conf`` to allow network connections to this user and database::
host pretix pretix 172.17.0.1/16 md5
Restart PostgreSQL after you changed these files::
# systemctl restart postgresql
If you have a firewall running, you should also make sure that port 5432 is reachable from the ``172.17.0.1/16`` subnet.
Of course, instead of all this you can also run a PostgreSQL docker container and link it to the pretix container.
Stop pretix
-----------
To prevent any more changes to your data, stop pretix from running. With a local installation::
# systemctl stop pretix-web pretix-worker
With docker::
# systemctl stop pretix
Change configuration
--------------------
Change the database configuration in your ``/etc/pretix/pretix.cfg`` file::
[database]
backend=postgresql
name=pretix
user=pretix
password= ; only required for docker or remote database, can be kept empty for local auth
host= ; set to 172.17.0.1 in docker setup, keep empty for local auth
Create database schema
-----------------------
To create the schema in your new PostgreSQL database, use the following commands. With a local installation::
If you are using Ubuntu 20.04, the ``pgloader`` version from the repositories seems to be incompatible with PostgreSQL
12+. You can install ``pgloader`` from the `PostgreSQL repositories`_ instead.
See also `this discussion <https://github.com/pretix/pretix/issues/3090>`_.
Create a new file ``/tmp/pretix.load``, replacing the MySQL and PostgreSQL connection strings with the correct user names, passwords, and/or database names::
LOAD DATABASE
FROM mysql://pretix:password@localhost/pretix -- replace with mysql://username:password@hostname/dbname
INTO postgresql:///pretix -- replace with dbname
WITH data only, include no drop, truncate, disable triggers,
create no indexes, drop indexes, reset sequences
ALTER SCHEMA 'pretix' RENAME TO 'public' -- replace pretix with the name of the MySQL database
ALTER TABLE NAMES MATCHING ~/.*/
SET SCHEMA 'public'
SET timezone TO '+00:00'
SET PostgreSQL PARAMETERS
maintenance_work_mem to '128MB',
work_mem to '12MB';
Then, run::
# sudo -u postgres pgloader /tmp/pretix.load
The output should end with a table summarizing the results for every table. You can ignore warnings about type casts
and missing constraints.
Afterwards, delete the file again::
# rm -rf /tmp/pretix.load
Start pretix
------------
Stop your MySQL server as a verification step that you are no longer using it::
# systemctl stop mariadb
Then, restart pretix. With a local installation::
# systemctl start pretix-web pretix-worker
With a docker installation::
# systemctl start pretix
And you're done! After you've verified everything has been copied correctly, you can delete the old MySQL database.
..note:: Don't forget to update your backup process to back up your PostgreSQL database instead of your MySQL database now.
Troubleshooting
---------------
Peer authentication failed
""""""""""""""""""""""""""
Sometimes you might see an error message like this::
django.db.utils.OperationalError: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL: Peer authentication failed for user "pretix"
It is important to understand that PostgreSQL by default offers two types of authentication:
-**Peer authentication**, which works automatically based on the Linux user you are working as. This requires that
the connection is made through a local socket (empty ``host=`` in ``pretix.cfg``) and the name of the PostgreSQL user
and the Linux user are identical.
- Typically, you might run into this error if you accidentally execute ``python -m pretix`` commands as root instead
of the ``pretix`` user.
-**Password authentication**, which requires a username and password and works over network connections. To force
password authentication instead of peer authentication, set ``host=127.0.0.1`` in ``pretix.cfg``.
- You can alter the password on a PostgreSQL shell using the command ``ALTER USER pretix WITH PASSWORD '***';``.
When creating a user with the ``createuser`` command, pass option ``-P`` to set a new password.
- Even with password authentication, PostgreSQL by default only allows local connections. To allow remote connections,
you need to adjust both the ``listen_address`` configuration parameter as well as the ``pg_hba.conf`` file (see above
for an example with the docker networking setup).
Database error: relation does not exist
"""""""""""""""""""""""""""""""""""""""
If you see an error like this::
2023-04-17T19:20:47.744023Z ERROR Database error 42P01: relation "public.pretix_foobar" does not exist
QUERY: ALTER TABLE public.pretix_foobar DROP CONSTRAINT IF EXISTS pretix_foobar_order_id_57e2cb41_fk_pretixbas CASCADE;
2023-04-17T19:20:47.744023Z FATAL Failed to create the schema, see above.
The reason is most likely that in the past, you installed a pretix plugin that you no longer have installed. However,
the database still contains tables of that plugin. If you want to keep the data, reinstall the plugin and re-run the
``migrate`` step from above. If you want to get rid of the data, manually drop the table mentioned in the error message
from your MySQL database::
# mysql -u root pretix
mysql> DROP TABLE pretix_foobar;
Then, retry. You might see a new error message with a new table, which you can handle the same way.
Cleaning out a failed attempt
"""""""""""""""""""""""""""""
You might want to clean your PostgreSQL database before you try again after an error. You can do so like this::
# sudo -u postgres psql pretix
pretix=# DROP SCHEMA public CASCADE;
pretix=# CREATE SCHEMA public;
pretix=# ALTER SCHEMA public OWNER TO pretix;
``pgloader`` crashes with heap exhaustion error
"""""""""""""""""""""""""""""""""""""""""""""""
On some larger databases, we've seen ``pgloader`` crash with error messages similar to this::
Heap exhausted during garbage collection: 16 bytes available, 48 requested.
Or this::
2021-01-04T21:31:17.367000Z ERROR A SB-KERNEL::HEAP-EXHAUSTED-ERROR condition without bindings for heap statistics. (If
you did not expect to see this message, please report it.
2021-01-04T21:31:17.382000Z ERROR The value
NIL
is not of type
NUMBER
when binding SB-KERNEL::X
The ``pgloader`` version distributed for Debian and Ubuntu is compiled with the ``SBCL`` compiler. If compiled with
``CCL``, these bugs go away. Unfortunately, it is pretty hard to compile ``pgloader`` manually with ``CCL``. If you
run into this, we therefore recommend using the docker container provided by the ``pgloader`` maintainers::
Our :ref:`installation guide <installation>` only covers "small-scale" setups, by which we mostly mean
setups that run on a **single (virtual) machine** and do not encounter large traffic peaks.
We do not offer an installation guide for larger-scale setups of pretix, mostly because we believe that
there is no one-size-fits-all solution for this and the desired setup highly depends on your use case,
the platform you run pretix on, and your technical capabilities. We do not recommend trying set up pretix
in a multi-server environment if you do not already have experience with managing server clusters.
This document is intended to give you a general idea on what issues you will encounter when you scale up
and what you should think of.
..tip::
If you require more help on this, we're happy to help. Our pretix Enterprise support team has built
and helped building, scaling and load-testing pretix installations at any scale and we're looking
forward to work with you on fine-tuning your system. If you intend to sell **more than a thousand
tickets in a very short amount of time**, we highly recommend reaching out and at least talking this
through. Just get in touch at sales@pretix.eu!
Scaling reasons
---------------
There are two main reasons for scaling up a pretix installation beyond a single server:
***Availability:** Distributing pretix over multiple servers can allow you to survive failure of one or more single machines, leading to a higher uptime and reliability of your system.
***Traffic and throughput:** Distributing pretix over multiple servers can allow you to process more web requests and ticket sales at the same time.
You are very unlikely to require scaling for other reasons, such as having too much data in your database.
Components
----------
A pretix installation usually consists of the following components which run performance-relevant processes:
*``pretix-web`` is the Django-based web application that serves all user interaction.
*``pretix-worker`` is a Celery-based application that processes tasks that should be run asynchronously outside of the web application process.
* A **PostgreSQL database** keeps all the important data and processes the actual transactions.
* A **web server** that terminates TLS and HTTP connections and forwards them to ``pretix-web``. In some cases, e.g. when serving static files, the web servers might return a response directly. We recommend using ``nginx``.
* A **redis** server responsible for the communication between ``pretix-web`` and ``pretix-worker``, as well as for caching.
* A directory of **media files** such as user-uploaded files or generated files (tickets, invoices, …) that are created and used by ``pretix-web``, ``pretix-worker`` and the web server.
In the following, we will discuss the scaling behavior of every component individually. In general, you can run all of the components
on the same server, but you can just as well distribute every component to its own server, or even use multiple servers for some single
components.
..warning::
When setting up your system, don't forget about security. In a multi-server environment,
you need to take special care to ensure that no unauthorized access to your database
is possible through the network and that it's not easy to wiretap your connections. We
recommend a rigorous use of firewalls and encryption on all communications. You can
ensure this either on an application level (such as using the TLS support in your
database) or on a network level with a VPN solution.
Web server
""""""""""
Your web server is at the very front of your installation. It will need to absorb all of the traffic, and it should be able to
at least show a decent error message, even when everything else fails. Luckily, web servers are really fast these days, so this
can be achieved without too much work.
We recommend reading up on tuning your web server for high concurrency. For nginx, this means thinking about the number of worker
processes and the number of connections each worker process accepts. Double-check that TLS session caching works, because TLS
handshakes can get really expensive.
During a traffic peak, your web server will be able to make use of more CPU resources, while memory usage will stay comparatively low,
so if you invest in more hardware here, invest in more and faster CPU cores.
Make sure that pretix' static files (such as CSS and JavaScript assets) as well as user-uploaded media files (event logos, etc)
are served directly by your web server and your web server caches them in-memory (nginx does it by default) and sets useful
headers for client-side caching. As an additional performance improvement, you can turn of access logging for these types of files.
If you want, you can even farm out serving static files to a different web server entirely and :ref:`configure pretix to reference
them from a different URL <config-urls>`.
..tip::
If you expect *really high traffic* for your very popular event, you might want to do some rate limiting on this layer, or,
if you want to ensure a fair and robust first-come-first-served experience and prefer letting users wait over showing them
errors, consider a queuing solution. We're happy to provide you with such systems, just get in touch at sales@pretix.eu.
pretix-web
""""""""""
The ``pretix-web`` process does not carry any internal state and can be easily started on as many machines as you like, and you can
use the load balancing features of your frontend web server to redirect to all of them.
You can adjust the number of processes in the ``gunicorn`` command line, and we recommend choosing roughly two times the number
of CPU cores available. Under load, the memory consumption of ``pretix-web`` will stay comparatively constant, while the CPU usage
will increase a lot. Therefore, if you can add more or faster CPU cores, you will be able to serve more users.
pretix-worker
"""""""""""""
The ``pretix-worker`` process performs all operations that are not directly executed in the request-response-cycle of ``pretix-web``.
Just like ``pretix-web`` you can easily start up as many instances as you want on different machines to share the work. As long as they
all talk to the same redis server, they will all receive tasks from ``pretix-web``, work on them and post their result back.
You can configure the number of threads that run tasks in parallel through the ``--concurrency`` command line option of ``celery``.
Just like ``pretix-web``, this process is mostly heavy on CPU, disk IO and network IO, although memory peaks can occur e.g. during the
generation of large PDF files, so we recommend having some reserves here.
``pretix-worker`` performs a variety of tasks which are of different importance.
Some of them are mission-critical and need to be run quickly even during high load (such as
creating a cart or an order), others are irrelevant and can easily run later (such as
distributing tickets on the waiting list). You can fine-tune the capacity you assign to each
of these tasks by running ``pretix-worker`` processes that only work on a specific **queue**.
For example, you could have three servers dedicated only to process order creations and one
server dedicated only to sending emails. This allows you to set priorities and also protects
you from e.g. a slow email server lowering your ticket throughput.
You can do so by specifying one or more queues on the ``celery`` command line of this process, such as ``celery -A pretix.celery_app worker -Q notifications,mail``. Currently,
the following queues exist:
*``checkout`` -- This queue handles everything related to carts and orders and thereby everything required to process a sale. This includes adding and deleting items from carts as well as creating and canceling orders.
*``mail`` -- This queue handles sending of outgoing emails.
*``notifications`` -- This queue handles the processing of any outgoing notifications, such as email notifications to admin users (except for the actual sending) or API notifications to registered webhooks.
*``background`` -- This queue handles tasks that are expected to take long or have no human waiting for their result immediately, such as refreshing caches, re-generating CSS files, assigning tickets on the waiting list or parsing bank data files.
*``default`` -- This queue handles everything else with "medium" or unassigned priority, most prominently the generation of files for tickets, invoices, badges, admin exports, etc.
Media files
"""""""""""
Both ``pretix-web``, ``pretix-worker`` and in some cases your webserver need to work with
media files. Media files are all files generated *at runtime* by the software. This can
include files uploaded by the event organizers, such as the event logo, files uploaded by
ticket buyers (if you use such features) or files generated by the software, such as
ticket files, invoice PDFs, data exports or customized CSS files.
Those files are by default stored to the ``media/`` sub-folder of the data directory given
in the ``pretix.cfg`` configuration file. Inside that ``media/`` folder, you will find a
``pub/`` folder containing the subset of files that should be publicly accessible through
the web server. Everything else only needs to be accessible by ``pretix-web`` and
``pretix-worker`` themselves.
If you distribute ``pretix-web`` or ``pretix-worker`` across more than one machine, you
**must** make sure that they all have access to a shared storage to read and write these
files, otherwise you **will** run into errors with the user interface.
The easiest solution for this is probably to store them on a NFS server that you mount
on each of the other servers.
Since we use Django's file storage mechanism internally, you can in theory also use an object-storage solution like Amazon S3, Ceph, or Minio to store these files, although we currently do not expose this through pretix' configuration file and this would require you to ship your own variant of ``pretix/settings.py`` and reference it through the ``DJANGO_SETTINGS_MODULE`` environment variable.
At pretix.eu, we use a custom-built `object storage cluster`_.
SQL database
""""""""""""
One of the most critical parts of the whole setup is the SQL database -- and certainly the
hardest to scale. Tuning relational databases is an art form, and while there's lots of
material on it on the internet, there's not a single recipe that you can apply to every case.
As a general rule of thumb, the more resources you can give your databases, the better.
Most databases will happily use all CPU cores available, but only use memory up to an amount
you configure, so make sure to set this memory usage as high as you can afford. Having more
memory available allows your database to make more use of caching, which is usually good.
Scaling your database to multiple machines needs to be treated with great caution. It's a
good idea to have a replica of your database for availability reasons. In case your primary
database server fails, you can easily switch over to the replica and continue working.
However, using database replicas for performance gain is much more complicated. When using
replicated database systems, you are always trading in consistency or availability to get
additional performance and the consequences of this can be subtle. It is important
that you have a deep understanding of the semantics of your replication mechanism.
..warning::
Using an off-the-shelf database proxy solution that redirects read queries to your
replicas and write queries to your primary database **will lead to very nasty bugs.**
As an example, if you buy a ticket, pretix first needs to calculate how many tickets
are left to sell. If this calculation is done on a database replica that lags behind
even for fractions of a second, the decision to allow selling the ticket will be made
on stale data and you can end up with more tickets sold than configured. Similarly,
you could imagine situations leading to double payments etc.
If you do have a replica, you *can* tell pretix about it :ref:`in your configuration <config-replica>`.
This way, pretix can offload complex read-only queries to the replica when it is safe to do so.
As of pretix 2.7, this is mainly used for search queries in the backend and for rendering the
product list and event lists in the frontend, but we plan on expanding this in the future.
Therefore, for now our clear recommendation is: Try to scale your database vertically and put
it on the most powerful machine you have available.
redis
"""""
While redis is a very important part that glues together some of the components, it isn't used
heavily and can usually handle a fairly large pretix installation easily on a single modern
CPU core.
Having some memory available is good, e.g. if lots of tasks queue up during a traffic peak, but we wouldn't expect ever needing more than a gigabyte of it.
Feel free to set up a redis cluster for availability – but you probably won't need it for performance.
The limitations
---------------
Up to a certain point, pretix scales really well. However, there are a few things that we consider
even more important than scalability, and those are correctness and reliability. We want you to be
able to trust that pretix will not sell more tickets than you intended or run into similar error
cases.
Combined with pretix' flexibility and complexity, especially around vouchers and quotas, this creates
some hard issues. In many cases, we need to fall back to event-global locking for some actions which
are likely to run with high concurrency and cause harm.
For every event, only one of these locking actions can be run at the same time. Examples for this are
adding products limited by a quota to a cart, adding items to a cart using a voucher or placing an order
consisting of cart positions that don't have a valid reservation for much longer. In these cases, it is
currently not realistically possible to exceed selling **approx. 500 orders per minute per event**, even
if you add more hardware.
If you have an unlimited number of tickets, we can apply fewer locking and we've reached **approx.
1500 orders per minute per event** in benchmarks, although even more should be possible.
We're working on reducing the number of cases in which this is relevant and thereby improve the possible
throughput. If you want to use pretix for an event with 10,000+ tickets that are likely to be sold out
within minutes, please get in touch to discuss possible solutions. We'll work something out for you!
@@ -40,10 +40,6 @@ ignore_in_statistics boolean If ``true``, ch
consider_tickets_used boolean If ``true`` (default), tickets checked in on this list will be considered "used" by other functionality, i.e. when checking if they can still be canceled.
:param organizer:The ``slug`` field of the organizer to fetch
:param event:The ``slug`` field of the event to fetch
:param number:The ``number`` field of the invoice to transmit
:statuscode 200:no error
:statuscode 401:Authentication failure
:statuscode 403:The requested organizer/event does not exist **or** you have no permission to transmit this invoice **or** the invoice may not be transmitted
:statuscode 409:The invoice is currently in transmission
:param organizer:The ``slug`` field of the organizer to fetch
:param event:The ``slug`` field of the event to fetch
:param number:The ``number`` field of the invoice to transmit
:statuscode 200:no error
:statuscode 401:Authentication failure
:statuscode 403:The requested organizer/event does not exist **or** you have no permission to transmit this invoice **or** the invoice may not be transmitted
:statuscode 409:The invoice is currently in transmission
.._Peppol: https://en.wikipedia.org/wiki/PEPPOL
.._Sistema di Interscambio: https://it.wikipedia.org/wiki/Fattura_elettronica_in_Italia
With this API call, you can instruct the system to create a new batch.
Since batches can contain up to 10,000 tickets, they are created asynchronously on the server.
If your input parameters validate correctly, a ``202 Accepted`` status code is returned.
The body points you to the check URL of the result. Running a ``GET`` request on that result URL will
yield one of the following status codes:
*``200 OK``– The creation of the batch has succeeded. The body will be your resulting batch with the same information as in the detail endpoint above.
*``409 Conflict``– Your creation job is still running. The body will be JSON with the structure ``{"status": "running"}``. ``status`` can be ``waiting`` before the task is actually being processed. Please retry, but wait at least one second before you do.
*``410 Gone``– Creating the batch has failed permanently (e.g. quota no longer available). The body will be JSON with the structure ``{"status": "failed", "message": "Error message"}``
*``404 Not Found``– The job does not exist / is expired.
..note:: To avoid performance issues, a maximum amount of 10000 is currently allowed.
..note:: Do not wait multiple hours or more to retrieve your result. After a longer wait time, ``409`` might be returned permanently due to technical constraints, even though nothing will happen any more.
With this API call, you can render the PDF representation of a batch.
Since batches can contain up to 10,000 tickets, they are rendered asynchronously on the server.
If your input parameters validate correctly, a ``202 Accepted`` status code is returned.
The body points you to the download URL of the result. Running a ``GET`` request on that result URL will
yield one of the following status codes:
*``200 OK``– The creation of the batch has succeeded. The body will be your resulting batch with the same information as in the detail endpoint above.
*``409 Conflict``– Your rendering process is still running. The body will be JSON with the structure ``{"status": "running"}``. ``status`` can be ``waiting`` before the task is actually being processed. Please retry, but wait at least one second before you do.
*``410 Gone``– Rendering the batch has failed permanently. The body will be JSON with the structure ``{"status": "failed", "message": "Error message"}``
*``404 Not Found``– The rendering job does not exist / is expired.
Download tickets for an order, identified by its order code. Depending on the chosen output, the response might
@@ -1017,6 +1018,7 @@ Creating orders
provider will not be called to do anything about this (i.e. if you pass a bank account to a debit provider, *no*
charge will be created), this is just informative in case you *handled the payment already*.
*``payment_date`` (optional) – Date and time of the completion of the payment.
*``tax_rounding_mode`` (optional)
*``comment`` (optional)
*``custom_followup_at`` (optional)
*``checkin_attention`` (optional)
@@ -1036,8 +1038,10 @@ Creating orders
*``internal_reference``
*``vat_id``
*``vat_id_validated`` (optional) – If you need support for reverse charge (rarely the case), you need to check
yourself if the passed VAT ID is a valid EU VAT ID. In that case, set this to ``true``. Only valid VAT IDs will
trigger reverse charge taxation. Don't forget to set ``is_business`` as well!
yourself if the passed VAT ID is a valid EU VAT ID. In that case, set this to ``true``. Only valid VAT IDs will
trigger reverse charge taxation. Don't forget to set ``is_business`` as well!
*``transmission_type`` (optional, defaults to ``email``)
*``transmission_info`` (optional, see also :ref:`rest-transmission-types`)
*``positions``
@@ -1062,6 +1066,7 @@ Creating orders
*``valid_until`` (optional, if both ``valid_from`` and ``valid_until`` are **missing** (not ``null``) the availability will be computed from the given product)
*``requested_valid_from`` (optional, can be set **instead** of ``valid_from`` and ``valid_until`` to signal a user choice for the start time that may or may not be respected)
*``use_reusable_medium`` (optional, causes the new ticket to take over the given reusable medium, identified by its ID)
*``discount`` (optional, only possible if ``price`` is set; attention: if this is set to not-``null`` on any position, automatic calculation of discounts will not run)
*``answers``
*``question``
@@ -1080,9 +1085,10 @@ Creating orders
prices. Note that this will not include other fees and is calculated once during order generation and will not
be respected automatically when the order changes later.)
*``_split_taxes_like_products`` (Optional convenience flag. If set to ``true``, your ``tax_rule`` will be ignored
and the fee will be taxed like the products in the order. If the products have multiple tax rates, multiple fees
will be generated with weights adjusted to the net price of the products. Note that this will be calculated once
during order generation and is not respected automatically when the order changes later.)
and the fee will be taxed like the products in the order*unless* the total amount of the positions is zero.
If the products have multiple tax rates, multiple fees will be generated with weights adjusted to the net price
of the products. Note that this will be calculated once during order generation and is not respected automatically
when the order changes later.)
*``force`` (optional). If set to ``true``, quotas will be ignored.
*``send_email`` (optional). If set to ``true``, the same emails will be sent as for a regular order, regardless of
created datetime The creation date of the voucher. For vouchers created before pretix 2025.7.0, this is guessed retroactively and might not be accurate.
code string The voucher code that is required to redeem the voucher
max_usages integer The maximum number of times this voucher can be
redeemed (default: 1).
@@ -49,8 +50,14 @@ subevent integer ID of the date
show_hidden_items boolean Only if set to ``true``, this voucher allows to buy products with the property ``hide_without_voucher``. Defaults to ``true``.
all_addons_included boolean If set to ``true``, all add-on products for the product purchased with this voucher are included in the base price.
all_bundles_included boolean If set to ``true``, all bundled products for the product purchased with this voucher are added without their designated price.
budget money (string) The budget a voucher is allowed to consume before being used up (or ``null``)
budget_used money (string) The amount of budget the voucher has already used up.
In this algorithm, the tax value and gross total are computed from the sum of the net prices. To accomplish this within
our data model, the gross price and tax of some of the tickets will be changed by the minimum currency unit (e.g. €0.01).
The net price of the tickets always stay the same.
**This is the algorithm intended by EN 16931 invoices and our recommendation to use for e-invoicing when (primarily) business customers are involved.**
The main downside is that it might be confusing when selling to consumers, since the amounts to be paid change in unexpected ways.
For the example above, the customer expects to pay 5 times 100.00, but they are are in fact charged 499.98:
In this algorithm, the tax value and gross total are computed from the sum of the net prices. However, the net prices
of some of the tickets will be changed automatically by the minimum currency unit (e.g. €0.01) such that the resulting
gross prices stay the same.
**This is less confusing to consumers and the end result is still compliant to EN 16931, so we recommend this for e-invoicing when (primarily) consumers are involved.**
The main downside is that it might be confusing when selling to business customers, since the prices of the identical tickets appear to be different.
In pretix 2.x, we changed large parts of the payment provider API. This documentation details the changes we made
and shows you how you can make an existing pretix 1.x payment provider compatible with pretix 2.x
Conceptual overview
-------------------
In pretix 1.x, an order was always directly connected to a payment provider for the full life of an order. As long as
an order was unpaid, this could still be changed in some cases, but once an order was paid, no changes to the payment
provider were possible any more. Additionally, the internal state of orders allowed orders only to be fully paid or
not paid at all. This leads to a couple of consequences:
* Payment-related functions (like "execute payment" or "do a refund") always operated on full orders.
* Changing the total of an order was basically impossible once an order was paid, since there was no concept of
partial payments or partial refunds.
* Payment provider plugins needed to take complicated steps to detect cases that require human intervention, like e.g.
* An order has expired, no quota is left to revive it, but a payment has been received
* A payment has been received for a canceled order
* A payment has been received for an order that has already been paid with a different payment method
* An external payment service notified us of a refund/dispute
We noticed that we copied and repeated large portions of code in all our official payment provider plugins, just
to deal with some of these cases.
* Sometimes, there is the need to mark an order as refunded within pretix, without automatically triggering a refund
with an external API. Every payment method needed to implement a user interface for this independently.
* If a refund was not possible automatically, there was no way user to track which payments actually have been refunded
manually and which are still left to do.
* When the payment with one payment provider failed and the user changed to a different payment provider, all
information about the first payment was lost from the order object and could only be retrieved from order log data,
which also made it hard to design a data shredder API to get rid of this data.
In pretix 2.x, we introduced two new models, :py:class:`OrderPayment <pretix.base.models.OrderPayment>` and
:py:class:`OrderRefund <pretix.base.models.OrderRefund>`. Each instance of these is connected to an order and
represents one single attempt to pay or refund a specific amount of money. Each one of these has an individual state,
can individually fail or succeed, and carries an amount variable that can differ from the order total.
This has the following advantages:
* The system can now detect orders that are over- or underpaid, independent of the payment providers in use.
* Therefore, we can now allow partial payments, partial refunds, and changing paid orders, and automatically detect
the cases listed above and notify the user.
Payment providers now interact with those payment and refund objects more than with orders.
Your to-do list
---------------
Payment processing
""""""""""""""""""
* The method ``BasePaymentProvider.order_pending_render`` has been removed and replaced by a new
``BasePaymentProvider.payment_pending_render(request, payment)`` method that is passed an ``OrderPayment``
object instead of an ``Order``.
* The method ``BasePaymentProvider.payment_form_render`` now receives a new ``total`` parameter.
* The method ``BasePaymentProvider.payment_perform`` has been removed and replaced by a new method
``BasePaymentProvider.execute_payment(request, payment)`` that is passed an ``OrderPayment``
object instead of an ``Order``.
* The function ``pretix.base.services.mark_order_paid`` has been removed, instead call ``payment.confirm()``
on a pending ``OrderPayment`` object. If no further payments are required for this order, this will also
mark the order as paid automatically. Note that ``payment.confirm()`` can still throw a ``QuotaExceededException``,
however it will still mark the payment as complete (not the order!), so you should catch this exception and
inform the user, but not abort the transaction.
* A new property ``BasePaymentProvider.abort_pending_allowed`` has been introduced. Only if set, the user will
be able to retry a payment or switch the payment method when the order currently has a payment object in
state ``"pending"``. This replaces ``BasePaymentProvider.order_can_retry``, which no longer exists.
* The methods ``BasePaymentProvider.retry_prepare`` and ``BasePaymentProvider.order_prepare`` have both been
replaced by a new method ``BasePaymentProvider.payment_prepare(request, payment)`` that is passed an ``OrderPayment``
object instead of an ``Order``. **Keep in mind that this payment object might have an amount property that
differs from the order total, if the order is already partially paid.**
* The method ``BasePaymentProvider.order_paid_render`` has been removed.
* The method ``BasePaymentProvider.order_control_render`` has been removed and replaced by a new method
``BasePaymentProvider.payment_control_render(request, payment)`` that is passed an ``OrderPayment``
object instead of an ``Order``.
* There's no need to manually deal with excess payments or duplicate payments anymore, just setting the ``OrderPayment``
methods to the correct state will do the job.
Creating refunds
""""""""""""""""
* The methods ``BasePaymentProvider.order_control_refund_render`` and ``BasePaymentProvider.order_control_refund_perform``
have been removed.
* Two new boolean methods ``BasePaymentProvider.payment_refund_supported(payment)`` and ``BasePaymentProvider.payment_partial_refund_supported(payment)``
have been introduced. They should be set to return ``True`` if and only if the payment API allows to *automatically*
transfer the money back to the customer.
* A new method ``BasePaymentProvider.execute_refund(refund)`` has been introduced. This method is called using a
``OrderRefund`` object in ``"created"`` state and is expected to transfer the money back and confirm success with
calling ``refund.done()``. This will only ever be called if either ``BasePaymentProvider.payment_refund_supported(payment)``
or ``BasePaymentProvider.payment_partial_refund_supported(payment)`` return ``True``.
Processing external refunds
"""""""""""""""""""""""""""
* If e.g. a webhook API notifies you that a payment has been disputed or refunded with the external API, you are
expected to call ``OrderPayment.create_external_refund(self, amount, execution_date, info='{}')`` on this payment.
This will create and return an appropriate ``OrderRefund`` object and send out a notification. However, it will not
mark the order as refunded, but will ask the event organizer for a decision.
Data shredders
""""""""""""""
* The method ``BasePaymentProvider.shred_payment_info`` is no longer passed an order, but instead **either**
.._Connecting a new product to your Reservation System: https://supply.getyourguide.support/hc/en-us/articles/18008029689373-Connecting-a-new-product-to-your-Reservation-system
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
