Short summary

The "activation-status" is determined as follows:

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

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 

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?

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

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.

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.

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.