Print-on-Registration plugin

Development
1

Hi,

I am thinking about developing a plugin that allows to trigger the printing of badges,etc. at the check-in desk as soon as a participant is checked in.
I already have some ideas how to accomplish this:

  1. a plugin listens for a checked-in signal (this is not yet in available in core)
    2a) the plugin sends the selected badge to a printer port//queue/ip
    Pros: simple interface
    Cons: The indico server needs access to the printer, which may be a problem with off-site events
    2b) provides a webinterface where an external printing proxy service can connect. This service then gets
    the data via a websocket connection and triggers the printing. This makes it easier to use for off-site
    events.

Question I have:

  1. is it possible to get the signal into core? And what data can be provided (event, registrant, account used for check-in?)
  2. is 2a or 2b the better approach?

Björn

2

A signal for this sounds like a good idea. If you want to contribute it, please base it on the v2.1-dev branch as 2.0 is in feature freeze. You’d have to trigger it from RHRegistrationBulkCheckIn and RHRegistrationCheckIn. For the signal I’d use this signature (similar to registration_state_updated):

registration_checkin_updated = _signals.signal('registration-checkin-updated', """
Called when the checkin state of registration changes. The `sender` is the
`Registration` object.
""")

No need to pass any information about the checkin state; that can be read from the registration object.

1 Like
3

I’d probably go for 2a, since it’s simpler. If you need to relay it to a server behind a firewall, you can always SSH tunnel it or something. Actually, I would probably implement the printing through a Celery task, as to offload work from the workers.

4

For the actual printing, I’d go a completely different way: a webhook that’s triggered whenever you check someone in (using the new signal).

You could add a new event setting to set the URL (you’d need to add a new page where this can be set, since there’s no general way of adding new event settings to any of the existing pages :/), and then call some custom HTTP microservice that handles the printing. This be either call an API of some printing system or send the badge straight to the printer.

The badge itself would be sent with the webhook in the POST data (check the files kwarg of requests.post()); you can generate the PDF data using generate_ticket(registration)

Like this the indico plugin remains pretty simple and you are still flexible.

1 Like
5

Is it also possible to trigger the signal from a db event listener (like indico.modules.events.registration.models.registrations_mapper_configured._set_checkin_dt)?

At least some other methods in the model seem to send signals as well.

6

Yes, sounds like a good approach.

7

You could do that, but it seems like a bad idea as it would also trigger the signal when cloning an event with registrations which is probably not what you want.

8

Yeah, that would be an even better approach, even though a little bit more complicated.

9

So now I am a big step further. The signal is ready as a pull request and triggering.
But I still have a problem with the plugin page:
code is here: https://github.com/bpedersen2/indico-print-checkin-plugin

The plugin loads fine, the link on the event management page is available, but calling it results in
"The method is not allowed for the requested URL." error.

10

You need to override _process in your RH; otherwise it tries to lookup http-verb-specific methods and reject any requests where there is no suitable method.

Also, just FYI, event_settings_form is only handled for payment plugins. However, you can use a simplified version of RHPaymentPluginEdit to handle the event settings page for your own plugin.

11

Thanks to the good input I got here, a first working version is now pushed to github.

12

I rewrote the plugin in a more generic way, so that it can now POST both the badge pdf and /or the registration data to a webhook. Due to this, the plugin changed it’s name as well,
to Indico Checkin Webhook Plugin: https://github.com/bpedersen2/indico-checkin-webhook-plugin/

13

This looks very good :thumbsup:
We should create a wiki page to keep track of existing plugins. What do the others think?

2 Likes
14

Yes, sounds like a good idea.