Wednesday, November 5, 2025
30 changes · saas-18.4
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#90281This update corrects the invoice information sent to Chorus Pro so it complies with Peppol BIS3 rules. It also renames a label to better match Chorus Pro terminology, helping reduce invoice rejections and confusion for French e-invoicing users.
Original PR description
1. We didn't met one of the specific requirement of the BIS3 invoices to be sent through Chorus Pro. > The SIRET number for the final recipient, behind Chorus Pro should always be sent in the following tag: Invoice/cac:AccountingCustomerParty/PartyLegalEntity/CompanyID 2. One of the attributes of the CompanyID was set to schemeName which is not a valid attribute of the Peppol BIS3 specification. Fixed in 18.0+: https://github.com/odoo/odoo/commit/c3ae4b29c51c7b0cff11aac5f4bf4aab5fad16c9 task-none (possible opw-4972189, but might not be the only problem) Source: <img width="787" height="673" alt="image" src="https://github.com/user-attachments/assets/2a410fa8-572a-4738-aa5d-764e91271880" /> https://www.pagero.com/onboarding/aife/aife-en Forward-Port-Of: odoo/odoo#234034 Forward-Port-Of: odoo/odoo#229014
The edit favorite filter icon in the search menu no longer flickers when users hover over it. This makes the interface feel smoother and avoids small layout shifts in the popover.
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 Forward-Port-Of: odoo/odoo#234383
This update corrects how overtime one-time payments are handled in Swiss payroll transmission. It helps ensure these payments are sent accurately, reducing the risk of payroll errors or missing overtime compensation.
Original PR description
Forward-Port-Of: odoo/enterprise#98670
This change prevents the delivery date from being unintentionally reset when confirming certain invoices. It helps keep invoice and delivery information consistent for businesses using anglo-saxon accounting and delivery-based invoicing.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable anglo-saxon accounting; 2. have a product category with automated AVCO; 3. assign category to a deliverable product; 4. set product to invoice on…
Versions
--------
- 17.0+
Steps
-----
1. Enable anglo-saxon accounting;
2. have a product category with automated AVCO;
3. assign category to a deliverable product;
4. set product to invoice on delivery;
5. add product to a sales order;
6. confirm order & delivery;
7. create invoice;
8. change the delivery on the invoice;
7. confirm the invoice.
Issue
-----
The delivery date gets reset.
Cause
-----
Commit 818cf04f05767 added `delivery_date` as a permanently protected field when modifying moves or move lines, protecting the records on `write`. With anglo-saxon accounting however, new move lines are created when confirming an invoice, which in turn recalculate the delivery date, as `_get_protected_vals` isn't used for their move on `create`.
Solution
--------
Add `self.env['account.move'].protecting(_get_protected_vals({}, moves))` when creating new lines for a move, to avoid recomputing fields that should always be protected.
opw-4965036
Forward-Port-Of: odoo/odoo#231186The gradient color picker now displays custom text more clearly in dark mode. This improves readability and makes it easier for users to choose colors while editing website content.
Original PR description
Steps to Reproduce: 1. Go to `Website` and enter edit mode. 2. Drop any `text` snippet. 3. Select the text. 4. Open color picker from the toolbar and switch to `gradient` tab. Issue: The custom text in the gradient tab of the color picker was not clearly visible in dark mode. Reason: The background is already light, and in dark mode the text color was also light. This resulted in insufficient contrast, making the text hard to read. Fix: Set the text color to black when button has no background image. In case of button containing style of background-image, the text color will be same as earlier. | Before | After | |-----------------------------|---------------------------------| | <img width="483" height="274" alt="image" src="https://github.com/user-attachments/assets/911c53f2-bb0e-4d70-9fb2-078ac17388c1" /> | <img width="473" height="326" alt="image" src="https://github.com/user-attachments/assets/c976fb49-6c10-47c0-b559-6a58cfcbcdc2" /> |
This update fixes an error that could stop Romanian e-invoices from being sent when a payment account is linked to a bank. The system now correctly uses the right address field for banks, preventing the process from failing and allowing invoices to be submitted successfully.
Original PR description
Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank. Repro Steps: 1- Create invoice for…
Issue:
When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank.
Repro Steps:
1- Create invoice for romanian localization.
2- Link payment account to invoice.
3- Add bank to payment account.
4- Confirm and send invoice with "Send E-Factura SPV" checked.
Video:
https://drive.google.com/file/d/1rweJgknjbKrpouJRTQ2cluKHsIXNZtSz/view?usp=drive_link
Cause:
The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank.
Fix:
The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly.
Test:
Linked the bank in the test suite. The test fails without this fix, confirming the issue is resolved.
opw-5099816
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents duplicated responses and ensures the payment interface receives the correct data from IoT drivers. It improves reliability when working with both newer and older driver versions, reducing checkout interruptions.
Original PR description
In order to accept values from both an up to date driver, and an old one, we selected either `data` or `data.result` in the callback. First issue here is that the first action was providing `data.result` to the callback, leading to `result` being undefined due to looking at `data.result.result`. Second issue is that we were calling `_keepListening` everytime we received a response from the driver, instead of only on specific cases such as timeout or first message received completely processed.
This change updates an internal website test helper so it works on a copy of the plugin list instead of modifying the original data directly. It helps keep test behavior predictable and reduces the risk of side effects in website-related tests.
Original PR description
The commit 25c602cff4db3f191434ab608ccdc51fa1ac75fb changed the internal of `addPlugin`, but did not follow the good practice of not mutating anything in a getter. In this commit, we instead create a mutated copy. task-5176469
Customers can no longer cancel self-ordering tickets once they have been sent to the kitchen display. This avoids a mismatch where the order looked canceled in the back office but the kitchen was not informed, reducing confusion and operational errors.
Original PR description
Currently, it is possible to cancel orders that have been sent to the kitchen display. However when doing so, the kitchen displayd does not receive any information about the cancellation. Steps to reproduce: ------------------- - Modify restaurant and enable self ordering - Open self an place an order (not paid but sent to kitchen) - Go back to "My orders" and cancel it > Order is cancelled in backend but not in the kitchen display Why the fix: ------------ When an order is sent to the kitchen the only way to cancel it should be by going to the register. Therefore now, if an order is present on the kitchen display we will not show the cancel button. opw-5030223 Enterprise: https://github.com/odoo/enterprise/pull/95770 Forward-Port-Of: odoo/odoo#232989 Forward-Port-Of: odoo/odoo#229039
Fixed an issue in the bank reconciliation screen where model buttons and partner counts could disappear after moving to another page. The widget now refreshes correctly as records change, so users can continue reconciling without missing guidance or counts.
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 Forward-Port-Of: odoo/enterprise#98127
Payslips will now correctly display worked days for employees on fully flexible contracts, even when no working calendar is set. This prevents missing payroll information when work entries come from attendance or planning, so payroll calculations and reviews are more reliable.
Original PR description
**Issue:** Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries **Cause:** `_get_worked_day_lines()` skips…
**Issue:** Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries **Cause:** `_get_worked_day_lines()` skips worked day computation if the contract has no calendar https://github.com/odoo/enterprise/blob/1a10e0444fdb71a072262a1f14f0bfc766d109c6/hr_payroll/models/hr_payslip.py#L665-L674 **Steps to Reproduce:** - Assign an employee a fully flexible contract with attendance as work entry source. - Create work entries based on the attendance records of the employee record - Go to employees > contracts > new Payslip Worked Days section is empty, even though attendance shifts are showing up on top. **Fix:** removing the calendar requirement in the main method and adding a fallback calendar in the called utility method **Note:** same issue happens if work entry source of the contract is Planning opw-4931972 Forward-Port-Of: odoo/enterprise#97384 Forward-Port-Of: odoo/enterprise#93935
Customers can no longer cancel a self-order once it has been sent to the kitchen display. This avoids mismatches between the backend order status and what the kitchen sees, and guides customers to cancel through the register when needed.
Original PR description
Currently, it is possible to cancel orders that have been sent to the kitchen display. However when doing so, the kitchen displayd does not receive any information about the cancellation. Steps to reproduce: ------------------- - Modify restaurant and enable self ordering - Open self an place an order (not paid but sent to kitchen) - Go back to "My orders" and cancel it > Order is cancelled in backend but not in the kitchen display Why the fix: ------------ When an order is sent to the kitchen the only way to cancel it should be by going to the register. Therefore now, if an order is present on the kitchen display we will not show the cancel button. opw-5030223 Community: https://github.com/odoo/odoo/pull/229039 Forward-Port-Of: odoo/enterprise#98035 Forward-Port-Of: odoo/enterprise#95770
Fixed a problem in the rental website that could reject valid end dates when the minimum rental period was set in months. The date calculation now uses the actual calendar month length, so bookings work correctly in shorter months like February.
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#98828 Forward-Port-Of: odoo/enterprise#98168