[MAGNOLIA-2801] Node properties update during activation is too restrictive Created: 25/Jun/09 Updated: 23/Jan/13 Resolved: 25/Jun/09 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | activation |
| Affects Version/s: | 4.0.1, 3.6.5, 4.1 |
| Fix Version/s: | 4.1.1 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Jan Haderka | Assignee: | Jan Haderka |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| 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)
|
||||||||
| Description |
|
Currently to update the properties of existing node on re-activation, the temporary subnode of CONTENT_NODE type is created to hold updated properties. Therefore any content has to allow for such children. This is too restrictive for some content types(e.g. mgnl:forum, and possibly custom data module types as well) and is unnecessary. |
| Comments |
| Comment by Jan Haderka [ 25/Jun/09 ] |
|
The temporary node is no longer stored directly under the activated node to prevent possible collisions due to allowed node types of child nodes for the activated node. |