Daily updates from Odoo
Wednesday, May 13, 2026
54 changes · saas-19.3
Resolved issues and error corrections
This update resolves a technical error that prevented users from generating balance sheet comparisons correctly. The fix ensures that date types are consistently handled, allowing the 'Comparison' smart button to function as expected. This improves the reliability of balance sheet reporting.
Original PR description
Step to reproduce - Install the accountant module. - create a fiscal year (for 01/01/26 to 30/06/26) from setting and enable it - Navigate to Accounting > Report > Balance Sheet - Click the…
Step to reproduce
- Install the accountant module.
- create a fiscal year (for 01/01/26 to 30/06/26) from setting and enable it
- Navigate to Accounting > Report > Balance Sheet
- Click the `Comparison` smart button and set `Previous Period` to `2 periods`.
Observation:
- we face a traceback
``` File "/home/odoo/odoo/codebase/enterprise/saas-19.2/account_reports/models/account_report.py", line 5739, in _get_annotations
period_date_from = self._adjust_date_for_joined_comparison(options, period_date_from)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/codebase/enterprise/saas-19.2/account_reports/models/account_report.py", line 5695, in _adjust_date_for_joined_comparison
return min(period_date_from, comparison_date_from)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'datetime.date' and 'str'
```
Cause:
- `_get_period_dates` return string in case we have date which falls in
`custom_range_match`, when `get_report_information` is called, while
`period_date_from` is of type date
- hence there is mismatch between types
Fix:
- `_get_period_dates` is supposed to return date object always, hence fixed the
return type in case we have match for custom range
opw-6185629
Forward-Port-Of: odoo/enterprise#116350This update simplifies a confusing error message related to multiple GST registrations within an organization. The previous message led to wasted support time and incorrect reports. Now, users are prompted to verify their GST username matches their GST number, providing a clearer solution.
Original PR description
Users operating with multiple GST registrations (GST-wise branches/companies) could encounter a misleading error when the GST username belonged to a different GST number within the same organization. Previously, the system raised an error directly received from the server: [AUTH4041] Invalid Parameter state-cd in request header This message was confusing and led to unnecessary support tickets and false reports, as the issue was actually a mismatch between GST username and number. The error message has been updated to be more explicit and user-friendly: Please confirm that <gst_username> is associated with <gst_number>. Additionally, refactored duplicated logic by extracting the common code into a single helper function and reusing it across all occurrences. task-6041510 Forward-Port-Of: odoo/enterprise#111115
This update resolves an issue where rapid actions triggered duplicate entries being created in the database for account return checks. The fix prevents multiple simultaneous processes from attempting to create the same record, ensuring data integrity. This improves the stability and efficiency of the account reporting feature.
Original PR description
Issue -------------- When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to…
Issue
--------------
When refreshing checks on account returns (e.g. from rapid successive clicks or component re-renders), multiple concurrent RPC calls to `refresh_checks` were being dispatched to the server. This created a race condition that resulted in duplicate `account.return.check` records being generated in the database.
steps to reproduce demonstrated in video: https://drive.google.com/file/d/1-A0ZHdYGdv-UL0dqClqK6Kos_iVXoZai/view?usp=sharing
When this happen the `runAllReturnChecks` method fires parallel RPC calls to [`refresh_checks`](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1974-L1992) on the server. In the case of instant multiple RPC calls, parallel threads are dispatched which causes the data preparation stage to run simultaneously.
Because both threads run in parallel, Thread 2 runs its [preparation and existing ](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1986-L1987 )check mechanism before Thread 1 has reached the actual `create()` function [trigger](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/account_reports/models/account_return.py#L1998-L1999). Consequently, Thread 2's existence check fails to find the record (since Thread 1 hasn't committed it to the database yet), and it considers the record eligible for creation—even though the exact same record is already prepared for creation by Thread 1. This race condition leads to duplicate `account.return.check` records.
Logs to demonstrate the thread execution:
--------
```python
2026-04-16 08:30:51,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.000 0.002
2026-04-16 08:30:51,662 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.report/dispatch_report_action#account.report.dispatch_report_action HTTP/1.0" 200 - 17 0.006 0.012
2026-04-16 08:30:51,847 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:51] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 26 0.009 0.025
2026-04-16 08:30:52,099 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 95 0.029 0.064
2026-04-16 08:30:52,320 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:52] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.004
THREAD NAME: odoo.service.http.request.137360481711808 Thread ID: 137360481711808
REFRESH CHECK START:--------------------------------------------
Thread ID: 137360481711808 -------------DATA PREPARING STAGE------------
Thread ID: 137360481711808
Thread ID: 137360481711808 RECORD EXISTING CHECK: None
2026-04-16 08:30:53,842 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:53] "GET /odoo/tax-report/tax-return?debug=1 HTTP/1.0" 200 - 29 0.020 0.021
2026-04-16 08:30:54,066 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/load_menus HTTP/1.0" 200 - 4 0.002 0.009
2026-04-16 08:30:54,351 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/manifest.webmanifest HTTP/1.0" 200 - 6 0.003 0.005
2026-04-16 08:30:54,493 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/webclient/translations?hash=bb5aa713d587cc7dd07b13d1d7efc2c525517e99&lang=en_US HTTP/1.0" 200 - 1 0.000 0.002
2026-04-16 08:30:54,586 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/bundle/web_tour.interactive?lang=en_US&debug=1 HTTP/1.0" 200 - 1 0.001 0.003
2026-04-16 08:30:54,640 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/action/load_breadcrumbs HTTP/1.0" 200 - 7 0.003 0.006
2026-04-16 08:30:54,710 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/ir.http/lazy_session_info#ir.http.lazy_session_info HTTP/1.0" 200 - 2 0.001 0.004
2026-04-16 08:30:54,753 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /bus/websocket_worker_bundle?v=19.0-2 HTTP/1.0" 304 - 3 0.004 0.006
2026-04-16 08:30:54,766 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "GET /web/image?model=res.users&field=avatar_128&id=2 HTTP/1.0" 304 - 9 0.012 0.013
2026-04-16 08:30:54,777 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /mail/data HTTP/1.0" 200 - 34 0.034 0.020
2026-04-16 08:30:54,824 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/get_views#account.return.get_views HTTP/1.0" 200 - 3 0.001 0.010
2026-04-16 08:30:54,934 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:54] "POST /web/dataset/call_kw/account.return/web_read_group#account.return.web_read_group HTTP/1.0" 200 - 88 0.029 0.051
2026-04-16 08:30:55,107 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "POST /web/dataset/call_kw/account.return/get_next_returns_ids#account.return.get_next_returns_ids HTTP/1.0" 200 - 2 0.001 0.005
THREAD NAME: odoo.service.http.request.137360513177280 Thread ID: 137360513177280
REFRESH CHECK START:--------------------------------------------
Thread ID: 137360513177280 -------------DATA PREPARING STAGE------------
Thread ID: 137360513177280
Thread ID: 137360513177280 RECORD EXISTING CHECK: None
2026-04-16 08:30:55,589 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:55] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.006
2026-04-16 08:30:56,702 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:56] "GET /web/service-worker.js HTTP/1.0" 200 - 1 0.000 0.003
2026-04-16 08:30:58,893 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:30:58] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.006 0.023
2026-04-16 08:31:05,296 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:05] "GET /websocket?version=19.0-2 HTTP/1.0" 400 - 1 0.001 0.002
Thread ID: 137360481711808 DATA to_create: 168
Thread ID: 137360481711808 done process create
2026-04-16 08:31:10,132 14 INFO bsra_4165887_upg werkzeug: 202.131.97.106 - - [16/Apr/2026 08:31:10] "POST /web/dataset/call_kw/account.return/refresh_checks#account.return.refresh_checks HTTP/1.0" 200 - 513 11.611 6.039
Thread ID: 137360513177280 DATA to_create: 168
Thread ID: 137360513177280 done process create
```
- OPW: 5917459
Forward-Port-Of: odoo/enterprise#114045This update fixes an issue where newly created stock batches were incorrectly named 'New' instead of following the standard 'BATCH/<TYPE>/000NN' naming convention. The change ensures that all new batches are correctly named, improving data consistency and reporting accuracy within the Delivery Orders feature. This resolves a bug impacting batch identification.
Original PR description
Steps to reproduce 1. Open the Barcode app > Operations > Delivery Orders. 2. Switch to the "Batches" tab. 3. Create a new one. Issue The created batch keeps the placeholder name "New" instead of…
Steps to reproduce
1. Open the Barcode app > Operations > Delivery Orders.
2. Switch to the "Batches" tab.
3. Create a new one.
Issue
The created batch keeps the placeholder name "New" instead of being
renamed to `BATCH/<TYPE>/000NN`.
The barcode kanban "New" button calls `open_new_batch_picking`, which
runs `Batch.create({})` while the action context carries
`default_picking_type_id` set by `stock.picking.type._get_action` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock/models/stock_picking.py#L432.
Since `vals` itself doesn't carry `picking_type_id`, the lookup in
`stock.picking.batch.create()` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock_picking_batch/models/stock_picking_batch.py#L181
returns an empty recordset, so the sequence-based rename branch is
skipped and the name stays at the field default `'New'`. The
subsequent `super().create` then applies the context default, so the
batch is correctly linked to a picking type but with the wrong name.
opw-6168320
Forward-Port-Of: odoo/enterprise#115809This update fixes a visual inconsistency in the appearance of website tabs when translating content. Specifically, it ensures that the translation state is correctly displayed for tab descriptions. This resolves a previously known issue, improving the overall user experience and consistency of the Odoo website.
Original PR description
Span elements which have a style that causes them to be displayed as "block" do not have the background color given by the translation span (this is a ["known" issue]) To show the translation state on those nodes, this commit uses the resource `force_background_translation_state_selectors` for the following: - `.o_nav_tabs_description`, the description of tabs in `s_tabs_images` Introduction of `force_background_translation_state_selectors`: cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 ["known" issue]: https://github.com/odoo/odoo/commit/9addf9617830885532c27abb0ad5fa915e9f8f62 task-5892636 Forward-Port-Of: odoo/odoo#263620
This update fixes an issue where subsections remained visible on invoices even after the 'Hide Composition' option was selected. The underlying code was updated to ensure subtotals and unit prices are correctly hidden when this feature is enabled, aligning invoice presentation with 'Hide Prices'.
Original PR description
### Steps to reproduce: - Download 'Sales' app and create a product - Create an invoice with a section and a subsection - Set `Hide Composition` on the section - Add a product line under the subsection - Confirm and preview the invoice report > The subsection is still visible _Same issue occurs when activating 'Hide Prices'_ ### Cause of Issue: The `report_invoice.xml` file didn't include the right conditions to display the subtotals and unit prices in case of 'Hide Composition'/'Hide Prices'. Also, taxes were returned in `account_move_line` when they shouldn't be visible in case of 'Hide Prices'. ### Fix: Altered the conditions for sections and subsections, so that the information showing in 'Quotations' and 'Invoices' are consistent. opw-6069334 Forward-Port-Of: odoo/odoo#263944 Forward-Port-Of: odoo/odoo#258628
This update corrects a previous oversight by adding the 'l10n_pl_bank_verification' module to the weblate.json file. This ensures that the new bank verification functionality is correctly translated and available within the Odoo application for Polish users.
Original PR description
[FIX] Add l10n_pl_bank_verification to weblate.json In a previous PR, we added the new module 'l10n_pl_bank_verification' but didn't added it in weblate.json. This PR fix it See odoo/odoo#262518 Forward-Port-Of: odoo/odoo#263758
This update resolves a technical error that prevented the system from correctly identifying project documents when a project lacked a designated folder. The fix ensures the system handles projects with and without associated document folders smoothly, improving data accuracy and preventing potential errors during document retrieval.
Original PR description
The `_compute_documents()` method was expecting that the `documents_folder_id` field was always set.
However, the field is not required and can be empty.
This is not an issue if the compute is called on a single record, but when called on a recordset with :
- A project with related folder with at least one document
- A project with `documents_folder_id` empty The compute will fail because it calls `startswith()` with a parameter that is `False`.
```python
File "/home/odoo/src/enterprise/19.0/documents_project/models/project_project.py", line 50, in <lambda>
document_ids = documents.filtered(lambda doc: doc.parent_path.startswith(project.documents_folder_id.parent_path))
TypeError: startswith first arg must be str or a tuple of str, not bool
```
Solution:
Check for project-related documents only if the dedicated folder is set.
Forward-Port-Of: odoo/enterprise#117066This update refines how Odoo automatically matches bank statements to invoices and payments. Previously, it prioritized the closest date, which wasn't always accurate. Now, it only matches if there's one prior statement candidate, ensuring more reliable reconciliation and reducing potential errors in financial reporting.
Original PR description
Before this pr, we decided that when there was multiple candidates, we would take the one closer to the date of the statement line but it is not always what we want. We decided to change that so that it would match only if there is one candidate prior the date of the statement line. Exemple: Invoice 1 the 10/06 and invoice 2 the 20/06 → Payment the 05/06 → no matching (0 before) → Payment the 15/06 → match with invoice 1 (only 1 before) → Payment the 25/06 → no matching (More than 1 invoice open before) task-6143809 Forward-Port-Of: odoo/enterprise#115888 Forward-Port-Of: odoo/enterprise#115284
This update resolves an issue preventing accurate translation exports from the Web Studio interactive editor. A specific formatting error in the code templates was causing incorrect data extraction, leading to translation failures. The fix removes this problematic formatting to ensure correct export and translation of code.
Original PR description
It seems that the Babel Javascript tokenizer is not able to correctly parse a template string starting with a backslash and a newline. This caused it to extract pieces of code coming after it. The code excerpts would be exported in the POT file, but not applied to the JS code of course. The original message was not exported though, so it was not possible to translate it. This commit rewrites the template string to not use a backslash and a newline. This way the string is properly extracted and the code after it is not. Change was introduced by this commit[^1]. [^1]: https://github.com/odoo/enterprise/commit/56a2d9c4c2cc655af0469038d4c483581ac78864 Forward-Port-Of: odoo/enterprise#116927
This update fixes an issue where loyalty point transactions in POS orders were only recorded as a net difference, not the individual earned and spent amounts. The change ensures that the loyalty history accurately reflects the complete transaction, providing a more precise record of customer loyalty activity. This improves reporting and data accuracy for managing customer rewards.
Original PR description
When a loyalty card both earned and spent points in the same POS order, the history entry only reflected the net difference instead of the gross amounts. The root cause was that the JS payload sent only a single `points` field representing the net change. Fix by tracking `points_earned` and `points_spent` separately in `couponData` and sending them to the server. opw-6041420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262314 Forward-Port-Of: odoo/odoo#256022
This update fixes a recurring issue where Odoo would repeatedly retry sending eTIMS transactions, leading to an error (924). The change improves reliability by intelligently handling network interruptions and ensuring that invoice numbers are not duplicated, preventing delays and data inconsistencies. This ensures smoother eTIMS processing for Kenyan customers.
Original PR description
When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already…
When the network drops after eTIMS processes a transaction but before Odoo receives the confirmation, Odoo would retry with the same invoice number, causing eTIMS error 924 (Invoice number already exists). For POS orders, the old code decremented the sequence on any error (including timeout), so the next retry consumed the same invcNo. If eTIMS had already recorded the original send, the retry was rejected with 924. Fix by introducing a fetch-first strategy: on retry, if a pending invcNo is found in l10n_ke_order_json, call selectInvoiceDetails before sending. If eTIMS already has the invoice, recover the receipt data directly without resending. If eTIMS does not have it, resend with the same invcNo safely. On timeout errors, the sequence is no longer decremented so the invcNo is preserved in l10n_ke_order_json for the next idempotent retry. For customer invoices, the existing fetch-first logic only bailed out on TIM (timeout) errors, falling through on CON (connection) errors and retrying blindly. Additionally, if saveTrnsSalesOsdc returned 924, there was no recovery path and the invoice number would be cleared. Fix by also bailing on CON in the fetch block, and adding an explicit 924 handler that calls selectInvoiceDetails to recover the existing receipt instead of failing. opw-6105693 Forward-Port-Of: odoo/enterprise#115649
This update fixes a layout issue on the shop page for users who view the website in RTL (Right-to-Left) language settings. The previous layout was broken due to incorrect spacing, and this change ensures the shop grid displays correctly for all users. This improves the overall user experience for a wider range of customers.
Original PR description
Prior to this commit, the shop grid layout was broken in RTL due to misplaced left borders and padding. This commit adjusts those elements for RTL, fixing the layout. task-5933289 | Before | After | |--------|--------| | <img width="1406" height="869" alt="Screenshot 2026-05-04 at 10 37 56" src="https://github.com/user-attachments/assets/81f057cc-89d3-44f6-a723-9b439b88290d" /> | <img width="1392" height="877" alt="Screenshot 2026-05-04 at 10 36 53" src="https://github.com/user-attachments/assets/ded4eb4a-c82d-4114-ade6-5455f341a8f5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262483
This update fixes a technical issue where linking restaurant tables could cause an infinite loop, potentially disrupting table management. The fix ensures correct table positioning calculations, particularly when tables are merged, preventing errors and maintaining data integrity. This improves the reliability of the restaurant table functionality.
Original PR description
Before this commit, it could happen that we try to link a restaurant table to another that was already its parent (for example by merging them while offline, we couldn't know that they were in a prent-child relation). This would lead to an infinite loop when trying to get the position of the table since it was computed based on the parent position so when a table is its own grand-parent, we get an active infinite loop. We solve the problem by going through the backend to merge tables. Task-id: 6183779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262642 Forward-Port-Of: odoo/odoo#262509
This update fixes a bug that occurred when users tried to reschedule marketing activities, specifically within automated campaigns. The change prevents errors related to missing parent information, ensuring campaigns run smoothly and reliably. This improves the stability of our marketing automation features.
Original PR description
**Steps to reproduce:** - Create a new marketing campaign with two activities - Set them to occur some number of days after the beginning - Save the campaign and start it - Modify one of the…
**Steps to reproduce:** - Create a new marketing campaign with two activities - Set them to occur some number of days after the beginning - Save the campaign and start it - Modify one of the activities to occur some number of days after the other activity and save - Modify the child activity by changing the number of days after its parent that it should run and save - An error will be thrown **Issue:** The trace related to the child activity has no parent when trying to reschedule it in `_update_schedule_date`. This causes an issue when trying to get the first mailing_trace_ids using index 0 in this line: `base_dt_str = trace.parent_id.schedule_date or trace.parent_id.mailing_trace_ids[0].write_date or trace.participant_id.create_date` **Fix:** Prevent the activity hierarchy to be modified on started campaigns. We also change the indexing to avoid further out of range issue and properly default on the participant create value. Trying to match existing traces to their parents has too many edge cases when trying to avoid duplicates, and might often need to reset the whole trace chain to work properly. This approach avoids user mistakes on running campaigns, but if a user tries to launch a test (even on draft campaign) he won't be able to modify the hierarchy further without deleting/recreating some activities/traces. So we should ignore this for test traces, but it could impact the behavior between test and actual executions. opw-5362978 Forward-Port-Of: odoo/enterprise#107556
This update fixes a visual flicker in the timesheet timer field when saving data. By rounding the timer value on the server-side and validating record data before saving, the flicker is eliminated, ensuring a smoother and more reliable user experience. Additionally, the delete button visibility was adjusted to prevent a related flicker issue.
Original PR description
before: The timer value is rounded to the record, then the saving attempt is made. This makes the timer flicker to the rounded value for a split second if the saving operation failed (ex. missing data) after: The record is updated with the rounded value if the saving operation is valid. We check the record validity before saving or updating the record. --- task-6120567 Forward-Port-Of: odoo/enterprise#114502
This update adds sample accounting data specifically for the Italian localization (l10n_it). This allows our team to easily test and demonstrate the Italian version of Odoo, ensuring accurate reporting and compliance with Italian accounting standards. The data includes key elements like invoices, bank accounts, and EDI information.
Original PR description
Purpose: Load a pre-configured set of Italian accounting sample data to facilitate localization testing and demonstrations. Specifications: This commit introduces comprehensive sample data for the Italian localization, configuring the following: * Partners * Bank Accounts * Invoices & Bills * Dynamic Dates: All generated moves use a relative date format to ensure testing data remains relevant and doesn't expire on runbot. * EDI Data: Populates necessary e-invoicing fields (`l10n_it_codice_fiscale`, `l10n_it_pa_index`) for the created partners. task-6103257 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263881 Forward-Port-Of: odoo/odoo#262711
This update optimizes the PDF generation process for Odoo's SA (Saudi Arabia) edition, addressing a significant performance bottleneck. Previously, PDF creation was delaying checkout, but ZATCA now only requires XML and QR codes. This change dramatically speeds up the checkout process for SA users.
Original PR description
For SA companies, wkhtmltopdf PDF generation was accounting for ~47% of the sync_from_ui response time (~3.1s out of ~6.5s total), blocking the cashier at every order. The PDF is not needed during checkout: ZATCA requires only the signed XML and returns the QR code. The PDF can be generated on demand when the invoice is first viewed or downloaded. opw-6019994 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261417 Forward-Port-Of: odoo/odoo#253641
This update fixes an issue where file boxes, even after deleting their content, wouldn't be fully removed from the To-Do creation screen. The fix allows deleting non-editable file boxes when they are fully selected and their parent is editable, ensuring a cleaner user experience.
Original PR description
Problem: When adding a file box, selecting all content, and deleting, the file box is not removed. Cause: `o_file_box` is non-editable, so `canBeDeleted` returns `false` for this node, preventing its deletion. Solution: Allow deletion of non-editable nodes when they are fully selected and their parent is editable. Steps to reproduce: - Go to To-Do → Create New. - Upload a file. - Type some text next to the file. - Select all content (Ctrl + A or with the mouse). - Press Backspace/Delete multiple times. - Observe that the file box is not removed. task-6185206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263008
This update corrects inaccuracies in the data used for payroll calculations in Belgium (l10n_be_hr_payroll_prisma). Specifically, it addresses missing codes related to leave types (LEAVE280, LEAVE115, LEAVE231) to ensure accurate reporting and compliance. This improves the reliability of payroll processing.
Original PR description
Issue: ---------------------------------------- Some prisma codes are wrong. Solution: ---------------------------------------- Change the data files. There are some subtilities that were not implemented: - LEAVE280: 0304 (if less than a year) and 0345 (if more) - LEAVE115: 0820 (Work accident) and 0830 (Occupational Disease) opw-6090081 Forward-Port-Of: odoo/enterprise#116808 Forward-Port-Of: odoo/enterprise#112949
This update resolves an error that occurred when calculating overtime deductions for employees with specific filing statuses (other than 'single' or 'jointly'). The fix ensures the system correctly handles different filing status values, preventing a crash. This improves the accuracy of overtime calculations for a wider range of employee scenarios.
Original PR description
Issue: ---------------------------------------- When having an employee with `l10n_us_filing_status` not in `['single', 'jointly']` and evaluating the rule parameter…
Issue: ---------------------------------------- When having an employee with `l10n_us_filing_status` not in `['single', 'jointly']` and evaluating the rule parameter `l10n_us_qualified_overtime_deduction_cap` an error occurs. Cause: ---------------------------------------- `l10n_us_filing_status` can have 5 values: `['single', 'jointly', 'separately', 'head', 'survivor']` But only `['single', 'jointly']` are defined for `l10n_us_qualified_overtime_deduction_cap` ([src](https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_rule_parameters_data.xml#L48)). When running the rule "Qualified Overtime", the custom Python crashes because we read a key that is not there: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L56 Solution: ---------------------------------------- In the custom Python condition, we first check if the key is there. The custom Python computation also tries to read the key, but it is run only if the condition is validated. So we don't need to change it. Also fixed indentation of test 069. opw-6129657 Forward-Port-Of: odoo/enterprise#116913 Forward-Port-Of: odoo/enterprise#115754
This update resolves an issue where Swedish characters in import files were being incorrectly interpreted, resulting in misformatted account data. The fix ensures that account names are imported accurately, specifically addressing the 'vriga imm anl tillg' error for account 1090. This improves data integrity for Swedish businesses using the Odoo Enterprise system.
Original PR description
Issue: Non-ASCII charatcter from sie file were lost on import. Steps to reproduce: - in a Swedish company - import the SIE4 exemple file from sie website: https://sie.se/wp-content/uploads/2024/01/SIE4-Exempelfil-Sample-file-1.zip Current behavior: - The account 1090 is imported as "vriga imm anl tillg" instead of "Övriga imm anl tillg" Expected behavior: - The account 1090 is imported as "Övriga imm anl tillg" Cause: CP437 uses 8 bits to represent data. Ö is \x99. However, file was imported using either UTF-8 or ISO-8859-1, where Ö is \xC396 and \x99 doesn't link to anything. This commit update the test file as it was save in cp437 but read as UTF-8. opw-6167408 Forward-Port-Of: odoo/enterprise#116722
This update resolves a crash that could occur when attempting to unassign items from a stock reception report if the associated source document (like an order) was empty. The fix prevents the system from trying to remove references to non-existent documents, making the report more reliable for all users. This change ensures a smoother user experience and prevents unexpected errors.
Original PR description
#### Issue: Clicking `Unassign` from the stock reception report could raise a traceback when the outgoing move source document was empty. ``ValueError: Expected singleton: mrp.production()`` Please…
#### Issue: Clicking `Unassign` from the stock reception report could raise a traceback when the outgoing move source document was empty. ``ValueError: Expected singleton: mrp.production()`` Please note that this is not expected in standard Odoo, where reception report moves should normally be linked to a source document, such as an MO, SO, or picking. This case seems specific to the client database and may be due to a customization, but handling it makes the reception report more robust. #### Cause: The reception report built report lines from `source = (move._get_source_document(),)` and checked `if not source`. Since the tuple itself is truthy, moves whose `_get_source_document()` returned an empty recordset were not filtered out. For example if `out_move._get_source_document()` returns `mrp.production()`, then `source = (mrp.production(),)` is still truthy, so the report keeps the line even though the source document is empty. later `action_unassign()` called `_remove_reference()` on that empty source document, which crashed on `ensure_one()`. #### Fix: Added a helper function that skips moves where `_get_source_document()` is empty. Also skip reference synchronization in `_action_assign()` and `_action_unassign()` when the source document is empty just for more protection. opw-6174870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263700 Forward-Port-Of: odoo/odoo#263366
This update resolves an issue where the DIAN (Colombia) information wasn't appearing on invoice PDFs in version 19.3. The fix reordered a section within the invoice XML to ensure all required data, including the DIAN code, is correctly rendered. This ensures accurate reporting for Colombian businesses.
Original PR description
**STEP TO REPRODUCE** 1. Setup DIAN. 2. Create an invoice. 3. Send it to dian. 4. Notice the cufe doesn't appear on the pdf. This fix moves the CUFE div before the informations div. Before the fix, it was placed at the top of the xml which appears to not render starting from 19.2. opw-6182706 Forward-Port-Of: odoo/enterprise#116245
A technical bug in the expense reporting feature has been resolved. The issue occurred when searching for customers within expenses, specifically related to the 'costumer to reinvoice' field. This fix ensures accurate search results and prevents a traceback error, improving the usability of the expense reporting process.
Original PR description
**PROBLEM** & operator must be used with 2 Domain. https://github.com/odoo/odoo/pull/206894 forget to convert the right side part to a domain, leading to a traceback. 1. Install sale and expense_sale. 2. Set the Sales/Sales permission to "User: Own Documents only". 3. Create an expense of type communication. 4. On the field "costumer to reinvoice", start typing to search. 5. A traceback will occur. opw-612755 Forward-Port-Of: odoo/odoo#263861
This update fixes a minor issue where the 'Plan' button appeared on the Gantt view even when no Sales Order Lines were available to plan. The fix ensures the button only appears when there's a valid SOL to work with, streamlining the user experience and preventing unnecessary form openings.
Original PR description
Steps to reproduce: === - Go to Planning → Gantt view. - Click on an empty cell where no Sale Order Line (SOL) exists. - Observe that the Plan button appears in the multi-selection toolbar. Issue: === The Plan button is shown even when there are no SOL to plan, and clicking it opens the planning form dialogue, which should not happen in this scenario. Cause: === The visibility of the Plan button relies solely on whether `onPlan` is defined. There is no built-in validation to check whether any SOL actually exists for the selected cell before exposing the 'onPlan' action. Fix: === Introduce a new reactive prop `hasAvailableSOL` and compute it before `onPlan` is used. The Plan button is now shown only when an SOL actually exists. task- 5163638 Forward-Port-Of: odoo/enterprise#99517
This update fixes an issue where flexible employees were incorrectly shown as unavailable in the Project Gantt chart. The change ensures that flexible employees without scheduled leaves are accurately displayed, aligning with the expected behavior of showing only approved leaves and holidays. This improves the accuracy of project timelines.
Original PR description
Steps to Reproduce --- - Assign a flexible working schedule to an employee (no leaves) - Open Project > Tasks > Gantt view grouped by Assignee - The employee's weekends and off-hours are grayed out…
Steps to Reproduce --- - Assign a flexible working schedule to an employee (no leaves) - Open Project > Tasks > Gantt view grouped by Assignee - The employee's weekends and off-hours are grayed out Current Behavior --- Flex employees with no approved leaves in the viewed date range have incorrect grayed-out days in the Project Gantt view. Expected Behavior --- Flex employees should have no grayed-out days except approved leaves and public holidays. Issue --- When a flex employee has no leaves in the viewed period, `_get_unavailable_intervals()` returns an empty dict for that resource. `_gantt_unavailability()` then falls back to `company_leaves`, producing incorrect gray intervals. The same case is already handled in `planning` (ref PR), but `project_enterprise` was not covered. Fix --- Add a guard in `_gantt_unavailability()` to return no unavailabilities for flexible resources absent from `leaves_mapping`. Related : https://github.com/odoo/odoo/commit/5f1cd39944134ffa2c30c331f8a5daca56446d78 task - 5063071 Forward-Port-Of: odoo/enterprise#116847 Forward-Port-Of: odoo/enterprise#113247
This update fixes an issue where public holidays in different companies were incorrectly impacting employee time tracking reports. The fix ensures that only company-related public holidays are considered when generating these reports, preventing inaccurate planned hour calculations. This improves the accuracy of time tracking data.
Original PR description
## Steps to reproduce: - Install project_timesheet_forecast module - Create a public holiday in one company - In another company create a planning slot for an employee that overlaps with the holiday - Go to Timesheets/Planning analysis report - Notice the report is not showing planned hours for the employee on the day of the public holiday ## Cause: When filtering the resource_calendar_leaves we don't check for the company so any public holiday in any company will be taken into account even if it doesn't affect the employee ## Fix: Exclude holidays that has different company than the planning slot opw-5027070 Forward-Port-Of: odoo/enterprise#117015 Forward-Port-Of: odoo/enterprise#116263
This update resolves an issue where users could unintentionally create links within inline code or code blocks while using the Ctrl+K shortcut in the HTML editor. The change ensures that selections within code blocks are treated correctly, preventing the automatic generation of links. This improves the stability and usability of the HTML editor for all users.
Original PR description
Description of the issue this PR addresses: This commit ensures that links are not created when the selection is inside inline code or a code block, even when using the Ctrl+K shortcut. task-5489870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262778 Forward-Port-Of: odoo/odoo#262397
This update ensures that the Studio XML editor only translates views for the currently selected website, preventing unintended translations across all websites. The change corrects a previous behavior where the default website's language was used, improving the user experience and ensuring accurate website localization. This fix is designed to maintain compatibility with existing customizations.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. While in debug mode, enter Studio and navigate to a view that has translation terms (ex. Sale Order Form view), then open the XML editor. opw-5136124 Foward Port of https://github.com/odoo/odoo/pull/237000
This update corrects an issue where the Studio XML editor incorrectly used translations from the first website in the database, regardless of the user's selected language. The fix ensures that translations are only applied to views within the Website module's HTML/CSS editor, improving the user experience and preventing unintended translation conflicts. This change maintains compatibility with existing customizations.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. While in debug mode, enter Studio and navigate to a view that has translation terms (ex. Sale Order Form view), then open the XML editor. opw-5136124 Foward Port of https://github.com/odoo/enterprise/pull/110418
A bug in the sale stock test was causing it to pass incorrectly due to a caching issue. This update ensures the test uses the correct, restricted user, triggering the intended access rights checks. This improves the reliability of our test suite.
Original PR description
When running the test, `button_validate()` was called twice in succession. - Once explicitly - Once through `process_cancel_backorder()` The first time it is called though, it's not through the restricted user that we want to test, allowing some access rights checks to run smoothly. The second time it's called with the restricted user, the cache still contains some data that should be no longer accessible, allowing the test to run even though it shouldn't. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264057
This update resolves an issue where regular stock users were unable to view sales orders, leading to access errors. The fix ensures all sales order deliveries, including inter-company transactions, can be properly accessed by standard users, improving operational efficiency.
Original PR description
When running `button_validate`, a regular stock user won't be able to access the related SO to check whether the partner is another company or not. This will raise access errors for all regular SO deliveries, regardless of being inter-company or not. Forward-Port-Of: odoo/enterprise#117047
This update fixes an issue where PDF Manager action names appeared awkwardly due to a styling class. The change removes this class, resulting in cleaner and more professional-looking action names within the PDF Manager interface. This improves the user experience.
Original PR description
Previously, pdf_manager actions used class "text-uppercase". Action names looked awkward. In this commit, we remove the class and properly display action names. task-6159317 Forward-Port-Of: odoo/enterprise#117000 Forward-Port-Of: odoo/enterprise#116382
This update fixes an issue where replying to notes using the HTML composer resulted in incorrect formatting and lost content. The change ensures proper spacing and formatting preservation when replying, leading to a more reliable and user-friendly note response experience.
Original PR description
Before this PR, Replying to a note with the HTML composer enabled had several issues. - The mention added did not include a trailing space. - If the composer already contained formatted content, reply action discarded all formatting because the content was overwritten using composerText, which is not formatting-aware. - the composer sometimes showed extra spacing between lines because the base container used a `<p>` tag instead of a `<div>`. This PR fixes these issues by - inserting the mention directly into composerHtml with an editable trailing space instead of mutating composerText. This preserves existing formatting, and correctly adds spacing after mentions. - The base container always use a `<div>`, preventing unwanted line spacing task-[5454785](https://www.odoo.com/odoo/project/1519/tasks/5454785) Forward-Port-Of: odoo/odoo#263901 Forward-Port-Of: odoo/odoo#242748
This update resolves an issue where users couldn't send messages from opportunities when a company partner was assigned. The previous system incorrectly checked for a direct match between the user and the assigned partner, failing when the user was a child contact. This change uses a more robust 'child_of' filter to ensure proper access, allowing messages to be sent correctly from company partners.
Original PR description
Steps to reproduce: 1) Create a partner contact form 2) Create a child contact for this partner, and grant it portal access 3) Create a customer contact form 4) Create an opportunity for the customer, with the previously created partner as "assigned partner" 5) Connect on the portal account of the partner 6) Send a message from an opportunity When a company partner is assigned to an opportunity (instead of a specific contact person), posting a message in the chatter raised a 404 NotFound error. _mail_get_operation_for_mail_message_operation was using a strict equality check (partner_assigned_id == user.partner_id), which fails when the assigned partner is the company and the user is a child contact under it. Replace the equality check with a child_of domain filter on commercial_partner_id, consistent with the logic already used in _assert_portal_write_access. Forward-Port-Of: odoo/odoo#259973 Forward-Port-Of: odoo/odoo#252854
This update fixes a previous issue where calls in inactive channels weren't showing up in the sidebar, confusing users. Now, when a call starts, the channel's 'last interest' date is updated, making calls more visible and improving the user experience. This ensures calls are easily found and reduces confusion.
Original PR description
Starting a call in an inactive channel could leave it hidden from the sidebar when the channel had no recent messages, which was confusing for users. To make call initiation more visible, update the channel's last interest date when the first participant joins the call, similar to call notification messages. Subsequent participants joining the same call do not update it again. task-6185134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263793
This update resolves several errors that could occur when Odoo processes NOTI files for Belgian payroll. These errors were preventing accurate tax calculations and reporting for businesses using the l10n_be_hr_payroll module. The fix ensures more reliable and accurate payroll processing for Belgian users.
Original PR description
Forward-Port-Of: odoo/enterprise#116871
This update fixes a frustrating issue where clicking 'Discard' in the Sign Template would cause the page to flicker and reload. Now, the discard process happens directly within the existing iframe, providing a smoother and more reliable experience for users. This improves usability and reduces confusion.
Original PR description
Before this commit, clicking Discard in Sign Template reloaded the action/PDF iframe, which caused flicker. The discard flow was also more complex than needed and field normalization was noisy. After this commit, discard now happens in place: we fetch fresh sign items/radio sets, reset fields inside the existing iframe, and keep the page mounted with no reload. task-6121560 Forward-Port-Of: odoo/enterprise#114892 Forward-Port-Of: odoo/enterprise#113853
This update enhances the logging of technical errors within the l10n_sa_edi module, which handles Saudi Arabia's VAT requirements. Previously, these errors were hidden to avoid confusing users, but now they are logged with a specific prefix for easier troubleshooting by our support and development teams. This improves our ability to quickly diagnose and resolve issues related to VAT processing.
Original PR description
Log suppressed technical validation failures in server logs with a stable ZATCA_ERROR prefix while keeping user-facing errors unchanged. task-6110313 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261536
This update fixes a bug in the Belgium Payroll DMFA report that incorrectly displayed 'Days Per Week' as 5 when employees worked fewer than 5 days. The fix ensures the report accurately reflects the employee's actual working schedule, improving the accuracy of tax reporting.
Original PR description
## Issue When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5. ## Steps to reproduce 1. Install…
## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.
## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
- set *ONSS Registration Number* to `0830123456`
- set *DMFA Employer Class* to `083`
- create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
- Work from 8:00 to 12:00
- Lunch from 12:00 to 13:00
- Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
- In the *Payroll* tab, set the start date of the contract to 01/01/2026.
- In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**
## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.
opw-6103934
Forward-Port-Of: odoo/enterprise#116963
Forward-Port-Of: odoo/enterprise#113804This update corrects a technical issue preventing the proper processing of end-of-service payslips when action_date is set. The fix ensures that departure registration actions can be executed correctly, resolving a test failure identified by Odoo's automated testing system. This improves the reliability of payroll processing for Jordanian users.
Original PR description
Setting action_date allows to execute departure.action_register on the same day. runbot error: https://runbot.odoo.com/odoo/runbot.build.error/242533 task: 6187007
This update removes outdated references to stock-related data within tests for the l10n_fr_pos_cert, pos_loyalty, and pos_self_order modules. Following a recent refactor of the POS module, these tests were no longer relevant, ensuring greater stability and accuracy of the testing process. This change ensures the POS modules function correctly.
Original PR description
*= l10n_fr_pos_cert,pos_loyalty, pos_self_order Issue: ====== - Some tests were still using stock-related fields and groups that were previously part of `pos`, but were moved to a new module `pos_stock` after the refactor. Fix: ===== - Remove references to these fields from the tests, as stock-related logic is now handled in `pos_stock` module. Task-6183114 Error-242928,243017,243059 Related Enterprise: https://github.com/odoo/enterprise/pull/116185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes outdated test references related to stock management within the l10n_mx_edi_pos and l10n_pe_edi_pos modules. Following a recent refactor of the POS stock functionality, these tests have been updated to align with the new module structure, ensuring accurate test results.
Original PR description
Issue: ====== - Some tests were still using stock-related fields and groups that were previously part of `pos`, but were moved to a new module `pos_stock` after the refactor. Fix: ===== - Remove references to these fields from the tests, as stock-related logic is now handled in `pos_stock` module. Task-6183114 Error-242928,243017,243059 Related Community PR: https://github.com/odoo/odoo/pull/262719
This update fixes a display issue where the number of ECOs listed on a Bill of Materials (BoM) was incorrect. The fix ensures that the count accurately reflects the ECOs directly associated with the current BoM version, resolving a misleading display for users. This improves the accuracy of BoM information and simplifies understanding of related changes.
Original PR description
Steps to Reproduce (Fresh Database): -------------------------------------- 1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules 2. Create a product > New -- Name: "Test Product" > Save 3.…
Steps to Reproduce (Fresh Database):
--------------------------------------
1. Install `Manufacturing` (mrp) and `PLM` (mrp_plm) modules
2. Create a product > New -- Name: "Test Product" > Save
3. Create BoM v1
- Go to Manufacturing > Products > Bills of Materials > New --Product: Test Product
- Add component: any
4. Create and apply ECO 1 on BoM v1
- Go to PLM > ECOs > New-- Product: Test Product | Apply on: Bill of Materials
- BoM: Test Product (v1) > Confirm > Apply Changes
- This creates BoM v2 (previous_bom_id = BoM v1)
5. Create and apply ECO 2 on BoM v2
- Same as step 4 but select BoM v2
- This creates BoM v3 (previous_bom_id = BoM v2)
6. Create a separate unrelated BoM for the same product
- Go to Manufacturing > Bills of Materials > New
- Product: Test Product | Component: "Component B" > Save
7. Create ECO 3 on the separate BoM
- Go to PLM > ECOs > New - Product: Test Product | Apply on: Bill of Materials
- BoM: select the separate BoM from step 6 > Confirm
Observed Bug:
-------------
- Open BoM v3 > ECO(s) stat button shows count = 2
- Click the button > opens 3 records (ECO 3 incorrectly included)
Explain:-
----------
The ECO stat button on the BoM form was showing a mismatched count vs
the actual records opened when clicking it. This happened because
[button_mrp_eco](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L56) was using all keys from [_get_previous_boms](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L67)() as the
domain, which includes BoMs from unrelated lineages of the same product
template, while [_compute_eco_data](https://github.com/odoo/enterprise/blob/55bfd499660d3eda0abfc9e8ed8c9a2befbd394b/mrp_plm/models/mrp_bom.py#L20) only counts ECOs belonging to the
current BoM's version lineage.
Fixed by filtering the domain to only include BoM IDs whose lineage set
contains the current BoM ID, making the opened records consistent with
the displayed count.
Before Fix
<img width="1901" height="875" alt="image" src="https://github.com/user-attachments/assets/3208aed5-ebd3-47a3-a457-a7d61b7743cb" />
```
In [24]: labo = self.env['mrp.bom'].browse(710)
In [25]: previous_boms_mapping = labo._get_previous_boms()
In [26]: Test = ['&', ('bom_id', 'in', list(previous_boms_mapping.keys())), ('type', '=', 'bom')]
In [27]: Test
Out[27]:
['&',
('bom_id',
'in',
[710,
1991,
2049,
1913,
1840,
1823,
1676,
1759,
1794,
1651,
1604,
1544,
1537,
1527,
1506,
1460,
1265,
1259,
1196,
1221,
1223,
1060,
1029,
960,
858,
850,
791,
739,
723,
698]),
('type', '=', 'bom')]
```
With My Fix
<img width="1824" height="947" alt="image" src="https://github.com/user-attachments/assets/0d68fdbc-7e42-4ce4-a326-2fb030ba1d06" />
```
In [15]: labo = self.env['mrp.bom'].browse(710)
In [16]: previous_boms_mapping = labo._get_previous_boms()
In [17]: previous_boms_mapping
Out[17]:
{710: {710},
1991: set(),
2049: set(),
1913: set(),
1840: set(),
1823: set(),
1676: set(),
1759: set(),
1794: set(),
1651: set(),
1604: set(),
1544: set(),
1537: set(),
1527: set(),
1506: set(),
1460: set(),
1265: set(),
1259: set(),
1196: set(),
1221: set(),
1223: set(),
1060: set(),
1029: set(),
960: set(),
858: set(),
850: set(),
791: set(),
739: set(),
723: set(),
698: {710}}
In [18]: relevant_bom_ids = [
...: bom_id
...: for bom_id, current_bom_set in previous_boms_mapping.items()
...: if labo.id in current_bom_set
...: ]
In [19]: relevant_bom_ids
Out[19]: [710, 698]
```
Task-6065020
Forward-Port-Of: odoo/enterprise#114039This update resolves an issue where users were experiencing errors when opening account records. The fix ensures that payment IDs returned in a key calculation are filtered based on user access rights, preventing unauthorized access and improving stability. This change was made to align with existing security practices.
Original PR description
the computed fields _compute_reconciled_payment_ids return payment ids with a sql request that by pass the access rule. This lead in an error while opening some account.move as for https://github.com/odoo/enterprise/pull/99410 invoice_ids in sale.order the result return by the sql query should be filtered according to the access right. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261595
A technical issue was causing a traceback in the Department Hierarchy view when departments had managers assigned. This fix addresses a problem with how the system handles date information, preventing the error and ensuring the view functions correctly. This improves the user experience for managing department structures.
Original PR description
## Issue When opening the *Hierarchy* view of Employees > Departments, if at least one department has a manager set, a traceback appears before the view. ## Steps to reproduce 1. Install *Employees*…
## Issue
When opening the *Hierarchy* view of Employees > Departments, if at least one department has a manager set, a traceback appears before the view.
## Steps to reproduce
1. Install *Employees* (`hr`)
2. In Employees > Departments, add a manager to a department
3. Open the *Hierarchy* view
4. **A traceback appears:**
```
Caused by: TypeError: Cannot read properties of undefined (reading 'toMillis')
at get uniqueId (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:21370:74)
at Many2OneAvatarEmployeeField.template (eval at compile (http://localhost:8192/web/assets/cbd2032/web.assets_web.min.js:1387:421), <anonymous>:25:122)
...
```
## Cause
The traceback is yielded from the `get uniqueId` getter from the `Many2OneAvatarEmployeeField` component:
https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/many2one_avatar_employee_field.js#L38-L40
where `write_date` is undefined. This getter was added by https://github.com/odoo/odoo/commit/3732ca85b03bea9eabfb05cc306ce0bf5bac88d4, which handled the case of undefined `write_date` for the related Kanban component:
https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/hr/static/src/views/fields/many2one_avatar_employee_field/kanban_many2one_avatar_employee_field.js#L49-L52
A similar solution is applied in this problematic getter.
opw-6128837
Forward-Port-Of: odoo/odoo#260069This update resolves an issue where the cursor would incorrectly appear after an image block after deleting content. The fix prevents the HTML editor from misinterpreting self-closing elements, ensuring the cursor remains before the image as intended. This improves the user experience when editing content with images.
Original PR description
After a deletion, if the selection would end up on an image and the image is considered as a block, the selection is set inside it. Upon collapse, this leads to having the selection after the image. This commit avoids this by preventing `normalizeEnterBlock` from taking self closing elements into account. Steps to reproduce: - Go to website - Drop a `s_text_image` snippet - Select the image - Press the left cursor key to put the cursor before the image - Type a letter - Press backspace - Type a letter => The second letter was put after the image task-5436148 Forward-Port-Of: odoo/odoo#263543
This update restores a key in Odoo's response messages to maintain compatibility with older versions. Removing this key simplified the system, but for continued support of Odoo 19.3, we've reintroduced it. This ensures seamless operation for existing integrations.
Original PR description
In odoo/odoo#243554, we removed the `owner` key in response messages to simplify (use only `session_id`). For backward compatibility, we need to keep the key. We'll be able to remove it completely when v19.0 will be deprecated.
This update ensures that when a restaurant order is split, the previously selected preset is automatically applied to the new order portion. Previously, a new 'Select a Preset' modal would appear unnecessarily. This change improves the user experience and consistency within the restaurant POS system.
Original PR description
In the restaurant pos when splitting an order, the 'Select a Preset' modal would show up even if a preset was already selected for the original order. This fix automatically copies the exiting preset on the split order as well Task-[6171972](https://www.odoo.com/odoo/project/1737/tasks/6171972) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update clarifies the display of archived users in the avatar card by hiding the 'offline' status. Previously, this status was misleading, as archived users are no longer active. This change improves user experience and aligns the display with the users' inactive state.
Original PR description
*: test_discuss_full Previously, archived users were displayed as 'offline' in the avatar card, which could be misleading since they are no longer active participants. This PR ensures that the status is hidden for archived users, avoiding confusion and aligning the behavior with their inactive state. task-4797343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where survey time limits were incorrectly displayed with 'h' (hours) instead of 'm' (minutes). The change ensures that survey time limits are shown in the correct unit, improving the user experience and accuracy of survey settings. This resolves a technical detail related to a recent update to the survey module.
Original PR description
In the `time_limit` field, `h` was displayed by default next to the limit because as recently here https://github.com/odoo/odoo/commit/4751bbed988d8ee5233d70c4852ecbd5a03b228a we introduced the unit option for the `float_time` widget and by default that unit will fallback to hour so that's why `h` was displayed there. This PR addresses the issue and passed the minute as a unit as we were using the minutes for the survey time limit. Task-6132365 Forward-Port-Of: odoo/odoo#260557
This update fixes a calculation error in employee timesheets, ensuring accurate tracking of working hours across contract versions. The change updates how the system determines the valid working schedule for each employee, resolving discrepancies in remaining hours displayed.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install Timesheets Module with demo data 2. Create a new Employee with: * Payroll Page > Contract > Start from 1st March * Payroll Page >…
Steps to reproduce:
------------------------------------
1. Install Timesheets Module with demo data
2. Create a new Employee with:
* Payroll Page > Contract > Start from 1st March
* Payroll Page > Working hours set to 'Standard 40 hours/week'
3. Go to Timesheets > All Timesheets
4. Add Timesheet for any task as follows:
* Select a date in a past week (e.g., 14th April)
* Hours: 8 hours
* Select the newly created employee
5. Go to Timesheets > All Timesheets:
* Filter by the new employee
* Navigate to the same past week
* Observe the remaining hours for the employee (e.g, -32:00)
6. Open the newly created employee form:
* Click on '+' to create a new contract version
* Set the version date before the timesheet date (e.g., 12th April)
* Change Working Hours to Standard 38 hours/week.
7. Repeat Step 5
Observation:
------------------------------------
The Remaining Hours shows -32:00, meaning the system still uses the 40 hours/week schedule instead of the updated one. The expected value should be -30:00 based on the 38 hours/week schedule.
Issue:
------------------------------------
The method `_get_contracts_valid_periods` determines which working calendar applies for which time period. It uses `contract.contract_date_start` and `contract.contract_date_end` to build calendar validity intervals, but these are the contract employment dates (shared across all versions of the same contract), NOT the version-specific effective dates.
Both versions share the same `contract_date_start`, so both claim the entire period as valid. The 40h calendar produces larger work intervals that win when combined via Intervals union, so the old 40h schedule is used instead of the current 38h one.
Solution:
------------------------------------
Replace `contract.contract_date_start` / `contract.contract_date_end` with `contract.date_start` / `contract.date_end`
These dates represent each version's effective validity period, computed from `date_version` and bounded by the next version's start date. Using these ensures each calendar is only valid during the period its version was actually in effect correctly splitting the working hours at version boundaries.
opw-6142137
Forward-Port-Of: odoo/odoo#264114
Forward-Port-Of: odoo/odoo#260614This update resolves an issue where the Project/Task dropdown menu in the Timesheets Assistant was hidden behind the sticky 'Total' footer. The fix adjusts the menu's layering to ensure it's always visible when the edit form is open, improving user experience.
Original PR description
**Steps to reproduce:** - Open Timesheets > Assistant menu. - Click a row near the bottom of the "My Timesheets" section to open the edit form. - Open the Project or Task dropdown menu. **Issue:** The dropdown menu is hidden underneath the sticky "Total" footer. This happens because both the edit form and the footer share the same stacking context priority. **Fix:** Update .o_activitywatch_sync_timesheet_edition_form to manage its own stacking context. It now defaults to z-index: 1 to ensure standard scrolling behavior, but jumps to z-index: 3 on hover or focus-within. This ensures that when a user interacts with the form, its dropdowns correctly float above the sticky footer. task-6105369 Forward-Port-Of: odoo/enterprise#113377