Projects

A project is the box everything lives in: cases, suites, runs, plans, settings, the Steps Database, the bin. Every record belongs to exactly one, and every request acts in exactly one. What you may see is decided by membership — you read a case because you are a member of its project — the model Testomat.io’s projects use. A company can stand above projects with people of its own, and this does not change: a company role opens no project, only membership of it does.

Every account has a default project, provisioned the first time the account is seen. Until you make or are invited to another, it is where everything goes, and nothing about the API changes for you — every request without a project named lands there.

Naming the project

X-Plune-Project: <id>

Every scoped route reads this header. Absent, the request acts in your default project. The ids come from one place:

GET /v1/projects   → 200

{
  "projects": [
    {
      "id": "u-shop::default", "name": "Checkout", "role": "owner", "createdAt": "…",
      "lastRun": { "at": "…", "total": 20, "passed": 19 }, "company": null
    },
    {
      "id": "9c4e7d10-…", "name": "Mobile app", "role": "member", "createdAt": "…", "lastRun": null,
      "company": { "id": "d662bdb4-…", "name": "Acme QA" }
    }
  ]
}

Oldest first, with your role in each and its newest run — when, how many results, how many passed — or null before the first one, and the company it is in, or null for a personal project. /v1/projects is the one surface that stands outside a project — it takes no header, because it is how a client learns which ids it may put there.

A project you are not in answers 404

X-Plune-Project with the id of a project you are not a member of answers 404 with the same body an invented id gets — project '<id>' not found. Existence is never confirmed to somebody outside it, the same rule every record follows.

Making one

POST  /v1/projects        { "name": "Mobile app" }   → 201  you are its owner
PATCH /v1/projects/{id}   { "name": "Checkout" }     → 200  an owner of THAT project

A new project is empty: settings, tags and the Steps Database are per project and start blank. The name is 1 to 100 characters; a member who tries to rename is told project owner only (403), a stranger gets the 404 above. Your default project is born named default — rename it on Settings → General once, and the switcher, the invitation mail and the token list say the name from then on.

The Projects page

Projects (/projects) lists every project you are in. The Plune mark and All projects in the switcher lead here from anywhere; the bare address of the dashboard comes here too when you are in more than one project, and opens the project straight away when you are in one.

Each card names the project, your role in it and its last run — when, and how much of it passed — or No runs yet. The project this browser opened last is marked Last opened and comes first, the others by name.

When you are in a company, or in one of its projects, the page groups the projects by company. Personal comes first — every project in no company, a colleague’s personal project you were asked into among them — then each company by name, under the building, with how many people it has, your role in it and Open company → to its page. Inside a group the order is the one above. A company where you are in none of its projects yet has a line of its own and the way to its page, where you join one; a company whose project you are in without being in the company has its name and no link. With no company at all, the page is one list.

Cards or Table is the switch on the right, and the browser remembers which you chose. The table adds the day each project was made.

Search narrows the list by name as you type — inside the groups, and a group with nothing left goes — and the count beside it becomes 2 of 3. When nothing matches, the page says so and offers Clear search.

A new project

1. Click New project. A dialog asks for a name.

   

2. Type the name and click Create. You are its owner, and the dashboard opens it.

3. Invite the team on its Settings → Members — see Members.

The switcher

Inside a project, the dashboard shows it at the left of the top bar, on every screen: the name and a chevron — in a company’s project, after the company’s name. Open it to see every project you are in, grouped by company as the Projects page is, the current one checked and your role in each, then All projects and New project… — a name, and the browser moves into the new project as its owner. A new project is personal: a company takes one in from its own page. It is pictured on Navigation.

The choice is remembered by the browser. When nothing is remembered yet — a first visit, a new browser — the dashboard stands in the first project it lists: for somebody invited before they ever signed in, that is the team’s project, not their own empty default. Switching starts over on the runs list.

Removed from a project?

A browser that remembers a project the account is no longer in meets the 404 above on its first request, forgets the choice and starts over in the first project it still lists. Nothing to clear by hand.

Tokens and projects

A CLI token is bound to the project it was minted for. Mint it on Account → API tokens with the project CI should write to picked beside Generate, and every request that carries it lands there — whatever X-Plune-Project a client sends, the header is ignored under a bearer token. Each row of the list leads with the project its token writes to; a token from before projects existed writes to your default project.

Over the API, the session’s POST /v1/tokens mints for the project X-Plune-Project names, else for your default one; a project you are not in answers 404, one you only read 403.

Two products, two projects, two tokens: the CI of each writes to its own, and neither can be pointed at the other by a header.

A reader cannot mint a token

Minting is a write, and a reader is refused every write in a project (see Members), so the dashboard does not offer such a project to pick. CLI read access for a read-only member is not a thing yet: a reader looks at reports in the dashboard, and an owner or member holds the tokens.

Where the records say it

Every record carries a projectId, and the audit feed is per project — GET /v1/audit lists what changed in the project the request stands in. Membership changes are recorded there too, as updates of the project entity: who was added, invited, promoted, removed, and by whom.