Project Overrides
A field’s Project assignment panel decides which projects offer it, whether it is required in each of them, and what value it starts from. The panel is part of the field editor, so these settings are saved with the rest of the field rather than in a dialog of their own.
There is no per-project “hide” setting. A group changes how a field behaves where it applies; it cannot make the field disappear from one project. To stop a project seeing a field, leave that project out of the field’s groups, or switch the field off entirely with Enabled.
Groups
The panel holds one or more groups. Each group is a set of projects that share the same settings, and carries its own heading naming those projects. Add group adds another; the bin on a group’s heading removes it. Nothing is written until you save the field.
Every group offers the same rows:
| Row | What it controls | Shown for |
|---|---|---|
| Applies to | All projects (including new ones) or Selected projects. | Every field |
| Projects | The multi-select of projects, with the running count in the label. Only when Selected projects is chosen. | Every field |
| Required here | “Testers cannot save without a value in these projects.” See Making a field required. | Every field except a checkbox test run field |
| Default value | “Pre-filled for testers in these projects. They can still change it.” The control matches the field’s type, and is always clearable — the empty state reads No default. | Every type except Steps |
Groups are independent. Changing one group has no effect on another. A project that appears in no group is not offered the field at all.
Each project should appear in only one group. Where a project is claimed by more than one, the panel warns at the top — “n projects are claimed by more than one group. The field uses whichever group loads first there — narrow the project lists so each project appears once.” — and the groups involved carry a Conflict marker.
All projects, selected projects, and mixed
- All projects
- One group set to All projects. The field is offered everywhere, including in projects created later.
- Selected projects
- Groups that each name their own projects. A project not named in any group does not see the field.
- Mixed
- An All projects group alongside one or more specific groups. The specific group wins for the projects it names, and the broad group covers everyone else — which is why its heading reads All other projects rather than All projects as soon as a specific group exists.
Option lists and step columns a project keeps
Option lists and step columns are authored once, in the field editor’s own panel, and apply everywhere. A project that still holds a list of its own from before says so inside its group — “This project keeps its own option list (n options) — edit it via the API for now”, or the same sentence for step columns. Its stored list is left exactly as it is by a save that does not touch the panel above.
Once you do edit that panel, the note changes to say what will happen: “Saving replaces it with the option list above.” So the divergence is visible before you commit to removing it.
Making a field required
Required here is a per-group switch, not a property of the field. A project in no group, or in a group with the switch off, never requires the field.
A checkbox test run field cannot be required
On a checkbox test run field the switch is locked in every group, and one banner at the top of the panel says why: “A checkbox can’t be required: an unchecked box is a real answer, so the requirement would never be enforced. To make testers consciously answer, use a Yes/No dropdown and mark that required.”
Test case fields are unaffected. The restriction applies only to result fields. A checkbox test case field can still be marked required.
Requiring a result field in every project
Requiring a test run field in a group that covers All projects is the widest-reaching change in the fields admin, so it asks first. Saving that combination opens a confirmation — Require a value on every result? — which names the real number of projects affected and spells out the consequence: “Testers there will no longer be able to record a result in one tap; every result has to go through the full form instead.” The dialog adds that quick-record, the keypad, board and table cells, Pass & next, and bulk actions carry no field values, so they will all route testers to the full result form.
The prompt appears only when a save would newly arm that combination. Re-saving an unrelated change — a label, an option list — on a group that is already all-projects-and-required does not re-prompt. Switching a group to All projects while Required happens to already be on does prompt, because that is the same change arriving by a side door. Cancelling leaves the editor open on your draft so you can adjust the choice rather than losing it.
Removing a group
Click the bin on a group’s heading. The group disappears from the draft immediately — there is no separate confirmation, because nothing has been written yet; the save is the commit, and Discard on the save bar puts it back. Projects left in no group stop being offered the field.
A field in no group appears nowhere. The panel says so where every group has gone: “A field with no assignment appears nowhere. Add a group to choose which projects offer it, and whether it is required there.”