Support deleting a tree of pages

RESOLVED WONTFIX

Status

Mozilla Developer Network
Wiki pages
P1
major
RESOLVED WONTFIX
4 years ago
2 years ago

People

(Reporter: sheppy, Unassigned)

Tracking

(Blocks: 1 bug)

Details

(Whiteboard: [specification][type:bug][LOE:3])

(Reporter)

Description

4 years ago
What did you do?
================
1. Delete a page that has subpages
2. Visit one of the subpages whose URL I already know.

What happened?
==============
The subpage is there despite the parent being deleted.

What should have happened?
==========================
If the page being deleted has children, we need to ask for permission to delete the children as well, and either delete the page and all its children or do nothing.

Is there anything else we should know?
======================================
(Reporter)

Updated

4 years ago
Blocks: 972547
(Reporter)

Updated

4 years ago
Summary: Deleting a page that has subpages succeeds but leaves children intact → Support deleting a tree of pages

Updated

4 years ago
Severity: normal → major
Component: General → Wiki pages

Updated

4 years ago
Priority: -- → P1

Updated

4 years ago
Whiteboard: [specification][type:bug] → [specification][type:bug][LOE:?]
needinfo :groovecoder for an estimate
Flags: needinfo?(lcrouch)
I have move / redirected / deleted thousands of pages since the beginning of the year. But except for a couple 2-3 page hierarchies, I wouldn't have needed this feature.

And with the reorg mostly done, I think it will be rarer in the future.

I don't think we need this feature, except if it comes for free (< 1-2 days of work)
(Reporter)

Comment 3

3 years ago
Well. I do think we need this feature, but I suppose we can do without it for a while, if someone is willing to do the manual labor of deleting those last few subtrees by hand... volunteers? :)
Do you have a list of the subtrees we need to delete?
I'm looking at the _move_tree[1] method for an idea of the kind of work we would need to do here. To delete, we DO NOT need to:

1. Check for slug conflicts
2. Copy review tags
3. Copy revision with new slug & title
4. Create REDIRECT doc & revision
5. Update breadcrumbs

So, all we really need to do is:

1. Update deleted=True on the doc
2. Recurse through self.children.all() and call delete() on them

Having said that, our recursive features are always risky. E.g., we could see many more instances of bug 1034802. (marking as blocker)

needinfo? :teoli or sheppy: Should this also include the ability to *purge* trees of pages? That seems extremely risky and would add considerable time to implement and test properly.

That answer will determine if this is LOE:3 or LOE:10

needinfo? :ubernostrum: Can you give me a sanity check on the above estimate?

[1] https://github.com/mozilla/kuma/blob/master/apps/wiki/models.py#L1012-1105
Depends on: 1034802
Flags: needinfo?(lcrouch)
Flags: needinfo?(jypenator)
Flags: needinfo?(jbennett)
Flags: needinfo?(eshepherd)
It's true that deleting does not require conflict checks, but deleting multiple pages in one go is scary and *should* be heavily restricted, with a big bold red warning about it.

TBH I'd be inclined to treat this as an "ask an MDN dev to do it manually" type of feature just to try to restrict the number of cases/times where it'd be used. But code-wise, it doesn't look terribly difficult to implement.
Flags: needinfo?(jbennett)
Unless :teoli or :sheppy correct me, I'm taking "purge" out of scope for this bug and set the LOE:3.
Flags: needinfo?(jypenator)
Flags: needinfo?(eshepherd)
Whiteboard: [specification][type:bug][LOE:?] → [specification][type:bug][LOE:3]
No, we don't want a recursive purge. Far too risky.

We can always undelete a page, if things goes wrong.
Whiteboard: [specification][type:bug][LOE:3] → [specification][type:bug][LOE:?]
(oops changed involuntary the whiteboard)
Whiteboard: [specification][type:bug][LOE:?] → [specification][type:bug][LOE:3]
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.