Bug 1123614 - UI paging: 'next' paging button is disabled when actually it should be enabled.
Summary: UI paging: 'next' paging button is disabled when actually it should be enabled.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal
Version: 3.5.0
Hardware: Unspecified
OS: Linux
high
high
Target Milestone: ---
: 3.5.0
Assignee: Alexander Wels
QA Contact: Jiri Belka
URL:
Whiteboard: ux
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-27 09:04 UTC by Eli Mesika
Modified: 2015-02-16 13:35 UTC (History)
8 users (show)

Fixed In Version: ovirt-3.5.0_rc1.1
Doc Type: Bug Fix
Doc Text:
Cause: The logic for enabling/disabling the button was reversed and would not show properly. Consequence: The next/prev buttons were disable when they should be enabled. Fix: Fix the logic to not be reversed. Result: The next/prev buttons are now properly enabled.
Clone Of:
: 1129298 (view as bug list)
Environment:
Last Closed: 2015-02-16 13:35:29 UTC
oVirt Team: ---


Attachments (Terms of Use)
screen-cast: paging is not working (1.78 MB, video/ogg)
2014-08-05 14:58 UTC, Einav Cohen
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 31410 master MERGED userportal,webadmin: next page not working Never
oVirt gerrit 31453 ovirt-engine-3.5 MERGED userportal,webadmin: next page not working Never

Description Eli Mesika 2014-07-27 09:04:01 UTC
Description of problem:
UI paging is not working 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.Add more than 100 events [1]
2.Open the UI events tab


Actual results:
You can see that the paging buttons ('<', '>') are disabled although there are more than 100 events in the table 

Expected results:
Paging should work when there are more than 100 records 

Additional info:
You can search with "Events:page <x>" where <X> is a page number and this is working as expected, but paging buttons are still disabled

Comment 2 Eli Mesika 2014-07-27 09:09:31 UTC
I had tested on other entities as DC / Cluster etc. and paging is not working as well , so it seems as a general issue

Comment 3 Einav Cohen 2014-08-05 14:49:56 UTC
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.

Comment 4 Einav Cohen 2014-08-05 14:58:23 UTC
Created attachment 924234 [details]
screen-cast: paging is not working

Comment 5 Einav Cohen 2014-08-05 16:47:51 UTC
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).

Comment 6 Eli Mesika 2014-08-06 07:54:53 UTC
(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 ....

Comment 7 Alexander Wels 2014-08-12 14:32:05 UTC
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 !).

Comment 8 Einav Cohen 2014-08-12 14:43:01 UTC
(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?).

Comment 10 Jiri Belka 2014-09-11 13:16:42 UTC
ok, rhevm-webadmin-portal-3.5.0-0.11.beta.el6ev.noarch

tested with many Vms and events


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