Daily updates from Odoo
Wednesday, March 4, 2026
23 changes · master
Resolved issues and error corrections
This update resolves an issue where taxes weren't correctly calculated during Google Pay (GPay) express checkout using Stripe. Specifically, Avatax calculations were missing, leading to discrepancies between the displayed price and the actual payment amount. This ensures accurate tax reporting and customer pricing.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793
Forward-Port-Of: odoo/enterprise#109121
Forward-Port-Of: odoo/enterprise#101579This fix resolves an error that occurred when no tax type was selected in Argentinian reports (like ARBA profits). Previously, the system would crash. Now, the report functions correctly even without a tax type selection, ensuring accurate reporting for Argentinian businesses.
Original PR description
Task Adhoc side: 56583 Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report.…
Task Adhoc side: 56583 Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report. Video showing the error: https://drive.google.com/file/d/1ecPOqL8DSp45rCT2QIATwYb0DB0RT_YP/view The error was this one: Odoo Client Error UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) Occured on 19.odoo.localhost on 2025-11-25 12:03:32 GMT OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) Error: An error occured in the owl lifecycle (see this Error's "cause" property) at handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:762:101) at App.handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1420:29) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:787:19) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Caused by: TypeError: Cannot convert undefined or null to object at Object.keys (<anonymous>) at get selectedTaxType (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:23629:758) at L10nARTaxReportFilters.slot3 (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:36:30) at callSlot (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:956:25) at Dropdown.template (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:8:12) at node.renderFn (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:905:207) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:786:96) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Forward-Port-Of: odoo/enterprise#100457
This update corrects a minor issue in the Documents app where action names weren't consistently reflecting the type of account move being created. Specifically, 'Invoices' was used regardless of the document type. The fix now uses the account move type to display the correct action name (e.g., 'Vendor Bills'), improving clarity and usability.
Original PR description
Previously, creating account moves from the Documents app opened the account.move list view with a static `Invoices` title, which was not explicit for all move types. Steps to reproduce: 1. Select suitable PDFs in Document App. 2. Click on `Vendor Bill`. 3. See the name of action (below Breadcrumbs) should be `Vendor Bills` instead of `Invoices` This fix adds and uses a mapping based on move_type to set the correct action name (e.g., Vendor Bills) after record creation. task-5983372 Forward-Port-Of: odoo/enterprise#109307 Forward-Port-Of: odoo/enterprise#109180
This update resolves an issue where the call method selection dialog wasn't appearing on mobile devices after adding a new call. The fix ensures the dialog is displayed correctly above the softphone, preventing errors and improving the user experience. It also includes a safety check to prevent errors when the dialog isn't immediately available.
Original PR description
After add-call PR: https://github.com/odoo/enterprise/pull/92835 when the user tries to add another call on mobile, they don't get the dialog that asks for the call method. This is because it was showing behind the softphone which also led to traceback when you click on it after ending the current call/s. This commit fixes that by making sure it's showing above the softphone in the calling state. Also, it adds a null check in the querySelector result before destructuring so that it returns instead of thrwoing an error if it was null (what happens when you click on it after you end the call). Task-5999040
This update ensures the IEPS (tax) breakdown is correctly displayed on Mexican CFDI invoices, aligning with SAT regulations. Specifically, it now only shows the IEPS if the invoice is a 'global invoice' or uses tax object 07, addressing previous inconsistencies. This ensures accurate tax reporting for Mexican businesses using Odoo.
Original PR description
This commit targets to modify the behaviour of IEPS breakdown on CFDI to follow on what is specified on SAT cfdi Tax Object Catalog. Now the IEPS will be displayed only considering if the CFDI is a global invoice, the value of the tax object and whether the check is set. The general idea is: - Is a global invoice? -> show IEPS - Is tax object 07? -> show IEPS - Has ieps breakdown but is not tax object 08? -> show IEPS - Anything else, don't. task-5953499 target: saas-18.4 -> master Forward-Port-Of: odoo/enterprise#109318 Forward-Port-Of: odoo/enterprise#108555
This update corrects a technical issue where incoming VoIP calls weren't properly recording their creation date in the database. The fix ensures accurate tracking of call start times, improving reporting and analysis of VoIP activity. This change impacts the VoIP module.
Original PR description
For incoming calls in VoIP, they didn't have create date written in the database becasue we were using `self.env.cr._now`. The orm `create` method uses `self.env.cr.now()`, a method, and it's working fine for outgoing calls. This commit fixes it for incoming calls and changes `_now` to `now()`. Task-5979968 Forward-Port-Of: odoo/enterprise#109041
A recent issue causing a crash when clearing booking dates in the restaurant appointment booking flow has been fixed. This update ensures the system correctly handles empty date values, preventing disruptions to the user experience. The fix improves stability and reliability for restaurant bookings.
Original PR description
Clicking the 'Clear' button in the booking date picker caused a crash because the system didn't expect the date fields to be emptied. This fix allows the booking popup to handle empty date values correctly without crashing. task-id: 5964417
This update simplifies the salary simulator by hiding temporary offers from the user interface. These offers are automatically deleted after a month by a scheduled process, so this change prevents confusion for users while ensuring the underlying salary calculations remain accurate.
Original PR description
The salary simulator creates temporary offers to compute salary configurations. These offers must still exist for backend computations, as the configurator relies on them when updating results. Simulation offers are already cleaned up by a cron job after one month, so this change simply hides them from the list view to avoid user confusion. task: 5498873 Forward-Port-Of: odoo/enterprise#109329 Forward-Port-Of: odoo/enterprise#107340
This update corrects a minor issue preventing users from editing date input fields within the HR payroll module. The change ensures the relevant popover is displayed before the input field is cleared, restoring full functionality. This resolves a temporary disruption to payroll processing.
Original PR description
With this additionnal step in tour, we ensure the popover is opened before clear the input. If we not wait for this, the input can be no longer editable. runbot-error-id~234440 Forward-Port-Of: odoo/enterprise#109346
This update corrects a technical issue within the Odoo Enterprise payroll module that could cause inconsistencies between payslip data. The fix ensures that all payroll line codes are synchronized, preventing potential errors in payroll calculations and reporting. This improves the accuracy and reliability of payroll processing.
Original PR description
Forward-Port-Of: odoo/enterprise#109280 Forward-Port-Of: odoo/enterprise#108729
This update corrects a bug where salary inputs weren't properly copied when creating duplicate selections. Previously, this prevented certain salary calculations from working correctly. The fix ensures that all necessary selection options are now accurately reflected, improving payroll accuracy and functionality.
Original PR description
When having a salary input avaiblable for employee and payslip, and using it in an employee made it unavailable in payslips. This is unwanted behaviour and is due to the domain restricting existing_ids in employees. This was extracted from the action and is set in each separate model according to the needs. task-5909636 Forward-Port-Of: odoo/enterprise#109277 Forward-Port-Of: odoo/enterprise#106488
This update fixes a minor issue in the Gantt chart's date selection tool. Previously, date labels didn't update immediately when a new range was chosen. Now, the UI provides instant visual feedback as you select dates, leading to a smoother and more responsive user experience. This ensures accurate date selection and reduces potential confusion.
Original PR description
This PR improves the user experience of the Gantt Scale Selector when using a **Custom** range. Previously, the "Start" and "Stop" date labels in the UI remained static until the "Apply" button was clicked, as they were bound directly to `props.scales`. This commit switches those labels to use the component's internal reactive state (`this.pickerValues`). **Changes:** * Bind `t-out` directives to `this.pickerValues` instead of `props.scales`. * Pass reactive Luxon objects through `getFormattedDate` for immediate localized rendering. **Task-5926713**
This update enhances the user experience within Odoo's web_studio by changing the names of report customizations from technical keys to more descriptive, human-readable labels. This makes it easier for users to understand and manage their report customizations, improving overall usability. The change was a simple refinement to improve clarity.
Original PR description
Before this commit the name of a view customization for a report was basically its key. After this commit, the name is more human readable task-5945040
This update corrects a display issue on payslips. The "Error" status, previously shown, has been changed to "Blocked" to provide a clearer indication of payroll processing problems. This ensures accurate reporting and easier troubleshooting for HR and finance teams.
Original PR description
[IMP] hr_payroll: renaming status name
Shown status in payslip ("Error") is needed to be changed to Blocked.
task - 5969322This update fixes an issue where payroll reports and payment exports incorrectly displayed employee names instead of the actual account holder's information. The change ensures payment records accurately reflect the bank account partner, improving data accuracy and compliance across various localized payroll modules (AU, BE, CH, IN, SA, US).
Original PR description
Steps to reproduce: 1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse). 2. Generate a payslip for this employee. 3. Print the payslip…
Steps to reproduce: 1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse). 2. Generate a payslip for this employee. 3. Print the payslip (PDF) or generate a payment export (SEPA, NACHA, ABA, CSV). 4. Observe that the employee's name is displayed instead of the account holder's information. Issue: Payroll reports and payment exports were frequently hardcoded to use the employee's legal name or work contact ID. This is incorrect when a bank account belongs to a different partner, as payment records should reflect the actual account holder. Solution: Unified logic across standard and localized payroll modules (AU, BE, CH, IN, SA, US) to prioritize the bank account's linked partner: - Updated QWeb templates to display bank.partner_id.name for account allocations. - Modified payment wizards (CSV, NACHA, ABA, SEPA) to use the bank account's partner ID. - Ensured a fallback to the employee's legal name remains in place. opw-5357652 Forward-Port-Of: odoo/enterprise#108785 Forward-Port-Of: odoo/enterprise#106718
This update resolves a stability issue in the invoice processing cron job for Brazilian tax documents. Previously, a single error would halt the entire process, wasting credits. The fix now processes invoices in smaller batches, committing changes after each, ensuring progress is preserved and preventing disruptions.
Original PR description
The cron searched with limit=batch_size and only retriggered when >batch_size records were found which never happens. It also ran all invoices in a single transaction so one failure rolled back all progress while IAP credits were already consumed. Search batch_size + 1 so remaining invoices are detected, and commit after each invoice to preserve progress. opw-5954211 Forward-Port-Of: odoo/enterprise#109315 Forward-Port-Of: odoo/enterprise#108191
This update simplifies the process of adding employees to workorders in Odoo Enterprise. Previously, the automatic employee creation for admins was removed, causing issues. Now, a popup allows quick employee creation with the current user's ID pre-filled, and automatically creates an employee if needed during shopfloor operator editing.
Original PR description
In 19.1, the automatic creation of an employee profile for the admin user has been removed. This causes issues when the admin wants to start a workorder or mark it as done, so we added a popup to create a new employee profile with the user_id already filled with the id of the current user. Also, if no employee exist when editing operators in the shopfloor, the popup proposes to directly create a new employee linked to the current user if they have HR access. This new employee will be directly logged in the shopfloor operators. see https://github.com/odoo/odoo/pull/250607 to make `action_create_employee` return an employee record. task 5932500 Forward-Port-Of: odoo/enterprise#107439
This update fixes an issue where worked days were incorrectly calculated for employees with no contract or contracts that didn't fully align with pay periods. The changes ensure accurate attendance and out-of-contract day calculations, particularly for new hires and those with contracts starting or ending mid-month. New tests have been added to verify this fix.
Original PR description
Problem: ------- In several scenarios, Worked Days are incorrectly computed when the employee has no contract or when the contract does not fully overlap with the payslip period. Case 1: - Create an…
Problem: ------- In several scenarios, Worked Days are incorrectly computed when the employee has no contract or when the contract does not fully overlap with the payslip period. Case 1: - Create an employee without a contract - Create a payslip for this employee for the current month: You'll see X days of attendance (= today until the end of the payslip period) and Y days of out of contract (= number of days from the start of the payslip period until today) - Create a payslip for this employee for the previous month: you'll see ( Z_prev + Y ) days out of contract ( Z_prev = number of working days in the previous month) - Create a payslip for this employee for the next month: you'll see Z_next days of attendance (Z_next = number of working days in the next month) Case 2: - Create a new employee with a contract starting during the current month - Create a payslip for this employee for the previous month - Out-of-Contract days are incorrectly computed as: contract_start_date - previous_month_start. Case 3: - Create an employee with a contract ending during this month - Create a payslip for this employee for the next month - Out-of-Contract days are incorrectly computed as: next_month_end - contract_end_date. Solution: -------- When generating work days lines: - Explicitly handle employees without a contract. - Use adjusted date bounds when the contract does not overlap the payslip period. Several tests were added to cover these scenarios, as well as the tests the corresponding commit in odoo/odoo (PR odoo: 241978) task-5430759 Forward-Port-Of: odoo/enterprise#109237 Forward-Port-Of: odoo/enterprise#103207
This update resolves an issue where foreign vendor VAT invoices were not correctly identifying the country of origin. The team has implemented a fix to ensure the correct country code is applied to vendor bills, improving accuracy in JPK reports. This ensures proper tax reporting for international suppliers.
Original PR description
PR #81359 fixed the country code for foreign VAT companies by adding the country code to the start. However, this was only fixed for invoices going out, not vendor bills coming in. [opw-5917264](https://www.odoo.com/odoo/project.task/5917264) Forward-Port-Of: odoo/enterprise#109080
This update resolves a problem that prevented Italian fiscal printers from working correctly. The fix ensures the order is fully synced before printing the ticket, preventing errors related to missing currency information. This improves the reliability of the Italian POS system for businesses.
Original PR description
Issue: When printing with the italian fiscal printer since the sync_from_ui was not awaited before printing, the generation of the ticket was trying to access the currency from the order that wasn't set. Fix: Print the ticket after the order is synced. Forward-Port-Of: odoo/enterprise#108144 Forward-Port-Of: odoo/enterprise#106455
A server error occurred when deleting mailings linked to marketing activities. This update corrects a technical issue caused by a change in Odoo's codebase, ensuring users receive a standard error message when attempting to delete mailings that are still in use. This prevents unexpected application crashes and improves the user experience.
Original PR description
How to reproduce ------ 1. Open the Marketing Automation app 2. Create a new campaign 3. Click on Add new activity to create a new activity (in the previously created campagin) 4. Set the Activity…
How to reproduce ------ 1. Open the Marketing Automation app 2. Create a new campaign 3. Click on Add new activity to create a new activity (in the previously created campagin) 4. Set the Activity Type to email 5. In the Mail Template option, select or create a mailing 6. Open the selected/created mailing (using the Templates smart button) 7. Click on the gear icon and then click Delete (either one or multiple together) DEMO: https://www.awesomescreenshot.com/video/50021531?key=18a341a6939e6ff8deb847fc251db570 Current behavior ----- Odoo Server Error is displayed. Expected behavior ------ Normal user error indicating that the mailing(s) being deleted is still linked to an activity (or marketing campaign). Cause ------ When formatting the user error, we used the attribute `name`, to get the mailing's display name, which does not exist in `mailing.mailing` model. Therefore, a KeyError is raised. The `name` attribute was an attribute in a class named `UtmSourceMixin` in the utm module, of which `mailing.mailing` was inheriting. In saas-19.2, that class was removed and hence the `name` is no longer available for `mailing.mailing`. The commit in which the metioned class was removed is: https://github.com/odoo/odoo/commit/93f8bb821ab86612d95d93ae0fdca5a08a12e2d5 (See utm_source.py) Solution ------ Change the `name` to `mailing.display_name`. DEMO: https://www.awesomescreenshot.com/video/50049334?key=a34a525ef38bdf2dc8037f2dcfa68761 task-5999999 Forward-Port-Of: odoo/enterprise#109400
This update resolves an issue where refreshing pivot tables caused unexpected delays. The fix ensures that related dynamic tables are also updated, improving the overall performance and stability of the pivot functionality. This change addresses a technical problem that impacts how users interact with data visualizations.
Original PR description
Refreshing the pivot will invalidate the datasource,which means that t dynamic table related to a pivot also needs to be invalidated. This usually occurs when we insert a new table but since [1], we create dynamic tables out of thin air. Pretty much every command that will invalidate the pivots will now need to invalidate the tables as well. [1]: https://www.odoo.com/odoo/2328/tasks/4552232 Counter-part of https://github.com/odoo/odoo/pull/250909 Task-5976773 Forward-Port-Of: odoo/enterprise#109325
This update corrects a display issue where upsell sale orders created from subscriptions incorrectly showed as "Quotation". The fix ensures that upsell orders now display as standard sales orders, aligning with the naming convention for initial subscriptions. This improves clarity and consistency for users.
Original PR description
## Issue When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate. <img width="1330" height="296" alt="5489970"…
## Issue
When creating and confirming an Upsell SO from a Subscription, the preview still shows the Sale Order as a "Quotation", which is inaccurate.
<img width="1330" height="296" alt="5489970" src="https://github.com/user-attachments/assets/cfff4c7a-fff7-4859-861b-c190dab9097d" />
## Steps to reproduce
1. Install *Subscription* (`sale_subscription`)
2. Create a Subscription S00001
- Any Customer
- Any Recurring Plan
- Any Product
3. Create and confirm the invoice for the subscription S00001
4. On the subscription S, click Upsell and confirm the resulting Sale Order S00002
5. On the Sale Order S00002, click Preview
6. **The title of the Sale Order is "Quotation - S000002". In the sale.order list view, the Sale Order is shown as a Sales order, just like the initial Subscription.**
## Cause
The title shown in the preview is defined here:
https://github.com/odoo/enterprise/blob/a4e2c7c7d3aa50c8b57668c9ca73f523a31a5c41/sale_subscription/views/sale_subscription_portal_templates.xml#L187-L195
The initial subscription falls into the `if` condition, which only shows the name of the SO. The upsell sale order is not considered as a subscription, as explained and showed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L193-L201
The word *"Quotation"* shown in the preview is the `sale_order.type_name`", computed here:
https://github.com/odoo/enterprise/blob/6bfd057b3d17ce8b266aa6dbd88ffef70ca634aa/sale_subscription/models/sale_order.py#L227-L237
The term "Quotation" was chosen in https://github.com/odoo/enterprise/commit/14e5cff65affa888f33d4008d10a32e6992d3a39.
## Fix
Before this commit, an upsell would always be named *"Quotation"*. With this commit, upsells are now added to the `other_orders` variable in `_compute_type_name` and follow the same logic as other SO:
https://github.com/odoo/odoo/blob/a3bf9264ca25ec11b0c9742e142d2404cac6d261/addons/sale/models/sale_order.py#L797-L803
<img width="1316" height="308" alt="5479900_2" src="https://github.com/user-attachments/assets/7cfeb578-2870-43a6-a48b-ba0898718641" />
## Alternative
An alternative to this fix would be to update the condition used to display the name of the subscription in the preview (cf. first code snippet). This would probably result in removing the `sale_order.is_subscription` from the condition, as it is the part of the condition that upsell SOs do not meet.
opw-5489970
Forward-Port-Of: odoo/enterprise#109268
Forward-Port-Of: odoo/enterprise#106767