JIRA
  1. JIRA
  2. JRA-8248

Retain values checkbox for Bulk Move should preserve versions or components based on version and components names

    Details

    • Support reference count:
      26

      Description

      Each project has different versions and components and therefore when moving issues between projects the versions and components will always be changed. We can make this option a bit more smart by letting JIRA check the version name and then change the versions and components based on name if the retain checkbox has been set.

      This gets tricky if more than one version/component has been selected on the issue, and a match is found for one of the selected versions/components. In this case should we:
      a) remove the version/component that does not have a version/component with the same name in the destination project
      b) remove the invalid version/component and replace it with the option entered by the user. In this case the values that do have a matching mapping in the destination project based on name will be kept
      c) completely replace the values with the ones entered during move.

      1. bulkmigration_mapping.png
        28 kB
      2. bulkmove_retain.png
        75 kB
      3. bulk-move-retain-3.11.png
        36 kB

        Issue Links

          Activity

          Hide
          Randy Hall added a comment -

          Grrr – I just wasted hours digging into why this didn't work. I created a doc bug: JRA-18485, please be up front about these kind of things.

          Show
          Randy Hall added a comment - Grrr – I just wasted hours digging into why this didn't work. I created a doc bug: JRA-18485 , please be up front about these kind of things.
          Hide
          Dev Govindaswamy added a comment -

          I see this has been scheduled for 4.1 that is going to get released in April. Can we get a confirmation that this bug is indeed going to be fixed in 4.1? There is data loss because of this bug and this is turning out to be a huge issue for us when there are 7,000+ users of our system moving issues between project. Would really appreciate if the Program Mgmt team can comment and assure us that the bug will indeed be fixed in 4.1.

          Thanks
          Dev

          Show
          Dev Govindaswamy added a comment - I see this has been scheduled for 4.1 that is going to get released in April. Can we get a confirmation that this bug is indeed going to be fixed in 4.1? There is data loss because of this bug and this is turning out to be a huge issue for us when there are 7,000+ users of our system moving issues between project. Would really appreciate if the Program Mgmt team can comment and assure us that the bug will indeed be fixed in 4.1. Thanks Dev
          Hide
          Michael Tokar [Atlassian] added a comment -

          The fix has been passed through QA and will definitely be available in 4.1.

          Show
          Michael Tokar [Atlassian] added a comment - The fix has been passed through QA and will definitely be available in 4.1.
          Hide
          David Weiser added a comment -

          Is there any way to cope with this problem in 4.0? I'm trying to migrate over 1000 issues from different projects into one project to cut down on what has become an overly complicated setup. The version and component information are critical. I have consistent component and version names across the projects, but JIRA seems to still be unable to retain them even if the same name is available.

          Show
          David Weiser added a comment - Is there any way to cope with this problem in 4.0? I'm trying to migrate over 1000 issues from different projects into one project to cut down on what has become an overly complicated setup. The version and component information are critical. I have consistent component and version names across the projects, but JIRA seems to still be unable to retain them even if the same name is available.
          Hide
          Jeff Kirby added a comment - - edited

          Though this has been marked as resolved in 4.1, we still see problems with this and with Issue Security Level in Jira 4.1.2.

          For example, if an admin changes a project's issue security level scheme in the middle of the day during a busy period - say 11 AM - then issues that are being concurrently modified by other users will still have their Issue Security Level set to levels from the old scheme which means that no one can see them once this happens and an admin has to go into the database and manually fix the security level for each issue.
          It's not limited to Issue Security Level. I see it with versions and components, too, still, in Jira 4.1.2

          Show
          Jeff Kirby added a comment - - edited Though this has been marked as resolved in 4.1, we still see problems with this and with Issue Security Level in Jira 4.1.2. For example, if an admin changes a project's issue security level scheme in the middle of the day during a busy period - say 11 AM - then issues that are being concurrently modified by other users will still have their Issue Security Level set to levels from the old scheme which means that no one can see them once this happens and an admin has to go into the database and manually fix the security level for each issue. It's not limited to Issue Security Level. I see it with versions and components, too, still, in Jira 4.1.2

            People

            • Assignee:
              Michael Tokar [Atlassian]
              Reporter:
              Anton Mazkovoi [Atlassian]
            • Votes:
              64 Vote for this issue
              Watchers:
              42 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: