Bug 1129298 - UI paging/sorting: paging/sorting using the paging-buttons/column-headers doesn't update the search text; need to eliminate paging-text/sorting-text from search-text completely
Summary: UI paging/sorting: paging/sorting using the paging-buttons/column-headers doe...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Alexander Wels
QA Contact: Petr Kubica
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-12 14:39 UTC by Einav Cohen
Modified: 2016-04-20 01:31 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1123614
Environment:
Last Closed: 2016-04-20 01:31:33 UTC
oVirt Team: UX
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1119309 0 unspecified CLOSED sorting columns and paging 2021-02-22 00:41:40 UTC
oVirt gerrit 33787 0 master MERGED webadmin: remove sortby/page from searchstring Never

Internal Links: 1119309

Description Einav Cohen 2014-08-12 14:39:08 UTC
+++ This bug was initially created as a clone of Bug #1123614 +++

see attachment 924234 [details] that shows at least two problems with the paging mechanism. 
** in the shown setup, I have reduced the default page size to 5, just in order to avoid creating hundreds of items for demonstrating paging-related issues **. 

(1) in my setup, I have 10+ VMs. results for the "VM:" search query return, as expected, the first page (5 items) in the complete VMs list. 
Note that that "Next" paging button is disabled, even though I have more VMs on the next pages. 
[this issue is a regression and will be resolved in the context of bug 1123614]

(2) since displaying the second page of the search results is impossible via the paging buttons, I appended "page 2" to the search query suffix, and indeed - the second page of results appeared, with the "Prev" paging button properly displayed. 
But again, the "Next" paging button was disabled. 
In addition, clicking on the "Prev" button did work as expected and brought me to the first page of results, but the search text remained with the "page 2" text, which is misleading. 

solution
--------
we should theoretically manipulate the search string to contain the correct page number; however, it will be simpler if we will "disable" the option to write the "page" suffix in the search text altogether. 

after discussing with Vojtech: this is what needs to be done (BTW, this will solve some search-sorting behaviors in the GUI as well):

we need a separate search auto-complete behavior for the client: 
currently, the auto-complete behavior is giving the "sortby" and "page " as possible suffixes for the search text. we need to make sure that the SearchBackend won't give these options as possible suffixes. 
** this will require to clone/inherit/... SearchBackend for the client; the "server" auto-complete behavior should remain as is (i.e. should return "sort by" and "page " as possible suffixes for the search string) in order to maintain backward compatibility for the API. **
if the user will "forcibly" write "sortby" / "page" suffixes for the Search text in the GUI, the GUI will treat that just as any other *illegal* search string. 
[this is in line with the client's SearchBackend not returning "sortby" / "page" as part of the auto-complete options].

when the user is paging / sorting using the GUI (i.e. clicks on the "next"/"prev" paging buttons / clicks on a grid column header), we will add the "page" / "sortby" suffixes to the search text *behind the scenes* (i.e. we won't reflect it in the search-text text-box).

Comment 1 Petr Kubica 2015-08-20 11:18:46 UTC
Verified in rhevm 3.6.0-0.11.master.el6


Note You need to log in before you can comment on or make changes to this bug.