Page MenuHomePhorge

Projects: improve quality of destroy workflow
Needs ReviewPublic

Authored by valerio.bozzolan on Aug 12 2024, 21:21.

Details

Summary

When you permanently destroy a specific project from the command line, the following
additional good things now happen:

  • the direct orhpan milestones are removed too (instead of leaving them orphan, broken, invisible forever)
  • all children projects emerge like cute bubbles by one level (instead of having them orphan, broken, invisible forever)
  • the parent project is eventually restored as "without sub-projects" (instead of having a broken root-project with bugged memberships)

This change has nothing to do with archived projects.

This change will only affect future usages of the destroy workflow, that is:

./bin/remove destroy PHID-OF-YOUR-PROJECT-TO-BE-DESTROYED

Example initial situation:

Project A
 [projectDepth: 0]
 [hasSubprojects: 1]
 [members: *automatic*, foo, bar]
 > Project B
  [projectDepth: 1]
  [hasSubprojects: 1]
  [members: *automatic*, foo, bar]
  > Project C
   [hasSubprojects: 0]
   [projectDepth: 2]
   [members: foo, bar]
   > Milestone C.1
    [projectDepth: 3]

Situation after destroying only project A:

Project B
 [projectDepth: 0]
 [hasSubprojects: 1]
 [members: *automatic*, foo, bar]
 > Project C
  [projectDepth: 1]
  [hasSubprojects: 0]
  [members: foo, bar]
  > Milestone C.1
   [projectDepth: 2]

Situation after destroying only project B:

Project A
 [projectDepth: 0]
 [hasSubprojects: 1]
 [members: *automatic*, foo, bar]
 > Project C
  [projectDepth: 1]
  [hasSubprojects: 0]
  [members: foo, bar]
  > Milestone C.1
   [projectDepth: 2]

Situation after destroying only project C:

Project A
 [projectDepth: 0]
 [hasSubprojects: 1]
 [members: *automatic*, foo, bar]
 > Project B
  [projectDepth: 1]
  [hasSubprojects: 0]
  [members: foo, bar]

Situation after destroying only milestone C.1:

Project A
 [projectDepth: 0]
 [hasSubprojects: 1]
 [members: *automatic*, foo, bar]
 > Project B
  [projectDepth: 1]
  [hasSubprojects: 1]
  [members: *automatic*, foo, bar]
  > Project C
   [hasSubprojects: 0]
   [projectDepth: 2]
   [members: foo, bar]
Test Plan

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

Closes T15697
Closes T15913
Closes T15918

Diff Detail

Repository
rP Phorge
Branch
arcpatch-D25772_3
Lint
Lint Passed
Unit
Tests Passed
Build Status
Buildable 1723
Build 1723: arc lint + arc unit

Event Timeline

valerio.bozzolan held this revision as a draft.
valerio.bozzolan retitled this revision from Project: improve permanent destroy of sub-projects to Projects: improve quality of destroy workflow.
valerio.bozzolan edited the summary of this revision. (Show Details)
valerio.bozzolan edited the test plan for this revision. (Show Details)

update description

valerio.bozzolan edited the summary of this revision. (Show Details)
valerio.bozzolan edited the test plan for this revision. (Show Details)

After only 30 hours of work. Wow. asd

add a bit of documentation - just because we can

Any other test plan suggested? Current ones: delete simple milestone, delete project with milestone, delete a project with sub-projects, delete a sub-project, ecc.

mainframe98 subscribed.

I find the current iteration too difficult to read, although that may be partially caused by the mutual language barrier.

src/docs/user/userguide/projects.diviner
341
344–347
349–357
368–370
372–373
375–377
379–380
382
386
387–389

I don't understand what this sentence wants to say. It implies not following Permanently Destroying Data? But why?

391
396
398
400
410–411
413–416
417–420
a real mess for family photos``` - Love this bit.
421–423
425
This revision now requires changes to proceed.Sun, Feb 2, 13:23

implement tips, simplify (thanks)

valerio.bozzolan added inline comments.
src/docs/user/userguide/projects.diviner
372–373

(I've just written "all these consequences" now. seems good?)

375–377

(I've simplified a bit with at least a useful examples like "show only to me")

387–389

The risks are explained after "What happens when you permanently destroy" 👍 (is this the answer?)

391

Here I would just like to clarify that a milestone is really a project. I put "or a milestone" as solution

valerio.bozzolan marked 4 inline comments as done.

add missing comma

last cosmetic change on a title with extra "==="

clarify that an archived tag is not removed from their tasks