Overview
Two field sets, both with a section named Issue Tracking, connect Validatar tests and catalog objects to the issues an issue-management integration raises. They are shared: the Jira integration uses them today, and the integrations that follow use the same fields, so a test keeps its routing if your team moves to another issue tool.
| Marketplace item | Adds | Used for |
|---|---|---|
| Issue Tracking - Project Custom Fields | 12 fields on every test | Where a test's issues go, and the issue it has open now |
| Issue Tracking - Catalog Custom Fields | 5 fields on tables, 2 on columns | The open issues raised by the tests linked to each table and column |
Neither set is required for issues to be opened and resolved. Without the test fields, a test cannot route its issues or show its open issue; without the catalog fields, the reconciliation sweep has nowhere to write open issues on tables and columns.
Test fields
The Issue Tracking - Project Custom Fields set adds these to the Test object type. People fill in the first seven. The integration writes the other five; leave them alone.
| Field | Reference key | Type | Purpose |
|---|---|---|---|
| Issue Tracking | issue_tracking |
Dropdown: On, Off | Off stops the integration opening, commenting on or resolving issues for this test, from its actions and from the sweep. Blank follows the data source |
| Issue Project | issue_project |
Short text | The project, queue or list this test's issues go to, such as a Jira project key. Blank uses the data source's default |
| Issue Type | issue_type |
Short text | The issue type to create, such as Task. Blank uses the data source's default |
| Issue Assignee | issue_assignee |
Short text | The email address of the person new issues are assigned to. Blank leaves them unassigned |
| Issue Priority | issue_priority |
Short text | The priority for new issues, by name as the issue tool shows it, such as High |
| Issue Labels | issue_labels |
Short text | Extra labels for new issues, comma-separated |
| Issue Field Values | issue_field_values |
Paragraph | A JSON object of field names to values for new issues, such as {"DQ Severity": "Critical"} |
| Issue System | issue_system |
Short text | Written by the integration: the issue tool holding the test's issue, such as Jira Cloud |
| Issue Key | issue_key |
Short text | Written by the integration: the open issue's key |
| Issue URL | issue_url |
Short text | Written by the integration: a link to the open issue |
| Issue Status | issue_status |
Short text | Written by the integration: the issue's status, a running count such as Pending: 2 of 3 failures, or Resolved |
| Issue Last Synced | issue_last_synced |
Short text | Written by the integration: when these fields were last refreshed, in UTC |
The routing fields take effect on the next issue the test opens. An issue that is already open keeps its project and fields.
The written fields are a copy for people reading the test. The issue tool is the record: the integration looks up each test's issue in the tool before every decision, so an out-of-date Issue Key cannot cause a wrong action. The reconciliation sweep corrects it, and the Jira Health Checks report any that point at a closed issue.
Catalog fields
The Issue Tracking - Catalog Custom Fields set adds an Issue Tracking section at Table and Column level. The reconciliation sweep writes them for every table and column linked to a test in its scope, and clears them when the last open issue is resolved.
| Level | Field | Reference key | Type | Holds |
|---|---|---|---|---|
| Table | Open Issues | issue_open_keys |
Tag list | The keys of open issues raised by tests linked to the table |
| Table | Open Issue Count | issue_open_count |
Short text | How many are open |
| Table | Oldest Open Issue | issue_oldest_open |
Date | When the oldest was raised |
| Table | Highest Open Priority | issue_highest_priority |
Short text | The highest priority among them |
| Table | Last Issue Opened | issue_last_opened |
Date | When the newest was raised |
| Column | Open Column Issues | issue_column_open_keys |
Tag list | The keys of open issues raised by tests linked to the column |
| Column | Open Column Issue Count | issue_column_open_count |
Short text | How many are open |
Counts are short text because Validatar custom fields have no number type. Column fields carry column in their keys because a reference key must be unique across catalog levels.
A test linked to a table and one of its columns reports its issue on both.
Import the fields
You need the Global Custom Metadata Admin role, or Global Admin. The catalog set also needs Govern Edition.
Test fields
- In Validatar, open Marketplace and find Issue Tracking - Project Custom Fields.
- Choose Get, then Import Directly. Validatar opens Settings > Project Custom Fields with an Import Custom Fields panel on the right.
- In the list of object types on the left, open Test. Import All adds the panel's section to the object type that is open.
- Choose Import All, then Save.
Catalog fields
- Open Marketplace, find Issue Tracking - Catalog Custom Fields, choose Get, then Import Directly. Validatar opens Settings > Catalog Custom Fields with the panel on the right.
- Open the Table level, pick Table in the panel's list, choose Import All once, then Save.
- Do the same for the Column level.
Warning: Choose Import All once per level. A second Import All adds the same fields again, and Save then refuses with "Please fix the errors on this page". If that happens, leave the page without saving, reload it and import again.
To create the fields by hand instead, use the section name, field names, reference keys and types above. The reference keys must match exactly, because the integration finds the fields by key.