Openbravo Issue Tracking System - POS2 |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0048349 | POS2 | Restaurants | public | 2022-01-03 16:22 | 2022-02-18 14:19 |
|
Reporter | mmohammad | |
Assigned To | AugustoMauch | |
Priority | normal | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | fixed | |
Platform | | OS | 5 | OS Version | |
Product Version | | |
Target Version | | Fixed in Version | | |
Merge Request Status | |
Review Assigned To | |
OBNetwork customer | |
Support ticket | |
Regression level | |
Regression date | |
Regression introduced in release | |
Regression introduced by commit | |
Triggers an Emergency Pack | No |
|
Summary | 0048349: JIRA 2591 - [FS] the keymap dissapears after screen resized |
Description | On WEBPOS, when I go to the screen sales, the keymap doesn't appear on my resized screen (1024x768)
If the screen resolution is bigger (1920x1080), the keymap is appearing.
|
Steps To Reproduce | Steps to reproduce only one resolution being taken into account:
- Use as base pos2 sample data
- The categories of the Terrace keymap only defines positions for the 16:9 resolution. Define also positions for the 4:3 resolution, different to the ones defined for 16:9, and define them in the * organization.
- Open webpos, and notice that in both 16:9 and 4:3 the position of those category buttons is the same even if their configuration in the backend is different.
- Update the organization of the records that define the position of buttons and define them in the vallblanca organization (update obpos2_keymap_cat_btn_pos set updated = now(), ad_org_id = 'D270A5AC50874F8BA67A88EE977F8E3B';)
- Refresh the master data on WebPOS and notice that now the buttons have different positions in 16:9 and 4:3 |
Proposed Solution | |
Additional Information | |
Tags | AGPCustom |
Relationships | |
Attached Files | Keymap.jpg (66,960) 2022-01-03 16:22 https://issues.openbravo.com/file_download.php?file_id=16488&type=bug
|
|
Issue History |
Date Modified | Username | Field | Change |
2022-01-03 16:22 | mmohammad | New Issue | |
2022-01-03 16:22 | mmohammad | Assigned To | => Retail |
2022-01-03 16:22 | mmohammad | File Added: Keymap.jpg | |
2022-01-03 16:22 | mmohammad | Triggers an Emergency Pack | => No |
2022-01-03 16:29 | mmohammad | Tag Attached: AGPCustom | |
2022-01-10 09:20 | ebecerra | Assigned To | Retail => ebecerra |
2022-01-10 09:20 | ebecerra | Status | new => scheduled |
2022-01-11 09:31 | guilleaer | Status | scheduled => closed |
2022-01-11 09:31 | guilleaer | Resolution | open => unable to reproduce |
2022-01-11 09:32 | guilleaer | Assigned To | ebecerra => mmohammad |
2022-01-14 18:32 | guilleaer | Assigned To | mmohammad => ebecerra |
2022-01-14 18:32 | guilleaer | Status | closed => new |
2022-01-14 18:32 | guilleaer | Resolution | unable to reproduce => open |
2022-01-14 18:32 | guilleaer | Status | new => scheduled |
2022-01-19 12:42 | jorge-garcia | Assigned To | ebecerra => jorge-garcia |
2022-01-24 13:02 | timothee_catteeuw | Note Added: 0134515 | |
2022-01-24 13:11 | timothee_catteeuw | Note Edited: 0134515 | bug_revision_view_page.php?bugnote_id=0134515#r23567 |
2022-01-24 13:12 | timothee_catteeuw | Note Edited: 0134515 | bug_revision_view_page.php?bugnote_id=0134515#r23568 |
2022-01-28 11:00 | guilleaer | Assigned To | jorge-garcia => AugustoMauch |
2022-01-30 11:39 | AugustoMauch | Description Updated | bug_revision_view_page.php?rev_id=23600#r23600 |
2022-01-30 11:39 | AugustoMauch | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=23602#r23602 |
2022-01-30 12:23 | hgbot | Note Added: 0134670 | |
2022-02-01 11:38 | hgbot | Resolution | open => fixed |
2022-02-01 11:38 | hgbot | Status | scheduled => closed |
2022-02-01 11:38 | hgbot | Note Added: 0134702 | |
2022-02-01 11:38 | hgbot | Note Added: 0134703 | |
2022-02-14 18:01 | guilleaer | Note Added: 0134973 | |
2022-02-14 18:01 | guilleaer | Status | closed => new |
2022-02-14 18:01 | guilleaer | Resolution | fixed => open |
2022-02-14 18:01 | guilleaer | Status | new => scheduled |
2022-02-15 14:05 | hgbot | Note Added: 0134989 | |
2022-02-18 14:19 | hgbot | Resolution | open => fixed |
2022-02-18 14:19 | hgbot | Status | scheduled => closed |
2022-02-18 14:19 | hgbot | Note Added: 0135131 | |
2022-02-18 14:19 | hgbot | Note Added: 0135132 | |
Notes |
|
|
The first thing is when switching to automatic the manner of displaying all the categories buttons depending on an area (ex :takeaway) to automatic, all the cat buttons are displayed well.
But it remains one thing to solve because when we want to keep "manual" as configuration for Category button position.
The position of 4:3 is always taking into account, never the 16:9 resolution.
Steps to reproduce :
- switch "Category button position" to manual for a keymap
- for a category button, create 2 category button positions :
--> 1 to GENERIC 16:9 Resolution
--> another to GENERIC 4:3 Resolution
For each resolution configure a different position (by selecting a different column for example)
Go to Web POS, refresh master data,
Switch between 4:3 and 16:9, the position is always the one selected for 4:3
|
|
|
(0134670)
|
hgbot
|
2022-01-30 12:23
|
|
|
|
(0134702)
|
hgbot
|
2022-02-01 11:38
|
|
|
|
(0134703)
|
hgbot
|
2022-02-01 11:38
|
|
|
|
|
Reopened
Timothee inputs
The 16:9 definition is only taking into account when it perfectly match with what it is configured (in my case 1920 x 1080 in my case.
If I am in 16:9 but not exactly with the same resolution , the system switch to 4:3 instead of keeping 16:9
Below a video explaining the topic :
https://watch.screencastify.com/v/H2qEFAwkPibkhcaoiVpQ [^] |
|
|
(0134989)
|
hgbot
|
2022-02-15 14:05
|
|
|
|
(0135131)
|
hgbot
|
2022-02-18 14:19
|
|
Directly closing issue as related merge request is already approved.
Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2 [^]
Changeset: afdfbfbe11d42ca6841b579b1c7f1c655d645873
Author: Augusto Mauch <augusto.mauch@openbravo.com>
Date: 18-02-2022 14:19:14
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/commit/afdfbfbe11d42ca6841b579b1c7f1c655d645873 [^]
Fixes ISSUE-48349: Improves the way the more fitting keymap resolution is selected
When there were several keymap resolutions available, the previous approach worked like this:
- The first keymap started as a candidate
- Then the rest of the keymaps were considered, and to replace the current candidate it must have a smaller distance in all three width, height and ratio than the current candidate
This means that if the second keymap resolution is much better on 2 on those points than the previous candidate and slightly better on one point, still the previous candidate
was used because the new one did not improve all three of them.
In the new approach we measure the normalized distance between the current window dimensions and the resolution of each keymap, and return the keymap with the smallest distance. When
calculating the distance more weight is given to the ratio (.5) than to the width and height (.25) each.
---
M web-jspack/org.openbravo.pos2/src/configurations/keymapConfiguration/utils/getBestScreenResolutionKeymapOption.js
---
|
|
|
(0135132)
|
hgbot
|
2022-02-18 14:19
|
|
|