[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:
2. All the nodes has "red" activation 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):
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) |
| Comment by Jan Haderka [ 12/Dec/13 ] |
|
@Greg nope, it's not. Problem in |