Signal list

This page lists the signals and hooks that are available in byro. The following guides will give examples on how to use these signals.

Member management

byro.members.signals.leave_member = <django.dispatch.dispatcher.Signal object>

Receives the new member as signal. If an exception is raised, the error message will be displayed in the frontend as a warning.

byro.members.signals.leave_member_mail_information = <django.dispatch.dispatcher.Signal object>

Receives the leaving member as signal. Response will be added to the email confirming termination to the member.

byro.members.signals.leave_member_office_mail_information = <django.dispatch.dispatcher.Signal object>

Receives the leaving member as signal. Response will be added to the email notifying the office about the termination of the member.

byro.members.signals.new_member = <django.dispatch.dispatcher.Signal object>

Receives the new member as signal. If an exception is raised, the error message will be displayed in the frontend as a warning.

byro.members.signals.new_member_mail_information = <django.dispatch.dispatcher.Signal object>

Receives the new member as signal. Response will be added to the email welcoming the new member.

byro.members.signals.new_member_office_mail_information = <django.dispatch.dispatcher.Signal object>

Receives the new member as signal. Response will be added to the email notifying the office about the new member.

byro.members.signals.update_member = <django.dispatch.dispatcher.Signal object>

If a member is updated via the office form collection at members/view/{id}/data. The signal receives the request, and the form_list as parameters. The changes will already have been saved at this point.

Payment

byro.bookkeeping.signals.process_csv_upload = <django.dispatch.dispatcher.Signal object>

This signal provides a RealTransactionSource as sender and expects a list of one or more Transactions in response.

If the RealTransactionSource has already been processed, no Transactions should be created, unless you are very sure what you are doing.

byro.bookkeeping.signals.process_transaction = <django.dispatch.dispatcher.Signal object>

This signal provides a Transaction as sender and expects the receiver to augment the Transaction with auto-detected information as appropriate.

The common case is a Transaction that is unbalanced and can be augmented to be a balanced Transaction by adding one or more Bookings.

Recipients MUST NOT change any data in the Transaction or its Bookings if Transaction.is_read_only is True.

Display

byro.office.signals.member_dashboard_tile = <django.dispatch.dispatcher.Signal object>

This signal allows you to add tiles to the member’s dashboard. Receives None as argument, must return either None or a dict:

1{
2    "title": _("Dash!"),
3    "lines": [_('Line 1'), _('Line 2')]
4    "url": "/member/123/foo/",
5    "public": False,  # False is the default
6}

All of the parts of this dict are optional. You cannot include HTML in the response, all strings will be escaped at render time. If “public” is set to True, the dashboard tile will also be shown on the member’s personal page.

byro.office.signals.member_view = <django.dispatch.dispatcher.Signal object>

This signal allows you to add a tab to the member detail view tab list. Receives the member as sender, and additionally the request Must return a dict:

1{
2    "label": _("Fancy Member View"),
3    "url": "/member/123/foo/",
4    "url_name": "plugins:myplugin:foo_view",
5}

Please use byro.office.views.members.MemberView as base class for these views.

byro.office.signals.nav_event = <django.dispatch.dispatcher.Signal object>

This signal allows you to add additional views to the sidebar. Receives the request as sender. Must return a dictionary containing at least the keys label and url. You can also return a ForkAwesome icon name with the key icon. You should also return an active key with a boolean set to True if this item should be marked as active.

If you want your Plugin to appear in the “Finance” or “Settings” submenu in the side bar, please set section in your return dict to either finance or settings, and don’t set an icon.

May return an iterable of multiple dictionaries as described above.

byro.common.signals.log_formatters = <django.dispatch.dispatcher.Signal object>

This signal is used to compile a list of log entry formatters. The return value must be a mapping of action_type: callable(LogEntry) -> html_fragment: str

byro.common.signals.unauthenticated_urls = <django.dispatch.dispatcher.Signal object>

This signal is used to compile a list of URLs that should bypass the normal authentication middleware. The return value must be an iterable where each item is either a) a local view name, or b) a callable with signature (request, resolver_match) that should return True if authentication should be bypassed. Note: in case a) only the local name must be provided, not with the “plugins:$plugin_name:” namespace prefix, in case b) the callable will see the request and resolver_match with the full name, including namespace prefix.

Import

byro.office.signals.member_list_importers = <django.dispatch.dispatcher.Signal object>

This signal allows you to add additional member list importers. Receives None as argument, must return a dict:

1{
2    "id": "dot.scoped.importer.id",
3    "label": _("My super importer"),
4    "form_valid": form_valid_callback,
5}

where form_valid_callback should accept two arguments: view (the View object handling the request), and form (the form object that was submitted, the file to import is in the upload_file form field) and should return a Response object.

General

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

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