General APIs

This page lists some general signals and hooks which do not belong to a specific type of plugin but might come in handy for various plugins.

Core

pretix.base.signals.device_info_updated = <django.dispatch.dispatcher.Signal object>

Arguments: old_device, new_device

This signal is sent out each time the information for a Device is modified. Both the original and updated versions of the Device are included to allow receivers to see what has been updated.

pretix.base.signals.email_filter = <pretix.base.signals.EventPluginSignal object>

Arguments: message, order, user

This signal allows you to implement a middleware-style filter on all outgoing emails. You are expected to return a (possibly modified) copy of the message object passed to you.

As with all event-plugin signals, the sender keyword argument will contain the event. The message argument will contain an EmailMultiAlternatives object. If the email is associated with a specific order, the order argument will be passed as well, otherwise it will be None. If the email is associated with a specific user, e.g. a notification email, the user argument will be passed as well, otherwise it will be None.

pretix.base.signals.event_copy_data = <pretix.base.signals.EventPluginSignal object>

Arguments: “other”, tax_map, category_map, item_map, question_map, variation_map, checkin_list_map, quota_map

This signal is sent out when a new event is created as a clone of an existing event, i.e. the settings from the older event are copied to the newer one. You can listen to this signal to copy data or configuration stored within your plugin’s models as well.

You don’t need to copy data inside the general settings storage which is cloned automatically, but you might need to modify that data.

The sender keyword argument will contain the event of the new event. The other keyword argument will contain the event to copy from. The keyword arguments tax_map, category_map, item_map, question_map, quota_map, variation_map and checkin_list_map contain mappings from object IDs in the original event to objects in the new event of the respective types.

pretix.base.signals.event_live_issues = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to determine whether an event can be taken live. If you want to prevent the event from going live, return a string that will be displayed to the user as the error message. If you don’t, your receiver should return None.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.gift_card_transaction_display = <django.dispatch.dispatcher.Signal object>

Arguments: transaction, customer_facing

To display an instance of the GiftCardTransaction model to a human user, pretix.base.signals.gift_card_transaction_display will be sent out with a transaction argument. The customer_facing argument specifies whether the HTML will be shown to an end-user or if it is being used in the backend.

The first received response that is not None will be used to display the log entry to the user. The receivers are expected to return a string (that might be marked with mark_safe from Django if it contains HTML).

pretix.base.signals.global_email_filter = <pretix.base.signals.GlobalSignal object>

Arguments: message, order, user, customer, organizer

This signal allows you to implement a middleware-style filter on all outgoing emails. You are expected to return a (possibly modified) copy of the message object passed to you.

This signal is called on all events and even if there is no known event. sender is an event or None. The message argument will contain an EmailMultiAlternatives object. If the email is associated with a specific order, the order argument will be passed as well, otherwise it will be None. If the email is associated with a specific user, e.g. a notification email, the user argument will be passed as well, otherwise it will be None.

pretix.base.signals.item_copy_data = <pretix.base.signals.EventPluginSignal object>

Arguments: source, target

This signal is sent out when a new product is created as a clone of an existing product, i.e. the settings from the older product are copied to the newer one. You can listen to this signal to copy data or configuration stored within your plugin’s models as well.

The sender keyword argument will contain the event. The target will contain the item to copy to, the source keyword argument will contain the product to copy from.

pretix.base.signals.notification = <pretix.base.signals.EventPluginSignal object>

Arguments: logentry_id, notification_type

This signal is sent out when a notification is sent.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.periodic_task = <django.dispatch.dispatcher.Signal object>

This is a regular django signal (no pretix event signal) that we send out every time the periodic task cronjob runs. This interval is not sharply defined, it can be everything between a minute and a day. The actions you perform should be idempotent, i.e. it should not make a difference if this is sent out more often than expected.

pretix.base.signals.quota_availability = <pretix.base.signals.EventPluginSignal object>

Arguments: quota, result, count_waitinglist

This signal allows you to modify the availability of a quota. You are passed the quota and an availability result calculated by pretix code or other plugins. availability is a tuple with the first entry being one of the Quota.AVAILABILITY_* constants and the second entry being the number of available tickets (or None for unlimited). You are expected to return a value of the same type. The parameter count_waitinglists specifies whether waiting lists should be taken into account.

Warning: Use this signal with great caution, it allows you to screw up the performance of the system really bad. Also, keep in mind that your response is subject to caching and out-of-date quotas might be used for display (not for actual order processing).

pretix.base.signals.register_global_settings = <django.dispatch.dispatcher.Signal object>

All plugins that are installed may send fields for the global settings form, as an OrderedDict of (setting name, form field).

pretix.base.signals.register_mail_placeholders = <pretix.base.signals.EventPluginSignal object>

DEPRECATED: This signal has a new name, please use register_text_placeholders instead.

pretix.base.signals.register_notification_types = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to get all known notification types. Receivers should return an instance of a subclass of pretix.base.notifications.NotificationType or a list of such instances.

As with all event-plugin signals, the sender keyword argument will contain the event, however for this signal, the sender may also be None to allow creating the general notification settings!

pretix.base.signals.register_sales_channel_types = <django.dispatch.dispatcher.Signal object>

This signal is sent out to get all known sales channels types. Receivers should return an instance of a subclass of pretix.base.channels.SalesChannelType or a list of such instances.

pretix.base.signals.register_text_placeholders = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to get all known text placeholders. Receivers should return an instance of a subclass of pretix.base.services.placeholders.BaseTextPlaceholder or a list of these.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.register_ticket_secret_generators = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to get all known ticket secret generators. Receivers should return a subclass of pretix.base.secrets.BaseTicketSecretGenerator or a list of these

As with all event-plugin signals, the sender keyword argument will contain the event.

Order events

There are multiple signals that will be sent out in the ordering cycle:

pretix.base.signals.allow_ticket_download = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out to check if tickets for an order can be downloaded. If any receiver returns false, a download will not be offered. If a receiver returns a list of OrderPositions, only those will be downloadable.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.invoice_line_text = <pretix.base.signals.EventPluginSignal object>

Arguments: position

This signal is sent out when an invoice is built for an order. You can return additional text that should be shown on the invoice for the given position.

pretix.base.signals.order_approved = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time an order is being approved. The order object is given as the first argument.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_canceled = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time an order is canceled. The order object is given as the first argument.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_changed = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time an order’s content is changed. The order object is given as the first argument. In contrast to modified, this signal is sent out if the order or any of its positions changes in a material way, such as changed products, prices, or tax rates, order_changed is used instead. If “only” user input is changed, such as attendee names, invoice addresses or question answers, order_modified is used instead.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_denied = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time an order is being denied. The order object is given as the first argument.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_expired = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time an order is marked as expired. The order object is given as the first argument.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_fee_calculation = <pretix.base.signals.EventPluginSignal object>

Arguments: positions, invoice_address, meta_info, total, gift_cards, payment_requests

This signals allows you to add fees to an order while it is being created. You are expected to return a list of OrderFee objects that are not yet saved to the database (because there is no order yet).

As with all plugin signals, the sender keyword argument will contain the event. A positions argument will contain the cart positions and invoice_address the invoice address (useful for tax calculation). The argument meta_info contains the order’s meta dictionary. The total keyword argument will contain the total cart sum without any fees. You should not rely on this total value for fee calculations as other fees might interfere. The gift_cards argument lists the gift cards in use.

DEPRECTATION: Stop listening to the gift_cards attribute, it will be removed in the future.

pretix.base.signals.order_fee_type_name = <pretix.base.signals.EventPluginSignal object>

Arguments: request, fee

This signals allows you to return a human-readable description for a fee type based on the fee_type and internal_type attributes of the OrderFee model that you get as keyword arguments. You are expected to return a string or None, if you don’t know about this fee.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_gracefully_delete = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time a test-mode order is being deleted. The order object is given as the first argument.

Any plugin receiving this signals is supposed to perform any cleanup necessary at this point, so that the underlying order has no more external constraints that would inhibit the deletion of the order.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_modified = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time an order’s information is modified. The order object is given as the first argument. In contrast to order_changed, this signal is sent out if information of an order or any of it’s position is changed that concerns user input, such as attendee names, invoice addresses or question answers. If the order changes in a material way, such as changed products, prices, or tax rates, order_changed is used instead.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_paid = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time an order is paid. The order object is given as the first argument. This signal is not sent out if an order is marked as paid because an already-paid order has been split.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_placed = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time an order is placed. The order object is given as the first argument. This signal is not sent out if an order is created through splitting an existing order, so you can not expect to see all orders by listening to this signal.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_reactivated = <pretix.base.signals.EventPluginSignal object>

Arguments: order

This signal is sent out every time a canceled order is reactivated. The order object is given as the first argument.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.order_split = <pretix.base.signals.EventPluginSignal object>

Arguments: original, split_order

This signal is sent out when an order is split into two orders and allows you to copy related models to the new order. You will be passed the old order as original and the new order as split_order.

pretix.base.signals.order_valid_if_pending = <pretix.base.signals.EventPluginSignal object>

Arguments: payments, positions, email, locale, invoice_address, meta_info, customer

This signal is sent out when the user tries to confirm the order, before we actually create the order. It allows you to set the valid_if_pending of the order even before it is created. Whenever any plugin returns True, the order will be valid if pending.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.validate_cart = <pretix.base.signals.EventPluginSignal object>

Arguments: positions

This signal is sent out before the user starts checkout. It includes an iterable with the current CartPosition objects. The response of receivers will be ignored, but you can raise a CartError with an appropriate exception message.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.validate_cart_addons = <pretix.base.signals.EventPluginSignal object>

Arguments: addons, base_position, iao

This signal is sent when a user tries to select a combination of addons. In contrast to validate_cart, this is executed before the cart is actually modified. You are passed an argument addons containing a dict of (item, variation or None) → count tuples as well as the ItemAddOn object as the argument iao and the base cart position as base_position. The response of receivers will be ignored, but you can raise a CartError with an appropriate exception message.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.validate_order = <pretix.base.signals.EventPluginSignal object>

Arguments: payments, positions, email, locale, invoice_address, meta_info, customer

This signal is sent out when the user tries to confirm the order, before we actually create the order. It allows you to inspect the cart positions. Your return value will be ignored, but you can raise an OrderError with an appropriate exception message if you like to block the order. We strongly discourage making changes to the order here.

As with all event-plugin signals, the sender keyword argument will contain the event.

DEPRECTATION: Stop listening to the payment_provider attribute, it will be removed in the future, as the payments attribute gives more information.

Check-ins

pretix.base.signals.checkin_created = <pretix.base.signals.EventPluginSignal object>

Arguments: checkin

This signal is sent out every time a check-in is created (i.e. an order position is marked as checked in). It is not send if the position was already checked in and is force-checked-in a second time. The check-in object is given as the first argument.

For backwards compatibility reasons, this signal is only sent when a successful scan is saved.

As with all event-plugin signals, the sender keyword argument will contain the event.

Frontend

pretix.presale.signals.checkout_all_optional = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘request’

If any receiver of this signal returns True, all input fields during checkout (contact data, invoice address, confirmations) will be optional, except for questions. Use with care!

As with all plugin signals, the sender keyword argument will contain the event. A request argument will contain the request object.

pretix.presale.signals.checkout_confirm_messages = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to retrieve short messages that need to be acknowledged by the user before the order can be completed. This is typically used for something like “accept the terms and conditions”. Receivers are expected to return a dictionary where the keys are globally unique identifiers for the message and the values can be arbitrary HTML.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.checkout_confirm_page_content = <pretix.base.signals.EventPluginSignal object>

Arguments: request

This signals allows you to add HTML content to the confirmation page that is presented at the end of the checkout process, just before the order is being created.

As with all plugin signals, the sender keyword argument will contain the event. A request argument will contain the request object.

pretix.presale.signals.checkout_flow_steps = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to retrieve pages for the checkout flow. Receivers are expected to return a subclass of pretix.presale.checkoutflow.BaseCheckoutFlowStep.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.contact_form_fields = <pretix.base.signals.EventPluginSignal object>

This signals allows you to add form fields to the contact form that is presented during checkout and by default only asks for the email address. You are supposed to return a dictionary of form fields with globally unique keys. The validated form results will be saved into the contact_form_data entry of the order’s meta_info dictionary.

As with all plugin signals, the sender keyword argument will contain the event. A request argument will contain the request object.

pretix.presale.signals.contact_form_fields_overrides = <pretix.base.signals.EventPluginSignal object>

Arguments: request, order

This signal allows you to override fields of the contact form that is presented during checkout and by default only asks for the email address. It is also being used for the invoice address form. You are supposed to return a dictionary of dictionaries with globally unique keys. The value-dictionary should contain one or more of the following keys: initial, disabled, validators. The key of the dictionary should be the name of the form field.

As with all plugin signals, the sender keyword argument will contain the event. A request argument will contain the request object. The order argument is None during the checkout process and contains an order if the customer is trying to change an existing order.

pretix.presale.signals.fee_calculation_for_cart = <pretix.base.signals.EventPluginSignal object>

Arguments: request, invoice_address, total, positions, payment_requetss

This signals allows you to add fees to a cart. You are expected to return a list of OrderFee objects that are not yet saved to the database (because there is no order yet).

As with all plugin signals, the sender keyword argument will contain the event. A request argument will contain the request object and invoice_address the invoice address (useful for tax calculation). The total keyword argument will contain the total cart sum without any fees. You should not rely on this total value for fee calculations as other fees might interfere. The positions argument will contain a list or queryset of CartPosition objects.

pretix.presale.signals.footer_link = <pretix.base.signals.EventPluginSignal object>

Arguments: request

The signal pretix.presale.signals.footer_link allows you to add links to the footer of an event page. You are expected to return a dictionary containing the keys label and url.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.front_page_bottom = <pretix.base.signals.EventPluginSignal object>

Arguments: request, subevent

This signal is sent out to display additional information on the frontpage below the list of products.

As with all plugin signals, the sender keyword argument will contain the event. The receivers are expected to return HTML.

pretix.presale.signals.front_page_bottom_widget = <pretix.base.signals.EventPluginSignal object>

Arguments: request, subevent

This signal is sent out to display additional information on the frontpage below the list of products if the front page is shown in the widget.

As with all plugin signals, the sender keyword argument will contain the event. The receivers are expected to return HTML.

pretix.presale.signals.front_page_top = <pretix.base.signals.EventPluginSignal object>

Arguments: request, subevent

This signal is sent out to display additional information on the frontpage above the list of products and but below a custom frontpage text.

As with all plugin signals, the sender keyword argument will contain the event. The receivers are expected to return HTML.

pretix.presale.signals.global_footer_link = <django.dispatch.dispatcher.Signal object>

Arguments: request

The signal pretix.presale.signals.global_footer_link allows you to add links to the footer of any page. You are expected to return a dictionary containing the keys label and url.

pretix.presale.signals.global_html_footer = <django.dispatch.dispatcher.Signal object>

Arguments: request

This signal allows you to put code before the end of the HTML <body> tag of every page in the frontend. You will get the request as the keyword argument request and are expected to return plain HTML.

This signal is called regardless of whether your plugin is active for all pages of the system.

pretix.presale.signals.global_html_head = <django.dispatch.dispatcher.Signal object>

Arguments: request

This signal allows you to put code inside the HTML <head> tag of every page in the frontend. You will get the request as the keyword argument request and are expected to return plain HTML.

This signal is called regardless of whether your plugin is active for all pages of the system.

pretix.presale.signals.global_html_page_header = <django.dispatch.dispatcher.Signal object>

Arguments: request

This signal allows you to put code right in the beginning of the HTML <body> tag of every page in the frontend. You will get the request as the keyword argument request and are expected to return plain HTML.

This signal is called regardless of whether your plugin is active for all pages of the system.

pretix.presale.signals.html_footer = <pretix.base.signals.EventPluginSignal object>

Arguments: request

This signal allows you to put code before the end of the HTML <body> tag of every page in the frontend. You will get the request as the keyword argument request and are expected to return plain HTML.

As with all plugin signals, the sender keyword argument will contain the event.

Note: If PCI DSS compliance is important to you and you keep an inventory according to rule 6.4.3 of PCI DSS, all plugins that are not required to load on a payment page should not return additional JavaScripts if getattr(request, 'pci_dss_payment_page', False) is True.

pretix.presale.signals.html_head = <pretix.base.signals.EventPluginSignal object>

Arguments: request

This signal allows you to put code inside the HTML <head> tag of every page in the frontend. You will get the request as the keyword argument request and are expected to return plain HTML.

As with all plugin signals, the sender keyword argument will contain the event.

Note: If PCI DSS compliance is important to you and you keep an inventory according to rule 6.4.3 of PCI DSS, all plugins that are not required to load on a payment page should not return additional JavaScripts if getattr(request, 'pci_dss_payment_page', False) is True.

pretix.presale.signals.html_page_header = <pretix.base.signals.EventPluginSignal object>

Arguments: request

This signal allows you to put code right in the beginning of the HTML <body> tag of every page in the frontend. You will get the request as the keyword argument request and are expected to return plain HTML.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.item_description = <pretix.base.signals.EventPluginSignal object>

Arguments: item, variation, subevent

This signal is sent out when the description of an item or variation is rendered and allows you to append additional text to the description. You are passed the item, variation and subevent. You are expected to return HTML.

pretix.presale.signals.position_info = <pretix.base.signals.EventPluginSignal object>

Arguments: order, position, request

This signal is sent out to display additional information on the position detail page

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.position_info_top = <pretix.base.signals.EventPluginSignal object>

Arguments: order, position, request

This signal is sent out to display additional information on top of the position detail page

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.question_form_fields = <pretix.base.signals.EventPluginSignal object>

Arguments: position

This signals allows you to add form fields to the questions form that is presented during checkout and by default asks for the questions configured in the backend. You are supposed to return a dictionary of form fields with globally unique keys. The validated form results will be saved into the question_form_data entry of the position’s meta_info dictionary.

The position keyword argument will contain either a CartPosition object or an OrderPosition object, depending on whether the form is called as part of the order checkout or for changing an order later.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.question_form_fields_overrides = <pretix.base.signals.EventPluginSignal object>

Arguments: position, request

This signal allows you to override fields of the questions form that is presented during checkout and by default only asks for the questions configured in the backend. You are supposed to return a dictionary of dictionaries with globally unique keys. The value-dictionary should contain one or more of the following keys: initial, disabled, validators. The key of the dictionary should be the form field name for system fields (e.g. company), or the question’s identifier for user-defined questions.

The position keyword argument will contain a CartPosition or OrderPosition object.

As with all plugin signals, the sender keyword argument will contain the event. A request argument will contain the request object.

pretix.presale.signals.render_seating_plan = <pretix.base.signals.EventPluginSignal object>

Arguments: request, subevent, voucher

This signal is sent out to render a seating plan, if one is configured for the specific event. You will be passed the request as a keyword argument. If applicable, a subevent or voucher argument might be given.

As with all plugin signals, the sender keyword argument will contain the event. The receivers are expected to return HTML.

pretix.presale.signals.seatingframe_html_head = <pretix.base.signals.EventPluginSignal object>

Arguments: request

Temporary workaround, might be removed again later. This signal allows you to put code inside the HTML <head> tag of the seatingframe page in the frontend. You will get the request as the keyword argument request and are expected to return plain HTML.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.order_api_meta_from_request = <pretix.base.signals.EventPluginSignal object>

Arguments: request

This signal is sent before an order is created through the pretixpresale frontend. It allows you to return a dictionary that will be merged in the api_meta attribute of the order. You will receive the request triggering the order creation as the request keyword argument.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.order_info = <pretix.base.signals.EventPluginSignal object>

Arguments: order, request

This signal is sent out to display additional information on the order detail page

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.order_info_top = <pretix.base.signals.EventPluginSignal object>

Arguments: order, request

This signal is sent out to display additional information on top of the order detail page

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.order_meta_from_request = <pretix.base.signals.EventPluginSignal object>

Arguments: request

This signal is sent before an order is created through the pretixpresale frontend. It allows you to return a dictionary that will be merged in the meta_info attribute of the order. You will receive the request triggering the order creation as the request keyword argument.

As with all event-plugin signals, the sender keyword argument will contain the event.

Request flow

pretix.presale.signals.process_request = <pretix.base.signals.EventPluginSignal object>

Arguments: request

This signal is sent out whenever a request is made to a event presale page. Most of the time, this will be called from the middleware layer (except on plugin-provided pages this will be called by the @event_view decorator). Similarly to Django’s process_request middleware method, if you return a Response, that response will be used and the request won’t be processed any further down the stack.

WARNING: Be very careful about using this signal as listening to it makes it really easy to cause serious performance problems.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.presale.signals.process_response = <pretix.base.signals.EventPluginSignal object>

Arguments: request, response

This signal is sent out whenever a response is sent from a event presale page. Most of the time, this will be called from the middleware layer (except on plugin-provided pages this will be called by the @event_view decorator). Similarly to Django’s process_response middleware method you must return a response object, that will be passed further up the stack to other handlers of the signal. If you do not want to alter the response, just return the response parameter.

WARNING: Be very careful about using this signal as listening to it makes it really easy to cause serious performance problems.

As with all plugin signals, the sender keyword argument will contain the event.

Vouchers

pretix.presale.signals.voucher_redeem_info = <pretix.base.signals.EventPluginSignal object>

Arguments: voucher

This signal is sent out to display additional information on the “redeem a voucher” page

As with all plugin signals, the sender keyword argument will contain the event.

Backend

pretix.control.signals.event_settings_widget = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘request’

This signal is sent out to include template snippets on the settings page of an event that allows generating a pretix Widget code.

As with all plugin signals, the sender keyword argument will contain the event. A second keyword argument request will contain the request object.

pretix.control.signals.html_head = <pretix.base.signals.EventPluginSignal object>

Arguments: request

This signal allows you to put code inside the HTML <head> tag of every page in the backend. You will get the request as the keyword argument request and are expected to return plain HTML.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.control.signals.html_page_start = <django.dispatch.dispatcher.Signal object>

This signal allows you to put code in the beginning of the main page for every page in the backend. You are expected to return HTML.

The sender keyword argument will contain the request.

pretix.control.signals.item_formsets = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘request’, ‘item’

This signal allows you to return additional formsets that should be rendered on the product modification page. You are passed request and item arguments and are expected to return an instance of a formset class that you bind yourself when appropriate. Your formset will be executed as part of the standard validation and rendering cycle and rendered using default bootstrap styles. It is advisable to set a prefix for your formset to avoid clashes with other plugins.

Your formset needs to have two special properties: template with a template that will be included to render the formset and title that will be used as a headline. Your template will be passed a formset variable with your formset.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.control.signals.nav_event = <pretix.base.signals.EventPluginSignal object>

Arguments: request

This signal allows you to add additional views to the admin panel navigation. You will get the request as a keyword argument request. Receivers are expected to return a list of dictionaries. The dictionaries should contain at least the keys label and url. You can also return a fontawesome icon name with the key icon, it will be respected depending on the type of navigation. You should also return an active key with a boolean set to True, when this item should be marked as active. The request object will have an attribute event.

You can optionally create sub-items to create hierarchical navigation. There are two ways to achieve this: Either you specify a key children on your top navigation item that contains a list of navigation items (as dictionaries), or you specify a parent key with the url value of the designated parent item. The latter method also allows you to register navigation items as a sub-item of existing ones.

If you use this, you should read the documentation on how to deal with URLs in pretix.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.control.signals.nav_event_settings = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘request’

This signal is sent out to include tab links on the settings page of an event. Receivers are expected to return a list of dictionaries. The dictionaries should contain at least the keys label and url. You should also return an active key with a boolean set to True, when this item should be marked as active.

If your linked view should stay in the tab-like context of this page, we recommend that you use pretix.control.views.event.EventSettingsViewMixin for your view and your template inherits from pretixcontrol/event/settings_base.html.

As with all plugin signals, the sender keyword argument will contain the event. A second keyword argument request will contain the request object.

pretix.control.signals.nav_global = <django.dispatch.dispatcher.Signal object>

Arguments: request

This signal allows you to add additional views to the navigation bar when no event is selected. You will get the request as a keyword argument request. Receivers are expected to return a list of dictionaries. The dictionaries should contain at least the keys label and url. You can also return a fontawesome icon name with the key icon, it will be respected depending on the type of navigation. You should also return an active key with a boolean set to True, when this item should be marked as active.

You can optionally create sub-items to create hierarchical navigation. There are two ways to achieve this: Either you specify a key children on your top navigation item that contains a list of navigation items (as dictionaries), or you specify a parent key with the url value of the designated parent item. The latter method also allows you to register navigation items as a sub-item of existing ones.

If you use this, you should read the documentation on how to deal with URLs in pretix.

This is no EventPluginSignal, so you do not get the event in the sender argument and you may get the signal regardless of whether your plugin is active.

pretix.control.signals.nav_organizer = <django.dispatch.dispatcher.Signal object>

Arguments: ‘organizer’, ‘request’

This signal is sent out to include tab links on the detail page of an organizer. Receivers are expected to return a list of dictionaries. The dictionaries should contain at least the keys label and url. You should also return an active key with a boolean set to True, when this item should be marked as active.

You can optionally create sub-items to create hierarchical navigation. There are two ways to achieve this: Either you specify a key children on your top navigation item that contains a list of navigation items (as dictionaries), or you specify a parent key with the url value of the designated parent item. The latter method also allows you to register navigation items as a sub-item of existing ones.

If your linked view should stay in the tab-like context of this page, we recommend that you use pretix.control.views.organizer.OrganizerDetailViewMixin for your view and your template inherits from pretixcontrol/organizers/base.html.

This is a regular django signal (no pretix event signal). Receivers will be passed the keyword arguments organizer and request.

pretix.control.signals.nav_topbar = <django.dispatch.dispatcher.Signal object>

Arguments: request

This signal allows you to add additional views to the top navigation bar. You will get the request as a keyword argument request. Receivers are expected to return a list of dictionaries. The dictionaries should contain at least the keys label and url. You can also return a fontawesome icon name with the key icon, it will be respected depending on the type of navigation. If set, on desktops only the icon will be shown. The title property can be used to set the alternative text.

If you use this, you should read the documentation on how to deal with URLs in pretix.

This is no EventPluginSignal, so you do not get the event in the sender argument and you may get the signal regardless of whether your plugin is active.

pretix.control.signals.oauth_application_registered = <django.dispatch.dispatcher.Signal object>

Arguments: user, application

This signal will be called whenever a user registers a new OAuth application.

pretix.control.signals.order_info = <pretix.base.signals.EventPluginSignal object>

Arguments: order, request

This signal is sent out to display additional information on the order detail page

As with all plugin signals, the sender keyword argument will contain the event. Additionally, the argument order and request are available.

pretix.control.signals.order_position_buttons = <pretix.base.signals.EventPluginSignal object>

Arguments: order, position, request

This signal is sent out to display additional buttons for a single position of an order.

As with all plugin signals, the sender keyword argument will contain the event. Additionally, the argument order and request are available.

pretix.control.signals.order_search_filter_q = <django.dispatch.dispatcher.Signal object>

Arguments: query

This signal will be called whenever a free-text order search is performed. You are expected to return one Q object that will be OR-ed with existing search queries. As order search exists on a global level as well, this is not an Event signal and will be called even if your plugin is not active. sender will contain the event if the search is performed within an event, and None otherwise. The search query will be passed as query.

pretix.control.signals.order_search_forms = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘request’

This signal allows you to return additional forms that should be rendered in the advanced order search. You are passed request argument and are expected to return an instance of a form class that you bind yourself when appropriate. Your form will be executed as part of the standard validation and rendering cycle and rendered using default bootstrap styles.

You are required to set prefix on your form instance. You are required to implement a filter_qs(queryset) method on your form that returns a new, filtered query set. You are required to implement a filter_to_strings() method on your form that returns a list of strings describing the currently active filters.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.control.signals.quota_detail_html = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘quota’

This signal allows you to append HTML to a Quota’s detail view. You receive the quota as argument in the quota keyword argument.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.control.signals.subevent_forms = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘request’, ‘subevent’, ‘copy_from’

This signal allows you to return additional forms that should be rendered on the subevent creation or modification page. You are passed request and subevent arguments and are expected to return an instance of a form class that you bind yourself when appropriate. Your form will be executed as part of the standard validation and rendering cycle and rendered using default bootstrap styles. It is advisable to set a prefix for your form to avoid clashes with other plugins.

subevent can be None during creation. Before save() is called, a subevent property of your form instance will automatically being set to the subevent that has just been created. During creation, copy_from can be a subevent that is being copied from.

Your forms may also have two special properties: template with a template that will be included to render the form, and title, which will be used as a headline. Your template will be passed a form variable with your form.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.customer_created = <pretix.base.signals.GlobalSignal object>

Arguments: customer

This signal is sent out every time a customer account is created. The customer object is given as the first argument.

The sender keyword argument will contain the organizer.

pretix.base.signals.customer_signed_in = <pretix.base.signals.GlobalSignal object>

Arguments: customer

This signal is sent out every time a customer signs in. The customer object is given as the first argument.

The sender keyword argument will contain the organizer.

pretix.base.signals.logentry_display = <pretix.base.signals.EventPluginSignal object>

Arguments: logentry

To display an instance of the LogEntry model to a human user, pretix.base.signals.logentry_display will be sent out with a logentry argument.

The first received response that is not None will be used to display the log entry to the user. The receivers are expected to return plain text.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.logentry_object_link = <pretix.base.signals.EventPluginSignal object>

Arguments: logentry

To display the relationship of an instance of the LogEntry model to another model to a human user, pretix.base.signals.logentry_object_link will be sent out with a logentry argument.

The first received response that is not None will be used to display the related object to the user. The receivers are expected to return a HTML link. The internal implementation builds the links like this:

a_text = _('Tax rule {val}')
a_map = {
    'href': reverse('control:event.settings.tax.edit', kwargs={
        'event': sender.slug,
        'organizer': sender.organizer.slug,
        'rule': logentry.content_object.id
    }),
    'val': escape(logentry.content_object.name),
}
a_map['val'] = '<a href="{href}">{val}</a>'.format_map(a_map)
return a_text.format_map(a_map)

Make sure that any user content in the HTML code you return is properly escaped! As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.orderposition_blocked_display = <pretix.base.signals.EventPluginSignal object>

Arguments: orderposition, block_name

To display the reason for a blocked ticket to a backend user, pretix.base.signals.orderposition_block_display will be sent out.

The first received response that is not None will be used to display the block to the user. The receivers are expected to return plain text.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.requiredaction_display = <pretix.base.signals.EventPluginSignal object>

DEPRECATED, will no longer be called.

pretix.base.signals.timeline_events = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to collect events for the time line shown on event dashboards. You are passed a subevent argument which might be none and you are expected to return a list of instances of pretix.base.timeline.TimelineEvent, which is a namedtuple with the fields event, subevent, datetime, description and edit_url.

Vouchers

pretix.control.signals.item_forms = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘request’, ‘item’

This signal allows you to return additional forms that should be rendered on the product modification page. You are passed request and item arguments and are expected to return an instance of a form class that you bind yourself when appropriate. Your form will be executed as part of the standard validation and rendering cycle and rendered using default bootstrap styles. It is advisable to set a prefix for your form to avoid clashes with other plugins.

Your forms may also have two special properties: template with a template that will be included to render the form, and title, which will be used as a headline. Your template will be passed a form variable with your form.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.control.signals.voucher_form_class = <pretix.base.signals.EventPluginSignal object>

Arguments: cls

This signal allows you to replace the form class that is used for modifying vouchers. You will receive the default form class (or the class set by a previous plugin) in the cls argument so that you can inherit from it.

Note that this is also called for the voucher bulk creation form, which is executed in an asynchronous context. For the bulk creation form, save() is not called. Instead, you can implement post_bulk_save(saved_vouchers) which may be called multiple times for every batch persisted to the database.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.control.signals.voucher_form_html = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘form’

This signal allows you to add additional HTML to the form that is used for modifying vouchers. You receive the form object in the form keyword argument.

As with all plugin signals, the sender keyword argument will contain the event.

pretix.control.signals.voucher_form_validation = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘form’

This signal allows you to add additional validation to the form that is used for creating and modifying vouchers. You will receive the form instance in the form argument and the current data state in the data argument.

As with all plugin signals, the sender keyword argument will contain the event.

Dashboards

pretix.control.signals.event_dashboard_top = <pretix.base.signals.EventPluginSignal object>

Arguments: ‘request’

This signal is sent out to include custom HTML in the top part of the the event dashboard. Receivers should return HTML.

As with all plugin signals, the sender keyword argument will contain the event. An additional keyword argument subevent can contain a sub-event.

pretix.control.signals.event_dashboard_widgets = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to include widgets in the event dashboard. Receivers should return a list of dictionaries, where each dictionary can have the keys:

• content (str, containing HTML)

• display_size (str, one of “full” (whole row), “big” (half a row) or “small” (quarter of a row). May be ignored on small displays, default is “small”)

• priority (int, used for ordering, higher comes first, default is 1)

• url (str, optional, if the full widget should be a link)

As with all plugin signals, the sender keyword argument will contain the event. An additional keyword argument subevent can contain a sub-event.

pretix.control.signals.user_dashboard_widgets = <django.dispatch.dispatcher.Signal object>

Arguments: ‘user’

This signal is sent out to include widgets in the personal user dashboard. Receivers should return a list of dictionaries, where each dictionary can have the keys:

• content (str, containing HTML)

• display_size (str, one of “full” (whole row), “big” (half a row) or “small” (quarter of a row). May be ignored on small displays, default is “small”)

• priority (int, used for ordering, higher comes first, default is 1)

• url (str, optional, if the full widget should be a link)

This is a regular django signal (no pretix event signal).

Ticket designs

pretix.base.signals.layout_image_variables = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to collect variables that can be used to display dynamic images in ticket-related PDF layouts. Receivers are expected to return a dictionary with globally unique identifiers as keys and more dictionaries as values that contain keys like in the following example:

return {
    "profile": {
        "label": _("Profile picture"),
        "evaluate": lambda orderposition, order, event: ContentFile(b"some-image-data"),
        "etag": lambda orderposition, order, event: hash(b"some-image-data")
    }
}

The evaluate member will be called with the order position, order and event as arguments. The event might also be a subevent, if applicable. The return value of evaluate should be an instance of Django’s File class and point to a valid JPEG or PNG file. If no image is available, evaluate should return None.

The etag member will be called with the same arguments as evaluate but should return a str value uniquely identifying the version of the file. This can be a hash of the file, but can also be something else. If no image is available, etag should return None. In some cases, this can speed up the implementation.

pretix.base.signals.layout_text_variables = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to collect variables that can be used to display text in ticket-related PDF layouts. Receivers are expected to return a dictionary with globally unique identifiers as keys and more dictionaries as values that contain keys like in the following example:

return {
    "product": {
        "label": _("Product name"),
        "editor_sample": _("Sample product"),
        "evaluate": lambda orderposition, order, event: str(orderposition.item),
        "evaluate_bulk": lambda orderpositions: [str(op.item) for op in orderpositions],
    }
}

The evaluate member will be called with the order position, order and event as arguments. The event might also be a subevent, if applicable.

The evaluate_bulk member is optional but can significantly improve performance in some situations because you can perform database fetches in bulk instead of single queries for every position.

pretix.plugins.ticketoutputpdf.signals.override_layout = <pretix.base.signals.EventPluginSignal object>

Arguments: layout, orderposition

This signal allows you to forcefully override the ticket layout that is being used to create the ticket PDF. Use with care, as this will render any specifically by the organizer selected templates useless.

The layout keyword argument will contain the layout which has been originally selected by the system, the orderposition keyword argument will contain the OrderPosition which is being generated.

If you implement this signal and do not want to override the layout, make sure to return the layout keyword argument which you have been passed.

As with all plugin signals, the sender keyword will contain the event.

API

pretix.base.signals.api_event_settings_fields = <pretix.base.signals.EventPluginSignal object>

This signal is sent out to collect serializable settings fields for the API. You are expected to return a dictionary mapping names of attributes in the settings store to DRF serializer field instances.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.base.signals.validate_event_settings = <pretix.base.signals.EventPluginSignal object>

Arguments: settings_dict

This signal is sent out if the user performs an update of event settings through the API or web interface. You are passed a settings_dict dictionary with the new state of the event settings object and are expected to raise a django.core.exceptions.ValidationError if the new state is not valid. You can not modify the dictionary. This is only recommended to use if you have multiple settings that can only be validated together. To validate individual settings, pass a validator to the serializer field instead.

As with all event-plugin signals, the sender keyword argument will contain the event.

pretix.api.signals.register_device_security_profile = <django.dispatch.dispatcher.Signal object>

This signal is sent out to get all known device security_profiles. Receivers should return an instance of a subclass of pretix.api.auth.devicesecurity.BaseSecurityProfile or a list of such instances.