Project:
View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | ||||||||
0050361 | ||||||||
Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
defect | [Retail Modules] Web POS | major | random | 2022-09-27 23:49 | 2022-09-28 23:25 | |||
Reporter | AugustoMauch | View Status | public | |||||
Assigned To | AugustoMauch | |||||||
Priority | normal | Resolution | fixed | Fixed in Version | RR22Q4 | |||
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 | 0050361: Add a check to automatically restart a cashup if current one is already processed | |||||||
Description | We have detected that sometimes there is a problem with the state persistence and as a result after completing a cashup, the cashup that was just completed remains in the status of the application. Then, the next time the cashier logs in he will keep using that cashup, and he will end up with an error in the backend after trying to process a cashup that has already been processed. We are still trying to find the root cause (state not being persisted properly), but in this issue we mean to prevent the duplicated cashup processing by checking if the user is working with a processed cashup and creating and in that case creating a new one | |||||||
Steps To Reproduce | We are not able to reproduce the issue unless we: - Increase the throttle of the state persistence from 100ms to 10s - Remove the state persistence flush we do after each cashup completion Doing that, if the user closes or refreshes the application right after completing the cashup, the completion will not be persisted and the next time the user logs in he will keep using the previous version of the cashup | |||||||
Tags | No tags attached. | |||||||
Attached Files | ||||||||
Relationships [ Relation Graph ] [ Dependency Graph ] | |||||||||||||||||
|
Notes | |
(0141427) hgbot (developer) 2022-09-27 23:53 |
Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/932 [^] |
(0141457) hgbot (developer) 2022-09-28 18:16 |
Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/412 [^] |
(0141459) hgbot (developer) 2022-09-28 23:25 |
Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/932 [^] |
(0141460) hgbot (developer) 2022-09-28 23:25 |
Directly closing issue as related merge request is already approved. Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal [^] Changeset: fa6419f705344ddb90c4f0b45fb38f65e604c07c Author: Augusto Mauch <augusto.mauch@openbravo.com> Date: 28-09-2022 18:18:47 URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/commit/fa6419f705344ddb90c4f0b45fb38f65e604c07c [^] Fixes ISSUE-50361: Prevents duplicated cashup In order to prevent a duplicated cashup if there has been a problem persisting the last cashup completion, we will now detect the case when the current cashup has already been processed in the backend, and in that case we will start a new one from scratch in the backend. --- M web/org.openbravo.retail.posterminal/app/model/business-object/cashup/actions/InitCashup.js --- |
(0141461) hgbot (developer) 2022-09-28 23:25 |
Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core [^] Changeset: b78c185814b1d2099f455740df582e6fc8e68fef Author: Augusto Mauch <augusto.mauch@openbravo.com> Date: 28-09-2022 18:17:30 URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/commit/b78c185814b1d2099f455740df582e6fc8e68fef [^] Related to ISSUE-50361: Extracts TerminalLog.addLog to utility function --- M web/org.openbravo.mobile.core/app/model/business-object/terminal-log/TerminalLogUtils.js M web/org.openbravo.mobile.core/app/model/business-object/terminal-log/actions/AddLog.js --- |
(0141462) hgbot (developer) 2022-09-28 23:25 |
Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.mobile.core/-/merge_requests/412 [^] |
Issue History | |||
Date Modified | Username | Field | Change |
2022-09-27 23:49 | AugustoMauch | New Issue | |
2022-09-27 23:49 | AugustoMauch | Assigned To | => Retail |
2022-09-27 23:49 | AugustoMauch | Triggers an Emergency Pack | => No |
2022-09-27 23:49 | AugustoMauch | Assigned To | Retail => AugustoMauch |
2022-09-27 23:49 | AugustoMauch | Status | new => scheduled |
2022-09-27 23:53 | hgbot | Note Added: 0141427 | |
2022-09-28 18:16 | hgbot | Note Added: 0141457 | |
2022-09-28 23:25 | hgbot | Resolution | open => fixed |
2022-09-28 23:25 | hgbot | Status | scheduled => closed |
2022-09-28 23:25 | hgbot | Note Added: 0141459 | |
2022-09-28 23:25 | hgbot | Fixed in Version | => RR22Q4 |
2022-09-28 23:25 | hgbot | Note Added: 0141460 | |
2022-09-28 23:25 | hgbot | Note Added: 0141461 | |
2022-09-28 23:25 | hgbot | Note Added: 0141462 | |
2023-04-20 16:29 | malsasua | Relationship added | related to 0052052 |
Copyright © 2000 - 2009 MantisBT Group |