Hooking into Indico using Signals ¶

Signals allow you to hook into certain parts of Indico without adding any code to the core (which is something a plugin can and should not do). Each signal has a sender which can be any object (depending on the signal) and possibly some keyword arguments. Some signals also make use of their return value or even require one. Check the documentation of each signal on how it’s used.

To avoid breakage with newer versions of Indico, it is highly advised to always accept extra **kwargs in your signal receiver. For example, a receiver function could look like this:

def receiver(sender, something, **kwargs):
    do_stuff_with(something)

indico.core.signals ¶

indico.core.signals.acl ¶

indico.core.signals.acl.can_access¶

Called when ProtectionMixin.can_access is used to determine if a user can access something or not.

The sender is the type of the object that’s using the mixin. The actual instance is passed as obj. The user and allow_admin arguments of can_access are passed as kwargs with the same name.

The authorized argument is None when this signal is called at the beginning of the access check and True or False at the end when regular access rights have already been checked. For expensive checks (such as anything involving database queries) it is recommended to skip the check while authorized is None since the regular access check is likely to be cheaper (due to ACLs being preloaded etc).

If the signal returns True or False, the access check succeeds or fails immediately. If multiple subscribers to the signal return contradictory results, False wins and access is denied.

indico.core.signals.acl.can_manage¶

Called when ProtectionMixin.can_manage is used to determine if a user can manage something or not.

The sender is the type of the object that’s using the mixin. The actual instance is passed as obj. The user, permission, allow_admin, check_parent and explicit_permission arguments of can_manage are passed as kwargs with the same name.

If the signal returns True or False, the access check succeeds or fails without any further checks. If multiple subscribers to the signal return contradictory results, False wins and access is denied.

indico.core.signals.acl.entry_changed¶

Called when an ACL entry is changed.

The sender is the type of the object that’s using the mixin. The actual instance is passed as obj. The User, GroupProxy or EmailPrincipal is passed as principal and entry contains the actual ACL entry (a PrincipalMixin instance) or None in case the entry was deleted. is_new is a boolean indicating whether the given principal was in the ACL before. If quiet is True, signal handlers should not perform noisy actions such as logging or sending emails related to the change.

If the ACL uses permissions, old_data will contain a dictionary of the previous permissions (see PrincipalPermissionsMixin.current_data).

indico.core.signals.acl.get_management_permissions¶: Expected to return ManagementPermission subclasses. The sender is the type of the object the permissions may be used for. Functions subscribing to this signal MUST check the sender by specifying it using the first argument of connect_via() or by comparing it inside the function.

indico.core.signals.acl.protection_changed¶

Called when the protection mode of an object is changed.

The sender is the type of the object that’s using the mixin. The actual instance is passed as obj. The old protection mode is passed as old_mode, the new mode as mode.

indico.core.signals.agreements ¶

indico.core.signals.agreements.get_definitions¶: Expected to return a list of AgreementDefinition classes.

indico.core.signals.attachments ¶

indico.core.signals.attachments.attachment_accessed¶: Called when an attachment is accessed. The sender is the Attachment that was accessed. The user who accessed the attachment is passed in the user kwarg. The from_preview kwarg will be set to True if the download link on the preview page was used to access the attachment or if the attachment was loaded to be displayed on the preview page (opening the preview itself already sends this signal with from_preview=False).

indico.core.signals.attachments.attachment_created¶: Called when a new attachment is created. The sender object is the new Attachment. The user who created the attachment is passed in the user kwarg.

indico.core.signals.attachments.attachment_deleted¶: Called when an attachment is deleted. The sender object is the Attachment that was deleted. The user who deleted the attachment is passed in the user kwarg.

indico.core.signals.attachments.attachment_updated¶: Called when an attachment is updated. The sender is the Attachment that was updated. The user who updated the attachment is passed in the user kwarg.

indico.core.signals.attachments.folder_created¶: Called when a new attachment folder is created. The sender is the new AttachmentFolder object. The user who created the folder is passed in the user kwarg. This signal is never triggered for the internal default folder.

indico.core.signals.attachments.folder_deleted¶: Called when a folder is deleted. The sender is the AttachmentFolder that was deleted. The user who deleted the folder is passed in the user kwarg.

indico.core.signals.attachments.folder_updated¶: Called when a folder is updated. The sender is the AttachmentFolder that was updated. The user who updated the folder is passed in the user kwarg.

indico.core.signals.attachments.get_file_previewers¶: Expected to return one or more Previewer subclasses.

indico.core.signals.category ¶

indico.core.signals.category.created¶: Called when a new category is created. The sender is the new category.

indico.core.signals.category.deleted¶: Called when a category is deleted. The sender is the category.

indico.core.signals.category.extra_events¶: Called when a category is displayed. The sender is the category. is_flat is passed as kwarg with the same name. The additional kwargs passed to this signal depend on the context.

indico.core.signals.category.moved¶: Called when a category is moved into another category. The sender is the category and the old parent category is passed in the old_parent kwarg.

indico.core.signals.category.updated¶: Called when a category is modified. The sender is the updated category.

indico.core.signals.core ¶

indico.core.signals.core.add_form_fields¶

Lets you add extra fields to a form. The sender is the form class and should always be specified when subscribing to this signal. Any arguments passed while instantiating the form are being passed in form_args and form_kwargs.

The signal handler should return one or more 'name', Field tuples. Each field will be added to the form as ext__<name> and is automatically excluded from the form’s data property and its populate_obj method.

To actually process the data, you can use e.g. the form_validated signal and then store it in flask.g until another signal informs you that the operation the user was performing has been successful.

indico.core.signals.core.after_commit¶: Called after an SQL transaction has been committed. Note that the session is in ‘committed’ state when this signal is called, so no SQL can be emitted while this signal is being handled.

indico.core.signals.core.after_process¶: Called after an Indico request has been processed. This signal should also be triggered by CLI utilities that result in other signals being triggered.

indico.core.signals.core.app_created¶: Called when the app has been created. The sender is the flask app.

indico.core.signals.core.before_notification_send¶: Executed before a notification is sent. The sender is a string representing the type of notification. The notification email that will be sent is passed in the email kwarg. The additional kwargs passed to this signal depend on the context.

indico.core.signals.core.check_password_secure¶: Check whether a password is secure. The sender is a string indicating the context where the password check happens, the plaintext password is sent in the password kwarg. To fail the security check for a password, the signal handler should return a string describing why the password is not secure.

indico.core.signals.core.db_query¶: Expected to return exactly one single Query object. The sender is a string identifying the context. The query kwarg contains the query object to be customized. The additional kwargs passed to this signal depend on the context.

indico.core.signals.core.db_schema_created¶: Executed when a new database schema is created. The sender is the name of the schema.

indico.core.signals.core.form_validated¶

Triggered when an IndicoForm was validated successfully. The sender is the form object.

This signal may return False to mark the form as invalid even though WTForms validation was successful. In this case it is highly recommended to mark a field as erroneous or indicate the error in some other way.

indico.core.signals.core.get_conditions¶: Expected to return one or more classes inheriting from Condition. The sender is a string (or some other object) identifying the context. The additional kwargs passed to this signal depend on the context.

indico.core.signals.core.get_fields¶: Expected to return field classes. The sender is an object (or just a string) identifying for what to get fields. This signal should never be registered without restricting the sender to ensure only the correct field types are returned.

indico.core.signals.core.get_placeholders¶: Expected to return one or more Placeholder objects. The sender is a string (or some other object) identifying the context. The additional kwargs passed to this signal depend on the context.

indico.core.signals.core.get_search_providers¶: Expected to return exactly one IndicoSearchProvider subclass. No more than one handler for this signal may return one as using multiple search providers at the same time is not possible.

indico.core.signals.core.get_storage_backends¶: Expected to return one or more Storage subclasses.

indico.core.signals.core.import_tasks¶: Called when Celery needs to import all tasks. Use this signal if you have modules containing task registered using one of the Celery decorators but don’t import them anywhere. The signal handler should only import these modules and do nothing else.

indico.core.signals.event ¶

indico.core.signals.event.abstract_accepted¶: Called when an abstract is accepted and a contribution is created. The sender is the abstract. The contribution is passed in the contribution kwarg.

indico.core.signals.event.abstract_created¶: Called when a new abstract is created. The sender is the new abstract.

indico.core.signals.event.abstract_deleted¶: Called when an abstract is deleted. The sender is the abstract.

indico.core.signals.event.abstract_state_changed¶: Called when an abstract is withdrawn. The sender is the abstract.

indico.core.signals.event.abstract_updated¶: Called when an abstract is modified. The sender is the abstract.

indico.core.signals.event.after_registration_form_clone¶: Executed after a registration form is cloned. The sender is the old RegistrationForm object being cloned. The new RegistrationForm object is passed in the new_form kwarg.

indico.core.signals.event.before_check_registration_email¶: Called before checking the validity of the registration email. The sender is the RegistrationForm object. The signal handler is expected to return None if all checks passed or a {'status': ..., 'conflict': ...} dictionary. 'status' is expected to be either 'error', 'warning' or ok.

indico.core.signals.event.before_reminder_make_email¶: Executed before a reminder email is created. The EventReminder object is the sender. The parameters to create an email (to_list, from_address, template and attachments) are passed as kwargs; the signal can return a dict used to update the params which will then be passed to the make_email call.

indico.core.signals.event.cloned¶: Called when an event is cloned. The sender is the Event object of the old event, the new event is passed in the new_event kwarg.

indico.core.signals.event.contribution_created¶: Called when a new contribution is created. The sender is the new contribution.

indico.core.signals.event.contribution_deleted¶: Called when a contribution is deleted. The sender is the contribution.

indico.core.signals.event.contribution_updated¶: Called when a contribution is modified. The sender is the contribution. A dict containing old, new tuples for all changed values is passed in the changes kwarg.

indico.core.signals.event.created¶: Called when a new event is created. The sender is the new Event. The cloning kwarg indictates whether the event is a clone.

indico.core.signals.event.deleted¶: Called when an event is deleted. The sender is the event object. The user kwarg contains the user performing the deletion if available.

indico.core.signals.event.draw_item_on_badge¶: Called when drawing an item on a badge for a given registration. The registration object is the sender. The items, self.height, self.width, item_data, person and template_data are passed in the kwargs. item_data is a dictionary containing item, text, pos_x and pos_y. template_data is a namedtuple containing the complete template structure. The signal returns a dictionary of updates for the contents of item_data.

indico.core.signals.event.filter_selectable_badges¶: Called when composing lists of badge templates. The sender may be either BadgeSettingsForm, RHListEventTemplates or RHListCategoryTemplates. The list of badge templates is passed in the badge_templates kwarg. The signal handler is expected to mutate the list.

indico.core.signals.event.generate_accompanying_person_id¶: Called after a permanent UUID is assigned to an accompanying person. The sender is the AccompanyingPersonSchema object. The temporary ID is passed in the temporary_id kwarg and the permanent UUID is passed in the permanent_id kwarg.

indico.core.signals.event.generate_ticket_qr_code¶: Called when generating the QR code for a ticket. The data included in the QR code is passed in the ticket_data kwarg and may be modified. The signal may also return a string which will then replace the original QR code content. When doing this, be aware that only one plugin may return such a value, and that e.g. the official check-in app will no longer work.

indico.core.signals.event.get_feature_definitions¶: Expected to return EventFeature subclasses.

indico.core.signals.event.get_log_renderers¶: Expected to return EventLogRenderer classes.

indico.core.signals.event.google_wallet_ticket_class_data¶: Called when data for a Google Wallet ticket class has been generated. The sender is the Event object, the data kwarg contains the data that will be passed to the Google Wallet API.

indico.core.signals.event.google_wallet_ticket_object_data¶: Called when data for a Google Wallet ticket object has been generated. The sender is the Registration object, the data kwarg contains the data that will be passed to the Google Wallet API.

indico.core.signals.event.hide_participant_list¶

The event object is the sender.

The signal should return a bool to determine if the Participant list menu should be displayed on the Event page.

indico.core.signals.event.imported¶: Called when data is imported to an event. The sender is the Event data was imported into, the source event is passed in the source_event kwarg.

indico.core.signals.event.is_field_data_locked¶

Called when resolving whether Indico should let a data value be modified in a registration. The participant’s Registration is passed as registration. The sender is the RegistrationFormItem object.

This signal returns a string containing the reason for the item being locked, or None if the item is not locked.

indico.core.signals.event.is_ticket_blocked¶

Called when resolving whether Indico should let a registrant download their ticket. The sender is the registrant’s Registration object.

If this signal returns True, the user will not be able to download their ticket. Any badge containing a ticket-specific placeholder such as the ticket qr code is considered a ticket, and the restriction applies to both users trying to get their own ticket and managers trying to get a ticket for a registrant.

indico.core.signals.event.is_ticketing_handled¶

Called when resolving whether Indico should send tickets with e-mails or it will be handled by other module. The sender is the RegistrationForm object.

If this signal returns True, no ticket will be emailed on registration.

indico.core.signals.event.location_changed¶: Called when the location of an object changed. The sender is the type of the object, the object itself is passed as obj. The changes are passed in the changes kwarg.

indico.core.signals.event.metadata_postprocess¶

Called right after a dict-like representation of an event is created, so that plugins can add their own fields.

The sender is a string parameter specifying the source of the metadata. The event kwarg contains the event object. The metadata is passed in the data kwarg. The user kwarg contains the user for whom the data is generated.

The signal should return a dict that will be used to update the original representation (fields to add or override).

indico.core.signals.event.moved¶: Called when an event is moved to a different category. The sender is the event, the old category is in the old_parent kwarg.

indico.core.signals.event.note_added¶: Called when a note is added. The sender is the note.

indico.core.signals.event.note_deleted¶: Called when a note is deleted. The sender is the note.

indico.core.signals.event.note_modified¶: Called when a note is modified. The sender is the note.

indico.core.signals.event.note_restored¶: Called when a previously-deleted note is restored. The sender is the note. This is triggered when a “new” note is created on an object that previously already had a note which got deleted.

indico.core.signals.event.person_link_field_extra_params¶

The signal should return a dict containing extra parameters that will be passed to the PersonLinkFields. The sender is the field.

The parameter disable_affiliations can be used to disable the affiliations field in the person details modal.

All parameters are camelized and passed to the personListItemActions and personLinkFieldModals React hooks.

indico.core.signals.event.person_updated¶: Called when an EventPerson is modified. The sender is the EventPerson.

indico.core.signals.event.print_badge_template¶: Called when printing a badge template. The registration form is passed in the regform kwarg. The list of registration objects are passed in the registrations kwarg and it may be modified.

indico.core.signals.event.registrant_list_action_menu¶: Called when composing the list of menu items to be displayed under the “Actions” button at the top of the list of registrants/participants. The sender is the corresponding registration form.

indico.core.signals.event.registration_checkin_updated¶: Called when the checkin state of a registration changes. The sender is the Registration object.

indico.core.signals.event.registration_created¶: Called when a new registration has been created. The sender is the Registration object. The data kwarg contains the form data used to populate the registration fields. The management kwarg is set to True if the registration was created from the event management area.

indico.core.signals.event.registration_deleted¶: Called when a registration is removed. The sender is the Registration object. The permanent kwarg indicates whether the registration is being permanently deleted from the database, e.g. due to it exceeding its retention period.

indico.core.signals.event.registration_form_created¶: Called when a new registration form is created. The sender is the RegistrationForm object.

indico.core.signals.event.registration_form_deleted¶: Called when a registration form is removed. The sender is the RegistrationForm object.

indico.core.signals.event.registration_form_edited¶: Called when a registration form is edited. The sender is the RegistrationForm object.

indico.core.signals.event.registration_form_field_deleted¶: Called when a registration form field is removed. The sender is the RegistrationFormField object.

indico.core.signals.event.registration_personal_data_modified¶: Called when the registration personal data is modified. The sender is the Registration object; the change is passed in the change kwarg.

indico.core.signals.event.registration_state_updated¶: Called when the state of a registration changes. The sender is the Registration object; the previous state is passed in the previous_state kwarg; the silent kwarg can be set to True to skip logging.

indico.core.signals.event.registration_updated¶: Called when a registration has been updated. The sender is the Registration object. The data kwarg contains the form data used to populate the registration fields. The management kwarg is set to True if the registration was updated from the event management area.

indico.core.signals.event.restored¶: Called when a previously-deleted event is restored. The sender is the event object. The user kwarg contains the user restoring the event if available, and the reason kwarg the reason if available.

indico.core.signals.event.session_block_deleted¶: Called when a session block is deleted. The sender is the session block. This signal is called before the db.session.delete() on the block is executed.

indico.core.signals.event.session_block_updated¶: Called when a session block is updated. The sender is the session block.

indico.core.signals.event.session_deleted¶: Called when a session is deleted. The sender is the session.

indico.core.signals.event.session_updated¶: Called when a session is updated. The sender is the session.

indico.core.signals.event.sidemenu¶: Expected to return MenuEntryData objects to be added to the event side menu. A single entry can be returned directly, multiple entries must be yielded.

indico.core.signals.event.subcontribution_created¶: Called when a new subcontribution is created. The sender is the new subcontribution.

indico.core.signals.event.subcontribution_deleted¶: Called when a subcontribution is deleted. The sender is the subcontribution.

indico.core.signals.event.subcontribution_updated¶: Called when a subcontribution is modified. The sender is the subcontribution.

indico.core.signals.event.times_changed¶: Called when the times of a scheduled object (contribution, break or session block) change, either by a change in duration or start time. The sender is the type of the object; the timetable entry is passed as entry and the object is passed as obj. Information about the changes are passed as changes which is a dict containing old/new tuples for start_dt, duration and end_dt. If an attribute did not change, it is not included in the dict. If the time of the event itself changes, entry is None and obj contains the Event.

indico.core.signals.event.timetable_buttons¶: Expected to return a list of tuples (‘button_name’, ‘js-call-class’). Called when building the timetable view.

indico.core.signals.event.timetable_entry_created¶: Called when a new timetable entry is created. The sender is the new entry.

indico.core.signals.event.timetable_entry_deleted¶: Called when a timetable entry is deleted. The sender is the entry. This signal is triggered right before the entry deletion is performed.

indico.core.signals.event.timetable_entry_updated¶: Called when a timetable entry is updated. The sender is the entry. A dict containing old, new tuples for all changed values is passed in the changes kwarg.

indico.core.signals.event.type_changed¶: Called when the type of an event is changed. The sender is the event, the old type is passed in the old_type kwarg.

indico.core.signals.event.update_badge_style¶: Called when printing a badge. The template is the sender. The item and it’s styles are passed in the kwarg. The signal returns a dictionary which is used to update the item style.

indico.core.signals.event.updated¶: Called when basic data of an event is updated. The sender is the event. A dict of changes is passed in the changes kwarg, with (old, new) tuples for each change. Note than the person_links change may happen with old and new being the same lists for technical reasons. If the key is present, it should be assumed that something changed (usually the order or some data on the person link).

indico.core.signals.event_management ¶

indico.core.signals.event_management.get_cloners¶: Expected to return one or more EventCloner subclasses implementing a cloning operation for something within an event.

indico.core.signals.event_management.image_created¶: Called when a new image is created. The sender object is the new ImageFile. The user who uploaded the image is passed in the user kwarg.

indico.core.signals.event_management.image_deleted¶: Called when an image is deleted. The sender object is the ImageFile that is about to be deleted. The user who uploaded the image is passed in the user kwarg.

indico.core.signals.event_management.management_url¶: Expected to return a URL for the event management page of the plugin. This is used when someone who does not have event management access wants to go to the event management area. He is then redirected to one of the URLs returned by plugins, i.e. it is not guaranteed that the user ends up on a specific plugin’s management page. The signal should return None if the current user (available via session.user) cannot access the management area. The sender is the event object.

indico.core.signals.plugin ¶

indico.core.signals.plugin.cli¶: Expected to return one or more click commands/groups. If they use indico.cli.core.cli_command / indico.cli.core.cli_group they will be automatically executed within a plugin context and run within a Flask app context by default.

indico.core.signals.plugin.get_blueprints¶: Expected to return one or more IndicoPluginBlueprint-based blueprints which will be registered on the application. The Blueprint must be named either PLUGINNAME or compat_PLUGINNAME.

indico.core.signals.plugin.get_conference_themes¶

Expected to return one or more indico.modules.events.layout.util.ConferenceTheme objects containing the information about custom conference themes.

Required: - name – string indicating the internal name used for the stylesheet which will be

stored when the theme is selected in an event.

css_path – string indicating the location of the CSS file, relative to the
plugin’s static folder.
title – string indicating the title displayed to the user when selecting the theme.

Optional: - js_path – string indicating the location for a simple, static javascript file to be

loaded, relative to the plugin’s static folder.

indico.core.signals.plugin.get_event_request_definitions¶: Expected to return one or more RequestDefinition subclasses.

indico.core.signals.plugin.get_event_themes_files¶: Expected to return the path of a themes yaml containing event theme definitions.

indico.core.signals.plugin.get_template_customization_paths¶: Expected to return the absolute path to a directory containing template overrides. This signal is called once during initialization so it should not use any data that may change at runtime. The behavior of a customization path returned by this function is exactly like <CUSTOMIZATION_DIR>/templates, but it has lower priority than the one from the global customization dir.

indico.core.signals.plugin.inject_bundle¶: Expected to return a list of bundle names which are loaded after all the rest. The sender is the WP class of the page.

indico.core.signals.plugin.interceptable_function¶

This signal provides a generic way to let plugins intercept function calls and inspect or modify their call arguments. The sender should always be taken from the interceptable_sender() util and not be used directly.

The signal handler also receives the original function in the func kwarg and the BoundArguments for the original function call in the args kwarg. Additional context may be preovided in the ctx kwargs.

The args object is mutable; its arguments attribute is a dict containing all the arguments of the original function call; if necessary its apply_defaults method can be called to fill in any default values the function provides.

The signal handler may also return a value; if it does so, the original function will NOT be called but rather the returned value used. Note that using the signal in this way should only be done if you are very sure that no other signal handler does so, as the function call will fail with an error in case more than one return value override is specified.

Due to how Python works, returning an explicit None in order to override the return value with None won’t work; but you can use the special RETURN_NONE kwarg for this purpose.

Note that this signal does NOT let you intercept arbitrary functions; only those which are either decorated or where the caller explicitly wrapped the function using make_interceptable() can be intercepted. If you believe a certain function should allow this, you’re welcome to send a Pull Request.

indico.core.signals.plugin.schema_post_dump¶

Called when a marshmallow schema is dumped. The sender is the schema class and code using this signal should always specify it. The signal is called with the following arguments:

many – bool indicating whether the data was dumped with many=True or not
data – the dumped data. this is guaranteed to be a list; in case of many=False
it is guaranteed to contain exactly one element
orig – the original data before dumping. just like data it is always a list

If a plugin wants to modify the data returned when dumping, it may do so by modifying the contents of data.

indico.core.signals.plugin.schema_post_load¶

Called after a marshmallow schema is loaded. The sender is the schema class and code using this signal should always specify it. The signal is called with the following arguments:

data – the data returned by marshmallow; this is usually a dict which may contain
more complex data types than those valid in JSON

If a plugin wants to modify the resulting data, it may do so by modifying the contents of data.

indico.core.signals.plugin.schema_pre_load¶

Called when a marshmallow schema is loaded. The sender is the schema class and code using this signal should always specify it. The signal is called with the following arguments:

data – the raw data passed to marshmallow; this is usually a dict of raw
json/form data coming from the user, so it can have all types valid in JSON

If a plugin wants to modify the data the schema will eventually load, it may do so by modifying the contents of data.

indico.core.signals.plugin.shell_context¶: Called after adding stuff to the indico shell context. Receives the add_to_context and add_to_context_multi keyword args with functions which allow you to add custom items to the context.

indico.core.signals.plugin.template_hook¶: Expected to return a (is_markup, priority, value) tuple. The returned value will be inserted at the location where this signal is triggered; if multiple receivers are connected to the signal, they will be ordered by priority. If is_markup is True, the value will be wrapped in a Markup object which will cause it to be rendered as HTML. The sender is the name of the actual hook. The keyword arguments depend on the hook.

indico.core.signals.rb ¶

indico.core.signals.rb.booking_created¶: Executed after a booking has been successfully created. The sender is the new Reservation object.

indico.core.signals.rb.booking_deleted¶: Executed after a booking has been deleted. The sender is the Reservation object.

indico.core.signals.rb.booking_modified¶: Executed after a booking has been modified. The sender is the Reservation object and a dictionary of changed values is passed in the changes kwarg.

indico.core.signals.rb.booking_occurrence_state_changed¶: Executed after the state of a booking occurrence changed. The sender is the ReservationOccurrence object.

indico.core.signals.rb.booking_state_changed¶: Executed after a booking has been cancelled/rejected/accepted. The sender is the Reservation object.

indico.core.signals.rh ¶

indico.core.signals.rh.before_check_access¶: Executed right before _check_access of an RH instance is called. The sender is the RH class, the current instance is passed in rh. If the signal returns True or False, the original _check_access method will not be executed. If multiple subscribers to the signal return contradictory results, False wins and access is denied. In case access is denied, a generic error message will be displayed. For custom errors, raise Forbidden yourself while handling the signal.

indico.core.signals.rh.before_process¶: Executed right before _process of an RH instance is called. The sender is the RH class, the current instance is passed in rh. If a signal handler returns a value, the original _process method will not be executed. If multiple signal handlers return a value, an exception is raised.

indico.core.signals.rh.check_access¶: Executed right after the access check of an RH instance has been performed unless the access check raised an exception. The sender is the RH class, the current instance is passed in rh.

indico.core.signals.rh.process¶: Executed right after _process of an RH instance has been called. The sender is the RH class, the current instance is passed in rh. The return value of _process is available in result and if a signal handler returns a value, it will replace the original return value. If multiple signals handlers return a value, an exception is raised.

indico.core.signals.rh.process_args¶: Executed right after _process_args of an RH instance has been called. The sender is the RH class, the current instance is passed in rh. The return value of _process_args (usually None) is available in result.

indico.core.signals.users ¶

indico.core.signals.users.anonymized¶: Called when a user is being anonymized. The sender is the user object. This signal is called once before the anonymization itself actually happens in case the code handling the signal needs to access e.g. the email address of the user and once after the changes have been flushed to the database. Each call contains the flushed kwarg indicating whether the signal is being called before or after flushing the changes.

indico.core.signals.users.db_deleted¶: Called when a user is being permanently deleted from the DB. The sender is the user object. Since permanent deletions of users can easily fail due to DB constraints, this signal is called once BEFORE the deletion actually happens, and then once again after flushing the changes to the database was successful. Each call contains the flushed kwarg indicating whether the deletion has already been flushed to the database or not. When using this signal to remove any external data, you must only perform these changes once the deletion was successful, since otherwise you removed data for a user that still exists in Indico.

indico.core.signals.users.email_added¶: Called when a new email address is added to a user. The sender is the user object and the email address is passed in the email kwarg. The silent kwarg indicates whether the email was added during some automated process where no messages should be flashed (e.g. because the sync was in a background task or triggered during a request from another user).

indico.core.signals.users.favorite_event_added¶: Called when a new event is added to a user’s favorites. The sender is the user object and the event is passed in the event kwarg.

indico.core.signals.users.favorite_event_removed¶: Called when a new event is removed from a user’s favorites. The sender is the user object and the event is passed in the event kwarg.

indico.core.signals.users.logged_in¶: Called when a user logs in. The sender is the User who logged in. Depending on whether this was a regular login or an admin impersonating the user, either the identity kwarg is set to the Identity used by the user to log in or the admin_impersonation kwarg is True.

indico.core.signals.users.merged¶: Called when two users are merged. The sender is the main user while the merged user (i.e. the one being deleted in the merge) is passed via the source kwarg.

indico.core.signals.users.preferences¶: Expected to return a ExtraUserPreferences subclass which implements extra preferences for the user preference page. The sender is the user for whom the preferences page is being shown which might not be the currently logged-in user!

indico.core.signals.users.primary_email_changed¶: Called when the primary address is changed. The sender is the user object and the new and old values are passed as kwargs.

indico.core.signals.users.registered¶: Called once a user registers (either locally or joins through a provider). The sender is the new user object. The kwarg from_moderation indicates whether the user went through a moderation process (this also includes users created by an administrator manually) or was created immediately on registration; the identity associated with the registration is passed in the identity kwarg.

indico.core.signals.users.registration_requested¶: Called when a user requests to register a new indico account, i.e. if moderation is enabled. The sender is the registration request.