26.1.1 Membership (MVP)

This release brings membership to the Studio, the admin app of appsolut ONE. An organisation describes where its people come from and which of them are members, and the Studio decides, for each person, which of its websites and apps they may use.

Registers

• Internal registers are kept in the Studio. Studio users add, edit, deactivate and reactivate entries by hand, or upload an Excel (.xlsx) or CSV file: they map its columns, read the "Validation report" and a preview, and confirm. An upload merges by member code and never removes anyone. 50,000 rows are written in under two minutes.
• An internal register can be downloaded as an Excel workbook, which can be edited and uploaded back as it is.
• An entry holds the member code and, as far as known, names, birth date, phone, postal address, status, groups and membership start. Each register says which statuses count as members.
• Challenge codes add a second proof at onboarding. The entries show "Challenge required" and "Code set", and whether a challenge code is required can be switched for an entry by hand or set for many entries with an upload. "Generate challenge codes" creates them for every entry that needs one, as an Excel file that can be downloaded once, ready for a mail merge. Codes can be replaced for selected entries or brought in with an upload. The Studio keeps only a hash of each code.
• External registers stay in the organisation's own system, and the Studio asks them live through the appsolut register API. The API key is stored encrypted. "Test connection" shows whether the register answers and how quickly, and names the cause when it does not.
• Groups can be set once for an external register, for everyone found in it.
• The register activity lists every change to a register and its entries, with the values before and after.
• An "Owner" can delete a register that is no longer used in the membership definition or a community.

Membership definition

• The "Membership definition" is the organisation's one ordered list of register assignments. A person is looked up from top to bottom, and the first register that decides wins, with the outcome "Qualifies" or "Refuses".
• Filters narrow which people an assignment decides: status, groups, membership start and minimum length of membership for an internal register, status and claims for an external one.
• While editing, "Eligible persons" counts the people the unsaved changes let in, per internal register. External registers are asked live, so they show "Not countable".
• A member code can be tested against the unsaved definition, with external registers asked live.
• "Save and publish" publishes the definition at once as a new version. The "Version history" keeps every saved version, read-only.

Membership check

• The membership check answers whether a member code and the facts that go with it belong to an eligible member: valid, not valid or unavailable. It runs when a person becomes a member (onboarding), at each of a member's sign-ins (login), and when a frontend's backend asks about someone (eligibility).
• The reason for a "Not valid" answer is shown only in the Studio, never to the person or the frontend.
• While an external register cannot be reached, members whose last valid check is less than 7 days old keep signing in on that result, under the grace rule.
• Failed checks are limited per member code, per applicant IP address and per frontend, so member codes and facts cannot be guessed. The ways one member code can be typed, such as in lower case or with a trailing space, count as one code, and checks sent at the same moment cannot slip past a limit together.
• An external register that finds a member code without names and birth date, with a status it does not count, passes the person on to the next register instead of stopping the check as unavailable.

Communities and frontends

• Communities are named filters over the members directory, by register, status, groups and claims. They can be created, renamed and deleted, and a member's communities follow from their last check.
• Frontends are the websites and apps an organisation's people use. Each has exactly one community, and with "Membership mandatory" only valid members of that community may use it.
• Frontend keys let a frontend's own backend call the Studio. A key is shown once when it is issued, and revoking it stops it at once.

Members directory

• The "Members directory" lists every organisation membership with search, filters, status and communities.
• The "Check lookup" lists the checks logged for a member code, with their mode, result and reason.
• A member's page shows their organisation membership with the names from the register, the frontend user who holds it, the frontends they used and the history.
• A membership can be deactivated with a reason. When a person asks for their data to be erased, "Anonymize now" removes everything that identifies them.
• When another register entry decides at a login check, the membership is relinked on its own, and the history shows it.

Members API

• POST /api/v1/members/eligibility answers, with the frontend key, whether a person is eligible for the calling frontend's community, without them signing in.
• GET /api/v1/members/me returns the signed-in member's own organisation membership and member data, read live from their register.

Community Portal

• A Community Portal connected with a frontend key checks member codes in its booking and redemption wizards through the Studio's membership check. When a register or the Studio cannot answer, the wizard asks the member to try again later and keeps everything they entered, instead of refusing them.

Studio users and organisations

• Studio roles decide what each Studio user may do in an organisation, from "Owner" and "Administrator" to roles for a single area.
• A public roadmap, where Studio users propose features, report bugs and vote on what comes next.
• The links in the Studio's emails for confirming a sign-up, accepting an invitation and changing the email address wait for a click on the page they open, so a mail scanner that opens them first no longer uses them up. A sign-up can also be confirmed with the code from the same email.
• Every invited Studio user without a password is offered to set up a way to sign in when they join.
• Only Studio users who may change an organisation's settings change its name and logo. A new logo shows at once, and a failed upload keeps the old one.
• Dates and times show in the viewer's time zone and in the language they use the Studio in.