Feature #1380
open![Author: Anonymous](/images/anonymous.png?1679302129)
Deleting an issue only marks it as being deleted
Added by Anonymous about 16 years ago. Updated about 1 year ago.
0%
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
Updated by Thomas Lecavelier about 16 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...
Updated by Mark Gallop about 16 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
Updated by Andrew Ness about 15 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.
Updated by Aaron Soules about 15 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]]
Updated by Dipan Mehta over 11 years ago
+1. Very necessary to have this feature.
Updated by Stéphane Champeau about 11 years ago
+1 today I had this problem with one user. The idea of "trash" looks good.
Updated by Toshi MARUYAMA over 10 years ago
- Related to Feature #6666: Soft delete of issues added
Updated by Toshi MARUYAMA over 10 years ago
- Related to Feature #7900: Restore issue added
Updated by claude g about 10 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.
Updated by Steven M about 10 years ago
Looks like maintainer does not care about his users. When is this feature going to be implemented?
Updated by Toshi MARUYAMA almost 10 years ago
- Related to Feature #18027: Notification when deleting an issue added
Updated by Sam XIAO over 9 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.
Updated by Sam XIAO over 9 years ago
i want to add delete trigger on the table issue, can i?
Updated by Đức Long Nguyễn over 9 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..... :(
Updated by Anh Le Giang over 8 years ago
+1 this is a "must have" feature nowaday
Updated by Fred B about 8 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.
Updated by Yevgen Vor about 8 years ago
+1 . Guys, please, I don't want to come back to Jira hell.
Updated by Laurent Barbareau about 8 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 ?!
Updated by Alexander Dyachkov almost 8 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.
Updated by Steve Hanselman almost 8 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).
Updated by Randa Bustami over 7 years 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
Updated by Randa Bustami almost 7 years ago
please please
its very important to know who delete and when, if you can generate report from redmine log file would be great
Updated by Karl Wilbur almost 7 years 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?
Updated by Aleksandar Pavic over 6 years 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" ...
Updated by Anton Sergeev over 6 years 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"
Updated by Yuuki NARA over 5 years ago
+1
As a workaround, there is also a way to simply change the project_id of the issue.
(Project_id -> 0, -% Project_id%,% Project_trashcan%)
The following requirements can be satisfied.
1.Even if you specify the ticket number, it is not displayed on the screen
2.The ticket is not displayed on the Project issue list screen
3.Data on the issue can not be changed.
4.The administrator can easily return to the original state when necessary.
Updated by Peter Lustig almost 5 years ago
Rename buttons on-the-fly via reverse proxy Nginx (nginx-extras on Ubuntu 18.04). Of course you need proxy_pass
with include proxy_params
to do this.
# Umlaute are OK. # g = Replace all the match strings. # i = Perform a case-insensitive match. # o = Just replace the first one. # r = The pattern is treated as a regular expression, default is fixed string. subs_filter '(<a class="projects(?: selected)?" href="/projects">Projects)' '<a class="projects" href="/issues">Issues</a></li><li>$1' or; subs_filter '(<a class="projects(?: selected)?" href="/projects">Projekte)' '<a class="projects" href="/issues">Tickets</a></li><li>$1' or; subs_filter '(<a[^>]+href="/issues[^>"]+">)Löschen</a>' '$1Das gesamte Ticket löschen</a>' gr; subs_filter '(<a[^>]+href="/issues[^>"]+">)Delete</a>' '$1Delete entire ticket</a>' gr;
It has happened to us many times that people wanted to delete their comment quickly and deleted the whole ticket because the button is just Delete
. With this solution, the probability of this happening is minimized.
Updated by Miodrag Milic over 4 years ago
During the last 10 years people deleted accidentally countless tickets.
There is no easy way to recover them.
I found that setting up RSS client to record each and every ticket change is probably the easiest way (files are gone tho but this can be downloaded by some clients too).
Updated by Go MAEDA over 1 year ago
- Has duplicate Defect #25595: Important usability bug - Too easy to delete issues added
Updated by Martin von Wittich about 1 year ago
Anton Sergeev wrote in #note-38:
Thanks to Guy Baconniere for him #1380#note-24. I restore deleted Issue (
issue_id=3381
) in PostgreSQL using this:
[...]
In addition, you need to restore attachment files. Their locations can be found with this:
[...]
I'm pretty sure this does not correctly restore journal_details
. The code attempts to match journal_details.journal_id
with the ticket ID, but as far as I can tell, journal_details.journal_id
references journals.id
.