Feature #36691
closed
Background job and dedicated status for project deletion
Added by Jens Krämer almost 3 years ago.
Updated about 1 year ago.
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
- Target version set to Candidate for next major release
- Related to Patch #31076: Issues CSV / PDF export via ActiveJob added
Jens, should we take into consideration also #34987?
maybe my group members issue #36696 can benefit from this as well
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.
Thanks Jens for your quick response.
- Target version changed from Candidate for next major release to 5.1.0
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.
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?
- Related to Feature #33422: Re-implement admin project list using ProjectQuery system added
- Assignee set to Jens Krämer
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).
- 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.
- Status changed from Resolved to Closed
- Related to Patch #37210: Make "Project" label translatable in app/views/projects/bulk_destroy.html.erb added
- Tracker changed from Patch to Feature
- Resolution set to Fixed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by