Uploaded image for project: 'Jira Platform Cloud'
  1. Jira Platform Cloud
  2. JRACLOUD-31465

Deleting JIRA filter/project may break greenhopper boards

    • 0
    • 9
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      NOTE: This suggestion is for JIRA Cloud. Using JIRA Server? See the corresponding suggestion.

      deletion/renaming of jira filters/projects should check if greenhopper is present and if so present a warning that this act may break greenhopper boards

            [JRACLOUD-31465] Deleting JIRA filter/project may break greenhopper boards

            The Jira Agile devs (who are fully aware that a board is based on a filter) say this is "expected" behavior, though I just had a visit from a user who found this totally surprising

            In https://jira.atlassian.com/browse/GHS-6706 someone from the Jira Agile team said they'd add a warning message, but from the reaction speed on the "small usability improvement" issues I've seen so far, I doubt I'll live to see it

            David Skreiner added a comment - The Jira Agile devs (who are fully aware that a board is based on a filter) say this is "expected" behavior, though I just had a visit from a user who found this totally surprising In https://jira.atlassian.com/browse/GHS-6706 someone from the Jira Agile team said they'd add a warning message, but from the reaction speed on the "small usability improvement" issues I've seen so far, I doubt I'll live to see it

            We just ran into this problem.

            Nancy Belser added a comment - We just ran into this problem.

            We ran into the same issue - this should really be fixed.

            Klaus Unterkircher added a comment - We ran into the same issue - this should really be fixed.

            Would be really nice if there could be a restriction if a filter is associated with a board. With the JIRA Agile 6.3.0.3 upgrade I've just found that we have 40 orphaned boards in the DB which are triggering the migration banner, but are not accessible.

            I can fix this in the database, but JIRA really should have a fail safe in place.

            Worst case scenario, if accessed by an admin, I should be able to update the board to a new filter from the GUI.

            Deleted Account (Inactive) added a comment - - edited Would be really nice if there could be a restriction if a filter is associated with a board. With the JIRA Agile 6.3.0.3 upgrade I've just found that we have 40 orphaned boards in the DB which are triggering the migration banner, but are not accessible. I can fix this in the database, but JIRA really should have a fail safe in place. Worst case scenario, if accessed by an admin, I should be able to update the board to a new filter from the GUI.

            i think a warning would be the strict minimum indeed, a stopgap before resolving the issue altogether of decoupling private filters from the Greenhopper 'admin' UI, i.e. ManageRapidViews + dropdown from top menu (ISSUES/AGILE)

            laurence bascle added a comment - i think a warning would be the strict minimum indeed, a stopgap before resolving the issue altogether of decoupling private filters from the Greenhopper 'admin' UI, i.e. ManageRapidViews + dropdown from top menu (ISSUES/AGILE)

            Jeison added a comment -

            As GreenHopper doesn't seem to be able to prevent this from happening (GHS-7063), a warning would be great.

            Jeison added a comment - As GreenHopper doesn't seem to be able to prevent this from happening ( GHS-7063 ), a warning would be great.

              Unassigned Unassigned
              cbenard Carlen Benard (Inactive)
              Votes:
              19 Vote for this issue
              Watchers:
              14 Start watching this issue

                Created:
                Updated:
                Resolved: