Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0048349 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [POS2] Restaurants | major | have not tried | 2022-01-03 16:22 | 2022-02-18 14:19 | |||
| Reporter | mmohammad | View Status | public | |||||
| Assigned To | AugustoMauch | |||||||
| Priority | normal | Resolution | fixed | Fixed in Version | ||||
| Status | closed | Fix in branch | Fixed in SCM revision | |||||
| Projection | none | ETA | none | Target Version | ||||
| OS | Any | Database | Any | Java version | ||||
| OS Version | Database version | Ant version | ||||||
| Product Version | SCM revision | |||||||
| Review Assigned To | ||||||||
| 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 | |||||||
| Tags | AGPCustom | |||||||
| Attached Files |  Keymap.jpg [^] (66,960 bytes) 2022-01-03 16:22
| |||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|
 Relationships |
|
Notes |
|
|
(0134515) timothee_catteeuw (developer) 2022-01-24 13:02 edited on: 2022-01-24 13:12 |
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 (developer) 2022-01-30 12:23 |
Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/merge_requests/794 [^] |
|
(0134702) hgbot (developer) 2022-02-01 11:38 |
Directly closing issue as related merge request is already approved. Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2 [^] Changeset: 416956034f628776a6aa621ec5819808e9f99ebc Author: Augusto Mauch <augusto.mauch@openbravo.com> Date: 01-02-2022 10:38:11 URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/commit/416956034f628776a6aa621ec5819808e9f99ebc [^] Fixes ISSUE-48349: Sometimes only one resolution is taken into account The problem is that there was some code that, when there were two positions defined for a button (one for each resolution) if both positions were defined on a non-store organization the same position was used regardless of the current resolution. The code could be removed as it was part of a previous implementation, after removing the code no tests are broken. --- M web-jspack/org.openbravo.pos2/src/configurations/keymapConfiguration/generateKeymapConfig.js --- |
|
(0134703) hgbot (developer) 2022-02-01 11:38 |
Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/merge_requests/794 [^] |
|
(0134973) guilleaer (manager) 2022-02-14 18:01 |
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 (developer) 2022-02-15 14:05 |
Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/merge_requests/815 [^] |
|
(0135131) hgbot (developer) 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 (developer) 2022-02-18 14:19 |
Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/merge_requests/815 [^] |
|
Notes |
|
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 | View Revisions |
| 2022-01-24 13:12 | timothee_catteeuw | Note Edited: 0134515 | View Revisions |
| 2022-01-28 11:00 | guilleaer | Assigned To | jorge-garcia => AugustoMauch |
| 2022-01-30 11:39 | AugustoMauch | Description Updated | View Revisions |
| 2022-01-30 11:39 | AugustoMauch | Steps to Reproduce Updated | View Revisions |
| 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 | |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |