
|
If you were logged in you would be able to see more operations.
|
|
|
uPortal
Created: 13/Jul/05 12:19 PM
Updated: 05/Mar/08 07:59 AM
|
|
| Component/s: |
Aggregated Layouts
|
| Affects Version/s: |
2.4.1,
2.4.2,
2.5.0 M1,
2.5.1 RC1,
2.5.0 RC1,
2.5.0 RC3,
2.5.0 RC2,
2.5.0 GA,
2.5.1 RC2,
2.5.2 RC1,
2.4.4,
2.4.3,
2.5.1 RC3,
2.5.1 GA,
2.4.3.1,
2.5.3 RC1,
2.5.2 GA,
2.5.3 RC2,
2.5.3 RC3,
2.5.3 GA,
2.5.3.1
|
| Fix Version/s: |
2.6.0 M1,
2.5.4
|
|
|
When deleting a fragment that exists in a user's saved layout, any tabs or fragments located to the right of the deleted fragment are permanently lost.
The last node prior to the deleted fragment has its next_node_id updated to be null, rather than relinking it with the next_node_id of the deleted fragment node. The nodes to the right of the deleted fragment are never updated, and continue to exist within the database.
This can result in confusion, especially when one of the lost nodes is a pushed fragment, as even republishing the fragment will not result in the fragment reappearing.
|
|
Description
|
When deleting a fragment that exists in a user's saved layout, any tabs or fragments located to the right of the deleted fragment are permanently lost.
The last node prior to the deleted fragment has its next_node_id updated to be null, rather than relinking it with the next_node_id of the deleted fragment node. The nodes to the right of the deleted fragment are never updated, and continue to exist within the database.
This can result in confusion, especially when one of the lost nodes is a pushed fragment, as even republishing the fragment will not result in the fragment reappearing. |
Show » |
|
This is done by comparing the list of expected fragments with the list of fragments that were actually processed, and appropriately update the linked list for the set difference.