Page tree
Skip to end of metadata
Go to start of metadata

Problem

Actual getting of node activation status is not sufficient for case in MGNLACTIVATION-135.

Environment: versioning and workflow.

Setup: modify page 1, create activation task 1, modify page 2, create activation task 2, approve task 1, approve task 2.

Result: page stay in modified status.

Diagram of actual state:

Problem core

Activation status is get from difference between modification date and activation date NodeTypes.java.

 

Investigated solutions

https://git.magnolia-cms.com/projects/MODULES/repos/activation/pull-requests/17/diff

If activated version is not latest set modification date to activation date +1 ms (already there). If activated version is latest version set modification date to creation date of the latest version (added in PR).

(plus) page has correct activated status after second activation task

(minus) there can be 3rd modification after creation of 2nd activation task and this information is lost while 1 activation task set modification date to activation1 +1ms which results in incorrect activated status of page

Proposal

I see only way how to solve it is change how we get/store node activaton status (3 state system property).

  • No labels

10 Comments

  1. Short summary

    The "activation-status" is determined as follows:

    NodeTypes.Activatable#getActivationStatus
    if (lastModified != null && lastModified.after(lastActivated)) {
        // node has been modified after last activation
        return ACTIVATION_STATUS_MODIFIED;
    }
    
    // activated and not modified ever since
    return ACTIVATION_STATUS_ACTIVATED;

    Some history and quirks

    Magnolia 4.4.x introduced MAGNOLIA-3230 to deal with the following scenario returning the wrong activation status:

    ---|----------------|---------|------------>
      V1               Mod       A1

    To "fix" it we decided to "touch" the node if there had been any modification after the in-progress activation and set the modification date 1ms later than the in-progress activation-date.

    // Before MAGNOLIA-3230
    if (Mod.date after V1.date) {
        ACTIVATED // WRONG
    }
    
    // After MAGNOLIA-3230
    if (Mod.date after V1.date) {
       Mod.date = A1 + 1ms
    }
    if (Mod.date after V1.date) {
        MODIFIED // CORRECT
    }

     

    The following scenario is a direct consequence of this change:

    ---|-------|---------|-----|-----------|--->
      V1      Mod       V2     A1         A2

    The modification date will be "pushed back" by touching the node after each activation.

    if (Mod.date after V1.date) {
       Mod.date = A1 + 1ms 
    }
    if (Mod.date after V2.date) {
       Mod.date = A2 + 1ms 
    }
    
    if (lastModified.after(lastActivated)) {
    // has been modified after last activation
        return ACTIVATION_STATUS_MODIFIED;
    }

    Conclusion

    As Evzen Fochr already pointed out: There is no easy fix for this.

    IMO we are trying to mix two different states into one. With workflow and versioning the state "Published" as we use it has no meaning. What you really want to know is which version was published to the public instances. And the status "Modified" has nothing to do with the last activation-status. A node is modified if there have been modifications to the node since the last version was created.

    I would suggest:

    • Revert MAGNOLIA-3230 and not touch the modification-date when publishing. It sort of makes the modification-status useless that way.
    • To determine whether the node has been modified, compare the mod-date with the latest version's creation date.
    • Display the modification-status and the last published version in the browser-app in separated columns.
    • This would also imply moving the activation-status out of NodeTypes again, so partly reverting MAGNOLIA-4651.

     

    Vx - Version x created
    Ax - activation of version x
    Mod - some modification
  2. Espen Jervidalo

    I see one problematic scenario:

    ---|-------|---------|-----|-----------|--->
      V1      Mod       V2     A2         A1

    After this we got activated, not modified page on author and V1 on public, i think we need to store information which 

    version was activated latest.
    1. Yeah, that is implied in "Display the modification-status and the last published version in the browser-app in separated columns.".

      1. I mean "compare the mod-date with the latest version's creation date" → "compare the mod-date with the latest published version's creation date"

  3. I've been asked to have a short look at this.

    I played through a couple of scenarios (typical flow; multiple publication tasks approved in order; out-of-order approval of multiple publication tasks; and modification after the last activation) and have found so far, that the following holds:

    is_modified = modification_date(latest_change) > activation_date(latest_version);

    This assumes that we revert the previous change and no longer change the modification date after an activation.

    Instead, we have to remember the activation date of the most recently created version (only).

    WDYT?

    1. Actually, rather then trying to solve the logic problem in the issue, I was hoping to get some mocks of what would be ideal for users to see and when. E.g. should we display that there is workflow running on that page? Or even on given version of the page in history view? Have a view of all workflows currently running against this page/piece-of-content? Would it be useful/expected for approver to get notifs about all other workflows on same piece of content when approving them so he can decide to skip older ones and just go for the latest? Should we group those somehow? Etc. What would be the ideal state for end users to have. What would they love. We can then derive technical solution from designed user experience rather than from pile of patch upon patch in code that was obviously not made with all current possibilities in mind when originally written (no offense).

  4. What about storing page state activation date (like publish task creation date, store it after task approval) ?

  5. Notes from Arch-meeting: 2016-08-30 Meeting notes

    Summary

    The proposal from my comment only works for versioned nodes. In the simplest case, without versioning the current implementation is correct. However, we usually work with versionable nodes, so we need to handle both use-cases correctly.

  6. I gave one more thought to activation ticket, what about creating WorkflowSyndicatorImpl and instead of storing time of activation aproval to node last activated we can store time, when wf task was created.

  7. One possible way out of this (in terms of quick fix) is to just calculate MD5 or other type of signature of node (w/ all it's subnodes and properties expect mgnl:lastModified* and compare to same signature of current/master version of the node. That way, as long as content of the node is same as one just activated, activation state will show correct value whether there were any versions or workflow tasks created in between or not ... or despite the order in which tasks have been approved and executed.