Redmine

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

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

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.

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]]

+1. Very necessary to have this feature.

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

+1
#6666
#7900

+1

+1

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

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

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

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

+1

+1

+1

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..... :(

+1

+1

I would like too.

+1

+1

+1 this is a "must have" feature nowaday

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.

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

+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 ?!

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

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

+1

Essential feature!

Anyone working on this?

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

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

+1

Please, essential feature!

+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?

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

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

RAILS_ENV=production bin/rails r "Attachment.where(container_id: ${issue_id}).sort.each do |_a| puts _a.diskfile; end" 

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

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.

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

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.