[MAGNOLIA-4415] Metadata - LastAction is not set correctly on public node after activation Created: 16/May/12  Updated: 17/May/12  Resolved: 17/May/12

Status: Closed
Project: Magnolia
Component/s: activation
Affects Version/s: 4.4.6
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Richard Unger Assignee: Jan Haderka
Resolution: Not an issue Votes: 0
Labels: activation, metadata
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Magnolia EE 4.4.6, Linux, Sun JDK 6


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   

You probably hate me by now, but here's another problem I found (my customers reported) to do with activation:

When content is activated, the lastAction is set to the publication date on the author system. Unfortunately this seems to happen after the content is sent to public instance.

The result is that the activated content on the public instance always has the "previous" value for the lastAction metadata field compared to the author system.

Eg:
Content is first published on 15.4.2012
Content is published again on 15.5.2012
Now, on public system lastAction is 15.4.2012 while on author system lastAction is 15.5.2012

This means that after activation, content on author and public instances is different!

This is a problem for us, as we use the publication date to sort the content for various listing type displays.



 Comments   
Comment by Richard Unger [ 16/May/12 ]

I think a solution could look like this:

1. On Author: Determine a timestamp for the activation, and remember it.
2. On Author: Send this timestamp to the public instance with the activation data.
3. On Public: After importing the activation data into mgnlSystem, update all the metadata lastAction fields with the supplied timestamp, before copying to destination workspace.
4. On Author: After receiving success message from public system(s), update lastAction with the remembered timestamp.

In this way, the timestamp for the activation will be constant for all content activated in the same request, and the timestamp will be the same on author and public instances.

Comment by Jan Haderka [ 17/May/12 ]

Hi Richard,
on the contrary we are very grateful when you point out any issue in Magnolia.

In this particular case however, I believe that this is not an issue.
lastAction date in meta data is value meant for Magnolia internal use only and is used on author instance to keep track of performed activations.

What you suggest might work on systems where versioning is not used, but as soon as you use versioning the contract is to deliver that exact version to the public instance, i.e. with whatever values are contained in it.
One more situation where your proposed solution can't be used is when instances are connected in chain, e.g. when your author publishes to staging instance which in turn has public set as its subscriber.

If you want to sort content by the date I would suggest to use custom property for such values rather then value that is meant to be for internal use by activation.

Alternatively, if you insist on using lastAction, you can either try to customize ReceiveFilter or you can add observer that will update the dates for you after activation (you can listen for all content changes, nothing else then activation should modify the content on public) or you can write custom flush policy for cache and when it receives list of content updates, you can selectively go and update that content values to whatever you feel like.

We can continue this discussion in user list or over support, whichever you prefer.

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