Daily updates from Odoo
Wednesday, November 5, 2025
171 changes
17 changes
Resolved issues and error corrections
This change stops the chat bubble launcher from briefly moving when tapped on mobile. It keeps the bubble in place by adjusting how its position is defined, improving the experience in Discuss and on websites.
Original PR description
**Description of the issue/feature this PR addresses:** when clicking on chat bubble in mobile, the chat bubbles were moving down temporarily **Current behavior before PR:** when clicking on chat…
**Description of the issue/feature this PR addresses:** when clicking on chat bubble in mobile, the chat bubbles were moving down temporarily **Current behavior before PR:** when clicking on chat bubble in mobile, the chat bubbles were moving down temporarily. this happens because in some contexts, the chat hub bubbles are lift up, like in discuss app and at bottom of website page. This was done with a `transform: translateY()` but when the button was being clicked the chat bubble temporarily resets its unlifted position, as if no `transform: translateY()` was in effect. **Desired behavior after PR is merged:** This fixes the issue by using `bottom` CSS style rule. Chat hub bubbles part has a bottom value, the lift up is now designed to combine with the static bottom value, thus bubbles part stay at the desired position even when being clicked. Backport of #225757 task-[4914438](https://www.odoo.com/odoo/project/1519/tasks/4914438) Before  After  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234269
This update lets users create an invoice linked to a Point of Sale order even when it stays in draft status, with a warning instead of a hard stop. It helps businesses in countries where invoices must be adjusted before being sent to tax authorities.
Original PR description
After this commit, it becomes possible to make an invoice linked to a PoS order draft, showing only a warning notification instead of blocking the action. This is required in some localizations where invoices must be modified before being sent to the government. opw-5218715 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233847 Forward-Port-Of: odoo/odoo#233649
PayPal payment options were updated to stop offering Chinese yuan (CNY) for accounts that cannot process it. This prevents customers from reaching a dead-end when trying to pay CNY invoices through PayPal, improving checkout reliability for affected businesses.
Original PR description
## Versions 18.0+ ## Issue No payment is possible with PayPal for invoices expressed in Chinese currency. ## Steps to reproduce **`account` app required** - Enable "CNY" currency via `Invoicing /…
## Versions
18.0+
## Issue
No payment is possible with PayPal for invoices expressed in Chinese currency.
## Steps to reproduce
**`account` app required**
- Enable "CNY" currency via `Invoicing / Configuration / Accounting / Currencies`;
- Install, setup and publish PayPal payment provider;
- Move to the Invoice app:
- Create a new invoice in "CNY" currency for any customer with at least 1 product;
- Confirm and click on the preview button:
- Click on the "Pay now" button then "Pay" button of the wizard.
## Cause
"CNY" currency is only supported for Chinese accounts and for transactions occurring in China. PayPal says:
> Please note that Chinese Renminbi (CNY) is supported as a payment currency (buyer currency) or settlement currency (holding currency) only for in-country PayPal accounts. If the settlement account is based outside of China, PayPal will convert the funds into the account’s primary currency using the applicable currency conversion rate, which includes a spread or fee.
opw-5071893
Forward-Port-Of: odoo/odoo#232092This fix ensures products added through the variant grid are handled correctly when they are also part of a combo offer. Without it, the same product could be merged into the combo line and have its price added twice, which could lead to incorrect sales order totals.
Original PR description
Steps: - create a product with attributes of create_variant=never - set variant selection to order grid entry - add this product as a combo choice and set extra_price>1 - In sale order form first add the new combo product with the previously created product - add the new product with same selection of attribute values as combo Issue: - The separately added product should create a new line, but since it was added as a part of the combo, the product's price is summed with extra price and added to the combo itself Cause: - the grid field that is responsible for adding product using product matrix does not filter combo lines Fix: - added filter for combo lines when matrix opens and saves opw-5164789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234102
This change adds a check before updating certain HR-related menus, so the system no longer fails if those menus were deleted or are missing during an upgrade. It helps keep database updates and migrations smoother and more resilient.
Original PR description
To Reproduce: 1) make a database in 16.0 and go to developer mode. 2) Delete the menus 3) I mocked the views with upgrade mockcrawler. it failed for these xmlids: ``` hr_attendance.menu_hr_attendance_attendances_overview hr_timesheet.timesheet_menu_activity_use hr.menu_hr_employee ``` but we should have a check anyways. 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#230135 Forward-Port-Of: odoo/odoo#215426
This change removes the bot-detection filter that was added to blog and slides tag pages. The previous check was not dependable, and some crawlers still indexed large numbers of tag combinations, so the team is rolling it back while a better solution is prepared.
Original PR description
This reverts [1] because the is_a_bot check is not reliable. Many crawlers spoof user agents or ignore robots rules, so they still index every tag combination and overload tag clouds. We revert while we look for a better protection. [1]: 4b1c3bfa83af2b1851db62df5aca4d5777a3d88c Forward-Port-Of: odoo/odoo#234278
Event registration forms now request the reCaptcha check only when the user submits the form, instead of when the form first opens. This prevents valid registrations from failing if someone takes more than two minutes to complete the form.
Original PR description
Steps to reproduce =============== 1. Enable reCaptcha in Settings and configure keys. 2. Go to an event and click Register. 3. Fill in the form but wait more than 2 minutes. 4. Submit the form ---> An error message is shown. When reCaptcha was enabled on event registrations, the token was being requested too early (during `willStart`). Since a token is only valid for 2 minutes, users who took longer to fill out the registration form encountered an error when submitting. After this commit, the reCaptcha token is requested only on submitting. This way, the token is always valid and the form can be submitted successfully, even after several minutes. Task-4982067 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#233517 Forward-Port-Of: odoo/odoo#223538
This fixes an error that could block the preview of a quotation after customizing the sales report in Studio. Users can now edit the report layout and still preview quotations normally in the portal without encountering a rendering error.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to…
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to a quotation and click on the "Preview" action. Issue ----- A traceback occurs during the rendering of the `sale.sale_order_portal_template` template. ``` Error while render the template KeyError: 'doc' Template: sale.document_tax_totals Path: /t/t/tr/td[1]/span Node: <span t-field="doc.amount_untaxed"/> The error occurred while rendering the template sale.document_tax_totals and evaluating the following expression: <span t-field="doc.amount_untaxed"/> ``` Cause ----- In the `sale.report_saleorder_document` template, `doc` is used as the variable name for the current sale order. Consequently, the studio edit uses this variable name to modify the `sale.document_tax_totals` template called within `sale.report_saleorder_document`. However, the `sale.sale_order_portal_template` template, used for the portal preview, also calls `sale.document_tax_totals` but uses `sale_order` as the variable name for the current order. Solution -------- Add an alias `doc` for `sale_order` during the rendering of `sale.document_tax_totals` when called in the portal report preview. opw-5136553 Forward-Port-Of: odoo/odoo#233755
This fix restores the image toolbar when users click away from editable content and then return to an image. It ensures the editor correctly recognizes where the text selection is, so image editing options appear when expected.
Original PR description
Description of the issue: - The image toolbar failed to open when the editable had lost focus. - Previously, `focusEditable()` exited early if the active element was inside the editable, even when the actual document selection wasn’t. Solution: - Updated the condition in `focusEditable()` to also check whether the document selection is inside the editable. - Now it only returns early when both the active element and the selection are within the editable. task-5117272 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230549
This fix prevents Odoo from trying to clean up stock reservations for kit products in cases where that would create an error. As a result, users can open and update stock records normally again without being blocked by this issue.
Original PR description
Since this commit: 766ec99 We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on…
Since this commit: 766ec99 We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on “stock.quant”. However, there are cases where a user creates a storable product, updates its quantity, and then uses it in a “stock.move.line”, confirms it, and later changes the product type to a kit. So, when trying to clean the reservations for these “stock.move.line”, a user error occurs because the system attempts to create a quant for a kit-type product: https://github.com/odoo/odoo/blob/c07778bbce4311c142bd8e2ce3013998d4f126ae/addons/mrp/models/stock_quant.py#L6-L11 As a result, each time users try to access the quant list, clean_reservation is triggered, causing a user error that prevents them from modifying the quantity of any quant. Solution: For kits, we can skip cleaning their quant to avoid unnecessary errors. This is a manual forward-port of #200595 opw-4625002 opw-4624008 opw-4621175 opw-4625465 opw-4621504 opw-4623523 opw-4621508 opw-4623329 opw-4629386 opw-5179369 Forward-Port-Of: odoo/odoo#232646
This change fixes an error in the device certificate expiration check that could occur when two different date formats were compared. It ensures the system uses matching time values, so certificate validation runs reliably and avoids unexpected interruptions.
Original PR description
Before this commit, datetime.now() was compared to cert.not_valid_after_utc, leading to an error because we compare offset-naive and offset-aware datetimes After this commit, we set an offset-aware datetime.now() if we use not_valid_after_utc Issue introduced in #234005 opw-5237595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234371
This change removes an extra test step that was no longer needed in the website product image removal flow. The newer website editor framework already handles the timing issue, so the test is simpler while keeping the relevant Python-side improvements.
Original PR description
Before #234150, the `remove_product_image_*` tours occasionally failed due to the incorrect assumption that removing an image from the DOM was immediately saved in the database. A fix was introduced by adding a final tour step to ensure that the asynchronous DOM save was completed before exiting the tour. This fix was later forward-ported to 18.4 with bb6825760095df30a3559bcbf69cfa17bf383654. However, in 18.4, the website editor framework was improved with the introduction of the `BuilderAction` class. The migration to this new framework already resolved the issues with the `remove_product_image_*` tours, rendering the fix in #234150 unnecessary. This commit reverts part of that fix by removing the final tour step while retaining some improvements in the Python code.
This fix ensures delivery fees on subscription invoices are no longer reduced when invoices are prorated. It helps businesses charge shipping at the correct fixed amount, avoiding underbilling on recurring deliveries.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a subscription with delivery product. 2. Select align to calendar in the recurring plan 2. Add shipping method by assigning a delivery product with recurring_invoice. 3. Create an invoice with prorated Issue: - Delivery products are considered service-type products and their price was prorated in invoice. Cause: - The proration logic treated delivery lines like normal recurring service products, instead of keeping their fixed charge. Solution: - Exclude delivery products from proration by setting their period ratio to 1. Co-authored-by: Darshan Patel dvpa@odoo.com Co-authored-by: Federico Braidi brfe@odoo.com task-4662188 Forward-Port-Of: odoo/enterprise#98687 Forward-Port-Of: odoo/enterprise#91133
This change corrects how inventory is balanced when a product is delivered with a lot or serial number from barcode scanning. It prevents stock from being assigned to an unnamed entry, which could later cause the lot-specific stock to remain unbalanced and create inaccurate inventory records.
Original PR description
Uecase to reproduce: - Create a quant with a product and 10 lot A - Create a delivery order - Open barcode - In barcode, deliver the product with lot C Current behavior: You have 2 quants: - 10 lot A - -1 without lot Expected behavior: - 10 lot A - -1 lot C It happens because the code try to balance negative quant for lot/sn in a stack of quants without lot/sn for the product. However in this case the barcode create a quant without quantity and without lot. In this case the system wants to update it due to an incorrect condition. It's an issue since in later receit with the correct lot. The quant will never be balanced and it will result with - -1 without - 1 lot C 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#231853
This change fixes a performance issue in the spreadsheet version history view by avoiding an extra company currency lookup. It makes the version history action load more efficiently and removes a bug that only appeared in that view.
Original PR description
The perfomance commit added in https://github.com/odoo/odoo/pull/151725 did not account for the version history action that does not inherit from `AbstractSpreadsheetAction`. this missing value trickled down to a bug only detectable in the VersionHistory action and which is addressed in https://github.com/odoo/odoo/pull/232985 This commit adds the same performance to VersionHistory action. Task-5187293 Forward-Port-Of: odoo/enterprise#98197 Forward-Port-Of: odoo/enterprise#98038
This fix prevents the Point of Sale from changing prices on all variants of a product when only one lot-tracked variant is added. It ensures each variant keeps its own correct price, avoiding pricing mistakes at checkout.
Original PR description
Before this commit, when a product had multiple variants with different prices and was tracked by lot, adding different variants in the PoS would incorrectly update all product prices. opw-5228830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234332 Forward-Port-Of: odoo/odoo#234171
This change prevents a server error when sending a credit or debit note to DGI if the original document is not a valid electronic invoice. Instead of failing unexpectedly, Odoo now shows a proper message so the user can correct the document before retrying.
Original PR description
### Description of the issue/feature this PR addresses: When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document…
### Description of the issue/feature this PR addresses:
When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document is not a real CFE then will raise a traceback error
### Steps to reproduce:
1. Create an e-invoice and confirm in Odoo (without sending to DGI)
2. Create an e-credit note from the e-invoice created in (1) and confirm
3. Try to send the credit note to DGI
The result is a traceback:
```
RPC_ERROR
Odoo Server Error
Occured on 18.core.odoo.localhost on model account.move.send.wizard on 2025-10-21 20:47:48 GMT
Traceback (most recent call last):
File "/home/odoo/custom/odoo/odoo/http.py", line 2144, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2111, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2359, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/wizard/account_move_send_wizard.py", line 294, in action_send_and_print
attachments = self._generate_and_send_invoices(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 719, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 620, in _generate_invoice_documents
self._call_web_service_before_invoice_pdf_render(invoices_data_web_service)
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move_send.py", line 88, in _call_web_service_before_invoice_pdf_render
invoice._l10n_uy_edi_send()
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 813, in _l10n_uy_edi_send
request_data = move._l10n_uy_edi_prepare_req_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 787, in _l10n_uy_edi_prepare_req_data
xml_content = self._l10n_uy_edi_get_xml_content()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 773, in _l10n_uy_edi_get_xml_content
"referencia_lines": self._l10n_uy_edi_cfe_F_reference(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 381, in _l10n_uy_edi_cfe_F_reference
cfe_serie, cfe_number = self.l10n_uy_edi_document_id._get_doc_parts(related_cfe)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/l10n_uy_edi_document.py", line 215, in _get_doc_parts
return re.findall(r"([A-Z]{1,2})[-]*([0-9]{1,8})", record.l10n_latam_document_number)[-1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3162:163)
at XMLHttpRequest.<anonymous> (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3167:13)
```
### Desired behavior after PR is merged:
Now we ensure to show a proper message to the user to fix the problem: the original document should be a electronic one
<img width="1203" height="664" alt="after" src="https://github.com/user-attachments/assets/bb7b105e-12f0-4935-b6bc-37edb3bc3aca" />
References LATAM 1301 / ADHOC Task 54770
Forward-Port-Of: odoo/enterprise#9028121 changes
Resolved issues and error corrections
The website now only shows the language selector when there is more than one language available. This prevents an empty menu item from appearing in the header, which removes an unnecessary border or blank space and improves the page layout.
Original PR description
This PR calls the language selector placeholder only when multiple languages exist, avoiding an empty header list item that creates an unnecessary border or empty space. task-5150808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233744 Forward-Port-Of: odoo/odoo#231256
This fixes an issue where a product selected through the variant grid could be incorrectly treated as part of an existing combo, causing its extra price to be added to the combo instead of creating a separate order line. With this change, the system now properly separates combo items from standalone products when the grid opens and saves.
Original PR description
Steps: - create a product with attributes of create_variant=never - set variant selection to order grid entry - add this product as a combo choice and set extra_price>1 - In sale order form first add the new combo product with the previously created product - add the new product with same selection of attribute values as combo Issue: - The separately added product should create a new line, but since it was added as a part of the combo, the product's price is summed with extra price and added to the combo itself Cause: - the grid field that is responsible for adding product using product matrix does not filter combo lines Fix: - added filter for combo lines when matrix opens and saves opw-5164789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234102
This change removes Chinese yuan (CNY) from the PayPal payment options in Odoo. It prevents customers from reaching a payment flow that PayPal cannot complete for most non-China accounts, avoiding failed invoice payments and confusion.
Original PR description
## Versions 18.0+ ## Issue No payment is possible with PayPal for invoices expressed in Chinese currency. ## Steps to reproduce **`account` app required** - Enable "CNY" currency via `Invoicing /…
## Versions
18.0+
## Issue
No payment is possible with PayPal for invoices expressed in Chinese currency.
## Steps to reproduce
**`account` app required**
- Enable "CNY" currency via `Invoicing / Configuration / Accounting / Currencies`;
- Install, setup and publish PayPal payment provider;
- Move to the Invoice app:
- Create a new invoice in "CNY" currency for any customer with at least 1 product;
- Confirm and click on the preview button:
- Click on the "Pay now" button then "Pay" button of the wizard.
## Cause
"CNY" currency is only supported for Chinese accounts and for transactions occurring in China. PayPal says:
> Please note that Chinese Renminbi (CNY) is supported as a payment currency (buyer currency) or settlement currency (holding currency) only for in-country PayPal accounts. If the settlement account is based outside of China, PayPal will convert the funds into the account’s primary currency using the applicable currency conversion rate, which includes a spread or fee.
opw-5071893
Forward-Port-Of: odoo/odoo#232092This fix ensures that when multiple product variants have different prices, adding one lot-tracked variant in Point of Sale no longer changes the prices of the other variants. It helps keep pricing accurate at checkout and avoids unintended price updates for customers and staff.
Original PR description
Before this commit, when a product had multiple variants with different prices and was tracked by lot, adding different variants in the PoS would incorrectly update all product prices. opw-5228830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234171
This change rolls back a previous bot-detection filter in the Blog and Slides areas. The earlier check was not reliable, so it is being removed while a better way to limit unwanted crawling is developed.
Original PR description
This reverts [1] because the is_a_bot check is not reliable. Many crawlers spoof user agents or ignore robots rules, so they still index every tag combination and overload tag clouds. We revert while we look for a better protection. [1]: 4b1c3bfa83af2b1851db62df5aca4d5777a3d88c Forward-Port-Of: odoo/odoo#234278
This update adjusts an automated sales/manufacturing test so it no longer depends on a field that only exists when Enterprise is installed. It helps keep the test suite reliable across different Odoo setups and prevents false failures during validation.
Original PR description
Cause ----- Test introduced in 2da1c78 uses the field `backorder_ids` which is only present when enterprise is installed https://github.com/odoo/enterprise/blob/67fdbc5ae724a184d62d8cfa23403b8c759b9317/stock_barcode_mrp/models/mrp_production.py#L10 ----- Error: 233584 Forward-Port-Of: odoo/odoo#233730
This fix adds a safety check before using certain HR menu entries, so the system no longer fails if those menus have been removed or are missing during an upgrade. It helps keep database updates and maintenance tasks running smoothly, especially in older databases with customized setups.
Original PR description
To Reproduce: 1) make a database in 16.0 and go to developer mode. 2) Delete the menus 3) I mocked the views with upgrade mockcrawler. it failed for these xmlids: ``` hr_attendance.menu_hr_attendance_attendances_overview hr_timesheet.timesheet_menu_activity_use hr.menu_hr_employee ``` but we should have a check anyways. 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#230135 Forward-Port-Of: odoo/odoo#215426
This update prevents accounting journals from reusing the same alias when a journal type is selected before its name. It removes an error that could block users from saving a second journal of the same type, making journal setup smoother and more reliable.
Original PR description
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the…
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error. **Steps to Reproduce** 1. Navigate to Accounting > Configuration > Journals. 2. Create a new journal. 3. Set the Type to Sales before entering the Name. 4. Save the journal. 5. Repeat the process to create another journal of the same type. 6. Observe that an error occurs: alias name is already used. **Root Cause** The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly. **Fix** Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured. Opw-5028713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225537
Event registration forms now request the reCAPTCHA verification token only when the user submits the form, instead of when the form first opens. This prevents the token from expiring while someone is filling out the form, so registrations complete successfully even if it takes a few minutes.
Original PR description
Steps to reproduce =============== 1. Enable reCaptcha in Settings and configure keys. 2. Go to an event and click Register. 3. Fill in the form but wait more than 2 minutes. 4. Submit the form ---> An error message is shown. When reCaptcha was enabled on event registrations, the token was being requested too early (during `willStart`). Since a token is only valid for 2 minutes, users who took longer to fill out the registration form encountered an error when submitting. After this commit, the reCaptcha token is requested only on submitting. This way, the token is always valid and the form can be submitted successfully, even after several minutes. Task-4982067 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#233517 Forward-Port-Of: odoo/odoo#223538
Fixed an issue in the product screen where tapping an order line no longer selected it when the certified scale module was installed. This restores the expected behavior so staff can select items normally, while long press continues to open the configurator popup.
Original PR description
Task: [5163235](https://www.odoo.com/odoo/project/1737/tasks/5163235) --- In the product screen, pressing an orderline was supposed to select this line and a long press was supposed to open the Configurator popup. However, since the feature of the long press, if we install the module `l10n_eu_iot_scale_cert`, pressing an orderline does not select it anymore. This was due to the fact that a `t-ref` was added in the orderline template and that in the `l10n_eu_iot_scale_cert` module, we were overriding this template completely. Forward-Port-Of: odoo/enterprise#96980
This update removes a flicker that appeared when hovering over the favorite filter edit icon in the search bar. The icon now keeps its space visible in the layout, so the menu no longer shifts size and behaves more smoothly.
Original PR description
This PR fixes an issue related to the edit favourite filter icon. Prior to this PR, the edit favourite filter icon used `d-none` by default and `display: block` on hover. Since `display: none` removes the element from the layout, the parent popover resized on hover, causing a flickering effect. This did not occur for filters with short labels (which had enough room for the icon) or for long labels (where the label was truncated). To prevent the flickering, the icon now uses `visibility: hidden/visible`, which keeps its space in the layout and avoids layout shifts. https://github.com/user-attachments/assets/5308c11e-8706-403c-80e3-fc05ab37a61d task-5237493 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales quotations can now be previewed correctly even after being customized with Studio. This prevents an error that previously blocked the portal report preview when certain sales report fields were added.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to…
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to a quotation and click on the "Preview" action. Issue ----- A traceback occurs during the rendering of the `sale.sale_order_portal_template` template. ``` Error while render the template KeyError: 'doc' Template: sale.document_tax_totals Path: /t/t/tr/td[1]/span Node: <span t-field="doc.amount_untaxed"/> The error occurred while rendering the template sale.document_tax_totals and evaluating the following expression: <span t-field="doc.amount_untaxed"/> ``` Cause ----- In the `sale.report_saleorder_document` template, `doc` is used as the variable name for the current sale order. Consequently, the studio edit uses this variable name to modify the `sale.document_tax_totals` template called within `sale.report_saleorder_document`. However, the `sale.sale_order_portal_template` template, used for the portal preview, also calls `sale.document_tax_totals` but uses `sale_order` as the variable name for the current order. Solution -------- Add an alias `doc` for `sale_order` during the rendering of `sale.document_tax_totals` when called in the portal report preview. opw-5136553 Forward-Port-Of: odoo/odoo#233755
The bank reconciliation screen now updates correctly when users move through paginated records. This prevents reconciliation buttons and partner counts from disappearing on later pages, so accountants can continue reconciling records without losing key information.
Original PR description
Issue: when navigating through paginated records in the bank reconcilliation widget the functions `computeReconcileLineCountPerPartnerId` and `computeAvailableReconcileModels` were not re-executed. This caused reconciliation model buttons and partner counts to disappear on pages after the first. steps to Reproduce: 1 - In a database with >80 records to reconcile and pre-existing reconciliation models: 2 - Go to Accounting -> N to reconcile button. 3 - In Kanban view expand a record to view reconciliation model buttons (displays correctly). 4 - Navigate to the next page. - From the second page onward, reconciliation model buttons and partner counts are not displayed. fix: on top of the `onWillStart` hook, which runs at the view is first rendered, I added `onRootLoaded` to ensure computations run whenever the dependencies change, updating the widget correctly on pagination. opw-5083877
This update adds the required accounting setup to an automated dropshipping test so it can run correctly even when demo data is not installed. It prevents the test from failing because a purchase journal was missing, improving the reliability of the test suite.
Original PR description
The test `test_dropship_return_backorders_bill_on_order` failed when running without demo data because no chart of accounts was installed, so no Purchase journal existed. As a result, `purchase_order.action_create_invoice()` raised: UserError: No journal could be found in company ... for any of those types: purchase This change inherits from `AccountTestInvoicingCommon` to have the necessary charts. [runbot-231285](https://runbot.odoo.com/odoo/error/231285) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224775
Tax closing entries are now linked to the right tax report, so generating a closing entry from a generic report or a national variant no longer creates duplicate or mismatched draft moves. This ensures users get a single, consistent closing entry for the same period, which avoids confusion and incorrect follow-up actions.
Original PR description
To reproduce the issue, on a Belgian company: 1) From the Generic Tax Report, or any of its two grouped variants (Account>Tax or Tax>Account), click on the closing entry button. It generates a draft…
To reproduce the issue, on a Belgian company: 1) From the Generic Tax Report, or any of its two grouped variants (Account>Tax or Tax>Account), click on the closing entry button. It generates a draft move. Log a note on that move. 2) Open the national tax report of Belgium, for the same period as in 1). Click on the closing entry button again. ==> The draft move generated in 2) is NOT the same as the one generated in 1) (you can check that from the note logged in 1)). This is because tax_closing_report_id is too naively set on the account.move, to always match the report on which the button was clicked. This commit fixes that, ensuring we set the right report in the closing field. Something will be done in the migration script to 19.0 to set the report properly before creating the returns. The problem also occurs when multiple national variants are available : in this case each of those reports creates a distinct closing entry, with the exact same informations, giving the illusion we're doing per-report closings. In such cases, we associate the closing move to the Generic tax Report. opw-4858689 Forward-Port-Of: odoo/enterprise#95775
This update removes a warning that could appear when using the booking form in Point of Sale during automated tours. It helps keep the POS experience cleaner and avoids confusing warning messages during testing and usage.
Original PR description
This will remove missing wigdet warning encountered when using the booking form from the point of sale. opw-5109501 Enterprise: https://github.com/odoo/enterprise/pull/96811
This fix corrects the mobile editor toolbar so it no longer switches to image controls when a text format like bold is applied. Users will now see the normal formatting toolbar and the active formatting button will be highlighted properly, making mobile editing clearer and more reliable.
Original PR description
**Current behavior before PR:** In mobile view, when applying the bold format using the toolbar button, the normal toolbar is incorrectly replaced by image toolbar. This occurs because `getFilteredTargetedNodes` returns an empty array, and as a result, the `isApplied` method evaluates to true since Array.every on an empty array returns true. **Desired behavior after PR:** This PR ensures that the toolbar remains in its normal state when a format is applied via the toolbar button. The corresponding format button (e.g., bold) is correctly highlighted. task-5123317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229454
This update stops the same invoice from being settled more than once in Point of Sale. It helps avoid duplicate customer account entries and keeps the settlement process accurate, while also preserving the selected customer if an attempt fails.
Original PR description
Steps to reproduce: ------------------------- - Install POS. - Create an invoiced order and pay with customer account. - Settle the created invoices from customers list. - Try to settle the invoice again from the same order. Issue: ------- - The system allows settling the same invoice multiple times. Cause: --------- - There is no check in place to verify whether the invoice has already been under settlement process before settling it again. Fix: ----- - Add a validation step to ensure that if the same invoice is selected again, the system prevents duplication and it will show that already being settled. - Also if error occured due to second try of settlment will not lose the selected partner. task: 5028009 related PR: [227971](https://github.com/odoo/odoo/pull/227971)
This update prevents archived reconciliation rules from showing up when users match bank transactions. It helps keep the list clean and reduces the chance of selecting outdated rules by mistake.
Original PR description
Steps to reproduce: ------------------- 1. Install Accounting (with demo data). 2. Go to Accounting > Dashboard and open the "Bank" journal. 3. Click on any unreconciled line and open the dropdown menu. 4. Select “Manage models” and archive one of the reconcile models. 5. Return to the bank journal and open any unreconciled line. Issue: ------- Archived reconcile models are still shown in the available model list. Cause: ------ The [SQL query](https://github.com/odoo/enterprise/blob/6615de3100ac1192039a5f276df278c543f2fabb/account_accountant/models/account_reconcile_model.py#L47-L118 ) does not filter out inactive reconcile models. Solution: ---------- Add a condition to include only active models. opw-5189700
This change prevents an error when sending a credit or debit note to Uruguay’s tax authority if the original invoice is not a valid electronic document. Instead of failing with a server traceback, Odoo now shows a clear message so the user can correct the issue before resending. This improves reliability and makes the process easier to complete successfully.
Original PR description
### Description of the issue/feature this PR addresses: When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document…
### Description of the issue/feature this PR addresses:
When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document is not a real CFE then will raise a traceback error
### Steps to reproduce:
1. Create an e-invoice and confirm in Odoo (without sending to DGI)
2. Create an e-credit note from the e-invoice created in (1) and confirm
3. Try to send the credit note to DGI
The result is a traceback:
```
RPC_ERROR
Odoo Server Error
Occured on 18.core.odoo.localhost on model account.move.send.wizard on 2025-10-21 20:47:48 GMT
Traceback (most recent call last):
File "/home/odoo/custom/odoo/odoo/http.py", line 2144, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2111, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2359, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/wizard/account_move_send_wizard.py", line 294, in action_send_and_print
attachments = self._generate_and_send_invoices(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 719, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 620, in _generate_invoice_documents
self._call_web_service_before_invoice_pdf_render(invoices_data_web_service)
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move_send.py", line 88, in _call_web_service_before_invoice_pdf_render
invoice._l10n_uy_edi_send()
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 813, in _l10n_uy_edi_send
request_data = move._l10n_uy_edi_prepare_req_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 787, in _l10n_uy_edi_prepare_req_data
xml_content = self._l10n_uy_edi_get_xml_content()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 773, in _l10n_uy_edi_get_xml_content
"referencia_lines": self._l10n_uy_edi_cfe_F_reference(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 381, in _l10n_uy_edi_cfe_F_reference
cfe_serie, cfe_number = self.l10n_uy_edi_document_id._get_doc_parts(related_cfe)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/l10n_uy_edi_document.py", line 215, in _get_doc_parts
return re.findall(r"([A-Z]{1,2})[-]*([0-9]{1,8})", record.l10n_latam_document_number)[-1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3162:163)
at XMLHttpRequest.<anonymous> (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3167:13)
```
### Desired behavior after PR is merged:
Now we ensure to show a proper message to the user to fix the problem: the original document should be a electronic one
<img width="1203" height="664" alt="after" src="https://github.com/user-attachments/assets/bb7b105e-12f0-4935-b6bc-37edb3bc3aca" />
References LATAM 1301 / ADHOC Task 54770
Forward-Port-Of: odoo/enterprise#90281This fix improves the spreadsheet version history view by avoiding an unnecessary company currency request. As a result, the view should open more efficiently and with less backend processing, especially in cases where this action is used frequently.
Original PR description
The perfomance commit added in https://github.com/odoo/odoo/pull/151725 did not account for the version history action that does not inherit from `AbstractSpreadsheetAction`. this missing value trickled down to a bug only detectable in the VersionHistory action and which is addressed in https://github.com/odoo/odoo/pull/232985 This commit adds the same performance to VersionHistory action. Task-5187293 Forward-Port-Of: odoo/enterprise#98197 Forward-Port-Of: odoo/enterprise#98038
2 changes
Resolved issues and error corrections
This fix corrects minimum rental duration rules so they follow real calendar months instead of assuming every month has 30 days. It prevents incorrect rejections for shorter months like February, making rental date selection work as users expect.
Original PR description
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting,…
Issue: Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days. To reproduce: 1- Install `website_sale_renting` 2- From Setting, set `Minimum Rental Duration` to 1 month. 3- Create a rental product and from website, choose the date: - 01/02/2026 - 28/02/2026 4- This fails. The earliest end date it accepts is 03/03/2026. Cause: This is due to hardcoded 30 days: https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L7-L12 https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L47-L53 We can use luxon plus method instead. ```diff + const minEndDate = startDate.plus(Object.fromEntries([[unit, duration]])); ``` In all usages of `msecPerUnit` we can do the same. Also we can keep remove `msecPerUnit` from master. opw-5094534 Forward-Port-Of: odoo/enterprise#98168
Fixed an issue in the barcode app where available stock was not refreshed after changing the product or source location on an internal transfer. This ensures users see the correct stock quantities when preparing transfers, reducing confusion and avoiding incorrect picking decisions.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624 Forward-Port-Of: odoo/enterprise#95906
20 changes
Resolved issues and error corrections
The journal audit report now correctly shows the detailed tax grid breakdown again, including the separate plus and minus columns. This fixes missing tax information that could make audit review and tax reconciliation harder for accounting teams.
Original PR description
During the removal of tax tag signs, the detail of the tax grids has been removed and both columns `+` and `-` have been removed by mistake. Forward-Port-Of: odoo/enterprise#98499
The Auto Transfers option in Accounting settings now points to the correct underlying module after a module rename. This means users can enable the feature from settings and have it install as expected instead of silently remaining unchecked.
Original PR description
### Steps to reproduce: - Install "account_accountant" - Go in the settings - Search for "Enable Auto Transfers", tick the option - Save - The option is not ticked ### Cause: This option is supposed to install the module for Account Transfers. The option field is called `module_account_auto_transfer`. It's supposed to install the module `account_auto_transfer`. But this module was [refactored in 19.0](https://github.com/odoo/enterprise/commit/77c248981c9e1ccbb5d4c88a0915a231f040df84) and renamed `account_transfer`. So the settings can't find the module to install, nothing happen, and the option stays the same. ### Solution: Give the variable the correct name: `module_account_transfer`. opw-5149342 Forward-Port-Of: odoo/enterprise#97513
The automated SAT status check for Mexican electronic invoices now rotates through eligible documents instead of repeatedly checking the same first batch. This helps ensure imported posted invoices are all reviewed for possible SAT portal cancellations, improving reliability for companies with larger invoice volumes.
Original PR description
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return…
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.
Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.
This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.
This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.
Forward-Port-Of: odoo/enterprise#97928
Forward-Port-Of: odoo/enterprise#93205The checkout process now handles external tax calculation errors more gracefully for Brazilian sales. Customers will no longer see an endless loading state when tax data or address validation fails, helping them continue or understand what needs to be corrected.
Original PR description
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with…
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with infinite loading. Examples include missing NCM codes or IAP service failures due to invalid addresses. **Steps to Reproduce** 1. Install Brazilian localizations (l10n_br, l10n_br_avatax, l10n_br_edi). 2. Configure Avatax Transfer API credentials (API ID and Key). 3. Create a website with a Brazilian company. 4. Add a product to the cart and proceed to checkout. 5. Choose a delivery method and observe that the UI gets stuck loading. **Root Cause** The `_order_summary_values` method in `website_sale_external_tax` called `_get_and_set_external_taxes_on_eligible_records()`, which could raise exceptions (e.g., IAPServerError). These exceptions were not handled, so they propagated to the frontend as generic RPC errors. The frontend has no built-in mechanism to display these exceptions as user-friendly messages, resulting in infinite loading. **Fix** Wrap the external tax calculation in `_order_summary_values` and catch `UserError`. Instead of letting the exception propagate as a generic RPC error, attach the error message to the result dictionary under `external_tax_error`. This prevents the frontend from hanging while still making the underlying problem visible in the next checkout step, where validation errors are properly handled and shown to the user. Opw-5052078 Forward-Port-Of: odoo/enterprise#96213 Forward-Port-Of: odoo/enterprise#95045
VoIP ringtones now fully stop when a call ends, so they cannot be accidentally restarted with media controls on a keyboard or headset. This avoids confusing or disruptive sounds after calls are already finished.
Original PR description
Before this commit, users can resume "stopped" ringtones by pressing the Media Play/Pause key of their keyboard/headphones, even after the call has ended. After this commit, stopping the ringtone clears the audio source, effectively preventing it from being resumed. Task-5222704 opw-5186087 Forward-Port-Of: odoo/enterprise#98660
Knowledge users can now publish or unpublish website articles from the share panel and have that choice saved. This fixes a problem where the toggle reverted after saving, which could prevent intended content visibility changes from taking effect.
Original PR description
Recently, we changed how fields are loaded in view_widgets: instead of relying on invisible fields defined in the main XML view (e.g., `<field name="website_published" invisible="1"/>`), we now load…
Recently, we changed how fields are loaded in view_widgets: instead of relying on invisible fields defined in the main XML view (e.g., `<field name="website_published" invisible="1"/>`), we now load them using the view widget's field descriptions (see: odoo/enterprise@301f63597b0c21fef16a1941314ac95602c8f01f) In the `addFieldDependencies` method of `addons/web/static/src/model/relational_model/utils.js`, the system retrieves field descriptions and, by default, marks the loaded fields as readonly. Since the readonly attribute is not explicitly defined for the `website_published` field, it is automatically treated as readonly. As a result, when a record is saved, any changes made to readonly fields are discarded. This means updates to the `website_published` field are lost, preventing users from publishing or unpublishing an article via the share panel. Steps to reproduce the issue: 1. Install `website_knowledge` 2. Open an article in Knowledge 3. Click on the share button 4. Click on the toggle to publish the article 5. Save the article => The toggle is set back to its initial position. Proposed fix: We will update the field description for `website_published` to explicitly set it as not readonly. This will allow users to successfully publish and unpublish articles using the share panel. Task-5240915
Salary offer previews now calculate gross pay correctly when a contract template has no working hours set. The system uses the most relevant available working calendar instead of showing a zero gross salary, giving payroll teams and candidates more accurate offer information.
Original PR description
Reproduce: In debug mode go to Payroll > Employees > Offers > Create a new offer with a contract template that has no working hours. The gross salary shown in the Salary Simulation Preview is 0. Issue: If the version has no resource calendar, its working hours are 0. This sets the `work_time_rate` to 0, and when multiplied by the wage the gross becomes 0 as well. Fix: Prioritize the version’s resource calendar when available, otherwise fallback to the offer’s calendar, and finally to the company’s. task-5051509 Forward-Port-Of: odoo/enterprise#95041
Belgian accounting reports now assign the correct receivable and payable accounts to VAT-related partners and add reconciliation rules for VAT payments. This helps bank transactions match VAT closing entries more reliably, reducing manual follow-up during VAT settlement.
Original PR description
This commit sets AR and AP accounts of "FPS" and "Collection Center" partners with the 2 new added VAT accounts. Additionally, a new reconciliation rules that detects the partner and the communication and creates a counter entry. The partner "FPS" have been added to the VAT closing line for auto-reconciliation with bank transaction. task-5148985 Forward-Port-Of: odoo/enterprise#98224
Salary package offers created from the Offers list now receive a valid access token, so their links work reliably outside the system. This fixes a gap where manually created offers could generate invalid links, while also tightening access rules for offers tied to employees with user accounts.
Original PR description
- Go to Recruitment > Applications > All Applications. - Open an applicant form and click "Generate Offer". - Repeat a few times so that the "Offers" smart button shows a list view. - From the list…
- Go to Recruitment > Applications > All Applications. - Open an applicant form and click "Generate Offer". - Repeat a few times so that the "Offers" smart button shows a list view. - From the list view, click "New" to create an offer. - Compare both flows: * With "Generate Offer" button: the generated offer link has a valid token and works even in an incognito window. * With "New" button: the generated offer link has `token=False`, which leads to an invalid link. #### Issue In the first scenario, `action_generate_offer()` generates an `access_token` for the offer's link in `hr.applicant`. In the second scenario, no token was generated in `hr.contract.salary.offer`, so offers created via the "New" button end up with `access_token=False` in their links. #### Fix Add a compute to `access_token` in `hr.contract.salary.offer` to generate a token if there is no employee or if the employee on the offer has no linked user. #### Additional - Mark the field `access_token` as readonly. task-5051394
This fixes ESG carbon emission reporting so currency and unit values stay aligned when an emission factor changes. It helps users see accurate emission report details without stale or mismatched values.
Original PR description
The `currency` and `unit` fields on emitted emissions are supposed to be related fields on the emission factor. However, due to how the report combining accounting emissions and other emissions is implemented, they are not correctly updated when the factor is modified. This PR makes them computed fields and enable the "store" attribute en them. Despite there being no actual table to store data into, this allows us to do a round trip to the server to fetch the correct values. Forward-Port-Of: odoo/enterprise#98724
Project users can now create updates on budgeted projects without encountering an error. The fix keeps profitability information hidden when the user does not have access to the underlying data, preventing the project update form from breaking.
Original PR description
Currently an issue is generated when the project user tries to add a project update. Steps to produce an error: - Install the 'project_account_budget' module with demo data. - Log in with the demo…
Currently an issue is generated when the project user tries to add a project update.
Steps to produce an error:
- Install the 'project_account_budget' module with demo data.
- Log in with the demo user
- Go to Project and open the dashboard of the Home Construction project
- Click new »> error occurs
Error
```
QWebError
Error while rendering the template:
KeyError: 'revenues'
Template: project.project_update_default_description
```
This issue occurs due to:
- The reference commit [1] enhances the project update form description by enabling the display of profitability even without the sale timesheet.
- With commit [1], code was added to set the `profitability_values` to an `empty dictionary ({})` and `show_profitability` to `False` (see [2]) , since the demo user does not belong to the `project.group_project_manager` group (see [3]).
- In the `project_account_budget` module, the value of `show_profitability` is updated and set to True because the total_budget_amount is present in the project (see [4]).
- In the template `project_update_default_description` rendering, the `profitability` is accessed when `show_profitability` is `True`. However, since `profitability` is an empty dictionary, attempting to access the key will result in an error (see [4]).
This commit fixes the above issue by preventing the recalculation of `show_profitability`, as it is already set based on whether `profitability` data is available or not.
[1]: https://github.com/odoo/odoo/commit/e81af984aabe61defa0932b7890ab373fe3c8e2a
[2]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/models/project_update.py#L114-L126
[3]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/models/project_project.py#L1111-L1112
[4]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/views/project_update_templates.xml#L26-L31
Sentry-6915109069,6981931420
Forward-Port-Of: odoo/enterprise#98441Self-order restaurant printing now includes the required IoT Box information when loading preparation printers. This helps kitchen or preparation orders print reliably through supported IoT connection methods.
Original PR description
Loading IoT preparation printers in self order was not providing the ID of the IoT Box record, required to print using both webrtc/longpolling/websocket. This commit fixes this issue by loading the whole device record, same as we do to load preparation printers in the regular pos. Forward-Port-Of: odoo/enterprise#98710
The signing confirmation dialog now has the right spacing and size after a document is signed. This fixes a visual issue introduced by a shared dialog behavior change, improving the post-signing experience for users.
Original PR description
Version: - master Steps to reproduce: - Upload a document. - Sign the document. - Notice that the “Thank You” dialog appears with incorrect margins. Issue: - After this [PR](https://github.com/odoo/odoo/pull/226581) was merged into the web module, the dialog component behavior changed medium-sized dialogs no longer include padding by default. Since the “Thank You” dialog is a medium dialog, it now appears with incorrect margins after signing a document. Solution: - Added a CSS class to fix the margin and adjust the dialog size. <img width="1570" height="789" alt="image" src="https://github.com/user-attachments/assets/4c6766df-6cc1-497a-9dcc-39a5f60054e1" />
The Journal Report now updates its Global Tax Summary values when users change the rounding unit. This keeps tax totals consistent with the rest of the report and avoids confusion from mixed number formats.
Original PR description
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This…
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged. Cause: - The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns. Fix Applied: - Updated frontend (`filters.js`) to call `format_column_values_from_client` via `dispatch_report_action` instead of calling `format_column_values` directly. (this enables proper routing through the custom handler system) - Added `format_column_values_from_client` override in `JournalReportCustomHandler` that intercepts the formatting call and applies special handling for tax summary lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines` monetary fields using their `_no_format` counterparts. - The custom handler then delegates to the base method via `report.format_column_values_from_client()` to format standard columns. - Also added missing `_no_format` fields in `account_journal_report.py` for `base_amount` and `tax_amount` to enable proper reformatting. Forward-Port-Of: odoo/enterprise#98662 Forward-Port-Of: odoo/enterprise#94660
Several screens now use the current standard button styling instead of an outdated style that no longer works. This keeps action buttons visually consistent and avoids confusing or broken-looking controls for users.
Original PR description
*: account_budget,industry_fsm,l10n_pe_edi,mrp_workorder,sign `btn-default` doesn't exist anymore, this is a dead utility class. This commit changes it for `btn-secondary` task-5236550 Com PR: https://github.com/odoo/odoo/pull/234401
Payroll processing now handles payslips that have no detected issues without causing an error. This prevents interruptions when checking multiple payslips, making payroll validation more reliable.
Original PR description
When there are multiple payslip on which we call get_error_message, some may have no issues. In this case, it raises a traceback as issues is False. Introduced in https://github.com/odoo/enterprise/pull/94748 Forward-Port-Of: odoo/enterprise#98803
Authorized users who are not administrators can now settle due invoices as expected. The update ensures the required screens load correctly, removing an access-related blockage in the point-of-sale settlement flow.
Original PR description
Before this commit, a user without the "Role / Administrator" group could not settle invoices because the required views were not loaded. After this commit, the necessary views are properly loaded, allowing all authorized users to settle invoices as expected. opw-5138892 Forward-Port-Of: odoo/enterprise#98487
This update resolves an internal warning in the Hong Kong payroll integration by using the correct access-checking method. It helps keep payroll processing stable and reduces noise from build or validation checks without changing business workflows.
Original PR description
Use `check_access` instead build-error-233453 Forward-Port-Of: odoo/enterprise#98654
### Before: - While printing payslip previously if an employee do not have any bank linked we were not printing anything,. ### After: - If no bank account present we will use: Amount to be paid to [employee_name]: [amount] task- 5101235 Forward-Port-Of: odoo/enterprise#95125
Original PR description
### Before: - While printing payslip previously if an employee do not have any bank linked we were not printing anything,. ### After: - If no bank account present we will use: Amount to be paid to [employee_name]: [amount] task- 5101235 Forward-Port-Of: odoo/enterprise#95125
The settings page now makes it clearer that accounting can be configured for inventory loss and production locations, including a direct link and helper text. This helps users find the right configuration when managing periodic closing alongside perpetual inventory accounting.
Original PR description
Forward-Port-Of: odoo/enterprise#98289
12 changes
Resolved issues and error corrections
This change prevents a product added through a combo from being mixed up with the same product added separately on a sales order. As a result, the correct line is created and prices are no longer incorrectly merged, avoiding billing errors.
Original PR description
Steps: - create a product with attributes of create_variant=never - set variant selection to order grid entry - add this product as a combo choice and set extra_price>1 - In sale order form first add the new combo product with the previously created product - add the new product with same selection of attribute values as combo Issue: - The separately added product should create a new line, but since it was added as a part of the combo, the product's price is summed with extra price and added to the combo itself Cause: - the grid field that is responsible for adding product using product matrix does not filter combo lines Fix: - added filter for combo lines when matrix opens and saves opw-5164789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234102
Withholding invoices now include the VAT percentage correctly in the Nilvera e-invoice data. This fixes the VAT amount display in the PDF, so customers see the right tax information on their invoices.
Original PR description
Before this commit: For withholding invoices, the VAT percentage was not included inside the <cac:TaxTotals> node, due to this, the VAT amount was not displayed in the PDF in Nilvera. After this commit: The VAT amount is shown correctly in the <cbc:Percent> node inside the <cac:TaxTotals> node and percent amount appears correctly in the PDF. task-5225600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234063 Forward-Port-Of: odoo/odoo#233929
This change ensures that when a component line is removed in the subcontracting wizard, it is fully deleted instead of being left behind as an invisible record. This prevents confusing leftover entries in inventory reports and keeps production data accurate.
Original PR description
Issue ----- Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML. Steps to reproduce ----- - Create a subcontracted product with 2 components - Add…
Issue ----- Removing a line using the subcontracting wizard does not delete the line in DB, there is a "phantom" ML. Steps to reproduce ----- - Create a subcontracted product with 2 components - Add one of each component in subcontractor's stock - Create a PO for the finished product and confirm it - Go to the production - Open the "Record components" wizard - Set quantity then remove the second line - Confirm production (don't update consumption) - Go to Inventory > Reporting > Moves History and remove the "Done" filter > There is a pending move in the report Cause ----- When saving the wizard's changes, we call a write on the production's `move_line_raw_ids` field to remove delete the line. The field is a simple compute, so we go through its' inverse method https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/mrp_subcontracting/models/mrp_production.py#L34-L46 The problem is that we populate `line_by_product` using the values present in `move_line_raw_ids` from which we just removed the line. This means that when we do `move.move_line_ids = line_by_product.pop(move.product_id, self.env['stock.move.line'])` we replace the value of `move_line_ids` with only the remaining ones, which means we unlink the move line (*from the move*). Because the inverse field (`move_id` of the SML) is not set as `ondelete='cascade'`, the link is broken but the line remains in db. https://github.com/odoo/odoo/blob/f173c738b1adcf85a80eb641ad307b7cccf17294/odoo/fields.py#L4311-L4322 We cannot change the field to `ondelete='cascade'` as such a change would not be stable. Solution ----- Keep reference of the lines to be removed in order to delete them once `move_line_ids` has been updated. ----- Ticket: opw-4817397 Forward-Port-Of: odoo/odoo#234180 Forward-Port-Of: odoo/odoo#229310
We fixed an issue in the salary calculator that could increase the Salary field incorrectly when switching employees. The calculator now also handles employees with existing payslips properly, so the displayed figures are filled in and calculated as expected.
Original PR description
- fixed a bug where the value of `Salary` field gets incremented when selecting another employee instead of computing the correct value
- fixed a bug of wrong calculations when the employee has a generated payslip
- Steps to reproduce:
- create a payslip for the employee
- open the salary calculator and select this employee
- the values are wrong or not filled because the `salary_simulation` wasn't set correctly on the simulation version
- added `test_simulation_offer_with_existing_payslip` for the salary calculator
task-id: 5065138This fix removes Chinese yuan (CNY) from the currencies offered by PayPal payments in Odoo. As a result, customers will no longer reach a payment flow that PayPal cannot complete, avoiding failed invoice payments and confusion.
Original PR description
## Versions 18.0+ ## Issue No payment is possible with PayPal for invoices expressed in Chinese currency. ## Steps to reproduce **`account` app required** - Enable "CNY" currency via `Invoicing /…
## Versions
18.0+
## Issue
No payment is possible with PayPal for invoices expressed in Chinese currency.
## Steps to reproduce
**`account` app required**
- Enable "CNY" currency via `Invoicing / Configuration / Accounting / Currencies`;
- Install, setup and publish PayPal payment provider;
- Move to the Invoice app:
- Create a new invoice in "CNY" currency for any customer with at least 1 product;
- Confirm and click on the preview button:
- Click on the "Pay now" button then "Pay" button of the wizard.
## Cause
"CNY" currency is only supported for Chinese accounts and for transactions occurring in China. PayPal says:
> Please note that Chinese Renminbi (CNY) is supported as a payment currency (buyer currency) or settlement currency (holding currency) only for in-country PayPal accounts. If the settlement account is based outside of China, PayPal will convert the funds into the account’s primary currency using the applicable currency conversion rate, which includes a spread or fee.
opw-5071893
Forward-Port-Of: odoo/odoo#232092This change adds a check to make sure menu entries still exist before the system tries to use them. It prevents upgrade and maintenance failures in HR-related apps when menus have been removed, improving reliability for affected databases.
Original PR description
To Reproduce: 1) make a database in 16.0 and go to developer mode. 2) Delete the menus 3) I mocked the views with upgrade mockcrawler. it failed for these xmlids: ``` hr_attendance.menu_hr_attendance_attendances_overview hr_timesheet.timesheet_menu_activity_use hr.menu_hr_employee ``` but we should have a check anyways. 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#230135 Forward-Port-Of: odoo/odoo#215426
This update ensures that when someone signs a document while logged in as a different user, the system no longer uses the other user’s saved signature. It also adds a clear note in the signing certificate to show that the document was signed through another account, improving transparency and trust.
Original PR description
Before this commit, we allow to sign on behalf on another user but we should not fetch his saved signature. We want that when a user is signing from the account of another user: - we don't load the signature of the user (saved in the user profile) - we have a mention in the certificate that the document was signed via another user. task-5223975
A quality form view was moved to the module that actually depends on the required manufacturing work order features. This fixes module loading issues and helps ensure the view is available in the right place without causing installation or upgrade problems.
Original PR description
view `quality_point_routing_view_form_inherit_quality_mrp` was supposed to be in the module `quality_mrp_workorder` as it has `quality` and `mrp_workorder` as dependency.
The warehouse duplication test now checks whether a purchasing-related field exists before using it. This prevents the test from failing in setups where the purchasing module is not installed, making the test more reliable across different environments.
Original PR description
The test `test_duplicating_warehouses_recreates_their_routes_and_operation_types` was failing with:
AttributeError: 'stock.warehouse' object has no attribute 'buy_to_resupply'
A recent change added to the test :
wh_original.buy_to_resupply = False
However, `buy_to_resupply` is defined in `purchase_stock`. When this module is not installed, the field is absent and the test crashes.
Fix:
Only assign the field if it exists on stock.warehouse.
[RB-232580](https://runbot.odoo.com/odoo/error/232580)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prWhen customers booked a table from the website, the phone number field could stay empty. This update correctly copies the phone number from the related contact so staff can reach the customer more reliably.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/project/1737/tasks/5005216) --- The phone number field was not being populated correctly when booking a table from the website. It is now properly filled using the phone number of the `res.partner` associated with the appointment. The field remains unlinked to the partner, as it is just a copy. Forward-Port-Of: odoo/enterprise#92836
This fix makes the email loop protection only count actual incoming emails, instead of also counting other message types. As a result, legitimate emails are less likely to be blocked by mistake when a thread includes non-email activity from the same sender.
Original PR description
When detecting loops with _detect_loop_sender if the count of these messages exceeds the LOOP_THRESHOLD, the next email from that user is blocked, even if the number of new emails alone hasn't yet crossed the threshold due to mail messages that are not email triggering the loop detection. This happens because it searches for messages in the mail.message model that share the same model name and author irrespective of the message type. To correct this, the function's search criteria must be modified to explicitly filter for messages where the message_type is set to 'email'. opw-5122962 Forward-Port-Of: odoo/odoo#232534 Forward-Port-Of: odoo/odoo#232026
This fix prevents quotation preview from crashing after a report has been customized in Studio. It ensures the portal preview uses the same data reference as the edited report, so users can continue reviewing quotations normally.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to…
Versions -------- - 17.0+ Steps ----- 1. Edit the `sale.report_saleorder` report using `web_studio`. 2. Add the `amount_untaxed` field next to the "Untaxed Amount" subtitle. 3. Create or navigate to a quotation and click on the "Preview" action. Issue ----- A traceback occurs during the rendering of the `sale.sale_order_portal_template` template. ``` Error while render the template KeyError: 'doc' Template: sale.document_tax_totals Path: /t/t/tr/td[1]/span Node: <span t-field="doc.amount_untaxed"/> The error occurred while rendering the template sale.document_tax_totals and evaluating the following expression: <span t-field="doc.amount_untaxed"/> ``` Cause ----- In the `sale.report_saleorder_document` template, `doc` is used as the variable name for the current sale order. Consequently, the studio edit uses this variable name to modify the `sale.document_tax_totals` template called within `sale.report_saleorder_document`. However, the `sale.sale_order_portal_template` template, used for the portal preview, also calls `sale.document_tax_totals` but uses `sale_order` as the variable name for the current order. Solution -------- Add an alias `doc` for `sale_order` during the rendering of `sale.document_tax_totals` when called in the portal report preview. opw-5136553 Forward-Port-Of: odoo/odoo#233755
22 changes
Resolved issues and error corrections
This fix prevents an error when sending credit or debit notes to DGI if the original document is not a valid electronic invoice. Instead of failing with a technical traceback, Odoo now shows a clear message so users can correct the source document before retrying.
Original PR description
### Description of the issue/feature this PR addresses: When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document…
### Description of the issue/feature this PR addresses:
When informing a Credit or Debit Note to DGI we always need to inform the related original document, Before this change is the related document is not a real CFE then will raise a traceback error
### Steps to reproduce:
1. Create an e-invoice and confirm in Odoo (without sending to DGI)
2. Create an e-credit note from the e-invoice created in (1) and confirm
3. Try to send the credit note to DGI
The result is a traceback:
```
RPC_ERROR
Odoo Server Error
Occured on 18.core.odoo.localhost on model account.move.send.wizard on 2025-10-21 20:47:48 GMT
Traceback (most recent call last):
File "/home/odoo/custom/odoo/odoo/http.py", line 2144, in _transactioning
return service_model.retrying(func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/service/model.py", line 156, in retrying
result = func()
^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2111, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 2359, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/http.py", line 754, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/odoo/api.py", line 535, in call_kw
result = getattr(recs, name)(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/wizard/account_move_send_wizard.py", line 294, in action_send_and_print
attachments = self._generate_and_send_invoices(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 719, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/custom/odoo/addons/account/models/account_move_send.py", line 620, in _generate_invoice_documents
self._call_web_service_before_invoice_pdf_render(invoices_data_web_service)
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move_send.py", line 88, in _call_web_service_before_invoice_pdf_render
invoice._l10n_uy_edi_send()
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 813, in _l10n_uy_edi_send
request_data = move._l10n_uy_edi_prepare_req_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 787, in _l10n_uy_edi_prepare_req_data
xml_content = self._l10n_uy_edi_get_xml_content()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 773, in _l10n_uy_edi_get_xml_content
"referencia_lines": self._l10n_uy_edi_cfe_F_reference(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/account_move.py", line 381, in _l10n_uy_edi_cfe_F_reference
cfe_serie, cfe_number = self.l10n_uy_edi_document_id._get_doc_parts(related_cfe)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/custom/enterprise/l10n_uy_edi/models/l10n_uy_edi_document.py", line 215, in _get_doc_parts
return re.findall(r"([A-Z]{1,2})[-]*([0-9]{1,8})", record.l10n_latam_document_number)[-1]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^
IndexError: list index out of range
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3162:163)
at XMLHttpRequest.<anonymous> (http://18.core.odoo.localhost/web/assets/c15481d/web.assets_web.min.js:3167:13)
```
### Desired behavior after PR is merged:
Now we ensure to show a proper message to the user to fix the problem: the original document should be a electronic one
<img width="1203" height="664" alt="after" src="https://github.com/user-attachments/assets/bb7b105e-12f0-4935-b6bc-37edb3bc3aca" />
References LATAM 1301 / ADHOC Task 54770This fix prevents the editor toolbar from switching to the wrong set of buttons when users apply formatting on mobile. As a result, the toolbar stays in its normal state and the active formatting button is highlighted correctly, making mobile editing more reliable.
Original PR description
**Current behavior before PR:** In mobile view, when applying the bold format using the toolbar button, the normal toolbar is incorrectly replaced by image toolbar. This occurs because `getFilteredTargetedNodes` returns an empty array, and as a result, the `isApplied` method evaluates to true since Array.every on an empty array returns true. **Desired behavior after PR:** This PR ensures that the toolbar remains in its normal state when a format is applied via the toolbar button. The corresponding format button (e.g., bold) is correctly highlighted. task-5123317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents the SEO optimization dialog from crashing when the website preview is still loading, especially on slower connections. It now waits until the page frame is ready, so users can open the dialog more reliably without errors.
Original PR description
Steps to reproduce: - Open Website app and enter edit mode on any page. - Reload the page with a slow connection. - Immediately open "Optimize SEO" from the navbar menu. Before this commit, the dialog accessed the preview document while the iframe was reloading, so reading location.origin raised a TypeError. After this commit, the dialog waits for the iframe to finish loading or returns immediately when it is already complete, preventing crashes. task-5104033
This change corrects how stock balances inventory records when a product is delivered with a lot or serial number. It prevents the system from assigning the adjustment to an empty tracking record, so future receipts with the correct lot are matched properly and stock stays accurate.
Original PR description
Uecase to reproduce: - Create a quant with a product and 10 lot A - Create a delivery order - Open barcode - In barcode, deliver the product with lot C Current behavior: You have 2 quants: - 10 lot A - -1 without lot Expected behavior: - 10 lot A - -1 lot C It happens because the code try to balance negative quant for lot/sn in a stack of quants without lot/sn for the product. However in this case the barcode create a quant without quantity and without lot. In this case the system wants to update it due to an incorrect condition. It's an issue since in later receit with the correct lot. The quant will never be balanced and it will result with - -1 without - 1 lot C 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#231853
This update prevents unexpected stock entries from being created when users view location or inventory reports for subcontracted products. It keeps on-hand quantities accurate, so receipt validation and stock tracking work as expected.
Original PR description
Issue: -------- When working with a subcontracted product, confirming the purchase order and opening the physical inventory or location report creates an unwanted quant for the final product. Later,…
Issue: -------- When working with a subcontracted product, confirming the purchase order and opening the physical inventory or location report creates an unwanted quant for the final product. Later, when validating the receipt picking, an extra quant appears in the subcontracting location with on-hand quantity. Steps to Reproduce: -------------------------- 1. Install `mrp_subcontracting`. 2. Create a lot-tracked subcontracted product and its BoM. 3. Create and confirm a purchase order for the main product. 4. Check the location report → a line with reserved qty is created. 5. Validate the receipt picking. 6. Check the location report again → an extra on-hand qty appears in the subcontracting location. Cause: ----------- When opening the location report, the scheduler (`_quant_tasks`) triggers `_clean_reservations`. In this process, the bypass logic for reservations is not applied in the subcontracting case, leading to the creation of a reserved quant. During picking validation, this quant is included in the `quants_cache` inside `_action_done`. Later, `_synchronize_quant` and `_update_available_quantity` use it, resulting in an extra quant being created in the subcontracting location. Fix: ------ Bypass the creation of reserved quants when opening the location report for subcontracting cases. This prevents unwanted quants and ensures correct on-hand quantities in subcontracting locations. After this Commit: ------------------------- No extra quants will be created in subcontracting locations when viewing location reports. Users will see accurate on-hand and lot quantities, ensuring a smooth and reliable workflow. Task ID: 5115466
Table booking notifications are now sent only for bookings that match the appointment type configured in the POS settings. This prevents irrelevant bookings from appearing on the floor plan and avoids bookings disappearing after a refresh when no matching setup exists. The POS configuration also now clears the appointment type automatically when table booking is turned off.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/my-tasks/5005216) Enterprise v17.0: [#93714](https://github.com/odoo/enterprise/pull/93714) --- **Before:** If no appointment type is specified in the POS config and a table is booked via the website, the floor plan is notified of a new booking because the resource used is one of the POS config resources. However, if the page is refreshed, the booking disappears since no appointment type is defined in the POS config **After:** The floor plan is notified of a new booking only if the appointment type of the booking matches the one specified in the POS config. If no appointment type is set in the POS config, no booking notifications are sent. Additionally, when the "Table Booking" field is unchecked in the POS config, the appointment type is automatically unset.
The invoice totals on printed documents now use the company’s theme color consistently for both the label and the amount. In layouts with a colored totals area, the text also switches to a contrasting color so it remains easy to read.
Original PR description
Issue: - Totals amount text stayed black in invoices when using SA (and other) templates. - Only the label (inside strong) changed color, the value (inside span) did not. - In Boxed/Bubble, totals…
Issue:
- Totals amount text stayed black in invoices when using SA (and other) templates.
- Only the label (inside strong) changed color, the value (inside span) did not.
- In Boxed/Bubble, totals row has a colored background but text didn’t always switch to a readable .
Repro steps:
- Create company in Saudia Arabia
- Company → Document Layout: Light or Boxed (others also affected).
- Create a customer invoice with taxes and print without payment.
- Observe totals: label colored, amount remains black. In Boxed, amount can be unreadable over the colored background.
Cause:
- CSS targeted .o_total strong only; amounts are in span, so they weren’t colored.
Boxed sets totals cell background to the company primary, but text color didn’t flip to a contrast color.
Solution:
- General (all layouts): color the whole totals cells so label + amount are styled:
.o_total td { color: <company primary>; }
- Boxed override: ensure readable contrast on colored background:
#total .o_total td { background-color: <primary>; color: preview-color-contrast(<primary>); }
#total .o_total td strong { color: inherit; }
opw-5169079
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUsers can now edit analytic distributions for batch payments directly in the bank reconciliation screen without running into validation errors. This makes the reconciliation flow work as expected and avoids blocks when handling batch payments.
Original PR description
**Issue** Users were unable to set analytic distributions on batch payments via the bank reconciliation widget. This limitation could lead to validation errors. **Steps to Reproduce** 1. Create two customer payments 2. Group them into a batch and validate it 3. Open the bank reconciliation widget 4. Create a bank statement line 5. Navigate to the batch payment tab and click on the batch payment 6. Attempt to click on the batch payment line **Root Cause** The method handleLineClicked was overridden in a way that prevented the call to the parent implementation when the flag was 'new_batch', disabling interactivity for these lines. **Fix** The restrictive override of handleLineClicked was removed. All fields in the Manual Operations tab are made read-only, except for analytic distributions, as this is the only field users should be allowed to edit in this context. Opw-4757131
When a lead automatically gets linked to a contact after sending an email, Odoo will now keep any manually entered contact and company names instead of replacing them with partner data. This prevents users from losing information they typed into the lead and keeps the record more accurate.
Original PR description
Description of the issue/feature this PR addresses: When a lead with manually entered contact_name and partner_name fields sends an email through a template, the _message_post_after_hook method…
Description of the issue/feature this PR addresses: When a lead with manually entered contact_name and partner_name fields sends an email through a template, the _message_post_after_hook method automatically assigns a partner_id based on the email address. This triggers the computed fields _compute_contact_name and _compute_partner_name, which overwrite the manually entered values with data from the partner record, causing data loss. Current behavior before PR: 1. User creates a lead with contact_name="person1", partner_name="company1", and email_from="person1@company1.com" 2. User sends an email template from the lead 3. System automatically finds/creates a partner and assigns it to partner_id 4. The _compute_contact_name and _compute_partner_name methods are triggered 5. Bug: Manual values are overwritten with partner data (e.g., contact_name changes from "person1" to "company1" if the partner is a company) Desired behavior after PR is merged: 1. User creates a lead with contact_name="person1", partner_name="company1", and email_from="person1@company1.com" 2. User sends an email template from the lead 3. System automatically finds/creates a partner and assigns it to partner_id 4. The _compute_contact_name and _compute_partner_name methods are triggered 5. Fixed: Manual values are preserved when partner data is empty or missing (e.g., contact_name remains "person1") Video with the problem: https://drive.google.com/file/d/1R0z6Rfni5J9b4iWpUxqKzyOvMIYjjMgA/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update restores the Swedish point-of-sale test tour by adding the missing IoT device mock. It matters because it allows the automated checks for this POS flow to run correctly again after earlier changes.
Original PR description
Due to changes introduced in odoo/enterprise#98179, the Swedish blackbox POS tour was broken. The fix is to add a mock for the IoT device, which was done in the forward ports but missed in 18.0. This commit adds the IoT mock to fix the tour. runbot-233700
This update adds the missing currency symbol next to event ticket prices in the event form. It makes pricing clearer for users and helps avoid confusion when working with ticket costs.
Original PR description
Add missing currency symbol next to the event ticket price in the event form view. Task-5114075 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects how shipping amounts and weights are rounded before being sent to DHL. It prevents shipments from failing validation due to tiny floating-point precision errors, helping ensure DHL deliveries can be processed successfully.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#96012
This fix ensures subscription invoices keep the correct billed quantity when only part of an invoice is refunded. Previously, a partial credit note could make the system think nothing had been invoiced, which could lead to wrong subscription quantities and billing records.
Original PR description
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is…
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the credit note. 6. The subscription order line shows qty_invoiced = 0 instead of the expected 20. **Root Cause** The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced` **Fix** Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity Opw-4908760
Fixed an issue in the Barcode app where available stock was not refreshed after changing the product or source location on a transfer. This ensures users see the correct quants immediately, reducing confusion during warehouse operations.
Original PR description
Issue: In this bug, stock quants are not being updated when product_id or location_id is updated. To reproduce: 1- Create a db with demo database and barcode installed 2- Enable storage locations 3- Open barcode -> operations -> Internal transfers -> New 4- Add a product -> e.g. Drawer which there are quants in demo 5- As you see quants are not shown Cause and Fix: This is a partial backport of: #55917 `_compute_product_stock_quant_ids` should depend on `product_id` and `parent_location_id` to be recomputed when product or source location is updated. opw-5065624 Forward-Port-Of: odoo/enterprise#95906
This change fixes a formatting issue in the editor where empty items inside tables or lists were not being handled correctly. It helps keep content consistent when users leave nested blocks empty, improving the reliability of edited documents.
Original PR description
Description of the issue this PR addresses: Commit [1] ensured that empty nodes are filled, but only handled the last element itself. If the last element was a container block (e.g, a table or list) containing empty child blocks such as or , those inner nodes were not filled. This commit ensures that is also applied to those leaf empty blocks nested within such container elements. [1]: 133478b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in the yearly calendar where some end dates could disappear from view when the screen was zoomed and the user scrolled to the bottom. The calendar now reacts properly to window size changes, so dates remain visible and easier to read.
Original PR description
Before this commit, when zooming on the screen in the yearly calendar and scrolling down to the bottom, some end dates are not visible. By merging this commit, resolved dates will be visible on screen when scrolling down to the bottom by responding to window size changes in the DOM. task-4809668 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
This update fixes several spelling mistakes in the Surveys app, including menu labels, breadcrumbs, dashboard text, and a column heading. It improves the clarity and professionalism of the user interface, but does not change how the feature works.
Original PR description
**Surveys app misspellings on main menu item, dashboard name, breadcrumbs, and column label** Impacted versions: - 16.0+ (confirmed on Runbot, however the PR target is 18.0+ to only be applied on the latest stable release) Steps to reproduce: 1. Open any Community Runbot (or deploy Odoo locally) 2. Navigate to the **Surveys** app to view misspelling across multiple app views. Current behavior --> Expected behavior - "Participations" is not a word --> It should be "Participants" - "Quizz" is misspelled --> It should be "Quiz" Proposed changes highlighted in green [here on the screenshots](https://imgur.com/a/0vM48R0). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a problem in the editor where selecting table cells from right to left or bottom to top in Firefox could drop the first cell from the selection. It improves the reliability of table editing for users working in Firefox.
Original PR description
Steps to Reproduce: 1. Create a table in the editor (Firefox). 2. Select table cells backward (right → left or bottom → top). Description of the issue this PR addresses: - The first selected cell does not remain selected in Firefox when extending the selection backward. task-5094832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change stops users from canceling a manufacturing order that has already been completed. Instead of canceling related stock movements by mistake, the system now shows a clear error message so the finished order remains protected.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to select an employee. -> No records found. Note: the many2one_avatar_employee widget used in HR apps avoid this problem. **Cause** Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374 The `web_search_read` on the private employee model returns no record
Original PR description
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to…
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to select an employee. -> No records found. Note: the many2one_avatar_employee widget used in HR apps avoid this problem. **Cause** Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374 The `web_search_read` on the private employee model returns no records when an `image_*` or `avatar_*` field is part of the requested fields. This is because we try to fetch these fields https://github.com/odoo/odoo/blob/188a3fe45fb41463ff86d1fa5e930ab43fb70d0e/addons/hr/models/hr_employee.py#L240 but they are not stored on the public employee model, and will not be put in cache. When performing a read after that, these fields are missing from cache. We try to fetch them from the db https://github.com/odoo/odoo/blob/e962860c6f0d8ec9e50bb376e1faab5c7bc69374/odoo/models.py#L3185 but this fetch is again done using the public employee. This results in missing values and is interpreted as an access error, no data is returned in `web_search_read`. **Solution** Read the problematic fields to make them present in cache when the cache of the public employee is copied to the one of the private employee. opw-4297115 Forward-Port-Of: odoo/odoo#197575
This change fixes an issue where partner details used for Peppol verification could briefly become inconsistent when multiple updates were applied separately. As a result, validations are now more reliable and less likely to fail with mismatched endpoint information.
Original PR description
In some cases, when doing two consequent writes instead of one batch, the ORM will trigger the dependencies needlessly, and it can end up to discrepancies like: EAS=0208, endpoint=BE... which lead to a validation error. opw-5228670 opw-5225590 opw-5228716 opw-5229057 opw-5232276 Forward-Port-Of: odoo/odoo#234290
This fix stops users from canceling a manufacturing order that has already been completed. Instead of canceling a related stock transfer by mistake, the system now shows an error and keeps the completed order unchanged.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-52162206 changes
Resolved issues and error corrections
This fixes incorrect inventory valuation records when subcontracted products are delivered directly from a vendor to a customer. It prevents those transactions from affecting FIFO and other costing calculations, helping keep inventory values accurate for products that never physically enter stock.
Original PR description
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a…
… correct remaining value when sbc dropship **Problem:** When selling and delivering a subcontracted and dropshipped fifo product, the incoming stock valuation layer has a remaining_qty and a remaining_value. (This also happens with 'standard price' and 'avco' but it's mostly problematic for fifo products. This being said the fix solves all 3 cases) Some context: When we confirm a SO and validate the delivery of a dropshipped (not sbc) product, two svls are created, - one with a negative quantity and value. - one with positive quantity and value. Both have a zero remaining value and remaining quantity. The outgoing svl does not trigger run_fifo or decrease the remaining_qty and remaining_value on any svl. In other words the fifo logic is not applied. If it was the case, the dropship delivery would impact the fifo valuation and other layers which we don't want as the product never really entered the stock. In the use case of this PR, a subcontracted dropshipped fifo product being delivered, the outgoing svl(s) are linked to the dropship and have the correct values. But the incoming svl is linked to the subcontract order and has a remaining value and remaining quantity which will impact the fifo logic when it shouldn't. **Steps to reproduce:** - enable the subcontracting setting and the dropshipping setting. - create a storable product, with a fifo category and positive cost. - create a subonctracted bom with a consumable component. - in the purchase tab of the product set a vendor which is the same as the subcontractor of the bom. - in the inventory tab select only the dropship route - create and confirm a SO for this product. - on the PO enter a positive unit price and confirm - validate the dropship delivery - click on the valuation smart button **Current behavior:** the stock valuation layer linked to the subcontract picking (the one with a positive quantity) has a positive remaining quantity and remaining value. **Expected behavior:** As the product is dropship remaining quantity and remaining value should be 0 **Cause of the issue:** When action_done is called on the picking: 1) In the super method, action_done is called on the move. There, _create_dropshipped_svl is called. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 Inside _get_dropshipped_svl_vals only the value for the (first) outgoing svl is returned because the location_id (subcontrating location) is valued. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L226 2) In the mrp_subcontracting override, button_mark_done is called on the mrp.production associated with the picking. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting/models/stock_picking.py#L90 Therefore action_done is called on the finished products move the mrp.production. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp/models/mrp_production.py#L1731 The move is a 'in' move so this lead to the creation of an in svl. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/stock_account/models/stock_move.py#L289 The problem is that there is no mechanism to prevent the in svl from having a remaining_value and remaining_qty **fix** The mrp_subcontracting_dropshipping override of _action_done (on stock picking) is where, when needed, the other ougoing layer is created specifically in this subcontracting dropshipping use case. https://github.com/odoo/odoo/blob/3c83171923124c7ea63a4d33262a87cddf004b2b/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L27-L32 Because the conditions are the same, imo, it's a good place to set the value of remaingin_value and remaining_qty of the incoming svl to 0. opw-5184644
This update fixes several website editing problems that could cause undo actions to behave incorrectly and certain form options to appear repeatedly. It also corrects donation payments so the updated amount is used after returning to the page, improving reliability for website visitors and editors.
Original PR description
*:website, website_payment > Commit 1: [FIX] web_editor: prevent infinite bounce loop when clicking undo Steps to reproduce: 1. Click on a snippet without dragging it. 2. Notice that the "Drag…
*:website, website_payment > Commit 1: [FIX] web_editor: prevent infinite bounce loop when clicking undo Steps to reproduce: 1. Click on a snippet without dragging it. 2. Notice that the "Drag building blocks here" section starts bouncing. 3. Observe that a step is added to the history (Undo becomes available). 4. Click on Undo button. Issue: 1. The `o_catch_attention class` is repeatedly added and removed, creating unnecessary history steps in the editor. 2. No actual changes occur in the wrap area, yet the editor records history steps. 3. This leads to an infinite bounce loop when using Undo/Redo. Expected behavior: 1. The Undo button should not be activated. 2. Infinite bouncing should not occur. This PR prevents unnecessary history steps by disabling history tracking during this phase using `observerUnactive` and `observerActive`. This ensures that the editor does not record redundant changes, preventing infinite bounce loops. > Commit 2: [FIX] website_payment: fix donation amount not updating issue Steps to Reproduce: 1. Go to Website → Add a Donation snippet. 2. Enter a custom amount and click "Donate". You will be redirected to the donation/pay page. 3. Use the browser's back button to return to the previous page. 4. Change the amount in the custom amount field. 5. Click "Donate" again. - The old amount is still used instead of the new one. Expected Behavior: The donation amount should update correctly when changed. The issue occurs because clicking the "Donate Now" button appends a hidden value to the form snippet, which is then used in payment_form. When navigating back and selecting "Donate Now" again, a duplicate hidden value is added instead of replacing the previous one. This PR ensures that if a value already exists, it is replaced instead of being appended, resolving the issue. > Commit 3: [FIX] web_editor: fix dropdown options value Steps to reproduce: 1. Go to the website and drag and drop the form snippet. 2. Change the action to 'Subscribe to Newsletter'. 3. Click on multi-checkbox field to view its options. - Even after selecting an option, it remains in the dropdown, allowing multiple selections of the same option. Expected behaviour: - Once an option is selected, it should be removed from the dropdown. Solution: This PR removes the count from the display name, ensuring correct form behavior. task-4583314
This update prevents an error that could appear when closing or canceling a helpdesk ticket after SLA working hours have been cleared. It ensures the ticket workflow only checks working hours when that setting is actually in use, so agents can complete tickets without interruption.
Original PR description
> **The issue:** When you go to a helpdesk's team settings -> SLA Policies -> Working hours, set the working hours to empty and then disable SLA Policies and save. After that if you try to move a ticket in the same team to done or canceled you will receive an exception. **Cause:** The part of the code causing the issue is supposed to only run if a Working Hours policy is set. **Fix:** Changed the section of the code to only run when Working Hours is set. opw-5120962 >
This change prevents an error that could appear when opening a stock quantity record without a location set. It keeps the Inventory app working smoothly in this edge case and avoids a confusing failure for users.
Original PR description
Currently, an error is produced when accessing the stock quant form view without a location set. **Steps to Reproduce: (V18.0)** - Install the **Inventory** app. - Create a product with tracking enabled (**Lots/Serial Numbers**). - Click **"Update Quantity"** (opens list view). - Click New and then click View on the unsaved record (opens **form view**). - Remove the **Location** field. **Error:** `TypeError - sequence item 0: expected str instance, bool found` This issue does not occur in v17.0 as the `stock.quant` model has no direct form view. **Cause:** In the display name computation ([1]), the code attempts to join name parts where one of them can be `False` if the location is not set. [1] - https://github.com/odoo/odoo/blob/2e97690e312c7c7e24dd550dd5d0112af6223816/addons/stock/models/stock_quant.py#L613 **Fix:** The display name generation now checks `location_id` before joining, preventing the error. Sentry - 6717759358
This change prevents duplicate withholding tax records from being created when the Argentina withholding demo data is installed. It helps keep the tax configuration clean and avoids confusion for users reviewing accounting setup.
Original PR description
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo…
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo data. 2. Take position in "(AR) Responsable Inscripto" company. 3. Check the taxes created on "Invoicing > Configuration > Accounting > Taxes". 4. Delete the filter "Sale or Purchase". 5. Add custom filter: Argentina Withholding Payment Tax type (l10n_ar_withholding_payment_type) is in ["supplier", "customer"]. 6. You will see that there are duplicated taxes (duplicated names) with suffix (Copy). **Current behavior before PR**: Duplicated taxes are created when demo data is installed. <img width="1583" height="784" alt="image" src="https://github.com/user-attachments/assets/49c9f4d4-b599-427b-a786-51191685b3fd" /> **Desired behavior after PR is merged**: No duplicated taxes are created when demo data is installed. _Task latam side_: 1360. _Task Adhoc side_: 57627. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can no longer create private Knowledge articles when they do not have the proper create permission. The interface also hides the create buttons in those cases, which prevents confusion and keeps what users see aligned with what they are allowed to do.
Original PR description
How to Reproduce : 1. Remove 'Create' access on the 'Knowledge Article' model for Portal and Internal users. 2. Now log in as a Portal. 3. Try to create a new private article. 4. Log in as an…
How to Reproduce : 1. Remove 'Create' access on the 'Knowledge Article' model for Portal and Internal users. 2. Now log in as a Portal. 3. Try to create a new private article. 4. Log in as an Internal user. 5. Try to create a new private article. Both Internal and Portal users can still create private articles even after 'Create access' is removed. Article creation logic in `knowledge.article` was bypassing the usual access rights because of `sudo` (mainly to add the creator as a member, since creation rights on the member model are not granted). This allowed users to create private articles even without create access. This commit introduces: 1. Model-level access check in `create`. Sudo the creation of articles only when the user has create rights. 2. UI imp to hide the '+' button in the sidebar and the `New` button in the topbar when the user doesn't have create access. 3. New test cases to verify that model-level access rights are respected when creating an article. task-4916280