| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T6004 When moving a wiki page with subpages prompt to also move subpages | ||
| Resolved | epriestley | T5166 Expand the BulkJob tool | ||
| Resolved | epriestley | T8637 Maniphest batch editor can affect far too many tasks |
Event Timeline
From T2685, a more complete spec from epriestley:
UI: Web
I think we should try to do this from the web, since 99% of the time it will work fine (moving <100 pages is definitely not a problem). We currently have bulk edits in Maniphest and no one has complained about them timing out yet, so I think we'll be able to cover most cases without building a CLI tool. I think the simplest interface is just a checkbox on the existing "move" dialog, that says:
- Also move all child documents
...or similar. If the user checks this box (and the move affects more than a handful of pages, maybe), we could then confirm:
Bulk Move
This will move 925 documents, which may take some time.
( Cancel ) ( Begin Bulk Move )Also relevant, T5166 discusses a UI + infrastructure approach to letting long-running workflows (e.g., batch edit 1K tasks, move 1K documents) run through the web UI.
Having started to close down and archive our first projects in Phabricator, we find this would be a very, very useful feature.
In our use-case, we have a /projects folder in Phriction, and then let each project have it's own page under that. The folder under these project pages can quickly accumulate all sort of useful project information: status reports, decision logs, post-mortem report, etc.
When the project closes down and is archived, we would like to move the project documents from the /projects folder to somewhere else (e.g. an /archived folder) so that it does not clutter up the project wiki structure for ever. Which is a problem once the project page accumulates more than a dozen subpages or so: having to move each page individually does not feel like a good use of time.
T7638 might be another approach -- roughly, a checkbox like:
- Archived: Hide this document and all children from navigation trees.
Then you wouldn't have to move things or break links, and could just kick older stuff out of the structure.
Hmm. Yes, for this particular use-case, T7638 would probably be a preferable solution, as there does tend to accumulate a fair amount of links over time in those wiki docs. I seem to think that there were redirects to handle moved wiki pages, but if that is not the case, then that could be a problem.
See also PHI1275. Now that Phriction supports relative references in [[ ... ]] syntax, moves should be able to modify those references.