# The developer mode
mmo.admin adds a layer to mmo.client's display modes (`docs/Modes.md` there): `dev`, toggled with **Ctrl + Alt + D**,
offered to users who hold `modes.dev`. Once the layer is on:
- **a button in the top bar** counts the page's tickets and the checks left to do on it. It opens the side panel, which
shows:
- the page's tickets: those whose `pages` name the page, those that a checklist item about the page verifies, and
those filed on this server that are not on the board yet;
- the checklist items whose `url` is the page, which you can tick there;
- « Next page to check », which walks through a checklist page by page;
- **pins** on the elements a ticket points at (`MMO.overlay`);
- **« New ticket »**, which captures:
- the type and urgency;
- an element the user points at;
- a screenshot, only for `dev.tickets#screenshot`. It is checked by default for those users and is stored only on the
server;
- the page context: modes, browser, release and recent errors.
The ticket gets the label for filed tickets, its `pages`, `reportedBy`, and a `claude` block for an agent. Users who
hold `dev.tickets#triage` are notified (mmo.client's notification centre);
- **the « Developer » menu** (`developer/`): mmo.admin's pages (Overview, Boards, Checklists). They sit next to the pages
an application puts in its own `developer/` folder (logs, database…); when both have a page of the same name, the
application's wins;
- **the bug button** of an application can post to `MMO.config.paths.developerReport`. That files a ticket for any
logged-in user, never with a screenshot.
## Scopes and roles
| Scope | Allows |
|---|---|
| `modes.dev` | turning the layer on; the Developer menu |
| `dev.boards` (`#write`) | the board and the page's tickets (changing the board) |
| `dev.checklists` (`#check`) | the checklists and the page's checks (ticking them) |
| `dev.tickets#create` / `#comment` / `#screenshot` / `#triage` | filing / commenting / attaching a screenshot / being notified of each new ticket |
| `dev.tools` | the application's developer tools |
Roles are stored per instance. Run `php admin.php developer roles '--assign=marc:project lead,jeanne:tester'` on every
instance: it creates or updates the roles `developer`, `tester` and `project lead`, gives them their scopes and their
default layer (`modes: {layers: [dev]}`), and gives them to the listed users.
`BoardController` and `ChecklistController` accept `sudo|dev.boards` as their `scope`, so either scope grants access.
## Where tickets go
| Machine | `DeveloperController.store` | A ticket filed from a page |
|---|---|---|
| development | `board` | goes straight onto `{boards}/{board}.json`, which git versions with the application -- the board the user picked in Développeur > Boards (`api/current-board.json`), else `board` |
| server | `inbox` | goes into `{folder}/inbox/{board}.json`, in a git repository of its own (`{db}/developer`, apart from the clients' data). Each change is committed, and screenshots are git-ignored |
To bring a server's inbox onto the board on your machine, run `php admin.php developer pull --target=dev [--dry-run]`:
1. it clones the server's repository over ssh, using `deploy.ssh.config` (`--remote=` gives the address directly);
2. it adds the server's tickets to the board, with their `origin`;
3. it adds their comments;
4. it marks them `pulled` and pushes that back.
An entry already on the board is never added twice. On a server, the cues read the release's board, which is read-only
there (`BoardController.readonly`), together with the server's own inbox.
A future database store would implement `iDeveloperStore` and live in a database of its own, never the application's.
## The api
```
GET api/developer/page.json?route=settings/users[&member=Marc][&done=1] the page's tickets and checks
GET api/developer/todo.json[?checklist=][&member=] the pages with checks left to do
POST api/developer/tickets.json {title, description, type, urgency, route, url, target, context, screenshot}
POST api/developer/reports.json {title, description, url, context} a user's report
POST api/developer/tickets/{ticket}/comments.json {body}
GET api/developer/screenshots/{id}.png
GET api/developer/summary.json the Overview page
```
`php admin.php developer pages [--write]` fills in the board tickets that have no `pages`. It takes the URLs from:
- the checklists' recipes;
- the ```` ```check ```` blocks in the ticket discussions;
- the ticket descriptions.
It keeps only routes that are real pages, and a page that has moved goes to its new address.