View Issue Details

IDProjectCategoryView StatusLast Update
0024130mantisbtsub-projectspublic2018-03-22 06:07
ReporterxtremevisionAssigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
Product Version2.10.0 
Target VersionFixed in Version 
Summary0024130: Deleting a project does not delete sub-projects
Description

Deleting a project does not delete sub-projects, resulting in orphaned sub-projects.

Steps To Reproduce
  1. Create project
  2. Edit project
  3. Add 2 sub-projects
  4. Delete parent project
TagsNo tags attached.

Activities

atrol

atrol

2018-03-17 05:20

developer   ~0059232

Automatic deletion of sub-projects does not always make sense.
It should be an option that can be activated or deactivated.

vboctor

vboctor

2018-03-21 02:57

manager   ~0059251

+1 for at least not always making sense. Often a single project is a sub-project of multiple projects. I would rather be conservative with project deletion since it can cause data loss that is irreversible.

xtremevision

xtremevision

2018-03-22 04:38

reporter   ~0059273

It actually does make sense depending on what you are trying to achieve. For example, I had an installation of mantis used both for my clients and our internal projects, so I decided to split the two into two separate instances. So I duplicated the site on another server, and began to purge users, tickets, and projects, that were no longer relevant to that particular instance. Deleting single projects is fine, as it also delete all associated tickets. But deleting parent project containing sub-projects left the sub-projects intact, orphaned, and at parent level. I suddenly had a problem finding and [safely] deleting the sub-projects. It too much longer than anticipated, with a more headaches.

When deleting a project I get asked if I am sure, so the message should contain also a warning that sub-project will also be deleted with all their associated tickets. I don't see a problem with this if the user has to give their permission before executing the operation.

cproensa

cproensa

2018-03-22 05:41

developer   ~0059281

It actually does make sense depending on what you are trying to achieve

So it makes sense for a subset of the use cases. And not for the rest. The tool must address consistently all scenarios.

Let's say we have:
project A
has C as subproject
project B
has C as subproject

Project C is one project, which is "linked" to A and B as "child"
Deleting project B, and recursively C, may have the unintended effect of C disappearing from A as child. The user may or not know what is actually happening, but as atrol said, data loss after deletion is irreversible, so we'd rather have a conservative approach.

I think, a good improvement that fits your actual use case, is to improve the project management page to allow a multiple "smart" delete:

  • allow multiple selection of checkboxes for projects in the list
  • have an action for delete project that apply to the selected projects

Note that in manage projects page one project is listed multiple time following the parent-child hierarchy, so the selected checkbox contains the information of which project has been selected, as well as which child relation was selected.
This "smart" delete action could perform:

  • if the target project is linked as subproject, remove this link
  • if the project has no remaining parents, do the actual deletion of the project
xtremevision

xtremevision

2018-03-22 06:07

reporter   ~0059283

I thoroughly understood the point about the sub-project assigned to multiple parent project, and I agree with you it could be a problem if it is deleted from a parent project it should not be. Checkboxes could work, frankly anything to make the work easier is a welcome benefit. I have the same task ahead of me, of purging projects from the second mantis instance, but I have stopped for now, cause it's gonna take some time. Presently I have to delete all sub-projects manually one by one, and then finally the parent project. No fun when you have lots and lots. :)

Issue History

Date Modified Username Field Change
2018-03-17 04:24 xtremevision New Issue
2018-03-17 05:20 atrol Severity major => feature
2018-03-17 05:20 atrol Category administration => sub-projects
2018-03-17 05:20 atrol Note Added: 0059232
2018-03-17 05:21 atrol Priority high => normal
2018-03-21 02:57 vboctor Note Added: 0059251
2018-03-22 04:38 xtremevision Note Added: 0059273
2018-03-22 05:41 cproensa Note Added: 0059281
2018-03-22 06:07 xtremevision Note Added: 0059283