v0.6.2

Ticket e-mails no longer cause a burst of Google Wallet errors on an event's first mail.

Restart Indico after installing. There is no migration, no asset rebuild, and members do not need to sign in again.

Fixes

• The Google Wallet class is made before the first ticket mail that links to it. Indico creates an event's Google Wallet class the first time anyone follows a Google link, with a lookup and then a create that nothing guards. A mail full of those links is followed by every link scanner on its way to the inbox (Safe Links on a university mailbox opens them all within a second), so on an event's first mail the creates collided: Google answered the losers 409 existingResource and Indico turned it into a 503 (Sentry INDICO-BACKEND-P). The plugin now makes the class first, so those requests find it already there.
• It never stops the mail. If Google cannot be reached, the ticket still goes out with its badge and a warning is logged; the link creates the class when first followed, as before. Each event is tried once per request, so a bulk approval while Google is slow does not wait on it for every registrant.

The race itself is in Indico core, which would be better fixed by treating a 409 on the create as success. Two organizers approving at the very same moment can still collide, which now costs a warning and nothing else. See README §4, In the e-mail.

v0.6.1

The registered-events API no longer answers with an empty list on a form nobody has configured.

Run indico db --plugin stsa upgrade after installing, then restart Indico. This release adds a data migration, not a column: it switches List in the events API on for every registration form that already has STSA settings. 0.6.0 left every saved row off, and a row also exists for a form whose settings were saved for some other reason, so an "off" already in the table cannot be told from a choice. If a form should not be listed, switch it off again on its STSA settings page afterwards. Nothing else needs doing: there is no asset rebuild, and members do not need to sign in again.

Fixes

• GET /api/stsa/registered-events listed nothing on a fresh install. List in the events API was off by default, and a form with no STSA settings row was never joined to, so the endpoint returned {"registrations": []} with nothing to say why. The switch is now on by default, and a form with no settings row is listed too. It is still per form, and an organizer can still switch a form off. The endpoint only ever returns the asking participant's own registrations, so there was nothing for the old default to protect.
• The registration form's STSA box, the STSA overview and the settings page now show a form with no settings row as Listed, matching what the endpoint does.

A database that has not been upgraded still lists nothing, and the server log still says so once per process. See README §10.

v0.6.0

A participant can ask which events they have registered for, and administrators get an API reference for every endpoint the Indico has.

Run indico db --plugin stsa upgrade after installing, then restart Indico (and the Celery worker, if you run one). This release adds a column. Until it has been run the plugin reads as nothing configured, the STSA pages in the management area say so, the new endpoint answers with an empty list, and the server log says so once per process. Nothing else needs doing: there is no asset rebuild, and members do not need to sign in again.

Features

• GET /api/stsa/registered-events lists the signed-in participant's own registrations, each with its event, filtered by from / to (any event that takes place, even in part, in the window; a bare date is the whole day) and by status: upcoming, ongoing, checked_in, no_show, pending, withdrawn, rejected. Withdrawn and rejected registrations are listed only when asked for. It answers to a session or a token with the read:user scope, and there is no way to ask for anybody else's. See README §10.
  • Each registration form decides whether its registrations are listed: a new List in the events API switch on the form's STSA settings page, off by default, shown in the STSA overview. A form with no settings row lists nothing.
• An API reference for administrators. Administration → Integration → API reference shows an OpenAPI 3.1 document, generated from the running instance, of every endpoint it has — plugins included — drawn with Scalar. The page, the document and Scalar's script are all administrator-only. Scalar is vendored rather than loaded from a CDN, and the page's content security policy lets it talk to nobody but the server. See README §11.

Changes

• The plugin's blueprint no longer has an /event/<id> prefix, since the new API is not about one event. The management URLs are unchanged.
• The wheel gate (check_wheel.py) now also requires the vendored Scalar files and refuses a wheel that carries the script in the public static folder.

v0.5.0

First and Last name can be switched off on a form that asks for 英文姓名 and 中文姓名, and the member-detail fields from 0.4.0 now actually fill in.

Run indico db --plugin stsa upgrade after installing. This release adds a column. Until it has been run the plugin reads as nothing configured, the STSA pages in the management area say so, and the server log says so once per process.

Features

• First and Last name can be disabled. Once a form has an English name field, First Name gets the Disable button Indico withholds from it; once it has a Chinese name field, so does Last Name. A switched-off field is drawn with the disabled fields in the editor and is not asked of the participant — on the registration form or in Add registrant. A registrant's name is the English name followed by the Chinese one (Xiao-Ming Wang 王小明), which is what tickets, badges, e-mails and lists print.
  • The English or Chinese name must then be filled in; a registration without it is refused on that field.
  • The fields are not really disabled — Indico's database and core forbid that for a required name — so the switch is the plugin's own and the fields keep working everywhere else. See README §9 for why.
  • Deleting or disabling the English or Chinese field, or giving it a show if, switches the default field back on.

Fixes

• The member-detail fields did not fill in. Indico builds an identity's data through a whitelist of the user fields it synchronizes, so chinese_name, english_name, major and year_of_study were dropped at login. They are now kept, and a field is locked only when its claim arrived. A login that carries none of the four claims now logs the claim names it did carry, to tell a missing scope mapping from claims that are in the wrong half of the response. Members need to sign in again once for their details to be stored.
• The Add field dialog opened with a dead Submit button for the four member-detail types: the title was prefilled in a way that left the form pristine, and Indico keeps Submit disabled until the form changes.
• The draft kept across the login page no longer restores blank answers over the name and affiliation Indico had just filled in from the account.

Docs

README §8 now lists the four things that decide whether the claims arrive, including that Indico reads the ID token rather than the userinfo endpoint when the openid scope is used.

v0.4.0

Four registration field types that a signed-in member's account fills in and
locks: 中文姓名, 英文姓名, 就讀科系 and 目前身分.

Features

• Membership details on the registration form. Add field now offers
  STSA 中文姓名, STSA 英文姓名, STSA 就讀科系 and STSA 目前身分, filled in
  from the chinese_name, english_name, major and year_of_study claims.
  They are plain text answers as far as the rest of Indico is concerned —
  summary, e-mails, registrant list, exports — and take the usual field
  settings.

  • Signed in, and the account has an answer: the field arrives filled in
    and disabled, with a padlock saying where it came from.
  • Signed out, or the claim is missing or blank: an ordinary text box.
    Locking is decided field by field, so a member with no major gets three
    locked fields and one open.
  • Enforced on the server, not just drawn. After core stores a
    registration, on creation and on every edit, the account's answer is
    written over whatever was submitted for a field it has one for — so a
    hand-built request for a locked field is replaced.
  • A visitor who is signed out is told signing in fills these in, in the
    same notice the member discount uses; what they had typed is kept across
    the login page, except in the fields the account then fills in.
  • Organizers in the management area, somebody else's registration opened
    from its e-mail link, and invitations are left as ordinary text boxes —
    the same carve-outs as the membership's e-mail address.

  A new switch, Fill in the member's details, on the plugin's admin page
  (on by default). Off, the padlock and the overwrite go together; the field
  types stay registered so forms that already carry them keep working.

Upgrade notes

• No migration. There are no new tables; nothing to run beyond installing
  the release and restarting Indico (and the Celery worker, if you run one).
• The claims have to arrive. Indico already keeps everything the identity
  provider sends, on every login, so there is no new call to authentik — but
  the four claims must be emitted by a scope mapping, and that scope must be
  one Indico asks for (authlib_args['client_kwargs']['scope']).
• Values are as of the last login. A member whose details changed, or who
  last signed in before the claims were being sent, sees the old ones — or
  none — until they sign in again.
• A member who signs in with an Indico password rather than authentik has no
  claims on that login, and gets ordinary text boxes.

Full Changelog: v0.3.2...v0.4.0

v0.3.2

Two fixes from a security review of the whole plugin, both in code an
organizer or a participant can reach.

Fixes

• The members-only gate on group registration now asks who is acting, not
  who created the registration. It exempted any registration an organizer
  had created, reading created_by_manager off the record — but a
  registration stays editable from the link in its confirmation e-mail with
  nobody signed in, so the exemption outlived the organizer's visit and the
  holder of that link could set a group plan on a form whose members-only
  switch was on. The carve-out is now core's management flag, which is what
  it always meant. The member discount's own trust in manager-created
  registrations is unchanged.

• scripts/sign-preview-pass.py no longer takes the Pass Type ID key's
  passphrase on the command line. --password put it in
  /proc/<pid>/cmdline, where any local account could read it while the
  script ran, and in the shell history of whoever followed the documented
  command.

If you script the preview signer

--password is gone. Set STSA_PASS_KEY_PASSWORD for an unattended run with
an encrypted key; run it interactively and it prompts. An unencrypted key
still signs with no prompt and no variable, exactly as before.

Full Changelog: v0.3.1...v0.3.2

v0.3.1

What's Changed

• Draw a pass an iPhone on iOS 26 can still open by @kimiyangg in #3

Full Changelog: v0.3.0...v0.3.1

0.3.0

What's Changed

• Draw the Apple Wallet pass in Xcode's Pass Designer by @kimiyangg in #1

Full Changelog: v0.2.8...v0.3.0

0.2.8

Added

• A member who is signed in registers under the address on their
  membership. The registration form's E-mail field is filled in from the
  account, as Indico has always filled it in, and now carries a padlock saying
  Your STSA membership is registered under this address. So the registrations
  a member makes can always be matched back to them — and the member discount
  stays honest, because that discount is decided from the link between a
  registration and an account, and the link is made from this field.

  Any address on the account is accepted, not only the first. Indico looks a
  registration's user up with get_user_by_email, which matches secondary
  addresses too, so a member who registered under one of theirs is already
  linked to the right membership; refusing it would leave them with a
  registration they could no longer edit, because the address it already holds
  is one the form would no longer take.

  Three cases are deliberately left alone. Organizers, because adding a
  registration from the management area means typing that participant's address.
  Somebody else's registration, which is editable from the link in its
  confirmation e-mail — the person in front of it need not be the person it
  belongs to, and a member who opens one must not stamp their own address onto
  it. And invitations, whose address is the organizer's choice and which
  Indico writes into the registration whatever was submitted.

  A disabled input is a courtesy, not a rule, so the address is checked again
  wherever it actually arrives: as it is typed, when a registration is
  submitted, and when an existing one is modified. A hand-built request is
  refused the same way, with Indico's own This email address is not associated
  with your Indico account.

  The draft that carries answers across the trip to the login page now leaves
  the e-mail field out while the lock applies. Restoring the address somebody
  typed while signed out would put a value the server refuses into the one field
  they can no longer correct — and the form has already filled it in from the
  account they just signed in with, which is the address they are registering
  under anyway.

  There is a switch for it under STSA in the plugin settings,
  Register under the membership address, on by default. Switching it off
  removes the padlock and the check together.

0.2.7

Fixed

• The payment reminder dialog's summary now reads over two lines. The info
  box at the top of the dialog is as wide as the dialog itself, so the count and
  the note about who gets the mail ran together into one full-width line of
  small print — and the count is the part you most need to see before pressing
  Send. They are two paragraphs now.