Project

General

Profile

Actions

Feature #11313

open

Automatic closing of resolved issues

Added by Pavel Loginov over 12 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Issues workflow
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:

Description

Are there any plans to implement this feature?
Would be great to turn on automatic closing of issues, if they have been marked as resolved for X days.
I know, that there is a plugin there, but it's not been updated for quite a while now and doesn't install on some instances of RedMine.
What do you think guys?


Related issues

Related to Redmine - Feature #1306: resolution fixed and % done out of syncNew2008-05-26

Actions
Has duplicate Redmine - Feature #16769: auto-close resolved issuesClosed

Actions
Actions #1

Updated by Alex Shulgin over 12 years ago

What is the point? Any resolved issue is also considered closed (by default.)

Actions #2

Updated by rm user over 12 years ago

Yes, it would be helpful.

1) Resolved doesn't mean issue is closed
2) Closed issue means you don't need to get back to issue anymore, it's completely closed.
3) Resolved doesn't mean always that issue was properly fixed, very often it needs testing.

Actions #3

Updated by Pavel Loginov over 12 years ago

Exactly. In our workflow every resolved issue needs to be closed by project leader or issue author. However, people are no robots and sometimes miss/forget to review a resolved issue which then simply goes down the issue queue. Would be highly useful if such issues could be auto-closed after "expiration".
So I think it's pretty simple and straight forward: if an issue's status was "A" for X days, then it's status is changed to "B". That's it.
Is it possible to just update the old plugin https://github.com/edtsech/redmine_x_closed/tree so that it installs on the newest versions of Redmine?

Here's another request for this, posted a year ago: http://www.redmine.org/boards/3/topics/20046 ...

Actions #4

Updated by Alexey Chepurnykh almost 12 years ago

It's a highly required feature. In our installation we have an agreement: if a resolved issue is not closed for 30 days, we close it by hands. The "Langoliers" eat my time. Please, help.

Actions #5

Updated by Filou Centrinov almost 12 years ago

For "Resolution: Cant reproduce" this feature would be also helpful. A suitable delay time might be 90 days.

Actions #6

Updated by Dipan Mehta over 11 years ago

There is some interesting discussion on #1306 for similar aspect.

Actions #7

Updated by Anonymous over 11 years ago

For me it would also be useful to have such a feature. For me, the inspiration is the (old / classic-style) SourceForge.net tracker. There, a status "Pending" exists for issues. If an issue is put into status "Pending", then if no change is made to it within 14 days, it is automatically closed. On the other hand, if a change is made, it is automatically put back to status "Open".

Having such a feature would be highly useful to us. And perhaps also to redmine.org: There are many ancients reports here, and for many, redmine staff now is adding comments like "Please respond until DATE, otherwise we will close this issue". But staff has to remember those issues, and on/after DATE, go back to them, and change their status manually to closed. With a "pending" status that could be automated.

Of course in Redmine, one may want to have a somewhat more general "status transition" facility. I.e. it would be nice if each issue status would get these extra fields (in addition to the existing "Name", "Issue closed" and "Default value"): * "If issue is in this status for more than [ checkbox / textfield ] days, change status to [ popup ]." * "If issue is updated while in this status, change status to [ popup ]."

(Of course the last option would only have an effect if the user making the issue update did not select some other target status manually).

Actions #8

Updated by Evgeny Smirnov over 11 years ago

+1

Actions #9

Updated by Miodrag Milic about 11 years ago

+1

Actions #10

Updated by Matthew Houston almost 11 years ago

This would also be helpful in our environment.

Just as an example, in our internal helpdesk system when a ticket is solved it will go into a 'Solved / Resolved' status, then if no feedback is provided by the tech or user it is automatically closed after 2 days. This allows the users a testing time while not clogging up the tech's ticket lists with active tickets. (The 2 days is adjustable, just what works for us).

Actions #11

Updated by Philippe Lafoucrière almost 11 years ago

+1
Our clients don't always close resolved issues :(

Actions #12

Updated by Daniel Felix almost 11 years ago

Yes, we encounter sometimes the same issues. Some issues have a long wait time until they were really closed.

Actions #13

Updated by Jonas Nielsen almost 11 years ago

+1

Actions #14

Updated by Willian Dolence Ribeiro over 10 years ago

+1 here!

Actions #15

Updated by Adnan Topçu over 10 years ago

+1
Nobody does not close the resolved issue.

Actions #16

Updated by Alfredo Mezquita over 10 years ago

Pavel Loginov wrote:

Exactly. In our workflow every resolved issue needs to be closed by project leader or issue author. However, people are no robots and sometimes miss/forget to review a resolved issue which then simply goes down the issue queue. Would be highly useful if such issues could be auto-closed after "expiration".
So I think it's pretty simple and straight forward: if an issue's status was "A" for X days, then it's status is changed to "B". That's it.
Is it possible to just update the old plugin https://github.com/edtsech/redmine_x_closed/tree so that it installs on the newest versions of Redmine?

+1!

Totally agree with you. This feature would be very useful for our company as well. When a issue has been resolved, we notified it to the client and if everything is ok or if we don't receive any answer in 3 days, we close the issue manually. A feature like this could automate this process and it would be very useful for us.

Is there any chance to include this feature into the roadmap for the next product iterations?

Actions #17

Updated by Toshi MARUYAMA over 10 years ago

Actions #18

Updated by Artyom Tuprikov over 10 years ago

+1
Highly requested!

Actions #19

Updated by Josep Mª Mas over 10 years ago

+1
Would be great!

Actions #20

Updated by Luis Blasco over 10 years ago

+1
Thanks in advance!

Actions #21

Updated by Cristiano Cesario about 10 years ago

+1
Thanks!

Actions #22

Updated by Dmitry Lukashin about 10 years ago

+1 vote

Actions #23

Updated by Stephan Smola almost 10 years ago

+1
This is essential if you want to have a retest for a resolved issue.

Actions #24

Updated by Jogi 1j almost 10 years ago

I tried to create a plugin for this problem, but it's my first plugin, so I'm not sure if you find an error, please contact me, thank you. It's not the final version.

http://www.redmine.org/plugins/redmine_closes_resolved_issues

Actions #25

Updated by David BOUCHE over 9 years ago

+1
Highly requested!

Jogi : your plugin is not compatible with 3.0 redmine installation.

Actions #26

Updated by Ivan Prokudin over 9 years ago

I've tried Jogi's plugin and and it's suit me (I use redmine 2.6). The only thing that I need is notifications about closing the issues. So I'm offering USD 20.00000000 via FreedomSponsors to the first person who fix it.

Offer link: https://freedomsponsors.org/issue/732/close-notifications

You can also join me and throw in a few bucks there and we'll get it fixed faster :)

If you fix this issue (see my acceptance criteria there) please use that site to request your payment.

Actions #27

Updated by Pongtawat C about 9 years ago

Ivan Prokudin: Maybe this is something you want?

https://github.com/jkraemer/redmine_issue_reminder

Actions #28

Updated by Etienne Massip about 9 years ago

  • Target version set to Candidate for next major release
Actions #29

Updated by Loïc Barreau over 8 years ago

+1 : will be very usefull for us to.

Actions #30

Updated by Anonymous over 8 years ago

+1

Actions #31

Updated by Mathieu Simard over 7 years ago

+1

Actions #32

Updated by Jeremy Johnson about 6 years ago

+1

Actions #33

Updated by Bernhard Rohloff about 6 years ago

Isn't that a better job for a custom script and a cron job?
Not every Redmine installation has to have a particular resolved state.
It's also a more versatile approach as you can have multiple automated status transfers and also for different workflows.

Actions #34

Updated by Pierre PP over 5 years ago

+1
redmine 3.4 here

Actions

Also available in: Atom PDF