Daily updates from Odoo
Wednesday, February 25, 2026
223 changes
5 changes
Resolved issues and error corrections
This update resolves an issue affecting the Gantt view of work orders, specifically related to planning and display. The changes include a revised calendar structure and the ability to exclude 'blocked by' workorders, improving workflow clarity and accuracy. This ensures a more reliable and user-friendly experience for managing production schedules.
Original PR description
- Use the old 'workcenter' gantt view rather than the 'production' (and remove it) - Create a new Work Center calendar - Add variant name in workorder display name - Add the falsy label to employee_assigned_ids (for Gantt view mainly) - Restore the possibility of not planning the 'blocked by' workorders - Reload after Plan in Gantt view task: 5946267
This update resolves an issue impacting the Gantt view used to manage work orders. The changes enhance the visual representation of work orders and improve the functionality of the Gantt chart, specifically regarding planning and scheduling. It corrects a display issue and ensures accurate planning capabilities.
Original PR description
- Use the old 'workcenter' gantt view rather than the 'production' (and remove it) - Create a new Work Center calendar - Add variant name in workorder display name - Add the falsy label to employee_assigned_ids (for Gantt view mainly) - Restore the possibility of not planning the 'blocked by' workorders - Reload after Plan in Gantt view task: 5946267
This update fixes an issue where the 'Call Settings' header in chat windows was visually unclear due to a missing background color. The fix ensures the header remains properly positioned and readable, preventing text overlap when scrolling. This improves the user experience for chat interactions.
Original PR description
Before this commit, when opening the "Call Settings" in a chat window, the header of the action panel was missing a background color. Because of this, when scrolling down, the Action panel title was floating above the content and the text was overlapping, making it hard to read. This comes from `.bg-inherit` that requires the parented chain to rigorously have `.bg-inherit` too until reaching an actual bg color. In this case, one parent container lacked it, which is what this commit fixes. Task-5867464 (point 84) Before / After <img width="382" height="465" alt="Screenshot 2026-02-24 at 16 06 32" src="https://github.com/user-attachments/assets/f5c4a309-c60a-4e9b-bef0-06ee7ba731b8" /> <img width="386" height="468" alt="Screenshot 2026-02-24 at 16 06 18" src="https://github.com/user-attachments/assets/fea35f8f-2a76-4c40-b51e-28dbfce3a281" /> Forward-Port-Of: odoo/odoo#250481 Forward-Port-Of: odoo/odoo#250398
This update fixes an issue where selling kit products through Point of Sale (POS) would incorrectly calculate stock valuation lines. The fix ensures that the UoM of kit components is properly considered when determining the cost of goods sold and stock levels. This ensures accurate inventory tracking and financial reporting for kit sales.
Original PR description
When selling a kit product in POS, if the component of the kit use a different UoM than the UoM defined on the product, the stock valuation lines are wrong. Steps to reproduce: ------------------- * Create a storable product A with a UoM "Dozen" and a cost price of 10€ * Create a kit product B with a BoM of 1 unit of product A * Sell 1 unit of product B in POS > Observation: The valuation lines have the wrong value Why the fix: ------------ The product qty was not considering the UoM when computing the expense and stock valuation lines. opw-5471923 Forward-Port-Of: odoo/odoo#249583 Forward-Port-Of: odoo/odoo#248694
This update ensures that freight charges for international UPS deliveries are accurately reflected on the commercial invoices used for customs clearance. Previously, invoices were set to $0, but the fix now correctly includes freight charges based on the UPS API parameters. This improves accuracy and compliance for international shipments.
Original PR description
Issue ----- For international deliveries, the commercial invoice used for customs does not include the freight charges (it is set to 0). Steps to reproduce ----- - Create an international UPS sale - Confirm the delivery - Open the "UPSCommercialInvoice.pdf" file > In the price breakdown, freight is set to 0.0 Cause ----- It has to be specified in the `ship` request as `ShipmentServiceOptions.InternationalForms.FreightCharges.MonetaryValue` (source https://docs.rocketshipit.com/rs/docs/ups-api-parameters.html#shipment) Expected result ----- <img width="1912" height="963" alt="image" src="https://github.com/user-attachments/assets/170e49f7-6575-4524-b186-3829f4c20430" /> ----- Ticket: opw-5135494 Forward-Port-Of: odoo/enterprise#108465 Forward-Port-Of: odoo/enterprise#105505
1 change
Resolved issues and error corrections
This update resolves an issue preventing portal users and internal users from uploading documents to newly created requests. The fix addresses a technical error caused by sending incorrect data to the document upload controller. Now, users can successfully upload documents, improving the functionality of the Documents module.
Original PR description
Portal users and internal users cannot upload a document in a requested document Steps to reproduce: 1. Install Documents 2. Go to Documents and create a new request for user Joel Willis 3. Connect as portal user and go to Documents 4. Try to upload the requested document 5. An error occurs The same problem occurs for user Marc Demo Problem: Sending both an access_token and a user_folder_id to the controller raises an error 400 https://github.com/odoo/enterprise/blob/519862bf9b708d756478d4d81787f8a1999bc574/documents/controllers/documents.py#L608-L609 Solution: Do not send a user_folder_id when we have an access_token opw-5439104 Forward-Port-Of: odoo/enterprise#106583
7 changes
Resolved issues and error corrections
This update addresses a long-overdue refresh of tax codes within the Avatax module, ensuring continued accuracy for sales and accounting calculations. The change is a routine maintenance fix to maintain compatibility and avoid potential issues with tax regulations. A future enhancement will automate this process for users.
Original PR description
It's been 4 years since the last update [1]. No codes were removed. At some point it would be nice to add this to the avatax_sync_company_params() method so it can be initiated by the user. But we need to update this file regardless, and the mechanism would need to be smart enough to not cause duplicates when e.g. the user has synced it themselves, we then update the csv and they then update the module. [1] https://github.com/odoo/enterprise/pull/30220 opw-5928245 Forward-Port-Of: odoo/enterprise#108209
This update fixes an issue where warehouse names with only numbers (e.g., '01') were displayed incorrectly in the barcode app. The fix removes a browser setting that caused numerical warehouse codes to be reversed, ensuring accurate and consistent display of warehouse names regardless of their format.
Original PR description
### Steps to detect the bug: - Download stock apps - Enable "storage locations" settings under warehouse index - Change name of warehouse with a name composed only of numbers (ex. 01) - Create a…
### Steps to detect the bug:
- Download stock apps
- Enable "storage locations" settings under warehouse index
- Change name of warehouse with a name composed only of numbers (ex. 01)
- Create a product (with barcode number)
- Insert a number of products available with smart button "on hand"
- Create a new delivery for that product
- Go to barcode app and search for the delivery you just created
- Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.
### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
opw-5730199
Forward-Port-Of: odoo/enterprise#107920This update removes an unnecessary wrapper div from article content, streamlining the HTML structure. Previously, the system added a `div` to ensure proper parsing of article bodies, but this caused increased HTML depth. This change improves efficiency and maintains consistent article formatting.
Original PR description
Prior to this commit, `_get_transformed_body_from` wrapped the source body in a `div` because `lxml.html.fragment_fromstring` is used with a `create_parent=True` argument. That argument is required because otherwise, the function throws an error if there are multiple root nodes in the parsed string, which is frequent in an article body. The final returned string still contained that additional `div` ancestor. This does not break an article per se, but repeated usage would increase the html structure depth by 1 every time, and that additional `div` was not part of the function desired transformations. task-5960616 Forward-Port-Of: odoo/enterprise#108310
This update resolves a validation error occurring during tax calculations for Brazilian invoices using the Avatax service. The fix clears incorrect tax data from the invoice before sending it to Avatax, preventing a mismatch between totals and ensuring invoices are processed correctly. This improves invoice accuracy and avoids disruptions to the invoicing process.
Original PR description
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not…
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not applicable - [Sales] Service Code Origin: 14.01.3/168061/1524 - [Sales] Service Codes: 14.01.3/168061/1524 - Create an Invoice with Document Type "Electronic Service Invoice - NFS-e" - Add the product on the line - Compute taxes - Compute taxes again Issue: Action will be blocked by a validation error resulting from the external taxes call ``` odoo.exceptions.ValidationError: Odoo could not fetch the taxes related to Draft Invoice. Errors: Rejection: Total Installments doesnt match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 ``` It occurs because during the call the system is considering the existing taxes on the line and it will send to the avatax service wrong amounts opw-5412456 opw-5409735 Forward-Port-Of: odoo/enterprise#108088
This update fixes an issue where international UPS shipments were generating commercial invoices with incorrect freight charges (showing $0.00). The fix ensures that freight charges are properly included on the invoice by specifying the necessary parameter during the shipment process. This ensures accurate customs documentation and avoids potential delays.
Original PR description
Issue ----- For international deliveries, the commercial invoice used for customs does not include the freight charges (it is set to 0). Steps to reproduce ----- - Create an international UPS sale - Confirm the delivery - Open the "UPSCommercialInvoice.pdf" file > In the price breakdown, freight is set to 0.0 Cause ----- It has to be specified in the `ship` request as `ShipmentServiceOptions.InternationalForms.FreightCharges.MonetaryValue` (source https://docs.rocketshipit.com/rs/docs/ups-api-parameters.html#shipment) Expected result ----- <img width="1912" height="963" alt="image" src="https://github.com/user-attachments/assets/170e49f7-6575-4524-b186-3829f4c20430" /> ----- Ticket: opw-5135494 Forward-Port-Of: odoo/enterprise#108465 Forward-Port-Of: odoo/enterprise#105505
This update resolves an issue preventing the BOE report export when using multi-company mode with companies having different VATs. The fix ensures the report correctly handles branch company selections, now requiring users to select all companies in the hierarchy for successful export.
Original PR description
**Steps to reproduce:** * Install the **l10n_es_reports** module. * Create a parent company with two branch companies with all has different VATs. * Enable **multi-company mode** with all companies selected. * Go to tax report `Mod 390` * From gear icon clck on `BOE`. **Observed behavior:** * A warning appears: Please select the main company and its branches in the company selector to proceed. * Not able to export BOE. **Cause:** * This is because the tax report's options only consider one of the two companies (because they have different VAT numbers). The button is not declared as branch_allowed, so when clicked, it checks whether all the companies of the branch hierachy are in the options => they're not => error. **Fix:** * Added the `'branch_allowed': True` to the `BOE` button options. opw-5891472 Forward-Port-Of: odoo/enterprise#107252
This update fixes an issue in the barcode picking interface where multiple extra product scans would repeatedly open a confirmation dialog. Now, the dialog opens only once and allows users to easily select or deselect extra items before confirming the addition, streamlining the picking process.
Original PR description
When adding extra products in the barcode picking interface, the confirmation dialog did not handle correctly the scan of multiple extra items. Before: Scanning multiple extra products successively opened (mutex + promise) the dialog multiple times. The user had to confirm/cancel each extra product addition one by one. After: The dialog is now only opened once and updated when scanning multiple extra products before confirming. The user can select/deselect the extra products to add before validating. [opw-5193269](https://www.odoo.com/odoo/project/49/tasks/5193269) Forward-Port-Of: odoo/enterprise#108393 Forward-Port-Of: odoo/enterprise#104932
9 changes
Resolved issues and error corrections
This update resolves an issue where newly created subtasks were incorrectly appearing at the top of the Kanban view. The fix sorts subtasks by their ID, ensuring they are displayed in the expected order, improving usability and clarity for users managing tasks and subtasks.
Original PR description
### Steps to reproduce: - Create a project and a task in this project - Create a subtask for the created task - Go for the kanban view and add another subtask - Notice the last created subtask is on the top of the list ### Cause: This is happening as we show the list of the subtasks as it is without sorting it. ### Fix: We sort the closedList for subtasks ascendingly according to their IDs opw-5943741
This update prevents archived subtasks from being duplicated when a task is copied. Previously, duplicated tasks incorrectly included inactive subtasks, leading to unnecessary clutter. This change ensures a cleaner and more efficient task management experience.
Original PR description
Currently, when duplicating a task that contains `archived subtasks`, the archived subtasks are also duplicated. **Steps to reproduce:** - Install the `project` module. - Open any `project` and create a task with a subtask. - `Archive` the subtask. - `Duplicate` the parent task. **Observation:** The duplicated task contains a copy of the archived subtask, even though it is inactive. **Root Cause:** At [1], subtasks are duplicated without checking their active status. As a result, archived (`active=False`) subtasks are also copied during duplication. **Fix:** This commit ensures that archived subtasks are not copied when duplicating a task. [1]: https://github.com/odoo/odoo/blob/531b887aec92c2fbf57495992be9fbc32d9ea20e/addons/project/models/project_task.py#L822 opw-5926009
A recent test within the Odoo payroll system was failing when the 'Attendance' module wasn't installed. This fix moved the test to a separate module to ensure it consistently runs with the Attendance module, preventing future test failures and maintaining system stability. This improves the reliability of payroll testing.
Original PR description
Purpose: `test_05_fully_flexible_contracts_payslip` was failing without attendance installed as it creates contracts with `'work_entry_source': 'attendance'` Fix: moved the test to `hr_payroll_attendance` to ensure that it always runs with attendance installed pr introducing the test: https://github.com/odoo/enterprise/pull/93935 task-id: 5902805
A recent issue causing live chat sessions to crash when multiple sessions were started quickly has been fixed. Previously, a reliance on outdated data led to conflicts. This update ensures a more stable and reliable live chat experience for users.
Original PR description
Since [1], a crash could occur when starting several live chat sessions quickly. Before this PR, the `thread` getter depended on `savedState`. In [1], `thread` became a field on the live chat service. There can be a slight delay where thread has been cleared, but saved state still exists. The `_createThread` method shouldn't rely on `savedState` to determine if there is a thread. [1]: https://github.com/odoo/odoo/pull/173197 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update clarifies the event booking process for existing partners. When presented with a 'Sign In' link, the message now suggests creating an account if they don't have portal access. This ensures a more complete and helpful experience for users.
Original PR description
When booking with an email that belongs to an existing partner, a 'Sign in' link is shown to the booker. If the partner has no portal access, then it is not relevant as they could also need to create an account. Therefore, change the wording by adding 'or create an account'. This way, the use of the login page redirection is more complete. opw-5419532
This update resolves a bug where transferring orders to booked tables could fail when the table had no associated orders. The fix ensures that only finalized orders are transferred, improving the reliability of the restaurant POS system. This prevents incorrect order transfers and enhances the user experience.
Original PR description
Step to reproduce: - Make a pos order - Book a table without orderlines - Transfer the order to the booked table - Traceback Issue: The transferOrder method was retrieving non-finalized table orders that contained order lines using getActiveOrdersOnTable. However, it later checked for the existence of any non-finalized order using tableHasOrders, regardless of whether it had order lines. This caused inconsistent behavior in cases where a table was booked but had no order lines. opw-5965705 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a minor issue where the website and web editor were experiencing delays in Firefox 148 due to how 'about:blank' documents were handled. By using empty iframes to load templates and previews, the system now completes navigation synchronously, resulting in faster performance and a smoother user experience.
Original PR description
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing context goes to about:blank, it completes > synchronously and is no longer replaced by a second parser-generated > document. Commit [e0796020] added the new page dialog in website, and used empty iframes to load each page template. Commit [edf81c13] added the add snippets dialog in website, and used an empty iframe to load the snippets previews. In both cases, before Firefox' fix, it meant we had to wait the recreation of the 2nd document before proceeding. This is no longer the case in Firefox >= 148. [release notes]: https://www.firefox.com/en-US/firefox/148.0/releasenotes/ [e0796020]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7 [edf81c13]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a
This update adjusts Odoo to comply with a new Italian law effective January 1, 2025. Forfettari (RF19) – a specific category of Italian taxpayers – can now utilize simplified invoices regardless of the total invoice amount. This simplifies invoicing processes for this group of businesses.
Original PR description
Since 01/01/2025, Italian law allows forfettari (RF19) to use simplified invoices even if the total amount exceeds 400€. References: - https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:legge:2014-12-23;190;1;59#:~:text=L'emissione%20della%20fattura%2C%20ove%20prevista%2C%20può%20avvenire%20in%20modalità%20semplificata%20ai%20sensi%20dell'articolo%2021%2Dbis%20del%20decreto%20del%20Presidente%20della%20Repubblica%2026%20ottobre%201972%2C%20n.%20633%2C%20anche%20se%20di%20ammontare%20complessivo%20superiore%20al%20limite%20indicato%20nel%20comma%201%20del%20medesimo%20articolo%2021%2Dbis. - https://www.dkpost.it/fattura-semplificata-senza-limiti-per-i-forfettari/ - https://www.gazzettaufficiale.it/eli/id/2024/11/30/24G00196/sg Forward-Port-Of: odoo/odoo#247264
This update fixes an error in the Spanish Profit & Loss reports where specific accounts (7950 and 7957) were incorrectly placed. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#107949
1 change
Resolved issues and error corrections
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicate quantities being added to the transfer. The fix ensures that the quantity is saved correctly, preventing data inconsistencies and improving the accuracy of inventory tracking.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899