Skip to content
GitHub
documentation

Artefact IDs

The stable ID every Bloom artefact carries, how it is numbered and where it is used.

Every artefact has a stable ID in the form AAA-TYP-NNN (for example PRJ-REQ-001): the number keeps at least three digits and widens as a type fills up, so it passes PRJ-REQ-1000 uncapped.

In PRJ-REQ-001, PRJ is the project, REQ the artefact type and 001 the number. A test case ID reads the same way, such as PRJ-TC-001. The IDs are stable, which makes them the reference for controlled project records.

Bloom assigns the ID when an artefact is created. The create screen shows the identifier the server will assign. To ask for it ahead of time, GET /api/projects/{project_ref}/next-doc-id/{type_code} reports the next identifier for a document type.

  • Addresses. Artefact detail references resolve by public ID. An address that uses a database identifier still resolves.
  • Mentions. Mention links in a document body resolve by public ID. From a document body you can open a mentioned artefact, and the exact parameter.
  • Inline tags. A # tag shows the current ID of the artefact it points at, looked up once per document, not the text captured when it was typed. A tag whose target is gone reads as plain text. See Typed links.
  • Test results from Bud. A test class with BloomMetaData("PRJ", "001") sends results that carry a Bloom tc_id, and Bud posts the outcomes per tc_id. See Connecting to Bud.
  • Imports. A TestRail reference that matches a requirement ID becomes a verifies link from the imported test case.
  • Issue trackers. A Bloom test case ID of the project in a Jira issue’s summary, description or reference field becomes the source of the defect the issue creates. See Issue tracker sync.
  • Access requests. The access-denied page names what was requested only by its public ID and project.