Organizer Interface

The talk component includes a comprehensive organizer interface for managing call for papers, submissions, and schedules.

Note

This documentation covers the organizer (orga) interface for the talk component. For CfP (call for papers) and public agenda interfaces, see other sections.

Overview

The organizer interface provides tools for:

  • Event Management: Configure talk-related settings

  • Submission Management: Review and manage talk submissions

  • Speaker Management: Handle speaker profiles and communications

  • Review Process: Coordinate talk reviews

  • Schedule Building: Create and publish event schedules

  • Track Organization: Manage parallel tracks

  • Team Coordination: Organize review teams

For complete API documentation, see Component Modules.

Key Modules

Signals

The organizer interface provides several signals for plugin integration:

eventyay.orga.signals.activate_event = <eventyay.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, eventyay 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.

eventyay.orga.signals.event_copy_data = <eventyay.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.

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

This signal allows you to put code inside the HTML <head> tag of every page in the organizer 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.

eventyay.orga.signals.nav_event = <eventyay.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 eventyay.

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

eventyay.orga.signals.nav_event_settings = <eventyay.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.

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

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.

Permissions

See Also