Very simple POS Tests go to backoffice

[flachica]

I have a very simple test. It contains only two steps:

1º Wait for the loading to finish

{
    content: "Test pos_order_to_sale_order: Waiting for loading to finish",
    trigger: "body:not(:has(.loader))",
},

2º Click on the login button that appears because I have pos_hr installed.

{
    content: 'click login button',
    trigger: '.login-overlay .login-button.select-cashier',
    run: () => {}
},

Well, my Tour starts like any Tour for POS, visiting the URL "/pos/ui?config_id=X" where X is a pos_config. When it finishes loading, instead of showing the POS UI it goes to 127.0.0.1:8069/web#action=point_of_sale.action_client_pos_menu

I can see than first step succeeded Tour PosTicketActions: step 'Test pos_order_to_sale_order: Waiting for loading to finish (trigger: body:not(:has(.loader)))' succeeded

What seems very strange to me is that before the first step in the log it appears

Tour Manager is ready. running_tour=PosTicketActions

And just after the success and before executing the second step also appears the same message.

Tour Manager is ready. running_tour=PosTicketActions

It makes me think that for some reason, the "Ready" event of the Tour is fired in duplicate or that it doesn't clear the cache properly for some issue. As if I'm double subscribed to this event.

This URL is the one you go to when more than one POS tab is open. The second one visits the POS UI but the first one that stays in the background goes to the backoffice.

I have made sure that the user profiles and cookies are being removed from the headless that opens automatically when the start_tour is opened with watch=True. If I run the tests with watch=False the same thing happens, it leaves the POS UI and goes to Backoffice.

[yajo]

trigger: "body:not(:has(.loader))",

I'm not sure if this is the problem, but this selector seems very prone to race conditions. Imagine the POS loads and then, later, some JS sets the loader class to the body. The trigger could fire before the other JS, causing a race condition.

To be able to better debug tours, there are a few techniques:

1. Use --screencasts and --screenshots CLI options to record a video of failed tours.
2. Make sure the selector is specific to something that won't trigger a race condition.
3. Always run tours with --workers=0.

[legalsylvain]

@ivantodorovich : your expertise would be appreciated around here.

[flachica]

Thanks for your suggestions. Finally I know what the problem was.

My tests, in addition to checking the openness of the UI should check certain access permissions to new buttons that I implemented. Also, that the python test method do config_id.open_ui. It is called just before the start_tour, and overwrites the user that I put in the setUpClass. That is, all test_ methods use Odoobot by default.

I noticed this redirect this Odoo redirect. That's why it always went to the backoffice

So to do the test it was enough to do self.config_id.with_user(self.env.user).open_ui()