@Trista Bailey ... how much would you pay? How often would you pay? The problem for any small startup filling a gap like this is that it is crucial when you need it, but the typical user only bumps into it rarely. When they do, they are mad as hell that a basic feature like this isn't there, but its hard to see anyone subscribing even $5pm for this. Especially because no-one likes paying for features that should be in there anyhow.

To JIRA: Why not just close this ticket out if you're never planning on doing anything with it?

@Darren Pye I think we all agree.

What we need is a small startup with java or api skills to make a dashboard app for this, that at least grabs all at the end of a sprint and checks for 0s and adds to bulk edits, then back to JIRA for rest.

Money in them there Rock Hard hills

I'm planning a new release and we have a lot of items that need to be verified and I'm trying to update the items with times so we can get a sense of the scope of the verification process other than manually calculating. Being able to bulk update the time remaining or original estimate (as a work around) would make this easy. I was quite surprised to find out that JIRA, being a planning tool.... lacks such basic support for... well... planning Please add

+1

+1

+2016

+1

+1

Hi macnewbold,

Bulk Edit was introduced in JIRA 2.5, back in 2004. Unfortunately I wasn't on the team then so I can't provide any context on why it wasn't implemented originally.

As for why it isn't currently planned: in order to prioritize our work, we generally identify several themes or focus areas that we believe need the most attention, and develop our roadmap around that. Currently those top investments look like:

1. Performance/page response times
2. Simplifying navigation and key user experiences (boards and backlogs, search)
3. Reducing complexity around project configuration (all the different schemes)

You can learn more about our process here – while we pay quite a bit of attention to the comments, votes, and sentiments of feature requests on jira.atlassian.com, usually the age of an issue isn't a factor. We don't follow a "last in, first out" approach to our roadmap – we are continually re-evaluating to determine what we could do to improve reliability, usability, or functionality for the most customers today. The best improvement we could make for folks may be on a feature that didn't exist when this issue was created.

That's not to say I don't think this should be supported, I do. Just at a high level, there is this request at dozens and dozens like it, and simply have to prioritize with limited staff.

My email address is in the description if you would like to follow up.

Regards,
Dave

dmeyer, do you know why this wasn't available in the first place, or why it isn't planned to be corrected? People have literally been asking for it for over 11 years now...

Hi dmeyer thanks for your follow up. 99% of the times I need to bulk edit estimates is because the CSV Import did something wrong, like JRA-44971 and JRA-43546. Hope at least one of these issues get resolved by Atlassian.

Thanks!

+1

@DMeyer thank you for taking the time to review this feature request again.

We will keep +1uping and see if you are more interested next time.

Hi everyone,

Thanks for voting and commenting on this issue. Your feedback is key to helping us understand how you use JIRA so we can continue improving your experience. We have reviewed this issue over the last few days; unfortunately we don't have any plans to support this in JIRA for the foreseeable future. In the meantime, we recommend bulk editing worklogs via the JIRA REST API

Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.

I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.

Regards,
Dave Meyer
dmeyer@atlassian.com
Product Manager, JIRA Platform

+1

Yes please

Yes please.

+1 once again please.

This would be incredibly useful for our organisation. Please do something about this Atlassian!

Yes, for anyone who has to use Jira to drive product deliverables, not being able to bulk edit certain fields does make it quite painful. I understand this is not a simple field and there may be some logic behind the updates, but that should be doable as there will be a huge benefit to the user community.

It's getting a little bit sad on this ticket, that it does not seem such a big issue to fix but even JIRA have posted back to this ticket that they do not see it as important and are not going to fix it in the medium term. I hope they do find space to have this as a feature as its been past 10 years requested.

How about a #bulktimeedit hashtag twitter day on the 24th October 2015 on the 11year anniversary of this request

"On 24th Oct, 11 year anniversary of @jira Bulk Time Edit feature request for please @d_meyer http://bit.ly/1hnuA2Y #bulktimeedit #agile" Or what ever you would like to say to the Product owner and team to get this one tabled,

Here is the tweet as link

This is painful. Am facing manually editing over a hundred estimates.

+1 Very importent feature!

+1 for the feature!

Such a feature would be great. Would save me a lot of time right now...have to "fix" a lot of issues where the Estimates were not done and now can not be verified...

Very much needed.

+1. very much needed

+1. Please have this

+1 . click on more and click add vote

Hope all those +1s in comments are also +1 in the votes (top right)

+1. Why is this not already a thing?

We really need it, we use our boards based on time estimation, so when I put bugs I want them to add time estimation. we estimate all bugs preliminary as 2 days (we have statistics of thousands of bugs and that's the average time), and as you know, before diving into a bug there is no chance to know how much it will really take, so I want to take all bugs assigned to a sprint and give them a 2d estimation and see how much time my sprint will take, to know how much content I have to take out of it....

very much needed

+1.

In my use case, it's not only the remaining estimates on done issues that I need to bulk edit, but also the original estimates on untouched issues.

Very much needed.

So there is a workaround here. On our instance, this was a recurring issue, so we tweaked the workflow adding a post function to reduce the remaining time to zero when transitioning from Resolved to Closed.

You can bulk transition issues from Resolved to Closed (or if you wanted a hackier hack, add a dummy transition state that is not a natural transition state), which kicks the post function and reduces the remaining time.

Job done.

This is less of a suggestion and more of a bug. Not being able to edit the logging fields in bulk surmounts to a lot of time wasted in reality.

10 years since the issue was created but still no Assignee for it?

Can this be prioritised? this has gained a fair bit of interest?
thanks
AK

We need to edit the remainingEstimate Field in Bulk Mode.
Please.

I have a bunch of tickets where "user error" has resulted in an original estimate of 0m (not unestimated).

I need to fix all these - they need to be set to "unestimated". How can I sensibly do this?

Yes I agree. I didn't previously mind the remaining hours on the jobs but when I realised that is what was blocking the burndown and reporting pages from ignoring all remaining time, it became a frustration.
I was pleased that at least I could write an advanced search to find the issues, but having to go about 3 steps with each one to close the time out makes it very frustrating.
"status in (Resolved, Closed) AND remainingEstimate != 0 ORDER BY originalEstimate DESC, key DESC"
Without a bulk edit which you might not need or what to do accidentally for anything but this, two options
1. option to check Zero time on close task workflow
2. burn down charts do not count Closed or Released tasks remaining time.

Based on advise from Atlassian, I initially resolved this issue by setting a "post function" in the workflow to set Remaining Estimate to zero when a ticket is resolved. This worked fine for the Jira ticket but the post function change is not recognized by the GreenHopper agile burndown chart so the value of Remaining hours in the burndown becomes progressively out of sync with a Jira dashboard pie chart. Therefore I had to remove the post function and now continue to run a query to monitor resolved issues that have none zero remaining estimate and adjust manually. If a batch function is provided it must also be recognized by the GH burndown. Providing a bulk edit for this issue is somewhat of a work-around, this problem could also be resolved if the default value for Remaining Estimate was zero for a status change to resolved/closed. In my opinion, a user should not be required to use external tools (such as mySQL) to maintain the integrity of the data in Jira/Greenhopper.

Any movement on this ticket? I would really like to be able to Bulk Edit the "Remaining Estimate" for all closed and resolved tickets like Roy said 6 months ago. It effects the burn down charts not showing correctly if developers have closed tickets but not 0ed the remaining time on the issue.
Please consider adding a Bulk action to this field.

This can also be done via MySQL, the fields are:

`jiraissue`.`TIMEORIGINALESTIMATE`,
`jiraissue`.`TIMEESTIMATE`,
`jiraissue`.`TIMESPENT`,

and are tracked in seconds, but with Jira's workday/week logic applied, so a week is 144000 seconds ( =5 days * 8 hours/day * 3600 seconds/hour)

Atlassian - any deep reason why the custom field type can't just set isAvailableForBulkEdit to true?

Everyone else - a workaround would be to use the JIRA CLI to update each issue individually

Being able to Bulk Edit the "Remaining Estimate" for all closed and resolved tickets would allow us to clean up tickets that the developer forget to set to zero. (I have since added Post Conditions to force it to zero upon Resolve going forward).

Agreed - this is functionality that is very much desired. If there is documentation for writing code into place to implement the change using the events? I cannot find any definitive documentation on how to accomplish this task and it is very time consuming when processing manually.

Yes, this is really painful. I had just assumed the capability would be there.

Please fix. If you want to set a minimum time estimate, bulk is the correct operation. Especially since editing is so hard in Jira. You press next, you press Edit, you have to use the mouse, you click on the field, you enter the value, you press save, you press next......

Any activity on this? There is no way to find issues that don't have an estimate, so we'd like to change all the empty estimate issues to zero so we can then search on that, but we can't do that either because of this issue. Another option is to set a default estimate of 0 when issues are created but I also can't find a way to do that.