Daily updates from Odoo
Monday, May 11, 2026
41 changes · saas-19.3
New functionality added to Odoo
This update expands Odoo's language capabilities to include Russian, specifically for the Uzbekistan localization module (l10n_uz). This allows Uzbek businesses using the Russian language to operate within Odoo, improving usability and compliance with local regulations. It's a straightforward translation enhancement.
Original PR description
Forward-Port-Of: odoo/odoo#263479
This update implements the required 5% IGIC (Value Added Tax) for Spanish businesses within the Odoo system. It also corrects previous errors where incorrect tax percentages (3%) or incorrect tax groups were applied. This ensures accurate tax calculations and reporting for Spanish customers.
Original PR description
- Fix also some errors on the 5% taxes, where a 3 percent was applied or the group was not the right onw @jco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263101 Forward-Port-Of: odoo/odoo#231836
Enhancements to existing features
This update adjusts payroll deductions for employees 60 or older in Kenya. It now stops NSSF contributions when an employee's birthday passes, aligning with Kenyan regulations. A new test has been added to ensure this functionality works correctly.
Original PR description
[IMP] l10n_ke_payroll: stop NSSF deductions after 60
When the user is creating a payslip and if the age of employee is >=60 the NSSF deductions must stop
(If the 60 years is finished in 10th of March -> it will stop in April (deduction stop starts from next month))
Test:
Unit test is written to check stopping NSSF deductions with dynamic birthday.
task - 6074658
Forward-Port-Of: odoo/enterprise#115236Resolved issues and error corrections
This update resolves a problem preventing the demo data for the MRP Subcontracting module from loading correctly in Odoo 19. The fix ensures that the correct product template record is used, which was previously mismatched. This ensures demo data loads properly and allows users to test the module's functionality.
Original PR description
Steps to reproduce: - Initialize an empty database with demo data enabled - Install mrp_subcontracting Problem: The product.product `product_delivery_02` record does not share the same #ID as the product.template `product_delivery_02_product_template` record. This leads to an error when loading the demo data. This errors only started with Odoo v19. Solution: Use the right product.template `product_delivery_02_product_template` record. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263387 Forward-Port-Of: odoo/odoo#262949
This update fixes an issue where the PDF viewer field didn't properly save the uploaded file's name. Now, when you upload a PDF, the correct filename is stored, improving file management and organization within the system. This ensures accurate tracking and retrieval of documents.
Original PR description
When uploading a file using the PDF viewer field, the filename was not stored in the corresponding filename field. This commit updates the PdfViewerField to support a filename field via the `filename` attribute. task-4825728 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262767 Forward-Port-Of: odoo/odoo#259795
This update resolves an issue where error messages from the Danish tax reporting system (l10n_dk_reports) could cause unexpected errors. The fix ensures the system correctly handles error messages, preventing crashes and improving the reliability of tax report generation. This change was driven by a technical update to the underlying system.
Original PR description
before this commit, if the SKU server was returning an error message, the error handler would raise an exception because of the lazyTranslate. The reason is that `join()` expects an actual sting as argument, not a lazy string. This commit adds some tests for the error case and fixes the error due to the lazytranslate in the error codes. opw-6171466 Forward-Port-Of: odoo/enterprise#115887 Forward-Port-Of: odoo/enterprise#115515
This update fixes an issue where subscription delivery dates were incorrectly displayed as the previous day due to timezone differences. The fix ensures delivery dates are accurately calculated based on the company's timezone, resolving a potential scheduling problem for subscription orders. This improves the reliability of delivery planning.
Original PR description
Steps to reproduce 1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. Create a sale order for a storable subscription product and confirm…
Steps to reproduce 1. Set the company's partner timezone to a negative UTC offset (e.g. America/Argentina/Buenos_Aires, UTC-3). 2. Create a sale order for a storable subscription product and confirm it. 3. Open the generated delivery order and check its Scheduled Date. Issue The scheduled date on the first delivery renders as the previous day. `_prepare_procurement_values` writes `date_planned` as `current_period_start`, which is a plain `fields.Date` value (https://github.com/odoo/enterprise/blob/ba41d7de3c0474286e3e9319710fdacfb95d3e2c/sale_subscription_stock/models/sale_order_line.py#L156). When a `date` is stored in the `Datetime` column `stock.move.date`, Odoo anchors it at midnight UTC; in any negative-offset timezone this renders as the previous day (e.g. `2022-03-02 00:00 UTC` shows as `2022-03-01 21:00` in UTC-3). The non-subscription path does not hit this because it resolves `date_planned` through `_expected_date()`, which returns `order_id.date_order` — a full `Datetime` set to `fields.Datetime.now()` at confirmation (https://github.com/odoo/odoo/blob/996702b0d5c518db2ac6f0b144e7835b27c29736/addons/sale/models/sale_order_line.py#L1398). The same midnight-UTC drift also affects later recurrences, where `current_period_start` falls back to `last_invoice_date` — another `Date`. Solution Split the two cases explicitly: - First delivery (`last_invoice_date` unset): set `date_planned` to `order_id.date_order`, matching the non-subscription flow. - Subsequent deliveries: localize `last_invoice_date` at `00:00` in the company timezone before converting back to UTC, reusing the pattern already applied to reordering rules (https://github.com/odoo/odoo/blob/20a0eee2d03293564320c268252a0353781d99ea/addons/stock/models/stock_orderpoint.py#L722). opw-6133831 Forward-Port-Of: odoo/enterprise#116593 Forward-Port-Of: odoo/enterprise#115100
This update fixes an issue where Peppol invoices were incorrectly sending data from branch companies instead of the designated parent company. The change ensures that the XML invoice accurately reflects the parent company's information, complying with Peppol regulations and improving data consistency. This resolves a prior reporting discrepancy.
Original PR description
### Issue before this commit: The XML export for branch companies incorrectly identified the branch as the sender, even when a Peppol parent company was configured. ### Steps to reproduce the issue:…
### Issue before this commit: The XML export for branch companies incorrectly identified the branch as the sender, even when a Peppol parent company was configured. ### Steps to reproduce the issue: 1. Download Accounting, Contacts and l10n_be 2. Create a branch for a Belgium company 3. Enable Peppol sending on the parent company 4. Enable Peppol sending on the branch company using the parent company endpoint 5. Switch to branch company 6. Create a customer invoice in the branch company using a customer who is on the Peppol network (meaning insert a valid VAT number and then verify button in the Accounting tab) 7. Confirm and send the invoice via Peppol 8. Download the resulting xml file and check the "AccountingSupplierParty" nodes. It contains the data of the branch and not the ones of the parent company ### Cause of the issue: The EDI export logic was fetching the supplier data directly from the invoice's company record without checking for a delegated Peppol parent company, ignoring the hierarchical relationship defined in the settings. ### Reason to introduce the fix: This fix ensures that the AccountingSupplierParty in the UBL/CII file correctly reflects the parent company's data when applicable. opw-6030526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260389
This update corrects a technical issue preventing the correct display of IP salary rules on employee payslips. The underlying calculation has been adjusted to ensure accurate reporting of IP contributions. This ensures payroll data aligns with Belgian tax regulations.
Original PR description
-**Issue**: The IP salary rule was not visible on payslip. -**Fix**: Computation has been adjusted to include the correct field. Forward-Port-Of: odoo/enterprise#112711 Forward-Port-Of: odoo/enterprise#110936
This update resolves a problem where invoices weren't correctly processing extra components within kit products when automatic accounting was enabled. Specifically, the system was misinterpreting the unit of measure, leading to invoicing errors. The fix ensures accurate accounting for these components during the invoicing process.
Original PR description
### Steps to reproduce: - In the settings Enable: "Automatic accounting" - Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time')…
### Steps to reproduce:
- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category.
### Cause of the issue:
The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34
opw-6041375
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#261878
Forward-Port-Of: odoo/odoo#258141This update ensures that a unique transaction ID, provided by the Italian tax authority (SDI), is saved when vendor bills are received in Odoo. Previously, this ID was lost during the import process. This enhancement improves the traceability and reporting capabilities for Italian tax compliance.
Original PR description
A unique transaction id is provided by the SDI for every document. This transaction was saved on document sending, but discarded for received one. --- For each unwrapped attachment, the _unwrap_attachments method extend the origin filename with `_<number>`. This mechanism allow finding what transaction id does each move correspond to. opw-6111186 Forward-Port-Of: odoo/odoo#261970
This update fixes an issue where automatically selected courses for multi-category restaurant items always chose the lowest sequence number, regardless of the active category filter. Now, the system correctly picks the course linked to the currently selected category, ensuring accurate order processing. Additionally, a new feature prevents the creation of unnecessary courses when adding items to orders with `use_course_allocation` enabled.
Original PR description
When a product belongs to multiple categories, each linked to a different course, the automatic course selection was always picking the one with the lowest sequence, regardless of context. The expected behavior is to pick the course tied to the currently active category filter, not an arbitrary one. This commit implements that logic. In addition, when `use_course_allocation` is enabled, adding a first course to an order that already contains products no longer creates an extra course. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6187108 Forward-Port-Of: odoo/odoo#262683
This update fixes an issue where preparation print requests for point-of-sale (ePOS) orders were not being processed correctly. Now, users can easily retry printing by clicking a 'Retry' button, ensuring that receipts are always generated as intended, preventing duplicate prints in the kitchen.
Original PR description
When ePOS preparation print fails, user can click on the "Retry" button to resend the request. Due to the logic of preparation receipts reprints, made to avoid duplicate prints in the kitchen, the changes were considered as already printed and the request was never made. We now provide only the printers with failures to the retry callback and a flag to mark them as failing in order to force reprint. Forward-Port-Of: odoo/odoo#263487
This update fixes an issue where the end date on generated payslip PDFs was displayed incorrectly. The problem stemmed from a formatting error in the XML file, which has now been resolved to ensure consistent and accurate date presentation on all payslips. This improves the user experience and data accuracy for payroll reports.
Original PR description
ٍSteps: - Go to the payslip tabs under payroll app - Create a payslip and preview the generated PDF - The end date format is messed up Cause: The format was different because the end date was being overriden in the xml file and being displayed in the xml through t-out tag instead of span and t-field tags. Solution: Matching the format of the start date and end date of the payslip template. Task: 6168607 Forward-Port-Of: odoo/enterprise#115317
This update resolves an issue where a unit test for LDAP authentication was leaving temporary data in the database. Switching to a simpler `HttpCase` approach has corrected this and paves the way for adding another test to address a related bug. This ensures the stability and reliability of our LDAP integration.
Original PR description
The unit test is tagged `-standard` and `database_breaking` because it was leaving left overs in the database. Using an `HttpCase` over a `BaseCase` solves that issue in addition to make the code way simpler. We want to resurrect this unit test class because we plan to add another unit test in that class for a bug fix. Forward-Port-Of: odoo/odoo#263417 Forward-Port-Of: odoo/odoo#261743
This update resolves an issue where uninstalling the l10n_ar_edi module caused database instability and prevented reinstallations. The problem stemmed from an inconsistent state within the module's configuration, specifically the currency provider field. A manual step is now required to restore the database, ensuring smoother module management.
Original PR description
since : https://github.com/odoo/enterprise/commit/de8c92290ca17f69b5cefa686fc743df7c645f32 Step to reproduce the crash: 1. Create a database with l10n_ar_edi installed 2. Uninstall currency_rate_live Result: Registry is crashed, database inaccessible Attempts to reinstall the module also crash due to the inconsistent state of the l10n_ar_edi application (specifically due to the currency_provider field) Required manual step to bring back the database to a valid state; 1. in SQL: mark the l10n_ar_edi module as uninstalled 2. ./odoo-bin -i currency_rate_live,l10n_ar_edi --stop-after-init opw-6124819 Forward-Port-Of: odoo/enterprise#115082
This update resolves an issue where the HR system might fail if no active versions of data were available. The change provides a fallback mechanism, ensuring core HR functions continue to operate smoothly. This improves system stability and prevents disruptions to employee management processes.
Original PR description
Forward-Port-Of: odoo/odoo#263324
The customer list view now accurately displays total due and overdue amounts. This fix addresses a technical issue where empty dashes were shown instead of calculated totals when specific columns were added. This ensures accurate reporting of customer financial information.
Original PR description
In the partner list view, enabling the "Total Due" and "Total Overdue" columns results in empty aggregates (—) at the bottom of the list. Steps to reproduce: - Navigate to Accounting -> Customers -> Customers - Add columns 'Total Due' and 'Total Overdue'. - Check the computed totals. Issue: The totals displays dashes (—) instead of the numbers. Analysis: The web client list renderer requires a currency field to be present in the view to correctly format and display aggregate sums for monetary fields, otherwise empty dashes are shown as fallback. opw-6169513 Forward-Port-Of: odoo/odoo#263585 Forward-Port-Of: odoo/odoo#261820
A recent update intended to automatically populate product descriptions in order forms caused unintended side effects, specifically preventing users from manually editing these descriptions. To avoid further disruption, the change has been reverted. This impacts product descriptions across multiple order types.
Original PR description
**Steps to reproduce:** 1- Create a new PO/SO/Invoice. 2- Add a new order line and select a product. 3- Click on the UI dropdown to hide the Product column/field. 4- In the Description column (stored…
**Steps to reproduce:**
1- Create a new PO/SO/Invoice.
2- Add a new order line and select a product.
3- Click on the UI dropdown to hide the Product column/field.
4- In the Description column (stored as name in the model), the product name appears by default. Delete it and write a manual description.
5- Enable the Product column once again.
**Issue:**
The description no longer appears under the product name in the form view
**Why this happens:**
Commit https://github.com/odoo/odoo/commit/bd5b86e1596e0058ff8f46a79b7c1a918f1d4adc introduces the new logic below:
`this.currentProductName = this.productName ? label.split("\n")[0] : "";`
which assumed the label will always come from the backend in the form [Product Name] + [Product Translation]
So when the following condition was checked, it evaluated to true and the description was truncated:
`else if(this.currentProductName && label.startsWith(this.currentProductName))`
However, a customer can manually edit the description like mentioned above, removing the product name from the description (`name`) column.
Additionally, the fix affected another flow. When you create a product with a Vendor Product Name/Code for vendor X and then create a RFQ for vendor X with that product, the Vendor Product Name/Code no longer appears in the description.
**Resolution:**
Since the fix for the initial problem is causing significant side effects across multiple flows, we decided to revert
the fix.
opw-6189252
Forward-Port-Of: odoo/odoo#263305This update resolves an issue where the composer field in the portal chatter wouldn't automatically focus after an emoji was added. The fix ensures the composer always receives focus, improving the user experience. This was caused by a missing default value for the composer's autofocus property.
Original PR description
Before this commit, after adding an emoji via the emoji picker in the portal chatter, the composer would not be focused. This is due to the `autofocus` prop of the composer being optional and not having a default value, leading to `NaN` when being incremented while `undefined`. This commit fixes the issue by giving it a default value of 0. task-6204911 Forward-Port-Of: odoo/odoo#263494
This update fixes a previous limitation in the Helpdesk system where returns for dropshipped orders couldn't be processed directly from tickets. Now, the 'Returns' button is visible for dropshipped transfers, allowing users to manage returns seamlessly and improving the efficiency of handling customer returns. This ensures consistent return functionality regardless of order type.
Original PR description
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and…
### Steps to Reproduce: - Enable dropshipping in Inventory settings - Create a product with inventory tracking enabled - Enable dropship under the Inventory tab for the product - Add a vendor and quantity under the Purchase tab - Create a sale order for the product - Go to the Purchase stat button and confirm the order - Click on the Dropship stat button and validate the transfer - Open Helpdesk and create a new ticket for the same partner ### Issue: The "Returns" stat button is not visible for dropshipped deliveries. ### Current behaviour: - The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor. - With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket. ### Expected behaviour: Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO). ### Fix: The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket Issue:https://github.com/odoo/enterprise/pull/81378 task-4881338 Forward-Port-Of: odoo/enterprise#91402
This update resolves a visual issue within the Time Off Type settings, specifically when the 'Allow Negative' option is selected. The change involved restructuring the form layout to correct a broken display, ensuring the Time Off Type settings are presented correctly. This improves the user experience for managing time off requests.
Original PR description
Version: - saas-19.3 Steps to reproduce: - Install the Time Off module - Go to Settings → Time Off Types - Click on “Allow Negative” Issue: - The form layout for Time Off Type is broken Cause: - Before this PR: https://github.com/odoo/odoo/pull/249288 , the Allow Negative field was inside a <group> tag. - After the PR, it was moved inside a <div>. Fix: - Updated the class based on the new structure to fix the layout Task-6127402
This update resolves an issue where self-billing invoices were incorrectly processed as standard invoices. The change ensures the correct document type ('credit_note') is used when generating UBL invoices for Peppol self-billing transactions, improving the accuracy of financial reporting. A demo environment setup has also been added.
Original PR description
To reproduce: - Activate Peppol - Activate selfbilling on your purchase journal - Create a Vendor Refund - Generate the UBL => The InvoiceTypeCode is 389, meaning it's considered a selfbilling invoice, not a selfbilling credit note. The issue is that we never put the document type of credit_note for selfbilling documents as it wasn't expected. invoice was, due to a else encompassing invoices and bills. Also add a handle demo to be able to create selfbilling documents in demo mode. opw-6132226 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263128 Forward-Port-Of: odoo/odoo#260941
This update removes a restriction that previously required Lazada products to be 'storable'. When stock synchronization with Lazada is disabled (as is common), tracking stock levels isn't needed, so this restriction is no longer relevant. This change simplifies product setup for Lazada listings.
Original PR description
Lazada items previously required products to be of type 'storable'. This restriction is unnecessary when stock synchronization is disabled, since no stock tracking is performed in that case. opw-6173986 Forward-Port-Of: odoo/enterprise#116543
This update resolves an issue where the automatic checkout feature would fail when an employee had multiple overtime entries on the same day, particularly when one entry lacked a defined checkout time. The fix ensures accurate calculation of overtime durations, preventing validation errors and ensuring the feature functions correctly across various scenarios.
Original PR description
__ ## Short functional explanation of the error When an employee has multiple overtimes for the same day, including one that doesn't have a check-out date. When running the scheduled action…
__ ## Short functional explanation of the error When an employee has multiple overtimes for the same day, including one that doesn't have a check-out date. When running the scheduled action `Attendance: Automatically check-out employees`, an error occurs: `odoo.exceptions.ValidationError: Duration must be positive and cannot exceed 24 hours.` ## Reproduction Steps 1. Create an employee. Set their timezone to UTC and the Overtime Ruleset to Default Ruleset in the settings tab. In the Payroll tab, set a contract start date. 2. Set their Working Hours to a fixed 40 hours/week. Set the timezone of the Working Schedule to UTC. 3. Go to attendances and create 2 attendances on a Sunday: one from 06:00 to 06:01 and a second that starts at 06:02 but that doesn't have a checkout date. 4. Go to Settings and enable Automatic Checkout. Leave the Tolerance to 2 hours. 5. Enable debug mode and go to Scheduled Actions. Look for `Attendance: Automatically check-out employees` and run it manually. ### Expected behavior As the tolerance is 2 hours, the second attendance check-out time should be set at 08:01. ### Unexpected behavior An error occurs: `odoo.exceptions.ValidationError: Duration must be positive and cannot exceed 24 hours.` ## Origin of the issue We retrieve overtime intervals with the domain: https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_version.py#L34-L42 This will make us retrieve all the overtimes for a given day, even if overtimes belong to different attendances. However, this means that we will retrieve several times the same overtimes, as this piece of code is executed in this context: https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_attendance.py#L35 https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_attendance.py#L43 This results in the generation of intervals containing multiple times the same overtimes. We then sum their duration to later create work entries: https://github.com/odoo/enterprise/blob/64f813dab727d76286c1ff6c80c08cb6a6737b49/hr_work_entry_attendance/models/hr_attendance.py#L47 As we try to create a work entry with too much overtime, that exceeds 24 hours, it raises a validation error. Moreover, as the overtime hours are always stored in UTC, it makes sense to always keep the timezone as UTC when performing a `_read_group` . __ opw-6036064 Forward-Port-Of: odoo/enterprise#116194
This update fixes an issue where the navbar menu items and app icon would disappear when users zoomed out or increased the screen width on mobile devices. The fix ensures the navbar dynamically adjusts to display the full menu and icon when sufficient screen space is available, improving the user experience.
Original PR description
**Issue:** In the navbar view, when a user starts in mobile view (narrow width) and then increases the screen width (e.g., by zooming out or resizing), the menu items and app icon do not reappear.…
**Issue:** In the navbar view, when a user starts in mobile view (narrow width) and then increases the screen width (e.g., by zooming out or resizing), the menu items and app icon do not reappear. The navbar remains stuck in mobile mode even when there is enough space to display the full layout. **Fix:** The navbar was relying on `env.isSmall`, which is only set during initialization and does not react to window resizing. This has been updated to use `this.ui.isSmall`, which is reactive and updates dynamically when the viewport size changes. **Before:** After resizing from mobile to a larger width, the navbar continued to behave as if it were still in mobile view, keeping menu items and the app icon hidden. **After:** When the screen width increases, the navbar correctly detects the change and re-renders, restoring the menu items and app icon as expected. opw-6107660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263675 Forward-Port-Of: odoo/odoo#263039
This update ensures that 'Back on' messages for employees on holiday are now consistently displayed in both the standard and compact versions of the chat sidebar. Previously, these messages were only visible in the larger sidebar view. This enhancement provides a more complete and user-friendly experience for viewing team availability.
Original PR description
Before this commit, the "Back on X" text below chats of people that are away was only displayed in non-compact sidebar. This comes from `xpath` that targets only the non-compact sidebar. This commit fixes the issue by adding the `xpath` for the compact sidebar. Task-6197362 Before / After <img width="247" height="254" alt="before" src="https://github.com/user-attachments/assets/da149668-7649-479a-baca-c3df9f6600b6" /> <img width="240" height="279" alt="after" src="https://github.com/user-attachments/assets/072405d1-b050-4314-933f-31f1c1c30ad4" /> Forward-Port-Of: odoo/odoo#263426 Forward-Port-Of: odoo/odoo#263071
This update fixes an issue where products added to a sales order catalog were appearing in the wrong order. The change ensures products are added to the catalog in the intended sequence, improving the user experience when managing product selections. This resolves a bug related to how the system adds new order lines to the catalog.
Original PR description
# How to reproduce
- Create product n1 & n2
- Create a SO
- Add a section to that SO
- Go to the catalog
- Ensure the section is selected, then add product n1 followed by n2
# The problem
The orders of the product are reversed. n2 is before n1 in the SO
# Cause
Clicking on the Add button will trigger an RPC call to "/product/catalog/update_order_line_info"
that will endup adding a new sale order line :
https://github.com/odoo/odoo/blob/c7f05ae216de64d1f8e76e332bc6dd9cf11ce657/addons/sale/models/sale_order.py#L2222-L2227
To determine the sequence of this new order line, we call `_get_new_line_sequence`.
Since a section_id is given, the new order line is inserted right after, before any
product under the same section :
https://github.com/odoo/odoo/blob/c7f05ae216de64d1f8e76e332bc6dd9cf11ce657/addons/account/models/product_catalog_mixin.py#L59-L63
opw-6175704
Forward-Port-Of: odoo/odoo#262556This update resolves a crash issue that occurred when creating Point of Sale (POS) orders with the pos_avatax module installed. The fix re-enabled a method that correctly identifies the customer's shipping information, ensuring POS order creation remains stable. This improves the reliability of the POS system for our users.
Original PR description
Before this commit, when pos_avatax was installed, creating a pos order could crash because the pos order does not have the partner_shipping_id field. This commit re-adds the _get_avatax_ship_to_partner method as it was before the refactor https://github.com/odoo/enterprise/commit/0404086db567ee0595414263d36a3b7dceaa0dbe, which returns the partner_id for the pos order. The `_get_avatax_ship_to_partner` is overridden in `pos_avatax`. Since a `pos.order` does not have a `partner_shipping_id`, the overridden function only reads the partner_id. opw-6122280 Forward-Port-Of: odoo/enterprise#116682 Forward-Port-Of: odoo/enterprise#115840
This update resolves an issue where removing a recruiter from a job position would corrupt links between employees and their user accounts within Odoo. The fix ensures that recruiter assignments are correctly updated across all related applications, preventing data inconsistencies and ensuring accurate user management.
Original PR description
**Steps to Reproduce:** 1. Click on configure on one of the job positions having a recruiter assigned. 2. Remove the recruiter from the form 3. Now try to go to Settings App > Manage Users. (You will…
**Steps to Reproduce:**
1. Click on configure on one of the job positions having a recruiter assigned.
2. Remove the recruiter from the form
3. Now try to go to Settings App > Manage Users. (You will stuck with an error)
4. Navigate to users using the menu, and open Mitchell Admin → He is no longer an employee.
**Bug Cause:**
In HrJob.write(), when recruiter_id changes, the code attempts to update ongoing applications' recruiter by writing:
application_ids.recruiter_id.user_id = job.recruiter_id.user_id
This traverses the relational chain and writes user_id directly on the existing recruiter employee record instead of reassigning the recruiter on the applications. When recruiter_id is cleared, job.recruiter_id.user_id resolves to False, effectively setting user_id = False on the previous recruiter's hr.employee record, breaking the link between the employee and their user account.
**Bug Solution:**
Directly reassign recruiter_id on the ongoing applications instead of mutating the employee's user_id: application_ids.recruiter_id = job.recruiter_id
**Task:** 6102209
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257836This update resolves a technical issue preventing subscription invoices from calculating correctly in version 19. The problem stemmed from a mismatch in data types when comparing dates, specifically when determining if an invoice should be generated. The fix ensures accurate invoice generation for subscription orders.
Original PR description
**Steps-to-Reproduce** - In v19, install subscriptions. - create new subscription + service product with allow one time sale enabled. - make a SO with that product,any reccuring plan and any end…
**Steps-to-Reproduce**
- In v19, install subscriptions.
- create new subscription + service product with allow one time sale enabled.
- make a SO with that product,any reccuring plan and any end date.
```
id | name | subscription_state | next_invoice_date | end_date
----+--------+--------------------+-------------------+------------
1 | S00001 | 1_draft | | 2026-05-02
```
- confirm the SO
```
id | name | subscription_state | next_invoice_date | end_date
----+--------+--------------------+-------------------+------------
1 | S00001 | 3_progress | 2026-05-01 | 2026-05-02
```
- remove its recurring plan (some product sold for months for testing then converted to one time sale )
```
id | name | subscription_state | next_invoice_date | end_date
----+--------+--------------------+-------------------+------------
1 | S00001 | 3_progress | | 2026-05-02
```
- upgrade to v19.1 will fail or opening sales > To Invoice > Orders To Invoice gives this error or add amount_to_invoice in list view using studio to produce in v19 :
```
File "/home/odoo/odoo18/enterprise/sale_subscription/models/sale_order_line.py",
line 175, in _compute_amount_to_invoice
and (not order.end_date or order.next_invoice_date < order.end_date)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```
- upgrade failing for v19.1 because amount_to_invoice added to list view [here](https://github.com/odoo/odoo/commit/427232efd121410380b62acf4fd2e9ee369e6542#diff-48cb4309a6006f91b2b40e4c1049860218d419fce1782c7dcc278329803129caR193-R213).
upg - [4220658](https://upgrade.odoo.com/odoo/upgrade.request/4220658)
opw - [6128033](https://www.odoo.com/odoo/project/70/tasks/6128033)
Forward-Port-Of: odoo/enterprise#115976This update enhances the tracking of errors within Odoo's Point of Sale system. Previously, IndexedDB errors weren't consistently recorded, making it difficult to diagnose issues. Now, critical IndexedDB errors are saved to local storage, ensuring that error traces are preserved even if the main IndexedDB system is temporarily unavailable, aiding in faster troubleshooting.
Original PR description
Add a `persistToStorage` flag to `logPosMessage` that mirrors critical IndexedDB errors to `localStorage["pos_idb_errors"]` in addition to the posLogger. This ensures error traces are preserved even when the IndexedDB daemon itself is unavailable. opw-6150816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263377 Forward-Port-Of: odoo/odoo#263093
This update resolves a crash issue that could occur when displaying data in Odoo's graph views. The fix ensures that a necessary data element is always available, preventing errors during data formatting and improving the overall stability of the graph view functionality. This change enhances the reliability of reporting and data visualization within Odoo.
Original PR description
**Current behavior before PR:** In graph rendering, `formatValue()` delegates to widget formatters (e.g., formatPercentage), which call `extractOptions()` (from formatFloat). That function directly accesses `attrs.digits`, assuming `attrs` is defined. Here, `extractOptions()` could be called without `attrs`, leading to a traceback when accessing `attrs.digits`. **Desired behavior after PR is merged:** This commit ensures `attrs` is always defined when calling `extractOptions()`, avoiding the crash. task-[6023555](https://www.odoo.com/odoo/project/1519/tasks/6023555) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262003
This update resolves an issue where the Odoo website crashed when rental products had overlapping closed days and public time off periods. The fix simplifies the availability check to focus solely on time ranges, ensuring the website correctly displays rental availability without errors. This improves the user experience for rental product browsing.
Original PR description
Steps to reproduce: - Install website_sale_renting_planning. - Create a rental service product linked to a planning role. - Enable Sync Shifts and Rental Orders on that role. - Add a two-day public time off on the working calendar. - Open the product on the website with overlapping dates. Current behavior: The shop crashes when the selected dates overlap a closed day and a public time off. Expected behavior: The website should show rental availability without crashing when both cases overlap. Issue: The availability flow mixed two kinds of calendar data while it only needed time ranges, so the overlap broke the website flow. Fix: Keep the unavailability check focused on time ranges for closed days and public time off so both cases can be combined safely. Ref: odoo/enterprise#98165 odoo/enterprise#102070 odoo/enterprise#102076 task-6164218 Forward-Port-Of: odoo/enterprise#115480
This update corrects a discrepancy in how the dashboard displays On-Time Delivery (OTD) rates. Previously, a slight timing difference between purchase order dates and the dashboard's calculation resulted in an inaccurate 0% OTD. This fix aligns the dashboard's OTD calculation with the partner's on-time rate, ensuring accurate reporting.
Original PR description
# Setup For easiness of testing : have no purchase order in your dashboard # How to reproduce - Create a Purchase Order for Vendor X and with Product Y - Click on Confirm Order -> Receive -> Validate…
# Setup For easiness of testing : have no purchase order in your dashboard # How to reproduce - Create a Purchase Order for Vendor X and with Product Y - Click on Confirm Order -> Receive -> Validate - Go back to the dashboard # The problem The displayed OTD is 0%, but when you go to the Vendor X form view and check his On-time Rate, it is 100% # Cause The computation for the On-time rate in the dashboard uses the whole datetime value, so if there is even a second of difference between `effective_date` and `date_planned`, the PO is not counted as on-time : https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/purchase_stock/models/purchase_order.py#L253 That is not the case for the partner On-time rate computation, where we round the datetime value to the date value : https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/purchase_stock/models/res_partner.py#L57 opw-6128510 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263341 Forward-Port-Of: odoo/odoo#260384
This update fixes an issue where Egyptian VAT invoices were not including the full street address information. The system now correctly combines street and street2 fields, ensuring accurate data is sent to tax authorities. A new test has been added to guarantee this fix.
Original PR description
## Description of the issue/feature this PR addresses: ETA receiver address was only using partner.street field, causing street2 information to be dropped in generated JSON payloads. ## Current behavior before PR: When generating ETA invoices, the receiver address street field only includes partner.street, ignoring partner.street2 field. ## Desired behavior after PR is merged: Street and street2 fields are concatenated with a single space in the receiver address. A regression test has been added to ensure the concatenated street value is correctly generated. task-6133587 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where user avatars appeared stretched on user profile pages after adapting the Odoo code to the m3.1 version. The fix ensures that user avatars display correctly, providing a consistent and professional user experience. This improves the visual quality of user profiles.
Original PR description
Before this commit, the user's displayed avatar was unexpectedly stretched after adapting the code to m3.1. Steps to reproduce: - Go to Settings > Users & Companies > Users - Select a user from the list -> The user's avatar appears stretched (bug) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue that prevented users from leaving live chat channels without triggering an error. The fix ensures the system only removes a user's access once when they leave a channel, improving stability and the user experience. This resolves a previous access problem.
Original PR description
When a non-livechat user leaves a livechat channel after being invited, an access error occurs. This is due to `leaveChannelRpc` being called twice: once in `_onClose`and again in `leaveChannelProcess`. The first call removes the membership, while the second attempts to access the channel without proper rights, triggering the error. This commit fixes the issue by ensuring that `leaveChannelRpc` is only called once when leaving the channel. Task-[6072247](https://www.odoo.com/odoo/project/1519/tasks/6072247) Forward-Port-Of: odoo/odoo#262020 Forward-Port-Of: odoo/odoo#257328
This update fixes an issue where payment methods weren't correctly displayed for branch companies within Odoo. Previously, the 'Payment Method' field in partner and account move forms didn't show options from the parent company. Now, payment methods from the parent company are consistently available when working with branch companies, ensuring accurate financial processing.
Original PR description
**Steps to reproduce:** - Install Contacts and Accounting - Create a branch company - Switch to the branch company **Issue:** In the partner form, "Payment Method" field doesn't propose the methods coming from the parent company. Same issue on the account move form. However, in the payment wizard opened from an invoice, the payment methods from the parent company are available. The behavior should be consistent. The payment methods from the parent company should be available from a branch company opw-6001573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260168
This update resolves a crash issue that occurred when installing the `sale_project` module on empty runbot instances. The problem stemmed from shared database configurations causing incorrect selections to be imported. The fix ensures selections are handled safely without impacting other databases, improving stability and installation success.
Original PR description
## Description of the issue this commit addresses: When a user attempted to install `sale_project` on an empty runbot instance, the entire runbot would crash. ## Root Cause: The global variable…
## Description of the issue this commit addresses: When a user attempted to install `sale_project` on an empty runbot instance, the entire runbot would crash. ## Root Cause: The global variable storing the available `billable_type` selections in `sale_project` (`BILLABLE_TYPES`) was being modified by `sale_timesheet`. Since runbot workers are shared across multiple databases, these modified selection values leaked from one database to another. When these values appeared in databases that did not have `sale_timesheet` installed, the installation of `sale_project` would fail. ## Desired behavior after this commit: The global variable storing `billable_type` is no longer imported or modified within `sale_timesheet`. Instead, the `selection_add` attribute is used to extend `billable_type` safely and without cross‑database side effects. task[-6178239](https://www.odoo.com/odoo/project/4105/tasks/6178239) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where a project's warning status was incorrectly calculated due to an outdated data format. The fix ensures all projects display a default 'false' warning status, streamlining the system. This change is considered low impact and will be addressed in the main Odoo release.
Original PR description
Prior to this commit, the `compute` method was getting all the projects that had missing employee sale order line mappings through an SQL query. The result of the query is supposed to be a tuple but was treated as an array of `Integer` ids causing trouble while browsing and then later writing the value for the field. Since the field `warning_employee_rate` is not used in the views we can assume that the warning will be `False` for all projects and remove this field later on Master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263866