Release 26.1.1, "Membership (MVP)", brings the heart of the Studio, the admin app of appsolut ONE: an organisation describes once where its people come from and which of them are members, and the Studio decides, at every sign-in, who may use which of its websites and apps. This post walks through the highlights with Pannoniqa AG, the fictional organisation of our documentation. The changelog entry lists every change, and the post From member lists to communities: rule-based membership explained explains the idea behind it at length.
Registers: where your people come from
A register is a list of people who may become members, each identified by their member code. Pannoniqa keeps three. "SAP HR", its HR system, is an external register: the people stay there, and the Studio asks it live through the appsolut register API whenever a check needs it. "Test connection" shows whether it answers, how quickly, and why not when it doesn't. Connect and test an external register has the details.
"Retirees" and "Works council" are internal registers, kept in the Studio. HR uploads the retirees once a quarter from an Excel file: it maps the columns, reads the "Validation report" and the preview, and confirms. The upload merges by member code and never removes anyone, and 50,000 rows take less than two minutes. The works council is so small that it is kept by hand. Upload and download entries explains the upload.
A member code alone is often easy to guess. Where that matters, a challenge code adds a personal secret that Pannoniqa sends by letter: "Generate challenge codes" downloads the codes once as an Excel file for the mail merge, and the Studio keeps only a hash of each. See Challenge codes.
One membership definition decides
The membership definition is one ordered list of register assignments. A person is looked up from the top, and the first register that decides wins, with the outcome "Qualifies" or "Refuses". At Pannoniqa, an active employee is decided by "SAP HR". A works council member on leave does not pass SAP HR's filter for the status "Active", so "Works council" decides instead. A retiree is decided by "Retirees". The manual page Membership definition walks through this example.
Filters on each assignment narrow it down, by status, groups, membership start or minimum length of membership, and by the claims an external register returns. While editing, "Eligible persons" counts how many people the unsaved changes let in. "Save and publish" publishes the definition at once as a new version, and the "Version history" keeps every one. Save and version history describes both.
Checked at every sign-in
The membership check walks the definition when a person becomes a member, at each of their sign-ins, and when a frontend's backend asks about someone. It answers valid, not valid or unavailable, and only the Studio sees the reason why someone is not valid. See Membership check.
When SAP HR is down for maintenance, Pannoniqa's members keep signing in: their last valid check counts for 7 days, as Grace rule explains. Failed checks are limited per member code, per applicant and per frontend, so nobody can try member codes until one fits. Rate limits lists the limits.
Communities and frontends
A community is a named filter over the members directory. Pannoniqa has "All staff", which serves the Pannoniqa Portal, and "Active employees", which serves the Pannoniqa App. Johann Gruber, a retiree, may use the Portal but not the App, and nobody had to put him on a list for that: his communities follow from his last check. See Communities.
Each frontend has exactly one community, and with "Membership mandatory" only valid members of that community may use it (Frontends). A frontend's own backend calls the Studio with a frontend key, which is shown once when it is issued (Frontend keys). Through the Members API, the backend asks whether an applicant is eligible before it accepts a booking, or reads the signed-in member's data live from their register. A Community Portal connected with a frontend key checks member codes in its booking and redemption wizards that way. When a register cannot answer, the wizard asks to try again later and keeps everything the member entered.
The members directory
The members directory lists every organisation membership with its status and communities (Members directory). When a retiree calls because she cannot sign up, the "Check lookup" shows every check of her member code and why it failed. A member's page shows the membership, the frontend user who holds it, the frontends they used and the history. A membership can be deactivated with a reason, and on an erasure request "Anonymize now" removes everything that identifies the person, as Anonymize a membership describes.
Also in this release
- A public roadmap, where Studio users propose features, report bugs and vote: see Roadmap and feature requests.
- The links in the Studio's emails wait for a click on the page they open, so mail scanners that open links first no longer use them up.
- Studio roles decide what each Studio user may do in an organisation, and dates and times show in the viewer's time zone.
Try it out
The changelog entry for 26.1.1 lists every change, and the Studio documentation describes how to use them. If something does not work the way you expect, let us know.