QMetry: Update Test Suite

Update an existing QMetry test suite by id(testsuite numeric id), with auto-resolution from entityKey.

Toolset: Test Suites

Parameters:

• id (number) required: Id of Test Suite to be updated (required)

• TsFolderID (number): Folder ID where Test Suite resides - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific folder ID. System will fetch project info using the projectKey and extract rootFolders.TS.id automatically. Manual folder ID only needed if you want to override the automatic resolution.

• entityKey (string) required: Entity Key of Test Suite to be updated (required)

• name (string): Name of the Test Suite

• description (string): Description of the Test Suite

• testsuiteOwner (number): Owner ID of the Test Suite

• testSuiteState (number): State of the Test Suite

• udfFields (record<string, union>): Flat UDF field values. Keys = UDF field names from 'Fetch UDF Layout'. Values depend on fieldTypeName: STRING/LARGETEXT: string, NUMBER: number, DATETIMEPICKER: date string ('14-08-2026'), LOOKUPLIST: numeric ID, MULTILOOKUPLIST: array of IDs [101, 102], CASCADINGLIST: { parent: 101, child: 102 }. Call 'Fetch UDF Layout' with entityType + pageName='ADD' to discover available fields and list option IDs.

• UDF (record<string, object>): UDF wrapper required for update. Keys = UDF field names. Each value must include fieldID (from 'Fetch UDF Layout' with pageName='DETAIL') and value.

Output Description: JSON object containing the new test suite ID, summary, and creation metadata.

Use Cases: 1. Update test suite summary (name) 2. Change owner, or state of a test suite 3. Bulk update using entityKey auto-resolution 4. Modify test suite description

Examples:

1. Update test suite summary (updated name)

{
  "id": 1505898,
  "entityKey": "VT-TS-7",
  "TsFolderID": 1644087,
  "name": "MAC Test11"
}

Expected Output: Test suite summary updated. Only 'name' field changed. Field IDs auto-resolved from project info. id(test suite numeric id) resolved from entityKey. TsFolderID auto-resolved. from the project info. info on rootFolders.TS.id.

2. Update state to Open and owner of the test suite

{
  "id": 1505898,
  "entityKey": "VT-TS-7",
  "TsFolderID": 1644087,
  "testSuiteState": 505036,
  "testsuiteOwner": 6963
}

Expected Output: State and owner updated. Example uses: testSuiteState=505036 (Open from customListObjs.testSuiteState[index].id), testsuiteOwner=6963 (umang.savaliya from customListObjs.owner[index].id). Field IDs auto-resolved from project info. id(test suite numeric id) resolved from entityKey. TsFolderID auto-resolved from the project info rootFolders.TS.id.

3. Update only description of the test suite

{
  "id": 1505898,
  "entityKey": "VT-TS-7",
  "TsFolderID": 1644087,
  "description": "Updated description for the test suite."
}

Expected Output: description updated only. Field IDs auto-resolved from project info. id(test suite numeric id) resolved from entityKey. TsFolderID auto-resolved. from the project info. info on rootFolders.TS.id.

Hints: 1. === DEFAULT VALUES — APPLY FOR ANY UNSET FIELD === 2. ALWAYS call 'Fetch UDF Layout' with entityType='TS', pageName='DETAIL' before updating. 3. defaultValues (from Fetch UDF Layout): { fieldName: defaultValueId } — sweep ALL entries. 4. For EACH key in defaultValues: if user did not explicitly provide that field → include it in payload with the default value. 5. This applies to non-mandatory fields too (e.g. testSuiteState). Omitting them = data loss. 6. systemFields (from qmSDF.TS): isMandatory=true fields must retain a valid value after update. 7. fields/UDF (from qmUDF.TS): isMandatory=true UDF fields must be included if being changed. 8. === END DEFAULT VALUES === 9. 10. === DATE FORMAT CHECK (MANDATORY — EVERY UPDATE REQUEST) === 11. ALWAYS call 'Fetch QMetry Project Info' before every update request — not only when the user explicitly mentions a date. 12. Any UDF field could be a DATETIMEPICKER. Wrong format causes QMetry to silently discard the field value (API returns success but value is NOT stored — no error). 13. STEP 1: From project info, read dateTimeFormatID (e.g. 3). 14. STEP 2: Find entry in dateTimeFormatNew where id === dateTimeFormatID → read its unique_value (e.g. 'yyyy-MM-dd'). 15. STEP 3: unique_value pattern: yyyy=4-digit year, MM=2-digit month (01-12), dd=2-digit day, MMM=3-letter month (Jan/Feb/...). 16. Example: id=1 → MM-dd-yyyy → '10-25-2000' | id=2 → dd-MM-yyyy → '25-10-2000' | id=3 → yyyy-MM-dd → '2000-10-25' | id=4 → dd-MMM-yyyy → '25-Oct-2000' 17. STEP 4: For EVERY DATETIMEPICKER field in the payload: parse any user-provided date and re-format it using the active unique_value pattern before sending. 18. NEVER assume a date format — always derive it from dateTimeFormatID. Wrong format = silent data loss. 19. === END DATE FORMAT CHECK === 20. 21. If user provides entityKey (e.g., MAC-TS-7), first call Fetch Test Suites with a filter on entityKeyId to resolve the id (test suite numeric id) and TsFolderID from rootFolders.TS.id. 22. To get valid values for owner, state, etc., call the 'Admin/Get info Service' API (FETCH_PROJECT_INFO tool) and use the returned customListObjs IDs. 23. CRITICAL: For testsuiteOwner mapping - Call API 'Admin/Get info Service', from the response get value from customListObjs.owner[].id. Match the user by customListObjs.owner[].name. 24. If the user provides an owner name, fetch project info, find the matching user in customListObjs.owner[index].name, and use its ID in the payload as testsuiteOwner. If the name is not found, skip the testsuiteOwner field (it is not required) and show a user-friendly message: 'Test suite updated without owner, as given owner is not available in the current project.' 25. CRITICAL: For testSuiteState mapping - Call API 'Admin/Get info Service', from the response get value from customListObjs.testSuiteState[].id. Match the state by customListObjs.testSuiteState[].name. 26. If the user provides a test suite state name, fetch project info, find the matching state in customListObjs.testSuiteState[index].name, and use its ID in the payload as testSuiteState. If the name is not found, skip the testSuiteState field (it is not required) and show a user-friendly message: 'Test suite updated without test suite state, as given state is not available in the current project.' 27. If either owner or state is not found in project info, the update for that field will be skipped and a user-friendly message will be shown to the user. 28. UDF fields in steps must match your QMetry custom field configuration. 29. All IDs (testSuiteState from customListObjs.testSuiteState[index].id, testsuiteOwner from customListObjs.owner[index].id) must be valid for your QMetry instance. 30. If a custom field is mandatory, include it in the UDF object. 31. 32. UDF (User Defined Fields) WORKFLOW FOR UPDATE: 33. 1. Call 'Fetch UDF Layout' with entityType='TS', pageName='DETAIL' to get field names, fieldIDs (projectUserFieldID), and list option IDs. 34. IF listOptions[field.listName] is empty after Fetch UDF Layout, the tool already tried a metadata fallback. If STILL empty, ask the user to provide the option ID from the QMetry UI — do NOT guess numeric IDs. 35. 2. For LOOKUPLIST fields: pick one ID from listOptions[field.listName][].id. 36. 3. For MULTILOOKUPLIST fields: pick array of IDs; also pass alias flat key (e.g., fieldNameAlias: 'Option Label'). 37. 4. For CASCADINGLIST fields: pick parent ID + fetch child with 'Fetch Cascade Child Values'. Pass { parent: parentId, child: childId }. 38. 5. Pass BOTH 'udfFields' (flat root values) AND 'UDF' wrapper (with fieldID) — both required for update. 39. Example: udfFields: { ts_field: 'value' }, UDF: { ts_field: { fieldID: 2001, value: 'value' } } 40. 6. Mandatory UDF fields (isMandatory=true) MUST be included.