# Defects > Track bugs across test runs, filter the project list, and review linked attempts. **Defects** are project-scoped bug records numbered sequentially (`D-1`, `D-2`, …). Open **Defects** in the project sidebar to browse the list, or file defects while executing a test run. ## The defects list The list table leads each row with the defect's number and title, then shows its status, severity and priority (from your org's system-field options), assignee, how many run attempts it was linked to, when it was last seen in a run, and when it was created. **Last seen** and **Age** show the date with how long ago underneath; hover a date for the exact time. When no defect matches your search and filters, the table is replaced by a panel with **Clear filters**, which resets the search and every filter at once. Members get a **⋯** menu at the end of each row (and on each entry on a phone) to act on a defect without opening it: **Assign to me**, **Assign** to any member or back to unassigned, **View** it, or **Delete** it. Status changes are made on the defect's page. Deleting asks for confirmation and permanently removes the defect with its attachments and links. On a narrow (phone-width) screen the list presents the same defects as a stack of ruled entries instead of a table: each entry leads with the defect number and title, then lists status, severity, priority, assignee, occurrences, last seen, and age underneath as labeled fields. Every value, filter, and sort you have on a wider screen is still there — only the layout changes. At tablet width and above the list is the ruled table described here. The search box and a permanent **Status** chip are always present in the filter bar; the search matches titles or defect numbers (`D-12` or `12`). The Status chip is always shown (it has no **×** and is never offered in **Add filter**) — click it to open its popover editor and check one or more statuses, or leave it empty. Severity, priority, and assignee are reached through **Add filter** and appear as removable chips — click a chip to open its popover editor and check values. Each of these is **multi-select**: pick several severities, priorities, or assignees and the list shows defects matching **any** of the checked values (the chip then reads "2 selected"). Different filters still combine with **and** — severity ∈ \{Critical, Major\} _and_ assignee ∈ \{Ana, Bruno\}. Active filters are reflected in the URL so you can share a filtered view; a link that carries a single value keeps working. ### Custom columns Use **Columns** in the toolbar to show additional defect custom fields after the built-in columns. Option fields render colored option names; checkboxes, dates, and members use the same read-only display as the defect detail page. Text values show on one line, a paragraph's without its formatting (hover for the full value when truncated). Defects with no stored value for a column show an em-dash. Your column choices are saved per project in this browser. If a field is later hidden from the project, its column is dropped silently on the next visit. ### Custom filters **Add filter** lists filterable custom fields (options, checkbox, and member picker) alongside the built-in severity, priority, and assignee filters. Selecting one adds a chip whose editor opens immediately — no filtering is applied until you pick a value. Each editor offers an **(empty)** choice for defects that have no stored value for that field — including defects that only show a default on the detail page. Custom filters are evaluated against **stored value rows only**; a default you see on detail does not satisfy an option filter until the value is saved. Custom filters appear in the URL as `cf` parameters and compose with built-in filters. Use a chip's **×** to remove it (clearing its `cf` entry). An age bucket chosen from the metrics strip appears as a removable chip too. ### Metrics strip Above the filter bar, a compact strip summarizes open defects for the project: the open count with a severity distribution bar and legend (one entry per org option, including zero counts), aging buckets (0–7, 7–14, 14–30, and 30+ days since creation) with the age of the oldest open defect, the reopen rate, and the mean time to resolve (MTTR). Click a severity legend entry or an aging bucket to apply the matching list filters (open and in-progress defects only). When metrics cannot be loaded, the strip is hidden and the list still works. The **Defects** item in the project sidebar shows a badge with the open-defect count when it is greater than zero. Click a row to open the defect detail. Use **Load more** when the project has more defects than one page. Members and above can click **New defect** to create a record from the list. Its **Description** can hold formatting and images: paste or drop an image into it, or type **/** and choose **Image**. The dialog includes a **Custom fields** section when the project has visible defect-scoped definitions; required fields must be filled before submit. Omitted empty values are not sent — the API materializes defaults on read. Viewers can browse but cannot create or edit. ## Filing from a run When you mark a case **Failed** or **Blocked**, the **Add result** modal opens first so you can review the outcome, add a comment, and adjust the recorded time — nothing is saved until you confirm. If you turn on the defect toggle before confirming, the **Report defect** modal opens next, against the attempt that was just saved. You can attach an existing defect or create one quickly. Suggestions include previously linked defects; selecting a **Resolved** or **Closed** suggestion announces that attaching it will reopen the defect, and confirming links the new attempt and moves the defect back to **Open** in the same step. Linked defects appear as chips in the case panel — click a chip to jump to that defect's detail page. A **back arrow** next to the Report defect title returns to the Add result modal without creating or linking anything, in case you need to correct the result first. With the [GitHub integration](https://docs.probara.net/en/guides/integrations/github/) connected, the **Report defect** modal also offers **Also create a GitHub issue**: once the defect is saved, a dialog opens with the issue prefilled from the failed result. See [Create an issue from a defect or a failed result](https://docs.probara.net/en/guides/integrations/github/#create-an-issue-from-a-defect-or-a-failed-result). Quick-create (**Enter** or **Create and link**) stays one keystroke when every required defect custom field visible in the project has a non-empty default (or when no required defect fields exist). If a required field has no default, the full **New defect** dialog opens prefilled with the capture title; submitting there creates the defect, links the marked attempt, and closes both dialogs. If the server rejects a quick-create because a required field was added mid-session, the same prefilled dialog opens instead of a raw error. While executing a run, the summary rail on the right lists every distinct defect linked to that run as `D-` chips. When you **Complete** the run, the confirmation mentions how many defects are linked if any remain untested cases or when closing with linked defects. ## Defect detail The detail page uses a full-width main column plus a right **sidebar** (stacked below the main content on narrow viewports). The **header** shows a breadcrumb (` › defects › D-`), the title, severity and priority chips, how many run attempts are linked (and when the defect was last seen), and a workflow status control with short descriptions for each legal transition. The **main column** contains, top to bottom: - The **description**, which can hold formatting and images: paste or drop an image into it, or type **/** and choose **Image** - An **Evidence** section (one grid of attachment tiles: the images in the defect's texts, then its files, with an **Add file** tile for members) - An **Affected cases** card — manually linked cases and cases surfaced by failing runs, with occurrence counts, latest result chips, and (for **Resolved** defects) verification badges with close/reopen suggestions in a banner above the table - **Occurrences** and **Activity** tabs Section headings (**Description**, **Evidence**, **Affected cases**) use your organization's localized defaults unless an admin renamed them under **Workspace → Custom fields** (core rows with the **Core** badge). Renamed titles appear verbatim in every locale; the affected-cases heading still appends the linked-case count when present. **Occurrences** is a table of every linked run attempt, newest first (run, case, result, execution date, who linked it). Select a row to open the frozen attempt snapshot (read-only steps and results). **Activity** shows the defect's audit history (created, updated, status changes, links). The **sidebar** holds the defect's properties: status, the severity and priority system fields, then assignee, reporter, tags, milestone, duplicate-of link, created/updated timestamps, and other visible **custom fields** (editable inline for members; read-only for viewers). A paragraph field holds formatting and images, like the description. The comment thread is not in the sidebar: it is the last section of the page (see [Discussion thread](#discussion-thread)). On a phone or tablet (below 1024px) this sidebar is not a column. A **Details** band under the page header carries the defect's status, and activating it opens the properties as a bottom sheet. Members can edit title, description, status, assignee, tags, and milestone from the header and the sidebar. Severity and priority are edited as system custom fields in the sidebar (not via defect PATCH). Status changes follow a guided lifecycle: | From | Allowed next statuses | | ----------- | ----------------------------- | | Open | In progress, Resolved, Closed | | In progress | Open, Resolved, Closed | | Resolved | Closed, Open (reopen) | | Closed | Open (reopen) | Choosing **Resolved** or **Closed** requires picking a resolution in a dialog. **Duplicate** resolutions must point at a canonical defect (`D-`); chains are flattened to the root automatically. Reopening clears the resolution, duplicate pointer, and lifecycle timestamps. ### Resizing and collapsing the summary panel On a desktop screen (1024px and wider) the sidebar carries the same manual controls as the other summary panels. Drag its **leading edge**: dragging left widens the sidebar and dragging right narrows it. With the handle focused, `ArrowLeft` widens by one step and `ArrowRight` narrows by one step, and a **double-click** restores its default width. The **round chevron button on the sidebar's left edge** — shown when you point at the sidebar or tab to it — or the `]` key collapses it into a 56px readout column. Because a defect has no progress chart, this column has **no progress ring and no percentage** — it carries the rack of icon keys directly, and each key opens that section's values in a popover anchored beside the column. **Every property stays reachable**: the same fields are hosted in their keys' popovers, and no value is removed. The same toggle, in the same place, expands the sidebar again. **The width and the collapsed state are shared by all four summary panels** — runs, test plans, milestones and defects — so a resize or collapse made here also applies to the other three, and both settings survive a reload. ### Affected cases The **Affected cases** card shows every test case associated with a defect, regardless of how the association was created. A case can appear because a failing run linked it automatically, because a member added it manually, or both at once. **Linking a case manually** Members (owner, admin, or member role) see a **+ Link case** button in the card header. Click it to open a search dialog, type part of the case title or `C-` number, and select a result. Archived cases and cases already in the list are excluded from the picker. The case appears immediately with a **Linked** badge indicating it was added manually. Viewers do not see the link button. **Reading the list** Each row shows the case number, title, occurrence count (how many run attempts linked this defect to that case), and latest result chip. A **Linked** badge marks cases that were added via **+ Link case**. A case that was both manually linked and surfaced by runs shows the badge alongside its occurrence count — the two origins are merged into one row. When there are no affected cases yet, the card shows an empty state with a **Link a case** shortcut (visible to members only). **Removing a case** Open the three-dot menu on any row to remove it. The available action depends on how the case was added: - **Unlink** — available for manually linked cases (those with the **Linked** badge). Removes the manual link. If the case still has run occurrences it stays in the list as a run-derived case (without the badge); if it had no occurrences it disappears entirely. - **Dismiss** — available for run-derived cases (those without the **Linked** badge). Hides the case from this defect without changing any run result. A dismissed case reappears automatically if the case fails again in a new run after the dismissal. Both actions open a confirmation dialog before taking effect. Viewers do not see the three-dot menu. ### Verification loop When a defect is **Resolved**, the **Affected cases** table adds a verification column. Each case shows a badge: - **Verified** — the case passed after resolution (close suggestion available). - **Failed after resolve** — the case failed or was blocked again (reopen suggestion). - **Pending** — nothing has run since resolution; re-run those cases to verify the fix. The banner above the table never changes status on its own — use the status control or the suggested CTAs, which route through the same flows as the header. ### Evidence gallery The **Evidence** section lists every image in the defect's description and paragraph custom fields, labeled with the field that holds it (**Description** or the custom field's name), then the files uploaded to the defect, labeled **File**. An image used in two fields shows once, with both labels. Uploads accept **any file type** — screenshots, logs, HAR files, PDFs, videos, spreadsheets, crash dumps — up to 32 MiB per file and 20 files per defect; the images in the texts do not count toward the 20. Members upload with the dashed **Add file** tile. To remove files, press **Edit** next to the section count: each file gets a remove button, and **Done** ends editing. A removal applies at once. An image has no remove button: delete it from its text, and it leaves the section once the text is saved. Viewers see the section but cannot upload or remove anything. Every attachment shows as a tile with its name and file extension: images (PNG, JPEG, WebP) with a thumbnail, other files with an icon. Clicking any tile opens the attachment viewer at that file. Images, videos, audio and text files (logs, Markdown, JSON) preview there; a file with no preview, such as a PDF or a ZIP, shows **No preview available** and a **Download** button. To download without opening the viewer, hover a tile and use its download button. Executable files (`.exe`, `.msi`, `.sh`, `.bat`, and similar) are rejected outright and never stored. Every evidence upload counts toward your organization's storage quota. If an upload would push the organization over its storage cap, it is rejected with a distinct quota-exceeded message and nothing is attached. ### Discussion thread The **Comments** thread is the last section of the defect page, below **Occurrences** and **Activity**, with a composer for members. Post a comment to append it without reloading the page. You can edit or delete your own comments; organization admins can delete any comment. Edited comments show an **(edited)** marker. When an author leaves the organization, their comments remain with a removed-author placeholder. Viewers can read the thread but cannot post, edit, or delete.