I’ve been working with the JIRA SOAP API and haven’t found a clear way to set an issue’s status to duplicate. My current method calls a workflow transition that ends up marking the issue as ‘Resolved - Fixed’. I attempted using a process that updates resolution parameters, but it doesn’t result in a duplicate label. I need help figuring out the correct SOAP call and the appropriate parameters to successfully mark an issue as a duplicate.
Below is an updated code example illustrating my current approach:
dupInfo = {};
dupInfo["status"] = "duplicate";
soapConnector = new SOAPHandler();
result = soapConnector.executeTransition("sessionCode", "ISSUE-456", 30, dupInfo);
console.log(result);
hey, i dont think jra soap supports marking as duplicate directly. you might need to use a custom workflow transition or update a dup flag custom field. some ppl also write a work around with an extra api call to set the proper resolution.
Based on my experience, JIRA SOAP does not offer a straightforward approach to flagging an issue as a duplicate. My workaround involved adapting the workflow to include a custom transition specifically designed for duplicates. After reviewing the workflow configuration and ensuring that the duplicate resolution exists in your JIRA setup, I crafted an additional API call right after the transition, solely to update the resolution field. This two-step process eventually permitted the system to reflect the duplicate status properly.
In my experience, the limitations of the JIRA SOAP API regarding marking issues as duplicates require a bit of creativity. I encountered similar challenges when attempting to use standard transitions to indicate duplicates. After thorough testing, I opted to extend the workflow by incorporating a custom field that specifically signals a duplicated issue. This approach allowed the system to recognize the duplicate after a post-transition update on the new field. While not seamless, it reliably reached the intended result. Given the constraints, exploring customizations in the workflow provided a practical solution.
hey, i’ve tried a workaround: after the transition i used an extra api call to set a custom dup field. its not native but works for me. sometimes you gotta patch things manually. good luck!
Based on my experience, updating the duplicate status through the SOAP API requires a workaround rather than a native solution. I solved this by rethinking the workflow design. I first used a custom workflow transition to signal the duplicate state, then immediately executed a workflow post-function that updates a custom field dedicated to duplicates. This method enables the system to correctly reflect the duplicate without overriding other statuses. It involved some initial configuration of the custom field, but ultimately provided a reliable approach within the limitations of the SOAP API.