[MAGNOLIA-3230] incorrect indication of status after edit during activation workflow Created: 17/Jun/10  Updated: 05/Feb/18  Resolved: 15/Nov/11

Status: Closed
Project: Magnolia
Component/s: activation, workflow
Affects Version/s: 4.3.2
Fix Version/s: 4.4.6

Type: Bug Priority: Major
Reporter: Richard Unger Assignee: Milan Divilek
Resolution: Fixed Votes: 0
Labels: activation
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested under Windows, using Magnolia Tomcat Bundle for EE 4.3.2


Issue Links:
causality
is causing MGNLACTIVATION-175 multiple publishing leaves page in "m... Closed
is causing PUBLISHING-34 multiple publishing leaves page in "m... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

If a page is edited while it is within the activation workflow, the edits will be reflected on the authoring system, but the (default implementation of the) activation workflow will publish the original version of the page, regardless of the edits.

The problem is that the status indication for the page will change to "green" when the activation workflow completes, even though the version published is not the most recent one.

So this creates a situation where the page is marked as green on the authoring system, even though it is not the same version as on the live system.



 Comments   
Comment by Jan Haderka [ 13/Jun/11 ]

The setting of the date is not done at correct place - activation date will be changed even when activation fails!
It is ok to retrieve the date at the beginning, but it can be only set after success in the updateMetadata() method.
And the change should be applied also to trunk.

Comment by Richard Unger [ 13/Jun/11 ]

I don't consider this the solution, it is at best a temporary "workaround".

If you record the last activation as the version creation date, this may work for the status-indicator, but in reality you have falsely recorded the activation date.

Any code currently depending on this field may have incorrect semantics: depending on whether it is trying to determine:

  • "time of last change before activation-initiation"
  • "time of activation-initiation"
  • or the "actual time of activation"

All these values can be different, and have different meanings.

I don't think you can solve this properly without doing some additional bookkeeping.
I think you need to record in some way both:

  1. the time of the content's "last change before activation-initiation" - this is the "version" of the content being activated
  2. the time of the "actual activation" - this is when the content really went online.

If you don't do it in this way, some information will be missing, and it will not be possible to tell when content was really activated, or which version was really activated.

Comment by Jan Haderka [ 14/Jun/11 ]

Thanks for the feedback Richard. The points you raise are valid and we will discuss the solution and possible re-development of the feature again.

Comment by Jan Haderka [ 15/Jun/11 ]

So here's the outcome of the discussion:

  • we will not change the metadata and introduce new field
    • such a field would have to exist for all content and would increase the size of repo
    • metadata will be re-factored completely after 5.0 release.
  • we will store the correct activation date as before
  • in order to show the correct status, Magnolia will touch every node after activation in case such node was modified between version creation and the activation.
  • the above behavior will be documented so ensure users understand why last modification date might change without user making changes to the content themselves.
Comment by Daniel Lipp [ 19/Aug/11 ]

Tests to cover all lines of BaseSyndicatorImpl#updateMetaData were added. Next step would be to create a test that actually provokes the error (needs versioned content). Might be less effort to use a RepositoryBaseTest here as e.g. versioning is not supported for MockContent.

Caution: recent changes have not been backported to trunk yet

Generated at Mon Feb 12 03:44:28 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.