Implemented in 4.4

 

Official Documentation Available

This topic is now covered in Deleting pages.

Introduction

Describes how deletion and de-activation can be un-coupled, respectively backed with a workflow.

--> download

Limitations

Note that our current UI framework restricts us in how much we can change the menu structure, labels and layout of the context menu shown when clicking with the right mouse button. In particular, we can gray out items with some trickery, but we can't add, change or delete entries. This limits what we can do with the 4.x family of Magnolia.

Mockups

Website tree


Workflow

The only change for a work item is that we actually use an icon, which reflects both the type of the node being activated as well as whether it was marked as "deleted" or not.


Flow remarks

  • Clicking on "Mark page for deletion" marks the page and all its sub pages as "deleted".
  • If a page marked as "deleted" is activated:
    • a new work item is added to the workflow, if configured.
    • if no workflow is configured, the page that is activated including all of its sub pages are deleted during the activation.
  • To restore a page marked as "deleted", choose "Versions", then restore the previous page.

Remarks:

  • Activation is always required to physically delete a page marked as "deleted".
  • No alert boxes are needed anymore.
  • If a page marked as "deleted" contains a sub page, which has not been marked as deleted (e.g. a page, which got restored), this page will get deleted anyway on activation of any of its deleted parent pages.
  • If you move a page from outside a tree of deleted page into such tree, the move will fail with an alert notifying you that you can't move a page to page intended to be deleted.
  • You could manually deleted the sub pages of a deleted parent page by manually activating each one of them. If you insisted and intend to work harder than you have to, that is, since deleting the parent node would be the way to go.
  • No labels

20 Comments

  1. Jan Haderka

    I know during discussion we agreed on making deletion directly for nodes that have never been activated. However I found following issue that makes me think it should not be treated special and we should always require activation of deletion:

    1. create a page
    2. version and activate such a page (e.g. run activation workflow) [version nr 1.0 is created)
    3. restore page to version 1.0 [there is no security or workflow on such so any editor can do it]
    4. delete the page [since the page was restored to a pre-activation state, deletion will happen immediately. At this point deactivation is triggered by the listener, but it won't be deactivated at all if we disable this mechanism due to requirement to activate deletion]

    1. Andreas Weder

      I agree this is a valid scenario.

      Same holds probably also if I would import a node with no previous activation info in both the author and the public version. Deleting this node from the author instance with no activation would leave the node on the public instance as well. Then again, my case could be considered somewhat special, I guess.

      So we change this to always require activation then?

      1. Philipp Bärfuss

        Yes, lets opt for the safest and simplest approach first.

  2. Andreas Weder

    I had a look at the work items. To keep changes to a minimum, the only change I propose is to use an icon signalling both the type of a node as well as whether it was deleted or not; check out the second mockup above.

    Do you think that's doable? Would you like to go further or less far?

    1. Philipp Bärfuss

      This is definitely doable. Lets stick to it until we see a need to make it more advanced.

  3. Boris Kraft

    What do you think of the idea to change the menu entry from "Delete page" to "Mark for deletion"? IMHO this would make it clearer that a page is actually not deleted just because you click on the menu entry but needs followup action (i.e. activation of the deletion).

    1. Andreas Weder

      Yes, I agree, calling the action "mark for deletion" makes things clearer. For an existing user, it is not overly intuitive that you'll now have to activate also in order to delete (although this behaviour is definitely wanted, don't get me wrong). Naming the menu entry differently from how it was called before also signifies that there's a change here.

      BTW, at one point I even thought about changing "Activate page" to "Activate changes" to futher clarify this, but that causes problems with "Activate incl. sub pages" ("Activate all changes"? "Activate changes recursively" (too technical)? "Activate changes also in sub pages"?). In the end, to avoid too much confusion, I decided to rather leave these menu entries the way they currently are for now. This also in the light that this is a minor release only.

      1. Andreas Weder

        Or, actually, "Mark page for deletion" would be more consistent with the other other entries and more descriptive.

        1. Boris Kraft

          yes I like it

  4. Boris Kraft

    Would it be difficult to have a menu entry called "Undo 'mark for deletion'" instead of requiring a user to click on versions to "restore" something that hasn't even been deleted yet? The latter seems rather unexpected.

    1. Andreas Weder

      I thought that this was somewhat difficult because of the way version handling works currently. Philipp?

      If not, I propose an entry like "X Remove deletion mark" or even "X Undo deletion", which are both clear enough and less technical.

      1. Antti Hietala

        Commenting on language per Andreas' request. I find the term "Mark page for deletion" perfectly clear. Will there be a corresponding command for non-page assets such as "Mark document for deletion"? Would "Mark for deletion" be more universal?

        The reverse action "Remove deletion mark" is not as clear but I am struggling to come up with a better alternative. Maybe just "Do not delete"?

        1. Jan Haderka

          maybe "Undelete" to not invent new terms?

      2. Philipp Bärfuss

        Would it be difficult to have a menu entry called "Undo 'mark for deletion'

        Yes, close to impossible. All we can do without further code changes/hacks is:

        • gray out menu points

  5. Jan Haderka

    few more scenarios that can happen:

    • activate plain
      • normal => published, OK
      • deleted => removed & deleted, OK
    • deactivate plain
      • normal => removed, OK
      • deleted => will be disabled
    • activate hierarchy
      • all normal => published, OK
      • some deleted => normal is published, deleted is removed and gone after act, OK
      • all deleted => all gone OK
    • deactivate hierarchy
      • all normal => all removed from public, OK
      • some deleted => fail/delete/deactivate?
      • all deleted => will be disabled
    • how to "activate" deletion when:
      • there's no subscriber configured (e.g. public)
      • when all subscribers are switched off

    1. Andreas Weder

      I've thought this through and have found that we could implement it symmetrically, meaning that we act the same on activation and on deactivation of a single page or a multiple pages. I'm not sure what you've meant with "disabled" though (the menu entry?).

      Here's the flows how I've found them. Please have a look at them and let me know if you agree with them and whether they are correct at all. Unfortunately, there's no way you can inline edit them in the wiki - would be great to have that.

      One particular point to discuss is whether we delete pages locally on deactivation, even if there's no subscriber available or configured.

      1. Andreas Weder

        We should actually differentiate it like this:

        • no subscribers configured on activate or deactivate -> delete marked pages locally on activation/deactivation
        • subscribers configured, but turned off -> do NOT delete any marked pages locally
        • subscribers configured, turned on, but not available/responding -> do NOT delete marked pages locally

        In those scenarios above, where we do not delete marked pages, we delete them the next time they are activated/deactivated and the subscribers are available and turned on.

        Do you agree? This would make the flows look like this.

        1. Andreas Weder

          We've discussed this internally and have finally settled on the following behaviour:

          • a page marked as "deleted" is only removed locally, if you activate it. This is independent of whether subscribers are configured, are active or not, or if no subscribers are available at all
          • if you still want to be able to delete pages without requiring activation, you'll remove the markDeleted command in the configuration. Like this, you return behaviour to always immediately delete a page.

          We've found in our discussion that this behaviour is the most consistent with what we currently have and are able to achieve technically.

          So the resulting flows look like this:

  6. Boris Kraft

    Did anybody look into the implication for the synchronization module?

    1. Jan Haderka

      In my opinion there are no implications. Sync module only activates latest versions of activated content so even if page was deleted locally and deletion was not activated yet, synchronization would just take last activated version of this content and use that one to do its job.