Release 36 DP Regression Testing (WAT1 Release) (ACE-1771)

[ACE-2000] Filters not created for doclib navigation Created: 12-Jun-14  Updated: 08-Jul-14  Resolved: 13-Jun-14

Status: Closed
Project: Alfresco One Platform
Component/s: Document Library, Share Application
Affects Version/s: Cloud 36
Fix Version/s: 5.0

Type: Feature Bug Priority: Critical
Reporter: Mike Farman Assignee: Closed Issues
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File screenshot-1.jpg    
Test In: DP
Sprint: WAT1 Release Sprint 2
Cloud or Enterprise: Cloud and Enterprise

 Description   

The filter is not being added to the page URL when navigating the document library. This means if the page is refreshed the path goes back to the doclib root, the folder path is not bookmark-able etc

See screenshot attached



 Comments   
Comment by David Webster [X] (Inactive) [ 12-Jun-14 ]

I've been able to reproduce locally. The folder path is correctly applied the first time you clicking on the folder tree after selecting a category, but otherwise is missing.

Comment by David Draper [X] (Inactive) [ 12-Jun-14 ]

I believe that the code that handles this is in documentlist.js and the last change that looks relevant was in r71925 (committed by Richard Smith [X])

Comment by David Webster [X] (Inactive) [ 12-Jun-14 ]

Yep - that's the line of code I've been looking at. Reverting that commit does indeed fix the issue. I'll rework that fix now.

Comment by Richard Smith [X] (Inactive) [ 12-Jun-14 ]

I believe that this will reintroduce bug ACE-1297 which was already introduced by ALF-19161. The original issue only related to the re-clicking of an already selected filter and reloading of the results from that repeated event.

Comment by David Webster [X] (Inactive) [ 12-Jun-14 ]

Fixed: r73679. I've reversed the fixes for ACE-1297 and ALF-19161, implementing the same fix as suggested in ALF-19161, but in a more robust way.

The problem was that YAHOO.util.History.multiNavigate doesn't do anything if the filter is the same as is currently displayed. The tree nav works around that without going through the onFilterChange event, but the filter and the tag don't, so without wishing to refactor those widgets the best fix is still to trigger an update, as opposed to a navigate, if the new filter is the same as the current one, but the method of comparing the new and the old filter wasn't really working in the original fix, so I've done that differently.

Comment by Dmitry Yukhnovets [X] (Inactive) [ 13-Jun-14 ]

The issue is not reproduced for Cloud2 myAlfrescoHead build 537 rel36rc5.
The issue is not reproduced for Alfresco Enterprise v4.3.0 (r73679-b1757) schema 7005

Generated at Sat Jul 11 06:53:48 BST 2020 using JIRA 7.6.3#76005-sha1:8a4e38d34af948780dbf52044e7aafb13a7cae58.