Whilst I most agree with the reasons against being able to delete objects for the sake of auditability, I think that there are certain conditions in which it is preferable to forcefully delete a project.
Description
Description
Revisions and Commits
Revisions and Commits
| Restricted Differential Revision | Restricted Diffusion Commit |
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | joshuaspence | T5235 Implement `PhabricatorDestructableInterface` on `PhabricatorProject` | ||
| Duplicate | joshuaspence | T5236 Allow projects to be deleted by `./bin/remove` if the project hasn't yet been used |
Event Timeline
Comment Actions
bin/remove should always be able to destroy objects, we just haven't implemented PhabricatorDestroyableInterface or whatever for Projects yet.
Comment Actions
Offhand, I think these are the related objects to destroy when destroying a project:
- The PhabricatorProjectColumns on its workboard.
- These should also implement PhabricatorDestructableInterface, since they have edges and transactions.
- The ProjectSlug rows.
- The wiki pages will become inaccessible, but I think we shouldn't delete them -- I plan to break Phriction and Projects apart more. Soon these will be more similar to a Maniphest task that happens to have a "Members of X" visibility policy, which we should not delete.
- At some point, we should handle classes of PhabricatorCustomFieldInterface (see TODOs in PhabricatorDestructionEngine->destroyObject()).
I think that's about it. Membership and subscription relationships are stored in edges, and transactions are normal, and those both get cleaned up for free already.