Sign-ins and roles

Sign-ins are not household members

Mirra keeps two separate lists of people, and it is worth being clear which is which before you add anybody.

Household is about faces: the people a screen recognises, greets, and shows a personalised agenda to. They have no password and cannot sign in to anything.

Sign-ins are accounts. An email address, a password, and a role that says what the account may reach. Somebody can be on both lists, on one, or on neither — the kitchen porter who edits the menu board has a sign-in and no face; a child on the wall recogniser has a face and no login.

Household members count against your plan. Sign-ins do not.

Adding a sign-in

1. Open Account

   From the account menu. The panel is called "Who can sign in", beside Change password.

2. Press "Add a sign-in"

3. Fill in a name, an email address and an initial password

   At least eight characters. The password is shown as you type rather than masked, on purpose, so you can read it out to somebody standing next to you.

4. Choose what they can reach

   Full access or Menus only. The line under the picker describes whichever one is selected.

5. Press "Create sign-in"

   They can sign in immediately.

Mirra does not send an invitation email. There is no outbound mail here, so nothing arrives in their inbox — you set the initial password and pass it on yourself. Pretending to send an invitation that never arrives would be worse than being plain about it. They can change the password from their own Account page once they are in, which signs out every other session they had.

The two roles

There are two, and the underlying test is written as "is this exactly a full-access account?" rather than "is this a menus-only one?". A role that is misspelt, set by hand in the database, or added later therefore resolves to less access rather than more.

Full access

Screens, scenes, schedules, photos, billing — everything. This is what every account has ever had.Default: What every existing sign-in already is

Menus only

Signs in, edits menus, and sees nothing else. Intended for kitchen and floor staff.Default: Pre-selected on the Add a sign-in form

Exactly what Menus only reaches

Menus only exists for a member of staff who looks after a menu board and nothing else — the person who changes tonight's prices without also being handed the screens, the billing and the emergency broadcast.

It is written as a list of what they may reach rather than a list of what they are kept out of. Anything not on that list is refused, including pages that do not exist yet.

• Pages they can open: Menus, their own Account page, the help centre and the support page, sign in, sign out, the privacy policy and the terms.
• Any other page in the portal sends them back to Menus.
• Behind the scenes they reach their own session, their own password, their own profile picture, menus, and support — a menu-only account is very often the person standing in front of the board that has stopped working halfway through service, so it can raise a ticket. Everything else answers "This account can only manage menus."
• Their navigation bar has one destination on it, and their account menu holds nothing but their own details and the help centre — but that is presentation. The refusal happens on the server, because hiding a link is not access control.
• They cannot download the household's data export, cannot change retention settings, and cannot reach billing.

Changing somebody's role

1. Open Account and find them under "Who can sign in"

2. Change the picker beside their name

   It saves as you change it, and confirms what they are now.

• You cannot change your own role. Ask another full-access account to do it.
• A super admin's role is not managed from here. They operate the install; they are not a member of your account. Their picker is disabled rather than left to fail.
• The last full-access account cannot be demoted. An account left with only menus-only sign-ins has lost its screens, its billing and its ability to make another owner, and there is no self-service way back.

A role change signs them out at once. Every session they held stops working on its next request rather than at their next sign-in — a demotion that takes effect in seven days is not a demotion.

Removing a sign-in

1. Press Remove beside their name

2. Confirm

   The prompt names the address and says plainly that they will not be able to sign in again.

• You cannot remove yourself. Closing the account is the thing you are looking for.
• You cannot remove a super admin.
• You cannot remove the last full-access account.

Removing a sign-in removes the login and nothing else. Anything they made stays, and if they were also linked to a Household member that person stays on the wall recogniser with the link simply cleared.

Limits, and what gets written down

• An account can hold 50 sign-ins. Well past a kitchen's worth of staff, and low enough that a runaway script is noticed.
• Email addresses are unique across the whole install rather than per account, because that is what the sign-in form looks up. If one is already in use you are told so rather than left staring at an unexplained failure.
• Creating a sign-in, changing a role and removing a sign-in are each written to the account activity log, with who did it and the address it came from. An account appearing, or an account changing what it may touch, is exactly the sort of thing somebody has to reconstruct six months later.
• Sign-in attempts are rate limited two ways: ten tries in fifteen minutes against any one email address, and forty in fifteen minutes from any one source address. The two budgets are separate so that a shared office connection cannot lock everybody out of their own accounts.

What only a full-access account can do

Managing sign-ins is guarded more narrowly than the rest of the portal. Creating an account and deciding what it may do is the one operation where getting the gate wrong hands over everything else, so it asks specifically whether you are an owner of this account rather than merely whether you are unrestricted.

Changing the retention windows and closing the account are held to the same standard.

Everybody, including a menus-only account, can change their own password and their own profile picture. An account whose holder cannot change its own password is worse for everyone than one that can.