Projects

A project is an independent repository of suites, test cases, runs, milestones, and defects. The Projects screen is your organization’s landing page: a directory of every project you can access, with at-a-glance health metrics and quick navigation into each one.

Reaching the screen

Two view modes

The directory renders the same paginated set of projects in either of two layouts, switched with the view toggle at the top right:

List — a compact row per project. This is the default on your first visit.
Cards — a responsive grid of project cards, denser on metrics and the team.

Your choice is remembered per browser (it persists across reloads), and it applies to both the directory and its loading, empty, and no-results states. Switching modes never re-fetches — it only re-draws the projects already on the page.

On a narrow (phone-width) screen your chosen mode is still honoured — the view toggle stays visible and switching still works. List reflows to a card per project (the same name, id, metrics, team, and favorite/menu actions as the row, just stacked instead of columned); Cards reflows to a single column instead of a multi-column grid. At tablet width and above both modes look exactly as described above.

Per-project metrics

Every project shows the same four health metrics in both modes, computed live from the project’s data:

Metric	Meaning
Cases	Active (non-archived) test cases in the project
Runs	All test runs, with a “{n} in progress” qualifier for runs that are still open
Defects	Unresolved defects (open or in progress). This metric is warn-highlighted when greater than zero, and the count is always shown as a number so the warning never relies on color alone
Milestones	Live (non-deleted) milestones in the project

The team avatar-stack

Each project shows a small stack of overlapping member avatars — the project team — with a “+N” indicator when the team is larger than the avatars shown.

What the team reflects today. By default every project is public: every member of your organization has access, and each project’s team stack shows the whole active organization. A project can be switched to private from the in-app Control access tab in project settings, or via the integrator API; once private, the team stack automatically narrows to that project’s allowlist — Control access — Individual members below is where you manage exactly who is on it. Enforcement follows the data, not the URL shape: a test case, run, or similar entity reached by its own ULID is gated exactly like the project itself, so a private project’s contents stay unreachable that way too. One documented limitation still applies: organization API tokens always keep reaching every project regardless of mode — “private” applies to human callers only.

Filtering

The filter row offers:

Search — type to filter projects by name. The term is reflected in the URL so a filtered view is shareable and survives a reload.
Member — filter the directory to projects a selected member can access. The selection is encoded in the URL as a memberUlid set, so a filtered link reproduces the same view when opened fresh.

Member filter today. For a public project the member filter behaves as before. A private project not on your allowlist is excluded from the directory entirely (whether or not it matches your filter selection) — organization owners and administrators always see every project regardless of mode.

Test runs — filter to projects that have no runs (Without runs), have at least one active run (Has active runs), or have at least one run of any state (Has any run).
Defects — filter to projects that have at least one unresolved defect (Has defects) or no unresolved defects (Without defects).
Milestones — filter to projects that have at least one milestone (Has milestones) or no milestones (Without milestones).
Cases — filter to projects that have at least one test case (Has cases) or no test cases (Without cases).
Status — a permanent filter (always visible, never removable) with two options: Active and Archived. The directory shows active projects by default — an archived project is hidden from both view modes and from the counter/pager until you check Archived (or both options, to see everything). Leaving it empty is the same as selecting Active alone, not a third state. Your selection is encoded in the URL as status, so a filtered link (for example ?status=archived) reproduces the same view when opened fresh.

These filters compose with each other, with the Member filter, and with the search term — all active conditions are applied together (AND across filters, OR within a filter’s selected options). Each selection is encoded in the URL so filtered views are shareable and survive a reload.

When a search, member, or Status filter matches no projects, the directory shows a no-results state with a Clear filters action that removes the search term, the member selection, and the Status selection all at once (the Status chip stays visible, just empty afterward, returning you to the default active-only view). This is distinct from the empty state shown when your organization simply has no projects yet, which offers a Create first project action (for organization owners and administrators).

Favorites

Click the star on any project to add it to your favorites. Favorited projects float to the top of the page you are viewing, keeping their relative order otherwise. Favorites are stored per user and per organization in your browser.

Favorites sort within the current page only. A favorite that lives on another page of a large directory is not pulled forward to the first page. For the typical single-page portfolio this is invisible; it only matters once a directory is large enough to paginate.

Pagination

When your organization has fewer than ten projects, no pager is shown — the directory is a single page. With ten or more, the pager appears below the directory: the rows-per-page selector and the range summary always show, and the previous/next and page-number controls appear only once the directory spans more than one page. Changing the page requests that page of projects.

Navigating tables with the keyboard

Across Probara’s list screens rendered as a table — test runs, workspace members, and others — every row that opens a detail can be reached without a mouse: press Tab until the row is focused, then press Enter or Space to open it, the same as clicking. A row’s own controls (an actions menu, a remove button) still work independently and never trigger the row’s own navigation.

Creating a project

Organization owners and administrators see a New project button in the header (and a Create first project action in the empty state). Members and viewers can browse the directory but do not see the create action.

Project settings

Open Settings from the project sidebar or choose Edit on the projects list (⋯ menu). You can review Name, Project ID, and Description for any member of the organization.

Only organization owners and administrators can save changes. Members and viewers see the same fields read-only.

Owners and administrators can also upload, change, or remove the project picture from settings. The image appears in the project sidebar, the projects list, and the settings header. Members and viewers see the picture (or initials fallback) but cannot change it. Allowed formats: PNG, JPEG, or WebP, up to 5 MB.

The Project ID is the uppercase prefix used in test case and suite display IDs (for example ACME-14). Changing it updates those prefixes immediately and breaks old /projects/<old-id> URLs and bookmarks—plan integrations and shared links before renaming.

Archiving and deleting a project

The settings header carries two whole-project lifecycle actions, visible to organization owners and administrators only:

Archive / Unarchive — a reversible toggle. Archiving hides the project from the default directory (see Status filter above) everywhere it is listed, but changes nothing else: the project, its suites, cases, runs, milestones, and defects stay fully readable and writable, and every existing link still resolves. Unarchiving brings it back to the default view. Archiving does not free a project seat toward your plan’s project limit — deleting remains the only way to do that.
Delete — permanent and irreversible. It removes the project and every suite, case, run, and milestone it holds. Both actions ask you to confirm before doing anything; cancelling makes no request at all.

Known limitation. Deleting a project does not remove its picture or any step attachments from storage — only the database rows. This has no visible effect today and is scheduled to be addressed in a future change.

Control access — Individual members

Open the Control access tab in project settings to manage a private project’s allowlist. Below the mode toggle and the owner, two inner tabs appear only in private mode: Groups (a reserved surface with no functionality yet — no group entity or group-based access exists) and Individual members.

The Individual members tab lists every member currently on the allowlist with their avatar, name, email, role, and position title. To add someone, choose an active organization member who isn’t already listed and confirm — they gain access immediately, without changing the project’s mode. To remove someone, use the Revoke access action on their row and confirm in the dialog that names them.

The revoke action only appears on a Member-role row — never on an Owner row or an Administrator row, even when that administrator happens to hold a grant themselves (their access comes from their organization role regardless, so revoking that particular row would change nothing about who can open the project). If every remaining row on the list is an Owner or Administrator, no row is actionable — the mode toggle is the only exit, and that is intentional: publishing a project is a mode change and should be made as one, not as a side effect of removing the last few visible rows.

Removing the last remaining grant on a private project now succeeds: the allowlist is emptied and the project stays private, reachable only by the organization owner/admin bypass until someone is granted again or the mode is explicitly switched to public. Emptying the allowlist is never itself a publication — only the mode toggle above publishes a project.