Friday, May 30, 2025
24 changes · 18.0
Enhancements to existing features
The Knowledge app now hides the expand caret when an article has no child pages. This reduces visual clutter and avoids suggesting there is more content to open when there is not.
Original PR description
Hide the caret icon when the article has no children. task-4830534
Resolved issues and error corrections
A point of sale test now creates its branch company with the required country information. This prevents an unrelated certification check from interrupting the test, helping keep automated quality checks reliable.
Original PR description
The test `test_pos_branch_account` was failing due to a `UserError` raised from the `l10n_de_pos_cert` module, which requires that a country be set on the company before opening the POS UI (`open_ui`). Since the test creates a new `res.company` record to represent a branch, the required `country_id` was missing, causing the test to crash instead of evaluating the intended logic. This change sets the `country_id` on the created branch company. build_error-223267
Documentation and clarification updates
This pull request records a signed contributor license agreement for the contributor elierwclik. It supports the project's legal compliance process and does not change product features or user workflows.
Miscellaneous changes
## Steps to reproduce: - Create a SO from sales, and don't confirm it - Enable 'Allow Ship Later' in PoS - From PoS, settle the SO, with "Ship Later" option ## Observed behavior: From the inventory app -> Delivery orders, we can see that 2 pickings for this order have been created, one for the original SO order, and another one for the PoS order. Both of them are in state 'confirmed', i.e. "Ready". ## Expected behavior: The original SO picking should have been cancelled, i.e. in st
Original PR description
## Steps to reproduce: - Create a SO from sales, and don't confirm it - Enable 'Allow Ship Later' in PoS - From PoS, settle the SO, with "Ship Later" option ## Observed behavior: From the inventory…
## Steps to reproduce: - Create a SO from sales, and don't confirm it - Enable 'Allow Ship Later' in PoS - From PoS, settle the SO, with "Ship Later" option ## Observed behavior: From the inventory app -> Delivery orders, we can see that 2 pickings for this order have been created, one for the original SO order, and another one for the PoS order. Both of them are in state 'confirmed', i.e. "Ready". ## Expected behavior: The original SO picking should have been cancelled, i.e. in state 'cancel', and only the PoS picking should be "Ready". ## Why that happens: When settling the SO from PoS, that will create a new order from PoS with its associated PoS picking. While doing that, we also confirm the original SO [1], changing its state from 'draft' to 'sale', and that will create a move and a picknig associated with that SO, both in state 'confirmed'. So at this point, we're heading toward having 2 pickings, one from the PoS order and the other from the SO, both in state 'confirmed', which is undesired! What we want is having the SO's picking in state 'cancel', and the picking from PoS in state 'confirmed' (since we have settled the order from PoS). To achieve this behavior, we check if the quantity delivered on the SO (i.e. `so_line.qty_delivered`) compensates for the qty that should be deliverd, i.e. for `so_line.product_uom_qty` [2], and if so, we cancel the SO picking ([3], [4]). However, if the order is "ship later", the `so_line.qty_delivered` will be 0 at first, and will only get updated when the picking has indeed being shipped [5], resulting in `new_qty` always being a positive number, and hence also the `product_uom_qty` on the SO pikcing [6], meanign that the SO picking will not qualify to be cancelled. ## The fix: Now, in the computation of `new_qty`, we don't only compare `so_line.product_uom_qty` with what quantity has indeed been delivered (i.e. `so_line.qty_delivered`), but also with the quantity that is expected to be delivered later (i.e. `get_expected_qty_to_ship_later`). [1]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L74 [2]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L88 [3]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L95 [4]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L103-L104 [5]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/sale_order.py#L57 [6]: https://github.com/odoo/odoo/blob/af6dcd70917b18d2d23406a14a948b603f4adfa7/addons/pos_sale/models/pos_order.py#L94 opw-4375941 opw-4457592 opw-4490398 opw-4628515 opw-4599490 Forward-Port-Of: odoo/odoo#197031
This fixes an issue where using Ctrl+Enter in a Point of Sale text dialog could confirm the action twice. For restaurant users, this prevents duplicate items such as two floors being created from a single entry.
Original PR description
For the `TextInputPopup` component a feature was introduced in 2f5c5c15644412cfb6493c661b2f1b927c8cc7e2 that allows the user to confirm the popup by simply clicking enter. The problem is that the dialog itself has a hotkey on "CTRL+Enter" that will also confirm the popup. This means that if a user uses the "CTRL+Enter" hotkey, the popup will be confirmed twice. Steps to reproduce: 1. In restaurant, click the button to add a new floor 2. Write a name for the floor 3. Click "CTRL+Enter" 4. Observe that 2 floors with the given name were created instead of one. The fix: We stop the propagation of the event Task: 4698289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale settings now prevent users from creating a new cash rounding method directly from the POS configuration screen. This ensures rounding methods are set up through the proper accounting form, reducing errors during cash in/out operations and session closing.
Original PR description
Added `no_create` option to the `pos_rounding_method` field to enforce use of predefined `cash.rounding.method` form, avoiding bypass of required Profit & Loss accounts setup (which cause some issue when trying to cash in/out in POS or when trying to close the session). task-id: 4805617 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The change updates an internal website shop loyalty test so it is not affected by tax settings that include taxes in product prices. This helps keep automated checks reliable across different configurations without changing customer-facing behavior.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Install `website_sale_loyalty` without demo data; 2. configure taxes to be included in the price; 2. run `test_apply_coupon_with_multiple_rewards`. Issue ----- Test fails. Cause ----- The test compares the product's list price to the order subtotal. With `price_include` set to `True`, the product's `list_price` does include taxes, making the comparison invalid. Solution -------- Explicitly set `taxes_id` to `False` on products created for the test. Also ensure the pricelist & partner don't change in the test. runbot-223362
This update corrects internal test checks for sales, purchasing, and stock transfer flows so they validate the right delivery steps. It helps prevent incorrect assumptions about shipments and internal transfers from hiding future issues.
Original PR description
The pick pickings are incorrect, because we get them from the next transfers of... the receipts. All next steps are wrong (some of the shippings are actually internal pickings) OPW-4552316
The html editor module metadata no longer lists the author as lowercase "odoo" and will instead use the standard company name, Odoo S.A. This is a minor cleanup that keeps module information consistent and professionally presented.
Original PR description
Author was set as "odoo" (lowercase). This commit removes the author key so it fallbacks to the default one, i.e. Odoo S.A. This also aligns keys with previous commits like 42bad1a6 and ef7005f5. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The rental search block now sends selected product attributes in the format expected by the shop page. This ensures customers see properly filtered rental results when using configured attribute options, reducing confusion and improving product discovery.
Original PR description
Description: Currently, when an attribute is selected in the Rental Search snippet options, the generated URL uses the `attrib` parameter. However, the `/shop` route expects the parameter to be named `attribute_value`, so the filter is not applied correctly and the search results are not filtered as expected. Steps to reproduce: - Add the "Rental Search" snippet to a website page. - Configure the snippet and select an attribute value in the snippet options. - Check the resulting URL: it uses the incorrect `attrib` param, so the filter does not apply on /shop.
This update makes an automated field service worksheet test wait for a pop-up to open before interacting with it. This reduces false test failures caused by timing issues, helping keep releases and quality checks more reliable.
Original PR description
The fsm_task_form_tour tour was failing because the modal was not open when the test tried to select the element. This change add a wait step was to ensure the modal is open before trying to select the element. Avoiding flaky behavior caused by timing issues in the UI. build_error-163017
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212192
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212192
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a multi-company environment, we cannot access the warehouse of a different company. In the sale_order model, the `_init_column` method populates the warehouse value for existing sales orders before stock is installed. It uses self.env.company to set the warehouse, but `_init_colum
Original PR description
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a…
Steps to reproduce: - Install sales - Create a new company (CMP2) - Switch to CMP2 - Create a sales order - Install stock - Go to the SO created, update it and save The problem is that in a multi-company environment, we cannot access the warehouse of a different company. In the sale_order model, the `_init_column` method populates the warehouse value for existing sales orders before stock is installed. It uses self.env.company to set the warehouse, but `_init_column` is called with superuser privileges, which lack user context. This causes warehouses to always be linked to the superuser's company (id=1). As a result, modifying sales orders from different companies becomes impossible. opw-4735086 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207792
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/error_event See also MDN's img, script and iframe docs. The error Event *doesn't* bubble. We sometimes reject a promise with the Event dispatched by the "error" handler of an HTMLElement. If the code throwing that at us doesn't wrap the event in an actual Error, there is no reason to do more than the spec: we do not handle this error bubbling to us via the Promise being rejected. This allows to silence errors coming from a failed
Original PR description
https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/error_event See also MDN's img, script and iframe docs. The error Event *doesn't* bubble. We sometimes reject a promise with the Event dispatched by the "error" handler of an HTMLElement. If the code throwing that at us doesn't wrap the event in an actual Error, there is no reason to do more than the spec: we do not handle this error bubbling to us via the Promise being rejected. This allows to silence errors coming from a failed load of an Element that was wrapped into a promise. Website uses that in image_processing for example. runbot-error-70404 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211827
Due to floating operation result of calculation might have "x.000000001" form. This will make user unable to submit efaktur to coretax platform. To prevent this, we use `float_repr` to ensure 2 decimal places. opw-4745508 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212186
Original PR description
Due to floating operation result of calculation might have "x.000000001" form. This will make user unable to submit efaktur to coretax platform. To prevent this, we use `float_repr` to ensure 2 decimal places. opw-4745508 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212186
Make the notification message searchable. Task-4828780 Forward-Port-Of: odoo/odoo#212047
Original PR description
Make the notification message searchable. Task-4828780 Forward-Port-Of: odoo/odoo#212047
There is a typo in the name of the Hebrew language. This commit fixes it. Task-4742567 Forward-Port-Of: odoo/odoo#212160
Original PR description
There is a typo in the name of the Hebrew language. This commit fixes it. Task-4742567 Forward-Port-Of: odoo/odoo#212160
The l10n_tr_nilvera_purchase_journal_id field was causing access errors due to its placement in the "Integrations" section without any group restriction, exposing it to users without the necessary rights. In contrast, the similar account_peppol_purchase_journal_id field is defined under the "Invoicing" section with the proper group restriction (account.group_account_manager), and behaves correctly. This fix moves the Nilvera field into the same restricted section as the Peppol field, align
Original PR description
The l10n_tr_nilvera_purchase_journal_id field was causing access errors due to its placement in the "Integrations" section without any group restriction, exposing it to users without the necessary rights. In contrast, the similar account_peppol_purchase_journal_id field is defined under the "Invoicing" section with the proper group restriction (account.group_account_manager), and behaves correctly. This fix moves the Nilvera field into the same restricted section as the Peppol field, aligning its access control and visibility with other similar fields in the same context. build_error-111279 Forward-Port-Of: odoo/odoo#210460 Forward-Port-Of: odoo/odoo#201563
### Before this commit: Empty paths in the config file are invalid but not verified, resulting in cryptic errors. ### After this commit: Empty paths are ignored, to prevent errors in the config. opw-4744154 Forward-Port-Of: odoo/odoo#209912
Original PR description
### Before this commit: Empty paths in the config file are invalid but not verified, resulting in cryptic errors. ### After this commit: Empty paths are ignored, to prevent errors in the config. opw-4744154 Forward-Port-Of: odoo/odoo#209912
Before this commit: - Vehicle number, document number, and date were rendered together without spacing, reducing readability. After this commit: - These fields are now separated by `&` for improved clarity in the vehicle details section. task-4807692 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210830
Original PR description
Before this commit: - Vehicle number, document number, and date were rendered together without spacing, reducing readability. After this commit: - These fields are now separated by `&` for improved clarity in the vehicle details section. task-4807692 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210830
Issue: ------------------------------------------ When we create MO having one picking, open this picking via Studio and switching to other view giving a ValidationError: `The modes in view_mode must not be duplicated: ['tree', 'kanban', 'form', 'calendar', 'map', 'kanban']` instead of switching to the selected view. How to reproduce: ------------------------------------------ 1.Install Manufacturing, 2.Enable 2-step manufacturing, 3.Create MO for any product, e.g.Wood Panel 4.Go
Original PR description
Issue: ------------------------------------------ When we create MO having one picking, open this picking via Studio and switching to other view giving a ValidationError: `The modes in view_mode must…
Issue: ------------------------------------------ When we create MO having one picking, open this picking via Studio and switching to other view giving a ValidationError: `The modes in view_mode must not be duplicated: ['tree', 'kanban', 'form', 'calendar', 'map', 'kanban']` instead of switching to the selected view. How to reproduce: ------------------------------------------ 1.Install Manufacturing, 2.Enable 2-step manufacturing, 3.Create MO for any product, e.g.Wood Panel 4.Go to the Transfers(having 1 picking), 5.Open Studio -> views -> Activate list view, Switching to Studio list view giving a ValidationError. Cause of the issue: ------------------------------------------ In the `action_view_mo_delivery` method when there is a single picking for the MO, only form view is passed in views, so it is not able to open other views. Solution: ------------------------------------------ In action_view_mo_delivery for single picking passes the form view and append the other views. This prevents the ValidationError and opens the selected view in Studio. This is similar to the issue previously fixed in: https://github.com/odoo/odoo/pull/37582 Forward-Port-Of: odoo/odoo#206269
## Description of the issue/feature this PR addresses: This PR is about fixing this issue: https://github.com/odoo/odoo/issues/182777 to avoid SMTPServerDisconnected ## Current behavior before PR: With some race condition got SMTPServerDisconnected ## Desired behavior after PR is merged: Do not get SMTPServerDisconnected while quitting non connect session and avoid to get non connected session using google oauth2 connection. --- I confirm I have signed the CLA and read the P
Original PR description
## Description of the issue/feature this PR addresses: This PR is about fixing this issue: https://github.com/odoo/odoo/issues/182777 to avoid SMTPServerDisconnected ## Current behavior before PR: With some race condition got SMTPServerDisconnected ## Desired behavior after PR is merged: Do not get SMTPServerDisconnected while quitting non connect session and avoid to get non connected session using google oauth2 connection. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212091 Forward-Port-Of: odoo/odoo#182817
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. R
Original PR description
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice…
**Steps to reproduce:** - Install l10n_cz_reports_2025 - Switch to a Czech company (e.g. CZ Company) - Create a bill: * Customer: [a Czech customer] * Bill Reference: [any] (e.g. XYZ) * Invoice Lines: [a line with an amount higher than 10000 and a tax] - Confirm the bill - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Select "VAT Control Statement (CZ)" as Report - Select a period covering the bill date The bill should appear in the report under "B.2. Received taxable supplies and provided payments above CZK 10,000" section. **Issue:** The "Tax document registration number" (i.e. "c_evid_dd" in the exported XML) value for the bill is the name of the bill. According to the documentation: https://financnisprava.gov.cz/en/taxes/VAT-Control-Statement https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 For purchase-type documents, this field should have the bill reference as value. It should identify the original reference coming from the vendor. If there is no bill reference, the field should be empty. opw-4737630 Forward-Port-Of: odoo/enterprise#85005
- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126 Forward-Port-Of: odoo/enterprise#86499
Original PR description
- we have to align to KE law by including the NSSF amount in the contribution cap calculations for taxes Task: 4720126 Forward-Port-Of: odoo/enterprise#86499