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

          Form Name

            [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.

            joefeser added a comment -

            Those fields make sense. How will we know when it is rolled out?

            joefeser added a comment - Those fields make sense. How will we know when it is rolled out?

            Based on analytics information gathered in the past while it has been decided to implement the clearing of the following fields when the 'create another' checkbox is set:

            • description
            • timetracking
            • timetracking_originalestimate
            • timetracking_remainingestimate

            All other field behaviour will remain the same.

            Marty Henderson (Inactive) added a comment - Based on analytics information gathered in the past while it has been decided to implement the clearing of the following fields when the 'create another' checkbox is set: description timetracking timetracking_originalestimate timetracking_remainingestimate All other field behaviour will remain the same.

            My concern is the way hours are getting duplicated and filled in automatically from one subtask to the next.

            Monica Bowen added a comment - My concern is the way hours are getting duplicated and filled in automatically from one subtask to the next.

            Joseph, we're going to be making more changes than just what's in the patch. The current plan is to get this into a 6.0.x release, but I can't promise anything yet, unfortunately, because we haven't started the relevant work on this and something may come up. A Chrome adding will let you work around it without having to upgrade, so it's really up to you what you want to do.

            Eric Dalgliesh added a comment - Joseph, we're going to be making more changes than just what's in the patch. The current plan is to get this into a 6.0.x release, but I can't promise anything yet, unfortunately, because we haven't started the relevant work on this and something may come up. A Chrome adding will let you work around it without having to upgrade, so it's really up to you what you want to do.

            joefeser added a comment -

            Eric, the patch was attached to the issue 9 months ago. Do you have an ETA on when this will be fixed or is it easier for me to write a chrome addin to work around this issue?

            joefeser added a comment - Eric, the patch was attached to the issue 9 months ago. Do you have an ETA on when this will be fixed or is it easier for me to write a chrome addin to work around this issue?

            Zachary, you're correct about the root cause, which is why there are so many similar issues all closed as duplicates of this one and JRA-30942. When we fix this is will be in conjunction with that issue.

            Eric Dalgliesh added a comment - Zachary, you're correct about the root cause, which is why there are so many similar issues all closed as duplicates of this one and JRA-30942 . When we fix this is will be in conjunction with that issue.

            ZachE added a comment -

            My comment above is probably more properly regarding JRA-30942 but I wouldn't be surprised if these issue share a root cause.

            ZachE added a comment - My comment above is probably more properly regarding JRA-30942 but I wouldn't be surprised if these issue share a root cause.

            ZachE added a comment -

            It is odd that JRA-30398 was made a duplicate of this but this issue's summary hasn't been altered. This is about a lot more than the "description" field.

            The description field is the least of my concerns. That's easy to notice and clear out and I see that Atlassian people are having some internal discussion about whether there is any value in retaining the description field.

            It is ALL THE OTHER fields that are a big concern and a HUGE hassle. ESPECIALLY fields we have specified a default value for that varies from issue type to issue type. That's a HUGE problem. I create one issue type and get the default value for a given field pre-populated, but then when I create another of a different issue type (actually even if I didn't just create an issue but merely changed the issue type in the dialog from one to another) the default value for the field from the previous issue type sticks. That really sucks! I never typed in that default value and the new issue type has a different default, why should it stick. That's DEFINITELY a bug wheras the description thing could arguably be a feature (though I see it as a bug).

            ZachE added a comment - It is odd that JRA-30398 was made a duplicate of this but this issue's summary hasn't been altered. This is about a lot more than the "description" field. The description field is the least of my concerns. That's easy to notice and clear out and I see that Atlassian people are having some internal discussion about whether there is any value in retaining the description field. It is ALL THE OTHER fields that are a big concern and a HUGE hassle. ESPECIALLY fields we have specified a default value for that varies from issue type to issue type. That's a HUGE problem. I create one issue type and get the default value for a given field pre-populated, but then when I create another of a different issue type (actually even if I didn't just create an issue but merely changed the issue type in the dialog from one to another) the default value for the field from the previous issue type sticks. That really sucks! I never typed in that default value and the new issue type has a different default, why should it stick. That's DEFINITELY a bug wheras the description thing could arguably be a feature (though I see it as a bug).

            joefeser added a comment -

            I raised this as a customer support issue asking why something that is so trivial made like live total hell last night trying to enter a bunch of issues.

            joefeser added a comment - I raised this as a customer support issue asking why something that is so trivial made like live total hell last night trying to enter a bunch of issues.

            Yes, I was just having this problem again two days ago when I had to enter a lot of stories with lots of subtasks into Jira, and I was wondering why this still has not been fixed.

            Monica Bowen added a comment - Yes, I was just having this problem again two days ago when I had to enter a lot of stories with lots of subtasks into Jira, and I was wondering why this still has not been fixed.

            joefeser added a comment -

            I am not sure why this is not a higher priority issue? 6 months to clear a field out when you batch create issues?

            This is verified as a bug in The latest Chrome on Windows 7.

            joefeser added a comment - I am not sure why this is not a higher priority issue? 6 months to clear a field out when you batch create issues? This is verified as a bug in The latest Chrome on Windows 7.

            Monica Bowen added a comment - - edited

            Monica Bowen added a comment - - edited This issue also relates to: https://support.atlassian.com/browse/JST-63445

            The best way is to have an analytics expert show you the ropes. Matt or Josh Devenny are not only two of my favorite people but experts in slicing and dicing our datums.

            Justus Pendleton (Inactive) added a comment - The best way is to have an analytics expert show you the ropes. Matt or Josh Devenny are not only two of my favorite people but experts in slicing and dicing our datums.

            mquail, were you the one who wanted to see the analytics for this? It has been running for a few months now. What's the verdict?

            Justus Pendleton (Inactive) added a comment - mquail , were you the one who wanted to see the analytics for this? It has been running for a few months now. What's the verdict?

            Is there any use case where you would think this is useful? When would you create several issues in series and want to retain the description?

            I have found this useful once.
            I was creating 20-30 issues where the description was 99% the same for every one, (I just changed a DB table name for each).

            However, I agree that in by far the majority of cases, this is not useful and likely to be annoying.

            Mark Lassau (Inactive) added a comment - Is there any use case where you would think this is useful? When would you create several issues in series and want to retain the description? I have found this useful once. I was creating 20-30 issues where the description was 99% the same for every one, (I just changed a DB table name for each). However, I agree that in by far the majority of cases, this is not useful and likely to be annoying.

            Thank you Eric for the clarification.
            The only thing is that this is a major security issue, because issues can have the wrong security level!

            Regards,
            Almar

            Almar Hollaar added a comment - Thank you Eric for the clarification. The only thing is that this is a major security issue, because issues can have the wrong security level! Regards, Almar

            Hi aho,

            Both of these bugs have the same cause - when the create issue popup's context changes, the fields that are retained and the fields that are reset are not ideal. The current behaviour was deliberately chosen and should be changed. We want to really think about how it should behave rather than apply a set of small unrelated patches.

            Regards,
            Eric

            Eric Dalgliesh added a comment - Hi aho , Both of these bugs have the same cause - when the create issue popup's context changes, the fields that are retained and the fields that are reset are not ideal. The current behaviour was deliberately chosen and should be changed. We want to really think about how it should behave rather than apply a set of small unrelated patches. Regards, Eric

            I can't see why issue JRA-30638 is duplicate of this issue! Please explain.

            Almar Hollaar added a comment - I can't see why issue JRA-30638 is duplicate of this issue! Please explain.

            On Customer request, a checkbox option for copying the relevant fields would be useful.

            Ivan Maduro (Inactive) added a comment - On Customer request, a checkbox option for copying the relevant fields would be useful.

            Ivan Tse added a comment -

            This extends beyond just the description field. I see the fields staying the same for every field I fill in except for the attachments and description as was listed.

            I believe it would make more sense to have all fields cleared.

            Ivan Tse added a comment - This extends beyond just the description field. I see the fields staying the same for every field I fill in except for the attachments and description as was listed. I believe it would make more sense to have all fields cleared.

            Is there any use case where you would think this is useful? When would you create several issues in series and want to retain the description? I would think if users routinely have to go out of their way to delete it and replace it, a strong case is made.

            Sam Hopkins added a comment - Is there any use case where you would think this is useful? When would you create several issues in series and want to retain the description? I would think if users routinely have to go out of their way to delete it and replace it, a strong case is made.

            ChrisA added a comment -

            By design, the quick create/edit dialog retains all fields except summary and attachments. We don't feel that there's a strong enough case to add description to this list of special-cases, but we're open to feedback.

            ChrisA added a comment - By design, the quick create/edit dialog retains all fields except summary and attachments. We don't feel that there's a strong enough case to add description to this list of special-cases, but we're open to feedback.

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

                Created:
                Updated:
                Resolved: