Daily updates from Odoo
Navigate
Branch
Friday, September 12, 2025
224 changes
20 changes
Enhancements to existing features
Mexican CFDI e-invoices are now generated with totals calculated directly from invoice lines, matching how SAT validates them. This reduces the risk of rejected electronic invoices by automatically handling small differences through discounts or adjustment lines when needed.
Original PR description
Simplify the CFDI generation. Now the totals are always computed from the lines. That way, it's impossible for the SAT to refuse a CFDI since it's built in the way the SAT checks the validity of the file. The difference between the CFDI total and the original documents is put using the discount if available. If not, we add a fake line in the CFDI. task-id: 4926200 Forward-Port-Of: odoo/enterprise#90434
This draft update adjusts how selection menus handle navigation callbacks in the website editing interface. It should make menu-based choices behave more consistently when users move through options, reducing friction in content editing workflows.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Sales orders created from a contact now use that contact’s preferred delivery address, matching the behavior in the Sales app. This prevents orders from being sent to an older or unintended address when customers have multiple delivery locations.
Original PR description
## Versions 17.0+ ## Issue When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery…
## Versions
17.0+
## Issue
When creating a SO from the Contacts app, the first delivery address is used, ignoring the preferred one. In contrast, the Sales app correctly uses the preferred delivery address. This fix ensures consistent behavior across both.
## Steps to reproduce
*Ensure Contacts app is installed*
*Activate "Customer Addresses" in the settings*
- Go to the Contacts app:
- Create a new contact:
- Name: C1;
- Contacts & Addresses:
- Delivery Address (Add 2 new addresses):
- D1;
- D2.
- Click the "Sales" action button:
- Create a new SO for C1 (pre-filled):
- Invoice Address: C1, D2;
- Delivery Address: C1, D2;
- Add any product with:
- Quantity: 1;
- Delivered: 1.
- Create the invoice and confirm it.
- Go back to Contacts and look for C1:
- Click the the "Sales" action button:
- Create a new SO and see the Delivery Address set to "C1, D1".
- Go to Sales app:
- Create a new SO and select C1 as customer;
- Delivery Address retrieves "C1, D2" as it is the preferred address.
## Cause
Each time an invoice is validated, the corresponding address gets a higher score.
This score is then used in the SQL ordering of customers/suppliers:
https://github.com/odoo/odoo/blob/b523f5c6d8e235a6cedb029f701a0ebd89a5f74a/addons/account/models/partner.py#L347-L354
## Fix
Apply context search mode if first call. This mimics the base behavior: https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/odoo/addons/base/views/res_partner_views.xml#L534
opw-4916381
Forward-Port-Of: odoo/odoo#225189This fix prevents a closed websocket connection from being treated as an unexpected internal error during test handling. It restores the intended cleanup behavior, reducing confusing error reports and improving reliability in core infrastructure.
Original PR description
Followup to 16.0-closed-in-stop-xmo: the condition in `stop` is a `hasattr`, so we need to delete `self.ws` not set it to `None`. Setting it to `None` means the condition passes then blows up as soon as we try to use it, which means we "just" converted all the old `WebSocketConnectionClosedException` to an `AttributeError`. https://runbot.odoo.com/odoo/error/231446 Forward-Port-Of: odoo/odoo#226267
Fixes an issue where users returning from an external link in a dashboard were taken back to the first dashboard instead of the one they had selected. This preserves the user’s place and avoids confusion when navigating between dashboards and linked pages.
Original PR description
Steps to reproduce: - go to dashboards - select a dashboard with external links on scorecard charts for instance (do not select the first dashboard) - click on the chart w/ the external link to be redirected - Go back to the previous page through the browser The selected dashboard is now the first dashboard instead of the one you came from. the behaviour was broken since the introduction of the path-based routing in #157867 as we did not specify a path for the dashboard action but still worked because the action params were sent in the context but this was corrected in #216067 task-5067826 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
Fixed an issue in restaurant Point of Sale where combo items could lose their connection to the main combo product after an order was synchronized. This helps staff return to a table and continue editing orders without combo meals appearing as separate regular products.
Original PR description
When one of the combo line is marked as "Dirty", it would be synched but it would remove it's link to the combo parent. Steps to reproduce: ------------------- * Create a combo product * Open a PoS restaurant * Open a table, and add the combo product * Leave the table to synchronize the order with the backend * Go back on the table and select a partner * This will mark the combo line as "dirty" * Leave the table again to synchronize the order with the backend * Go back on the table > Observation: The combo now appears as a normal product, not linked to the combo parent. Why the fix: ------------ When marking a line as "dirty", we now make sure to also mark it's combo parent as "dirty" so that it will be synchronized correctly. And keep the link to the combo parent. opw-4950262 Forward-Port-Of: odoo/odoo#225573 Forward-Port-Of: odoo/odoo#220099
Users can now update approvers on their own approval requests without running into an access error. The change also prevents request owners from adding, editing, or deleting approvers when they should not have that permission, improving consistency and control in the approval process.
Original PR description
Fixed an issue happening when trying to add approvers to one's own request, and remove their ability to delete approvers from the request Task-4897775 Forward-Port-Of: odoo/enterprise#94261 Forward-Port-Of: odoo/enterprise#92309
Due to time constraints the translations were not added in the commit adding the modules (72ac059edfcc35ad44c5faa9daf971123377af24). This commit adds the translations / fills the `.po` files. The translations were created by LMAN based on the 18.0 po files. Veri*Factu task: task-3745982 Forward-Port-Of: odoo/odoo#226298 Forward-Port-Of: odoo/odoo#225173
Original PR description
Due to time constraints the translations were not added in the commit adding the modules (72ac059edfcc35ad44c5faa9daf971123377af24). This commit adds the translations / fills the `.po` files. The translations were created by LMAN based on the 18.0 po files. Veri*Factu task: task-3745982 Forward-Port-Of: odoo/odoo#226298 Forward-Port-Of: odoo/odoo#225173
The cash basis General Ledger now combines duplicate payment-related entries before showing additional results. This prevents errors when users load more lines for accounts with many payments, making financial reporting more reliable.
Original PR description
**Steps to reproduce:**: - Install the module "account_reports_cash_basis" - Create a new account - Create an invoice with a line in the newly created account - Create a number of payments on the…
**Steps to reproduce:**: - Install the module "account_reports_cash_basis" - Create a new account - Create an invoice with a line in the newly created account - Create a number of payments on the invoice - Go to general ledger, and set method to cash basis - Set limit to a value less than the number of payments - Open the account on the general ledger, and click on load more **Issue:** After clicking on 'Load more', we get a traceback due to duplicate lines **Cause:** The same aml can return multiple results when using "account_reports_cash_basis" module. While this has been taken into consideration for each batch of lines loaded into the report (we won't get the same line referenced two times in the same batch, since they are grouped together), if we load a new batch by clicking "Load More", we can potentially get a line that was referenced in the first batch, and we get an error for having two lines in the report referencing the same thing. **Solution:** We add a add a GROUPBY statement in the query of _get_aml_values() This will add up all the cash basis lines in the query itself. opw-4635115 Forward-Port-Of: odoo/enterprise#93904 Forward-Port-Of: odoo/enterprise#86817
This fixes an issue where service lines added after a sales order was confirmed showed a zero cost instead of the product's configured cost. The correction helps keep margins accurate when teams update confirmed sales orders with additional services.
Original PR description
…O confirmation **Problem:** When a service is added on a SO after the confirmation the cost column (purchase_price) is 0 **Steps to reproduce:** - make sure that sale_timesheet_margin is installed - create a service with a positive cost - create a SO for 1 unit of this service - confirm - add a new line on the SO for the same service **Current behavior:** the cost is 0 **Expected behavior:** the cost should be the cost you set on the product form **Cause of the issue:** since this PR https://github.com/odoo/odoo/pull/207228 services that are "ordered_prepaid" on confirmed sale order are filtered out the purchase price computation https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/sale_timesheet_margin/models/sale_order_line.py#L9-L15 opw-5016622 Forward-Port-Of: odoo/odoo#225704 Forward-Port-Of: odoo/odoo#225027
This update adjusts an internal email server test to match a changed error message from a supporting mail library. It helps keep automated quality checks reliable without changing how users work with Odoo.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226489
This update fixes failing automated tests in the online shop area. It helps keep the website sales feature reliable by ensuring test checks run successfully during validation.
Original PR description
runbot-error-227575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payments for Mexican electronic invoices could fail validation when an invoice was issued in a foreign currency and paid in MXN because exchange-rate rounding was handled inconsistently. This fix aligns the calculation with the official rounding rules, helping affected payments validate correctly and reducing manual correction work.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to: - 0.049216958195 for day 1 - 0.053418803419 for day 2 - Create an invoice in USD as follows: - line 1: price_unit 91, quantity 64,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
- 0.049216958195 for day 1
- 0.053418803419 for day 2
- Create an invoice in USD as follows:
- line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI
Issue: Payment validation will fail with error
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862
This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.
opw-4750981
Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768The survey leaderboard now shows score changes in a clearer sequence, so participants can better understand how their points are updated after each question. The leaderboard display was also enlarged to prevent scores from appearing cramped or incorrectly shown.
Original PR description
The way the score bars were animated was a bit confusing. We simplify the animation by: - Showing the score accumulated so far without the question - Animating the score bar towards the accumulated…
The way the score bars were animated was a bit confusing. We simplify the
animation by:
- Showing the score accumulated so far without the question
- Animating the score bar towards the accumulated score with the question
- Animating the numerical score on the left towards the accumulated score with the question while fading the numerical score increment on the bar ("+ x p")
- (reordering participants)
We also fix the size of the leaderboard as it was too small to display the score correctly.
How to reproduce
- Create a scored survey with time reward
- Add a question to get the name and toggle the nickname option
- Add a question with an answer that grants n points
- Start a live session
- After a user has completed the question
- Display the leaderboard
The score animation is confusion as it was going through:
- Showing the score accumulated so far without the question
- Animating towards 0: showing a minimal bar due to the minimum size of the score bar
- Animating towards the score question (on top of the minimal bar)
- And finally adding the score accumulated so far without the question
Task-4893763
Forward-Port-Of: odoo/odoo#224996This fix makes the website editor's background positioning tool align correctly with the selected section across scrolling, mobile preview, browser zoom, and scroll effects. Users can now adjust background images more consistently without missing overlays, blocked scrolling, or misleading loading masks.
Original PR description
__Current behavior before commit:__ The background position overlay action allows the user to move the background image of the editing element. To do that it copies it inside an overlay which is…
__Current behavior before commit:__ The background position overlay action allows the user to move the background image of the editing element. To do that it copies it inside an overlay which is outside the iframe since the [Website refactoring]. This creates multiple challenges because the overlay needs to perfectly align with the editing element behind it which is not a trivial task for several reasons: - The iframe can have different sizes and positions when toggling the mobile preview. - The editing element can be anywhere on the page, and it can move if the user scrolls. - Some scroll effects depend on the dimensions of the viewport which is different in and out of the iframe. Furthermore the `overlay` plugin currently used is designed for contextual menus and pop-ups. It forces the overlay content to always be fully visible in the window and it hides the content if it is bigger. This makes it unsuitable for the purpose of positioning a background image. Here are several bugs that arise from the above: - The overlay doesn't appear if the editing element is taller than the window. - When the overlay is open, it's only possible to scroll while the mouse is hovering the scrollbar. - The overlay image doesn't follow the editing element after scrolling. - The overlay dark mask doesn't cover the whole iframe window. - The loading spinner and its dark overlay is displayed while the background position overlay is on. - If the Scroll Effect is set to "Zoom Out" with maximum intensity, the overlay is not correctly positioned. - If the Scroll Effect is set to "Fixed", the overlay **is** correctly positioned but the background position doesn't align with the one behind it. - In the mobile preview the overlay doesn't cover the iframe. - etc. __Description of the fix:__ Several things are now done differently to fix these issues: - The `overlay` service is used instead of the plugin. This way we have a better control over the positioning of the overlay. - The overlay positioning is more robust to take into account the mobile preview iframe position, the page scrolling and a possible browser zoom. - We stop using an image copy, instead the editing element `background-position` is directly modified making it a perfect wysiwyg. To do this, the overlay dark mask is kept but the portion in front of the editing element is cut-out to highlight it. An invisble dragger element is there to be able to listen to mouse event for the dragging. Also, the content of the section is made invisible so that only the background is shown. [Website refactoring]: https://github.com/odoo/odoo/pull/187419 Related to task-4367641
The Documents app now consistently shows the Activities button in the document chatter, including for files linked to other document-related models such as signing documents. This makes it easier for users to manage follow-ups and tasks from the same place without missing activity options.
Original PR description
Step to Reproduce: - Install `Documents_sign` module - open Documents - click on 'info & tags` button on the top right corner to show chatter - Open 'Odoo CLA.pdf' document Observation: - The Activities button is not shown in Chatter. Issue: - after this https://github.com/odoo/enterprise/commit/a32825ee00f2b330d99113f4d8c1488903fe744e, the activities button shows only for those documents which are related to `documents.documents` model or a document has no model, but it should be shown for all documents https://github.com/odoo/enterprise/blob/23fb26ae0f91a5bdb74d0d4fce48b31fa7abef86/documents/static/src/views/kanban/documents_kanban_renderer.xml#L21-L26 Solution: - Remove condition for Kanban and list view to show `activities` button in Chatter opw-5013427 Forward-Port-Of: odoo/enterprise#94361 Forward-Port-Of: odoo/enterprise#93093
The web test runner now reports critical setup problems during dry runs as real errors. This helps Odoo’s automated checks catch blocking test issues earlier and more clearly, reducing the risk of failed or misleading test runs.
Original PR description
The test runner replaces most occurences of `console.log` with a formatted `console.trace`, as to avoid duplicate runbot error messages in general. The issue is that during the dry run, errors that are caught should be logged on the runbot since these errors are more critical (i.e. duplicate test name, which will prevent the runner to run at all). This commit ensures that errors caught during dry run are logged as actual errors to prevent this issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225688
The web test runner now avoids over-simplifying test URLs when specific tests are excluded. This keeps automated test selections accurate, reducing the risk of running the wrong set of tests during development and validation.
Original PR description
Before this commit, when the test runner simplified the URL (e.g. if the runner is given the ID of every test in a suite, it will remove them and only include the suite ID), it always considered IDs as being "included", and ignored the "-" specifying that some IDs should be "excluded". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225950
This fix makes the online rental checkout test wait until the cart has fully updated after a customer changes the rental duration. It helps prevent false build failures and improves confidence that rental pricing is displayed correctly before checkout checks continue.
Original PR description
steps to reprduce: 1. duplicate multi enterprise 18.0 database 2. run the tour `website_sale_change_rental_duration` in the duplicated database inspired from: https://github.com/odoo/enterprise/commit/c7542e897c537650966497065db9c7d033dcb8ee added a delay to wait when choosing the rental duration, after page is loaded when go to cart , check if the next page is loaded before checking untaxed amount build_error-227718 Forward-Port-Of: odoo/enterprise#93659 Forward-Port-Of: odoo/enterprise#89274
Survey datetime answers now show the same time in list views and detail forms by using the current user's timezone. This prevents confusion when reviewing submitted survey responses across different time zones.
Original PR description
Steps to reproduce ==================== 1. Create survey with some datetime questions. 2. Receive some response on it. 3. Check answer of datetime questions in answer tab. 4. Click on that answer to open form. ->The time shown in answer tab differs from actual value in form. The display_name of survey.user_input.line is computed based on the answers submitted by users. For questions of type datetime, the display_name was generated by converting the datetime value to a string without accounting for the user's timezone, leading to a mismatch between the actual value and the displayed time. After this commit ================== This commit updates the computation of display_name for datetime answers to consider the current user's timezone. Task-4890423 Forward-Port-Of: odoo/odoo#226354 Forward-Port-Of: odoo/odoo#216281
5 changes
Resolved issues and error corrections
This fix prevents point-of-sale payments through Adyen from getting stuck when a cancellation receives no response. It also improves error reporting when the Adyen payment service is unavailable, helping staff recover faster at checkout.
Original PR description
When we try to cancel a processing payment, we can get stuck with a in the state waiting card, if there is no anwser from adyen. Also when we call Adyen to process payment, the value returned by data.silentCall is false, so we don't get error when the service is not available --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a rounding mismatch that could cause Mexican electronic payment documents for foreign-currency invoices to be rejected. Payments made in MXN against USD invoices now calculate values consistently with the required reported precision, reducing failed validations.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to: - 0.049216958195 for day 1 - 0.053418803419 for day 2 - Create an invoice in USD as follows: - line 1: price_unit 91, quantity 64,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
- 0.049216958195 for day 1
- 0.053418803419 for day 2
- Create an invoice in USD as follows:
- line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI
Issue: Payment validation will fail with error
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862
This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.
opw-4750981
Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768This fixes an issue where adding a prepaid service line to an already confirmed sales order showed a zero cost instead of the product’s configured cost. The correction helps keep margin reporting accurate when sales orders are updated after confirmation.
Original PR description
…O confirmation **Problem:** When a service is added on a SO after the confirmation the cost column (purchase_price) is 0 **Steps to reproduce:** - make sure that sale_timesheet_margin is installed - create a service with a positive cost - create a SO for 1 unit of this service - confirm - add a new line on the SO for the same service **Current behavior:** the cost is 0 **Expected behavior:** the cost should be the cost you set on the product form **Cause of the issue:** since this PR https://github.com/odoo/odoo/pull/207228 services that are "ordered_prepaid" on confirmed sale order are filtered out the purchase price computation https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/sale_timesheet_margin/models/sale_order_line.py#L9-L15 opw-5016622 Forward-Port-Of: odoo/odoo#225704 Forward-Port-Of: odoo/odoo#225027
This fix stops Odoo from adding a log note when a Saudi e-invoicing error happens before any request is sent to ZATCA. It keeps invoice communication history cleaner by only logging actual ZATCA responses.
Original PR description
In a previous commit e90c35cde2a1f5de5d7bc4db7a525638ca3fab6e, we modified the logic of posting a log note when receiving a response from ZATCA to always log a note of the response. An issue occured because sometimes, Odoo raises user errors before sending a request to ZATCA, In which case, we do not need to log a note. Task-id: 5056724 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#226174 Forward-Port-Of: odoo/odoo#226036
This update prevents errors when users choose a measure while configuring a cohort view in Studio. It limits the measure choices to compatible fields and removes an unnecessary request parameter that was causing system warnings.
Original PR description
Currently, an error occurs when user tries to select any measure in cohort view. Steps to replicate: - Install `sale_management` and `web_studio`. - Open the Sales app and turn on studio mode. -…
Currently, an error occurs when user tries to select any measure in cohort view. Steps to replicate: - Install `sale_management` and `web_studio`. - Open the Sales app and turn on studio mode. - Under the Views tab, turn on cohort view. - Under the Measures field, select any value and observe the error appearing in the terminal. Error: `ValueError: Invalid aggregate method 'None' for 'create_date:None'` Cause: - The Measure field dropdown in the Cohort Editor was mistakenly assigned the choices of `dateFields` [1] instead of `measureFields`. - This allowed users to select incompatible field types (e.g., date/datetime), which lead to error in aggregation behavior in the cohort view. Solution: - Corrected the choices of Measure field to `measureFields`. - Also added a condition to allow only those fields that have an aggregator (for some fields like `sequence` that dont have an aggregator). - Also removed context field from arguments [2] in the rpc call as function doesnt need it [3] (This shows warning on runbot as well). [1]: https://github.com/odoo/enterprise/blob/d8539dff5f3dcecfeb99fd7fc22a6915aaa02c4b/web_studio/static/src/client_action/view_editor/editors/cohort/cohort_editor_sidebar.xml#L30 [2]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/static/src/client_action/editor/new_view_dialogs/new_view_dialog.js#L87 [3]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/controllers/main.py#L805 sentry-6781792463 Forward-Port-Of: odoo/enterprise#94354 Forward-Port-Of: odoo/enterprise#91599
3 changes
Resolved issues and error corrections
Swiss ISO 20022 payment files now place bank clearing numbers in the correct XML structure. This helps prevent payment file validation issues when companies generate batch payments for Swiss vendors.
Original PR description
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner - Pay with "Swiss ISO20022" - Create a batch payment with that payment and validate - In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId)) ### Cause: The code directly inputs the value of `clearing_number` in `ClrSysMmbId`. ### Solution: Add `MmbId` to contain the clearing number. ### Note: The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`. This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations. opw-4872507
Payments for Mexican electronic invoices could fail validation when invoices were issued in USD and paid in MXN because exchange-rate rounding was handled inconsistently. This fix aligns the payment calculation with the official rounded value, helping businesses successfully issue payment CFDIs and avoid tax document rejection.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to: - 0.049216958195 for day 1 - 0.053418803419 for day 2 - Create an invoice in USD as follows: - line 1: price_unit 91, quantity 64,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
- 0.049216958195 for day 1
- 0.053418803419 for day 2
- Create an invoice in USD as follows:
- line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI
Issue: Payment validation will fail with error
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862
This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.
opw-4750981
Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768This fixes an access issue in the Approvals app that could prevent selected approvers from approving requests when they did not have the general Approvals user role. It ensures approval workflows continue smoothly for the people specifically asked to approve, reducing process delays.
Original PR description
Follow up on the previous PR odoo/enterprise#92309 , fixing access rights preventing approvers from approving in requests they are requested to approve in case they don't have the group approvals user. Task-4897775 Forward-Port-Of: odoo/enterprise#94316
1 change
Resolved issues and error corrections
This draft reverses a previous change affecting how rental products behave in the online shop. It likely restores earlier behavior for website rentals while the reverted change is reviewed or corrected.
Original PR description
revert of 655e0875b192575dd699cf36676c02f1c241daa2
46 changes
Enhancements to existing features
Adds a warning when an uploaded or scanned vendor bill appears to use a GSTIN that does not match the selected company, helping users catch company selection mistakes before proceeding. It also improves GSTR-2B matching so duplicate invoice references in draft purchase documents no longer block automated processing.
Original PR description
Use Case 1 – Bill Upload/Scan - Issue: When scanning or uploading vendor bills, system allows upload even if the bill’s GSTIN does not match the company GSTIN. This can happen when multiple companies share the same name but have different GSTINs under the same PAN. - Solution: Add a warning if the bill’s GSTIN doesn’t match the company GSTIN: *"It seems Bill’s GSTIN doesn’t match this company. Please verify before proceeding.”* Use Case 2 – Duplicate IRN in GSTR-2B Matching - Issue: Cron job gets stuck when duplicate IRN exists in both draft purchase documents and fetched GSTR-2B data. - Solution: Include draft purchase documents having IRN in the matching process for the current period, so duplicate warnings are skipped and processing continues smoothly. Task ID: 4862214 Forward-Port-Of: odoo/enterprise#92948
The Accounting Reports area now again offers access to financial budget records, but only when debug mode is enabled. This helps administrators and support teams inspect or import budget data without adding clutter for everyday users.
Original PR description
This menuitem was removed with the idea to clean the view, but we now have second thoughts. Having a means to access a tree view of those objects is interesting for debugging purposes and in order to import them. We now put in debug mode only, though. Forward-Port-Of: odoo/enterprise#94155
This update refreshes Belgian payroll demo data and related setup so it better supports the “Running your payroll yourself” Odoo Experience presentation. It helps presenters show a more realistic payroll flow, including employee salary data, payslip inputs, work entries, and accounting demo information.
Original PR description
prepare some demo data for the oxp talk "Running your payroll yourself"
The rental date picker on product pages has been redesigned and moved into the product header. This keeps date selection visible and accessible while customers review rental products, improving the shopping experience.
Original PR description
This commit revises the UI of the date picker and moves it from the side bar to the `product_header` to always be available. task-4903754 Part of task-4252024 Requires: - https://github.com/odoo/odoo/pull/217272 - https://github.com/odoo/upgrade/pull/8028 
The VoIP softphone now shows a clear visual indicator when it is running in demo mode. This helps users understand why calling behavior may be limited or simulated, reducing confusion during trials, demos, or testing.
Original PR description
[Task-5055883](https://www.odoo.com/odoo/project/5778/tasks/5055883) Forward-Port-Of: odoo/enterprise#93610
Payroll contract templates now better preserve country-specific information when creating new employee contracts. This helps HR teams avoid missing localization details and adds checks to ensure templates work consistently across supported payroll localizations.
Original PR description
This commit implements _get_whitelist_fields_from_template() method across all HR payroll localizations to ensure that localization-specific fields are properly copied when creating contracts from templates. Additionally, tests has been added for all localizations to validate the whitelist functionality and ensure proper template loading behavior. task-4954283 Forward-Port-Of: odoo/enterprise#92093
The home menu has been refreshed with new light and dark backgrounds and updated visual styling. This improves the first-screen experience for users and keeps the Enterprise interface aligned with the upcoming v19 design direction.
This update refines how spreadsheet borders are handled when working with list and pivot spreadsheet features. It should make spreadsheet behavior more consistent and easier to maintain, with minimal direct impact on day-to-day users.
Audit report PDFs now avoid adding page titles for template sections that do not contain meaningful printable content. This reduces unnecessary blank or cluttered pages and makes exported audit reports easier to read.
Original PR description
Previously, the algorithm that generated the audit report PDF would create a page title for empty articles using the article name. This often resulted in unnecessary pages, since many template articles are considered empty (because they contain elements that should not be printed). To reduce page clutter, we are revising the algorithm and introducing a new heuristic: a page title will be generated only if the article contains a single heading (h1, h2, or h3) and no other text elements. In such cases, the heading itself will be used as the page title. Task-5079472 Forward-Port-Of: odoo/enterprise#94327
Knowledge articles linked to audit reports now keep the standard Download PDF option visible. The separate audit report export action is renamed to Download Annual Report, making it clearer which document users are downloading.
Original PR description
Previously, when an article was linked to an audit report, the "Download PDF" button was hidden and replaced with a button to generate the audit report PDF. This commit restores the default "Download PDF" button and renames the button for generating the audit report PDF to "Download Annual Report", improving the clarity of the interface. Task-5079472 Forward-Port-Of: odoo/enterprise#94328
The barcode app's demo sheet now includes the new "OBTWREV" barcode command. This helps users and testers access the latest barcode action from the standard reference sheet, making demonstrations and training more complete.
Original PR description
This commit adds the newly created barcode command "OBTWREV" introduced in #88614 to the barcode demo sheet. Forward-Port-Of: odoo/enterprise#94324
The pull request adjusts internal performance test expectations for the Knowledge app after a change in how HTML content is cached when records are created. This helps keep automated performance checks accurate without changing day-to-day user workflows.
Original PR description
Adapting query count, due to not putting html fields in cache upon creation. task-4962646 Forward-Port-Of: odoo/enterprise#93741 Forward-Port-Of: odoo/enterprise#93171
Users now manage their light, dark, or system-based color scheme from their personal preferences instead of the main user menu. This keeps the menu simpler while preserving theme choice, and reduces first-load flicker when the system preference is dark.
Original PR description
As the backend now supports the browser/system/device color scheme, having a directly accessible switch in the UserMenu is not as necessary as before. This commit moves it to the user's preferences instead. task-5074720 Forward-Port-Of: odoo/enterprise#94223
Studio no longer includes the outdated date delay setting when configuring calendar views. This reduces confusion and helps keep calendar setup aligned with the current behavior of Odoo views.
Original PR description
This commit removes the attribute "date_delay" from calendar view arch. task-4609678
Gantt views now keep the cursor consistent while users drag, drop, or create multiple items. This makes scheduling interactions feel clearer and less distracting because the cursor no longer changes unexpectedly when hovering over different elements.
Original PR description
In multi create mode, the cursor on a cell will now be cell. We also make the cursor be more consistent. Before this commit, start an interaction (i.e. a drag & drop) and hover various elements during that interaction would change the cursor according to the type of hovered elements. Now the cursor is constant through the duration of the interaction and related to the type of interaction. Task ID: 5076037
Spreadsheet border handling was reworked to make list and pivot spreadsheet behavior more consistent and easier to maintain. This should support a more reliable editing experience without introducing major user-facing changes.
Resolved issues and error corrections
This fix prevents the Chilean electronic invoicing factoring flow from crashing when the tax authority returns invalid or unexpected responses. It also resets problematic tokens and adds tests, improving reliability during intermittent external service issues.
Original PR description
There were some typos in this method. We add test coverage and we reset the token in situations where we receive invalid responses. It's apparently common for the SII to have some random errors that could result in invalid tokens being generated. Based on the work in https://github.com/odoo/enterprise/pull/92035. Forward-Port-Of: odoo/enterprise#94342 Forward-Port-Of: odoo/enterprise#94134
The bank reconciliation screen’s statement button was broken after a recent bank statement view change. This fix restores the previous statement view for that button so users can open statements correctly again during reconciliation.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/935b25fdb9238e9d249e913922804d5b673a09a9 change the view of the bank statement but by doing so they broke the use of the statement button on the bank rec widget. This commit will add the old view back and change the view used in the action of the statement button. no task id
This fix stops improvement suggestions on extra manufacturing work orders from creating quality checks that the system cannot handle. It prevents an error when manufacturing orders are duplicated and keeps PLM/quality workflows limited to existing bill-of-material operations as intended.
Original PR description
## Issue: Creating multiple suggestions sequences for differents Workorder in Manufacturing Orders that are added aside BoM defined WorkOrder cause an issue with a Traceback error ## Cause: In the…
## Issue: Creating multiple suggestions sequences for differents Workorder in Manufacturing Orders that are added aside BoM defined WorkOrder cause an issue with a Traceback error ## Cause: In the method `add_check_in_chain()`, the `point.sequence` cause issue because the check can have multiple points https://github.com/odoo/enterprise/blob/e85d11f9b3bf07a55e5365adac7370955a149566/mrp_workorder_plm/models/mrp_workorder.py#L58-L66 That the case because multiple quality checks sequences are created when the operation_id is False That's unexpected because PLM isn't made to suggest WorkOrder additions and Suggestions to New WO, but only Suggestions to existing operations So we avoid to create `quality.point` when there is no operation_id ## Information: To get the Traceback, you need to install Quality_control because this module will copy the QC to the MO including the one with operation_id set to False ## Steps to reproduce: Quality_control and plm need to be installed - Enable Work Orders in Settings - Create a Product with a BoM - Create a MO for the Product - Add an extra WO - In the Shop Floor, Mark as Done the BoM's WO - On the Extra WO, click Gear Icon > Update Instructions > Improvement Suggestion > Add a Step - Insert a Title and Propose Change - Duplicate the MO and redo the Shop Floor steps to get the Traceback opw-4874108 Forward-Port-Of: odoo/enterprise#92384
Archived quality points are now excluded from the product Quality Points smart button. This keeps the displayed count and list accurate, reducing confusion for users reviewing quality controls.
Original PR description
**Steps to reproduce:** 1. Install the module `quality_control`. 2. Go to **Products → select any product → Quality Points (smart button)**. * Create a new Quality Point that applies to *all…
**Steps to reproduce:** 1. Install the module `quality_control`. 2. Go to **Products → select any product → Quality Points (smart button)**. * Create a new Quality Point that applies to *all products*. 3. Open any product form. * Verify that the *Quality Points* smart button shows the created point and the correct count. 4. Archive the Quality Point. 5. Reopen the same product form and check the *Quality Points* smart button again. **Observed behavior:** - The archived Quality Point is still counted and shown in the smart button. **Root cause:** - During the refactor from raw SQL (`get_sql` + `cr.execute`) to the ORM query builder (`query.add_where(SQL(...))`), one outer bracket was dropped. [ref](https://github.com/odoo/enterprise/pull/66290/commits/a6362bc07eac7640f68d145a0f6a14a81f499913#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L542-R561) - This changed the operator precedence, causing the `active = true` condition to no longer properly apply when combined with the OR block. - As a result, archived Quality Points bypass the filter and are still counted. **Solution:** - Fix the missing bracket in the `query.add_where` SQL expression so that the `active` condition is always enforced before evaluating the OR block. opw-5046289 Forward-Port-Of: odoo/enterprise#94173
This fixes an issue in the Belgian CodaBox integration where processing multiple companies could trigger an error. The correction helps ensure company-specific CodaBox actions run reliably without disrupting users.
Original PR description
We incorrectly used the recordset `self` instead of the record `company` This commit fixes this opw-5036698 Forward-Port-Of: odoo/enterprise#94289
Batch payments for bills with multiple installments now ignore payment term lines that have already been reconciled. This prevents users from seeing an incorrect reconciliation error when processing later installments, allowing vendor payments to be matched smoothly.
Original PR description
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: *…
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: * Vendor: [any] * Payment terms: [the created payment term] * Amount: 1000 - Confirm the bill - Pay the first installment from the bill (i.e. 200) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -200 - Reconcile the statement with the batch payment - From the bill, pay the second installment (i.e. 800) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -800 - Reconcile the statement with the batch payment **Issue:** The following UserError is raised: "You are trying to reconcile some entries that are already reconciled." **Cause:** When reconciling a batch payment, all the payment term lines from the invoices/bills linked to the payment are used. However, in this case, when the first batch payment has been reconciled, the first payment term line of the bill (linked to the first installment) has been reconciled. It should not be reused when reconciling the second batch payment. **Solution:** Exclude reconciled payment term lines when reconciling a batch payment. opw-4830185 Forward-Port-Of: odoo/enterprise#92524 Forward-Port-Of: odoo/enterprise#91367
The Swiss financial reports now show previous-year unallocated earnings using the correct period. The balance sheet also separates current-year earnings into retained and allocated lines, helping businesses review profit allocation more accurately.
Original PR description
Before this commit, `Previous Year unallocated profit and loss` was showing wrong amount. With this commit, we adapt this line (change period of one of its expression) and we add two new lines to reflect the actual year earnings, retained and allocated. Steps, with fresh db: - 1 invoice confirmed in the past year for 1000 - Create the carryforward move (1000 debit for 999 account, and 1000 credit for 2979 account) - Go to balance sheet, set date as 'End of last fiscal year' -> See 'Previous Years Unallocated Earnings` showing -1000 opw-4054341 Forward-Port-Of: odoo/enterprise#94243 Forward-Port-Of: odoo/enterprise#91281
Downloading documents from the Send & Print wizard no longer fails when a Uruguayan electronic invoice file is present. The system now skips that specific electronic tax document in the wizard download, while users can still access it from the CFE document screen.
Original PR description
When downloading attachment via the send & print wizard, we get an error from the server. This is because we raise an assertion error if any attachment is not from 'account.move' model. But the CFE file is from 'l10n_uy_edi.document' model. With this commit, we extend the `_action_download` method to filter the CFE file from the attachments. It is not blocking for client as he can still download it from the form view of the CFE document. Steps: - Create an invoice - Set a 0% tax on the invoice line - In 'Other infos' tab, fill the 'Incoterm', 'Sales Modality' and 'Transportation Rules' fields - Confirm - Open S&P wizard, select 'Create CFE' and confirm - Reopen S&P wizard, select 'Download' and confirm (can be done along the previous step too) -> Error opw-5043902 Forward-Port-Of: odoo/enterprise#93830
Scanning package type barcodes with GS1 barcode settings now works without triggering server errors. This prevents interruptions in warehouse barcode workflows and keeps package handling smoother for users.
Original PR description
Steps to Reproduce: - Set the barcode nomenclature to GS1 - Scan a package type barcode - Server logs an AttributeError(in Odoo 18) or KeyError(in Odoo 16 and 17) Issue: - The model class "stock.package.type" is missing an attribute "_barcode_field" Solution: - Add the attribute "_barcode_field" to the model class "stock.package.type" Task: [4888064](https://www.odoo.com/odoo/49/tasks/4888064) Forward-Port-Of: odoo/enterprise#94347 Forward-Port-Of: odoo/enterprise#93116
Aged Receivable and Aged Payable reports now correctly expand all lines when users apply custom grouping. This prevents report navigation from breaking and helps finance teams review outstanding receivables and payables more reliably.
Original PR description
We previously checked if the groupby is not changed to use the _common_custom_unfold_all_batch_data_generator. However, the user cannot change this field and is instead editing the user_groupby, so _common_custom_unfold_all_batch_data_generator was always used. Forward-Port-Of: odoo/enterprise#93594
The Count Entire Locations button now appears correctly during normal stock operations such as deliveries and receipts. It remains restricted only on the physical inventory page, helping warehouse users access the right action in the right workflow.
Original PR description
This commit fixes showing "Count Entire Locations" button in normal operations (delivery, receipt, etc.) and only restricts it in physical inventory page. Forward-Port-Of: odoo/enterprise#94194
This update fixes access errors that blocked non-administrator users from opening certain appraisal, planning, and manufacturing shop floor screens. Employees can now use the affected workflows without needing administrator permissions, reducing interruptions in daily operations.
Voice recording now shows a clearer notification when it cannot start because of a backend setup issue, such as a missing API key. This helps users understand what went wrong and reduces confusion when transcription is unavailable.
Original PR description
This PR adds a more explicit toast message for the recording when an error occurs on the backend (i.e. UserError). This applies to cases such as not having the API key set and trying to start the recording
Several spreadsheet dashboards have been corrected so charts line up properly and are easier to read. The Helpdesk and Operation Analysis dashboards also receive visual improvements, helping teams interpret key metrics with less confusion.
Original PR description
Forward-Port-Of: odoo/enterprise#94387
The Belgian salary configurator now prevents employees from combining a reimbursed private bike option with fuel card benefits. When private bike reimbursement is active, fuel card values are cleared and the related fields are disabled to keep salary choices consistent with policy.
Original PR description
The Belgian salary configurator allows employees to declare a private bike cost. When the "Private Bike" option is checked and its reimbursement value is greater than zero, the fuel card inputs must be reset to 0 and disabled. task-5062963 Forward-Port-Of: odoo/enterprise#94063 Forward-Port-Of: odoo/enterprise#93884
This fix prevents products using nightly rental pricing from being combined with other rental period types. It helps avoid incorrect rental configurations and pricing issues after recent changes.
Original PR description
with other rental periods. Fixes from regression testing post merge. Forward-Port-Of: odoo/enterprise#93715
This update corrects an issue in the SEPA Direct Debit payment form behavior. It helps ensure the payment flow works as intended for customers using SEPA direct debit, reducing the risk of failed or confusing checkout experiences.
Original PR description
Forward-Port-Of: odoo/enterprise#94462
This update corrects the product name from “Urban Piper” to “UrbanPiper” across point-of-sale restaurant-related screens, settings, translations, and tests. It helps keep branding consistent and avoids confusion for users configuring or using the integration.
Original PR description
Description of the issue/feature this PR addresses: Correct the spelling Current behavior before PR: Urban Piper was in 2 words. No space needed Desired behavior after PR is merged: UrbanPiper in one word
The accounting import screen now correctly passes the intended target to each import button. This prevents confusion or failed imports when the same page offers multiple import options.
Original PR description
Since [1], the import action will infer the model from the current action. In this case, the action is a client action with multiple import buttons. This commit, adapts the extends of the import action to accept the model as as a parameter. Forward-Port-Of: odoo/enterprise#94388
This fixes an error in the Salary Calculator that occurred when removing an employee's working schedule. Payroll users can now adjust salary simulation details without being interrupted by a system crash.
Original PR description
#### Steps to Reproduce In Payroll → Employees → Salary Calculator: 1. Select an employee with a working schedule. 2. The working schedule is auto-filled in the modal. 3. Remove the working schedule. #### Issue A traceback occurs (`Expected singleton: resource.calendar()`) because `salary_simulation` was not correctly set in the context, causing the flow to recompute work entries with an empty calendar. #### Fix In order to avoid work entry recomputations during simulation, always attach `salary_simulation=True` in the base `_get_version()` and propagate the context when creating a new version for the simulation employee. task-5063150
Mexican electronic payment documents now use consistent rounding when converting foreign-currency invoice values to MXN. This prevents valid payments from being rejected by tax authority validation due to tiny rounding differences.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to: - 0.049216958195 for day 1 - 0.053418803419 for day 2 - Create an invoice in USD as follows: - line 1: price_unit 91, quantity 64,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
- 0.049216958195 for day 1
- 0.053418803419 for day 2
- Create an invoice in USD as follows:
- line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI
Issue: Payment validation will fail with error
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862
This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.
opw-4750981
Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768This fix ensures temporary concurrency conflicts during website generation are handled in a way that allows the process to retry instead of failing prematurely. It improves reliability when multiple operations happen at the same time.
Original PR description
When a concurrency error occurs, we need to let it retry. To do this, we must catch the Serialization Failure and raise it. Forward-Port-Of: odoo/enterprise#93851
The wording in the bank synchronization duplicate finder was corrected to remove an instruction users could not actually follow. This avoids confusion by no longer suggesting that customers select a journal when that option is unavailable.
Original PR description
The aim of this commit is removing a small part of sentence in the find duplicate tool in bank synchronization. Indeed, this sentence is proposing the customer to select the journal where it's not possible to do it. no task id Forward-Port-Of: odoo/enterprise#94386
The Ask AI button now reliably opens the AI chat window even when the original button disappears during loading. This prevents users from clicking the button and seeing nothing happen, making the AI drafting experience smoother and more dependable.
Original PR description
The issue is caused by the use of orm service wrapped in "useService". When the button is clicked, it will be unmounted but an orm query is still pending. The pending query is blocked by the useService because the component is already unmounted. The remedy is to use the raw orm service. Forward-Port-Of: odoo/enterprise#94417
Fixes an issue where manufacturing shop floor quality checks could crash or stay in the wrong status after users reverted and repeated a pass/fail or measurement step. This helps operators continue production workflows without being blocked and keeps quality check results accurately highlighted.
Original PR description
To reproduce: - Create a BoM for a product with an operation and a quality point for this operation - Create and confirm a MO for this BoM - Process it in Shop Floor, pass or fail the QC, revert it then pass/fail it again Current behaviour: traceback Expected behaviour: mark the quality check with primary highlight Introduced in: https://github.com/odoo/enterprise/pull/91986 Forward-Port-Of: odoo/enterprise#92604
Resource-based appointment bookings no longer incorrectly reduce availability for a responsible staff member. This prevents customers from being blocked when booking user-based appointments in the same time slot after a resource appointment was already scheduled.
Original PR description
In [1], we introduced capacity for users. Therefore, capacity is handled by using booking lines, with capacity reserved / used set on them. However, unlike the resources, the user is not stored and…
In [1], we introduced capacity for users. Therefore, capacity is handled by using booking lines, with capacity reserved / used set on them. However, unlike the resources, the user is not stored and is related as the responsible (user_id) of the meeting instead. This has a side effect: if there are resource booking lines on a meeting, and a responsible is set (manually or the appointment type creator as a default responsible, as done in appointment module), then those booking lines may end up counting as booked capacity for the responsible as well! Therefore, we now make sure that the appointment type linked to the meeting is scheduled based on users when searching for booking lines in the remaining capacity computation. STEPS TO REPRODUCE ================== 0. Create a new db and install website_appointment 1. Log in as mitchell Admin 2. Create an appointment_type R based on resources, with a resource R1 and an appointment_type U based on users, with only Mitchell Admin set as staff user 3. Log out and book R on a given slot S 4. Once done, go to appointment U and try to book the same slot S 5. Once you submit the form, you are brought back to the calendar selection screen with an error message (code 'failed-staff-user') TEST ==== A test is added covering most cases, both when getting slots and when directly measuring the user's remaining capacity. 1: https://github.com/odoo/enterprise/commit/bce7e94650c337a9046958a7689c81db5b2a4c73 Task-5080374 Forward-Port-Of: odoo/enterprise#94339
Code cleanup and technical improvements
This update cleans up internal tests for subscription optional products to make them easier to maintain. It does not change customer-facing subscription features, but helps keep future updates more reliable.
Original PR description
See Also: - https://github.com/odoo/odoo/pull/226052 Forward-Port-Of: odoo/enterprise#94276
The AI transcription connection has been updated to use OpenAI's stable realtime transcription API. This should improve long-term reliability and maintainability of voice transcription features, while adding clearer handling when unsupported AI providers are used.
Original PR description
This PR refactors the transcription connection to use the now stable version of the OpenAI realtime API for transcription. This also introduce typing for the realtime in the backend and errors when trying to use the LLMApiService with unsupported provider.
This update renames an internal editor asset bundle so it better fits its use beyond website editing, including email composition. The change improves consistency with the shared HTML builder and should not alter day-to-day user workflows.
Original PR description
The new html_builder is used by both website and mass_mailing. While the old name `[html_builder|website].assets_edit_frontend` makes sense in the context of the website builder, where the iframe is indeed used to "edit the frontend", it is not the case in mass_mailing, where the email being composed is not a "frontend". A more generic name is more appropriate. This commit is linked to the community PR that updates the bundle name everywhere. Forward-Port-Of: odoo/enterprise#94435
Several search screens were simplified by removing redundant grouping settings and separators that behaved the same way. This keeps the interface configuration cleaner without changing expected business workflows.
Original PR description
- Remove all attributes from group element in search view. - Remove the tags separator before a group tag (separator and group do the same thing) Community PR : https://github.com/odoo/odoo/pull/226862 task-5005075
10 changes
Enhancements to existing features
The German tax report has been restructured to work without the previous balance column. This keeps the report aligned with the updated layout and helps ensure tax reporting remains accurate for German localization users.
Original PR description
After removing the `balance` column, we need to refactor the code that depends on it task-5046641
The German tax report has been reorganized to better match the official VAT advance return structure used in ELSTER guidance. This makes the report easier for German businesses to follow and helps align Odoo's tax reporting layout with local filing expectations.
Original PR description
Rework the structure of the German Tax Report according to the very well detailed structure https://sevdesk.de/ratgeber/buchhaltung-finanzen/ustva/formular-elster/ task-5046641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Auditors can now get Audit Working Files in PDF format when reviewing completed internal audits. This makes audit verification easier by providing the required working-file documentation beyond the existing Trial Balance export details.
Original PR description
When verifying internal audits that have been done, auditors may request reports of Audit Working files. The working file must be available in PDF. The export currently only contains the Trial Balance with the audit state and last comments (more recent annotation) during the audit. task-id: 4993075
Resolved issues and error corrections
Deleting all items from a grouped list no longer causes an error screen. This keeps list views stable when users remove the last records in a group.
Original PR description
After this commit [1], deleting all entries of a grouped list may trigger the following traceback: ``` TypeError: value[currencyField].forEach is not a function ``` This happens because the `currency_id` of an empty group becomes `0`, so `forEach` is called on a non-iterable value. This fix ensures that `currency_id` is correctly handled to prevent such error. [1] odoo@98f7462
Fixed an issue where downloading files from the Send & Print wizard could fail for Uruguayan electronic invoices. The wizard now skips the CFE attachment that belongs to the e-invoicing document, while users can still access that file from the CFE document itself.
Original PR description
When downloading attachment via the send & print wizard, we get an error from the server. This is because we raise an assertion error if any attachment is not from 'account.move' model. But the CFE file is from 'l10n_uy_edi.document' model. With this commit, we extend the `_action_download` method to filter the CFE file from the attachments. It is not blocking for client as he can still download it from the form view of the CFE document. Steps: - Create an invoice - Set a 0% tax on the invoice line - In 'Other infos' tab, fill the 'Incoterm', 'Sales Modality' and 'Transportation Rules' fields - Confirm - Open S&P wizard, select 'Create CFE' and confirm - Reopen S&P wizard, select 'Download' and confirm (can be done along the previous step too) -> Error opw-5043902 Forward-Port-Of: odoo/enterprise#93830
This change fixes an issue in the SEPA Direct Debit payment form customization. It helps ensure the payment form behaves as expected when customers use SEPA Direct Debit, reducing the risk of checkout or payment setup problems.
The PAN entity list in the Indian localization no longer shows the same Type column twice. This removes visual clutter and makes the list easier for users to read without changing any underlying data or workflow.
Original PR description
Before: - The list view in `l10n_in_pan_entity_view_tree` included `type` field twice, causing redundancy. After: - The duplicate field has been removed
The Website Builder mobile preview button now uses green to better match the product's visual theme. This is a small visual consistency fix with low business impact.
Original PR description
- The mobile preview button color is changed to green to align with the overall theme. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where image descriptions could be accidentally erased after reopening and saving the website SEO dialog without making changes. It helps preserve accessibility and SEO metadata reliably for website content.
Original PR description
Steps to reproduce: 1. Open Optimize SEO. 2. Mark an image as decorative. 3. Give a description(ALT) to that image from editor. 4. Open Optimize SEO again and save without doing anything. Issue: The description(ALT) on the image being set is lost. Cause: When reopening the `Optimize SEO` dialog, `seoContext.updatedAlts` still contained entries from previous edits. As a result, saving without making any further change triggered an call to `/website/update_alt_images` which reset the `alt` attribute to empty, effectively discarding the description. This PR ensures `seoContext.updatedAlts` is reset when opening the dialog.
Features or functions removed from Odoo
This update removes an internal function that was recently added but never used. It keeps the web and website-building code cleaner without changing what users see or how they work.
Original PR description
A function has been recently added to the action service API, but it turns out that it wasn't useful (no even used by the PR adding it). This commit removes it. 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
13 changes
Resolved issues and error corrections
This fix prevents a closed connection from being misread as a different internal error during test and core connection handling. It helps keep error reporting accurate, making issues easier to diagnose and reducing misleading failures.
Original PR description
Followup to 16.0-closed-in-stop-xmo: the condition in `stop` is a `hasattr`, so we need to delete `self.ws` not set it to `None`. Setting it to `None` means the condition passes then blows up as soon as we try to use it, which means we "just" converted all the old `WebSocketConnectionClosedException` to an `AttributeError`. https://runbot.odoo.com/odoo/error/231446 Forward-Port-Of: odoo/odoo#226267
This fixes an issue where tapping Send in Odoo’s iOS web app could sometimes fail while writing messages in Discuss or chatter. The message composer no longer shifts at the moment of tapping, making message sending more dependable for mobile users.
Original PR description
Before this commit, when using IOS PWA, pressing 'Send' button of in composer in discuss or chatter would sometimes not register the send. This happens because in IOS PWA, the composer has a bottom margin as this is close to iOS persistent swipe bar. However, the margin should not be present when there's the soft-keyboard. Because of this dynamic margin based on input focus, when composing textual message and pressing "Send" button, the textarea looses focus and a fraction of second the margin-bottom is increased and moves the "Send" button. This leads to mis-clicking the "Send" button. This commit removes the margin-bottom rule on non-focusin of textarea with iOS PWA. The composer is close to swipe bar so that's not as elegant as before, but at least this doesn't add the problem of non- working "Send" button. opw-5028809
This fixes an error that could block Indian e-Way Bill generation through IRN. Users should now receive the expected response instead of a crash when generating an e-Way Bill.
Original PR description
backport of https://github.com/odoo/odoo/commit/b7b987c4077c064fdfdb6b956379455cbdd93de3 on generating ewaybill through irn following traceback is produced ```py File…
backport of https://github.com/odoo/odoo/commit/b7b987c4077c064fdfdb6b956379455cbdd93de3 on generating ewaybill through irn following traceback is produced
```py
File "/home/odoo/src/odoo/addons/l10n_in_ewaybill_stock/tools/ewaybill_api.py", line 165, in _ewaybill_generate
return self._ewaybill_make_transaction("generate", json_payload)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/l10n_in_ewaybill_stock/tools/ewaybill_api.py", line 157, in _ewaybill_make_transaction
response = self._ewaybill_get_by_consigner(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/addons/l10n_in_ewaybill_stock/tools/ewaybill_api.py", line 181, in _ewaybill_get_by_consigner
'message': self.DEFAULT_HELP_MESSAGE % 'generated',
~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
TypeError: unsupported operand type(s) for %: 'LazyGettext' and 'str'
```
In this commit we resolve this issue
opw-5079789
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe spreadsheet interface now consistently uses the light theme because dark theme is not supported there. This prevents mixed light and dark styling, giving users a clearer and more consistent experience.
Original PR description
Spreadsheet doesn't support dark theme. This fixes some style where dark and light themes are mixed. Task: 5082593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mollie payments that are created but still waiting, such as SEPA bank transfers, are now treated as pending instead of invalid. This prevents customers from seeing an error after checkout when their payment is expected to remain open until completed.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Mollie as a payment provider; 2. set up an eCommerce order in EUR; 3. go to checkout; 4. pay via Mollie; 5. pick SEPA bank transfer as payment method; 6. leave the transaction open. Issue ----- When returning from the redirect, we get the following error message: > Mollie: Received data with invalid payment status: open Cause ----- An 'open' payment indicates the payment has been created, but nothing else has happened yet[^1]. This is the expected status for bank transfers, but is currently not getting handled in `_process_notification_data`, leading to the error. [^1]: https://docs.mollie.com/docs/status-change Solution -------- Handle 'open' payments the same as 'pending' ones. opw-4894556 Forward-Port-Of: odoo/odoo#226642 Forward-Port-Of: odoo/odoo#225875
Users can now open assigned activities from the “View all activities” menu even when they do not have permission to view the related record. The activity opens in a safe form view so they can still complete the task, reducing access errors and workflow interruptions.
Original PR description
**Steps to reproduce** 1. Create an activity on a record and assign it to a user who doesn't have access to this record. (e.g. create an activity on a `hr.employee` record and assign to a user without HR rights). 2. With this user lacking access rights, click on "View all activities" in the systray. 3. Click on the activity: error **Cause** The user may not have access rights to the record related to an activity. **Change** Open the activity's form view, we use `mail_activity_view_form_without_record_access` to display the "Mark as done" button. opw-4925744
The automation rule trigger dropdown now uses the correct background color when dark mode is enabled. This keeps the interface visually consistent and easier to read for users working in dark mode.
Original PR description
Steps: - Install `base_automation` - Enable dark mode - Open Automation rules - Create a new rule - open trigger dropdown - the dropdown background is still in light mode This commit apply $dropdown-bg on `o_field_base_automation_trigger_selection` opw-5064357 Forward-Port-Of: odoo/odoo#226116
Fixes an issue where moving documents into a folder previously visited by the same members could accidentally remove those members' access. This helps ensure shared documents remain available to the intended people after being reorganized.
Original PR description
When moving documents with members to a folder which has been visited by those same members (or some of them) they are removed from those documents access. This is caused by the document.access which has an entry for the members but with a null role. Task-5075196
The journal report test was updated so it no longer depends on a payment reference staying blank in all local accounting setups. This prevents false build failures when Czech localization is installed, improving release reliability without changing customer-facing behavior.
Original PR description
test_document_data_basic was failing in builds with l10n_cz installed because - we set move_sales_2.payment_reference = '' in setUpClass and without l10n_cz it stays empty - but with l10n_cz installed it gets recomputed because of precompute=True on taxable_supply_date (which a stored computed field that triggers an extra write on account.move when the company is in CZ, and that write causes the compute graph to run again, and _compute_payment_reference fills the value back in) this commit solves this issue by not making assumptions about the payment_reference value and would use it as is in the generated data validation build_error-231479
Tax return closing entry reports now keep the selected tax period when generating PDF or XML files. This prevents reports for a prior month, such as August, from incorrectly showing the posting month, such as September.
Original PR description
**Issue** When posting a closing entry in September on a tax return report for the month of August, the generated report (PDF/XML) incorrectly shows September instead of August. **Steps to Reproduce** 1. Install Belgian localization. 2. Go to Accounting > Reporting > Tax Return. 3. Select August as the reporting period. 4. Post the Closing Entry. 5. The report shows September as the month instead of August. **Root Cause** The logic in `_init_options_date` was changed in PR #89290 mutating the `options['date']['filter']` by replacing `"tax_period"` with a resolved period type (e.g., `"month"`). As a result, the `"month"` branch was triggered later in the code, recomputing `date_from` and `date_to` based on the current date instead of the selected tax period boundaries. **Fix** Keep the `options['date']['filter']` unchanged (e.g., `"custom_tax_period"`). Use `period_type` field to indicate whether the tax period represents a month, quarter, or year. Opw-5073081
Tax report values are now protected from edits once the relevant tax period has been locked, helping preserve submitted tax data. The tax closing process was adjusted so required default values are created before the lock date is applied, with a temporary exception for a French VAT filing edge case.
Original PR description
[FIX] account_reports: external value check lock date This commit add the check that protects external values from being edited out of the lock date. For example when the tax report is submitted, the…
[FIX] account_reports: external value check lock date This commit add the check that protects external values from being edited out of the lock date. For example when the tax report is submitted, the user is not supposed to modify any external values anymore. To do this, we had to modify the tax closing flow a little bit: when closing the tax period, we now generate the default external values before setting the tax lock date. This is because the generation of the default external values was done for the period we were closing, but now that we forbid the creation of an external value after the lock date we had to change the order of the flow. Due to one specific corner case (l10n_fr), we had to keep a hack to bypass the Tax Return Lock Date check. This was done with a context key and will have to be removed in master. The case is the following : when the user generates the tax closing entry, the external values for the period are generated and the Tax Return Lock Date is set with the last day of the month. Then if the user tries to submit the EDI VAT report, it tries to create 2 external values for the carryover but as the lock date was set, it raises an error. task-5012442
This fixes a time off workflow issue where approving a leave that deducts extra hours could proceed without creating the required negative overtime record. Businesses get more reliable extra-hours balances when leave requests are refused, reset, and approved again.
Original PR description
**Issue** - Create a leave for a time off type deducting extra hours. - Check: a negative overtime (`hr.attendance.overtime`) has been created. - Approve, refuse and reset the leave. - Inconsistency: state is in "confirm" state, but no overtime exists. - Approve the leave. - Issue: no overtime exists. **Cause** The forward port 8dd74bc723fe8ddffaac718f537f6284f341bfe6 didn't correctly consider the removal of the "Draft" leave state. **Change** Ensure leaves in "Confirm" and next steps have an associated negative overtime. opw-4815190
The attendance Gantt popup now lets users enter a checkout time for an open attendance directly in the popup. This removes a frustrating blocker for correcting attendance records without leaving the Gantt view.
Original PR description
The Gantt popup form explicitly set `check_out` invisible when it was empty, which prevented users from manually entering a checkout for an open attendance. This commit removes the overriding xpath so that the form simply inherits the standard `hr_attendance_view_form` behavior, where the `check_out` field is always visible and editable. Users can now set a manual checkout directly from the Gantt modal. task-5026978
2 changes
Resolved issues and error corrections
Users with approval rights can now view other users' timesheets on private project tasks they follow. This prevents approvers from missing relevant time entries when they already have access to the task.
Original PR description
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security…
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access. https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117 **Steps to reproduce:** 1. Create a private project (`privacy_visibility == 'followers'`) 2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access 3. Add Marc Demo as a follower of a task in that private project 4. Have another user log time on that task 5. Log in as Marc Demo Marc cannot see the other user's timesheets, neither on the task form nor in reporting. opw-5022877
This update adds the missing SZJ product code required by Hungary's official NAV electronic invoicing specification. It helps ensure Hungarian invoice data can be classified correctly and stay aligned with regulatory documentation.
Original PR description
Description of the issue/feature this PR addresses: In the official NAV XML 3.0 documentation (available at: https://onlineszamla.nav.gov.hu/dokumentaciok page 123), according to the list of possible product codes, there is an 'SZJ' code that is missing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr