Project:
View Revisions: Issue #56730 | [ Back to Issue ] | ||
Summary | 0056730: Management of inconsistent application state should be properly addressed in EnyoPOS | ||
Revision | 2024-10-10 11:54 by AugustoMauch | ||
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 [^] |
||
Revision | 2024-10-10 11:52 by AugustoMauch | ||
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. |
Copyright © 2000 - 2009 MantisBT Group |