|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|
- Mentioned In
- T5166: Expand the BulkJob tool
T11475: Allow users to bulk-change visibility and editability policies for Phriction documents
T9167: Simplify destroying wiki pages
T7638: Archiving wiki pages in Phriction
- Mentioned Here
- T7638: Archiving wiki pages in Phriction
T5166: Expand the BulkJob tool
From T2685, a more complete spec from epriestley:
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 )
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.
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.