This release brings Login with appsolut: the one sign-in an organisation's people use for all of its websites and apps. Their first sign-up also makes them members. Alongside it, the Studio gets permission sets and units for its Studio users, claims in internal registers and the member code query.
The sign-in surface
- The sign-in, sign-up, password reset and support screens carry the organisation's sign-in branding: layout, colour and dark-mode colour, logo, an optional side image, links to the privacy policy and imprint, and the support address. They are in English and German, following the browser's language, and follow its light or dark setting.
- People sign up with any email address they own. A 6-digit verification code confirms it, and the account exists only once the code matches.
- At sign-up, people prove their membership with their member code, names, date of birth and, where the organisation sends one, their challenge code. Whoever signs up without it confirms it later under "Confirm your membership".
- At every later sign-in, the Studio checks the membership again. The person enters nothing.
- Someone who cannot sign up or onboard sends a support request with "Request support" to the organisation's support address.
- A forgotten password is reset by link. Saving the new password ends every session of the frontend user on all of the organisation's frontends.
- "Sign out" signs out of this browser, and "Sign out of all websites and apps" out of every website and app of the organisation, on every device.
- Someone signed in to one frontend is signed in to the next one of the same organisation without entering anything, and a sign-in that took too long restarts by itself instead of showing an error.
- A security check and limits on failed attempts protect the screens from automated attacks.
Frontends
- A frontend's "Sign-in" card sets its app type, redirect URIs and start URL. Saving it sets up the frontend's sign-in client, whose secret is shown once and can be replaced with "Rotate secret".
- In this release, internal frontends that are web apps sign users in. External frontends and the other app types follow in a later release.
- The frontend learns the frontend role of each sign-in, "member" or "authenticated", with the frontend user's email address and names.
- Under "Released claims", Studio users choose which claims a frontend's backend may read about its members. Nothing is released until someone releases it.
- "Disconnect frontend" switches a frontend off: it signs no one in, and its frontend keys are refused. "Reconnect" restores everything.
- The developer documentation describes Login with appsolut for the people who build frontends.
Community Portal
- The Community Portal signs its visitors in with Login with appsolut. Every navbar design and the mobile menu show "Log in"; signed in, the header shows the person's first name and "Log out".
- "Log out" opens the sign-out screen of the sign-in surface, with "Sign out" for this browser and "Sign out of all websites and apps" for every website and app of the organisation.
- If a sign-in cannot be completed, the person returns to the page they started from, with a short notice. If the Studio cannot be reached, the Portal's pages still open.
- Signed-in members read the member-only pages, and the booking and redemption wizards no longer ask them for their member code. Names and email come from their account, and the date of birth from their register. A booking also suggests their phone and postal address.
- For signed-in people who are not members yet, the wizards take names and email from their account and ask for the member code as before.
- In the travel and the benefit "Configuration", "Code proof allowed from" decides who may still prove membership with a member code instead of signing in as a member: "Everybody", "Signed-in users" or "Nobody (sign-in as a member only)". It applies once the Portal requires signing in to book or redeem, and where it applies, the member code is mandatory. Whoever may not use one sees "Log in to book" or "Log in to redeem".
- When the organisation ends someone's access, the Portal signs them out within an hour at the latest.
- appsolut switches sign-in on for each Portal together with its organisation.
Frontend users
- "Frontend users" lists everyone with an account, with search and filters. "Block" shuts a frontend user out of every frontend and ends all their sessions; "Unblock" lets them sign in again. Their membership stays.
- A frontend user's page shows their profile, their organisation membership, the frontends they use, their recent sign-ins and what Studio users did with the account.
- "Export data" downloads a file with what the Studio holds about a frontend user's account, for a data access request under the GDPR.
- Frontend users and Studio users have separate accounts: an account for a frontend never signs anyone in to the Studio, even with the same email address.
Studio users and roles
- Five Studio roles: "Owner", "Administrator", "Manager", "Editor" and "Stakeholder", each with its own badge colour. "Manager" and "Stakeholder" are new, and the role "Member" is now called "Editor", since members are the people in the members directory.
- The area roles "Community manager", "Frontend manager" and "Frontend user manager" give way to permission sets. Whoever held one is now an "Editor" with the matching set, such as "Community: manage", and keeps exactly the access they had; pending invitations into an area role carry the set too.
- Permission sets decide what a "Manager", "Editor" or "Stakeholder" may do in the areas "Community", "Frontends" and "Frontend users", to read or to manage. Besides the predefined sets, owners and administrators compose the organisation's own. A set is assigned with a reason and, for example for a vacation cover, a period.
- Units group Studio users, such as a department. A "Manager" invites new Studio users into their units and looks after them.
- With an area's read permission, a Studio user sees its pages without anything that changes them.
- Owners, administrators and managers manage the invitations they could send themselves. An invitation lapses 7 days after it was sent or last renewed, and one whose sender may no longer send it shows "Needs renewal".
- "Billing" in the sidebar shows only to owners.
- The Studio says "organisation" and "Studio user" throughout, in English and German.
- The personal home shows a card for each of your organisations, with its logo, your Studio role and, if you may read the members directory, its member count.
Registers and membership
- Internal registers hold claims, such as an employee group or the working hours per week. A register's settings declare them, the entry form, upload and download carry them, and assignments and communities filter on them as on an external register's claims.
- The postal address of an internal register entry has a country, chosen from a list. An upload takes the country's code or its name.
- The new "Member code query" shows how the saved membership definition decides one member code right now, with the deciding register's member data and claims by name. Nothing is logged. "Query this member code" in the check lookup opens it.
- The member code query replaces "Test a member code" in the membership definition, which tested a member code against unsaved changes. The editor keeps the preview of eligible persons before saving.
- The claim "Working hours per week" holds hours, such as 38.5 h, instead of a percent.
- An external register that answers a claim with no value no longer counts as unavailable.
- An external register that knows a member code with a status it does not count, but sends no person data, now passes the code on to the next register, instead of stopping the check.
Lists and pages
- Every list's pager has "Rows per page", with 10, 20, 50 or 100 rows, and each list remembers the choice.
- A row's main column opens its detail. In an internal register, the member code opens the entry, read-only for Studio users who may only read.
- An internal register's settings, claims and deletion are behind the gear button "Settings" in the page header, so the entries come first.
- Each page's main list uses the full width, and form dialogs are as wide as their form needs.
Signing in to the Studio
- The security check on the Studio's sign-in forms shows its challenge when it needs a click, and offers "Try again" when it fails, instead of waiting forever.
- Email links that confirm an address or reset a password ask for the email address or the new password before they take effect. Mail security scanners that open links and press buttons can no longer use them up.
Website and documentation
- The website has a front page, a FAQ, a blog, this changelog, legal pages with an imprint, and prices in euros, net with a VAT note, in English and German.
- The documentation has three sets: the Studio manual, the Portal documentation and the developer documentation with its API reference.
- The contact form is protected by a security check.