We need this feature!! 18 years since this was created

critical element. that and story points.

Need this as well

Yes, i need this as well.

Folks, this issue is old enough to vote, I don't think it's gonna go anywhere. I had to dig out an ancient account to log back in to un-watch it so I stop getting pinged on other people also asking for it.  Good luck out there.

We definitely need this feature.

For me this feature is needed because of testing plugins create a lot of test issues, which efforts are so small that can be omit, but still they appear as not estimated issues in the reports. This feature can easily make them all estimated to 0.

As a workaround, you can configure an automation to set the remaining estimate to X when an issue is transitioned to a state.

We use this automation: When issue is transitioned to Done, then edit issue field Remaining Estimate.

I could have used this feature so many times already. It means that now I'll need to manually update 22 cards and colleagues will get spammed with emails about these changes.

Please re-evaluate this.

Still a desperately needed feature. Please re-evaluate the 2016 response.

+1

Just migrated from Jira Server to Jira Cloud, huge regression from my point of view 
We need this to easily close issues and erase remaining time on tasks

+1

Hi

At Divim, we saw our customers struggling with this issue and we created Backlog refinement and Sprint planning.

https://marketplace.atlassian.com/apps/1220864/backlog-refinement-and-sprint-planning?tab=overview&hosting=cloud

It allows you to find all the stories without an estimate (in story points), and all the subtasks without a time estimate. 

Let me know if you would like to see other features as well.

Jerry

+1

we need this

+1 We need this. Why is it only available for the Server version? Jira Cloud should also offer this!

+1

@dmeyer Testing mention functionality (b/c they seem to get used here, but there's no user lookup functionality available via Comment editor @ symbol invocation). Not sure if I'll be able to delete this, so apologies and please disregard if I'm unable.

+1

+1 From here too.

Much needed for daily project management tasks.

can we please get this feature? 

Very annoing, I miss this afer swiching to Jira Cloud.

I really don't understand why some things are omitted like this. We want full control, even when using the cloud version!

+1 

urgently needed for our daily operations and project management

I know this was fixed last year in Data Center, it would be great if users of Cloud could have these handy feature as well.

+1

Would really like to be able to bulk change time estimations.

Hello everybody. If I understand the issue here correctly, this is easily doable by just copying and pasting, using our spreadsheet app JXL: https://jxl.app

• Install JXL your Jira site
• Create a sheet inside Jira with all the issues you want to change (you can write JQL for this)
• Add the Original estimate column to the sheet (or whatever field you want to bulk change)
• Edit, mark and copy (⌘/Ctrl + C) a cell with the desired field value
• Mark multiple cells and paste (⌘/Ctrl + V) the copied value into them
• JXL takes care of the bulk change for you instantly

Hope that helps. It works with hundreds or thousands of issues.

Disclaimer: I'm co-founder of the app vendor behind JXL. Your feedback is welcome and much appreciated. There's a free fully functional trial available on the Atlassian Marketplace here: https://marketplace.atlassian.com/1224710 (check out the short demo video)

+1 we would like to have this feature

we need that feature

Bhuvnesh.Chandra, see the description at the top of the page: "unfortunately we don't have any plans to support this in JIRA for the foreseeable future".

Is this feature coming up or just a ticket is open  

+1 need for our team, as we just started using the time estimate this was requested.
 

NOT available for me as well 

I can't believe such an obvious feature hasn't been implemented in Jira Cloud yet. A 16 year wait and still not done even though it was for server over a year ago.

Just submit a ticket now and maybe by the time your new born child is ready to start college it will have been addressed. Simple! 16 years is entirely a reasonable time for an open ticket!

This is not available for me in Jira Cloud as well.

Still not available in Jira Cloud in my instance.

Jira Cloud does not mirror Server. A lot of Server features are missing from Cloud.

Should be available in Cloud version, as it is also available for server and data center.

Suggested workaround using Jira API is unusable for non devs - rather unsatisfying that you need to have your own Jira Admin developer although using the cloud version, specially, if this version is focussing on nice UI (beside confusing UX changes) instead of functionality.

Thanks

Can we please get this for the cloud?

This was implemented on Jira Server now - can anyone provide an idea of whether this will make it into Jira Cloud?

The Jira Server task has been marked as In Progress. Great news! Will that in progress feature work be passed to Jira Cloud?

Yes, this would be really great. Also, it should support third party plugins like tempo.

Working on a project where this feature would've helped to streamline some of the process in managing 600 issues.

andy.holvoet,

You can get a set of issues by calling the {{/search} endpoint with the ?jql= query parameter and a URI encoded string of JQL, e.g.

https://baseurl.atlassian.net/rest/api/2/search?jql=project%20%3D%20DEMO%20and%20%22text%20field%22%20~%20%22asdfasdf%22&fields=worklog

In this example I also passed worklog in the fields expansion to expand the worklog objects in each issue that is returned.

Each issue object contains a self URL that is the REST representation of the worklog, like this:

"worklogs": [
                        {
                            "started": "2016-09-07T00:00:00.000+1000",
                            "self": "https://baseurl.atlassian.net/rest/api/2/issue/10103/worklog/10300",
                            "updated": "2016-09-07T23:59:56.722+1000",
                            "issueId": "10103",
                            "id": "10300"
                            ...
                         }
               ...
            ]

You can then call the update worklog REST API to change the remaining estimate, like this:

https://baseurl.atlassian.net/rest/api/2/issue/DEMO-4/worklog/10300?adjustEstimate=new&newEstimate=50m

by using the adjustEstimate and newEstimate query parameters. In case I changed the new estimate to 50 minutes, but you could easily provide "0" as well.

The workaround is to write a script to make the initial REST API call to get the worklogs, parse the response, and then make each individual worklog update request.

Hope this helps.

Dave Meyer
Senior Product Manager, JIRA

Issue created on 25/Oct/2004 Nice of Atlassian to care about the input of their users...

@dmeyer Can you please provide a more specific link to the workaround you suggest with the REST API? Can you elaborate on how to set the remaining estimate to 0 with the REST API?

Please implement this, this is a feature we have needed at the moment. Affects version 6.4.12

@martin Gregory I would see it as at first a free thing to use as a lead magnet for a business agency or for another product. So you could promote your product and here are an email list from it. As people would only need it every 2-4 weeks for a minute or two. It would be a help and people will be likely to search For a fix. Also just take the names of everyone on here in 10 years of comments.

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

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

Hear hear! I have to do an export to Excel every day to get tasks with 'zero time estimate,' and then I have to manually go through and set estimates. Often we have dozens of bugs that all get a default 2 hour estimate. This is tedious!

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.