Verified Answers


If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it!  Learn more

  • State Not Answered
  • Replies reply
    1
  • Subscribers subscribers
    6
  • Views views
    411
  • Users 0 members are here
  • Locked Locked
Related
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to prevent Defect duplication in MF ALM on type change in Jira?

Thilo Brause

We have a connection that synchronizes Bugs and CRs from Jira to Defects in MF ALM.

As Bugs and CRs are different types in Jira and MF Connect only allows to define a TypeMapping towards one type, we have one connection with two (identical) type-mappings.

One for Bug to Defect, one for CR to Defect:

In MF ALM we have defined a Field "Type" which contains either "Bug" or "Change" and is set to the corresponding value by a "Master CalculatedValue" for the TypeMappings.

Recently the Type of a Jira-Issue was change from "Bug" to "Change" after the synchronisation. All other attributes (including Jira-KEY) stayed the same.

Expected behaviour: The value Type of the Defect in MF ALM changes from "Bug" to "Change"

Observed behaviour: The remaining Defect remains the same. A duplicate Defect is created, which only differs in the field "Type" from the original and is linked to the same Jira issue:

What do I have to do, to come from the observed to the expected behaviour?

After all, changing the issue type from Bug to Change in Jira (or vice versa) is nothing frequent, but happens once or twice each month, and can be done by all users (in case of identical workflows in Jira).

  • 0

    Hi Thilo,

    >>Observed behavior: The remaining Defect remains the same. A duplicate Defect is created, which only differs in the field "Type"

    Unfortunately, this is the actual behavior, and is by design. (the connect database stores jira keys, not ids)

    Whether either of us agree to the correctness of the architecture/design or not is largely irrelevant.

    the only workaround for this is...

    if you know that a user intends to do this, and you can stop/prevent the next synchronization of the artifact,

    then you can stop all connections in the running service,

    export the cross references of the 'problem' connection,

    remove the cross reference of the one that has gone 'stale'

    and 'add' a cross reference for the new (old?) type changed defect.

    Manage cross references (microfocus.com)

    put another way, if you can, schedule a monthly window in which this can be done across all users, 

    then stop all connections, have the users perform all these re-typ'ing, and then retrofit the cross references accordingly.

    take care

    anil

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.