[MAGNOLIA-7889] Using publication incl. subnodes in assets app does not display the correct 'subassets' status Created: 13/Nov/19  Updated: 06/Oct/20  Resolved: 30/Sep/20

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 5.7.9, 6.2.4

Type: Bug Priority: Neutral
Reporter: Siegfried Zach Assignee: Jaroslav Simak
Resolution: Fixed Votes: 0
Labels: 622, maintenance
Remaining Estimate: Not Specified
Time Spent: 3h
Original Estimate: Not Specified

Issue Links:
Problem/Incident
is caused by MAGNOLIA-7251 Determine activated state from last a... Closed
Relates
causality
relation
is related to PAGES-310 Refresh status column indicators in t... Closed
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:
Visible to:
Bartosz Skonieczny, Nikolaus Hoellige
Epic Link: Support
Sprint: Maintenance 26, Maintenance 27
Story Points: 5

 Description   

The following UseCase leads to "unpublished" (=yellow) Assets in the assts app:

  • Create a folder
  • Upload 2 assets to this Folder: Asset-A and Asset-B
  • Publish the Folder using "Publish incl. subnodes"
  • Edit Asset-A and immediatly publish the asset directly
  • Edit Asset-A again, it becomes yellow
  • Edit Asset-B, it becomes yellow
  • Publish the Folder using "Publish incl. subnodes"
  • Asset-A is not published and stays yellow (forever!)
  • Asset-B becomes green

 

  • This UseCase can be tested on demoauthor
  • Some more Details are described in SUPPORT-10581.
  • The Problem Comes from the configuration of the Actions, the "Publish" Action uses the Version catalog, while the PublishInclSubnodes is using the Default catalog.


 Comments   
Comment by Richard Gange [ 13/Nov/19 ]

It should be mentioned that you can workaround this issue by setting activate recursive to use the versioned catalog. Or you can remove versioning from the single publish and use the default catalog.

Comment by Siegfried Zach [ 26/Nov/19 ]

Some thoughts about:

  • We currently created a Workaround by using a custom Version of the StatusColumnFormatter, which is always using lastModified and lastActivated Dates for decission
  • In my opinion: After publication the node should have the "right" Information. So maybe it would be best if the Default-Version command is Clearing the properties mgnl:lastActivatedVersionCreated and mgnl:lastActivatedVersion, as they do no longer reflect "last" Information about activation of this node.
Comment by Rishab Dhar [ 16/Sep/20 ]

The issue is a more general one and is not limited to Assets App but can be also found in other apps that use node wrapping for performing complex workflows which require persistence of Node state across JCR sessions. Some of the observations during analysis was:

  • Old pages app/assets app don't have this issue (as they use the old deprecated activate command) which is a chain of Version command and Publish command
  • For both assets and pages app the recursive publish goes over DefaultSender which iteratively checks each sub node for VersionedNode type to update the system property lastActivatedVersionCreated. If the node does not match the VersionedNode, as is the case with wrapped nodes, only the activationStatus gets updated to true.
private void updateMetaData(String operation, Node systemSessionNode, Node originalNode, Rule rule, boolean updateVersionName) {
        try {
            if (NodeUtil.isNodeType(systemSessionNode, NodeTypes.Activatable.NAME)) {
                String userName = (String) context.get("userName");
                boolean isPublishOperation = PUBLISH.equals(operation);
                if (updateVersionName && originalNode instanceof VersionedNode) {
                    Version version = ((VersionedNode) originalNode).unwrap();
                    NodeTypes.Activatable.update(systemSessionNode, userName, isPublishOperation, version);
                } else {
                    NodeTypes.Activatable.update(systemSessionNode, userName, isPublishOperation);
                }
            }
        } catch (RepositoryException e) {
            log.error("Could not check for mixin " + NodeTypes.Activatable.NAME + " or failed to update activation status on systemSessionNode: " + NodeUtil.getNodePathIfPossible(systemSessionNode), e);
        }
...
  • The recursive publish seems to work correctly when workflow is used (dx-core) but not on ce

As per jsimak the issue could possibly be a misconfiguration of the publish recursive action in the relevant apps, as they have missing configuration for catalogue which if configured might fix the issue. The older pages app uses catalog website for its configuration for example.

Comment by Rishab Dhar [ 16/Sep/20 ]

this issue has been reported and reproduced in also in 5.7(old UI). When you talk about old apps, are you talking about Magnolia 5.6 or previous, when the activation modules was used instead of publishing module?

I tested on the old compatibility apps which use old UI framework and compared it against the new apps on UI 6.

I verified the issue you mentioned and indeed it breaks. It could be that these issues are related, as in the end the publication goes for both old UI and new UI over the DefaultSender. And the sequence of actions possibly causes Node wrapping also on the old app (not verified). The reason why the publication works is because the update action (meta data of versioned Node on JCR) after sending over the changes to the public instance.

Comment by Simon Lutz [ 30/Sep/20 ]

Needs back-port to 5.7.9.

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