Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-27544

When creating a bug and "create another is checked" the description and time tracking fields are not cleared when creating the bug

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

      When you fill out a bug (like this one), turn on the "create another" checkbox, and click create, the bug is created just fine, but the "description" and time tracking values stick around. These fields need to change between issue creations so it makes sense to clear them.

        1. JRA-27544.patch
          0.5 kB
        2. screenshot-1.jpg
          screenshot-1.jpg
          104 kB
        3. Screen Shot 2012-03-16 at 3.47.51 PM.png
          Screen Shot 2012-03-16 at 3.47.51 PM.png
          127 kB

            [JRASERVER-27544] When creating a bug and "create another is checked" the description and time tracking fields are not cleared when creating the bug

            It's interesting how we see it completely different over here. For us clearing the "Description" field value when "create another" is tickled is a bug, actually.
            It is really useful when you:

            • Enter new items to backlog. Related user stories for some features very often sound similiar, have very similiar acceptance criteria, the description follows same template, they even come from one feature request.
            • When entering bugs discovered during testing it happens frequently testers to find several defects on the same scenario. It saves lots of time to not enter the detailed path again.
            • Some of our teams create very same task for set of people. E.g. each project leader gets a task from department head to prepare a report, as a task or sub-task. Description, summary, timetracking data, due dates - everything is same, just assignees differ.

            Pawel Ptaszynski added a comment - It's interesting how we see it completely different over here. For us clearing the "Description" field value when "create another" is tickled is a bug, actually. It is really useful when you: Enter new items to backlog. Related user stories for some features very often sound similiar, have very similiar acceptance criteria, the description follows same template, they even come from one feature request. When entering bugs discovered during testing it happens frequently testers to find several defects on the same scenario. It saves lots of time to not enter the detailed path again. Some of our teams create very same task for set of people. E.g. each project leader gets a task from department head to prepare a report, as a task or sub-task. Description, summary, timetracking data, due dates - everything is same, just assignees differ.

            Yes, this should work in IE.

            Eric Dalgliesh added a comment - Yes, this should work in IE.

            Sven.H added a comment -

            This works also in the IE 8 ?

            Sven.H added a comment - This works also in the IE 8 ?

            Sean Curtis (Inactive) added a comment - - edited

            QA this one for the retention of the Description field - not attachments (tracked in JRA-33652)

            Sean Curtis (Inactive) added a comment - - edited QA this one for the retention of the Description field - not attachments (tracked in JRA-33652 )

            ohernandez@atlassian.com The update for this should now be on stable and ready for retesting.

            Marty Henderson (Inactive) added a comment - ohernandez@atlassian.com The update for this should now be on stable and ready for retesting.

            When you say you're clearing: "timetracking_originalestimate" do you mean the field I've circled in red in screenshot-1? That is the field I'm concerned about.

            Monica Bowen added a comment - When you say you're clearing: "timetracking_originalestimate" do you mean the field I've circled in red in screenshot-1? That is the field I'm concerned about.

            Yep, we're looking at JRA-30942 next. It's a bigger issue though so may take a while.

            Eric Dalgliesh added a comment - Yep, we're looking at JRA-30942 next. It's a bigger issue though so may take a while.

            ZachE added a comment -

            It is disappointing that you think we would want every single custom field to retain the same value in the next issue creation.

            I hope you'll still fix the related (but much more damaging) issue JRA-30942 - Retaining values we entered is one (annoying) thing, retaining unaltered default values from a different issue type is a MUCH worse (bug) problem.

            ZachE added a comment - It is disappointing that you think we would want every single custom field to retain the same value in the next issue creation. I hope you'll still fix the related (but much more damaging) issue JRA-30942 - Retaining values we entered is one (annoying) thing, retaining unaltered default values from a different issue type is a MUCH worse (bug) problem.

            Quick edit plugin bumped to 1.0.74 to incorporate the fixes for this.

            Marty Henderson (Inactive) added a comment - Quick edit plugin bumped to 1.0.74 to incorporate the fixes for this.

            joseph.feser I'll mark a fix version on this and when it is available to the public this should ship with it.

            Marty Henderson (Inactive) added a comment - joseph.feser I'll mark a fix version on this and when it is available to the public this should ship with it.

              edalgliesh Eric Dalgliesh
              edalgliesh Eric Dalgliesh
              Affected customers:
              10 This affects my team
              Watchers:
              21 Start watching this issue

                Created:
                Updated:
                Resolved: