0056730: Management of inconsistent application state should be properly addressed in EnyoPOS

Openbravo Issue Tracking System - POS2

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0056730

POS2

Core

public

2024-10-10 11:52

2024-10-24 07:54

Reporter

AugustoMauch

Assigned To

ranjith_qualiantech_com

Priority

normal

Severity

major

Reproducibility

have not tried

Status

scheduled

Resolution

open

Platform

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

Summary

0056730: Management of inconsistent application state should be properly addressed in EnyoPOS

Description

From time to time, the application state gets inconsistent, apparently not reflecting the current state of the application but a previous one.

We looking for those inconsistencies on a case-to-case basis, and introducing mitigation measures on a case-to-case basis as well.

This mechanism should be improved, so that if any inconsistency is found, all the application state modules should be re-initialized properly.

Note, the backend infra to support this, and the frontend infra for core2 applications has already been developed here: https://issues.openbravo.com/view.php?id=56377. [^] This issue should only address the missing piece, which is to consume the backend API during the login process to check the validity of the state, and reset the state accordingly if it is not valid. Similar to what is done in core2 applications here: https://gitlab.com/openbravo/product/pmods/org.openbravo.core2/-/merge_requests/1604/diffs#a9f9ead2b85fe0a0ffdef835b186359c141b3b79_41_42 [^]

Steps To Reproduce

Proposed Solution

Additional Information