Run multiple times the destroy workflow under every imaginable case,
to violently destroy a projects tree, leaf by leaf. We suggest to run it
with the trace option. Example:
./bin/remove destroy --trace PHID-PROJ-s0met1ng
To run the above workflow multiple times, you may appreciate a dump:
./bin/storage dump | gzip > dump.sql.gz
So you can easily restore it whenever you want:
zcat dump.sql.gz | ./bin/storage shell
- Delete simple milestone
- create a new simple project "A" with milestone "M" and delete "M"
- deletion still works on milestone "M"
- Delete simple project
- create a new simple project "A" with a workboard and destroy "A":
- deletion still works on project "A"
- workboard is still not accessible
- if there were tasks, they are still there but without tag "A"
- Delete project with milestone (T15913)
- create a new project "A" with a milestone "B" and delete "A"
- deletion still works on project "A"
- milestone "B" is finally nuked from the database
and you do not see it anymore in the phabricator_project table
- Delete a project with sub-projects (T15918)
- create a new project "A" with a sub-project called "B" and delete "A"
- deletion still works on project "A"
- project "B" becomes a root-project and it has depth "0" again
and it's usable, instead of having it borked with "You Shall Not Pass"
- Delete a sub-project (T15697)
- create a new project "A" with a sub-project called "B" and delete "B"
- deletion still works on project "B"
- project "A" is usable again like "B" never existed, so you can
change memberships and all the things, instead of having it borked
If you don't have enough time to test this, just enjoy the new unit tests covering the destroy process (T16043):
arc unit src/applications/project/storage/PhabricatorProject.php
In particular, in the unit test results, check the new green light about this method:
PhabricatorProjectCoreTestCase::testProjectDestroy