Project:
| View Issue Details[ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
| ID | ||||||||
| 0054743 | ||||||||
| Type | Category | Severity | Reproducibility | Date Submitted | Last Update | |||
| defect | [Retail Modules] Web POS | major | have not tried | 2024-02-22 12:26 | 2024-04-18 11:58 | |||
| Reporter | marvintm | View Status | public | |||||
| Assigned To | sreehari | |||||||
| Priority | normal | Resolution | fixed | Fixed in Version | RR24Q3 | |||
| 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 | 0054743: When the state persistence fails, the information of the cashup becomes outdated, and this can lead to data corruption | |||||||
| Description | When the state persistence fails, the information of the cashup will be retrieved from an outdated state, and as it is the base for subsequent sales, the aggregated information can then become corrupted, as it will be missing the information from previous sales. Although the final solution will be to fix the persistence issues, there is a simple mitigation mechanism that we can implement, and it would then avoid the problem in many cases, thus avoiding the unnecessary problems that are currently happening randomly in the customers. | |||||||
| Steps To Reproduce | The problem can only be reproduced in when the state persistence fails, and the terminal is opened with an outdated cashup information that is missing some sales. | |||||||
| Proposed Solution | We can use the lastCashupReport property to identify a case that is impossible to happen unless the persistence failed. The main idea would be, when the POS login happens, to validate the lastCashupReportDate in the client against the one in the frontend. In case they are the same, everything is fine. In case the client is more recent that the backend, then it is also fine, as maybe there are errors while importing pending to be processed, or some message not yet fully processed in the backend. However, when the backend is more recent than the frontend, we know for sure something wrong happened, because under normal conditions this cannot happen as this property comes from the client side. So in this case, we need to regenerate the cashup information, from the information we currently have in the backend. | |||||||
| Tags | No tags attached. | |||||||
| Attached Files | ||||||||
 Relationships [ Relation Graph ]
[ Dependency Graph ]
|
|
 Relationships |
|
Notes |
|
|
(0162761) hgbot (developer) 2024-04-02 07:45 |
Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/1522 [^] |
|
(0163361) hgbot (developer) 2024-04-18 11:58 |
Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/merge_requests/1522 [^] |
|
(0163362) hgbot (developer) 2024-04-18 11:58 |
Directly closing issue as related merge request is already approved. Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal [^] Changeset: 93ec5386b5cd9213776123ecb347b178c35a384e Author: Sreehari Venkataraman <sreehari.venkataraman.ext@openbravo.com> Date: 18-04-2024 06:41:09 URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.retail.posterminal/-/commit/93ec5386b5cd9213776123ecb347b178c35a384e [^] Fixes ISSUE-54743: Added postHook for initCashup Action *used cashupDate for validating the cashup info *changed cashUpReportDate & cashUpCreationDate accordingly *this hooks checks the client & server lastcashup time *and if client cashup time is older than server cashup time *then, we regenerate the cashup data from the back office with the not processed data *added log message for overriding cashup *fixed test failures --- M src/org/openbravo/retail/posterminal/UpdateCashup.java M src/org/openbravo/retail/posterminal/master/Cashup.java M web-test/model/business-object/cashup/Cashup-InitCashup-ActionPreparation.test.js M web-test/model/business-object/cashup/Cashup-initCashup-StateAction-fromLocal.test.js M web-test/model/business-object/cashup/Cashup-updateCashupFunction-afterTicketDone.test.js M web-test/model/business-object/cashup/test-data/cashupAfterComplete.js M web-test/model/business-object/cashup/test-data/cashupAfterTicketDone.js M web-test/model/business-object/cashup/test-data/cashupCreatedFromScratch.js M web-test/model/business-object/cashup/test-data/cashupCreatedFromScratchWithoutLastCashupPayments.js M web-test/model/business-object/cashup/test-data/cashupMessageSharedPayments.js M web-test/model/business-object/cashup/test-data/messagesAfterCompleteCashupSharedPayments.js M web-test/model/business-object/cashup/test-data/ticketAfterTicketDone.js M web/org.openbravo.retail.posterminal/app/model/business-object/cashup/CashupUtils.js M web/org.openbravo.retail.posterminal/app/model/business-object/cashup/actions/InitCashup.js --- |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2024-02-22 12:26 | marvintm | New Issue | |
| 2024-02-22 12:26 | marvintm | Assigned To | => Retail |
| 2024-02-22 12:26 | marvintm | Triggers an Emergency Pack | => No |
| 2024-02-22 13:38 | Practics | Issue Monitored: Practics | |
| 2024-03-06 11:06 | jorgewederago | Status | new => acknowledged |
| 2024-03-08 12:36 | sreehari | Assigned To | Retail => sreehari |
| 2024-03-08 12:36 | sreehari | Status | acknowledged => scheduled |
| 2024-04-02 07:45 | hgbot | Note Added: 0162761 | |
| 2024-04-18 11:58 | hgbot | Resolution | open => fixed |
| 2024-04-18 11:58 | hgbot | Status | scheduled => closed |
| 2024-04-18 11:58 | hgbot | Note Added: 0163361 | |
| 2024-04-18 11:58 | hgbot | Fixed in Version | => RR24Q3 |
| 2024-04-18 11:58 | hgbot | Note Added: 0163362 | |
|
Issue History |
| Copyright © 2000 - 2009 MantisBT Group |
 |