QMetry: Update Requirement

Update an existing QMetry requirement by rqId and rqVersionId.

Toolset: Requirements

Parameters:

• rqId (number) required: Requirement numeric ID (required). This is the internal numeric identifier, not the entity key like 'MAC-RQ-730'.

• rqVersionId (number) required: Requirement version ID (required for update).

• updateWithVersion (boolean): Pass 'true' to create a new version of the requirement instead of updating the existing version in place.

• name (string): Name of the requirement.

• description (string): Description of the requirement.

• component (array): Component (Label) IDs associated with the requirement.

• requirementOwner (number): Owner ID of the requirement.

• requirementState (number): State ID of the requirement.

• priority (number): Priority ID of the requirement.

• attachments (object): Attachment changes. ADD and REMOVE are both required arrays (use empty arrays for no change).

• 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 operations. Keys = UDF field names. Each value must include fieldID and value. Also set matching flat key in udfFields for the LOOKUPLIST Alias display. Example: { custom_text: { fieldID: 1001, value: 'new value' } }

Output Description: JSON object containing the updated requirement ID, summary, and update metadata.

Use Cases: 1. Update the name, description, priority, owner, state, or component of a requirement 2. Add or remove attachments on a requirement 3. Update custom field (UDF) values on a requirement 4. Create a new version of a requirement while updating it (updateWithVersion)

Examples:

1. Update the priority of a requirement

{
  "rqId": 2073,
  "rqVersionId": 2087,
  "updateWithVersion": false,
  "priority": 688865
}

Expected Output: Requirement priority updated successfully.

2. Update name, description, owner, and state

{
  "rqId": 2073,
  "rqVersionId": 2087,
  "name": "Updated login requirement",
  "description": "Users must be able to log in with SSO.",
  "requirementOwner": 8,
  "requirementState": 688912,
  "component": [
    689030
  ]
}

Expected Output: Requirement updated with new name, description, owner, state, and component.

Hints: 1. If the user provides an entityKey (e.g., MAC-RQ-730), first call 'Fetch Requirements' with a filter on entityKeyId to resolve rqId and rqVersionId. 2. updateWithVersion: pass 'true' to create a new version of the requirement instead of updating the current version in place. 3. To get valid values for priority, requirementOwner, requirementState, and component, call the 'Admin/Get info Service' API (FETCH_PROJECT_INFO tool) and use the returned customListObjs IDs. 4. If the user provides a name instead of an ID for owner/state/priority, fetch project info, find the matching entry by name in the relevant customListObjs list, and use its ID. If not found, skip that field and tell the user it was omitted because the value wasn't available in the current project. 5. attachments (if used) requires both ADD and REMOVE arrays — pass empty arrays when there is nothing to add or remove. 6. Only fields explicitly listed in this tool's parameters are supported — releaseCycleMapping and associateRelCyc are create-only and not supported here. 7. HARD GATE: before updating, this tool checks project info for isExtTrackerConfigured, extTrackerType, and isRQConfigured. If the project has an external tracker configured (isExtTrackerConfigured=true) and isRQConfigured=true, and the tracker is Jira (extTrackerType=1) or Azure (extTrackerType=3), the update is refused with an error — do NOT retry or work around this. Tell the user requirements for this project must be updated directly in the external system (Jira or Azure), then synced into QMetry. 8. 9. UDF (User Defined Fields) WORKFLOW FOR UPDATE: 10. 1. Call 'Fetch UDF Layout' with entityType='RQ', pageName='DETAIL' to get field names, fieldIDs (projectUserFieldID), and list option IDs. 11. 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. 12. 2. For LOOKUPLIST fields: pick one ID from listOptions[field.listName][].id. 13. 3. For MULTILOOKUPLIST fields: pick array of IDs; also pass alias flat key (e.g., fieldNameAlias: 'Option Label'). 14. 4. For CASCADINGLIST fields: pick parent ID + fetch child with 'Fetch Cascade Child Values'. Pass { parent: parentId, child: childId }. 15. 5. Pass BOTH 'udfFields' (flat root values) AND 'UDF' wrapper (with fieldID) — both required for update. Example: udfFields: { rq_field: 'value' }, UDF: { rq_field: { fieldID: 2001, value: 'value' } } 16. 6. Mandatory UDF fields (isMandatory=true) MUST be included.