Daily updates from Odoo
Wednesday, March 4, 2026
81 changes · saas-19.2
Resolved issues and error corrections
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 all calls, improving reporting and operational efficiency. This change was implemented as a bug fix.
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
This update fixes an issue where refreshing pivot tables caused unexpected errors due to outdated data. The change ensures that all related dynamic tables are properly invalidated, leading to a more stable and reliable pivot table experience. This resolves a potential disruption for users generating reports.
Original PR description
Refreshing the pivot will invalidate the datasource, which means that the 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 Task-5976773 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where refreshing pivot tables caused unexpected behavior in related dynamic tables. The fix ensures that all dependent tables are properly invalidated during a pivot refresh, improving overall performance and stability. This change addresses a technical detail that enhances the user experience.
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
A recent update to the Odoo spreadsheet module caused issues with the pivot table drilldown feature, leading to crashes. This fix ensures that pivot cells can be displayed correctly, resolving a stability problem for users accessing livechart dashboards.
Original PR description
The helper `getNumberOfPivotFunctions` now requires the getters following a recent refactoring. This would cause crashes when we tried to determine if the drilldown of pivot cells could be displayed. How to reproduce: Go to the livechart dashboard and scroll a bit... Task-5969008 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where sample data continued to appear after creating new records in list views. The fix ensures that sample data is properly disabled when views are reloaded, providing a cleaner and more accurate display of data in the control panel. This improves the user experience by removing visual clutter.
Original PR description
Have a view (e.g. list) with no real records but sample data. In the control panel, have a button that, when clicked, creates new records which match the current filter, i.e. which are displayed…
Have a view (e.g. list) with no real records but sample data. In the control panel, have a button that, when clicked, creates new records which match the current filter, i.e. which are displayed directly in the UI. Before this commit, the new records were correctly displayed, but the sample data overlay (opacity) was still there. The problem came from the fact that the sample data are automatically disabled when the view is reloaded **from above** (typically from the WithSearch component, when the user interacts with the search view). However, in the faulty scenario, the `load` function of the model is called directly by the view itself, so we don't go through WithSearch, and the code of model.js that ensures that we leave the sample mode. We already faced that issue in pivot and graph, and we solved it locally. This commit fixes it globally, by creating a small override of model.load which leaves the sample mode. task~5980226 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the HTML editor's paste functionality by removing redundant code. Previously, the process of moving table headers (thead) into table bodies (tbody) was duplicated. This change, implemented through a refactoring, ensures a more efficient and reliable paste experience.
Original PR description
Description of the issue/feature this PR addresses: This PR removes duplicated logic in `cleanForPaste` that moves `thead` content into `tbody`. That behavior is already handled in insert (via `before_insert_processors`), so keeping it in `cleanForPaste` was redundant. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Odoo search bar on iOS devices (specifically with Korean keyboards) would incorrectly clear the input field during IME composition. The fix introduces a brief delay to account for iOS's temporary Backspace events triggered by the IME, ensuring the autocomplete remains open while Korean characters are typed.
Original PR description
Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in…
Safari does not reliably set `KeyboardEvent.isComposing` during IME composition (e.g. Korean). As a result, the search value was processed too early and got cleared while composition was still in progress. Interestingly, the issue could not be reproduced with the Japanese keyboard, which appeared to behave correctly. See [1]. This commit introduces a short delay before closing the autocomplete. On iOS, the IME temporarily triggers a Backspace event to remove the previously composed character before inserting the updated one. This Backspace incorrectly causes the autocomplete to close. With this change, we wait briefly (10ms) before closing it. If a new input event is received during that delay (corresponding to the newly composed character generated by the IME), the close action is cancelled. This ensures that the autocomplete remains open while the IME composition process completes. Steps to reproduce: - Configure a Korean keyboard on an iPhone - Open a Sale Order - Focus the search bar - Type a character, then type a second one to combine them - The search input value gets reset [1] #222151 opw-5448385 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251141
This update resolves an issue where the admin user wasn't automatically creating an employee profile since version 19.1. The change streamlines the process when using workorder functions, directly creating an employee profile without a prior search, ensuring consistent functionality.
Original PR description
Since 19.1, the admin user doesn't have an employee profile automatically created. So we added a way to create one rapidly when using workorder functions. For that, we want to make direct use of the employee created by action_create_employee without needing to do a search. see https://github.com/odoo/enterprise/pull/107439 task 5932500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the process of adding employees to work orders. Previously, the automatic creation of employee profiles was removed, causing issues for administrators. Now, a popup allows quick employee creation with the current user's ID pre-filled, and automatically creates an employee if none exist when editing shopfloor operators.
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
This update addresses a potential issue in the Swiss payroll reporting process. Specifically, it now displays a warning instead of an error when the 'AVS' (Authorized Value System) is negative, providing clearer guidance to users. This ensures accurate reporting and avoids potential disruptions to payroll calculations.
Original PR description
Forward-Port-Of: odoo/enterprise#109046
This update resolves a test failure caused by demo data interfering with the lot search functionality. We've implemented changes to ensure the test environment is clean, creating new data and avoiding conflicts with existing demo data. This ensures the test consistently passes and the lot search feature continues to function correctly.
Original PR description
The `test_lot_search_partner_ids` expects a specific number of lots/SNs to exist in the database in order to ensure its custom `partner_ids` search works correctly. Because of this, the test fails if any lot demo data is installed. Therefore we create all new locations, products, lots and add extra search domain fields to avoid loading any of these demo data. Also add in extra long partner name to avoid conflicts with overlapping demo/test partner names. runbot error: 162921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250783 Forward-Port-Of: odoo/odoo#220777
This update fixes an issue where the shipping weight for deliveries wasn't accurately calculated when products were placed into packages. The fix ensures that the total weight, including package weight, is correctly computed, improving the accuracy of shipping costs and order fulfillment. This resolves a bug related to how the system handles product weights within packages.
Original PR description
Steps to reproduce: - Enable “Packaging” in Inventory settings. - Create a storable product “P1” with: - weight: 10 kg - Create a delivery picking: - Add one unit of P1 - Mark as “To Do” - Set…
Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
- weight: 10 kg
- Create a delivery picking:
- Add one unit of P1
- Mark as “To Do”
- Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0
Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
- `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
- `pack.shipping_weight` is 0 on creation.
- The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13
opw-5357843
Forward-Port-Of: odoo/odoo#251216
Forward-Port-Of: odoo/odoo#238917This update corrects a bug that prevented inventory quantities from being properly deleted when set to zero. The fix ensures that when a quantity is reduced to zero, the corresponding inventory record is correctly removed, streamlining inventory management. This resolves a previous issue impacting accurate stock tracking.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Click on Quantity On Hand - Set the quantity to 10 and save - Set the quantity to 0 - Go back to the quant list view by clicking on Quantity On Hand - The quant is deleted by: https://github.com/odoo/odoo/blob/08015c2a15704b30c7815b62612b71b8970e3ac2/addons/stock/models/stock_quant.py#L1076-L1079 - Set the quantity to 10 again and save - Select the quant - Action > Set to 0 Problem: The function `action_set_inventory_quantity_zero` sets the current user on the quant even on inventory mode. This prevents the quant from being deleted when `_unlink_zero_quants` is called. opw-5906681 Forward-Port-Of: odoo/odoo#248881
This update resolves an error that occurred when generating payslips for employees who had changed contracts within a pay period. The fix ensures that the system correctly calculates employee work history by using the start date of the employee's initial contract, preventing errors related to holiday calculations. This improves the accuracy of payroll processing.
Original PR description
An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change Steps to reproduce: 1. Install l10n_mx and l10n_mx_hr_payroll modules…
An error is thrown when we try to generate a payslip for an employee that changed contract on a period before the contract change
Steps to reproduce:
1. Install l10n_mx and l10n_mx_hr_payroll modules
2. Switch to INNOVACION VALOR... company
3. Go to Employees and open Cecilia Miranda Sanchez
4. Go to Payroll tab, set the end of the contract to Jan 31 and save
5. Create a new contract from Feb 1
6. Go to Payroll > Payslips > Payslips and create a new pay run
7. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Bi-weekly' and Period 'Jan 1 -> Jan 15'
8. Click on Continue, select Cecilia and click on Select
9. An error is thrown
Problem:
In `_compute_integration_factor` we try to compute the number of years the employee has worked by accessing the start date on the employee but this date might be earlier than the start date of the employee's current contract if the employee has changed contract. This will throw an error when we try to access the holidays count for 0 year because `payslip._rule_parameter('l10n_mx_holiday_tables')` doesn't have an entry for 0
Solution:
Use the start date of the first contract of the employee, take gaps in between the employee's contracts into consideration to correctly compute the number of years worked
opw-5931355
Forward-Port-Of: odoo/enterprise#108495This update resolves an issue where stock reporting (Inventory / Reporting / Stock) displayed incorrect values due to a flaw in how the system identified the last product value. The fix ensures that the last product value is correctly determined based on the selected company, preventing inaccurate unit costs, total values, and on-hand quantities.
Original PR description
Before this fix, when searching for the last product value, we don't check the company. We search for the last product.value among all companies, even when only one company is selected. As a result, we end up with strange values when going to Inventory / Reporting / Stock. For instance, we may end up with: unit cost 10, total value 100, on hand quantity 0. OPW-5957947 Forward-Port-Of: odoo/odoo#251413
This update corrects a technical issue where salary inputs weren't properly duplicated when creating copies of selections. Previously, this prevented accurate payslip generation. The change ensures that salary input selections are correctly copied, resolving a potential data discrepancy and improving payroll accuracy.
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#106488
This update resolves a technical issue that caused the Point of Sale system to hang during startup. The fix ensures the indexedDB is correctly initialized and populated, preventing delays and guaranteeing a smooth POS launch. This improves the overall user experience for Point of Sale operations.
Original PR description
There were 2 issues when `serverDateTime` was lower than `lastConfigChange` which triggered a reset on the indexedDB. The first issue was that we would try to await dbInstance.deleteDatabase request.…
There were 2 issues when `serverDateTime` was lower than `lastConfigChange` which triggered a reset on the indexedDB. The first issue was that we would try to await dbInstance.deleteDatabase request. But it returns a request object and then executes the delete asynchronously. This would cause a race condition on the init where we would trigger the init of the indexedDB at the same time as we were trying to delete it and it would hang for ~10 seconds before finally launching the POS.
The second more important issue is that after the reset there is a `localData = []`. This would cause the line in `synchronizeServerDataInIndexedDB` `JSON.parse(JSON.stringify(serverData));` to return an empty array so no new models would get created in the indexedDB and the POS would launch with an empty indexedDB.
This commit changes the `indexed_db.reset()` method to return a promise and awaits it before reinitialising the indexedDB. And resets the `localData` to `{}` which fixes the `synchronizeServerDataInIndexedDB`
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246476This update corrects a technical issue that could cause inconsistencies in payroll payslip data. The change ensures that all related data is synchronized correctly, preventing potential errors in payroll calculations and reporting. This improves the reliability of our payroll system.
Original PR description
Forward-Port-Of: odoo/enterprise#109112 Forward-Port-Of: odoo/enterprise#108729
This update fixes an issue where fiscal positions were incorrectly applied to Brazilian customers, leading to errors when creating tasks. The change ensures that each customer's fiscal position is correctly associated with the company they belong to, resolving inconsistencies and preventing errors related to valid fiscal settings.
Original PR description
Issue ===== The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors. Steps to Reproduce ================== 1. Install…
Issue ===== The fiscal position defined on a partner was not properly isolated per company, leading to cross-company inconsistencies and errors. Steps to Reproduce ================== 1. Install `industry_fsm_sale` and `l10n_br`. 2. In the US company: - Create a Brazilian customer. - Set a fiscal position on the customer. 3. Switch to the Brazilian company: - Open the same customer. - Set a fiscal position on the customer. 4. Still in the Brazilian company: - Create a task for that customer in the Field Service app. - Add a product to the task. Result ====== An error is raised because the fiscal position from the US company is used, which is not valid for the Brazilian company. Root Cause ========== When reading the fiscal position from the partner, the value is fetched in the environment of the company in which the partner record was originally created (US company). If no company is explicitly specified, the fiscal position is read in that original environment, even when the user is operating under the Brazilian company. Solution ======== Explicitly enforce the current company context when reading the fiscal position from the partner to ensure the correct company-specific value is used. opw-5270522 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250115 Forward-Port-Of: odoo/odoo#249482
This update ensures that timesheet updates accurately reflect the cost of tasks associated with sales orders, regardless of the sales order's invoice policy (ordered_prepaid, delivered_manual, delivered_milestones). Previously, this calculation was inconsistent, leading to inaccurate cost reporting. This fix improves the reliability of sales order costing and timesheet tracking.
Original PR description
Originally, timesheet updates for tasks associated with sale order lines would cause the cost (purchase_price) to be recomputed. However, this was prevented if the invoice policy was 'ordered_prepaid.' This should also apply to 'delivered_manual' and 'delivered_milestones.' Otherwise, any timesheet updates will recompute the sales.order.line purchase_price field. Steps to reproduce: 1. Create a service product that creates a project/tasks 2. Create a sales order with the product and manually set the cost 3. Assign the timesheets of the task to an employee 4. Have the employee update their timesheet for the task 5. The cost on the sales order line gets recomputed to the default product price task-5902688 related-pr-205415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250495
This update corrects a bug that prevented physical gift cards from being created in the backend when multiple were added to a single Point of Sale (PoS) order. The fix addressed a misinterpretation of data keys, ensuring accurate gift card creation and tracking. This resolves a potential issue impacting order processing and gift card management.
Original PR description
When selling mutliple physical gift cards in the same PoS order, no gift cards were created. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on the gift card line and set a physical gift card with a value of 100€ * Add another gift card to the order * Click on the gift card line and set a physical gift card with a value of 50€ * Validate the order > Observation: No gift card is created in the backend Why the fix: ------------ When looking for the `oldChanges` we tried to retrieve the gift card code as `gift_code` but the key name is `code`. Because of this the `pointsCount` was wrong. opw-5928320 Forward-Port-Of: odoo/odoo#251339 Forward-Port-Of: odoo/odoo#249066
This update fixes an issue where dropshipped components to subcontractors were incorrectly categorized as expenses instead of stock valuation items. The change ensures these components are properly valued in the stock account, aligning with the 'ordered quantity' invoice policy. This improves accuracy in inventory tracking and reporting for subcontracting operations.
Original PR description
A component bought from a vendor and dropshipped to a subcontractor should the valued into the stock valuation account and not the expense one. In case this component have its "Invoice Policy" set to…
A component bought from a vendor and dropshipped to a subcontractor should the valued into the stock valuation account and not the expense one. In case this component have its "Invoice Policy" set to "ordered quantity", the `_eligible_for_stock_account` method will test if the related stock move are dropshipped https://github.com/odoo/odoo/blob/7436e0cfaf8d4b0c0e0390e8d6a3df404ba240f6/addons/stock_account/models/account_move_line.py#L31-L35 The value `is_dropship` is only set at the validation of the stock move. Due to the invoice policy, the receipt is not validated yet. close #243015 This commit will rather use the helper `_is_dropshipped()` that only rely on the location and not on the state. This commit also clean and reenable the related tests. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249134 Forward-Port-Of: odoo/odoo#245930
This update fixes an error that occurred when generating Argentinian tax reports (specifically ARBA profits reports) by ensuring the report filter correctly handles cases where no tax type is selected. The fix prevents a JavaScript error and ensures accurate report generation for these reports.
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 resolves an issue where taxes weren't correctly calculated during Google Pay (GPay) express checkout using Stripe. The fix ensures that Avatax taxes are accurately applied, aligning payment amounts with the final order total. This improves payment accuracy and prevents discrepancies between customer payments and the displayed price.
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 update fixes a minor inconsistency in the Documents app by ensuring that action names (like 'Vendor Bills') are dynamically set based on the type of account move being created. Previously, the action title was fixed to 'Invoices,' which wasn't always accurate. This change improves clarity and usability within the Documents app.
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 ensures the IEPS tax breakdown is correctly displayed on Mexican CFDI invoices, aligning with SAT regulations. Specifically, it now accurately shows IEPS based on whether the invoice is a 'global invoice' or uses tax object 07, addressing previous inconsistencies. This ensures accurate tax reporting for Mexican businesses.
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 allows managers to automatically launch appraisal campaigns for all their team members, even if they don't select individuals from a list. This simplifies the process for managers and ensures all employees are included in the appraisal cycle. The change includes new tests to verify the functionality.
Original PR description
. Allow the Leader to launch an appraisal campaign for all their employees by default when no specific employees are selected in the list. task-5347755 Forward-Port-Of: odoo/enterprise#100214
This update fixes an error in how Odoo calculates worked days for employees without contracts or when contracts don't align with pay periods. The change ensures accurate attendance and out-of-contract day tracking, particularly for employees starting or ending contracts mid-month. This improves payroll accuracy and reporting.
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#109103 Forward-Port-Of: odoo/enterprise#103207
This update simplifies the salary simulator by hiding temporary offers from the user interface. These offers are automatically removed after a month by a scheduled task, so this change only improves clarity and prevents user confusion. It ensures a smoother experience when using the salary configuration tool.
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#109241 Forward-Port-Of: odoo/enterprise#107340
This update resolves a crash issue that occurred when viewing pay runs on mobile devices with smaller screens. The fix ensures the system correctly identifies and interacts with the pay run Kanban view, preventing unexpected errors and improving overall stability. This update is a critical fix for users accessing payroll data on mobile.
Original PR description
**Steps to Reproduce:** 1. Open Payroll->Payslips->Pay Runs 2. Click on a Pay Run in Mobile View (Width < 600px). 3. Return to the previous view using the breadcrumb. 4. The system crashes with…
**Steps to Reproduce:** 1. Open Payroll->Payslips->Pay Runs 2. Click on a Pay Run in Mobile View (Width < 600px). 3. Return to the previous view using the breadcrumb. 4. The system crashes with Traceback: TypeError: Cannot set properties of null (setting 'scrollLeft') **Bug Cause:** The custom 'hr_payroll.PayrunKanbanRenderer' template overrode the 'class' attribute of the root div. By setting it only to 'o_payrun_kanban', the standard 'o_renderer' class was removed. The Kanban controller's scroll restoration logic (introduced in recent lazy-loading updates) relies on the '.o_renderer' selector to find the scrollable container. When missing, querySelector returns null, leading to a traceback. **Solution:** Updated the XML template to explicitly include 'o_renderer' in the class list. This restores the functional hook required by the JavaScript controller for scroll restoration while maintaining the custom 'o_payrun_kanban' layout. Task: 5971861 Forward-Port-Of: odoo/enterprise#108847
This update fixes a hidden error in the Point of Sale system that prevented invoice generation when an untrusted bank account was used. Previously, users wouldn't receive any explanation of the issue. Now, a popup will clearly identify the problem, such as an untrusted bank account, guiding the user to correct the setup.
Original PR description
Steps to reproduce: - Add untrusted bank account to the database's selected company's contact - Finalize an order in point of sale through register - While in register, go to orders and click on the invoice button for the finalized order Current behavior: - There is no indication of why you can't generate an invoice Expected behavior: - There should be a popup to the user identifying the error (e.g. untrusted bank account) This addresses a side effect of: https://github.com/odoo/odoo/pull/248108 opw-5946239 Forward-Port-Of: odoo/odoo#251197 Forward-Port-Of: odoo/odoo#249558
This update ensures that B2C customers in Taiwan requesting a paper invoice during guest checkouts correctly skip the "Invoicing Info" step. Previously, a technical issue prevented the system from recognizing this preference, but this fix now accurately saves and applies the paper invoice option, improving the customer experience.
Original PR description
In Taiwan e-invoicing, B2C customers can request a paper copy of their invoice. When selected, the "Invoicing Info" step—which collects data like donation codes or carriers—should be skipped as it is…
In Taiwan e-invoicing, B2C customers can request a paper copy of their invoice. When selected, the "Invoicing Info" step—which collects data like donation codes or carriers—should be skipped as it is not applicable to physical copies. Previously, this logic failed during guest checkouts because the partner initially associated with the order is an archived public user. The persistent partner is only created/assigned after the address form is submitted. This commit: - Overrides `_create_or_update_address` instead of `_handle_extra_form_data` to ensure the paper format preference is saved on the correct, newly generated partner. - Updates `_prepare_address_form_values` to correctly load existing preferences from the partner for registered users. - Ensures the `l10n_tw_edi_is_print` flag on the Sales Order stays in sync with the partner's preference. Task-5912985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250651 Forward-Port-Of: odoo/odoo#247961
This update fixes an issue where custom messages in website shop pages were being lost after saving. The change removes a cleanup process that incorrectly removed these messages during the website page save. Now, custom dropzone messages are correctly preserved after saving website pages.
Original PR description
Steps to reproduce: - Open the website shop page in edit mode. - Drag and drop a block in the shop header dropzone. - Save the page and re-enter edit mode. - Check the shop header dropzone message.…
Steps to reproduce: - Open the website shop page in edit mode. - Drag and drop a block in the shop header dropzone. - Save the page and re-enter edit mode. - Check the shop header dropzone message. => The custom message is replaced by the default one. Before this commit, `SetupEditorPlugin.cleanForSave()` removed `data-editor-message` and `data-editor-message-default` on the saved HTML clone, including custom messages defined in website templates. This cleanup was originally introduced in `web_editor` in [1]. Since the builder refactor in [2], website page saves now use the shared `html_builder` save cleanup flow and wrongly inherited that behavior, which introduced this regression in website. This commit removes that cleanup from `html_builder`, as it does not provide useful value in this save flow and drops custom dropzone messages. After this commit, custom dropzone messages are preserved after saving website pages. [1]: bab673488e185ddd7792aedecc3870663290fed3 [2]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5921283 Forward-Port-Of: odoo/odoo#251579 Forward-Port-Of: odoo/odoo#250874
This update fixes a data issue in the Danish (DK) demo company data within Odoo. Specifically, the street number was missing, which was preventing proper functionality with Nemhandel (the Danish e-commerce payment system). This ensures accurate data for testing and demonstration purposes.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task Forward-Port-Of: odoo/odoo#250970
This update fixes an issue where tip and discount amounts in the Point of Sale system were not correctly formatted when using a different decimal separator. This ensures users see accurate tip and discount calculations, reducing potential confusion and improving the user experience. The change was made to align with standard decimal formatting practices.
Original PR description
Before this commit, when the decimal separator was not a dot, the amount in the tip and the discount number popup was not correctly formatted, which could lead to confusion for the user. opw-5921256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248232
This update fixes inaccuracies in the Bulgarian tax settings within the Odoo accounting system. Specifically, it corrects incorrect tax names and changes the default purchase tax rate to 20% FTC, aligning with current Bulgarian regulations. This ensures accurate tax calculations and reporting for Bulgarian businesses using the Odoo system.
Original PR description
Fixing incorrect tax names and changing the default purchase tax to 20% FTC instead of 20% PTC. task-5935754 Forward-Port-Of: odoo/odoo#251593 Forward-Port-Of: odoo/odoo#249269
This update resolves an issue where related fields within many2one chains were incorrectly displaying the wrong related model. Specifically, when two fields with the same name were used in a chain, the popover would show incorrect field options. This change ensures accurate field selection during related field creation.
Original PR description
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if…
You cannot create a related field with a related field chain that has two or more fields with the same name in a row. When you click the relation icon for a field the wrong model will be displayed if the related model you are trying to show has a many2one with the same name as the field that was selected. Steps to reproduce 1. Create two many2one fields with studio that have the same name, one of the fields must link to the model the other field is on. i.e. `model_a.x_studio_test(relation=model_b), model_b.x_studio_test(relation=other_model)`. 2. Create a related field on model_a and click the related icon for the test field. 3. The popover will now be displaying the fields for other_model instead of model_b. Cause: This behavior was introduced by adding support for properties in this [pr](https://github.com/odoo/odoo/pull/189841). Solution: Check if `fieldDef` is a property or not in order to decide what to pass to `loadPath`. opw-ticket 5459944 Forward-Port-Of: odoo/odoo#249185
This update resolves an issue where product variant pricelists were incorrectly storing data after a rule was removed. Specifically, the ‘product_tmpl_id’ field wasn't being reset, leading to data inconsistencies. The fix ensures that the data is properly updated when a pricelist rule is deleted, maintaining accurate product pricing information.
Original PR description
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to…
Steps: - Create a price list (or existing one) - Create (or find) a product with only one variant - Add price list rule for that variant (Should show as Variant:... in Pricelist listing) - Go to pricelist listing, select the pricelist - Edit price list rule - Remove the product - Save and check the data (applied_on, product_id, product_tmpl_id) (applied_on still 0_product_variant, product_id, and NO product_tmpl_id) Related ticket: opw-5411034 (Video: https://drive.google.com/file/d/1xmg9A9NgavFQkIFkUZrzuAxVF-PNqdnL/view) Description of the issue/feature this PR addresses: Fix corrupted data <img width="583" height="108" alt="image" src="https://github.com/user-attachments/assets/961e75f8-b2a6-4812-a0b4-d73e02d52b08" /> Current behavior before PR: product_tmpl_id set to None product_id / applied_on data stays the same Desired behavior after PR is merged: When product_tmpl_id is removed, reset the applied_on type back to 3_global --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250531 Forward-Port-Of: odoo/odoo#249417
A slow process for adding attribute values to products was identified and resolved. The update utilizes more efficient database searching techniques, reducing the loading time from 8 minutes to 2-3 minutes. This improves the overall user experience for customers managing complex product configurations.
Original PR description
opw-4876370 Issue: A customer who uses many attribute values complained that the "add to products" button on product attribute values in their database was really slow (8 minutes or so). Upon investigation I found parts of the involved functions used iteration over a set of records, which proved notably slower to psql searches. Fix: Replacing the code with what I believe is equivalent operations making use of the `search` method to filter through the sets much quicker. Behaviour after fix: The process takes 2-3 minutes when running this commit on the aforementioned database, but it's still a major improvement compared to the previous time. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251571 Forward-Port-Of: odoo/odoo#232149
This update fixes an issue where landed costs weren't correctly applied to subcontracted products, resulting in inaccurate product valuations and missing journal entries. The fix ensures landed costs are properly linked to the subcontracted manufacturing order, leading to accurate valuation updates and the creation of necessary account move lines.
Original PR description
…bcontracted **Problem:** Landed cost added on the receipt of a subcontracted product do not increase the valuation of the product and do not create account move lines. **Steps to reproduce:** -…
…bcontracted **Problem:** Landed cost added on the receipt of a subcontracted product do not increase the valuation of the product and do not create account move lines. **Steps to reproduce:** - create a tracked product with avco perpetual category - create a subcontracted bom for this product with no comp - create and confirm a PO for 10 unit of this product at a unit price of 1$ with the same partner as the subcontractor of the bom - validate the receipt - navigate to inventory/operations/adjustments/landed costs - create a new landed cost - select the receipt from the PO - add a landed cost of 10$ and validate - navigate to inventory/reporting/stock - search for your product and click on the unit cost **Current behavior:** 1) the valuation of the product was not increased by the value of the landed cost 2) open journal items : no account move lines were created for the landed cost **Expected behavior:** 1) the valuation of the product should have been increased: in the unit cost view, the SBC move should have gone from a value of 10 to 20 2) account move lines should have been created with a value of 10 **Cause of the issue:** both issues come from the fact that when creating the stock valuation adjustment line, the move linked is the receipt move when it should be the move of the subcontracted MO linked to the receipt. **fix:** if we create the adjustement line with move_id as the move of the MO (instead of the move of the receipt as it is the case currently) : when button_validate is called on the landed cost : - when using the remaining quantity, it will be the correct one (in our case 10, instead of 0 for the move of the receipt because it's actually an internal move) so the account move line are going to be created https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L129-L130 https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_landed_cost.py#L372-L373 which solves problem 2) - when calling _set_value on the move (which will be the move of the MO thanks to this fix), https://github.com/odoo/odoo/blob/064407d32f998ceb08601f9e0a6356c94ad10347/addons/stock_landed_costs/models/stock_landed_cost.py#L152 get_value_data will call _get_value_from_extra, https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_account/models/stock_move.py#L392 which uses _get_landed_cost to fetch the landed cost https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L18 before this fix the landed cost created from the receipt were linked to the receipt move so they were not fetched inside _get_landed_cost which caused problem 1) but now the move_id of the adjustment lines is the move of the MO so they are fetched inside _get_landed_cost https://github.com/odoo/odoo/blob/9c85d7265d7b1ca0b212f46c20aa1e8119c33a22/addons/stock_landed_costs/models/stock_move.py#L7-L12 So now the adjustment lines do impact the valuation of the move of the MO which solves problem 1) opw-5723126 Forward-Port-Of: odoo/odoo#248469
This update fixes an issue where modifying production quantities in a Manufacturing Order would incorrectly create duplicate work orders. The change ensures that work orders are correctly updated instead of duplicated, maintaining accurate production tracking. This improves the reliability of the MRP process.
Original PR description
Steps to reproduce: 1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty). 2. Create a Manufacturing Order (MO) for the product selecting BoM A. 3. Switch BoM A to BoM B, then…
Steps to reproduce:
1. Create a product and two BoMs: BoM A (with operations) and BoM B (empty).
2. Create a Manufacturing Order (MO) for the product selecting BoM A.
3. Switch BoM A to BoM B, then switch back to BoM A.
4. Modify the production quantity field. -> New operation lines are appended every time the quantity is changed.
The issue occurred because _compute_workorder_ids used 'wo.ids' to filter existing workorders. In the "Draft" state (UI/onchange), records exist as "virtual records" (NewIds). For these records, .ids returns an empty list [], which evaluates to False in Python.
Consequently, the existing virtual workorders were filtered out of the dictionary used to map operations to existing lines. The logic assumed the lines didn't exist and used Command.create() instead of Command.update(), causing duplication. Similar issues existed where 'NewIds' were ignored during BoM swaps, leaving "phantom" records in the cache.
Solution:
Removing the '.ids' check and using '.mapped('id')' ensures the computation remains "virtual-aware" and stable across sequential onchanges.
TECHNICAL JUSTIFICATION:
In Odoo 18.0, the ORM explicitly supports using Command.update and Command.delete with virtual records (NewIds) without an origin. This is handled by the 'write_new' method in relational fields:
- Virtual browse wraps IDs in NewId: https://github.com/odoo/odoo/blob/f688c6b66310438fa3e36a207770a63d0d8fffa5/odoo/fields.py#L4826-L4855
opw-5489862
Forward-Port-Of: odoo/odoo#246995This update corrects a bug where the standard price of dropshipped products wasn't updated when the bill price differed from the original purchase order price. The fix ensures that the product's standard price accurately reflects the actual billing amount, improving inventory accuracy for dropshipping scenarios. This was triggered by a validation step in the dropship move process.
Original PR description
**Problem:** When Billing a dropshipped PO, if the price of the bill is changed from the price of the Purchase Order, the standard price of the product is not updated **Steps to reproduce:** - enable…
**Problem:** When Billing a dropshipped PO, if the price of the bill is changed from the price of the Purchase Order, the standard price of the product is not updated **Steps to reproduce:** - enable the dropshipping settings - create a storable product with avco perpetual category - in the inventory tab, select the dropship route - in the purchase tab, set a vendor - create and a confirm a quotation for this product - on the linked purchase order, set a unit price of 100$ and confirm - validate the dropship move (- you can check on the product form that the standard price is now 100$) - create a bill for the purchase order - set the price to 90$ and confirm - navigate to the product form **Current behavior:** The standard price is still 100$ **Expected behavior:** It should be 90$ **Cause of the issue:** When we validate the picking, action_done() is called on the moves . Inside the action_done() override of stock_account, after the call to super, set_value is called on is_in and is_dropship moves https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L168-L169 Inside _set_value(), because the move is dropship, it's going to be added to products_to_recompute https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L277-L278 and then we're going to exit this iteration of the for loop. https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/stock_move.py#L285-L286 so basically we simply call the _update_standard_price() on the product. https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/stock_move.py#L310 Because the product is avco, _update_standard_price is going to call _run_average_batch https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/product.py#L541 The value is not set on the dropship move but it's still used in the computation because for dropship move, we use _get_value() https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/product.py#L382-L383 which will take into account the bills and POs if there are some. But the problem is that, when we post the invoice we only call set_value on is_in moves https://github.com/odoo/odoo/blob/3670c83f1e59d79df439be7c23a679d4d988ec20/addons/stock_account/models/account_move.py#L42 So the standard price of our dropshipped product is not updated. opw-5498878 Forward-Port-Of: odoo/odoo#250067
This update corrects a bug in the self-order module where the selected time slot was unreliable due to timing issues. The fix now explicitly defines the desired time slot and verifies its availability after selection, ensuring accurate scheduling and preventing incorrect bookings. This improves the reliability of the self-order functionality.
Original PR description
The selected time slot was not the right one as the time of the execution influed on the first choice available. We now specify which time slot to take, and check that this specific timeslot is not available anymore afterwards. runbot-233381 Forward-Port-Of: odoo/odoo#233469
This update resolves a server error that occurred when deleting mailings associated with marketing activities. The fix ensures a user-friendly error message is displayed instead of a crash, guiding users to correct the activity's links to mailings. This improves the overall stability and usability of the Marketing Automation feature.
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
This update corrects a visual inconsistency in Odoo forms. Previously, the favorite star icon didn't match the heading font size, appearing at a smaller size. This change ensures all icons, including the favorite star, consistently align with the heading styles for a more polished and professional user experience.
Original PR description
Steps to reproduce:
Open a form with a favorite star in .oe_title (e.g. Product form). The star icon appears at body size (1rem) instead of matching the heading font size.
The <a> -> <button class="btn btn-link btn-link-inline"> refactor broke the size: .btn-link-inline sets --bs-btn-font-size to body size, so the existing .o_favorite i.fa { font-size: inherit } rule inherited 1rem from the button instead of the heading size.
Solution:
Add .o_favorite .btn to the font-size: inherit rule so the heading size cascades through the button to the icon.
opw-5998155This update corrects a bug that prevented users with RTL languages (like Arabic) from dragging and dropping content outside of designated dropzones. The fix adjusts the detection logic to account for the left-aligned sidebar in RTL layouts, ensuring proper functionality. This improves usability for a wider range of users.
Original PR description
When dropping outside a dropzone but still on the page, the code checks if the drop happened well outside of the sidebar (so on its left). However, in RTL languages, the sidebar is positioned on the left, so we need to check if the drop is on the right side of it instead. The fix checks if the sidebar is at the left edge (the body of the document should have the `o_rtl` class) and verifies the drop position is on the right of the sidebar. Steps to reproduce: - Set your profile to Arabic - Drag and drop a snippet outside of a dropzone => It's not dropped, but it should, as it would with an LTR language. task-5484936 Forward-Port-Of: odoo/odoo#251041 Forward-Port-Of: odoo/odoo#247759
This update resolves a technical issue that was causing errors in the mail composer and report generation when exporting invoices in certain UBL transactions. The fix ensures that the system doesn't attempt to access invoice date information when an invoice isn't present, preventing crashes and maintaining normal functionality.
Original PR description
### Description of the issue/feature this PR addresses: A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery…
### Description of the issue/feature this PR addresses:
A regression in account_edi_xml_ubl_bis (_ubl_get_delivery_node_from_delivery_address) references invoice.invoice_date in the intracom delivery branch even when invoice is not set.
This method is also used in sale-order UBL export flows (for example during quotation PDF generation from mail.compose.message), where vals.get('invoice') can be None.
Blame points to regression introduction in commit 0bf8df7d0a096cf8fe984c42d331404d473eeb71 (FP from f6c5aed52e00e807c4879e4139b116f1bea8282e).
### Current behavior before PR:
When the flow reaches sale-order BIS3 export without an invoice in vals, Odoo crashes with:
AttributeError: 'NoneType' object has no attribute 'invoice_date'
This raises an RPC_ERROR and breaks the mail composer / send flow
### Desired behavior after PR is merged:
The intracom delivery-date override is only applied when invoice exists and has invoice_date.
If invoice is missing (sale-order export context), no crash occurs, the delivery node is still generated safely, and mail composer/report generation completes normally.
Invoice export behavior remains unchanged for valid invoice contexts.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250167This update resolves a bug in the BR invoice processing cron job. Previously, the job processed all invoices at once, leading to failures and wasted IAP credits. Now, the cron job 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 pull request addresses several issues within Odoo's testing framework, primarily focused on improving test reliability and debugging. Key changes include automatically clearing test caches, enhancing error reporting, and refining keyboard handling to ensure accurate test execution.
Original PR description
Fixes for tests and testing framework. See commit messages for details. Enterprise: https://github.com/odoo/enterprise/pull/107286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251667 Forward-Port-Of: odoo/odoo#247137
This update resolves a problem where tests were failing due to incorrectly triggered event handlers. The fix ensures that test environments are properly cleaned up, preventing potential issues with resource usage and improving the stability of our core system. This change focuses on internal testing improvements.
Original PR description
Adapt tests failing due to keydown events being applied to the current active element. Community: https://github.com/odoo/odoo/pull/247137 Forward-Port-Of: odoo/enterprise#109316 Forward-Port-Of: odoo/enterprise#107286
This update resolves an issue preventing multiple tax lines on Italian invoices processed through the l10n_it_edi_doi module. Previously, only the DOI tax could be added. Now, other taxes like Enasarco and RIT can be included on the same line, aligning with Italian invoicing practices. This ensures accurate tax reporting for Italian businesses.
Original PR description
We should be able to add more taxes with the 0% on the same line, like the Enasarco and 23% RIT. Indeed in italy it is possible to have invoices with Dichiarazione d'intento togheter with a withholding and Enasarco taxes. See also: odoo/odoo#236251 Ticket [link](https://www.odoo.com/odoo/project.task/5933699) opw-5933699 Forward-Port-Of: odoo/odoo#248586
This update resolves a technical issue within the Odoo Enterprise HR payroll module that prevented users from editing date inputs in a tour. The fix ensures the popover is displayed before the input field is cleared, restoring full functionality. This improves the user experience for payroll configuration.
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 resolves an issue where certain WebSocket routes were unintentionally causing user sessions to expire. By preventing session rotation for these specific routes, we ensure a smoother and more reliable experience for users. This improves stability and reduces potential disruptions.
Original PR description
Before this commit, calling `/websocket/peek_notifications` or `/websocket/update_bus_presence` could rotate the session. Since those routes are not called by the client, the cookie is unchanged on the client side, leading to expire sessions error later on. This commit ensure we won't rotate the sessions for those routes. opw-5445323 Forward-Port-Of: odoo/odoo#251496 Forward-Port-Of: odoo/odoo#250826
This update resolves an issue where the cash drawer wasn't opening when the cash details popup was accessed in the Italian Point of Sale (POS) system. The fix ensures that the cash drawer opens consistently, regardless of the printer type, improving the user experience for Italian POS operations. This was a simple missing function call.
Original PR description
When opening the cash details popup the cash drawer should be opened. It was not the case for the Italian fiscal printer. Steps to reproduce: ------------------- * Setup a Italian fiscal printer with cash drawer support * Open PoS * Open the cash details popup > Observation: The cash drawer does not open * Try to close the PoS session * Open the cash details popup > Observation: The cash drawer opens Why the fix: ------------ The cash drawer opening function was simply not called opw-5391094 Forward-Port-Of: odoo/enterprise#109155 Forward-Port-Of: odoo/enterprise#107987
This update fixes an issue where time formatting in reports and lists was inaccurate, consistently flooring the time value. The changes ensure time is rounded correctly based on its precision and allows for more flexible formatting options, including controlling the display of seconds.
Original PR description
The rounding of time was not correct. I was always flooring, but before the new duration the rounding was depending of the precision of the duration. The rounding has been restored as before and put…
The rounding of time was not correct. I was always flooring, but before the new duration the rounding was depending of the precision of the duration. The rounding has been restored as before and put in formatDuration. formatFloatTime has been modified to use formatDuration and now take the same options (specify the unit of time of the value). The graph view and list view didn't extract the otpions from the fields with widget. Now, they get the options and give them to the formatter. The widget was showing the seconds by default, but it doesn't match with the behavior of the DateTime widget. It has been changed and now the seconds are shown only if the options 'showSeconds' is true and it's false by default. The impacted views has been restored as before the original commit. The options of float_time widget couldn't take falsy values, now it can. an improvment has also been done: the popover on the float_time widget doesn't show up if the input value and the formattedValue are the same. followup of TASK-5347051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where time formatting was inaccurate, particularly in graph and list views. The changes ensure time is displayed correctly, allowing for precise reporting and scheduling, and provides more flexible options for displaying time values.
Original PR description
The rounding of time was not correct. I was always flooring, but before the new duration the rounding was depending of the precision of the duration. The rounding has been restored as before and put…
The rounding of time was not correct. I was always flooring, but before the new duration the rounding was depending of the precision of the duration. The rounding has been restored as before and put in formatDuration. formatFloatTime has been modified to use formatDuration and now take the same options (specify the unit of time of the value). The graph view and list view didn't extract the otpions from the fields with widget. Now, they get the options and give them to the formatter. The widget was showing the seconds by default, but it doesn't match with the behavior of the DateTime widget. It has been changed and now the seconds are shown only if the options 'showSeconds' is true and it's false by default. The impacted views has been restored as before the original commit. The options of float_time widget couldn't take falsy values, now it can. an improvment has also been done: the popover on the float_time widget doesn't show up if the input value and the formattedValue are the same. followup of TASK-5347051
This update resolves a bug that prevented users from creating new resources within appointment bookings. The issue stemmed from an incorrect default value being set for the resource timezone, triggering a validation error. The fix ensures a proper timezone is assigned, preventing this error and improving the appointment booking process.
Original PR description
Steps to reproduce =============== 1. Open appointment of resource type 2. Create a new resource from resource tags. 3. Give the resource a name and save. ----> ValidationError will be shown. Issue…
Steps to reproduce =============== 1. Open appointment of resource type 2. Create a new resource from resource tags. 3. Give the resource a name and save. ----> ValidationError will be shown. Issue ===== When creating the new resource from the appointment form view, the value for the `tz` of the `appointment.resource` is `False`. Also, `tz` field is inherited from `resource.mixin` and is a related field as `resource_id.tz`. Therefore, when creating the `appointment.resource` with `tz` as `False` writes the related `resource.resource`'s `tz` field. As `tz` field is required field for the `resource.resource` table, the `ValidationError` is raised. Solution ======= After this commit, we give the default value to the timezone with fallback to current user's timezone or UTC which matches to the default value of `resource.resource`'s timezone field but with a side-effect of overwriting resource's timezone if somehow `default_resource_id` is provided. We also fix in parallel by making the timezone field `readonly` when invisible to avoid "saving" the `False` value for the tz. Task-5712786
This update resolves a technical issue preventing users from correctly selecting a cashier when opening the Point of Sale (POS) system. The problem stemmed from a renaming of a variable without corresponding updates, causing an error. This fix restores the original variable name, ensuring proper POS functionality.
Original PR description
Since this commit: https://github.com/odoo/enterprise/commit/52e2f216528bcb0e67844ac2164f647fee4a2a95 The clockState variable was renamed without modifying the other references. This causes a traceback when trying to select a cashier while opening the POS. This has now been fixed by restoring the previous variable name. Forward-Port-Of: odoo/enterprise#108665
This update resolves an issue where foreign vendor VAT invoices were not correctly identifying the country of origin for JPK reports. The fix adds the necessary country code to vendor bills, ensuring accurate reporting and compliance with Polish tax regulations. This improves the reliability of financial data.
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 fixes an issue where the 'Request Signature' option wasn't consistently appearing on form views, specifically within Timesheets and Projects. The change ensures the menu item only shows when a chatter is present, improving the user experience and ensuring all users can access this important feature.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423 Forward-Port-Of: odoo/enterprise#109274 Forward-Port-Of: odoo/enterprise#97401
This update ensures that disabled user records are no longer incorrectly flagged as blacklisted when checking email communication. This prevents potential issues with email delivery for users who have been deactivated in the system. The change was made to address a previous bug and includes new tests for verification.
Original PR description
Same as https://github.com/odoo/odoo/pull/249466, but for v17 and with tests. > When computing wether the user is blacklisted, disabled records must be ignored. > > https://www.loom.com/share/41ea437477f8416f8b50f9ef979d82bf > > > --- > I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr > > @moduon MT-13153 OPW-5952301 Forward-Port-Of: odoo/odoo#250361
This update corrects a bug where internal users receiving ‘Signed Document’ emails were incorrectly directed to the public portal. Now, internal users automatically see the document preview, while the existing portal redirection for public users remains unchanged. This ensures a consistent and correct experience for all users.
Original PR description
Internal users opening the “Signed Document” email link were redirected to the portal instead of the document preview. Now they are redirected to the internal preview, while public users remain unchanged. task-5486043 Forward-Port-Of: odoo/enterprise#107079
This change corrects a display issue where upsell sale orders created from subscriptions incorrectly showed as "Quotation" in the preview. The fix ensures that upsell orders now display as standard sales orders, aligning with the presentation of the initial subscription. 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#106767This update resolves an issue where stock users with 'Own Documents Only' sales access were unable to open delivery orders. The fix avoids unnecessary access restrictions by computing the delivery description directly, rather than relying on complex rule configurations. This ensures stock users can perform their tasks without encountering access errors.
Original PR description
### Steps to reproduce: - Create a Stock User with access rights: - Sales: User: Own Documents Only - Inventory: User - With your admin: Create and confirm a sale order for 1 x a consumable. - With…
### Steps to reproduce:
- Create a Stock User with access rights:
- Sales: User: Own Documents Only
- Inventory: User
- With your admin: Create and confirm a sale order for 1 x a consumable.
- With the Stock User open try to open the delivery
#### > Access Error: Uh-oh! Looks like you have stumbled upon some top-secret records.
### Cause of the issue:
Sale users `Own Documents Only` are granted read access to the `sale.order` model which is restricted to the `sale.order`'s to which they are the designated sale person or no-one is due to this `ir.rule`: https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale/security/ir_rules.xml#L44-L49 However, the read access of the sale order related to a stock move is required in order to compute its desciption:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/models/stock.py#L26-L31 While this access is suppose to be provided:
https://github.com/odoo/odoo/blob/d038b2c23b9f7c74d381e25276d00155bf89331e/addons/sale_stock/security/ir.model.access.csv#L5 It is overriden by the `ir.rule`.
### Fix:
Since the `_compute_description` overrides rely on numerous independant models such as the `sale.order`, `purchase.order.line`, `product.supplierinfo`, `mrp.bom`, since the `picking_description` does not really carries sensitive informations and since parts of the computes already required to be put in `sudo` for similar reasons see 80c80505fabc4544e41f270169737218e47cad5a, it is preferable to compute the field in sudo rather than adding an `ir.rule` with true leaf on the `sale.order` model for the `stock.group_stock_user`.
opw-5929485
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251471This update fixes an issue where users would need to refresh the application after installing a new language. The change clears all application caches when a language is installed, ensuring the new language is immediately available in the user preference settings. This provides a smoother and more intuitive experience for users.
Original PR description
Before this commit, after installing a new language, that language wasn't directly available in the selection field of the user preference form view. An extra reload was necessary to see the new language, which could confuse the user. This was due to the cache. As installing a language isn't a frequent operation, we simply clear all caches when this happens. task~5895416 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251729
This update fixes an issue where long email addresses in the Point of Sale partner list were difficult to read due to awkward wrapping and inconsistent alignment. The changes include truncating long emails and adding a hover-over feature to display the full email address, ensuring a cleaner and more user-friendly experience.
Original PR description
Before this commit, long email addresses in the POS partner list would wrap awkwardly or expand the row height excessively, making the list difficult to read. Additionally, the vertical alignment between the text and the action buttons was inconsistent. This commit improves the Partner List UI by: - Truncating long email addresses - Adding a `title` attribute so the full email is visible on hover - Vertically centering all cell content to match the buttons. opw-5919153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247964
This update corrects inaccuracies in the XML files used for Swedish SEPA payments. Specifically, it ensures BIC numbers are used instead of incorrect 'Bankgiro' codes and allows users to manually select the payment version, regardless of SEPA payment method selection. This improves payment processing accuracy and flexibility for Swedish customers.
Original PR description
We currently have customizations for the iso20022 xml file for payments in Sweden. But those customizations aren't correct. This commit fix multiples issues: 1) In DbtrAgt, we sometimes have bankgiro information. But this node should always contain the BIC number for Swedish payments. 2) The _get_cleaned_bic_code method was replacing the real bic code with a fake value like 'SE:Bankgiro', but this seems to be wrong. None of the SE banks ask for this BIC, so we remove it. 3) The sepa_pain_version field is supposed to tell Odoo which pain version to use. But the problem is this field is computed, and only editable once the user set the SEPA payment method, but for iso_se, we want to let the user choose as well, even if he didn't add SEPA as payment method. This commit change the invisible on the field, so it can be edited as soon as iso_se is in the journal payment methods. task-5427570 Forward-Port-Of: odoo/enterprise#105536
This update resolves a bug where approval rules for account moves in Web Studio would incorrectly activate a related list view action. The fix ensures that list view actions linked to approval rules are automatically deactivated, preventing unintended actions and improving the reliability of the approval process. This change enhances the overall stability and usability of Web Studio.
Original PR description
Following commit odoo/odoo@c442f72479b50855f40ba079800ee9e5a5690753 When putting an approval rule action_post (account.move) the action bound to the list view must be deactivated. opw-5921128 Forward-Port-Of: odoo/enterprise#106853
This update resolves an issue preventing users from modifying rounded corner settings in the website editor when using themes with unitless '0' values for border-radius. The fix ensures the editor correctly handles these values, allowing for seamless customization of rounded corners across different themes. This improves the user experience and flexibility of theme customization.
Original PR description
**Problem:** When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the…
**Problem:**
When using themes that define border-radius as unitless `0` (e.g., Anelusia theme) and attempting to modify the "Rounded Corners" value of any element through the website editor, the following error occurs: "Cannot convert 'px' units into '' units !"
**Steps to reproduce:**
1. Install and activate the Anelusia theme (or any theme with unitless border-radius: 0)
2. Open the website editor
3. Select any element (e.g., a table in the footer)
4. Try to change the "Rounded Corners" field to any non-zero value
5. Observe the error: "Uncaught Promise > Cannot convert 'px' units into '' units !"
**Current behavior:**
The website editor throws a JavaScript error and prevents changing rounded corners.
**Expected behavior:**
Users should be able to modify rounded corners values without errors, regardless of whether the theme uses unitless or unit-based zero values.
**Cause of the issue:**
Some themes define border-radius variables as unitless `0` (e.g., `$border-radius: 0`). When the website editor's areCssValuesEqual() function in utils_css.js compares the new value (e.g., "10px") with the existing computed value ("0" - unitless), it attempts to convert between units. The getNumericAndUnit() function extracts the unit from "0" as an empty string "", then convertValueToUnit() tries to convert "10px" to "" unit. Since there's no conversion defined for "px" to "" (empty unit), convertNumericToUnit() throws the error.
**Fix:**
Add a special case in areCssValuesEqual() to handle unitless zero values before attempting unit conversion. When the first value is unitless "0", we compare the numeric values directly using Number.EPSILON, avoiding the unit conversion entirely. This allows proper comparison between unitless "0" and values like "10px" or "0px" without errors, while maintaining correct equality checks (0 equals 0px, but 0 does not equal 10px).
opw-5412414
Forward-Port-Of: odoo/odoo#246335This update resolves an issue where custom reports, built using specialized models, were causing Studio to crash. The change prevents Studio from attempting to access this data, ensuring a smoother and more stable Studio experience for users.
Original PR description
…eport Some report build their data via a report model. Those are often tailor made to their business use cases and may crash when entering studio. This commit prevents this Forward-Port-Of: odoo/enterprise#107229
This update resolves an issue where the Sendcloud shipping API required a minimum product weight of 0.00099. This commit ensures that product weights are always at least 0.001, preventing errors and ensuring accurate shipping calculations through the Sendcloud integration. It's a necessary adjustment to maintain reliable delivery processing.
Original PR description
The Sendcloud API do not allow parcel details to have a weight value less than 0.00099 . This commit makes sure the products weights are at least 0.001. ref: <img width="1850" height="689" alt="image" src="https://github.com/user-attachments/assets/10242315-3c4d-4670-b77d-8cb429e00891" /> Forward-Port-Of: odoo/enterprise#107676
This update resolves a test failure within the Belgian payroll module (l10n_be_hr_payroll_fix) by adding a temporary freeze to time calculations. This ensures the holiday attest test runs successfully, preventing potential disruptions to payroll processing for Belgian users. The change is a technical fix to maintain the stability of the system.
Original PR description
Addind freeze_time to Fix holiday attest test that failed on the runbot Forward-Port-Of: odoo/enterprise#107490
This update fixes an issue where clicking the 'More options' button in the HTML editor would cause the editor to lose focus. The fix ensures the editor remains focused after the button is clicked, improving the user experience. It also addresses a filtering problem within the powerbox, ensuring commands are correctly displayed.
Original PR description
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: -…
**Issue 1:** Steps to Reproduce - Click on the More options button in the power buttons. - The powerbox opens, but the editor loses focus and the button receives focus. Description of the issue: - After clicking the power button, the button becomes focused and the editor loses focus. Solution - When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused. **Issue 2:** Steps to reproduce - Click More options in the Power Buttons to open the powerbox. - Start typing `heading`. Description of the issue: - The powerbox does not filter commands and continues to show all commands. Cause: - In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true. - `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`. - Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered. Solution: - Introduced `openSearchPowerbox` in `searchPowerboxPlugin`. - Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`. - Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress. task-5485088 Forward-Port-Of: odoo/odoo#249844 Forward-Port-Of: odoo/odoo#244454
This update ensures that both KMD INF-A and INF-B reports correctly include partners without VAT numbers. It also harmonizes partner warnings to align with the main query, providing more accurate reporting on VAT-registered and non-registered businesses.
This update addresses a recurring test failure related to the automatic focus of speakers during one-to-one calls. The team added safeguards to the test process, including sound assertions and additional checks, to reliably avoid race conditions. This resolves a previous runbot error and ensures consistent test execution.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/250174 PR above attempts to solve race condition of the following test: ``` @mail/discuss/call/call/auto-focus participant video in one-to-one call in…
Follow-up of https://github.com/odoo/odoo/pull/250174 PR above attempts to solve race condition of the following test: ``` @mail/discuss/call/call/auto-focus participant video in one-to-one call in chat window ``` Where the meeting view may not have been considered as open and thus mistakenly trigger the speaker auto-focus feature. However the test is still failing non-deterministically at the same step. While the previous fix sounds good in theory, this is insufficient. We couldn't reproduce the problem, but there are a few theories on what may cause the problem: "Join Call" has side-effect to auto-focus speaker, which might mistakenly be triggered later in test if executing very fast. To make sure this doesn't happen, test now asserts playing of call-join sound, which happens close to the initial auto-focus of the speaker. This commit also adds more intermediate assertions that should help awaiting proper time (thus avoiding race conditions) or help with further hints at what's wrong with this test: - properly check video stream is off visually when other participant stops the camera feed - click on active card should return to showing of 2 cards, before the other participant re-enables the camera feed in the meeting view - make use of `card:has(video)` in earlier assertions, instead of `card video`, to more easily distinct which step is problematic. The last one is very likely the issue, therefore we keep the original `card video` as this is more likely to hit with the same runbot error entry, in case the problem is still ongoing. Fixes runbot error 240554
This update fixes a problem where restarting the live chat bot after a page reload would cause duplicate actions. The fix removes a redundant command from the restart process, ensuring the bot functions correctly and consistently. This improves the user experience for live chat support.
Original PR description
Since [1], restarting the chat bot after reload could lead to multiple steps being executed at the same time. Steps to reproduce: - Go to the `/im_livechat/support/2` page. - Chat with the support bot until the end of the conversation. - Reload the page. - Click on the restart button. - Two question selections are displayed at the same time. This occurs because the bot starts from the `_toggleChatbot` field's `onUpdate` method. The `restart` method also calls `start` on the chat bot. To fix this issue, the call to `start` is removed from the `restart` method. [1]: https://github.com/odoo/odoo/pull/194399 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251390 Forward-Port-Of: odoo/odoo#250623
This update fixes an issue where the cursor wasn't correctly navigating within long text blocks inside Odoo tables. Previously, users couldn't move up and down within multi-line text cells, jumping directly to the next cell instead. This change ensures accurate line-by-line navigation within table text, improving usability.
Original PR description
When navigating inside a table cell, if a single text node is rendered over several lines, the cursor up and down key go directly to the next cell instead of navigating to the (visually) previous or next line of text. This commit determines if the cursor position is within such positions inside a multi-line text node and prevents the table navigation if needed. Steps to reproduce: - Add a table with `/table` - Put a very long text (without paragraph splits) in the center cell, so that the text spans over several lines - Navigate with the up and down arrows => The cursor could not reach distinct lines within the text task-5417834 Forward-Port-Of: odoo/odoo#240764
This update addresses minor issues within the HTML editor and email functionality, primarily focused on improving usability and stability. Specifically, it removes unnecessary features like video support, streamlines the email composer, and ensures proper quoting of replies for a better user experience.
Original PR description
This PR only applies changes requested during the backport as this is the version of the original PR -------- Backport of fixes added in odoo/odoo#238694 - banners don't work in emails because of…
This PR only applies changes requested during the backport as this is the version of the original PR -------- Backport of fixes added in odoo/odoo#238694 - banners don't work in emails because of inline conversion, and we don't need them - video elements and iframes are also not supported, hence we can remove the plugin entirely - the highlight inside the composer is redundant with the footer separator - "edit" should not be a quick option for admins on other users' messages, instead reply is more appropriate - signatures should be shown when composing replies and forwards as well - images already embedded into the body of a message don't need to be shown as attachments as well - images shown in the composer don't need to be big and legible by default, users can click on them as needed - when the author has no email and there is no email from (log not on a fresh db for example), replying should be possible - recipients should not be recomputed in the composer unless the user selected a template using specific recipients. This avoids picking a bunch of specific recipients only to lose them when picking a template. - when sending a reply immediately without touching the body, the reply content should still be quoted task-5013894 Forward-Port-Of: odoo/odoo#251062 Forward-Port-Of: odoo/odoo#239679
This update fixes an issue where the default putaway strategy wasn't consistently applied in stock movements. Specifically, it ensures the strategy defaults to the child location of a move, resolving a potential misdirection of goods. This improves the accuracy and efficiency of stock management processes.
Original PR description
Steps to reproduce ----- - Enable locations & by products - Create 4 locations - View A of type view (parent: Stock) - View B of type view (parent: Stock) - Storage A of type internal location…
Steps to reproduce ----- - Enable locations & by products - Create 4 locations - View A of type view (parent: Stock) - View B of type view (parent: Stock) - Storage A of type internal location (parent: View A) - Storage B of type internal location (parent: View B) - Create a "Manufacture to A" route - Rule 1: Manufacture, Stock -> Stock - Rule 2: Push To, Internal Transfer, Stock -> View A - Create a "By Products to B" route - Rule 1: Push To, Internal Transfer, Stock -> View B - Create a "Bonus" product with route "By Products to B" - Create a "Finished" product with route "Manufacture to A" - BoM with "Bonus" as by product - Create a MO for Finished, and produce it - Open the linked transfers' list view - Open the "Bonus" transfer > "Destination Location" states View B - Open the line's details (hamburger button) > "Store To" states View A/Storage A Cause ----- When retrieving the location in https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L280-L282 we pass `locations` as a context key. The problem is that `locations` contains the childs of **all** of the SMLs' locations https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L260 This means that, in `_get_putaway_strategy`, when no `putaway_location` is found, we end up defaulting to the first element of the list https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L370-L371 which might not be a child of the location. Solution ----- By removing the context key, locations get populated as such https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L328-L330 This is ok because we know the call to `_get_putaway_strategy` is made on a single record (`sml.move_id.location_dest_id`) so the default will correctly be a child of said location. ----- Ticket: opw-5359945 Forward-Port-Of: odoo/odoo#250147 Forward-Port-Of: odoo/odoo#247403
This update corrects a technical issue where the ‘commercial_partner_id’ field in the Contacts app would trigger errors when using the IAP autocomplete. The change ensures this field is always populated, preventing validation problems and improving the user experience. This resolves a bug related to web_studio customizations.
Original PR description
Before this commit, when commercial_partner_id is on the view (possible with web_studio), the value by default is False. When the autocomplete widget is used, many fields could be autofilled and raise _onchange_verify_peppol_status, that requires this field. To avoid this issue we review that the value has been filled. Steps to Reproduce: 1. Open the Contacts app 2. Open Studio on the contact form view 3. Add the field commercial_partner_id to the form view (make it visible) 4. Create a new contact 5. Type a name 6. Select a suggestion from the IAP autocomplete 7. An error is raised immediately OPW-[5896847](https://www.odoo.com/odoo/action-4043/5896847) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251590 Forward-Port-Of: odoo/odoo#248895
This update resolves a problem where updating a Bill of Materials (BoM) in a draft manufacturing order would incorrectly delete and attempt to delete associated work orders, leading to errors. The fix ensures that work orders are only removed when they are truly outdated, improving the stability of the manufacturing process.
Original PR description
Steps to reproduce: - Create a storable product P1 with the following BoM: - Component: C1 - Operation: OP1 - Create a draft MO for P1 - Update the BoM by adding a new component - Go back to the MO…
Steps to reproduce:
- Create a storable product P1 with the following BoM:
- Component: C1
- Operation: OP1
- Create a draft MO for P1
- Update the BoM by adding a new component
- Go back to the MO and click "Update from BoM"
Problem:
Missing Record
Record does not exist or has been deleted.
(Record: mrp.workorder(8,), User: 2)
Clicking on `update bom` will launch a call of the `action_update_bom`
which will itself call the `_link_bom` to update the record:
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418
The function will sets `bom_id` to False, which triggers
`_compute_workorder_ids` and `_compute_move_finished_ids`
(depends on bom_id). As the MO is in draft, related moves and
workorders are deleted.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L849
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L659
After that, it will try to delete the work orders again, and
since the operation no longer exists, an error will be triggered.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2586-L2587
opw-5947687
Forward-Port-Of: odoo/odoo#251352
Forward-Port-Of: odoo/odoo#249336