History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: UP-1164
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Andrew Petro
Reporter: Eric Andresen
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
uPortal

Tabs to the right of a deleted fragment are lost

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

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown
File Attachments: 1. Text File 242_alm_explore.txt (4 kb)
2. Text File 25.txt (4 kb)
3. File up-1164.ALM.2.diff (4 kb)
4. File up-1164.ALM.diff (4 kb)

Issue Links:
Generic Relation
This issue relates to:
UP-1577 AggregatedUserLayoutStore setAggregat... Major Closed
UP-1578 AggregatedUserlayoutStore setAggregat... Major Closed
 


 Description  « Hide
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.

 All   Comments   Work Log   Change History      Sort Order:
Eric Andresen [13/Jul/05 05:24 PM]
Attached is a unified diff of the fix to this issue.

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.


Eric Andresen [13/Jul/05 05:30 PM]
Further note: the attached patch is against uPortal 2.4.2.

Eric Andresen [19/Jul/05 12:34 PM]
Updated patch against uPortal 2.4.2; this fixes the additional case of the lost fragment being the first or last tab in a user's layout.

Brad Johnson [17/Oct/05 01:25 PM]
Is this a problem in 2.5.x?

Andrew Petro [21/Aug/07 02:21 PM]
Attaching a slightly textually cleaned up take on the 2nd (improved) patch, against the 2.4.2 ALM exploratory branch. I have verified the existence of this issue there and that this patch apparently fixes the issue.

Andrew Petro [21/Aug/07 03:44 PM]
I have replicated this issue in 2-5-patches tip.

Steps to replicate:
1) Log in as Admin
2) Observe a rich listing of tabs across the top, along the lines of
Error Handling | Development | Portlet Examples | CWebProxy examples | ICC Demo | Admin tools | WSRP Examples | Dynamic Title | News |
3) Enter preferences mode
4) Enter the Fragment Manager
5) Select the Admin Tools fragment
6) Click the Delete Fragment control in the context of the Admin Tools fragment
7) Exit the fragment manager
8) Save preferences (not clear that this step makes any difference)
9) Exit preferences mode
10) Log out
11) Log in as admin
12) Experience a greatly reduced set of tabs along the lines of
Error Handling | Development | Portlet Examples | CWebProxy examples | ICC Demo
Notice that more fragments disappeared than the Admin Tools fragment

Expected behavior:
Expected was that only the Admin Tools fragment would disappear, as only it had been deleted.


Andrew Petro [21/Aug/07 04:24 PM]
Patch against 2-5-patches applying the Eric Andresen fix.

Andrew Petro [21/Aug/07 04:43 PM]
The fix in UP-1164 was applied to HEAD for uPortal 2.6.0 M1 by nbolton per more general merging in of Academus ALM fixes via UP-1577 and UP-1578

Andrew Petro [21/Aug/07 04:43 PM]
The fix in UP-1164 was applied to HEAD for uPortal 2.6.0 M1 by nbolton per more general merging in of Academus ALM fixes via UP-1577 and UP-1578

Andrew Petro [21/Aug/07 04:44 PM]
The fix in UP-1164 was applied to HEAD for uPortal 2.6.0 M1 by nbolton per more general merging in of Academus ALM fixes via UP-1577 and UP-1578

Andrew Petro [21/Aug/07 05:01 PM]
Fixed this issue in 2-4-patches, 2-5-patches, and in the 2.4.2 ALM exploratory branch. This issue was already fixed in 2-6-patches and in trunk (released in UPortal 2.6.0 M1) under the more general merge of Academus uPortal codebase enhancements into uPortal itself.