[MGNLACTIVATION-50] Wrong activation status on sub nodes which are type mgnl:contentNode Created: 20/Nov/13  Updated: 12/Apr/17  Resolved: 20/Nov/14

Status: Closed
Project: Activation
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Milan Divilek Assignee: Evzen Fochr
Resolution: Cannot Reproduce Votes: 0
Labels: next
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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   

How to reproduce:
1.Create structure in configuration like

  • parent [mgnl:content]
    • subFolder [mgnl:content]
    • subContent [mgnl:contentNode]

2. All the nodes has "red" activation status
3. Then do the "Publish incl. subnodes"
4. status of parent and subFolder are correctly change to "green", but subContent has "red" status



 Comments   
Comment by Peili Liang [ 09/Dec/13 ]

We changed the code so that activation status is updated on nodes of JCR type mgnl:ContentNode, whereas before it was only updated on nodes of JCR type mgnl:Activatable (mgnl:ContentNode does not inherit from mgnl:Activatable).

However, one question we have is whether mgnl:ContentNode should inherit from mgnl:Activatable (since it can be independently activated), which would make it unnecessary to change to the code at all?

Comment by Jan Haderka [ 11/Dec/13 ]

Sorry but there is no need to change code of activation to fix this problem. The issue is default configuration which is made for website(pages) rather then for commands. And it actually shows that we will most likely need to reconfigure activation for every special type such as contacts, etc.

Look at ActivationCommand, it has property called itemTypes} that is list of types to be activated together w/ parent type. By default, it's set to {{mgnl:contentNode because that is the super type of mgnl:area and mgnl:component and those needs to be activated together w/ the page.

Because they are activated as part of the parent type (mgnl:content) their activation status is not updated, which is correct.

However in case of config workspace, there it is ok to be able to activate mgnl:contentNode type separately because there we use it differently. So in case on config workspace, itemTypes property of the activation command should have empty value. I can see 2 ways how to achieve that (although there might be more ways):

  • create config command catalog and reconfigure activation command there and change activate action definition for config app to point to this version of activation command
  • modify ActionDefinition so you can define this property there and make sure it get passed to the command ActionDefinition is invoking

On first sight it seems also as possibility to change default value of itemTypes property from mgnl:contentNode to mgnl:area, mgnl:page however that would not work as some more complex dialog fields save their content in substructure made of mgnl:contentNode elements and those would then not be activated correctly.

Similarly to redefining itemTypes for config, we need to reevaluate such configuration also for contacts and other types we use in M5, but that should be probably done in separate issues.

Comment by Magnolia International [ 11/Dec/13 ]

Isn't this related (or even duplicating) MAGNOLIA-5474 ?

Comment by Jan Haderka [ 12/Dec/13 ]

@Greg nope, it's not. Problem in MAGNOLIA-5474 is that there is mgnl:content node under mgnl:contentNode ( i.e. folder under file) which should not be permissible, but apparently we can't exclude that in JCR node type definition directly w/o other side effects.

Generated at Sun Feb 11 22:59:11 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.