MusterContents

The admin console

For HR and administrators. It is at /admin/ on the same address as the app, and you sign in to it with your username and password, the same ones as the app. Sign in with a token instead, under the box, is there for the very first admin, before anybody has a password. Somebody on hold cannot sign in here either.

It is deliberately plain: no framework and no build step, so it cannot drift a build behind the thing it manages. It wears the app's colours, and the switch at the foot of the menu turns it to Daylight and back; this browser remembers which. HR and administrators reach it from the app, in Settings › Account.

The three roles

Three, fixed. One organisation per database file already separates clients, so what is left inside a file is a much smaller question: your own work, or the organisation's.

RoleSees
MemberTheir own entries, travel and pay
HRThe organisation's timesheets and its people. Not anyone's travel: presence is personal
AdminEverything HR sees, plus the system: tokens, jobs, the store

The three are ordered, and the order is a rule: nobody may hand out a role above their own, or edit somebody who already holds one. Without it, "HR manages the company" would quietly include "HR appoints admins".

A menu item you are not entitled to is hidden, not shown and refused: a menu item that answers 403 teaches people the console is broken.

Who may change the overtime rules

Contracted hours and overtime bands are normally HR's. A member may change their own: the app saves the change with a warning that they are normally set by HR, and the audit log records it with what it was before. Somebody else's rules, and the employer's agreement for everyone, stay with HR and administrators.

Corrections are kept

Every edit, delete and HR correction to an entry is kept whole, with what the entry said before, and so is every clock-in, clock-out and pause as it was pressed. A person whose entry you correct sees on it that it was corrected by someone else, and that what it said before is kept.

What each screen is for

The menu groups them by what they are about: Time, Jobs, People and System. The screen you are on is in the address, so reloading the page or pressing Back keeps your place.

ScreenWhat it is
DashboardThe store at a glance. Account location sets the currency figures are shown in and how numbers are punctuated, and nothing else. It changes nobody's hours, rates or overtime; those are the employer's rules, not the country's
All timesEverybody's entries. The app only ever shows a person their own; this is the one screen that crosses people
Customers, Projects, Activities, TagsThe things entries are recorded against. A project's job code is the order number that reaches the timesheet
SitesWhere the work happens, and the tags on their gates
UsersThe people, what each may do, and the invitations that create them
SecurityTokens, access links and passwords. Admin only
RolesThe three, described
DataEvery table as it is on disk, read-only
AuditWho did what, and what it was before
DoctorWhat this box is and whether it is well

Adding a customer, project or activity

The form under the list adds one, and it can be booked straight away: whatever the console adds is accepted and open to everyone as it is made. A project needs its customer, and may have a Job code.

An activity under a new name says what its hours are paid as. Hours are paid by the activity's name, and the pay rules know only their own names - Labour, Travel, Sick and the rest. So a new name, like Survey, has to be given one of them under Paid as; left as Its own name, only a name the rules already know is accepted. The row then shows paid as …. A new activity appears in everybody's job dropdown straight away.

A row that is waiting is marked waiting - nobody can book it or not open to everyone, with an Approve and publish button: one press, and everybody can see it and book to it. If somebody proposed it from the app, the row also says added by and their name.

A row somebody added for themselves from the app (see Project changes from the app) is not waiting. It says whose it is - Sol's own - nobody else sees it - and is already theirs to book to. It has an Open to everyone… button instead, for the day it should become the company's. That button asks first, naming the person and saying every member will see it in their pickers; say Cancel and nothing changes.

Changing a customer, project or activity

Click its row. It opens in the form under the list, where you can rename it, give a project its job code or move it to another customer, and Hide it from the pickers (or Show again). Nothing is ever deleted: a hidden job keeps every entry recorded against it.

Entries point at a job, not at its name, so a rename reaches every entry that already carries it. Two changes are refused, because they would change pay rather than a label:

Every change is written to the Audit, with what it was before.

Adding someone

Users › Invite someone. Give a Username, Their name, optionally an Email, a Role, and the Time to accept - 1, 3, 7, 14 or 30 days - then press Invite. The line under the button says whether this box sends email; with no mail set up, an invitation is a link you copy and hand over, which is a supported way to run Muster.

The link that comes back is shown once. It is stored only as a salted hash, so nothing can show it again, but you can always withdraw it and invite them afresh.

An invitation carries a claim, not a token. It is single use, it lapses, and it buys a credential on their own device. Opening the link asks them to make a password and spends nothing; only their press on Create password and sign in does, so a work mail system that checks every link cannot use it up. Nothing about that person exists until that press, so a withdrawn invitation leaves no account behind.

Invitations, under the form, lists each one with its state: waiting, accepted, lapsed, or cannot be used, with the reason - the account has been signed into since, or renamed, for instance. A waiting one has Withdraw. A lapsed one - withdrawn, or never taken up - has Remove, for an admin only, which asks first; the audit keeps what it was. An accepted one stays, because it is how the account came to exist.

That is also why invitations live on the Users screen with the people, while tokens and passwords live on Security: issuing an invitation is HR's job in a way that handing out a bearer token is not.

Somebody's record

Click Edit on a person in Users. Their Username, Display name, Name on the payslip, Employee number, Timezone, Role and Active are saved with Save. The list shows, beside each person, any of inactive, on hold, access ends and a date, and projects from the app; the features they have switched on in the app; and how many tokens they hold.

Project changes from the app

A tick, Project changes from the app, for HR or an admin to give - never for somebody who outranks you. It is saved as soon as you tick it, and audited.

With it, that person adds their own clients and projects in the app, ready to log time to at once and seen by nobody else, renames or hides their own, and adds their own kinds of work, which are always paid as ordinary work, like Labour. They can never change a job HR has opened to everyone. It is meant above all for somebody self-employed; choosing Self-employed in the app gives nobody this. The app's side is in Jobs.

Access: an end date, and Revoke and hold

For an admin, on anybody who is not an admin. The line at the top says where they stand: Can sign in, with no end date, Can sign in until the end of …, On hold now, or Switched off. Each button acts at once and is audited on its own; none waits for Save.

On hold means they cannot sign in: their end date has passed, or they hold no live token an admin issued (or that an invitation or access link made). Their app and console sessions stop at their next request, and signing in tells them to ask you. An admin is never on hold: revoke an admin's tokens one at a time instead.

On Security, and admin only. Everything that can be used to sign in is here; who somebody is stays with the people.

Tokens

Each row says whose it is and what it is called, how it came to be - issued by an admin, app sign-in, console session, from an access link, from an invitation - and what it is on, such as Android phone · Chrome, noted from the browser the first time it is used: the kind of device and browser only, never a model or a place. Then when it was last used, when it was issued and when it expires. The token this console is using says this console.

Rename names it again, and the rename is audited with its old name. App sign-ins and console sessions are named for you and have no Rename. Revoke names the token in words and asks before it goes; revoking this console signs you out.

To issue one: pick the Person, give it a Name - whose it is and what it is on; Joe's phone and the like are offered, and it will not issue without one - and choose when it Stops working. Never is right for a wall-mounted terminal and wrong for most things. Then either:

An access link signs a phone in without a token ever sitting in a mailbox. Pick the person, name and expiry as for a token, put Their email, to send a link if mail is set up here, and press Make an access link. It is shown once, to copy, and sent too if you gave an email, under the same hourly limit as invitations.

When they open it, the app shows their name and asks them to make a password - or, if they have one, only to sign in on that phone. Opening the link spends nothing, so a work mail system that checks every link cannot use it up; their press does. It then makes the token you described on that phone. A link works once, within two days, and making a new one for somebody lapses their last.

Unlike an invitation, it works for an account that has already been used: it is how somebody gets back in after a lost phone or Revoke and hold. It never replaces a password they already have; for a forgotten one, use Set password below.

Passwords

Pick the Person; the line under it says whether they have a password yet. Type a New password and press Set password. A password does not authenticate anything by itself: it buys a token, and the token is what every request carries. There is one auth path, and the password box is the front of it. Passwords that are guessed first are refused here as they are in the app.

A new password does not stop a device that already holds a token. When the reason is a lost phone rather than a forgotten password, tick Also revoke their existing tokens. That leaves them holding no token, so they are on hold until you send an access link or issue a new token.

Sites and gate tags

A site is its own thing, not an attribute of a job: jobs move between sites, and sites carry several jobs.

Add a site with a name, a customer, a postcode and an address. The postcode is whatever a person would write on an envelope. It is typed, never derived from a position and never checked against a pattern: a UK unit postcode is about fifteen addresses, a US ZIP is a town, a Mexican CP is a neighbourhood, and Ireland had none until 2015, so a rule that passes one is wrong for the next. Deriving one from a GPS fix would also mean sending somebody's exact position to a mapping company on every clock-in.

A gate tag is an NFC tag or a link carrying #site=…. Tapping it tells the app where; the phone in somebody's pocket already says who. It may corroborate a day. It never decides one, and it never touches pay. A retired sticker or a tag from another company is ignored quietly, so that somebody can always clock in exactly as they would have anyway.

Audit

Appended by every change made in the console, with what the value was before. There is no route that edits or deletes a line of it, because a log somebody can tidy is not a log.

Data and Doctor

Data shows every table as it is on disk, read-only. Seeing everything and editing anything are different privileges, and a grid that can write is a way to break the pay record with a typo.

Doctor reports what the box is and whether it is well: the facts you would otherwise connect to the server to gather.


Back to the manual