[MGNLACTIVATION-66] Activation of subnodes fail when parent node has been renamed but change has not been activated Created: 14/Oct/09 Updated: 04/Nov/15 Resolved: 04/Nov/15 |
|
| Status: | Closed |
| Project: | Activation |
| Component/s: | None |
| Affects Version/s: | 5.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Timo Pulkkinen | Assignee: | Philipp Bärfuss |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | parentnotfound | ||
| 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 |
|
Didn't find this reported earlier, so here comes: Steps to reproduce: 1. Create a simple hierarchy of pages, e.g.: 2. Activate all nodes 4. Try to activate some of the child nodes, e.g. 'child1' The problem is resolved if the parent node is re-activated but this operation apparently is not intuitive to the user and causes confusion. Possible fixes:
|
| Comments |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |