General APIs

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

Core

pretalx.common.signals.periodic_task = <django.dispatch.dispatcher.Signal object>

This is a regular django signal (no pretalx 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, meaning it should not make a difference if this is sent out more often than expected.

pretalx.common.signals.register_locales = <django.dispatch.dispatcher.Signal object>

To provide additional languages via plugins, you will have to provide some settings in the pretalx settings file, and return a list of the registered locales as response to this plugin signal. Every entry should be a tuple of two strings, the first being the locale code, the second being the display name of the locale. (Though pretalx will also accept just a locale code.)

You should always return your locale when no sender keyword argument is given to make your locale available to the makemessages command. Otherwise, check that your plugin is enabled in the current event context if your locale should be scoped to events with your plugin activated.

pretalx.submission.signals.submission_state_change = <pretalx.common.signals.EventPluginSignal object>

This signal allows you to trigger additional events when a submission changes its state. You will receive the submission after it has been saved, the previous state, and the user triggering the change if available. Any exceptions raised will be ignored.

As with all plugin signals, the sender keyword argument will contain the event. Additionally, you will receive the keyword arguments submission, old_state, and user (which may be None). When the submission is created or submitted from a draft state, old_state will be None.

pretalx.schedule.signals.schedule_release = <pretalx.common.signals.EventPluginSignal object>

This signal allows you to trigger additional events when a new schedule version is released. You will receive the new schedule and the user triggering the change (if any). Any exceptions raised will be ignored.

As with all plugin signals, the sender keyword argument will contain the event. Additionally, you will receive the keyword arguments schedule and user (which may be None).

pretalx.mail.signals.queuedmail_post_send = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out after a QueuedMail has been sent. Return value of receivers will be ignored. Receivers must not alter any data of the QueuedMail instance.

As with all event-plugin signals, the sender keyword argument will contain the event. Additionally, the mail keyword argument contains the QueuedMail instance itself.

pretalx.mail.signals.queuedmail_pre_send = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out before a QueuedMail will been sent. Receivers may set the sent timestamp to skip sending via the regular email backend. The email text and HTML is rendered after this signal has been processed, so you can also alter the email’s content here. Any exceptions raised by receivers will be ignored.

Please note that this signal is only sent for QueuedMail instances that are saved/persisted in the database and that belong to an event. This means that you will not receive this signals for emails like password resets or draft reminders, or anything else that pretalx thinks should be private between the sender and the recipient.

As with all event-plugin signals, the sender keyword argument will contain the event. Additionally, the mail keyword argument contains the QueuedMail instance itself.

pretalx.mail.signals.register_mail_placeholders = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out to get all known email text placeholders. Receivers should return an instance of a subclass of pretalx.mail.placeholder.BaseMailTextPlaceholder or a list of these.

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

Exporters

pretalx.common.signals.register_data_exporters = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out to get all known data exporters. Receivers should return a subclass of pretalx.common.exporter.BaseExporter

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

Organiser area

pretalx.orga.signals.activate_event = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out before an event goes live. It allows any installed plugin to raise an Exception to prevent the event from going live. The exception message will be exposed to the user. If a string value is returned, pretalx will show it as a success message. You will get the request as a keyword argument request. Receivers are not expected to return a response.

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

pretalx.orga.signals.event_copy_data = <pretalx.common.signals.EventPluginSignal object>

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 slug to copy from. The keyword arguments submission_type_map, question_map, track_map and speaker_information_map contain mappings from object IDs in the original event to objects in the new event of the respective types.

pretalx.orga.signals.html_head = <pretalx.common.signals.EventPluginSignal object>

This signal allows you to put code inside the HTML <head> tag of every page in the organiser 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. Additionally, the signal will be called with the request it is processing. The receivers are expected to return HTML.

pretalx.orga.signals.nav_event = <pretalx.common.signals.EventPluginSignal object>

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 ForkAwesome 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. If the children key is present, the entries will be rendered as a dropdown menu. The request object will have an attribute event.

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

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

pretalx.orga.signals.nav_event_settings = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out to collect additional settings sub-pages 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.

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

pretalx.orga.signals.nav_global = <django.dispatch.dispatcher.Signal object>

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 ForkAwesome 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. If the children key is present, the entries will be rendered as a dropdown menu.

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

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.

pretalx.common.signals.activitylog_display = <pretalx.common.signals.EventPluginSignal object>

To display an instance of the ActivityLog model to a human user, pretalx.common.signals.activitylog_display will be sent out with an activitylog 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 (lazy) text.

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

pretalx.common.signals.activitylog_object_link = <pretalx.common.signals.EventPluginSignal object>

To display the relationship of an instance of the ActivityLog model to another model to a human user, pretalx.common.signals.activitylog_object_link will be sent out with an activitylog 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 an HTML link as a string. 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.

Display

pretalx.cfp.signals.cfp_steps = <pretalx.common.signals.EventPluginSignal object>

This signal allows you to add CfP steps of your own. This signal will expect a list of pretalx.cfp.flow.BaseCfPStep objects. The integration of CfP steps in the CfP workflow is currently considered unstable and may change without notice between versions.

As with all plugin signals, the sender keyword argument will contain the event. Additionally, the signal will be called with the request it is processing.

This signal 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. Additionally, the signal will be called with the request it is processing.

pretalx.cfp.signals.html_above_profile_page = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out to display additional information on the personal user profile page, above the submission list.

As with all plugin signals, the sender keyword argument will contain the event. Additionally, the signal will be called with the request it is processing. The receivers are expected to return HTML.

pretalx.cfp.signals.html_above_submission_list = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out to display additional information on the personal user submission list page, above the submission list.

As with all plugin signals, the sender keyword argument will contain the event. Additionally, the signal will be called with the request it is processing. The receivers are expected to return HTML.

pretalx.cfp.signals.html_head = <pretalx.common.signals.EventPluginSignal object>

This signal allows you to put code inside the HTML <head> tag of every page in the frontend (i.e. everything not in the organiser 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. Additionally, the signal will be called with the request it is processing. The receivers are expected to return HTML.

pretalx.agenda.signals.html_above_session_pages = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out to display additional information on the public session pages.

As with all plugin signals, the sender keyword argument will contain the event. Additionally, the signal will be called with the request it is processing, and the submission which is currently displayed. The receivers are expected to return HTML.

pretalx.agenda.signals.html_below_session_pages = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out to display additional information on the public session pages.

As with all plugin signals, the sender keyword argument will contain the event. Additionally, the signal will be called with the request it is processing, and the submission which is currently displayed. The receivers are expected to return HTML.