• 1
    • Severity 3 - Minor
    • No

      Issue Summary

      Only certain Epics get listed twice on the Live Roadmap.

      This seems to be a different case from the previously reported bug JIRAALIGN-4558
      In this new scenario, we did not apply any rank to Epic prior to the duplicate, so it seems to have a different source as a problem.

      Steps to Reproduce

      1. Set in the tier 1 filter a:
        1. Program or a Team
        2. Program Increment
      2. Go to Programs > Roadmap
      3. Select Work > Portfolio Epics
        (You can enable the 'Group by' option under the View configuration although it does not have an influence).

      The issue was observed with Epic 3096 in our local instance alignsupport. This only happens locally, when we use 2 specific PIs on the config bar, 523 - Mangala Report PI and 381 - Mangala Release two (both need to be present on the filter for this to happen). Unfortunately, we can't reproduce it in other examples.

      Expected Results

      No duplicate Epics are shown in the Live Roadmap.

      Actual Results

      Duplicate Epics appear under the name column (within the same grouping if enabled) as shown in the images below with state grouping

       

      Workaround

      Currently, there is no known workaround for this behavior. A workaround will be added here when available

        1. Epic duplicate.png
          210 kB
          Mangala Narayana

          Form Name

            [JIRAALIGN-4987] Epics are displayed twice in the live Roadmap

            Thank you, @Inna!

            Victor Galli added a comment - Thank you, @Inna!

            Inna Dogan added a comment -

            The defect is fixed in 10.126.2

            Inna Dogan added a comment - The defect is fixed in 10.126.2

            Hi @Don & @Mangala, it looks like the current values in this Bug's status and fix version/s fields don't make sense together. Would you be willing to update this Bug's status or fix version/s field to reflect its current state?

            Victor Galli added a comment - Hi @Don & @Mangala, it looks like the current values in this Bug's status and fix version/s fields don't make sense together. Would you be willing to update this Bug's status or fix version/s field to reflect its current state?

            a8cff3407f0b Looking at the example, I noticed that there is a feature associated with the epic despite it being in a portfolio where capabilities are enabled and also having a capability associated with it. I'm pretty sure this is causing our query to return two rows as it gets the number of capabilities associated with the epic and the number of features associated with the epic separately, and merges those two results into a temporary table but expects there to only by one entry for the epicId in the table since an epic shouldn't be able to have both a capability and a feature as a direct descendent. 

            For the example data, if you look at the duplicate rows in roadmaps you'll notice that one row has 1 as the value for the Items column, this is the number of capabilities, and the other row has 2 for the value for the items column, this number being the features. If you go to the Features grid, you can then see features "Mangala PI Status report" and "Mangala test ProcessStep copy" which both appear to be "Contained in" the duplicated epic "Mangala Epic1 Process Step1" despite not having a parent capability.

            I can solve this issue in our roadmaps query, but would you be able to verify with the customer if this is the case with their data as well? Maybe a simple check would be to look at the duplicated rows and see what number the "Items" column displays and see if those numbers match up with the number of capabilities and features associated with the epic?

            Nick Gretta added a comment - a8cff3407f0b Looking at the example, I noticed that there is a feature associated with the epic despite it being in a portfolio where capabilities are enabled and also having a capability associated with it. I'm pretty sure this is causing our query to return two rows as it gets the number of capabilities associated with the epic and the number of features associated with the epic separately, and merges those two results into a temporary table but expects there to only by one entry for the epicId in the table since an epic shouldn't be able to have both a capability and a feature as a direct descendent.  For the example data, if you look at the duplicate rows in roadmaps you'll notice that one row has 1 as the value for the Items column, this is the number of capabilities, and the other row has 2 for the value for the items column, this number being the features. If you go to the Features grid, you can then see features "Mangala PI Status report" and "Mangala test ProcessStep copy" which both appear to be "Contained in" the duplicated epic "Mangala Epic1 Process Step1" despite not having a parent capability. I can solve this issue in our roadmaps query, but would you be able to verify with the customer if this is the case with their data as well? Maybe a simple check would be to look at the duplicated rows and see what number the "Items" column displays and see if those numbers match up with the number of capabilities and features associated with the epic?

              dfuller@atlassian.com Don Fuller
              37857daa0c44 Mangala Narayana
              Affected customers:
              2 This affects my team
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: