# Part 1 · The Service

## 1.1 Opening a lens

**Who** · `Service`.

**Where** · **Open a lens** on the platform's home, the "No lens" chip at the top, or the eye on a workspace's row in
**Workspaces**.

**Before you start** · Why you need to look, and whom to see the workspace as: usually the person who asked for help.

**The steps**
1. Choose the workspace, then the person to see it as. You see what they see and may do what they may.
2. Say why, in at least ten characters. The workspace will see it.
3. Choose how long (30, 60 or 120 minutes; it shows when it ends) and what you can do: **Look only**, or **Look and
   change**.
4. Press **Open the lens**. Unless you confirmed your password in the last 15 minutes (the setting **Password re-check
   window**), it is asked first, over the page (S8's step-up).

**What the record shows** · The lens log, the sign-in log and the workspace's own audit log each keep the lens.

**Who is told** · The workspace's Owners see a notice while it is open (1.5). E-mail comes later.

**What can go wrong**
- *"… is paused, so it can't be looked into."* Reactivate it first (1.4), if that is what is needed.
- *The person I want isn't in the list.* Only active members are; someone turned off can't be seen as.
- *"That password isn't right."* Your own password, the Service's, asked in the "Confirm it's you" dialog.

## 1.2 Working inside a lens, and ending it

**Who** · `Service`.

**Where** · Every page, under the banner: the workspace, the mode, when it ends, whom you see it as, and why. Amber
for look only, red for look and change.

**Before you start** · An open lens.

**The steps**
1. Use the workspace's pages as the person would. Looking only, nothing to change is drawn, and any change is refused.
2. Press **End the lens** when you're done. It also ends by itself at its time, when you sign out, or if the workspace
   is paused.

**What the record shows** · Every change you make inside a lens names the lens and is recorded as Tutelora support's.

**Who is told** · The notice in the workspace goes when the lens ends.

**What can go wrong**
- *"That isn't open inside a lens."* The platform's pages, switching workspace and your account's pages wait until the
  lens ends.
- *"This lens only looks: nothing was changed."* Open a new lens to look and change.
- *A page isn't open to me.* The person you see it as can't open it either.

## 1.3 Reading the lens log

**Who** · `Service`.

**Where** · **Lens log** in the menu.

**Before you start** · Nothing.

**The steps** · Read when each lens opened, on which workspace, as whom, how, why and how it ended. Filter by
workspace, mode or date; search the reasons; *Open* shows the ones open now.

**What the record shows** · Lenses are kept for good, closed once and never changed.

**Who is told** · Nobody.

**What can go wrong**
- *A lens shows as open after I closed the browser.* It ends by itself at its time; the sweep closes it within a minute.

## 1.4 Pausing and reactivating a workspace

**Who** · `Service`.

**Where** · **Workspaces** › the toggle on a workspace's row.

**Before you start** · A reason of at least ten characters.

**The steps**
1. Press the toggle, say why, and confirm.
2. Paused, nobody can work in it and any lens on it ends; its records are kept. Reactivated, its people can work in it
   again.

**What the record shows** · Each change is kept with its reason, in the workspace's status history and audit log.

**Who is told** · Its people see that it is paused when they next open a page. E-mail comes later.

**What can go wrong**
- *"Give a reason of at least 10 characters."* Say a little more.

## 1.5 When support looks into your workspace (Owner)

**Who** · `Owner` · anyone whose role includes seeing when support looks in.

**Where** · A notice under the header of every page while a lens is open; **When Tutelora support looked in** on the
home page.

**Before you start** · Nothing.

**The steps** · Read the notice: whether support is only looking or can change things, until when, and why. The home
page lists the recent lenses and whom each saw the workspace as.

**What the record shows** · The workspace's audit log keeps each lens, and every change made through one, as Tutelora
support's.

**Who is told** · You are: that is this notice.

**What can go wrong**
- *I didn't ask for help.* The reason says who did. If something isn't right, contact Tutelora.

## 1.6 Naming, checking and moving the Service (operator)

**Who** · `Operator`.

**Where** · The command line on the server.

**Before you start** · On a new installation, nothing: the first step makes the account. On one with people already, an
account can be named instead (step 2).

**The steps**
1. `php artisan service:create <e-mail> --first="…" --last="…"` makes the Service on a new installation: its account and
   its identity, with a password shown once. It is refused once there is a Service.
2. `php artisan service:identity <e-mail> --set` names an account that already exists (in `.env`).
3. `php artisan service:whoami` says who it is, the e-mail masked.
4. `php artisan service:reset` gives it a new password, shown once.
5. `php artisan service:transfer <e-mail>` moves it to another account; the old one loses it at once.

**What the record shows** · Resets and transfers are in the sign-in log.

**Who is told** · Nobody.

**What can go wrong**
- *Nobody is the Service after a deploy.* `SERVICE_IDENTITY` is missing from that server's `.env`.
- *The web won't delete the Service or change its e-mail.* On purpose: only these commands change it.

---

## 1.7 Making a workspace

**Who** · `Service`.

**Where** · **Workspaces** › **New workspace**. On a new installation the empty list offers it.

**Before you start** · The worker is running, so the invitation goes out. You know who will run the workspace, and their
e-mail.

**The steps**
1. Type the workspace's name, and its Owner's first name, family name and e-mail.
2. **Make the workspace**, and your password when it asks.

**What the record shows** · The workspace appears on the list. Its audit log has "Workspace made, and its Owner named".

**Who is told** · The Owner. Without an account they get an invitation, which names the company rather than you, and
which works for the days your platform sets. With one they get an e-mail saying the workspace is theirs.

**What can go wrong**
- *"The Service can't run a workspace."* That was your own address. Name someone else.
- *The invitation never arrives.* The worker isn't running; the e-mail log says what happened.

---

## 1.8 Letting people sign up by themselves

**Who** · `Service`.

**Where** · **Platform settings** › **Sign up**.

**Before you start** · It's off as shipped. Decide whether your product should let anyone start a workspace.

**The steps**
1. Turn **Self sign-up** on. The sign-in page now offers it, and `/sign-up` opens.
2. Leave the other figures unless you have a reason: how long a code works, how many tries, how many sign-ups from one
   network in an hour.

**What the record shows** · The setting's change is in the audit log. Each workspace made this way has "Workspace made,
and its Owner named", saying it came from a sign-up.

**Who is told** · You, by e-mail, with each new workspace's name. That's a rule you can turn off under Notifications.

**What can go wrong**
- *Sign-ups from a throwaway address are refused.* On purpose: the domains are the list "Throwaway e-mail domains", under
  Input Fields, and you can add to it.