Daily updates from Odoo
Wednesday, May 13, 2026
48 changes · saas-19.2
Resolved issues and error corrections
This update resolves an issue where the DIAN (Colombia) information wasn't appearing on invoice PDFs in version 19.2. The fix simply reordered the layout of the PDF to ensure the required data was correctly rendered. This ensures accurate reporting for Colombian businesses using the Enterprise module.
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
This update resolves an issue where child partners in the Spanish localization were incorrectly flagged as companies. The fix ensures that child partners retain their correct status based on their individual commercial entity information, preventing misidentification as companies. This ensures accurate reporting and compliance within the Spanish tax system.
Original PR description
Step to reproduce: - install contacts and l10n_es and switch to ES company - create a partner, with valid vat ex. A12345674 - create a child partner from the form view Observation: - with debug mode,…
Step to reproduce: - install contacts and l10n_es and switch to ES company - create a partner, with valid vat ex. A12345674 - create a child partner from the form view Observation: - with debug mode, check that both records have `is_company` = True - child partner should not be considered as a company Cause: - After commit [1] `is_company` is a computed field, which can be overridden by other localization - in commit [2] for spain localizaton, `is_company` is true for all partner with valid CIF vat. - when we create a child partner, its value is synced with its parent at `_fields_sync` method with chain of methods finally leading to `vat` at `_synced_commercial_fields` - hence we propagate such commercial fields from parent to child - as now child also have same CIF vat, its is_comany = True [1] https://github.com/odoo/odoo/commit/f2965048f60fe6c815b3e50fa714c97a93dfb5d3 [2] https://github.com/odoo/odoo/commit/2d8013ccc858898fed52deac6eb11a8b5bb57351 Fix: - we now consider a partner as a company only when they own their commercial entity opw-6063786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users couldn't delete attachments from vendor bills after confirmation. The fix restricts a recent feature change to only 'comment' message types, addressing a technical limitation that prevented attachment deletion for notifications. This ensures users can properly manage attachments within the system.
Original PR description
Step to reproduce: - install purchase - create a RFQ, confirm it. a PO will be created - click on "upload bill" , upload a documnet, you will be sent for vendor bill - confirm the bill - try to…
Step to reproduce: - install purchase - create a RFQ, confirm it. a PO will be created - click on "upload bill" , upload a documnet, you will be sent for vendor bill - confirm the bill - try to delete the attachment from "paper-clip" icon Observation: - Error message: ```Only messages type comment can have their content updated ``` Cause: - commit [1] introduced a feature which adds "edited" tag in message body if attachment is removed, but that is only applicable for message with type == 'comment' https://github.com/odoo/odoo/blob/c3172d65db44c41f5619aef20532c3846494ea0e/addons/mail/models/mail_thread.py#L521-L531 - As this attachment is attached to record at time of creation, its type is "notification", and hence we are not able to delete this [1] https://github.com/odoo/odoo/commit/7c8971f2e2870fee19f55f971f3b8c8e553959c3 Fix: - we now limit the feature introduced by commit [1] only for message type "comment" opw-6055206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where the tour worksheet wasn't consistently saving due to a timing issue. The fix adds a brief delay to ensure the worksheet is fully loaded before saving, preventing data loss. This improves the reliability of the tour process.
Original PR description
Currently, the test tour loads too quickly, so the worksheet is not saved properly. The issue happens because the worksheet is not yet visible on the portal view side. Therefore, i added an extra step to wait for the HTML field to load, giving enough time for the worksheet to be fully loaded. runbot error-242479 Forward-Port-Of: odoo/enterprise#116918
This update simplifies a confusing error message related to multiple GST registrations within an organization. Previously, users received a technical error that led to support requests. Now, the system clearly prompts users to verify the GST username matches the associated GST number, reducing support burden and improving user experience.
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 account return checks, leading to unnecessary database entries. The fix ensures that only one check is created, improving system performance and data integrity. This was caused by a race condition in how the system processed multiple requests.
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 enhances the logging of technical errors related to Saudi VAT (ZATCA) compliance within the odoo system. Previously, these errors were hidden from users to maintain a clean interface, but this made troubleshooting difficult. Now, server logs will record these errors with a specific prefix, allowing our team to quickly identify and resolve issues.
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 an issue where newly created stock batches were initially named 'New' instead of following the standard 'BATCH/<TYPE>/000NN' naming convention. The fix ensures that all new batches are correctly named, improving data consistency and reporting accuracy within the Delivery Orders feature. This resolves a minor operational issue.
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 website builder's tab design. Specifically, it ensures that translation states are correctly displayed on tab descriptions, resolving a previously identified issue. The change improves the overall user experience and consistency of the 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 resolves an issue where invoice subsections remained visible even after the 'Hide Composition' feature was enabled. The fix adjusted the underlying invoice report settings to ensure consistent display across 'Invoices' and 'Quotations', preventing unwanted subtotals and tax information. This improves invoice clarity and accuracy for users.
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 fixes a display issue where the number of ECOs listed on a Bill of Materials (BoM) was incorrect. The fix ensures that only ECOs directly associated with the current BoM version are counted, resolving a misleading display. This improves the accuracy of BoM information for users.
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 corrects a previous oversight by adding the 'l10n_pl_bank_verification' module to the Weblate translation file. This ensures that all user-facing text within the Odoo system is accurately translated for Polish bank verification processes, improving localization and user experience.
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 bug that prevented the system from correctly identifying project documents when the designated folder was empty. The fix ensures the system functions reliably regardless of whether a folder is associated with a project, improving document retrieval accuracy.
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 fixes a previous issue where employee export reports were unavailable. It reintroduces the ability to generate these reports by updating the user interface and ensuring compatibility across installed modules. This ensures users can continue to generate necessary reports.
Original PR description
During the work entry apocalypse, the gantt view that was used to do the exports for Partena, Acerta etc was removed. With it, we lost the ability to trigger those reports, which we want to…
During the work entry apocalypse, the gantt view that was used to do the exports for Partena, Acerta etc was removed. With it, we lost the ability to trigger those reports, which we want to reintroduce here. To do so we create a dropdown element in the cog menu registry, which starts out empty but is populated with the various reports based on which modules are isntalled, by inheriting and adding the relative dropdown items. At the same time, currently the cogmenu of the employee when hr_presence is installed is being overridden to use HrPresenceCogMenu which adds a Dropdown of its own that includes actions related to employee presence. Therefore, we need to refactor this dropdown becuase depending on the module installation order the HrPresenceCogMenu might override the addition of the ExportCogMenu and overriding the CogMenu is not the correct way to add elements to it in general. I have been able to move the logic of the PresenceCogMenu to the registry but the actions don't have the correct context and give errors because the records are not passed. Also there are some problems with the ActionMenu (the one that shows up if you select employees from the lsit view. Task: 5985900
This update reintroduces the ability to export HR reports that were previously unavailable. The changes address an issue where export functionality was removed and now utilize a more robust method for adding export options based on installed modules. This ensures consistent reporting across different HR modules.
Original PR description
During the work entry apocalypse, the gantt view that was used to do the exports for Partena, Acerta etc was removed. With it, we lost the ability to trigger those reports, which we want to…
During the work entry apocalypse, the gantt view that was used to do the exports for Partena, Acerta etc was removed. With it, we lost the ability to trigger those reports, which we want to reintroduce here. To do so we create a dropdown element in the cog menu registry, which starts out empty but is populated with the various reports based on which modules are isntalled, by inheriting and adding the relative dropdown items. At the same time, currently the cogmenu of the employee when hr_presence is installed is being overridden to use HrPresenceCogMenu which adds a Dropdown of its own that includes actions related to employee presence. Therefore, we need to refactor this dropdown becuase depending on the module installation order the HrPresenceCogMenu might override the addition of the ExportCogMenu and overriding the CogMenu is not the correct way to add elements to it in general. I have been able to move the logic of the PresenceCogMenu to the registry but the actions don't have the correct context and give errors because the records are not passed. Also there are some problems with the ActionMenu (the one that shows up if you select employees from the lsit view. Task: 5985900
This update corrects a display issue in the survey time limit field, previously showing 'h' by default. The change ensures the time limit is consistently shown in minutes, aligning with how survey durations are defined, improving the user experience.
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
This update fixes an issue where scanning a packaging barcode (like '6' for a 6-pack) intermittently added quantities to the wrong line in the stock picking process. The fix ensures the barcode scan correctly identifies and updates the intended packaging unit, resolving quantity discrepancies.
Original PR description
Issue ----- When there are 2 lines for a single product and different packaging uoms, scanning a packaging barcode alternates between lines. Steps to reproduce ----- - Enable packagings - Create a…
Issue ----- When there are 2 lines for a single product and different packaging uoms, scanning a packaging barcode alternates between lines. Steps to reproduce ----- - Enable packagings - Create a product AAA - barcode 1 - Create a packaging 6-Pack - 6 units - barcode for AAA set to 6 - Create a PO - one line for 30 units of AAA - one line for 5 6-Pack of AAA - Confirm PO and open picking in barcode - Scan "6" multiple times > Quantity increases on both lines, alternating for each scan Cause ----- Both lines can be found as matching lines when doing https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1426 The reason it alternates between the lines is because we set the currently selected line first in the array - and since both lines match, the `foundLine` returned ends up being the non-selected line. https://github.com/odoo/enterprise/blob/d279632db25713dd639a51385cad197dfdbd2bdc/stock_barcode/static/src/models/barcode_model.js#L1823-L1832 We can avoid this y refining the `break` condition of the loop to also match the packaging uom. ----- Ticket: opw-6034572 Forward-Port-Of: odoo/enterprise#112578
This update fixes an issue where the Table of Contents in the website's navigation bar wasn't displaying the correct translated text after styling headings. The fix ensures that translated headings are consistently shown in the navbar, regardless of inline styling, improving the user experience across multiple languages.
Original PR description
Steps to reproduce: =================== 1. Enable a second language on the website 2. Add a Table of Content snippet to a page 3. Apply bold (or any inline style) to one of the headings, save 4.…
Steps to reproduce: =================== 1. Enable a second language on the website 2. Add a Table of Content snippet to a page 3. Apply bold (or any inline style) to one of the headings, save 4. Switch to the second language in translation mode 5. Translate the styled heading and save => The TOC navbar entry keeps showing the source text on reload. => Expected: navbar shows the translated heading text, unstyled. Cause: ====== When a TOC heading carries inline markup, the server emits the heading and the navbar entry as two independent translation terms with different `data-oe-translation-source-sha` values, even though their textContent matches. A translation written under the heading's sha therefore never reaches the navbar's slot. `handleToC` was meant to bridge that by aliasing the navbar span's sha to the heading's during translation-mode setup, but two issues prevented it from working in saas-18.4+: - The TOC navbar lives under `.o_not_editable`, so its translation spans were excluded from `findOEditable` and `handleToC` never ran on them. The class `o_translation_without_style` was never added, and the sha was never aliased. Solution: ========= - `prepareTranslation` iterates TOC navbar translation spans explicitly, so `handleToC` reaches them despite `findOEditable` skipping `.o_not_editable`. - `handleToC` always tags the navbar span with `o_translation_without_style` when a matching heading exists. - An `after_replication_handlers` hook flags every replicated unstyled-translation target as `.o_dirty`, so the replicated translation is included in the save. opw-5950228 Forward-Port-Of: odoo/odoo#263547 Forward-Port-Of: odoo/odoo#260378
This update resolves an issue preventing accurate translation exports from the Web Studio interactive editor. A specific code formatting problem (using backslashes and newlines) was causing incorrect code extraction. The fix removes this problematic formatting, ensuring translations can now be properly exported and applied.
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 a recurring issue where Odoo would retry eTIMS transactions, leading to errors (specifically 924) because it was using the same invoice number repeatedly. The fix ensures Odoo intelligently recovers existing invoice data when possible, improving the reliability of eTIMS processing for Kenyan VAT invoices. This prevents delays and ensures accurate data transmission.
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 grid that was appearing incorrectly when Odoo is set to display content in Right-to-Left (RTL) languages. The changes adjust the layout elements to ensure a proper display for users in RTL environments, improving the overall user experience. This ensures all customers can easily browse and purchase products regardless of their language settings.
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 problem that could cause the restaurant table management system to freeze due to an infinite loop when merging tables. The fix ensures that table relationships are correctly handled, preventing this error and improving system stability. This change focuses on internal system improvements.
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 campaign scheduling works reliably. It also avoids potential user confusion by limiting modification options for test campaigns.
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 potential problem where multiple sign automation actions could silently override roles. The change adds a check within the automation process to ensure no conflicting roles are used, preventing incorrect permissions and maintaining data integrity. A new test has been implemented to verify this fix.
Original PR description
Before this commit, creating multiple server actions for the Sign app in a single transaction (e.g., when saving an Automation Rule with multiple nested actions) bypassed the `_check_sign_template_conflicts` constraint. Because the constraint only queried the database for existing links, it failed to detect conflicts within the in-memory batch, allowing the save to succeed and causing silent role overrides. This commit introduces an intra-batch check to the constraint. By tracking requested roles in memory during the loop, the constraint now correctly raises a ValidationError if multiple actions in the same transaction attempt to automate the exact same template roles. A test has been added to ensure batch creations are properly validated. Task: 6128909 Forward-Port-Of: odoo/enterprise#115062
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 and overall appearance.
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 file boxes, even after deleting their content, wouldn't be fully removed from the To-Do creation interface. The fix allows deletion of non-editable file boxes when they are fully selected and their parent is editable, improving the user experience and ensuring content is accurately removed.
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
A recent test was failing due to inconsistencies in how account reports were loaded during automated testing. This update ensures the test accurately reflects the system's behavior by generating the necessary account reports within the test itself. This resolves a runbot error and maintains consistent test results.
Original PR description
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report,…
Previously, embedded account reports always loaded the global account report. A fix introduced in version 19.0 changed this behavior so that the system now loads the most appropriate audit report, specifically, the account report corresponding to the audit report's company (see: odoo/enterprise#101377). In version 19.1, a test was added to validate account report options. However, this test assumed that embedded account reports would always load the global account report (i.e., `account_reports.balance_sheet`). When tests run on runbot, demo data is not loaded. In that context, no report variants exist in the database, so the system falls back to the global account report, causing the test to pass. In environments where demo data is loaded, a report variant does exist, and the system correctly selects it instead of the global report. As a result, the test assertions are no longer valid and fail, leading to runbot errors. To address the issue, we will generate the account reports within the `setup` method of the test. This ensures that the assertions remain consistent, regardless of whether demo data is present. runbot-error-id~242235 Forward-Port-Of: odoo/enterprise#112486
A technical error in the Odoo system's expense reporting feature has been resolved. The issue occurred when searching for customers within expense records, specifically related to the 'costumer to reinvoice' field. This fix ensures the system functions correctly and prevents errors during searches.
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 was incorrectly displayed in the Gantt view when no Sale Order Lines were present. The fix ensures the button only appears when there are actual sales opportunities to plan, streamlining the user experience and preventing unnecessary form openings. This improves efficiency and clarity for users.
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 resolves an issue where the cursor position was incorrectly placed after images after a deletion. Specifically, when deleting an image block, the cursor would end up positioned within the image itself. This change ensures the cursor remains before the image after a deletion, improving user workflow and data entry accuracy.
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
A bug in the sale stock test was causing it to pass incorrectly. The test was being executed with the wrong user, leading to inaccurate access rights checks. This fix ensures the test uses the correct user, guaranteeing reliable test results and preventing potential issues in the live system.
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 that all sales order deliveries, including inter-company transactions, are accessible to 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 a previous issue where the closing popup for bank payments didn't accurately display the number of payments made. Now, the popup correctly shows the total count of payments associated with a bank method, reducing user confusion and improving the accuracy of transaction information. This resolves a minor usability concern.
Original PR description
Before this commit, in the closing popup if a bank payment method had more than one payment, it would not show the count of payments, which could lead to confusion for the user. opw-6198656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent test in the Odoo MRP module failed because the user account lacked the necessary permissions to view lot tracking information. This change explicitly grants the required group (`stock.group_production_lot`) within the test environment, ensuring the test now passes consistently. This resolves a minor issue impacting test stability.
Original PR description
The test uses the stock move line detailed operations form and expects the `lot_id` field to be present in the view. Without demo data, the current user may not belong to the `stock.group_production_lot` group, causing the field to be absent from the rendered form view and the test to fail. Causing: `AssertionError: 'lot_id' was not found in the view` in line: https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/mrp/tests/test_consume_component.py#L477 Grant the lot tracking group explicitly in the test setup. runbot-243588 Forward-Port-Of: odoo/odoo#263759
This update corrects a technical issue within the HR module that could have caused incorrect version calculations related to employee contracts. The fix ensures accurate tracking of contract periods, preventing potential reporting discrepancies. This improves the reliability of HR data.
This update resolves several errors that occurred when the system processed NOTI files for Belgian payroll. The fix ensures accurate calculations and reporting related to ONSS declarations, improving the reliability of payroll data. This prevents potential discrepancies and ensures compliance with Belgian tax regulations.
Original PR description
Forward-Port-Of: odoo/enterprise#116871
This 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 to sensitive financial data. This improves data security and stability.
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
This update fixes a confusion point in the split bill screen for point-of-sale, allowing users to clearly see the different price variations for product variants. Previously, it was difficult to identify which price corresponded to each variant option when splitting an order. This enhancement ensures accurate order processing and reduces potential errors.
Original PR description
Currently, when using the split bill screen you cannot differentiate variants. That's problematic when each variant is assigned to an extra price and you have to determine which price corresponds to each variant. Steps to reproduce: ------------------- * Go to the product and search for the Bacon Burger * Assign a different extra price for each variant option * Open Restaurant * Order the bacon burger multiple times, one for each possible variant * Split the order > Observation: On the split screen you see multiple lines of bacon burger each with a different price but if you don't know all the extra price possible it's impossible to know which orderline corresponds to each variant. Why the fix: ------------ Attributes are only shown in display mode, we also show them in split mode. opw-6041713 Forward-Port-Of: odoo/odoo#262489 Forward-Port-Of: odoo/odoo#257265
This update fixes a reporting issue where employees with flexible schedules and overlapping shifts were incorrectly shown with double the planned hours. The fix ensures that the attendance analysis accurately reflects the duration of planned shifts, regardless of overlap, preventing inflated reporting figures.
Original PR description
__ ## Short functional explanation of the error When for an employee with a Flexible schedule, we set a shift overlapping on two days. The attendance report displays twice the worked hours. ##…
__ ## Short functional explanation of the error When for an employee with a Flexible schedule, we set a shift overlapping on two days. The attendance report displays twice the worked hours. ## Reproduction Steps 1. Create an employee with a flexible schedule and with Work Entry Source set at Planning. 2. Go to Planning. Create a Planning Slot for this employee from 9 pm to 5 am, then Send and Publish it. 3. Click on the Reporting tab > Planning / Attendance Analysis. ### Expected behavior The total for this Month for this employee under the Planned Time field should be equal to 8 hours, which is the duration of the planning slot. ### Unexpected behavior The total for this Month for this employee under the Planned Time field is equal to 16 hours. ## Origin of the issue This report is a view, for which the SQL is defined starting this line: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L27 the issue stems from here: https://github.com/odoo/enterprise/blob/7362f1c5be7f496bdab660ed8fad37a6dd283616/planning_attendance/report/planning_attendance_analysis_report.py#L56 where we don't select distinct the planning entries based on their ID. As our shift overlaps 2 days, there will be only one entry for this shift in the `planning_slot`, but because of that, it will be duplicated. __ opw-6146052 Forward-Port-Of: odoo/enterprise#115447
This update resolves several issues related to timesheet timers, specifically preventing incorrect timer displays and simultaneous timer activation. The fix reverts changes that were causing the timer to reset incorrectly or run in the background, ensuring accurate time tracking within projects.
Original PR description
## Issues When starting a timer from a task within a project, the timer appears in two locations: the page header, and the task's *Timesheets* tab. The latter does not behave as expected: when…
## Issues When starting a timer from a task within a project, the timer appears in two locations: the page header, and the task's *Timesheets* tab. The latter does not behave as expected: when opening the *Timesheets* tab, the timer resets to 00:00, and if the timer was started more than a minute earlier, it begins counting down (00:00, then -00:59, and so on). (**I1**) A second issue (**I2**), introduced at the same time, is that two timers can run simultaneously if the database is reloaded while a timer is active. A third issue (**I3**) happens after starting and stopping a timer from the Project app: the timer seems to still be running in the Timesheet app. ## Steps to reproduce 1. Install *Timesheets* (`timesheet_grid`) 2. Create a Project P and a Task T 3. Start the timer for Task T, wait a few seconds, then open the *Timesheets* tab 4. **The timer from the _Timesheets_ tab does not match the one on top of the page** 5. Wait for the timer in the header to reach 00:01:00, then open the *Timesheets* tab again 6. **The timer is going backward** For the second issue (**I2**), after executing the steps above: 7. Do not stop the timer, but stop the database and start it again 8. Create a new Project P2 and a Task T2 9. Start the timer for Task T2 10. **The timer in the header blinks between the timer from T1 and the newly started timer for T2**  For the third issue (**I3**): 1. In the project app, (create a project and a task and) start then stop a timer. Log the time 2. Open the timesheet app 3. **A timer is running** ## Cause The issues are introduced by the following commit: https://github.com/odoo/enterprise/commit/f4c7115fdf. The commit aimed to resolve an issue in which timers for sample data would start automatically, and the *Stop* button would throw an error. The issue was addressed by updating the condition that defines the `timerRunning` variable, which controls whether the *Stop* button in the Timesheets app is displayed. https://github.com/odoo/enterprise/blob/ac186aa71cd7e1b80b307ea12c7eaca246afd649/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L57-L64 Issue **I1** is a side effect of this change in the Project app, where the `timerRunning` variable is evaluated to `true`, causing the timer to be displayed when it should not. The multiple timers running simultaneously (**I2**) stems from the `timerRunning` variable being initiated to false by default in the props. https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L47-L50 The *Stop* button appearing after logging a task (**I3**) stems from the condition of the patch using `is_timer_running` over `timer_start`. https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/timesheet_grid/static/src/hooks/sample_server_patch.js#L9-L15 ## Fix This commit reverts the problematic segments from the previous commit. opw-5870756 opw-5879176 opw-5961764 Forward-Port-Of: odoo/enterprise#107014
This update fixes a naming issue with quarterly returns. Previously, returns were labeled with 'Q1', 'Q2', etc., regardless of the company's fiscal year. Now, returns are named with the 'From Month Year - To Month Year' format, providing clearer and more accurate reporting for businesses with non-calendar fiscal years.
Original PR description
Currently, if the company fiscal year doesnot align with calender year, i.e Fiscal year end is not december and any month in between like India (March 31), while creating quarterly returns, the return name has Q1 for Jan - Mar, Q2 for Apr - Jun, and so on, which is not aligned with the fiscal year quarters. This commit fixes that issue by naming it like "From Month Year - To Month Year" for quarterly returns. task-6124692
This update resolves an issue where reports would fail when the fiscal year's end date was set to February 29th. The fix ensures that the system correctly handles leap year fiscal years, consistently calculating the start date as March 1st regardless of the end date.
Original PR description
**Steps to Reproduce:** 1. Install the Accounting module. 2. Go to Settings and set the fiscal year's last day to 29 February. 3. Accounting > Reporting > open any report. **Error:** `ValueError - day is out of range for month` **Cause:** At [1], a fixed year (2025) is used to compute the fiscal year end. However, 2025 is not a leap year, so creating a date with February 29 raises an error. **Fix:** Ensure that when the fiscal year’s last day is Feb 29, a leap year (2024) is used for the computation. For all other dates, the year remains unchanged (2025). As a result; - If the last day is February **28** (non-leap year) -> `fy_start` becomes **March 1** - If the last day is February **29** (leap year) -> `fy_start` also becomes **March 1** [1] - https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/account_reports/models/account_report.py#L820 sentry-7438598965
This update ensures that PDF attachments sent through the portal chatter are now correctly displayed as previews. Previously, the system was missing key data needed to generate these previews. This fix improves the user experience by allowing users to quickly view attached documents within the portal.
Original PR description
Before this commit, previews of pdf attachments (introduced in [1]) would not be displayed in portal chatters. This happens due to `_portal_message_format` not returning the data necessary to display pdf previews (i.e. `has_thumbnail` and `thumbnail_access_token`). This commit fixes the issue by returning said data. [1] https://github.com/odoo/odoo/pull/221006 task-6204747 Forward-Port-Of: odoo/odoo#263481
This update resolves a technical issue that could cause a traceback when a tour had no defined steps. The fix simply prevents the tour from starting if there are no actions to perform, ensuring a smoother user experience. The previous workaround has been removed, and the underlying cause (related to a database option) has also been addressed.
Original PR description
This commit is a backport of the PR odoo/262537 which prevents a traceback when a tour has no steps and thus no actions. We just do not start the tour if it has no steps. The reason why it was at first targeting saas-19.3 is because the `option.fromDB` was removed in this version. And on previous versions, it was really rare for this option to be true which prevented the traceback from being seen by users. On top of that, I revert the onHold property which was added to solve the same issue. But we keep the best solution which is to not start the tour if it has no steps. --- Backport of : https://github.com/odoo/odoo/pull/262537 Remove option.fromDB: https://github.com/odoo/odoo/pull/253523/changes#diff-992f9ec16e1b54e31fb4bbb37d3c0c099738282ad66ef33ea2239b15010351f7L166 Revert onHold: https://github.com/odoo/odoo/pull/255094 Forward-Port-Of: odoo/odoo#264156 Forward-Port-Of: odoo/odoo#263781
This update prevents a critical error that occurred when creating quality checks from quality points. The issue arose when a product wasn't specified, leading to a system error. This fix ensures quality checks can be created successfully under all circumstances, improving data integrity and preventing disruptions to the quality control process.
Original PR description
When creating a quality check from a quality point, a traceback occurs if no product is set. Steps to reproduce the error: - Install ``quality_control`` module with demo data - Go to Quality > Quality Control > Control Points > Create a new Control point > Set Control per: Quantity, Partial Test: 99 > Save - Click on Quality Checks smart button > Click on New Traceback: ```py ValueError: Expected singleton: uom.uom() ``` https://github.com/odoo/enterprise/blob/4fa1c0c13308bd8de06646543391f8cbcf28d05e/quality_control/models/quality.py#L369 During creation of a quality check, ``product_id`` is not set. The compute method ``_compute_qty_to_test`` accesses ``product_id.uom_id``, which leads to the above traceback. sentry-7440188763
This update fixes a calculation error in employee timesheets, ensuring accurate tracking of working hours across contract versions. The fix updates how the system determines the valid working schedule for each employee, resolving a discrepancy where hours were incorrectly calculated.
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 a visual bug where the Project/Task dropdown in the Timesheets Assistant was hidden behind the sticky 'Total' footer. The fix adjusts the layout to ensure the dropdown is 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