Issues with new "archived" state

[sweddell]

Giving the new 3.2 beta a test drive and have found issues with how the "archived" state is treated. A common usecase for us is the need to restore an entire section when a user archives a page, either knowingly or unsuspectingly, and there were subpages in the tree that needed to be moved before archiving, or the whole lot needed to remain in the case of an unscheduled archive.
Archiving a page with children,

Results in the children pages being archived, as expected.

There needs to be a "restore" action in the Multi-selection dropdown, especially if a very large section was archived and needs to be returned to its former glory.

Restoring the subpages individually only gives an option to restore to the top level, which is expected if the parent is archived, but not if the page is moved to an active page first.

However, if the parent page that was archived is restored, then the expected "restore draft" option is available, as a child of the same restored parent or another parent in the tree if it is moved.

On restoring, or the tree refreshing, the page returns to the previous parent. It is probably a good idea to restrict the ability to move the page unless restored first. I understand what is going on here and the message about the move not taking effect until the page is saved relates to the reason the page moves back, but a CMS user won't understand that and will think that it should stay in the place they moved it to the same as if the moved a published or draft page.

[chillu]

/cc @clarkepaul @jonom @stevie-mayhew @flashbackzoo

[jonom]

Agree a Restore bulk action would be nice, and the action should start at the top of the tree and work down so pages get restored to the right place. But "prevention is the best medicine" and I think the more important change here is warning users when children will be archived as a result of archiving a page.

window.alert() sucks pretty bad and modifying the message that comes up when people click Archive might not be very effective. The CMS could really benefit from some rich alert messages so we can properly grab attention and communicate clearly with formatted text and imagery. Here's an example: http://t4t5.github.io/sweetalert/ not saying we should use that exact script but something like it. We could say something like Are you sure you want to archive this page? 5 child pages will also be archived and then list the affected pages, up to a limit, with an archive all button. We could also add a subtle note here that archived pages can be restored later if needed.

Or changing the action text could be an option I guess, instead of just 'Archive' it could be 'Archive (incl. 5 child pages)'.

p.s. the 5th example at http://t4t5.github.io/sweetalert/ that starts with ... and by passing a parameter is a really nice example of a dialogue with multiple options and feedback after selection.

[dhensby]

Presumably all child pages are archived recursively? So giving an explicit number is not required in my view. Changing the action to "archive page and sub pages" would do it

[jonom]

Yeah that's what happens - I just think an explicit number would highlight the magnitude of the change. If you archive a page but haven't manually expanded all the sub page nodes in the site tree you might have no idea how many pages are being archived - could be 1 or 50.

[dhensby]

But the impact is the same if the user does or doesn't realise what is happening, surely?

Counting the nested children will also be expensive.

[jonom]

Yeah the impact is the same, but might just make people think twice before archiving. Like "Oh whoa, there's 50 pages under there... better ask the boss first". But yeah I didn't consider performance, might be a deal breaker.

[clarkepaul]

We were aware of these issues stated by @sweddell when going about our creation of the archive functionality and ideally if we had the time we would have included it in our work. But because our work was directed by user testing we did, we had a different aim and a set amount of time to do the work so we didn't try and fix all of the existing issues.

Adjusting the message which notifies the user about the child pages should be an easy addition that could be added sooner than the other things (nice suggestion).

We discussed giving the user options to restore to the old location and/or select a new location (if it wasn't available).

The bug of being able to move archived pages or newly restored page and it not saving is a pre-existing bug (might be logged somewhere else?).

[tractorcow]

I've added batch restore at #1255

[tractorcow]

Archive alert messages have been "fixed" with silverstripe/silverstripe-framework#4470 and #1254

[tractorcow]

All of the above issues except the "moving of archived pages" has been resolved.

[sminnee]

It would be good to reopen a new issue with just that boy, @tractorcow, and then close this one. It will make it easier for someone to jump in and fix down the line. :-)

[tractorcow]

Moved this issue to #1257