Project

General

Profile

Actions

Feature #36691

closed

Background job and dedicated status for project deletion

Added by Jens Krämer about 2 years ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Category:
Administration
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

Due to the deletion of dependent objects (issues etc) and child projects,
project deletion may take a long time.

This patch, which was extracted from [Planio](https://plan.io/redmine-hosting),
moves the actual project deletion into an ActiveJob job. It also introduces a
new project status (SCHEDULED_FOR_DELETION) that is used to effectively hide
the project that is about to be deleted (and any potential descendant projects)
from the system immediately.

A security notification is sent out to the user who deleted the project,
informing about success / failure.

The projects list is extended to be able to filter for the new status,
so in case of a failure, the project can still be accessed for
examination.


Files


Related issues

Related to Redmine - Patch #31076: Issues CSV / PDF export via ActiveJobNew

Actions
Related to Redmine - Feature #33422: Re-implement admin project list using ProjectQuery systemClosedMarius BĂLTEANU

Actions
Related to Redmine - Patch #37210: Make "Project" label translatable in app/views/projects/bulk_destroy.html.erbClosedGo MAEDA

Actions
Actions #1

Updated by Marius BĂLTEANU about 2 years ago

  • Target version set to Candidate for next major release

Nice feature!

Actions #2

Updated by Marius BĂLTEANU about 2 years ago

  • Related to Patch #31076: Issues CSV / PDF export via ActiveJob added
Actions #3

Updated by Marius BĂLTEANU about 2 years ago

Jens, should we take into consideration also #34987?

Actions #4

Updated by James H about 2 years ago

maybe my group members issue #36696 can benefit from this as well

Actions #5

Updated by Jens Krämer about 2 years ago

Marius BALTEANU wrote:

Jens, should we take into consideration also #34987?

Ah, that's interesting. If I understand correctly, that would mean the project record (plus potential child projects' records) would be deleted synchronously, but removal of all dependent objects would be pushed to the job queue.

I see few problems with that:

1. Data integrity. Before the job is finished, we have an inconsistent database (i.e. issues referencing a nonexisting project). I am not sure we handle such a situation gracefully (i.e. resulting in an HTTP 404 vs a 500) in all cases.
2. Two transactions instead of one. Currently, if the project deletion fails due to a problem somewhere along the way (due to a failing callback for example), the transaction is rolled back and everything is as if nothing happened. Splitting the process in two separate transactions (one for the project, one later for the dependent objects), means the project record will be gone even if some dependent object insists on not being destroyed. I do not think core has any such callbacks, but plugins might.
3. Does not work at all when there are foreign keys referencing `projects.id`. We do not have such in core, but again, there may be plugins that do.

Actions #6

Updated by Marius BĂLTEANU about 2 years ago

Thanks Jens for your quick response.

Actions #7

Updated by Marius BĂLTEANU about 2 years ago

  • Target version changed from Candidate for next major release to 5.1.0
Actions #8

Updated by Jens Krämer about 2 years ago

Marius, I just have re-submitted this patch as part of a larger work on the admin projects list in #33422. It would be great if you could have a look and consider integrating that one instead.

Actions #9

Updated by Marius BĂLTEANU about 2 years ago

There is a random failing test, you can reproduce by running the tests using the following command: TESTOPTS="--seed=42328" rake test

Failure:
DestroyProjectJobTest#test_should_destroy_project_and_send_email [/work/test/unit/jobs/destroy_project_job_test.rb:60]:
No enqueued job found with {:job=>ActionMailer::MailDeliveryJob, :args=>#<Proc:0x0000aaaafe3aec98 /work/test/unit/jobs/destroy_project_job_test.rb:62 (lambda)>}

Jens, can you take a look, please?

Actions #10

Updated by Marius BĂLTEANU about 2 years ago

  • Related to Feature #33422: Re-implement admin project list using ProjectQuery system added
Actions #11

Updated by Marius BĂLTEANU about 2 years ago

  • Assignee set to Jens Krämer
Actions #12

Updated by Jens Krämer about 2 years ago

this is really strange, looks like under some circumstances emails are processed inline and not result in a queued mailer job. I did not find the cause of this, but the attached patch would handle both cases in the tests (the same issue exists in the test case for the job that handles deletion of multiple projects).

Actions #13

Updated by Marius BĂLTEANU almost 2 years ago

  • Status changed from New to Resolved
  • Assignee changed from Jens Krämer to Marius BĂLTEANU

Both patches from #33422 and the fix for tests committed, thank you for your contribution, really useful feature.

Actions #14

Updated by Marius BĂLTEANU almost 2 years ago

  • Status changed from Resolved to Closed
Actions #15

Updated by Go MAEDA almost 2 years ago

  • Related to Patch #37210: Make "Project" label translatable in app/views/projects/bulk_destroy.html.erb added
Actions #16

Updated by Go MAEDA 6 months ago

  • Tracker changed from Patch to Feature
  • Resolution set to Fixed
Actions

Also available in: Atom PDF