Bug 1123614

I had tested on other entities as DC / Cluster etc. and paging is not working as well , so it seems as a general issue

not sure what is happening in 3.4; if this is not a regression from 3.4, it is not urgent to fix for 3.5 -> flagging for 3.6.

Created attachment 924234 [details]
screen-cast: paging is not working

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. 

(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
--------

* the "Next" paging button should be enabled if the number of displayed results equals the requested page size; e.g. if the page size is 100, and the number of displayed results in this page is 100, we should enable the "Next" button (since most likely, there are more results on the next page). Otherwise (e.g. if the page size is 100 and the number of displayed results is 90), we should disable the "Next" button (since there are no more results on the next page for sure). 
In my setup, the page size was 5 and the number of displayed items in both page 1 and page 2 was 5, however the "Next" paging button was disabled (I am not sure if this is because I changed the default page size to 5, but still somewhere there is a hardcoded comparison to "100" or something similar). 

* In order to fix (2), 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).

(In reply to Einav Cohen from comment #5)

> solution
> --------
> 

That's OK, but since I am sure that this is a regression , I would use git-bisect to find when this had occurred and see what was the original solution before thinking on a new one ....

I think we want to split out the 'page' and 'sortby' in the search box into a separate BZ RFE. This was a simple regression, with a really simple fix (a single !).

(In reply to Eli Mesika from comment #6)
> (In reply to Einav Cohen from comment #5)
> 
> > solution
> > --------
> > 
> 
> That's OK, but since I am sure that this is a regression , I would use
> git-bisect to find when this had occurred and see what was the original
> solution before thinking on a new one ....

indeed - it seems that the 'next' button was disabled due to a bug that was introduced only in 3.5 AFAIK (http://gerrit.ovirt.org/#/c/24523/), so this is indeed a regression, so worth fixing this particular one for 3.5. 

issue (2) (which requires a little bit more work, probably) is now documented in Bug 1129298 and will be resolved later on (3.6?).

ok, rhevm-webadmin-portal-3.5.0-0.11.beta.el6ev.noarch

tested with many Vms and events