Friday, March 27, 2026
58 changes · saas-19.1
Resolved issues and error corrections
This update corrects an issue where searching for deliveries solely by zip code resulted in inaccurate location suggestions. The fix ensures that the city field is properly populated when a zip code is provided, allowing Sendcloud to correctly identify the delivery location. This improves the reliability of our website's delivery options.
Original PR description
Issue ----- Searching for locations by only providing a zip code has unexpected results. Steps to reproduce ----- - Set up Sendcloud with Mondial Relay - Create a sale through the website - Get to the delivery part - Select sendcloud delivery - Search for a zip code only (11000) > Points are all in the 12200 area Cause ----- When searching through the wizard, a temporary address is created in https://github.com/odoo/odoo/blob/89e5038c224d58a2f6be8f3001fd0a2932733cbc/addons/delivery/models/sale_order.py#L108-L112 which always has its' city field set to `False`, as all of the wizard's info is interpreted as the zip code. This leads to the address field sent to Sendcloud being '11000 False' instead of the expected '11000', which Sendcloud fails to interpret correctly. ----- Ticket: opw-5999194 Forward-Port-Of: odoo/enterprise#110459
This update prevents a system error that occurred when users removed the interval setting from expense cards. The fix ensures the system defaults to 'all_time' when no interval is specified, improving the user experience and preventing data inconsistencies. This resolves a technical issue impacting expense reporting.
Original PR description
Currently, an error occurs when the user removes the interval from the expense card. **Steps to Reproduce:** - Install the `hr_expense_stripe` module. - Go to `Expenses` > `Cards`. - Click `New` and remove the `interval value (All Time)`. `KeyError: False` When the user removes the interval, the system attempts to access the interval from `interval_multiplier_map`. However, since the interval becomes False, it raises a KeyError at [1]. This commit ensures that when no interval is set, the system defaults to `all_time` as the interval, since `all_time` is ignored as the default value. [1]:- https://github.com/odoo/enterprise/blob/06be616bb4d74f0a089e8e318d25c2424594f813/hr_expense_stripe/models/hr_expense_stripe_card.py#L287 Forward-Port-Of: odoo/enterprise#110639
This update fixes a bug where flexible schedules with different time zones were incorrectly displaying an inflated expected hour count (48 hours instead of 40). The fix ensures accurate hour calculations by properly accounting for time zone differences, preventing incorrect hour displays in the Attendances app.
Original PR description
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of…
__ ## Short functional explanation of the error When the time zone of an employee's schedule is different from the employee's time zone, and that the employee's time zone has more than 9 hours of difference with UTC. The schedule is flexible and is set to 40 hours per week. When we open the Attendances app, the expected hours for this employee show 48. ## Reproduction Steps 1. Create an employee. The time zone of the employee should be different from the one on his work schedule. To be sure to replicate the bug, set the time zone of employee's time zone to Pyongyang. 2. Open the work schedule and set it to Flexible. Set the weekly hours to 40, and the full time equivalent to 40. Set the work schedule to Europe/Brussels time. 3. Open Attendances. ### Expected behavior When we hover the name of our employee, we can see in white on green background 0/40h. ### Unexpected behavior Instead, we see 0/48h. ## Origin of the issue This line: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L419 is used to retrieve the correct date. We assume that `end_datetime` will be set at midnight, so subtracting one second gives us the day before, allowing us to ignore the date of `end_dt`, for which we don't need to compute the intervals. However, this doesn't take into account different time zones. Indeed, we compute `end_datetime_adjusted` from `end_datetime`, which has the user timezone, and not UTC, as defined here: https://github.com/odoo/odoo/blob/e49536031f61b90212eb6f0d1a8a3e15927e723d/addons/resource/models/resource_calendar.py#L402 As a result, if we set the user timezone to Pyongyang, `end_datetime` will be set at 8am, and `end_datetime_adjusted` will lead to the same date, instead of a day before. Hence, we would compute an additional interval for an additional day, which would in the end give us 48 hours expected instead of the 40 hours indicated in the contract. Therefore, we have to take into account the time zones, hours, minutes and seconds when checking the start and end dates. __ opw-5937298 Forward-Port-Of: odoo/enterprise#110011
This update resolves a technical problem in the Odoo Enterprise payroll analytics testing process. The previous test was failing due to relying on test data that wasn't consistently available. The fix ensures the test uses defined analytic accounts, improving the reliability of the payroll reporting.
Original PR description
The test that was introduced in the following PR (https://github.com/odoo/enterprise/pull/111140), under some circumstances, was causing problems due to some records not being present. Indeed it was bad practice to use records not defined in the test, so we fix it here by defining the analytic accounts and their plan directly in the test instead of searching for them. Runbot Error: 242151 Forward-Port-Of: odoo/enterprise#112134
This update resolves an issue where the Customer Ratings reporting form in Helpdesk displayed a duplicate 'Comment' field. The fix made the redundant 'publisher_comment' field invisible, streamlining the form and improving data clarity. This ensures a consistent and accurate user experience.
Original PR description
**Steps to reproduce:** - Go to helpdesk > Reporting > Customer Ratings. - Open any rating record. - Observe that the 'Comment' field is displayed twice. **Issue:** - The form view contains a two different field with same string i.e feedback and publisher_comment **Fix:** - Made the publisher_comment field invisible in helpdesk's customer rating **Task-id: 5359052** Forward-Port-Of: odoo/enterprise#100823
This update resolves an issue where users with limited access (Invoicing Users) were encountering errors when validating invoices while audit reports were present. The fix ensures proper invoice validation functionality without requiring additional user permissions, improving usability for all users.
Original PR description
An issue occurs when an Invoicing User tries to validate a bill while an audit report exists, resulting in an access error because the user does not have permission to access account.report. Steps to reproduce: - Create an audit report for the current year - Create a user with only the “Accounting / Invoicing” access - Log in with this user and attempt to validate a bill, the access error appears on account.report since only Bookkeeper, Invoicing & Banks and Read-only accounting group has access to return. This fix ensures the validation works correctly without requiring extra access. opw-6049259 Forward-Port-Of: odoo/enterprise#111782
This update resolves a recurring error that occurred when the POS system in Italy (l10n_it_pos) lost its internet connection. By adding a safety mechanism to handle offline printing attempts, the system now gracefully manages errors instead of crashing, ensuring smoother transactions for Italian retailers.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#111487 Forward-Port-Of: odoo/enterprise#105515
This update resolves an issue where discounts weren't correctly processed in the self-order point-of-sale flow. The fix ensures that discount information is properly handled, preventing errors and ensuring accurate order totals. This improves the reliability of the self-order functionality.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719
Forward-Port-Of: odoo/enterprise#111591This update fixes an issue where audit reports weren't using the correct company-specific account report variants. Now, when creating an audit report in the Denmark localization, the system will automatically load the correct balance sheet report, ensuring accurate financial reporting for Danish businesses. This improves the reliability of financial data generated within the system.
Original PR description
Currently, when creating an audit report, the system does not use the audit report's company when generating the options for the account reports embedded in the new articles. As a result, the system may not load the account report variant that is specific to the audit report's company. Steps to reproduce: 1. Install the Denmark localization module (`l10n_dk`) 2. Switch to the Denmark company using the navbar 3. Create an audit report 4. Open the article "Balance Sheet" of your report 5. Open the embedded account report of that article => The system opens the global balance sheet. **TO BE**: it should open the balance sheet that is specific to the Denmark. To fix the issue, we will set the company to use when generating the account report options via the context and the `forced_companies` option. These changes should ensure that the account reports embedded in the articles load the right variants. Task-5901886 Forward-Port-Of: odoo/enterprise#101377
This update resolves a technical issue where the signing dialog wasn't reliably sending necessary information. The fix ensures that the correct data is consistently transmitted to the controller, improving the stability and functionality of the signing process. This prevents potential errors and ensures a smoother experience for users.
Original PR description
Before this commit, the `this.signInfo.get("signRequestToken")` variable could be undefined in some cases. This commit ensure the correct values are always sent to the controller in the propagation.
task-6064181
Forward-Port-Of: odoo/enterprise#111786This update fixes an issue where duplicating a product template automatically published it, even if the original wasn't. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing accidental product listings. This improves data consistency and reduces potential errors.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789 Forward-Port-Of: odoo/enterprise#112063 Forward-Port-Of: odoo/enterprise#111340
This update resolves an issue where Web Studio exports were incorrectly formatting property data. The fix ensures that properties are exported in the correct XML record format, improving the reliability and accuracy of exported configurations. This enhances the overall usability of Web Studio for users.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4 Forward-Port-Of: odoo/enterprise#110336
This update adds a 200% overtime wage type within the Swiss payroll module for Odoo Enterprise. This change aligns with Swiss tax regulations and ensures accurate payroll calculations for employees working overtime hours. It improves compliance and reporting accuracy for Swiss businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update allows users to access and view canceled signature requests within the Odoo portal. Previously, canceled requests were hidden, preventing users from seeing important communication details. Now, the portal displays a 'View Document' option for canceled requests, mirroring the experience for completed requests.
Original PR description
Previously, users were redirected to the home page if they tried to access a signature request in the 'canceled' state. This prevented them from viewing the communication history or the document metadata. This commit: - Removes the 'canceled' state restriction in the portal controller. - Updates the portal template to show "View Document" instead of "Sign" for canceled requests, similar to the completed state. Task: 6034621 Forward-Port-Of: odoo/enterprise#110974
This update fixes an issue where payslips for UAE employees with attendance-based work entries were incorrectly calculating hourly wages due to a technical error in how worked days were tracked. The change ensures accurate wage calculations, particularly when processing paid leave, by using the correct record object within the calculation process. This improves payroll accuracy for UAE employees.
Original PR description
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry…
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry source to attendance. - Register a paid leave time off entry, for the employee whose work entry source is set to attendance. - Compute a payslip batch using the UAE Monthly pay structure. - Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again. - The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually. ### Cause: In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees ### Fix: We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage. opw-5979631 Forward-Port-Of: odoo/enterprise#112098 Forward-Port-Of: odoo/enterprise#111280
This update fixes an issue in our tax reporting module where calculations for previous tax periods were inaccurate, particularly when using trimester tax periods. The fix ensures correct period boundaries are used, preventing incorrect report values and improving the reliability of tax reporting data. This impacts financial reporting accuracy.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#111721 Forward-Port-Of: odoo/enterprise#110504
This update fixes an issue where XML invoices for public CFDI documents weren't correctly marked as 'public' during import. Previously, the system incorrectly defaulted to 'private'. Now, the system automatically identifies and processes invoices to public CFDI standards, ensuring accurate invoice creation and reporting.
Original PR description
**PROBLEM** When importing a XML to create an invoice, even if the XML is an invoice to public, l10n_mx_edi_cfdi_to_public is False. **STEP TO REPRODUCE** 1. Create an invoice to public, and generate the xml (send with CFDI). 2. Use this xml to upload an new invoice and notice the cfdi to public checkbox is unticked. **NOTE** Previously, there was a [bug](https://www.odoo.com/odoo/my-support-tasks/5911542) where it would always be ticked. opw-5934626 Forward-Port-Of: odoo/enterprise#108287
This update resolves an issue where timesheet updates wouldn't consistently save while a timer was running. The fix prevents a technical error that occurred when the timesheet was navigated away from, ensuring timesheet entries are reliably saved and updated.
Original PR description
Steps to reproduce: 1. Install `timesheet_grid` 2. Open timesheet and start timer 3. Update any cell by clicking on seach icon. 4. Now after updating go back by clicking "My Timesheet" breadcrumb Issue: - Tracback: `Uncaught Promise > Cannot convert undefined or null to object` Cause: : - The error was occurring because the updateTimerState function in timesheet_timer_service.js was trying to iterate over timerState.data when it was undefined or null. This happens when the list view's urgent save is triggered. Solution: - added a safeguard to updateTimerState so that it simply returns early if timerState.data is empty opw-6018970 Forward-Port-Of: odoo/enterprise#110637
This update improves how Odoo handles Indonesian NPWP (tax identification numbers) by correctly classifying them as either individual or company based on the leading digit. This ensures accurate tax reporting and compliance in Indonesia, aligning with the latest regulations regarding company type identification.
Original PR description
For Indonesia, NPWP is distinguishable between an individual and company by prefix If an NPWP starts with 001, 002, or 003, treat it as a Company. Anything else is likely an Individual (local or foreign). For Indonesia, NPWP is distinguishable between an individual and company by prefix An NPWP must consist 16 digits How to distinguish between individual and company details: - Individual (Local) -> first two digit is province code start from 11 to 92 - Individual (Expat/Foreign) -> first digit = 0, second and third digit 07-09 - Company (Local or Foreign) -> first digit = 0, second and third digit 01-03 Task [#5915988](https://www.odoo.com/web#model=project.task&id=5915988) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where invoice quantities were incorrectly calculated when using timesheets for sales orders. The system was adding timesheet hours directly to the invoice line instead of converting them to the Sale Order line's unit of measure (Days). This change ensures invoices accurately reflect the time spent on the order, providing correct quantity calculations.
Original PR description
Steps to reproduce: -------------------------- 1. Install sale_timesheet 2. Create a quotation with a timesheet-based product - Set quantity = 3 - Set UoM to Days (timesheet UoM is Hours) 3. Confirm…
Steps to reproduce: -------------------------- 1. Install sale_timesheet 2. Create a quotation with a timesheet-based product - Set quantity = 3 - Set UoM to Days (timesheet UoM is Hours) 3. Confirm the quotation and click on the smart button Recorded. 4. Record 16 hours of timesheets. 5. Create an invoice using a timesheet period (starting from SO date) 6. Check the invoice quantity Issue: ----------- The invoice quantity is incorrect. It assigns the hour value (e.g., 16) to the invoice line even though the SOL is configured in "Days" (expected 2 days for 16 hours). Cause: ----------- After this commit c3b6053, The `_recompute_qty_to_invoice` method sums timesheet `unit_amount` (in hours) and assigns it directly to `qty_to_invoice` without converting it to the sale order line UoM when a timesheet period is applied. Solution: --------------- Convert the aggregated timesheet hours into the SOL UoM before assigning it to qty_to_invoice. opw-6024804 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255790 Forward-Port-Of: odoo/odoo#254273
This update allows users to easily re-upload files within the link popover without needing to manually delete the previous URL. Previously, users were required to remove the old URL before adding a new file, which was a cumbersome process. This change simplifies the file upload experience and improves usability.
Original PR description
Specification: - When a user uploads a file in the link popover, user can not re-upload another file without manually removing previous URL. <img width="320" height="231" alt="image" src="https://github.com/user-attachments/assets/9e67535a-22a1-4d41-808d-a91d07593251" /> <img width="320" height="231" alt="image" src="https://github.com/user-attachments/assets/92a33d8c-a325-4979-9956-42e81b369bd7" /> After this commit: - This commit allows user to re-upload a file without removing previously generated URL first. - TL;DR : upload button won't disappear. task-5470111 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247552
This update fixes an issue where discount popups displayed incorrect default discount values. Previously, the way decimal separators were handled caused problems when users clicked the discount button without manually changing the value. Now, the discount popup correctly formats the starting value, ensuring accurate discount calculations.
Original PR description
Before this commit, if the decimal separator was different than the dot, the starting value of the discount was not correctly formatted in the discount popup. This caused incorrect default discount values to be applied when the user clicked on the discount button without changing the value. opw-6018555 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253848
This update fixes an issue where invoice PDFs weren't displaying page numbers correctly. The change ensures that page numbers (e.g., 'Page 1/1') are shown on a single line, improving the user experience when printing invoices. This resolves a previous visual inconsistency.
Original PR description
Steps:
- Install accountant
- Configure Document layout
- Set folder layout
- Set Montserrat text font
- Try to print an invoice pdf it displays
```
Page 1/
1
```
This commit use text-nowrap to displays page numbers in one line to have
```
Page 1/1
```
opw-6006148
Forward-Port-Of: odoo/odoo#256094This update resolves an issue preventing barcode scanning of product packaging when a product doesn't have a barcode defined. The fix ensures that the system searches for the product when a barcode is scanned on packaging, allowing for seamless product identification during sales transactions. This enhances the user experience and improves the accuracy of point-of-sale operations.
Original PR description
Step to reproduce - Create a product - Add two attributes: 1. One with Instantly creation mode 2. One with Never creation mode - Define packaging from the Sales tab - Add a barcode on the variant packaging ex: 111356,11357 - Scan the packaging barcode in POS Observation: - we get a traceback `TypeError: Cannot read properties of undefined (reading 'product_template_attribute_value_ids')` Cause: - when we do not have barcode on product, when opening `openConfigurator` - (as we have few varianst) product get undefined. https://github.com/odoo/odoo/blob/f229f23d7bf3d837ff5577c36145bf2ba410ea22/addons/point_of_sale/static/src/app/services/pos_store.js#L738 - Hence the traceback Fix: - For the case, when packaging has barcode but not the product, we search for product in that case too. opw-5886570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248838
This update resolves an issue where a default empty value was appearing in website form fields, specifically radio buttons. This prevented validation warnings even when the field was marked as required. The fix corrects a technical error in how default values are handled within the website builder, ensuring proper form validation.
Original PR description
# How to reproduce - Go to the website editor - Add a Contact Form block - Add a new field with the type "Radio Buttons" - Do not set any value to default # The issue A default empty value appears in the form. The is value can be selected by the user and will not trigger any validation warning even if the field is set to required # Cause Commit [1] changed the way the default value is added for the Selection field. It contains a small oversight as the type value for "Selection" is not "selection" but many2one. https://github.com/odoo/odoo/blob/f28c9f8dc5639ff8606b139ca9d384f115b003d3/addons/website/static/src/builder/plugins/form/form_option.xml#L96-L109 [1]: https://github.com/odoo/odoo/commit/34ddd5dd6a036792c44b865cb7a4671f4ca033cf opw-6062186 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr