Idea ID: 2875544

Detect synced jira items whitch are moved to another jira project at a later time or deleted in jira

Status: Waiting for Votes

If synced jira items are moved to another jira project at a later time or deleted in the jira project, this is not detected by the MF Connect sync

MF Connect should provide a mechanism or script that matches Octane items and Jira items and creates a list of the items that are not included in Octane and Jira. And send this list to a email adress whitch can be defined by a MF Connect administrator.

Parents
  • I agree this idea description needs better wording. But I believe the spirit and intent is there. And I too would like to be notified if the project key ID from 1 JIRA project changes to another project.  In my use case here is what I imagine:

    1) ALM defect is created 

    2) mf connect syncs defect to JIRA as bug 

    3) mf connect runs again this time telling ALM defect what the newly created project key ID is BUG-1234 for example in field called “ref ID”

    4) someone decides to move BUG-1234 to an entirely different JIRA project 

    5) mf connect detects that the original jira project used to sync BUG-1234 changed and BUG-1234 is now really FIX-1234 inside JIRA 

    6) mf Connect is smart enough to then update “ref ID” field on the original defect field to FIX-1234 to continue the testing -> defect -> JIRA bug traceability end to end. 

Comment
  • I agree this idea description needs better wording. But I believe the spirit and intent is there. And I too would like to be notified if the project key ID from 1 JIRA project changes to another project.  In my use case here is what I imagine:

    1) ALM defect is created 

    2) mf connect syncs defect to JIRA as bug 

    3) mf connect runs again this time telling ALM defect what the newly created project key ID is BUG-1234 for example in field called “ref ID”

    4) someone decides to move BUG-1234 to an entirely different JIRA project 

    5) mf connect detects that the original jira project used to sync BUG-1234 changed and BUG-1234 is now really FIX-1234 inside JIRA 

    6) mf Connect is smart enough to then update “ref ID” field on the original defect field to FIX-1234 to continue the testing -> defect -> JIRA bug traceability end to end. 

Children
  • At Point 6) I'd like to have a choice:

    1.) Update field like suggested OR

    2.) Send Mail to Link-Admin and let him decide what to do. In my case I have some 1:n Jira-ALM-Links, in some n:1 Jira-ALM-Links each with multiple type rules in different Jira or ALM-Instances.

    In first case I'd have another Type Rule which would lead to Defect duplication and in second it would work fine.

    With Exporting and Importing Cross References it's a little pain in the butt, but it works fine