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.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.

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.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. 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_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 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.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. 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.nav_event_settings = <pretalx.common.signals.EventPluginSignal object>

This signal is sent out to collect additiona 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.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, and track_map contain mappings from object IDs in the original event to objects in the new event of the respective types.

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 a 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.

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.

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.

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. The receivers are expected to return HTML.

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. 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. paths not behind /orga). 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. The receivers are expected to return HTML.