Openbravo Issue Tracking System - POS2
View Issue Details
0046059POS2Corepublic2021-03-11 18:252021-07-15 12:42
lorenzofidalgo 
jarmendariz 
normalminoralways
closedno change required 
5
 
 
Automated tests
https://gitlab.com/openbravo/product/pmods/org.openbravo.core2/-/commit/373006f5633b58705817e1ef809f8fdf120f8f4e [^]
No
0046059: Typing inside input fields is broken in automated tests
Using basic Cypress typing functionality is broken now, due to the New POS is behaving badly treating how text is written in the login input fields (it seems some action is being performed after typing the text inside the input field that induces a clear of that input field).
I attach the following 2 videos with the specific behaviours (pre and post issue) and the context with the specific changesets narrowing down the cause of this issue:
https://drive.google.com/file/d/1FDkndHEoVeX_Y0SeTAjER8wRoiraUEU0/view?usp=sharing [^]
https://drive.google.com/file/d/1DgHqyid3XOWRcc1dpLPf7eSjWzfHeLGl/view?usp=sharing [^]


Since basic functionalities such as cy.get('#user').type(Cypress.env('terminalUser')); can not be performed properly, this situation is blocking the executions of the cypress automated tests.
To reproduce easily this issue, a Cypress context with the automated tests is required.
0-With a Cypress context properly set up, launch the Initial.spec.js tests from POS2 module. Path: .../openbravo/modules/org.openbravo.pos2/web-jspack/org.openbravo.pos2/src-test/cypress/integration/Components/Initial.spec.js
1-Once the test is launched, realise the input fields are sometimes clearing the input field content, inducing the test to fail. (It was working properly previous to this merge).
No tags attached.
Issue History
2021-03-11 18:25lorenzofidalgoNew Issue
2021-03-11 18:25lorenzofidalgoAssigned To => Retail
2021-03-11 18:25lorenzofidalgoRegression level => Automated tests
2021-03-11 18:25lorenzofidalgoRegression introduced by commit => 373006f5633b58705817e1ef809f8fdf120f8f4e
2021-03-11 18:25lorenzofidalgoTriggers an Emergency Pack => No
2021-03-11 18:32lorenzofidalgoRegression introduced by commit373006f5633b58705817e1ef809f8fdf120f8f4e => https://gitlab.com/openbravo/product/pmods/org.openbravo.core2/-/commit/373006f5633b58705817e1ef809f8fdf120f8f4e [^]
2021-04-29 10:10guilleaerNote Added: 0127641
2021-04-29 10:10guilleaerAssigned ToRetail => lorenzofidalgo
2021-04-29 10:10guilleaerStatusnew => feedback
2021-04-29 10:29lorenzofidalgoNote Added: 0127648
2021-04-29 10:30lorenzofidalgoAssigned Tolorenzofidalgo => Retail
2021-04-29 10:30lorenzofidalgoStatusfeedback => new
2021-04-29 10:46guilleaerResolution time => 1622239200
2021-04-29 10:46guilleaerAssigned ToRetail => platform
2021-04-29 10:46guilleaerPriorityimmediate => none
2021-04-29 10:46guilleaerSeveritymajor => minor
2021-04-29 10:46guilleaerStatusnew => acknowledged
2021-05-07 15:00guilleaerPrioritynone => normal
2021-05-19 09:30jarmendarizAssigned Toplatform => jarmendariz
2021-05-19 09:30jarmendarizStatusacknowledged => scheduled
2021-06-01 19:20guilleaerResolution time1622239200 => 1624917600
2021-07-15 12:42dmiguelezNote Added: 0130507
2021-07-15 12:42dmiguelezStatusscheduled => closed
2021-07-15 12:42dmiguelezResolutionopen => no change required

Notes
(0127641)
guilleaer   
2021-04-29 10:10   
Is still a problem?
(0127648)
lorenzofidalgo   
2021-04-29 10:29   
The problem is still there, yes.
Since the problem is induced by the BarcodeScanner, a temporal workaround that disables it is being used at the beginning of every automated tests to be able to continue working for the moment: "win.OB.App.BarcodeScanner.disable();"
(0130507)
dmiguelez   
2021-07-15 12:42   
The tests are already using a workaround to bypass this problem and from the product point of view we are comfortable with it.