[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: |
|
||||||||||||||||||||||||
| 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:
|
| 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:
|
| 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:
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); } ...
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 ] |
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. |