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.

This works also in the IE 8 ?

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.

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

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.

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

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.

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

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

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

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.

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.

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.

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.

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

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.

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.

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.