Skip to Content
  2. Mailing Lists
  3. Contributors
  4. Re: Very simple POS Tests go to backoffice

Archives

Contributors

Re: Very simple POS Tests go to backoffice

Re: Very simple POS Tests go to backoffice

Re: Very simple POS Tests go to backoffice

Dear community,

first of all I apologize because I am not good at bureaucracy. On the other hand, I am not very clear about the previous message. If the issue is that I am posting in the github discussion forum and here at the same time, it is because I interpreted that it had to be done this way reading this thread. Github does not have an alert system to subscribe to threads. If what the previous message refers to is that I have spoken twice about the tests, it is because I left the first thread as solved because the colleague who answered clarified the doubts I had and I understand that this matter should be opened in a new thread.

I take this opportunity to confirm that I still have doubts. I am not sure how to confirm that the session is closed and there is no thread or cache that is messing up the tests.


El lun, 27 mar 2023 a las 17:47, Pedro M. Baeza (<notifications@odoo-community.org>) escribió:
Please don't cross post. Write in one place or the other, not in both.

Regards.

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

by Fernando La Chica - 09:26 - 27 Mar 2023

Reference

  • Very simple POS Tests go to backoffice
    Content:

    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.
    by Fernando La Chica - 05:41 - 27 Mar 2023