Openbravo Issue Tracking System - POS2
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0057951POS2POSpublic2025-02-11 17:592025-03-18 11:09
Reporterjfvaringot 
Assigned ToAugustoMauch 
PriorityhighSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOS5OS Version
Product Version 
Target VersionFixed in Version 
Merge Request Statusapproved
Review Assigned To
OBNetwork customerOBPS
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary0057951: POS 2 - POS is frozen after automatic logout out, when manual action to logout is in progress
DescriptionREPRODUCED ON 24Q4 and 25Q1 and MASTER

When the automatic logout (timeout) is set, that the user started to manually log out when he is logged out automatically, the POS is frozen at login.
Steps To ReproduceSet an automatic logout on back :
1. Preference 'Web POS Session Timeout' (for example 30s)
2. Preference 'Web POS Session Timeout - Alert Lead Time' (for example 10s)

On POS :
1. log in
2. click on deconnexion
3. do not disconnect and wait for the automatic logout
4. let the POS disconnects the user
5. log in

-> the POS is frozen
Proposed SolutionAffter having been disconnected, the user can connect again when login again.
Additional Information
TagsNo tags attached.
Relationships
depends on backport 005827425Q1 closed meriem_azaf POS 2 - POS is frozen after automatic logout out, when manual action to logout is in progress 
depends on backport 005827524Q4 closed meriem_azaf POS 2 - POS is frozen after automatic logout out, when manual action to logout is in progress 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2025-02-11 17:59jfvaringotNew Issue
2025-02-11 17:59jfvaringotAssigned To => Retail
2025-02-11 17:59jfvaringotTriggers an Emergency Pack => No
2025-02-12 09:11inaki_azkonobietaOBNetwork customer => OBPS
2025-02-12 09:12inaki_azkonobietaIssue Monitored: inaki_azkonobieta
2025-02-12 09:42guillermogilAssigned ToRetail => Triage Platform Base
2025-02-25 16:58jfvaringotNote Added: 0176129
2025-02-25 16:59jfvaringotNote Edited: 0176129bug_revision_view_page.php?bugnote_id=0176129#r29290
2025-03-04 13:47AugustoMauchNote Added: 0176433
2025-03-04 13:48AugustoMauchNote Added: 0176434
2025-03-04 14:38hgbotMerge Request Status => open
2025-03-04 14:38hgbotNote Added: 0176436
2025-03-04 20:25AugustoMauchStatusnew => scheduled
2025-03-04 20:25AugustoMauchAssigned ToTriage Platform Base => AugustoMauch
2025-03-11 18:24hgbotMerge Request Statusopen => approved
2025-03-11 18:24hgbotNote Added: 0176687
2025-03-11 18:24hgbotResolutionopen => fixed
2025-03-11 18:24hgbotStatusscheduled => closed
2025-03-11 18:24hgbotFixed in Version => 25Q2
2025-03-11 18:24hgbotNote Added: 0176688
2025-03-18 11:08meriem_azafStatusclosed => new
2025-03-18 11:08meriem_azafResolutionfixed => open
2025-03-18 11:08meriem_azafFixed in Version25Q2 =>
2025-03-18 11:08meriem_azafStatusnew => scheduled
2025-03-18 11:09meriem_azafStatusscheduled => resolved
2025-03-18 11:09meriem_azafResolutionopen => fixed
2025-03-18 11:09meriem_azafStatusresolved => closed

Notes
(0176129)
jfvaringot   
2025-02-25 16:58   
(edited on: 2025-02-25 16:59)
2nd scenario :
On back-office, set your touchpoint type in order to display the Receipt delivery method on POS, after the payment.

On POS :
1. do a ticket
2. click on pay and process to payment
3. when the Receipt delivery pop-up is display, wait for the log-out
4. let the POS disconnects the user
5. log in

-> the POS is frozen
(0176433)
AugustoMauch   
2025-03-04 13:47   
Another way to reproduce:

On POS :
1. add a line to the ticket
2. click on Delete Ticket. A popover will be displayed because a ticket with lines is being removed.
3. do not close the popover, wait for the log-out
4. let the POS disconnects the user
5. log in
(0176434)
AugustoMauch   
2025-03-04 13:48   
The problem occurs because when the automatic logout took place, an action was in execution (i.e. DeleteTicket, with the latest steps to reproduce).

When logging in, the action will still count as in execution in OB.App.State.getState().UI.userActions.inProgressStack, so the user action scrim will be on top.
(0176436)
hgbot   
2025-03-04 14:38   
Merge Request created: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/pmods/org.openbravo.core2/-/merge_requests/1809 [^]
(0176687)
hgbot   
2025-03-11 18:24   
Merge request merged: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/pmods/org.openbravo.core2/-/merge_requests/1809 [^]
(0176688)
hgbot   
2025-03-11 18:24   
Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/pmods/org.openbravo.core2 [^]
Changeset: 0c349ff25d70df3be2ece5d48dfd298772a66286
Author: Augusto Mauch <a.mauch@orisha.com>
Date: 11-03-2025 17:24:39
URL: https://gitlab.com/orisha-group/bu-commerce/openbravo/product/pmods/org.openbravo.core2/-/commit/0c349ff25d70df3be2ece5d48dfd298772a66286 [^]

Fixes ISSUE-57951: Screen is not locked after automatic logout

The problem was that if the automatic logout took place while a user action was blocked because of a dialog
in a prehook, the user action stack was never cleaned, and when the user logged in again, the application
would think the user action was still in execution, showing the user action scrim and blocking the screen.

Now, when the login screen is rendered for the first time, the user action stack will be reset.

---
M web-jspack/org.openbravo.core2/src/components/AuthProvider/LoginScreen.jsx
M web-jspack/org.openbravo.core2/src/components/AuthProvider/__test__/LoginScreen.test.jsx
M web-jspack/org.openbravo.core2/src/components/AuthProvider/stories/LoginScreen.stories.jsx
---