[PUBLISHING-63] Publish recursively and modified only is broken Created: 14/Feb/19  Updated: 29/Mar/22  Resolved: 04/Sep/19

Status: Closed
Project: Publishing
Component/s: None
Affects Version/s: 1.1.1
Fix Version/s: None

Type: Bug Priority: High
Reporter: Sebastian Tauch Assignee: Aleksandr Pchelintcev
Resolution: Not an issue Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Attachments: Text File Don't_inverse_child_node_selection_for_recursive+modifiedOnly_publications.patch     PNG File screenshot-1.png    
Issue Links:
Relates
relates to PUBLISHING-57 Publishing with subnodes fails when o... Closed
Template:
Patch included:
Yes
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:
Epic Link: Support
Sprint: Maintenance & Releases
Story Points: 1
Team: Nucleus

 Description   

Selection of child nodes for recursive+modifiedOnly publications selects the wrong nodes. For some reason the rule selection method is overwritten to NOT use the nodes returned by the RuleBasedNodePredicate and there is no comment as to why this change was made. I have attached a patch with a suggested change.

Steps to reproduce:

  • Create new publication action that uses recursive=true, modifiedOnly=true
  • Modify a child node
  • Publish parent node with the new action
  • Modified child node will not get published


 Comments   
Comment by Aleksandr Pchelintcev [ 04/Sep/19 ]

Hi stauch,

After investigation and some pondering, we decided to not proceed with trying to find a solution to this issue. Even though intuitively the problem statement you provided and the patch may seem legit, however, they conflict with some sensitive logic in publishing mechanism:

  • publish action uses a configurable rule which dictates the node types that are considered to be the subjects for the incorporation into the published node version. Simply speaking, if you publish a folder in configuration app (or contacts or any other app that doesn't use worflow publication), *all the mgnl:contentNode nodes will get published with it automatically* (! even in non-recursive case !). Restoring the previous version of such published node will restore those incorporated child nodes as well.
  • however, child directories will only get published if we activate recursively. In order to collect all the nodes for recursive publication we collect all the children that are not considered to "direct" content (like described in the previous bullet). Hence the predicate that inverts the rule (will gather all the folders, but will not consider the content types). This way all the "pubblication roots" will be activated virtually separately (each of them will have its own version and can be handled separately later on).

In order to achieve the behaviour that you desire, you can alter the configuration of the corresponding action. See e.g. /modules/dam-app/apps/assets/subApps/browser/actions/restorePreviousVersionIncludingChildren:

If you desire to handle all the nodes separately disregarding their type - you can leave the allowedTypes node empty.

Hope that helps,
Aleksandr

Comment by Sebastian Tauch [ 04/Sep/19 ]

Hi Aleksandr,

that makes sense!

Thank you for the detailed explanation. The added documentation in the PR will definitely help the next person who stumbles over this! Looks like I'll have to remove our override and add the allowed nodeTypes for publication the canonical way.

Sincerely
Sebastian Tauch

Generated at Mon Feb 12 10:35:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.