Odoo Changelog — 2023-05-19

Friday, May 19, 2023

27 changes · master

New Features(2)

New functionality added to Odoo

Run watched tours in a regular (headful) browser

CoremastercoreMedium

Odoo’s automated tour tests can now be watched in a regular visible browser, making it easier to investigate issues that depend on normal mouse behavior, such as drag and drop. The testing browser is now started fresh for each tour run, improving isolation and simplifying cleanup, with some internal browser setup streamlined for efficiency.

Original PR description

Chrome's screencast / remote view (in the remote devtools) is apparently *designed* for touch emulation / simulation (https://crbug.com/1410433), which is not convenient when trying to debug…

Chrome's screencast / remote view (in the remote devtools) is apparently *designed* for touch emulation / simulation (https://crbug.com/1410433), which is not convenient when trying to debug mouse-bound issues in a tour (e.g. drag&drop problems).

This can be solved by just running the browser normally if the user wants to watch, in which case the user can also use their normal devtools.

However this doesn't work with the current architecture, where the browser is lazy-started one per test class and reused between `browse_js` calls.

Scrap that, run and shut down the browser entirely for every `browse_js` calls that way it's possible to use entirely different browser. This also simplifies the cleanup phase somewhat as we don't have a persistent profile directory to try and reset, instead every `browse_js` has its own.

Notes:

- `--no-first-run` causes tours to not run at all on my machine, in a non-headless browser
- also moved a bunch of other flags which seem to be mostly for automated annoyances to headless only
- left extensions for now, not entirely sure which is the right one, since we're running with fresh profiles I would assume there's no extensions anyway

#testing#browser#debugging#tours

[IMP] pos_self_order: Allow ordering from web app

PR #121029

Coremasterpos_self_orderpoint_of_saleHigh impact

Restaurant customers can now scan a table QR code, browse the menu, customize items, add notes, and submit orders directly from the self-service web app. Orders appear in the regular POS session for staff to review and send to preparation, while payment continues through existing in-person methods.

Original PR description

Currently from the pos_self_order app a customer can only view the menu. This PR adds the option to order items. A customer of the restaurant will now be able to scan a qr code on their table, and…

This version does not support online payment. This means that the customer will still have to pay by the usual methods.

The pos can be configured such that a customer can add items to an existing order. For example, ordering a second coffee will result in an update of the existing pos order containing the first coffee. Alternatively, the pos can be configured such that each order made from the web app results in a new pos order. Orders made from the self order app will be placed in the same pos session as regular orders. Once a customer orders from the self order app, a new order will appear in the pos app. Thus, a waiter will be able to quickly see all the orders placed by customers from the self order app. He/She will then be able to send the order to the preparation display. This step has to be done manually.

In the interest of security, each table now has an associated access token. It is included in url that the customer gets from the qr code. When sending the order, the self order app also sends back to the server this access token. The server will only process the order if it receives a valid access token. When placing an order, the server will respond with the pos_reference and access_token of the created order. The web app will keep this data and will send it back to the
server as a proof of ownership in the event that it intends to get the latest state of the order or to update it. The server will only reveal information about an existing order when the request contains a valid pair of pos_reference and access_token.

Task: 3058586

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Improvements(2)

Enhancements to existing features

[IMP] core: introduce OrderedWeakSet

PR #121604

Coremasterbase

This update makes internal transaction handling process environments in a predictable order, avoiding inconsistent behavior that could vary between system runs. It also adds tests to confirm the new behavior remains stable without affecting cleanup of unused resources.

Original PR description

The Weakset Used for envs can lead to unpredictible behaviour when calling flush on the transaction because we iterate on the `envs`.

Since WeakSet.data is a set, the iteration will depends on the python hash seed.

This commit proposes to replace Transaction.envs.data by an OrderedSet to solve this issue.

Some test demonstrates that it does not affect the garbage collection and that the order is now deterministic.

The question to now if we should reverse the envs to find the most suitable envs remains.

#transactions#stability#deterministic

Other(23)

Miscellaneous changes

[FW][IMP] unreserve only quantity required if available quantity is less than quantity required when action_done on stock move.

PR #121724

Coremasterstock

**Current behavior before PR:** Inventory quantity 4 Reserved quantity 3 Available quantity 1 If i confirm a stock move of 2 pieces, it will unreserve ALL the stock moves of the product until the quantity of "2" is reached. **Desired behavior after PR is merged:** It will unreserve only the pieces that are required minus the available quantity not reserved , in this case 2 (new stock move) - 1 (available quantity) = 1 --- I confirm I have signed the CLA and re

Original PR description

**Current behavior before PR:**

Inventory quantity 4
Reserved quantity 3
Available quantity 1
If i confirm a stock move of 2 pieces, it will unreserve ALL the stock moves of the product until the quantity of "2" is reached.


**Desired behavior after PR is merged:**

It will unreserve only the pieces that are required minus the available quantity not reserved , in this case 2 (new stock move) - 1 (available quantity) = 1










---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#119999

Chrome's screencast / remote view (in the remote devtools) is apparently *designed* for touch emulation / simulation (https://crbug.com/1410433), which is not convenient when trying to debug mouse-bound issues in a tour (e.g. drag&drop problems). This can be solved by just running the browser normally if the user wants to watch, in which case the user can also use their normal devtools. However this doesn't work with the current architecture, where the browser is lazy-started one per test class and reused between `browse_js` calls. Scrap that, run and shut down the browser entirely for every `browse_js` calls that way it's possible to use entirely different browser. This also simplifies the cleanup phase somewhat as we don't have a persistent profile directory to try and reset, instead every `browse_js` has its own. Notes: - `--no-first-run` causes tours to not run at all on my machine, in a non-headless browser - also moved a bunch of other flags which seem to be mostly for automated annoyances to headless only - left extensions for now, not entirely sure which is the right one, since we're running with fresh profiles I would assume there's no extensions anyway

Currently from the pos_self_order app a customer can only view the menu. This PR adds the option to order items. A customer of the restaurant will now be able to scan a qr code on their table, and navigate to a website where they will be able to order items from the pos. The customer can select product variants and add a specific notes for each of the ordered products. This version does not support online payment. This means that the customer will still have to pay by the usual methods. The pos can be configured such that a customer can add items to an existing order. For example, ordering a second coffee will result in an update of the existing pos order containing the first coffee. Alternatively, the pos can be configured such that each order made from the web app results in a new pos order. Orders made from the self order app will be placed in the same pos session as regular orders. Once a customer orders from the self order app, a new order will appear in the pos app. Thus, a waiter will be able to quickly see all the orders placed by customers from the self order app. He/She will then be able to send the order to the preparation display. This step has to be done manually. In the interest of security, each table now has an associated access token. It is included in url that the customer gets from the qr code. When sending the order, the self order app also sends back to the server this access token. The server will only process the order if it receives a valid access token. When placing an order, the server will respond with the pos_reference and access_token of the created order. The web app will keep this data and will send it back to the server as a proof of ownership in the event that it intends to get the latest state of the order or to update it. The server will only reveal information about an existing order when the request contains a valid pair of pos_reference and access_token. Task: 3058586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

The Weakset Used for envs can lead to unpredictible behaviour when calling flush on the transaction because we iterate on the `envs`. Since WeakSet.data is a set, the iteration will depends on the python hash seed. This commit proposes to replace Transaction.envs.data by an OrderedSet to solve this issue. Some test demonstrates that it does not affect the garbage collection and that the order is now deterministic. The question to now if we should reverse the envs to find the most suitable envs remains.

# Current behavior: Connections for outgoing email servers using Outlook/Office365 or Gmail accounts will establish an OAuth2 authentication for the smtp server. Through the `ir_mail_server` form view, one can fetch the necessary tokens by logging in into their Microsoft/Gmail account. Not specifying an username (`smtp_user`) on the `ir_mail_server` record will not produce an error while fetching those tokens. But when trying to test the connection or use that server to send an email, even if the FROM header is correctly set (i.e. the account email address authorized to sent emails), the smtp connection will fail. This is due to the fact that when `smtp_user == False`, the respective method `_generate_outlook_oauth2_string` or respectively `_generate_oauth2_string` will not be called and send the necessary OAuth2 string when sending an email through the smtp connection. This will lead to a `5.7.57 Client not authenticated to send mail.` error. # After this change: Add specific UserErrors that get called if `smpt_user == False` before the actions in `open_google_gmail_uri` and `open_microsoft_outlook_uri` get called. This forces the user to input a `smpt_user` (field Username) before the login page for OAuth2 gets called to fetch the tokens. Note: there is no check if the user inputs the right username, only that the field is not empty. So it is still possible to input an invalid username. opw-3268246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121700 Forward-Port-Of: odoo/odoo#121048

Before this commit, links scrolling to an anchor with a special character did not work and displayed a traceback. The issue was that to check that the anchor is valid, we don't need to check that the anchor is a valid url as we have been doing since these commits [1], [2]. But we only need to check if the jQuery selector is valid to correctly target the element to which the page must scroll. Indeed, the anchor widget returns stuff like 'ok%C3%A9%25' when typing 'oké%' wich is not valid jQuery selector. It has to be encoded to '#ok\\%C3\\%A9\\%25' to be valid and that's what this commit does. Also, this commit detect if the success URL of the redirect of a from is the current page to perform a scroll to the anchor instead of a redirect. Also, before this commit, the page froze when we clicked on the "submit" button of a form that redirected to an anchor that did not exist. [1]: https://github.com/odoo/odoo/commit/0abfaeda96c2eaa868cc7fc5fa1926dfa90fc420 [2]: https://github.com/odoo/odoo/commit/b492bde6a121be1c15ed90ce0827fcfd72a12f5c task-2172312 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121463 Forward-Port-Of: odoo/odoo#82059

Before this commit this tour was often failing. It seems to be because there were some requests still being executed / received after the test was marked as successful and browser getting killed. According to the logs, even when the tour is actually not failing, there is still some unexpected requests going on. With this commit, saving and waiting the edit mode to be exited will prevent all those requests issues, as it seems like the requests done after exiting edit mode are all awaited before marking the test as successfull. == Before the fix success case == - Tour snippet_editor_panel_options on step: 'The text toolbar should still be visible, and the text still selected. (trigger: #oe_snippets .o_we_customize_panel > #o_we_editor_toolbar_container)' - GET /website/static/src/img/snippets_options/header_template_default.svg HTTP/1.1" 200 - 0 0.000 0.003 - [Same GET for 10 other header templates] - test successful - Session expired - POST /website/theme_customize_data_get HTTP/1.1" 200 - 3 0.001 0.003 - [2 lines above x10] - Deleting cookies and clearing local storage - Navigating to: "about:blank" - Navigation result: {'frameId': 'A538603CC37A4E9EBA99B8624C1CD34E', 'loaderId': '9187051DD3D9477FA4EDEB1A544D584E'} - Waiting for frame 'A538603CC37A4E9EBA99B8624C1CD34E' to stop loading - waiting for threads: [<Thread(odoo.service.http.request.139669352166976, started 139669352166976)>] == Before the fix error case == - Tour snippet_editor_panel_options on step: 'The text toolbar should still be visible, and the text still selected. (trigger: #oe_snippets .o_we_customize_panel > #o_we_editor_toolbar_container)' - GET /website/static/src/img/snippets_options/header_template_sidebar.svg HTTP/1.1" 200 - 0 0.000 0.004 - [Same GET for 10 other header templates] - test successful - GET /web/static/img/smile.svg HTTP/1.1" 200 - 0 0.000 0.001 - GET /web/static/img/spin.svg HTTP/1.1" 200 - 0 0.000 0.001 - Failed to fetch - Asking for screenshot - Trying to set result to failed (TypeError: Failed to fetch) but found the future settled (<Future at 0x7f8fa1a25120 state=finished returned bool>) - Deleting cookies and clearing local storage - Screenshot in: /data/build/tests/36222061-master-all_no_autotag/screenshots/sc_20230513_220042_739175_TestUi.png - Navigating to: "about:blank" - Navigation result: {'frameId': 'E1A779132E972A440E5FE892BBBC9FEC', 'loaderId': '822ACED443DB0C84F57DD4A1FF451D5B'} - Waiting for frame 'E1A779132E972A440E5FE892BBBC9FEC' to stop loading - waiting for threads: [<Thread(odoo.service.http.request.140254747010624, started 140254747010624)>] == After the fix case == - Tour snippet_editor_panel_options on step: 'iframe body:not(.editor_enable)' - GET /web/static/img/spin.svg HTTP/1.1" 200 - 0 0.000 0.003 - POST /website/theme_customize_data_get HTTP/1.1" 200 - 8 0.002 0.035 - [Many other POST/GET requests] - test successful - Deleting cookies and clearing local storage - Navigating to: "about:blank" - Navigation result: {'frameId': '4B87BC8A50A3FEBD7D508394DD5BDB19', 'loaderId': '7CCB3B6434B52B456A1AA470C3CFA1BF'} - Waiting for frame '4B87BC8A50A3FEBD7D508394DD5BDB19' to stop loading - waiting for threads: [<Thread(odoo.service.http.request.139744500471360, started 139744500471360)>] runbot-15312 Forward-Port-Of: odoo/odoo#121635

New Features(2)

Run watched tours in a regular (headful) browser

[IMP] pos_self_order: Allow ordering from web app

Improvements(2)

[IMP] core: introduce OrderedWeakSet

Other(23)

[FW][IMP] unreserve only quantity required if available quantity is less than quantity required when action_done on stock move.

New Features(2)

Run watched tours in a regular (headful) browser

[IMP] pos_self_order: Allow ordering from web app

Improvements(2)

[IMP] core: introduce OrderedWeakSet

Other(23)

[FW][IMP] unreserve only quantity required if available quantity is less than quantity required when action_done on stock move.

[IMP] mail: allow to close the attachment previewer with bus event

[FW][FIX] web_editor: convert color opacity to be compatible with PIL Image color

[FW][FIX] web_editor: impossible to select all in empty paragraph.

[FW][FIX] microsoft_outlook, google_gmail: require username for OAuth2

[FW][FIX] website, website_form: fix anchor link redirects

[FW][FIX] loyalty : unarchive archived rules and rewards

[FW][FIX] website: increase timeout

[FW][FIX] account: epd lines duplication

[FW][FIX] website: prevent race condition on snippet_editor_panel_options

[FW][FIX] point_of_sale: fix indeterministic order of payment methods

[FW][FIX] web_editor: entering a hax color trigger traceback

[FW][IMP] account: deferred management

[FW][FIX] mrp{ ,_subcontracting}, purchase_mrp: missing days when calculate DTPMO

[FW][FIX] account: cash rounding

[FW][FIX] mrp_mps: ignore DTPMO when set indirect demand

[FW][IMP] account_{accountant,asset,reports},sale_subscription,*: deferred management

[FW][FIX] web_map: text contrast on buttons

[FW][FIX] hr_work_contract_attendance: use attendance

[FW][FIX] l10n_co_reports: Translation json problem

[FW][FIX] l10n_de_pos_cert: escape line breaks in product name

[FW][ADD] l10n_cl_edi_website_sale:

[FW][FIX] approvals: prevent attachment deletion

[FW][FIX] appointment: inserting appointment should insert inside list