QMetry: Fetch Issue Executions
qmetry_fetch_issue_executionsRetrieve all test case executions linked to a QMetry defect, presented as a unified table with test suite details, release, cycle, platform, execution status, and custom UDF fields.
Instructions
Get test case executions linked to a QMetry-native (non-Jira) defect/issue. ALWAYS present results as a unified table: Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | <UDF Label columns…>. NEVER show a separate type+value UDF breakdown — always combine identification fields and UDF values in one table per execution row.
Toolset: Issues
Parameters:
projectKey (string): Project key - unique identifier for the project (default: "default")
baseUrl (string): The base URL for the QMetry instance (must be a valid URL)
linkedAssetId (number) required: Numeric defect ID of the QMetry issue. CRITICAL: parameter name is 'linkedAssetId' — do NOT use 'issueId', 'defectId', 'id', or other variants. Accepts a string or number. To get this ID, call the Fetch Defects or Issues tool and use data[].id from the response.
start (number): Start index for pagination - defaults to 0 (default: 0)
page (number): Page number to return (starts from 1) (default: 1)
limit (number): Number of records (default 10). (default: 10)
platformID (string): Platform ID to filter executions by environment/platform
filter (string): JSON filter string. Supported fields: tcName (string), linkageLevel (string), executedVersion (string), runStatusName (list of status names), platformID (list of numeric IDs), executionCreatedByLoginAlias (list of usernames), isTestSuiteArchived (list: [1] active, [0] archived, [1,0] both). Example: '[{"type":"string","value":"login","field":"tcName"}]' (default: "[]")
Output Description: JSON object with 'data' array of execution records, 'hasTcRunUdf' boolean flag, and 'total' count. Each execution record ALWAYS contains these mandatory identification fields: 'tsEntityKey' (Test Suite Key, e.g. 'MAC-TS-42'), 'tsName' (Test Suite Name), 'releaseName' (Release), 'cycleName' (Cycle), 'platformName' (Platform/environment), 'executedVersion' (Executed Version of the test case), 'runStatusName' (Execution Status label), 'tcRunID' (numeric Test Run ID), 'tcName' (Test Case Name), 'tcEntityKey' (Test Case Key), and 'testRunUdfs' (array of objects each with name, label, fieldID, fieldType, value — use 'label' for display headers, null if not set). ALL project-defined UDF fields are always included, even those with no value. When hasTcRunUdf is false, a 'testRunUdfNote' field provides a professional explanation instead.
Use Cases: 1. Get all test executions linked to a specific defect 2. Audit which test cases were run against a given issue 3. Filter executions by run status (failed, passed, etc.) for an issue 4. Filter executions by platform/environment for an issue 5. Filter executions by tester/executor for an issue 6. Show archived and active test suite executions for an issue 7. View UDF (custom field) values on executions linked to an issue 8. Track test coverage and execution progress for a defect
Examples:
Get all executions linked to issue ID 9598240
{
"linkedAssetId": 9598240
}Expected Output: Present as ONE unified table — never as a separate type+value UDF breakdown. Example: | Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | Tested By | Environments UDF | Execution Type | | MAC-TS-42 | Regression Suite | R1 | Sprint1 | Chrome | 1 | Failed | varis | chrome, edge, safari | Functional | | MAC-TS-43 | Login Suite | R1 | Sprint1 | Firefox | 2 | Blocked | john | firefox | Regression | Columns in order: Test Suite Key (tsEntityKey) | Test Suite Name (tsName) | Release (releaseName) | Cycle (cycleName) | Platform (platformName) | Executed Version (executedVersion) | Execution Status (runStatusName) | then one column per UDF label. Use the UDF 'label' as column header. Show null UDF values as '-'.
Get executions with pagination (page 1, 20 records)
{
"linkedAssetId": 9598240,
"page": 1,
"start": 0,
"limit": 20
}Expected Output: First 20 executions linked to the issue
Filter executions by run status (failed or passed)
{
"linkedAssetId": 9509016,
"filter": "[{\"type\":\"list\",\"field\":\"runStatusName\",\"value\":[\"failed\",\"passed\"]}]",
"page": 1,
"start": 0,
"limit": 20
}Expected Output: Executions with failed or passed status for the issue
Filter executions by test case name
{
"linkedAssetId": 9509016,
"filter": "[{\"type\":\"string\",\"value\":\"login\",\"field\":\"tcName\"}]",
"page": 1,
"start": 0,
"limit": 20
}Expected Output: Executions where test case name contains 'login'
Filter by platform, status, and tester
{
"linkedAssetId": 9509016,
"filter": "[{\"type\":\"list\",\"field\":\"runStatusName\",\"value\":[\"failed\"]},{\"type\":\"list\",\"field\":\"platformID\",\"value\":[100145]},{\"type\":\"list\",\"field\":\"executionCreatedByLoginAlias\",\"value\":[\"Varis Khan\"]}]",
"page": 1,
"start": 0,
"limit": 20
}Expected Output: Failed executions on platform 100145 created by Varis Khan
Filter by status and include archived test suite executions
{
"linkedAssetId": 9509016,
"filter": "[{\"type\":\"list\",\"field\":\"runStatusName\",\"value\":[\"failed\",\"passed\"]},{\"value\":[1,0],\"type\":\"list\",\"field\":\"isTestSuiteArchived\"}]",
"page": 1,
"start": 0,
"limit": 20
}Expected Output: Executions with failed/passed status including archived test suites
Filter by execution version and linkage level
{
"linkedAssetId": 9509016,
"filter": "[{\"type\":\"string\",\"value\":\"1\",\"field\":\"executedVersion\"},{\"type\":\"string\",\"value\":\"Test Case\",\"field\":\"linkageLevel\"}]",
"page": 1,
"start": 0,
"limit": 20
}Expected Output: Executions at Test Case linkage level for version 1
Hints: 1. === MANDATORY RESPONSE FORMAT — READ THIS BEFORE RENDERING ANY OUTPUT === 2. 3. PIVOT RULE — CRITICAL: 4. The 'testRunUdfs' field on each execution is an array of { name, label, fieldID, fieldType, value }. 5. You MUST pivot this array into TABLE COLUMNS — do NOT render it as rows. 6. → Each testRunUdfs[i].label = a column header in the unified table 7. → Each testRunUdfs[i].value = the cell value for that execution's row 8. → testRunUdfs[i].fieldType = INTERNAL METADATA — NEVER show this as a column 9. → testRunUdfs[i].fieldID = INTERNAL METADATA — NEVER show this as a column 10. 11. FORBIDDEN PATTERNS — NEVER do any of these: 12. ❌ Do NOT render a separate sub-table (UDF Label | Type | Value) per execution 13. ❌ Do NOT show 'Type' or 'fieldType' as a visible column 14. ❌ Do NOT group output by tcRunID with individual breakdowns beneath each 15. ❌ Do NOT show raw UDF field keys (e.g. 'TRString', '8260LUP') as headers — use 'label' 16. 17. REQUIRED OUTPUT — ONE unified table, all executions as rows: 18. | Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | <UDF Label 1> | <UDF Label 2> | ... | 19. |----------------|-----------------|---------|-------|----------|------------------|------------------|---------------|---------------|-----| 20. | MAC-TS-42 | Login Suite | R1 | S1 | Chrome | v1 | Failed | varis | chrome, edge | ... | 21. 22. MANDATORY COLUMNS (always first, in this order): 23. 1. Test Suite Key → tsEntityKey (e.g. 'MAC-TS-42') 24. 2. Test Suite Name → tsName (test suite display name) 25. 3. Release → releaseName 26. 4. Cycle → cycleName 27. 5. Platform → platformName 28. 6. Executed Version → executedVersion 29. 7. Execution Status → runStatusName 30. 8. Tested By → executionCreatedByLoginAlias/testedBy when present 31. 9+. One column per UDF field — use testRunUdfs[i].label as header, testRunUdfs[i].value as cell. 32. 33. Null UDF values → show as '-'. If hasTcRunUdf is false, show columns 1-8 only. 34. ISSUE EXECUTION UDF SOURCE — CRITICAL: 35. Do NOT call 'Fetch Test Run UDF Values' for issue execution UDFs. 36. Do NOT create or use another issue-specific UDF fetch tool. 37. Use this tool's response directly: it calls /rest/execution/getExecutionsForIssue for execution rows, parses each row's udfjson for saved UDF values, and uses Test Run UDF metadata to include all configured UDF labels with null/empty values. 38. === END MANDATORY RESPONSE FORMAT === 39. 40. CRITICAL: linkedAssetId is REQUIRED - this is the numeric defect ID from QMetry (not entity key like VKT-IS-5) 41. HOW TO GET linkedAssetId: Call Fetch Defects or Issues tool → use data[].id from the response 42. AUTO-RESOLVE: If user provides an issue entity key (e.g. VKT-IS-5, MAC-IS-10), first call Fetch Defects or Issues with that entity key as filter, extract data[].id, then use it as linkedAssetId 43. AUTO-RESOLVE FILTER EXAMPLE: to resolve VKT-IS-5 → use filter '[{"type":"string","value":"VKT-IS-5","field":"entityKeyId"}]' in Fetch Defects or Issues tool 44. This tool supports QMetry-native issues only — do NOT use for Jira-integrated projects 45. API SOURCE: Execution rows and saved UDF values come from /rest/execution/getExecutionsForIssue. The udfjson field contains saved Test Run UDF values, e.g. Tested_By, execution_type, Country_mcp_udf, environments_udf. 46. METADATA SOURCE: This tool also calls Test Run UDF metadata once to get all available labels, fieldIDs, field types, and empty fields. Merge metadata fields with udfjson values by UDF name. 47. RESPONSE FIELDS: hasTcRunUdf=true means executions have UDF data; each execution includes a 'testRunUdfs' array with ALL project-defined UDF fields 48. ALL UDF FIELDS: ALL project-defined Test Run UDF fields are returned for every execution — including fields not yet set (value: null) 49. Each element in testRunUdfs: { name, label, fieldID, fieldType, value } — use fieldID when calling 'Bulk Update Test Run UDFs' 50. EXAMPLE testRunUdfs: [{ "name": "TRString", "label": "TR String", "fieldID": 229241, "fieldType": "STRING", "value": "test" }, { "name": "dateField", "label": "Date", "fieldID": 229255, "fieldType": "DATETIMEPICKER", "value": null }] 51. FILTER FIELDS: 52. - tcName (string): filter by test case name substring 53. - linkageLevel (string): 'Test Case' or 'Test Step' 54. - executedVersion (string): version number as string e.g. '1' 55. - runStatusName (list): e.g. ["failed","passed","in progress"] 56. - platformID (list): numeric platform IDs e.g. [100145]. Get from FETCH_PLATFORMS tool 57. - executionCreatedByLoginAlias (list): usernames/login aliases e.g. ["john.doe"] 58. - isTestSuiteArchived (list): [1] active only, [0] archived only, [1,0] both 59. FILTER FORMAT: JSON string array — '[{"type":"list","field":"runStatusName","value":["failed"]}]' 60. Multiple filter conditions are combined with AND logic 61. Use pagination (page, start, limit) for large result sets 62. Get platform IDs using the FETCH_PLATFORMS tool before filtering by platformID 63. Execution status names are case-sensitive — use lowercase: 'failed', 'passed', 'in progress', 'blocked', 'not run' 64. hasTcRunUdf: false → No Test Run UDFs configured; testRunUdfs will not appear; a 'testRunUdfNote' field explains this.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number to return (starts from 1) | |
| limit | No | Number of records (default 10). | |
| start | No | Start index for pagination - defaults to 0 | |
| filter | No | JSON filter string. Supported fields: tcName (string), linkageLevel (string), executedVersion (string), runStatusName (list of status names), platformID (list of numeric IDs), executionCreatedByLoginAlias (list of usernames), isTestSuiteArchived (list: [1] active, [0] archived, [1,0] both). Example: '[{"type":"string","value":"login","field":"tcName"}]' | [] |
| baseUrl | No | The base URL for the QMetry instance (must be a valid URL) | |
| platformID | No | Platform ID to filter executions by environment/platform | |
| projectKey | No | Project key - unique identifier for the project | default |
| linkedAssetId | Yes | Numeric defect ID of the QMetry issue. CRITICAL: parameter name is 'linkedAssetId' — do NOT use 'issueId', 'defectId', 'id', or other variants. Accepts a string or number. To get this ID, call the Fetch Defects or Issues tool and use data[<index>].id from the response. |