Openbravo Issue Tracking System - Openbravo ERP
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0055313Openbravo ERP01. General setuppublic2024-04-25 12:182024-06-13 13:00
ReporterLeyre 
Assigned ToAugustoMauch 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in VersionPR24Q3 
Merge Request Statusapproved
Review Assigned To
OBNetwork customerOBPS
Web browser
ModulesCore
Support ticket96211
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0055313: Slowness in the "Product Category" dropdown.
DescriptionSlowness in the "Product Category" dropdown.
Steps To ReproduceBackend:
1. Add 1000 active new records in the "Product Category" window.
2. Open the "Product" window and open a product.
3. Try to filter the "Product Category", using "123", it will work fine. Delete the filter text.
4. Open the combo and scroll down until a new page is loaded
5. Write again "123". Notice that the combo is opened empty, when it should have loaded a record.

To create the records for the White Valley client, execute the attached script like this:

psql -h localhost -d db_pos2_modules2 -U tad -f populateCategories.sql

Video provided by the client: https://youtu.be/MJyCh4icwo0 [^]
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
Attached Files? bulkProductCategory.curl (333,753) 2024-04-25 12:18
https://issues.openbravo.com/file_download.php?file_id=19704&type=bug
? populateCategories.sql (1,532) 2024-05-27 08:54
https://issues.openbravo.com/file_download.php?file_id=19820&type=bug
png wrong.png (60,213) 2024-05-27 09:11
https://issues.openbravo.com/file_download.php?file_id=19821&type=bug
png

png right.png (59,882) 2024-05-27 09:11
https://issues.openbravo.com/file_download.php?file_id=19822&type=bug
png
Issue History
Date ModifiedUsernameFieldChange
2024-04-25 12:18LeyreNew Issue
2024-04-25 12:18LeyreAssigned To => Triage Omni OMS
2024-04-25 12:18LeyreFile Added: bulkProductCategory.curl
2024-04-25 12:18LeyreOBNetwork customer => No
2024-04-25 12:18LeyreModules => Core
2024-04-25 12:18LeyreSupport ticket => 96211
2024-04-25 12:18LeyreTriggers an Emergency Pack => No
2024-04-25 12:56PracticsIssue Monitored: Practics
2024-05-07 15:14ngarciaOBNetwork customerNo => OBPS
2024-05-08 09:32LeyreSeverityminor => major
2024-05-08 09:42frank_gonzalezNote Added: 0164310
2024-05-22 13:11aferrazNote Added: 0164970
2024-05-22 13:11aferrazStatusnew => feedback
2024-05-23 08:54egoitzAssigned ToTriage Omni OMS => Triage Platform Base
2024-05-23 08:54egoitzStatusfeedback => new
2024-05-23 08:55egoitzNote Added: 0165005
2024-05-27 08:47AugustoMauchAssigned ToTriage Platform Base => Leyre
2024-05-27 08:48AugustoMauchNote Added: 0165134
2024-05-27 08:51AugustoMauchNote Deleted: 0165134
2024-05-27 08:54AugustoMauchSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=28030#r28030
2024-05-27 08:54AugustoMauchFile Added: populateCategories.sql
2024-05-27 08:55AugustoMauchSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=28031#r28031
2024-05-27 09:01AugustoMauchSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=28032#r28032
2024-05-27 09:10AugustoMauchNote Added: 0165135
2024-05-27 09:11AugustoMauchFile Added: wrong.png
2024-05-27 09:11AugustoMauchFile Added: right.png
2024-05-27 09:44AugustoMauchAssigned ToLeyre => AugustoMauch
2024-05-27 09:44AugustoMauchStatusnew => acknowledged
2024-06-10 13:19AugustoMauchNote Edited: 0165135bug_revision_view_page.php?bugnote_id=0165135#r28086
2024-06-10 17:30hgbotMerge Request Status => open
2024-06-10 17:30hgbotNote Added: 0165749
2024-06-12 09:56AugustoMauchStatusacknowledged => scheduled
2024-06-12 11:24hgbotMerge Request Statusopen => approved
2024-06-12 11:24hgbotMerge Request Statusapproved => open
2024-06-13 12:59hgbotMerge Request Statusopen => approved
2024-06-13 13:00hgbotResolutionopen => fixed
2024-06-13 13:00hgbotStatusscheduled => closed
2024-06-13 13:00hgbotNote Added: 0165907
2024-06-13 13:00hgbotFixed in Version => PR24Q3
2024-06-13 13:00hgbotNote Added: 0165908

Notes
(0164310)
frank_gonzalez   
2024-05-08 09:42   
Jira: https://openbravo.atlassian.net/browse/RM-13808 [^]
(0164970)
aferraz   
2024-05-22 13:11   
Waiting feedback to know how to reproduce the bug
(0165005)
egoitz   
2024-05-23 08:55   
Reasgined to Platform as per Alvaro's request
(0165135)
AugustoMauch   
2024-05-27 09:10   
(edited on: 2024-06-10 13:19)
Problem:
- When filtering after having scrolled down, two request are done. Both include the filter text as criteria. The first one is wrong because it contains a wrong start row, the second one is proper.

See attached images
(0165749)
hgbot   
2024-06-10 17:30   
Merge Request created: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/1272 [^]
(0165907)
hgbot   
2024-06-13 13:00   
Merge request merged: https://gitlab.com/openbravo/product/openbravo/-/merge_requests/1272 [^]
(0165908)
hgbot   
2024-06-13 13:00   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/openbravo [^]
Changeset: d54fc216f43a800493d4bc58488ab9820a30d155
Author: Augusto Mauch <augusto.mauch@openbravo.com>
Date: 13-06-2024 08:59:35
URL: https://gitlab.com/openbravo/product/openbravo/-/commit/d54fc216f43a800493d4bc58488ab9820a30d155 [^]

Fixes ISSUE-55313: No data displayed when filtering after previous scrolling down

The problem is that the wrong start/end row was requested when a filter was set if the current selector list was not showing the first
page.

To fix it, now whenever a selector filter is edited, the scroll is forced to the top, to ensure always the first page is initially requested
. Scrolling down after filtering works fine, further pages are requested

---
M modules/org.openbravo.userinterface.selector/web/org.openbravo.userinterface.selector/js/ob-selector-item.js
---