Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
0018139Openbravo ERPB. User interfacepublic2011-07-29 18:482022-02-01 08:09
pjuvara 
Triage Platform Base 
normalmajorhave not tried
newopen 
5
3.0MP1 
 
Core
No
0018139: It is not possible to find out the number of records in a grid
When the number of records exceeds 100, the record counter displays >100.

This makes sense since calculating the number of records is an expensive proposition and in many cases users do not need to know that information.

However, there should be a way to request the calculation of the record count.

Please notice that this is a functional regression compared to 2.50 since in that version you could at least scroll to the end of the grid and see the total. This is not possible in Openbravo 3.
Open a grid with more than 100 records and try to figure out how many are there.
(you can use the heartbeat data).
>100 should be an hyperlink that when clicks invokes the record count.
No tags attached.
related to feature request 0018140 new Triage Platform Base It could be interesting if the client have the posibility to choose all records with one click 
has duplicate feature request 0020167 closed dbaz Total count of all records in Grid 
png row-count.png (25,650) 2011-08-09 14:01
https://issues.openbravo.com/file_download.php?file_id=4425&type=bug
png

png LOAD-ALL_0000_01.png (48,297) 2011-09-17 14:01
https://issues.openbravo.com/file_download.php?file_id=4562&type=bug
png

png LOAD-ALL_0001_02.png (21,964) 2011-09-17 14:01
https://issues.openbravo.com/file_download.php?file_id=4563&type=bug
png

png LOAD-ALL_0002_03.png (42,635) 2011-09-17 14:02
https://issues.openbravo.com/file_download.php?file_id=4564&type=bug
png
Issue History
2011-07-29 18:48pjuvaraNew Issue
2011-07-29 18:48pjuvaraAssigned To => dbaz
2011-07-29 18:48pjuvaraModules => Core
2011-08-01 11:39dbazAssigned Todbaz => mtaal
2011-08-01 11:52dbazNote Added: 0039563
2011-08-01 18:04mtaalFixed in Version => 3.0MP3
2011-08-09 14:01rgorisNote Added: 0040041
2011-08-09 14:01rgorisFile Added: row-count.png
2011-08-09 14:01rgorisStatusnew => scheduled
2011-08-09 14:01rgorisFixed in Version3.0MP3 => 3.0MP4
2011-08-09 17:28rgorisNote Added: 0040052
2011-08-09 17:59dbazNote Added: 0040054
2011-08-09 18:15rgorisNote Added: 0040056
2011-08-09 18:16rgorisIssue Monitored: iciordia
2011-09-16 12:44iciordiaRelationship addedrelated to 0018140
2011-09-16 12:57iciordiaNote Added: 0041017
2011-09-16 13:12mtaalNote Added: 0041019
2011-09-17 09:01pjuvaraNote Added: 0041039
2011-09-17 13:52rgorisNote Added: 0041040
2011-09-17 13:53rgorisFile Added: LOAD-ALL_0000_01.png
2011-09-17 13:53rgorisFile Added: LOAD-ALL_0001_02.png
2011-09-17 13:53rgorisFile Added: LOAD-ALL_0002_03.png
2011-09-17 14:01rgorisFile Deleted: LOAD-ALL_0000_01.png
2011-09-17 14:01rgorisFile Deleted: LOAD-ALL_0002_03.png
2011-09-17 14:01rgorisFile Deleted: LOAD-ALL_0001_02.png
2011-09-17 14:01rgorisFile Added: LOAD-ALL_0000_01.png
2011-09-17 14:01rgorisFile Added: LOAD-ALL_0001_02.png
2011-09-17 14:02rgorisFile Added: LOAD-ALL_0002_03.png
2011-09-17 14:03rgorisNote Edited: 0041040bug_revision_view_page.php?bugnote_id=0041040#r2722
2011-09-17 15:58mtaalNote Added: 0041041
2011-09-19 14:34rgorisNote Added: 0041070
2011-09-19 14:34rgorisNote Edited: 0041070bug_revision_view_page.php?bugnote_id=0041070#r2726
2011-09-19 14:36rgorisFixed in Version3.0MP4 => 3.0MP5
2011-09-19 15:34iciordiaNote Added: 0041073
2011-09-19 15:44mtaalNote Added: 0041074
2011-09-19 16:52iciordiaNote Added: 0041080
2011-09-19 17:01pjuvaraNote Added: 0041081
2011-09-19 17:17mtaalNote Added: 0041084
2011-09-19 17:18mtaalNote Edited: 0041084bug_revision_view_page.php?bugnote_id=0041084#r2728
2011-09-19 17:18mtaalNote Edited: 0041084bug_revision_view_page.php?bugnote_id=0041084#r2729
2012-01-20 17:15rgorisNote Added: 0044472
2012-01-20 17:15rgorisIssue Monitored: rgoris
2012-04-03 16:38dbazRelationship addedhas duplicate 0020167
2016-10-21 11:01mtaalStatusscheduled => closed
2016-10-21 11:01mtaalResolutionopen => out of date
2016-10-21 12:37mtaalStatusclosed => new
2016-10-21 12:37mtaalResolutionout of date => open
2016-10-21 12:37mtaalFixed in Version3.0MP5 =>
2016-10-21 12:37mtaalAssigned Tomtaal => platform
2022-02-01 08:09alostaleAssigned Toplatform => Triage Platform Base

Notes
(0039563)
dbaz   
2011-08-01 11:52   
For me a good approach would be: If you click in the "> 100" the real count is shown (related to feature request 18139). After that, the checkbox header is enabled again to be able to select all (related to feature request 18140)

PD: Now it is also possible to click in the selected row count to go to the seleted record. The click visualization for the "> 100" should be similar

PD2: If the query is going to take some time, an animated spinning circle or something similar should be shown while the count is being calculated
(0040041)
rgoris   
2011-08-09 14:01   
I propose to launch a row count request when pressing the row counter in the top left of the grid.

Currently we already use the selected row counter as a button in case selected rows are outside the visible viewport. The same can be done for the total row counter. On hover it turns orange, on click the ">100" is replaced by the actual total row count.
(0040052)
rgoris   
2011-08-09 17:28   
(as per email from Iciordia) - let´s do it this way.

as we discussed I think that our UI is already pretty sophisticated and I would prefer to keep it simple and avoid "additional" behaviour if it does not add huge value. So I am not for the count request when pressing the row counter.
Instead I would just implement the counter properly. If the grid knows the count of records (because all records fit in the current page) it should write the exact count (you know, just tell me!). If the number or records does not fit in the current page and the user wants to know the exact number of records it has push the scroll up to the end. Simple and obvious. It does not add any additional complexity to our ui and solves the problem. This solution does not just provide the exact count when requested but in all cases it is known by the grid (most Openbravo tabs have less than 100 records so you will get the exact number without any additional request).
(0040054)
dbaz   
2011-08-09 17:59   
http://openbravo.uservoice.com/forums/13955-openbravo/suggestions/2088541-it-should-be-possible-to-request-the-count-of-reco?ref=title [^]

I think there is a point that you have missed, although maybe is pointless, since you affirm that most Openbravo tabs have less then 100 records. In large grids, the grid doesn't know where is the bottom of the scroll, so if you move the scroll to the bottom, it request new data, and it is added at the end, and then the scroll is moved to the middle of the scroll bar. Inside, for example, a 2000 records grid, maybe you have to scroll down (to the bottom) 50 times to see the end (to know the total count).

You can test what I am saying, for example, in "Tables and Columns" or in "Windows, Tabs, and Fields" in current pi
(0040056)
rgoris   
2011-08-09 18:15   
i believe Ismael means that you would then have to re-drag over and over again to reach the end. Google Reader does the same.

Can be tedious but it is still a decent human task for a couple of thousand of records.
(0041017)
iciordia   
2011-09-16 12:57   
I think the best solution is to "decide" when the user really wants to go to the end of the scroll. In that case it should be done in one shot without asking the user for several scroll actions to reach the end.

At this moment I see two clear cases:
-When the user drags the grid scroll to the end (maybe there are other scroll user actions that can be interpreted as "take me to the end", David?)
-When the user checks the "Select all" button (see related issue 18140)

Then we have the case of a user who wants to know the exact number or records. Once we have implemented a method to ask the grid "take me to the end", it would be simple to invoke that method when clicking the "> 100". Not sure if it makes our UI more complex (sounds like simple).
(0041019)
mtaal   
2011-09-16 13:12   
First: currently scrolling to the next page is done by the putting the scrollbar at the end. So it is not really possible to make a difference to next page and end of set.

To get to end of the set a user can also change the sort.

Another solution can be to add a preference which allows enabling the count query for a tab. This would make the count shown to the user reliable and also would result in a correct scrollbar. Or maybe add a property to a table ('Extra High Volume').

But even then the select all is not solved.

The first 'problem' is that dragging to the end does not load all data either, it should only load the last page.

Secondly currrently selecting and processing records is done completely on the client using javascript.

If we want to support select all (also select non-loaded records) then it means that each button potentially needs to support a client side select and a server side select (select all) and processing. For example, delete currently does this:
- get the id's of all selected records
- send a delete request to the server with these id's

If we want to support select all then *in addition* we need to support this:
- if select all and not all records are loaded then, send the query/filter criteria to the server
- process the query there and execute the action

It is a fair amount of work to develop a generic server side select all (like a few days to a week). While imv there is already a fine solution: just increase the number of records to show in the grid or add a new preference 'Enable Count' or table property.
(0041039)
pjuvara   
2011-09-17 09:01   
I do not mean to interfere with the team's user interaction design but to me it is clear that the best and most intuitive option to get the actual count of records is to make the ">100" text clickable and that initiates the count.

Wanting to see how many records are returned by a query is a *very* frequent action for anybody that wants to analyze the data.
That action needs to be explicit and fast, rather than implicit (move the bar to the bottom) or slow (paginate to the end of 100,000 records, 100 at a time).

With regards to select all, I am not sure how pressing a need that would be, but I would not mix these two requests.
Certainly, there are valid business cases for taking actions on records in mass (for example: select all orders in draft status and book them) but it never happened to me to want to perform an action on more than 100 records at a time (people want to be careful in those situations and see all records that they manipulate).

If we want to implement a "select all", the interaction design adopted by GMail is a very successful and proven one:
1) You click on select all and only visible records are selected
2) A message appears stating that other records exist and giving you an opportunity to select all
3) If you select all, the action is taken on all of them.

I am not sure how much work that would be but, even in this scenario I would separate the priority of the request:
1) If you select all and there are non visible records that are not selected, the user should be informed. In other words, we should present a message alerting them that there are other records, even if we do not give them an option to select all.
2) Lower priority is to select all and take an action.

My 2 cents.
(0041040)
rgoris   
2011-09-17 13:52   
(edited on: 2011-09-17 14:03)
Record Count
I agree with Paolo. Let´s build the original idea (see first screenshot). Also build in a confirmation step. Would it be possible to have a loader (progress indicator) while counting the records?

Select All
The concepts of visible and invisible is not clear in our grids as there are two "visibilities": visible in view port, visible outside view port (when moving the slider bar. Gmail uses pagination, and select-all selects all items on a page (50 rows). In our case when having >100 records this won´t work (as it is not clear what the visible amount really is).

So I suggest to add a confirmation step (just as for the count) in case of a select-all action. This warns the user that the amount of records is high and that this might take a while.

See mocks. For counting replace "Select" with "Load" (if that´s really possible or "Count" if it is just a count.

(0041041)
mtaal   
2011-09-17 15:58   
To give some background information:
1) doing a count on request is quite doable, another solution can be to have the grid work in 2 modes:
a) non-counted which is the default, which gives an 'inaccurate' scrollbar
b) count mode, which gives an accurate scrollbar
It is quite easy to let the grid work in count mode, actually we currently send an extra parameter to prevent the count from happening, so working in count mode is not more then removing this extra parameter.

2) doing selectall also for non-loaded records is somewhat different from what we do currently. Currently it works like this:
a) select (all) records on the client, then press a button
b) the id's of the selected records are collected and send to the server
c) on the server the id's are used to execute the action

If we want to support select all incl. non-loaded records we can not send the id's from the client to the server but we need to send the query and the filter parameters to the server to be processed there and the action executed. This can be made generic so that the specific server side action implementation is not soo much extra work.

But overall, enabling count mode is far more easy (a few hours with visualization) compared to the select-all-with-action-on-the-server which is a few days (because of the new generic code on the client/server to send out the query/filters).

gr. Martin

gr. Martin
(0041070)
rgoris   
2011-09-19 14:34   
Martin and I just discussed and we will first focus on the count. It will be implemented as follows:
1-User clicks on >100 counter
2-System loads and counts all records from the server
3-Loading activity status bar is visible while loading (either on the spot of the counter or using the common loading candy bar.
4-System replaces the >100 with the correct amount.
5-System stays in Count Mode until tab is closed.

Select all will be looked at in a later stage.

(0041073)
iciordia   
2011-09-19 15:34   
Rob,

what does it mean "System stays in Count Mode until tab is closed"?

I think it would be trivial to add a new small feature: after the system returns the real number records the scroll is resized to fit that count. Makes sense?

Ismael
(0041074)
mtaal   
2011-09-19 15:44   
Hi Ismael,
The scroll is automatically resized, so that works fine. In count mode means that when the user then scrolls through the data that either the computed count is re-used or a new count is computed. So the grid switches from non-count mode (current behavior) to count mode (either by caching the computed count or recompute the count all the time).

gr. Martin
(0041080)
iciordia   
2011-09-19 16:52   
Ok, clear.

It should cache the count, right? So only the full count is executed when the user specifically requests it.

Ismael
(0041081)
pjuvara   
2011-09-19 17:01   
I am a bit concerned with Rob's statement "System loads and counts all records from the server".

I would like to make sure that we are not planning to load all records and to count them on the client. There could be millions of very large records so this would take a huge amount of resources at all levels.

I think that the client should request the server for the count and the server should simply respond with the result (just the number).

Executing the count could be expensive for the server but at least it would not propagate the issue on other resources.

Everything else should continue working as it does now.

Can you please clarify?
(0041084)
mtaal   
2011-09-19 17:17   
(edited on: 2011-09-19 17:18)
Yes for sure the count is done on the server and it is done with a count query, so definitely not by iterating over the records.

To give some background info, the json webservice (which retrieves the data) when getting a request for page of data (so with a startRow and endRow parameter) will also do a count of the total records and return the totalCount together with the data itself.

If a 'noCount' parameter is passed-in then the count action is not done and the system returns a guessed count (there is some 'smart' logic which tries to make the best assumption about the count without doing a count, I can explain it separately if someone is interested :-).

As a default all our grids pass the 'noCount' parameter and receive a guessed count back.

So when we do the count action separately we need to add a caching mechanism for the count so that it is not repeated all the time, for example, pass the cached count to the server where it can be re-used or ignored if the server detects that the cachedCount is incorrect (the server knows the real count when getting the last page of data).

gr. Martin

(0044472)
rgoris   
2012-01-20 17:15   
After our little discussion yesterday, here´s a nudge to work on this one again.