Feature #1380

Deleting an issue only marks it as being deleted

Added by Nick Read over 10 years ago. Updated 5 months ago.

Status:NewStart date:2008-06-05
Priority:HighDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:-
Resolution:

Description

It would be fantastic if deleting issues only marked them as being deleted, and providing a "recently deleted" link under "change log" link n the right-hand side. Going to this list would give you the option to completely purge items, which would actually deleting the issue from the database.

I've learnt the hard way - just deleted two issues when I was trying to "move" them using the context menu. I though I clicked "move", quickly clicked OK on the confirmation dialog without reading it (thinking 'yes, I want to move these items'), and watched the issues disappear. Restoring our database backup from yesterday now..... :(


Related issues

Related to Redmine - Feature #6666: Soft delete of issues New 2010-10-14
Related to Redmine - Feature #7900: Restore issue New 2011-03-17
Related to Redmine - Feature #18027: Notification when deleting an issue New

History

#1 Updated by Thomas Lecavelier over 10 years ago

I like this idea, which is very close to enterprise requirements. Maybe we could add it an option in the admin panel to bypass this new feature in order to keep the old way to do...

#2 Updated by Mark Gallop over 10 years ago

My workaround was to disable deletion of issues by normal users and give them a "Trash" tracker to move issues to. I then use a rake task to delete "trashed" issues if they were moved more than 2 weeks ago.

A little clunky but at least it can be accomplished without altering Redmine.

Mark

#3 Updated by Andrew Ness over 9 years ago

I would really like this to be implemented. I just came back from vacation and a couple of issues were unexpectedly deleted. I assumed they would just be flagged as deleted, but their rows in the issues table have actually been removed. I'll try to merge them back in from database archives, but it seems that implementing this feature would make things a lot easier.

#4 Updated by Aaron Soules over 9 years ago

There is an excellent rails plugin called acts_as_paranoid that could potentially be used. I sets a deleted_at field on the table, and modifies ActiveRecord so that it does not find things deleted in the past.

[[http://github.com/technoweenie/acts_as_paranoid/tree/master]]

#5 Updated by Dipan Mehta over 5 years ago

+1. Very necessary to have this feature.

#6 Updated by Stéphane Champeau over 5 years ago

+1 today I had this problem with one user. The idea of ​​"trash" looks good.

#8 Updated by Toshi MARUYAMA almost 5 years ago

#9 Updated by Toshi MARUYAMA almost 5 years ago

#10 Updated by Lubos Racansky over 4 years ago

+1

#12 Updated by claude g over 4 years ago

+1 Also, in case of deletion (this could be a dedicated feature) : we should have a notification with the all (and final) history of the tracker. Why not like a pdf export if easier but a full history.

#13 Updated by Steven M over 4 years ago

Looks like maintainer does not care about his users. When is this feature going to be implemented?

#14 Updated by Toshi MARUYAMA about 4 years ago

  • Related to Feature #18027: Notification when deleting an issue added

#15 Updated by Sam XIAO over 3 years ago

+1
Dipan Mehta wrote:

+1. Very necessary to have this feature.

admin made a mistake delete a issue. and then want to bring it back.

and no email notification configured, so i have no any history information about the deleted issue.

#16 Updated by Sam XIAO over 3 years ago

i want to add delete trigger on the table issue, can i?

#17 Updated by Kevin Palm over 3 years ago

+1

#18 Updated by Daniel de Wildt over 3 years ago

+1

#19 Updated by Rudolf Osman over 3 years ago

+1

#20 Updated by Đức Long Nguyễn over 3 years ago

Good idea! I like it

Nick Read wrote:

It would be fantastic if deleting issues only marked them as being deleted, and providing a "recently deleted" link under "change log" link n the right-hand side. Going to this list would give you the option to completely purge items, which would actually deleting the issue from the database.

I've learnt the hard way - just deleted two issues when I was trying to "move" them using the context menu. I though I clicked "move", quickly clicked OK on the confirmation dialog without reading it (thinking 'yes, I want to move these items'), and watched the issues disappear. Restoring our database backup from yesterday now..... :(

#21 Updated by Ami Desai over 3 years ago

+1

#22 Updated by Paco Alcaide over 3 years ago

+1

I would like too.

#23 Updated by Matthew Palencia over 3 years ago

+1

#24 Updated by Guy Baconniere almost 3 years ago

+1

It would be nice to have a manual procedure to restore a single "issue" (ticket)

I did the following procedure to restore my deleted ticket ID 8461 :

# Restore redmine_default database to redmine_20151126090000
perl -p -i -e 's/redmine_default/redmine_20151126090000/' redmine_default.sql
rename 's/redmine_default/redmine_20151126090000/' redmine_default.sql
mysqladmin create redmine_20151126090000
mysql redmine_20151126090000 < redmine_20151126090000.sql

# Check lines which your ticket id (to find all tables involved)
mysqldump --opt --skip-extended-insert --complete-insert redmine_20151126090000 > t.sql
grep '8461' t.sql | cut -c-250

# Copy lines from the backup database to the current database
mysql redmine_default

insert into redmine_default.issues select * from redmine_20151126090000.issues where id = 8461;
insert into redmine_default.journals select * from redmine_20151126090000.journals where journalized_id = 8461;
insert into redmine_default.journal_details select * from redmine_20151126090000.journal_details where journal_id = 8461;
insert into redmine_default.custom_values select * from redmine_20151126090000.custom_values where customized_id = 8461;
insert into redmine_default.attachments select * from redmine_20151126090000.attachments where container_id = 8461;
insert into redmine_default.time_entries select * from redmine_20151126090000.time_entries where issue_id = 8461;
insert into redmine_default.issue_relations select * from redmine_20151126090000.issue_relations where issue_from_id = 8461;

quit

#25 Updated by juntao liu almost 3 years ago

+1

#26 Updated by Anh Le Giang over 2 years ago

+1 this is a "must have" feature nowaday

#27 Updated by Fred B over 2 years ago

This feature is mandatory. +1000!

Any development? Plugin that can do something similar? Main goal is to have a way to rollback. Or at least to prevent deleting by replacing the Delete button for a Archive function.

#28 Updated by Yevgen Vor about 2 years ago

+1 . Guys, please, I don't want to come back to Jira hell.

#29 Updated by Laurent Barbareau about 2 years ago

+1
Unbelievable that there's at least no confirmation message !

Managing a deletion flag instead of a pure deletion is certainly tricky to implement now but backing up the records prior to delete them, into dedicated tables or even a kind of log file, should be quite easy to implement, no ?!

#30 Updated by Alexander Dyachkov about 2 years ago

+1
I was really amazed when didn't find this feature in new & stable version of Redmine (after occasionaly deleting an issue, of course). According to this issue's info, it's 8 years old - please devs, do something about it.

#31 Updated by Steve Hanselman almost 2 years ago

I think this is an essential feature, however, after 8 years it's not looking likely!

The ideal would be to mark as deleted then have a job that hard deletes after a set period of time (configured from settings).

#32 Updated by Inese Ez almost 2 years ago

+1

#33 Updated by Fred B almost 2 years ago

Essential feature!

Anyone working on this?

#34 Updated by Randa Bustami over 1 year ago

Fred B wrote:

Essential feature!

Anyone working on this?

its very important to know who delete and when, if you can generate report from redmine log file would be great

#35 Updated by Randa Bustami about 1 year ago

please please
its very important to know who delete and when, if you can generate report from redmine log file would be great

#36 Updated by Jaime Iranzo about 1 year ago

+1

Please, essential feature!

#37 Updated by Karl Wilbur 11 months ago

+1

Not being able to track deletion of, and potentially restore, deleted issues is significant shortcoming.

This is a seemingly simple thing to implement. Why has it not been implemented in 9 years?

#38 Updated by Aleksandar Pavic visit redminecookbook.com 10 months ago

There are some plugins helping with this but +1...

However there might be trouble giving proper statistics with tickets...

Statistics would have to include "if not some_field=deleted" ...

#39 Updated by Anton Sergeev 5 months ago

Thanks to Guy Baconniere for him #1380#note-24. I restore deleted Issue (issue_id=3381) in PostgreSQL using this:

createdb restore_redmine_db
zcat my_redmine_DB_dump.sql.gz | psql restore_redmine_db

tables='
  issues;id
  journals;journalized_id
  journal_details;journal_id
  custom_values;customized_id
  attachments;container_id
  time_entries;issue_id
  issue_relations;issue_from_id
'
issue_id=3381
for i in $tables; do
  _t=${i%;*}; _id=${i#*;}; echo "t=$_t; _id=$_id";
  psql --command="COPY (SELECT * FROM ${_t} where ${_id} = ${issue_id}) TO STDOUT;" restore_redmine_db | psql --command="COPY ${_t} FROM STDIN;" original_redmine_db
done

dropdb restore_redmine_db

In addition, you need to restore attachment files. Their locations can be found with this:
RAILS_ENV=production bin/rails r "Attachment.where(container_id: ${issue_id}).sort.each do |_a| puts _a.diskfile; end" 

Also available in: Atom PDF