Anonymous | Login
News | My View | View Issues | Roadmap | Summary

View Issue DetailsJump to Notes ] Issue History ] Print ]
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[POS2] Restaurantsmajorhave not tried2022-01-03 16:222022-02-18 14:19
ReportermmohammadView Statuspublic 
Assigned ToAugustoMauch 
PrioritynormalResolutionfixedFixed in Version
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Review Assigned To
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo

0048349: JIRA 2591 - [FS] the keymap dissapears after screen resized

DescriptionOn 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 ReproduceSteps 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
Attached Filesjpg file icon Keymap.jpg [^] (66,960 bytes) 2022-01-03 16:22

- Relationships Relation Graph ] Dependency Graph ]

-  Notes
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

hgbot (developer)
2022-01-30 12:23

Merge Request created: [^]
hgbot (developer)
2022-02-01 11:38

Directly closing issue as related merge request is already approved.

Repository: [^]
Changeset: 416956034f628776a6aa621ec5819808e9f99ebc
Author: Augusto Mauch <>
Date: 01-02-2022 10:38:11
URL: [^]

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
hgbot (developer)
2022-02-01 11:38

Merge request merged: [^]
guilleaer (manager)
2022-02-14 18:01


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 : [^]
hgbot (developer)
2022-02-15 14:05

Merge Request created: [^]
hgbot (developer)
2022-02-18 14:19

Directly closing issue as related merge request is already approved.

Repository: [^]
Changeset: afdfbfbe11d42ca6841b579b1c7f1c655d645873
Author: Augusto Mauch <>
Date: 18-02-2022 14:19:14
URL: [^]

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
hgbot (developer)
2022-02-18 14:19

Merge request merged: [^]

- 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

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker