Daily updates from Odoo
Navigate
Branch
Thursday, May 7, 2026
359 changes
20 changes
New functionality added to Odoo
This update introduces a new VAT provision account (411800) in the Odoo accounting module for Belgium, aligning with new regulations. Starting May 1st, businesses will need to use this account for their periodic VAT returns instead of the previous account. This change ensures compliance with Belgian tax law.
Original PR description
Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new account 'Tax Provision Account' 411800 Enterprise PR: odoo/enterprise#111599 Task [link](https://www.odoo.com/odoo/project.task/6044017) task-6044017 Forward-Port-Of: odoo/odoo#262897 Forward-Port-Of: odoo/odoo#255272
This update prepares Odoo for a new Belgian tax regulation. Starting May 1st, a new 'Tax Provision Account' (411800) is added to ensure accurate VAT reporting for periodic returns. This change simplifies the accounting process for Belgian users.
Original PR description
Starting May 1st, in Belgium the VAT provision account will replace the current account for periodic returns - Adding the new bank account - Adding a new account 'Tax Provision Account' 411800 Community PR: odoo/odoo#255272 Task [link](https://www.odoo.com/odoo/project.task/6044017) task-6044017 Forward-Port-Of: odoo/enterprise#116290 Forward-Port-Of: odoo/enterprise#111599
Resolved issues and error corrections
This update resolves an issue where uploading an empty file to the Sign Documents feature would cause an error. The fix ensures that the system correctly handles empty file uploads, preventing a technical error and improving the stability of the Sign module. This ensures users can consistently upload files without encountering this specific problem.
Original PR description
## Steps to Reproduce: - Install the Sign module. - Try to upload an empty file in Sign Documents. Sample File: https://drive.google.com/file/d/1ik3b7Z--Xla_TmvRj92uTCGy1PspQ_cP/view?usp=drive_link ## Error: `TypeError - a bytes-like object is required, not 'bool'` ## Cause: Before saas-19.2, at [1] `datas` returns an empty binary string (`b''`) when the file content is empty. After the [refactor], `raw` is used instead, which returns `False` for empty content, leading to this error. ## Fix: This commit ensures that when the attachment raw value is False, it is replaced with an empty binary string (`b''`). [refactor]: https://github.com/odoo/enterprise/commit/8d66ffa62ab3fb3334528999d4534a9a995c6830 [1] - https://github.com/odoo/enterprise/blob/0d70215fb5d7b72dcfe86ac23fd04208329aad5d/sign/models/sign_document.py#L65 sentry-7432818850 Forward-Port-Of: odoo/enterprise#115917
This update resolves a bug in the generation of Spanish BOE reports (mod347) for businesses. Previously, invoices under €3,005.06 caused incorrect partner data to be included in the export. This fix ensures that only relevant partners are listed, improving data accuracy and compliance for Spanish tax reporting.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#116387 Forward-Port-Of: odoo/enterprise#110947
This update corrects a technical issue where the demo user's employee record was being duplicated, leading to a database constraint violation. The fix ensures the demo user always utilizes the existing employee record, preventing errors and maintaining data integrity. This improves the stability of the HR holiday testing environment.
Original PR description
Issue: The test was creating a new employee linked to the demo user, but if the demo user already had an employee, it would violate the (user_id, company_id) uniqueness constraint. Fix: Before creating a new employee, we check if the demo user already has one. If not, we create it, otherwise we use the existing one. task-6050719
This update fixes an issue where manually specified lot quantities in manufacturing orders weren't being applied correctly. Previously, the system was incorrectly calculating quantities based on available lot stock, leading to inaccurate consumption. This change ensures that manually set lot quantities are accurately reflected during the production process.
Original PR description
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for…
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for product P with 2 units each - Create a MO for a product consuming two units P and confirm it - On the raw move, manually set 1 unit for each lot - Click on "Produce All" - Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each **Cause** While producing: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line: - Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297 - Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity **Solution** Assume that raw move lines being created in mrp without changing the producing quantity are manually created opw-5946439 Forward-Port-Of: odoo/odoo#260518 Forward-Port-Of: odoo/odoo#257258
This change corrects a visual issue in the online store where a product offering free shipping (a reward) displayed a border in the shopping cart. The fix removes this border by adjusting the styling of the quantity field, ensuring a cleaner and more professional shopping experience for customers.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Enable `Discounts, Loyalty & Gift Cards` from settings. - Go to `Website > eCommerce > Loyalty > Discount & Loyalty`. - Create a new program…
Steps to produce: --- - Install `website_sale` module. - Enable `Discounts, Loyalty & Gift Cards` from settings. - Go to `Website > eCommerce > Loyalty > Discount & Loyalty`. - Create a new program and edit the reward to set the reward type to `Free Shipping`. - Create a new product, set its price to 1000, and publish it. - Open the product on the website and add it to the cart > open the cart. Issue: --- - The quantity field for the unsellable product (Free Shipping reward) displays a border in the cart. Root cause: --- - The form-control class is applied to the quantity field at [1]. - This class includes a default border style defined in Bootstrap at [2]. Solution: --- - Apply the Bootstrap utility class `border-0` to remove the border from the quantity field for unsellable products. [1]https://github.com/odoo/odoo/blob/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab/addons/website_sale/views/templates.xml#L2901 [2]https://github.com/odoo/odoo/blob/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab/addons/web/static/lib/bootstrap/scss/forms/_form-control.scss#L5-L31 Before: --- <img width="822" height="135" alt="image" src="https://github.com/user-attachments/assets/d66c0445-5fd4-45c5-ae81-b4270cab6378" /> After: --- <img width="827" height="132" alt="image" src="https://github.com/user-attachments/assets/9cc2bd65-c542-4d1f-89de-2212fa968c8e" /> opw-6153161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262883 Forward-Port-Of: odoo/odoo#261275
This update corrects a problem with the Intrastat CSV export report in the Netherlands. The fix addresses an issue where data was incorrectly formatted (specifically the 'Commodity flow' field) and ensures the database is up-to-date before generating the report, improving data accuracy.
Original PR description
Since the technical refactoring of intrastat in 18.0, the csv export in `l10n_nl_intrastat` seems broken. Here is the fixes done in this commit: 1. `Commodity flow` is supposed to be a single diggit (6 or 7) but an empty blank space was hidden. 2. Switching the condition on `country_origin_code` as it was the opposite 3. Add a `flush_all` before calling the report during the export, to be sure the database is up to date. opw-5799126 Forward-Port-Of: odoo/enterprise#116230 Forward-Port-Of: odoo/enterprise#115791
This update fixes an issue where bank statement imports were failing due to the system not using the correct partner name. The change ensures that when a CAMT file contains both 'Dbtr' and 'UltmtDbtr' information, the 'UltmtDbtr' name is used for reconciliation matching, preventing errors and improving data accuracy.
Original PR description
Steps to reproduce: 1- Create a Swiss company and switch to it 2- Go to [Accounting -> Configuration -> Journals] and create a Bank journal 3- Go to the Accounting dashboard, click on the three dots on the Bank journal and click import records 4- Upload a CAMT file with a record that has both a value for "Dbtr" and "UltmtDbtr" (file can be found in the ticket chatter) Issue: The added record uses the "Dbtr" `name` value for the partner name. As a result, reconcilation matching fails Expected behavior: If exists, should use the "UltmtDbtr" `name` value opw-6024860 Forward-Port-Of: odoo/enterprise#113560
This update significantly improves the speed of importing large XML bills, particularly those received via Peppol or manual upload. By optimizing the system's database queries and update processes, the upload time for bills with 30,000+ lines has been reduced from failing to completing in just 11 minutes. This enhances efficiency for our accounting operations.
Original PR description
### Description: The upload and import process for large XML bills via Peppol or manual upload was inefficient due to two primary bottlenecks. First, the system performed individual queries per line to match products, taxes, and accounts, leading to an N+1 query issue. Second, multiple write operations were executed on each line to update various fields. This commit introduces batching and improve caching for these operations to reduce database call. ### Benchmark: | N° of lines | Before | After | |-------------|---------|-------| | 30264 | Timeout | 11min | ### Reference: opw-5416612 Forward-Port-Of: odoo/odoo#262882 Forward-Port-Of: odoo/odoo#248680
This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices. Specifically, a problem with how the system handled multiple currency lines led to incorrect balance calculations and hidden values. The fix ensures accurate balance display during reconciliation, improving the user experience.
Original PR description
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366 Forward-Port-Of: odoo/enterprise#115101
This update resolves an issue where the power button test in the HTML editor was unreliable, particularly on slower runbots. The fix ensures the test consistently triggers the correct behavior by correctly managing animation frames, preventing delays and ensuring accurate timing.
Original PR description
The previous fix [1] removed one animation frame too many because the first one after arow down is needed in order to trigger the hiding of the power buttons in the first place, otherwise the timer can have elapsed without an animation frame when the runbot is slow. Then, for the other ones, the animation frame must not be awaited, otherwise we risk having an animation frame when the runbot waited more than the debouce delay, as explained in [1]. runbot-242466 [1]: https://github.com/odoo/odoo/pull/259654 Forward-Port-Of: odoo/odoo#262929 Forward-Port-Of: odoo/odoo#262679
This update corrects a problem where payroll period calculations in the Hong Kong module were failing when tests were run outside the default date range. Specifically, the calculation relied on a date derived from today, causing issues with payslips generated in different years. This ensures accurate payroll reporting.
Original PR description
ir56b._compute_period depends on year_of_employer_return, which is derived from submission_date (defaults to today). If tests are run in a different year (mocked time or different environment), the period won't cover the January 2026 payslip. Forward-Port-Of: odoo/enterprise#116246 Forward-Port-Of: odoo/enterprise#116172
This update fixes an issue where long translated labels in product category configuration forms would overlap other fields, creating a cluttered and difficult-to-use interface. The fix allows radio button labels to wrap correctly, ensuring a cleaner and more readable layout, particularly when using localized content.
Original PR description
Steps to reproduce: - Go to Accounting > Configuration > Product Categories - Open the "Goods" category in a narrow enough form layout - Check the "Reserve Packagings" radio field in Ukrainian #### Issue: In configuration forms, `.o_form_label` is forced to `white-space: nowrap`. Since radio option labels also use `.o_form_label`, long translated labels cannot wrap and can overlap the neighboring valuation field area. #### Fix: Exclude `.form-check-label` from that rule so radio labels can wrap without changing the behavior of regular form labels. opw-6086700 <img width="1872" height="966" alt="image" src="https://github.com/user-attachments/assets/db5e5803-b5e7-4904-a036-8bdfbb5504fc" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261284
This update fixes a technical issue that caused a traceback error when users replaced images within the HTML editor. The fix ensures the system correctly identifies the relevant block when deleting images, preventing errors and improving the overall stability of the HTML editor functionality. This ensures a smoother experience for users editing content.
Original PR description
Steps to Reproduce: - Go to the website - Add an image and set it to center alignment - Copy the image - Paste it into a To-Do note - Replace the image - Click the Delete button Description of the issue: - A traceback error occurs when deleting the image after replacement. Cause: - When an image has display: block, the closestBlock function returns the image element itself as the closest block. However, this causes an issue, After the image is deleted, fillEmpty is called on this closestBlock, which refers to an image that has already been removed from the dom resulting in a traceback. Solution: - Instead of finding the image's closestBlock directly, find the closestBlock of its parent element. - This ensures the correct block is found even when the image has display:block. task-6171827 Forward-Port-Of: odoo/odoo#262217
This update fixes an issue where invoices for recurring subscriptions weren't accurately reflecting the billing period. The change ensures invoices align correctly with the subscription's billing period value, regardless of the billing period length (e.g., 6 months, 3 months). This prevents invoices from only covering a single month's worth of service.
Original PR description
## Issue When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit…
## Issue
When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit of time (week/month/year).
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Recurring Plan RP:
- *Billing Period*: 6 Months
- *Align to Period Start*: Checked
3. Create a Subscription Product P
4. Create a Subscription SO:
- Any Customer
- Recurring Plan RP
- Product P (any quantity/price)
5. Confirm the SO and create the invoice
6. **In the line of the SO, only one month is covered by the invoice. If we generate the next invoice, only one month will be covered as well.**
## Cause
Since https://github.com/odoo/enterprise/commit/45f28f6c288f5213a4e29c816ec68d2c3966b55f, the `next_date_1st` is evaluated by taking the last day of the month/year and incrementing it by one day, to reach the first day of the next month/year.
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/sale_subscription/models/sale_order_line.py#L377-L382
This is inaccurate when working with recurring plan which are not monthly/yearly, as it will always set the `next_date_1st` to the next month/year, without taking in account the `billing_period_value`.
## Fix
There are two ways to align dates to the period start. Given a subscription starting on January 15, with a billing period of 3 months, we could:
1. Invoice from January 15 to January 31, then from February 1 to April 30. This aligns the invoice to the closest month, then apply the 3 months period for the next invoices.
2. Invoice from January 15 to March 31, then from April 1 to June 30. This applies most of the billing period for the first invoice, while still aligning it to the start of the month, then apply the 3 months period normally for the next invoices.
**Here, we chose the second option** to avoid making the code more complex and keep the diff minimal.
opw-6151530
Forward-Port-Of: odoo/enterprise#115830This update resolves an issue preventing mobile users from uploading documents through the portal. The fix adjusts how the file upload button interacts with the mobile interface, ensuring the file picker remains active and uploads complete. This improves the user experience for mobile portal users.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Create a portal user and share a document folder with edit access 3. Log in as the portal user on a mobile device 4. Try to upload a document inside the…
Steps to reproduce:
1. Install `documents`
2. Create a portal user and share a document folder with edit access
3. Log in as the portal user on a mobile device
4. Try to upload a document inside the shared folder
Issue:
- After selecting a file from the file picker, the document is not uploaded.
Cause:
- On mobile in the portal flow, Upload is triggered from a nested dropdown (inside New) inside the adaptive control-panel dropdown (bottom sheet). By default, DropdownItem uses closingMode="all", so tapping Upload closes parent dropdowns immediately. That unmounts the hidden <input type="file"> before the OS file picker returns. When the user comes back, the input no longer exists, so change never fires and upload does not start.
- Admin/internal users do not hit the same nested adaptive-dropdown path in this view
Solution:
- Set closingMode="'none'" on the Upload DropdownItem so the menu stays mounted while the native picker is open. After a file is selected and onFileInputChange starts upload, close the bottom sheet programmatically with: `window.dispatchEvent(new Event("popstate"))`
opw-5937105
Forward-Port-Of: odoo/enterprise#108486This update resolves an issue where custom snippets weren't correctly reflecting translated content due to a conflict with the delayed translation feature. The change ensures that translated values are properly applied when using custom snippets, improving the website localization experience for users. This fix allows for accurate multi-language content display.
Original PR description
The feature "delayed translation" and "copy translation in custom snippet" have been worked on in parallel, but had buggy interactions. This commit changes the way translations terms are copied in custom snippets to read and write the translated values as expected with delayed translations. Steps to reproduce: - With a page with some content on a website in 2 languages - Open the website builder in the main language - Drop a custom snippet - Save - Bug: The change is immediate on the version in the second language (instead of being only available after user translated it) Delayed translations: 2d08f97c0778469b409fca23f2be5f5a98ce3df8 Copy translation in custom snippet: d3426b7714012e833caae10281cfb8433223299a Re-enabling delayed translations: 03a85b13b2c46ef7174123d902e95d5103031c6c task-5474184 Forward-Port-Of: odoo/odoo#263032 Forward-Port-Of: odoo/odoo#245850
This update fixes an issue where payment reminders weren't being sent to newly duplicated subscriptions. The root cause was a shared 'last_reminder_date' field preventing new reminders from triggering. The fix sets this field to 'false' for copied subscriptions, ensuring reminders are sent as expected.
Original PR description
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new…
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago 3. Confirm the subscription 4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token" 5. Go back to the previously created subscription (see that a reminder email has been added in the chatter) 6. Duplicate the subscription and confirm the duplicate 7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again 8. There are no reminder for the duplicate subscription Issue: The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120 Solution: Set `copy=False` on the field `last_reminder_date` opw-6167356 Forward-Port-Of: odoo/enterprise#116335 Forward-Port-Of: odoo/enterprise#115509
This update resolves an issue where the AI systray button in the Odoo interface had excessive padding. The change removed unnecessary styling classes, streamlining the button's appearance and improving the user experience. This ensures a cleaner and more consistent look for the application.
Original PR description
Remove the `btn` class because it adds additional padding, and eliminate the other unnecessary classes since the rules have already been applied in the `navbar.scss` file. task-5079952 Forward-Port-Of: odoo/enterprise#116423
19 changes
New functionality added to Odoo
This update aligns Odoo's data with international standards by incorporating the states of Georgia, as defined by ISO 3166-2. The change also improves address formatting to display state names instead of codes, enhancing data clarity and accuracy for users.
Original PR description
Added the states in Georgia to align with official ISO 3166-2 standards. task-6119824 Forward-Port-Of: odoo/odoo#261689
Resolved issues and error corrections
This update resolves an issue where the Mod 349 report in Spain's tax reporting system incorrectly excluded vendor bills with amounts less than 1 Euro. The fix adjusts a technical setting to ensure these small amounts are properly displayed, improving the accuracy of tax reporting. This ensures compliance and accurate financial data.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#116102 Forward-Port-Of: odoo/enterprise#114776
This update resolves a bug where the color picker would unexpectedly close when users tried to change the color of icons within the HTML editor. The fix ensures that styling elements like 'font' are properly handled, preventing the toolbar from closing prematurely and allowing users to consistently apply colors to icons.
Original PR description
Problem: Trying to change the color of an icon causes the color picker to close when hovering over colors. Cause: When the icon (`span`) is wrapped inside a `font` element, the `toolbar_namespace_providers` for the icon return `false` because the `font` wrapper was not handled. As a result, the `namespace` becomes `undefined`, which causes the toolbar to close during selection changes. Solution: Handle cases where an icon is wrapped by styling elements (such as `font`) so the correct toolbar namespace is preserved. Steps to reproduce: - Insert a Font Awesome icon using `/media`. - Click on the icon to open the toolbar. - Try to apply a color or background color. - Notice the color picker closes instantly when hovering over colors. task-6109153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258729
This change corrects a visual issue in the online store where a border appeared around the quantity field for a product offering free shipping. This was caused by a default border style in the Bootstrap framework. The fix removes this border, ensuring a cleaner and more professional shopping experience for customers.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Enable `Discounts, Loyalty & Gift Cards` from settings. - Go to `Website > eCommerce > Loyalty > Discount & Loyalty`. - Create a new program…
Steps to produce: --- - Install `website_sale` module. - Enable `Discounts, Loyalty & Gift Cards` from settings. - Go to `Website > eCommerce > Loyalty > Discount & Loyalty`. - Create a new program and edit the reward to set the reward type to `Free Shipping`. - Create a new product, set its price to 1000, and publish it. - Open the product on the website and add it to the cart > open the cart. Issue: --- - The quantity field for the unsellable product (Free Shipping reward) displays a border in the cart. Root cause: --- - The form-control class is applied to the quantity field at [1]. - This class includes a default border style defined in Bootstrap at [2]. Solution: --- - Apply the Bootstrap utility class `border-0` to remove the border from the quantity field for unsellable products. [1]https://github.com/odoo/odoo/blob/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab/addons/website_sale/views/templates.xml#L2901 [2]https://github.com/odoo/odoo/blob/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab/addons/web/static/lib/bootstrap/scss/forms/_form-control.scss#L5-L31 Before: --- <img width="822" height="135" alt="image" src="https://github.com/user-attachments/assets/d66c0445-5fd4-45c5-ae81-b4270cab6378" /> After: --- <img width="827" height="132" alt="image" src="https://github.com/user-attachments/assets/9cc2bd65-c542-4d1f-89de-2212fa968c8e" /> opw-6153161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262883 Forward-Port-Of: odoo/odoo#261275
This update resolves an error that occurred when calculating benefit costs with property fields in employee contracts. Previously, the system couldn't properly handle these fields, leading to a calculation failure. This fix prevents the system from attempting to sum property fields as cost values, ensuring accurate benefit calculations.
Original PR description
**Steps to Reproduce:** 1. Install `hr_contract_salary_payroll` with demo data. 2. Open Employee (e.g; Abigail Peterson) > Payroll tab > Gear Icon > Edit Properties. 3. Add a new property for Payroll…
**Steps to Reproduce:** 1. Install `hr_contract_salary_payroll` with demo data. 2. Open Employee (e.g; Abigail Peterson) > Payroll tab > Gear Icon > Edit Properties. 3. Add a new property for Payroll and fill in the value also. 4. Go to Payroll > Configuration > Benefits. 5. Create a new benefit with: Salary Structure Type: Worker Cost Field: Payroll Properties (Employee Contract) 6. Save the record. Video: https://drive.google.com/file/d/1gHRkDW5G0bURlo9_IRgCnvqpE-8Fk1xa/view?usp=drive_link **Error:** `TypeError - unsupported operand type(s) for +: 'int' and 'Property'` **Cause:** The method `_get_benefits_costs()` directly sums values using: ``` self[benefit.cost_field] ``` When the selected cost field is a property field, it returns a **fields_properties.Property** object instead of a numeric value, and this object is not directly compatible with the arithmetic sum operation. Before 19.0, property fields were not allowed to be selected as a cost field - [1]. **Fix:** This commit prevents selecting property fields as cost fields from the list of supported field types. [1] : https://github.com/odoo/enterprise/blob/04224abcc7eec1c81df7ad57a9213fd091774888/hr_contract_salary/models/hr_version.py#L183 sentry-7388663038 Forward-Port-Of: odoo/enterprise#113238
This update corrects a problem with the Intrastat CSV export report in the Netherlands. The fix addresses an incorrect data format for 'Commodity flow' and ensures the database is up-to-date before generating the report, preventing inaccurate export data.
Original PR description
Since the technical refactoring of intrastat in 18.0, the csv export in `l10n_nl_intrastat` seems broken. Here is the fixes done in this commit: 1. `Commodity flow` is supposed to be a single diggit (6 or 7) but an empty blank space was hidden. 2. Switching the condition on `country_origin_code` as it was the opposite 3. Add a `flush_all` before calling the report during the export, to be sure the database is up to date. opw-5799126 Forward-Port-Of: odoo/enterprise#116230 Forward-Port-Of: odoo/enterprise#115791
This update resolves an issue where the AI systray button in the Odoo interface had excessive padding. The code was simplified to remove unnecessary styling rules already defined elsewhere, improving the button's visual appearance and overall user experience. This change ensures a cleaner and more consistent look for users.
Original PR description
Remove the `btn` class because it adds additional padding, and eliminate the other unnecessary classes since the rules have already been applied in the `navbar.scss` file. task-5079952 Forward-Port-Of: odoo/enterprise#116423
This update fixes an issue where bank statement imports were failing due to incorrect partner name matching. The change ensures that when a CAMT file contains both 'Dbtr' and 'UltmtDbtr' values, the 'UltmtDbtr' name is used for reconciliation, resolving import failures and improving data accuracy.
Original PR description
Steps to reproduce: 1- Create a Swiss company and switch to it 2- Go to [Accounting -> Configuration -> Journals] and create a Bank journal 3- Go to the Accounting dashboard, click on the three dots on the Bank journal and click import records 4- Upload a CAMT file with a record that has both a value for "Dbtr" and "UltmtDbtr" (file can be found in the ticket chatter) Issue: The added record uses the "Dbtr" `name` value for the partner name. As a result, reconcilation matching fails Expected behavior: If exists, should use the "UltmtDbtr" `name` value opw-6024860 Forward-Port-Of: odoo/enterprise#113560
This update significantly speeds up the process of importing large XML bills, particularly those received via Peppol or manual upload. The change addresses a performance bottleneck by optimizing database queries and reducing the number of operations, resulting in a much faster upload time. This improves efficiency for users handling invoices.
Original PR description
### Description: The upload and import process for large XML bills via Peppol or manual upload was inefficient due to two primary bottlenecks. First, the system performed individual queries per line to match products, taxes, and accounts, leading to an N+1 query issue. Second, multiple write operations were executed on each line to update various fields. This commit introduces batching and improve caching for these operations to reduce database call. ### Benchmark: | N° of lines | Before | After | |-------------|---------|-------| | 30264 | Timeout | 11min | ### Reference: opw-5416612 Forward-Port-Of: odoo/odoo#262882 Forward-Port-Of: odoo/odoo#248680
This update corrects a build error within the Odoo AE (l10n_ae_faf) module related to a dependency issue. By adjusting the view's location, the update eliminates the need for a problematic, automatically installed module, ensuring smoother operation.
Original PR description
the inherited tax view form was raising an error since ubl_cii_tax_category_code is in the view under the module account_edi_ubl_cii and this module is not in the resolved dependencies of l10n_ae_faf but is usually autoinstalled. to fix this we are changing the xpath to be something that doesn't need the dependency of the account_edi_ubl_cii but only account. runbot-239123 Forward-Port-Of: odoo/enterprise#116163
This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices. Specifically, a problem with how the system handled multiple currency lines during reconciliation was corrected. This ensures accurate balance calculations and a smoother user experience when working with multi-currency transactions.
Original PR description
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366 Forward-Port-Of: odoo/enterprise#115101
This update fixes an issue where the undo function in the HTML editor would sometimes restore the selection to the wrong position. By staging the selection before deletion, the undo operation now correctly restores the user's previous editing state, ensuring a smoother and more reliable editing experience. This improves overall usability and reduces frustration for users.
Original PR description
Problem: In some cases, undo restores the selection to an incorrect position. Cause: The selection state was not staged before the deletion started, leading to an inconsistent selection being restored during undo. Solution: Stage the selection before performing the deletion to ensure it can be restored to the correct position. Steps to reproduce: - Go to To-Do → Create New. - Type something on the first line and press Enter. - Type something on the second line and apply styling to it. - Use the Up arrow key to move to the first line. - Remove a character. - Press Undo (Ctrl + Z). - Observe that the selection and toolbar appear on the second line. task-6142055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262896 Forward-Port-Of: odoo/odoo#260630
This update resolves an issue where the power button test in the HTML editor was unreliable due to timing inconsistencies. The fix ensures the test consistently triggers, preventing potential delays or failures in the runbot process. This improves the stability and reliability of the HTML editor's testing.
Original PR description
The previous fix [1] removed one animation frame too many because the first one after arow down is needed in order to trigger the hiding of the power buttons in the first place, otherwise the timer can have elapsed without an animation frame when the runbot is slow. Then, for the other ones, the animation frame must not be awaited, otherwise we risk having an animation frame when the runbot waited more than the debouce delay, as explained in [1]. runbot-242466 [1]: https://github.com/odoo/odoo/pull/259654 Forward-Port-Of: odoo/odoo#262929 Forward-Port-Of: odoo/odoo#262679
This update fixes an issue where long translated labels in product category forms (like 'Reserve Packagings') would overlap other fields on narrow screens. The fix allows radio labels to wrap correctly, improving the overall usability and visual appearance of configuration forms, particularly for users with translated data.
Original PR description
Steps to reproduce: - Go to Accounting > Configuration > Product Categories - Open the "Goods" category in a narrow enough form layout - Check the "Reserve Packagings" radio field in Ukrainian #### Issue: In configuration forms, `.o_form_label` is forced to `white-space: nowrap`. Since radio option labels also use `.o_form_label`, long translated labels cannot wrap and can overlap the neighboring valuation field area. #### Fix: Exclude `.form-check-label` from that rule so radio labels can wrap without changing the behavior of regular form labels. opw-6086700 <img width="1872" height="966" alt="image" src="https://github.com/user-attachments/assets/db5e5803-b5e7-4904-a036-8bdfbb5504fc" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261284
A recent issue causing errors when deleting images within the HTML editor has been fixed. This update ensures the editor functions reliably, preventing disruptions to users' ability to format and manage content. The fix corrects a logic error related to image element identification during deletion.
Original PR description
Steps to Reproduce: - Go to the website - Add an image and set it to center alignment - Copy the image - Paste it into a To-Do note - Replace the image - Click the Delete button Description of the issue: - A traceback error occurs when deleting the image after replacement. Cause: - When an image has display: block, the closestBlock function returns the image element itself as the closest block. However, this causes an issue, After the image is deleted, fillEmpty is called on this closestBlock, which refers to an image that has already been removed from the dom resulting in a traceback. Solution: - Instead of finding the image's closestBlock directly, find the closestBlock of its parent element. - This ensures the correct block is found even when the image has display:block. task-6171827 Forward-Port-Of: odoo/odoo#262217
This update corrects a setting for Thai (l10n_th) taxes. By default, WHT taxes no longer create closing entries, aligning with how these taxes are handled through separate payable accounts. This ensures accurate accounting for WHT transactions.
Original PR description
Set tax closing entry to False by default for WHT taxes, as WHT uses separate payable accounts and does not require closing entries. task-6146195 Forward-Port-Of: odoo/odoo#262469 Forward-Port-Of: odoo/odoo#262464
This update fixes an issue where invoices for recurring subscriptions weren't accurately reflecting the billing period. The change ensures that invoices align correctly with the subscription's billing period value, regardless of the period's length (e.g., 3 months, 6 months). This prevents incorrect invoice amounts and ensures accurate billing.
Original PR description
## Issue When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit…
## Issue
When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit of time (week/month/year).
## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Recurring Plan RP:
- *Billing Period*: 6 Months
- *Align to Period Start*: Checked
3. Create a Subscription Product P
4. Create a Subscription SO:
- Any Customer
- Recurring Plan RP
- Product P (any quantity/price)
5. Confirm the SO and create the invoice
6. **In the line of the SO, only one month is covered by the invoice. If we generate the next invoice, only one month will be covered as well.**
## Cause
Since https://github.com/odoo/enterprise/commit/45f28f6c288f5213a4e29c816ec68d2c3966b55f, the `next_date_1st` is evaluated by taking the last day of the month/year and incrementing it by one day, to reach the first day of the next month/year.
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/sale_subscription/models/sale_order_line.py#L377-L382
This is inaccurate when working with recurring plan which are not monthly/yearly, as it will always set the `next_date_1st` to the next month/year, without taking in account the `billing_period_value`.
## Fix
There are two ways to align dates to the period start. Given a subscription starting on January 15, with a billing period of 3 months, we could:
1. Invoice from January 15 to January 31, then from February 1 to April 30. This aligns the invoice to the closest month, then apply the 3 months period for the next invoices.
2. Invoice from January 15 to March 31, then from April 1 to June 30. This applies most of the billing period for the first invoice, while still aligning it to the start of the month, then apply the 3 months period normally for the next invoices.
**Here, we chose the second option** to avoid making the code more complex and keep the diff minimal.
opw-6151530
Forward-Port-Of: odoo/enterprise#115830This update fixes an issue where manually set lot quantities in manufacturing orders weren't being applied correctly. Previously, the system was incorrectly calculating quantities based on available lot stock, leading to inaccurate consumption. This change ensures that manually specified lot quantities are accurately reflected in the manufacturing order's move lines.
Original PR description
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for…
**Issue** Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order. **Steps to reproduce** - Create a storable product P tracked by lot - Create two lots for product P with 2 units each - Create a MO for a product consuming two units P and confirm it - On the raw move, manually set 1 unit for each lot - Click on "Produce All" - Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each **Cause** While producing: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line: - Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297 - Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity **Solution** Assume that raw move lines being created in mrp without changing the producing quantity are manually created opw-5946439 Forward-Port-Of: odoo/odoo#260518 Forward-Port-Of: odoo/odoo#257258
This update resolves an issue where error messages from the IAP (Internet Access Point) were not being displayed correctly after adapting the code to the new ASPone API. The fix ensures that errors are now properly presented, improving the user experience and troubleshooting capabilities.
Original PR description
When adapting the code to ASPone new rest api, errors were no more well handled, this fix aims to correctly display the errors we get from IAP task-5955980
1 change
Resolved issues and error corrections
This update resolves an issue where the website publish toggle on job positions initially displayed incorrect status. The change ensures the form autosave accurately reflects the published state immediately after the toggle is clicked, improving the user experience.
Original PR description
Steps to reproduce: 1. Install `website_hr_recruitment` 2. Create a job position from form view 3. Click on Published toggle button Issue: - Publishing a job position from the `hr.job` form is…
Steps to reproduce: 1. Install `website_hr_recruitment` 2. Create a job position from form view 3. Click on Published toggle button Issue: - Publishing a job position from the `hr.job` form is showing an incorrect first-click result: the website page is actually published, but the form autosave response still return `website_published = false`, so the toggle flips back to unpublished until the next refresh. Cause: - In v19.0, `website.published.mixin.write()` was effectively a thin wrapper around `super().write()`. The backend autosave path used by boolean toggles (`web_save`) performs a `write()` and then an immediate `web_read()` in the same request, and that simple flow returned the fresh publish state. - In saas-19.1, the publish flow became more complex: - `website.published.mixin.write()` now triggers `_finalize_publication()` - `_finalize_publication()` performs an additional internal `write()` - The record is published correctly, but the immediate `web_save()` readback can still use cached values for `website_published` from the same ORM environment. This makes the first form response inconsistent with the actual state. Solution: - Invalidating `website_published` field after the`write()` in `_finalize_publication()` so the immediate `web_read()` performed by `web_save()` returns the real post-write state on the first click. opw-6012359
4 changes
Resolved issues and error corrections
This update resolves an issue where commission plans with negative target values caused a system error. The fix ensures the commission plan generation process can handle negative targets correctly, preventing errors and improving the flexibility of commission plan configuration. This change enhances the reliability of sales commission calculations.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_commission 2. Create a commission plan based on targets 3. Try to add a new commission level with negative targets Issue: ------ Adding a commission level with a negative target results in a ```python RangeError: Maximum call stack size exceeded. ``` Cause: ------ https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/sale_commission/static/src/js/commission_plan_graph/commission_plan_graph.js#L50-L56 Negative target values caused infinite recursion in the GCD function, leading to this `RangeError`. Solution: ----------- Since the Euclidean algorithm only works correctly with non-negative integers, apply Math.abs() on both inputs before the recursion starts. This ensures negative targets are handled gracefully without causing infinite recursion. **NOTE:** Backport: c0d748f opw-6182644 Forward-Port-Of: odoo/enterprise#116050
This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices. Specifically, a problem with how the system handled multiple currency lines during reconciliation was addressed. Now, the balance is consistently shown, regardless of the number of lines or currencies involved.
Original PR description
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366 Forward-Port-Of: odoo/enterprise#115101
This update resolves an issue where the Mod 349 tax report incorrectly excluded vendor bills with amounts less than 1 Euro. The fix adjusts a calculation to ensure these small amounts are properly displayed, improving the accuracy of tax reporting for Spanish businesses. This ensures compliance and accurate financial data.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#116102 Forward-Port-Of: odoo/enterprise#114776
This update resolves an issue preventing users from modifying warehouse routes in the Romanian (RO) version of Odoo. The fix addresses a bug where an error occurred when changing routes, blocking modifications. This ensures multi-step routes can be updated without disruption.
Original PR description
### Issue: When changing the routes of a Romanian warehouse, an error is raised, blocking any modification of multi-step routes ### Cause: The code attempts to access `in_type_id` from `warehouse_data` However, when updating routes, `warehouse_data` is empty in the method `_create_or_update_sequences_and_picking_types` This leads to a crash because the code assumes that `warehouse_data` always contains `in_type_id` and `out_type_id` Additionally, even if the data were present, it would result in creating duplicate `stock.picking.type` records ### Steps to reproduce: - Install `l10n_ro_saft_stock` with demo data and switch to `RO Company` - Enable `Multi-steps Routes` in Settings - Try to modify Incoming or Outgoing Shipments on a warehouse - When saving, the following error is raised: "Oh snap! in_type_id" odoo-pr: https://github.com/odoo/odoo/pull/257293 opw-5925087 Forward-Port-Of: odoo/enterprise#114166
4 changes
Resolved issues and error corrections
This update fixes a limitation in how Odoo Enterprise updates its UNSPSC product codes. Previously, new codes could only be added during initial installation, not subsequent updates. Now, an automated upgrade script runs on module updates, ensuring the database always reflects the latest UNSPSC codes. Existing product codes remain unchanged.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#112652
This update resolves an issue where commission plans with negative target values caused a system error. The fix ensures the commission plan generation process can handle negative targets correctly, preventing errors and allowing for more flexible commission plan configurations. This improves the reliability of sales commission calculations.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_commission 2. Create a commission plan based on targets 3. Try to add a new commission level with negative targets Issue: ------ Adding a commission level with a negative target results in a ```python RangeError: Maximum call stack size exceeded. ``` Cause: ------ https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/sale_commission/static/src/js/commission_plan_graph/commission_plan_graph.js#L50-L56 Negative target values caused infinite recursion in the GCD function, leading to this `RangeError`. Solution: ----------- Since the Euclidean algorithm only works correctly with non-negative integers, apply Math.abs() on both inputs before the recursion starts. This ensures negative targets are handled gracefully without causing infinite recursion. **NOTE:** Backport: c0d748f opw-6182644 Forward-Port-Of: odoo/enterprise#116050
This update corrects a bug in the Mod 349 tax report for Spanish businesses. Previously, amounts under 1 Euro were not displayed correctly. The fix ensures that all financial lines, regardless of their value, are accurately included in the report, improving data accuracy for tax reporting.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#116102 Forward-Port-Of: odoo/enterprise#114776
This update resolves a bug that prevented users from merging mailing lists, resulting in an error message. The fix ensures that the system correctly identifies and accesses mailing list IDs during the merge process, improving the reliability of this key feature. This change avoids a frustrating user experience.
Original PR description
Currently, error occurs when user tries to merge a mailing list. Steps to replicate: - Install `mass_mailing`. - Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view. - Select…
Currently, error occurs when user tries to merge a mailing list.
Steps to replicate:
- Install `mass_mailing`.
- Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view.
- Select a single record, and from cog menu Click merge.
Warning:
```
odoo.http: Record does not exist or has been deleted.
(Record: mailing.list(6,), User: 2)
```
Cause:
- When the user clicks Merge, the `mailing.list.merge` form opens and `default_get()` is executed to populate defaults.
- At this point, `src_list_ids` is added to res in a structured format like `[(6, 0, ids)]` [1].
- Later, `res.get('src_list_ids')` is reused and assigned to `src_list_ids` [2].
- Taking `src_list_ids[0]` [3] returns `(6, 0, ids)`, and its first element `6` is incorrectly treated as a record ID and assigned to `dest_list_id`.
- This leads to an attempt to access a record with ID 6, which does not exist, causing the error.
Solution:
- Instead of reading `src_list_ids` back from `res` after it has been set, we initialize and reuse local variables (src_list_ids, active_ids) at the beginning of the method.
- This avoids relying on transformed values in `res` and ensures that `dest_list_id` is computed using a consistent and valid list record IDs.
[1]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L20-L22
[2]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L24
[3]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L26
sentry-7447326420
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#2624664 changes
Resolved issues and error corrections
This update fixes a limitation in how Odoo Enterprise manages its UNSPSC product codes. Previously, new codes required a full module reinstall. Now, an automated upgrade script triggered during module updates adds missing codes to the database, ensuring the system always reflects the latest industry standards. Existing product codes remain unchanged.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#112652
This update resolves an issue where commission plans with negative target values caused errors. The fix ensures the commission calculation logic handles negative targets correctly by applying absolute values within the calculation process. This expands the flexibility of commission plan setup.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_commission 2. Create a commission plan based on targets 3. Try to add a new commission level with negative targets Issue: ------ Adding a commission level with a negative target results in a ```python RangeError: Maximum call stack size exceeded. ``` Cause: ------ https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/sale_commission/static/src/js/commission_plan_graph/commission_plan_graph.js#L50-L56 Negative target values caused infinite recursion in the GCD function, leading to this `RangeError`. Solution: ----------- Since the Euclidean algorithm only works correctly with non-negative integers, apply Math.abs() on both inputs before the recursion starts. This ensures negative targets are handled gracefully without causing infinite recursion. **NOTE:** Backport: c0d748f opw-6182644 Forward-Port-Of: odoo/enterprise#116050
This update fixes an issue where CodaBox statements were sometimes incorrectly routed to the wrong bank journal due to currency differences. The system now prioritizes journals with explicit currency IDs, ensuring statements are accurately assigned to the correct currency-specific account. This prevents financial discrepancies and improves the reliability of CodaBox data import.
Original PR description
When several journals share the same IBAN but use different currencies, a CODA could land on the wrong journal instead of the currency-specific one. Split the lookup in two passes: first a journal with an explicit currency_id matching the CODA, then fall back to the no-currency journal (qualified by the company currency). Steps to reproduce: - Create 2 bank journals sharing the same IBAN; one without currency and one with USD. - Setup CodaBox connection and retrieve USD statements. - Before this fix: may land on the EUR journal. opw-6048931 Forward-Port-Of: odoo/enterprise#116228 Forward-Port-Of: odoo/enterprise#114590
This update fixes an issue where Colorado state income tax calculations resulted in a positive value on payslips, which is incorrect. The fix aligns with established payroll tax principles, ensuring that taxes are always withheld from employee paychecks, not returned as refunds. This ensures accurate payroll reporting and compliance.
Original PR description
## Issue When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive. ## Steps to reproduce 1. Install *United States - Payroll*…
## Issue
When generating a payslip for an employee of a company located in Colorado, the *CO State Income Tax* could end up positive.
## Steps to reproduce
1. Install *United States - Payroll* (`l10n_us_hr_payroll`)
2. Set the current company's State to Colorado
3. Create an employee and a contract
- Wage: $0
- (Set the contract's status to *Running*)
- (In the payroll tab) State Withholding Allowance: $1000
4. Create a Payslip for the employee
- Structure: *"United States: Regular Pay"*
5. Compute Sheet
6. **In the _Salary Computation_ tab, the _CO State Income Tax_ line has a positive value**
## Justification
This fix is similar to the one applied for the AL(abama) state income tax by https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6. That modification was justified by CAS (PO of US localizations for Payroll) in opw-5137280:
> *"Payroll taxes are always funds withheld from employee's paychecks, if there is a positive value it means the tax is a refund, not a withholding. Refunds happen when individuals file their income."*
## Note to reviewer
The test [`test_069_al_state_tax_0_income`](https://github.com/odoo/enterprise/blob/219d2a797ee2099c9d77c2defc9c9c5e1d504ffe/test_l10n_us_hr_payroll_account/tests/test_salary_rules.py#L957-L989) (added by the aforementioned commit https://github.com/odoo/enterprise/commit/f0eeb55f1e3cf965c6a409675813d4a699e5fca6) is wrongly indented and thus never executed. The test passes with the dedicated fix, and fails without it, as expected. Let me know if you want me to indent it correctly (in this commit or in an additional one).
opw-5999856
Forward-Port-Of: odoo/enterprise#11272434 changes
New functionality added to Odoo
This update simplifies and expands Odoo's reporting capabilities. It removes a technical limitation forcing the use of a single reporting engine and introduces a new Paper-Muncher engine. Users can now choose their preferred reporting engine based on the report type, offering greater customization and control over financial reporting.
Original PR description
Description of the issue/feature this PR addresses:
We currently force the use of WKHTML, since it's hardcoded we can't add new reporting engines easily.
The main goal of this PR is to be able to :
modularize the reporting engines
make accounting use the same generation pipeline
add a new reporting engine for paper-muncher
allow user to choose their reporting engine by company/action report/accounting reportEnhancements to existing features
This update simplifies the product list view used by sales teams, making it easier to understand key information. Specifically, irrelevant fields have been hidden and aggregation on the 'version' field has been disabled to prevent misleading totals. This change improves clarity and usability for sales users.
Original PR description
Simplify product views by hiding non-relevant fields and improving clarity for sales users. - Disable aggregation on version field to avoid misleading totals task-6131606
Resolved issues and error corrections
This update addresses a change in Sendcloud's API, ensuring our system continues to reliably process deliveries. By adding a specific API key, we maintain compatibility with Sendcloud's older version, guaranteeing a seamless transition for our users and accurate delivery tracking. Future work will focus on upgrading to the latest Sendcloud API.
Original PR description
Sendcloud pass their api v2 to maintenance and only provide new api V3 key to the new customers. In order to make a smooth transition for the user we add the partner key, so they know that the customer are coming from odoo and they use the v2 api. Future work will be done to upgrade our module and support the v3. API key. Forward-Port-Of: odoo/enterprise#115999 Forward-Port-Of: odoo/enterprise#114441
This update resolves issues with how tracking information is embedded in messages, particularly within emails and notifications. The changes improve the reliability of tracking data and ensure consistent display of tracking values, leading to more accurate reporting and data analysis. The team has addressed formatting inconsistencies and test failures related to tracking message types.
Original PR description
Since [1] trackings are embed in message body. This PR provides various fixes and improvements following the merge of the revamped implementation. See commits for more details. Task-6128706 [1] See odoo/odoo#235719 and odoo/enterprise#99500 Forward-Port-Of: odoo/enterprise#115664
This update fixes an issue where users could select customers from different companies within the Helpdesk system. The fix involved adding a restriction to the customer selection process, ensuring users only see customers within their assigned company. This improves data accuracy and prevents errors in ticket management.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#116157 Forward-Port-Of: odoo/enterprise#111909
This update resolves a bug that caused bank reconciliation balances to reset to zero after editing a bank move line when using multiple currencies. The fix ensures accurate balance calculations during bank reconciliation processes, improving financial reporting reliability.
Original PR description
Fixed an issue where when editing a move line for the bank reconciliation and setting the currency to a currency other than the company's currency if we edit the move line again we will find that the balance is equal to 0. task-6037835 Forward-Port-Of: odoo/enterprise#114898
This update resolves an issue causing incorrect rounding when importing purchase orders processed through OCR. The fix restores the original rounding precision, which was designed for EDI, rather than the OCR process. This ensures accurate financial calculations for purchase order imports.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116141 Forward-Port-Of: odoo/enterprise#116021
A bug in the testing process was causing tests to fail when demo data was loaded. This was due to a duplicate IoT Box record existing in both the test setup and the demo data. This fix resolves the conflict, ensuring tests run correctly and reliably.
Original PR description
We define an IoT Box record in tests with name "Shop". Another IoT Box with this name is defined in the demo data of the module. As a result, when tests are started with demo data loaded, we tend to click on the first IoT Box record with whis name, which correspond to the one from demo data. Some tests are then failing as they can't find device record defined in the test setup. related: odoo/enterprise#96760 Forward-Port-Of: odoo/enterprise#116234
This update adjusts the placement of editable value pencils in reports, moving them to the right of the data for a more intuitive and user-friendly experience. All report values have been aligned to the right, ensuring consistent readability regardless of whether a value is editable.
Original PR description
The UI for editable values in reports was recently revamped. Currently, the pencil icon for editing the values is awkwardly positioned between the text and the value of a line in a report. This change moves the pencil to the right of any editable values. All report values have been shifted so that they are still right-aligned, regardless of whether they are editable or not. task-6086452 Forward-Port-Of: odoo/enterprise#113535
This update fixes an issue where Amazon order-related stock moves incorrectly displayed 'False' as their reference. The change updates the system to use the 'reference' field, which is automatically calculated, ensuring accurate tracking of Amazon orders within the stock management system. This resolves a potential reporting discrepancy.
Original PR description
Issue ----- Commit d0c1e78 removed the `name` field of `stock.move`. Instead, we now use the `reference`field, which is computed in `_compute_reference` https://github.com/odoo/odoo/blob/2ec714b19e2c56bff965ab32f7e6a4485df2d247/addons/stock/models/stock_move.py#L357-L369 The problem is that there is no picking linked to the move, so `move.reference` is set to `False`. This means that, after we go through the override in `sale_amazon`, we end up with `Amazon move: False` https://github.com/odoo/enterprise/blob/596d8c1216b33c1f73feb8f60eef1b69a2164579/sale_amazon/models/stock_move.py#L10-L14 ----- Ticket: opw-5969357 Forward-Port-Of: odoo/enterprise#116109 Forward-Port-Of: odoo/enterprise#114345
This update fixes an issue where the valid date range for emission factors wasn't being displayed correctly. The missing 'always_range' option was the root cause, now resolved to ensure accurate date information is shown to users. This improves the reliability of ESG reporting data.
Original PR description
Before this commit, the validity period was not correctly displayed because the always_range option was missing no related task Forward-Port-Of: odoo/enterprise#115832 Forward-Port-Of: odoo/enterprise#114784
This update resolves an error preventing the import of emissions data related to journal entries. The fix restricts imports to manual emissions, streamlining the reporting process and addressing a technical limitation. This ensures accurate ESG reporting by preventing import errors.
Original PR description
The import button is present in the Emitted Emissions menu, but it produces the following error: "cannot insert into view 'esg_carbon_emission_report' DETAIL: Views containing UNION, INTERSECT, or EXCEPT are not automatically updatable." => To fix this, we will only allow the insertion of manual emissions (model: other.emission) via import, not emissions related to journal entries. task-6168587 Forward-Port-Of: odoo/enterprise#116092 Forward-Port-Of: odoo/enterprise#115306
This update corrects a minor issue where the 'unfold all' option was incorrectly applied during the export of aged receivable reports (like PDFs). Previously, this resulted in overly complex reports. This fix ensures that reports are generated with the correct level of detail, improving report clarity and usability.
Original PR description
This commit introduced a small issue: https://github.com/odoo/enterprise/commit/40484f985f511edd7ba2ae759ce63ef564bcf1f7 When exporting a report (the aged receivable in pdf for example), the option key "unfold_all" was set but shouldn't be. Forward-Port-Of: odoo/enterprise#115985
This update resolves a tour test failure in the HR contract salary module. The issue was caused by a missing employee type configuration, which prevented the tour from running correctly. This fix ensures the tour test passes, indicating proper functionality for salary configurations.
Original PR description
tour test is failing without employee_type task-6186664 Forward-Port-Of: odoo/enterprise#116057
A recent issue prevented non-administrator users from importing websites due to restricted access to a key database model. This update grants read-only access to a broader group of users, allowing the website import process to function correctly for everyone. The change ensures a smoother experience for all users importing websites.
Original PR description
Steps to reproduce: =================== 1. On a 19.1, launch a website import as admin 2. Log in as a non-admin internal user => AccessError on website_generator.request Cause: ====== The website generator systray polls `website_generator.request` on every page load: https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/website_generator/static/src/systray_items/generator_request.js#L48 Only `base.group_system` had access on the model, so any non-admin user hit an AccessError as soon as an import request existed (session_info sets show_scraper_systray=True for everyone based on the last request's notified flag). Solution: ========= Grant read-only access to `base.group_user`; writes/creates stay restricted to system so the import flow itself is unchanged. => Systray loads silently, shows status indicator opw-6092411 Forward-Port-Of: odoo/enterprise#114879
This update fixes a problem where the 'attach file' button wasn't working correctly in the Enterprise version of Odoo. The change ensures the button is enabled only after the email thread has fully loaded, improving the user experience and preventing errors when attempting to attach files.
Original PR description
Wait for the attach file button to be enabled, meaning that the thread is loaded. PR community: https://github.com/odoo/odoo/pull/262018 Forward-Port-Of: odoo/enterprise#115658
This update ensures that barcode validations in the stock picking process correctly check if a destination has been scanned, even when 'Force a destination' is enabled. Previously, the validation wasn't triggered, now it will confirm a destination was set before validating the picking, ensuring accurate inventory tracking.
Original PR description
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a…
### Steps to reproduce: - In the settings: Enable "Storage Locations" - Inventory > Configuration > Warehouse Management > Operation Types - On receipts, in the Barcode App tab enable: "Force a destination on all products" - Open the barcode app, create a new receipt - Scan a product > Validate #### > You are not blocked by the fact that you did not scan any destination even just to validate the default one ### Cause of the issue: The `barcode_validation_after_dest_location` operation type setting is not used at any point in the barcode app. ### Note: Line in the barcode app are always created a with a `location_dest_id`: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1310-L1322 In particular, even if the setting says: Force a destination on all products. It should rather be interpreted as force a destination scan before validation. Note that a destination scan will not necessarily update a single line but rather all concerned lines at once: https://github.com/odoo/enterprise/blob/a220fc61d9076decdb987421df9330a1c2c20546/stock_barcode/static/src/models/barcode_picking_model.js#L1558-L1576 It is therefore a valid call to check if a location dest was scanned to determine if the a destination was set on each product before validation of the picking, even if it is just to confirm the default destination. ### Note 2: We modify the `_get_barcode_config` to only provide a `barcode_validation_after_dest_location` if locations re enabled otherwise users enabling the option without the ability to scan locations would be soft lock and unable to validate their picking. That same logic already being applied to the `restrict_scan_dest_location` config parameter: https://github.com/odoo/enterprise/blob/6afe02e3e836df2822d7cae8aebbd5bdde6b34cc/stock_barcode/models/stock_picking_type.py#L109 opw-6110690 Forward-Port-Of: odoo/enterprise#115723 Forward-Port-Of: odoo/enterprise#114429
This update corrects a previous issue where payslips were incorrectly referencing contract dates instead of the version's dates. The fix ensures payslips accurately reflect the correct payroll version, improving data consistency and reporting. This change was enabled by a related update to search functionality.
Original PR description
Prior to this commit, the version domain on payslips only looked at the contract dates rather than the version's dates. The domain was fixed in this commit to limit the domain based on the version's dates instead, and this was allowed after the searches on the version date_start and date_end fields were fixed in the odoo/odoo#256581. task-6067139 Forward-Port-Of: odoo/enterprise#113818
This update fixes an issue where stock synchronization with Amazon was failing due to incorrect fulfillment channel data. The system now uses a more reliable field from the Amazon Listings API to determine availability, defaulting to FBM when necessary to ensure continued synchronization. The update also improves the process of updating FBM stock to respect user-specific configurations.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#116285 Forward-Port-Of: odoo/enterprise#114473
This update corrects a calculation issue related to Pay-For-Account (PFA) and Daily Pay Value (DPV) in the Belgian payroll module. Separating these calculations ensures more accurate payroll processing and compliance with Belgian tax regulations. This change improves the reliability of payroll reports and reduces potential errors.
Original PR description
Forward-Port-Of: odoo/enterprise#116236 Forward-Port-Of: odoo/enterprise#113385
This update fixes an issue where users couldn't delete time off requests after a payslip had been validated. Previously, the system incorrectly blocked deletion, even if the time off wasn't impacting the payslip calculation. Now, time off requests can be deleted regardless of payslip validation status, streamlining payroll processes.
Original PR description
## Issue After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved. ##…
## Issue
After confirming a payslip for a period, no time off request within that period can be deleted, even though requests are ont taken into account in the payslip if they are not approved.
## Steps to reproduce
1. Install *Time Off in Payslips* (`hr_payroll_holidays`)
2. Create or use an employee E with a running contract, e.g.:
- Contract: Jan 1 to Indefinite
- Wage: $1000/month
3. In Time Off > Management > Time off, create a new time off allocation for Employee E:
- Date: anywhere during March
- **Do not validate the time off**
4. In Payroll > Payslips, create a new Off-Cycle for Employee E:
- Period: March 1 - March 31
- *Compute Sheet*, *Confirm* and *Mark as paid*
5. Try to delete the allocation created in step 3
6. **An error occurs: _"The pay of the month is already validated with this day included. If you need to adapt, please refer to HR."_, even though the time off is not taken into account in the payslip.**
## Cause
The condition to raise the error message does not take into account the state of the leave:
https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/hr_payroll_holidays/models/hr_leave.py#L195-L204
This commit completes https://github.com/odoo/enterprise/pull/114895, which was preventing the error from being raised when time off were generated after validating the payslip. The error should also not be raised for leaves that are not approved yet, as they did not impact the generation of the payslip.
(related to)
opw-6089990
Forward-Port-Of: odoo/enterprise#116024
Forward-Port-Of: odoo/enterprise#115765This update ensures Odoo's Dutch reporting modules (SBR) correctly submit data to the new Digipoort infrastructure, effective May 1, 2026. The change updates URLs and clarifies certificate requirements, preventing submission failures. This is crucial for accurate reporting and compliance with Dutch regulations.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#115668This update resolves an issue where the softphone tour started with the wrong tab, causing confusion during initial use. The fix ensures the softphone displays the 'recent calls' tab immediately upon opening, improving the user experience. It addresses a minor display problem that could have impacted tour flow.
Original PR description
Commit [1] made the softphone to show recent tab when there are missed calls. Commit [2] changed the demo data to contain 1 missed call. As a result, now when you open the softphone for the first time, you will see recent tab instead of the keypad tab before. This causes issues when a tour starts with switching to, for example, contacts tab, and then do a search for something immediatly. This is because that `input[id='o-voip-Tab-searchInput']` can be found on both recent and contacts tab. It can happen that we do the search before the dom change finished. To avoid that, we add extra check to make sure we have changed to the tab we want. [1]: c995b7df3fc6ff541dc65d8b28661ab03f4a8c08 [2]: f16faa029220ca7152289180c4de78783bab03be Forward-Port-Of: odoo/enterprise#116239
This update resolves an issue where the last column of accounting reports was partially cut off when scrolling to the bottom. Adding bottom padding ensures all data is visible and accessible, improving the clarity and usability of these reports. This change was implemented to address a visual discrepancy impacting report accuracy.
Original PR description
Before this commit, there was no bottom padding in the accounting reports, which caused the last column’s values to appear partially cut off when scrolling to the bottom. This issue started occurring after the PR: https://github.com/odoo/enterprise/pull/99198 opw-6130981 **Before fix (runbot)** <img width="1920" height="1005" alt="image" src="https://github.com/user-attachments/assets/808bbb2b-3b4e-4b5c-a872-b8bd7bf589ba" /> **After fix:** <img width="1917" height="1006" alt="image" src="https://github.com/user-attachments/assets/55f04e1f-0469-46e1-af69-f5055a7232d9" /> Forward-Port-Of: odoo/enterprise#116329 Forward-Port-Of: odoo/enterprise#116168
This update fixes an issue where list header labels in Odoo's spreadsheet edition stopped translating correctly. The change allows for more flexible header labels, defaulting to translated display names when needed, ensuring consistent and accurate translations across different languages for spreadsheet pivots.
Original PR description
**Description** With odoo/odoo#247578, we were storing static column names in the list definition during migration and list insertion. As a result, list header labels stopped being translatable. This…
**Description** With odoo/odoo#247578, we were storing static column names in the list definition during migration and list insertion. As a result, list header labels stopped being translatable. This was originally done because spreadsheet pivots created from list ranges can break when translated headers change from one language to another. In this commit: - make `string` optional in list column definitions so headers fall back to the translated field display name when no explicit label is stored - keep explicit/custom labels by storing `string` only when a stable header is really needed - update list migration, insertion, and reinsertion flows so they no longer force static labels by default - simplify the list side panel so users can choose between the automatic translated label and a custom stored label - when creating a spreadsheet pivot from a list range in multi-language mode, automatically store the current displayed labels only for the list columns used by that pivot so the pivot stays stable across languages Task: 247578 Forward-Port-Of: odoo/enterprise#115411
This update resolves an issue where multiple users were incorrectly added to Whatsapp discussion channels after a message was sent. The fix ensures that only the user who initiated the conversation is added, preventing unnecessary notifications and channel clutter. This improves the user experience and channel management efficiency.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138 Forward-Port-Of: odoo/enterprise#114912 Forward-Port-Of: odoo/enterprise#102452
This update resolves an issue where the purchase dashboard's spreadsheet data was misconfigured, leading to inaccurate reporting. The fix ensures the correct pivot ID is used in the formulas, resulting in more reliable purchase data visualization. This improves the accuracy of the dashboard for business insights.
Original PR description
This commits fixes the pivot id in some formulas. Task: 5875749 Forward-Port-Of: odoo/enterprise#116110 Forward-Port-Of: odoo/enterprise#114559
This update resolves an issue causing instability in the overtime ruleset tour within the Odoo Enterprise system. By removing redundant steps and improving the tour's selection process, the system is now more reliable and predictable. This ensures a smoother user experience when configuring overtime rules.
Original PR description
This commit stabilizes the 'overtime_ruleset_flow' tour by making the following adjustments: - Updated the wage field selector to be less fragile (removed nth-child dependency). - Removed a redundant dropdown selection step that was causing potential timing issues. - Removed the 'undeterministicTour_doNotCopy' flag to mark the tour as stable.
This update resolves an issue where the Mod347 BOE export incorrectly included Spanish companies with invoices below a certain amount. The fix removes a redundant search that was adding these companies to the export, ensuring the BOE only contains partners as defined by the primary reporting requirements. This prevents inaccurate reporting to the Spanish tax authority.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#116387 Forward-Port-Of: odoo/enterprise#110947
This update corrects a problem with the Intrastat CSV export that occurred after a recent technical update. The fix ensures accurate data reporting by resolving an issue where commodity flow codes were incorrectly formatted and by updating database connections. This prevents data discrepancies in Intrastat reports.
Original PR description
Since the technical refactoring of intrastat in 18.0, the csv export in `l10n_nl_intrastat` seems broken. Here is the fixes done in this commit: 1. `Commodity flow` is supposed to be a single diggit (6 or 7) but an empty blank space was hidden. 2. Switching the condition on `country_origin_code` as it was the opposite 3. Add a `flush_all` before calling the report during the export, to be sure the database is up to date. opw-5799126 Forward-Port-Of: odoo/enterprise#116230 Forward-Port-Of: odoo/enterprise#115791
This update resolves an issue where adding certain attachments (like images) to invoices caused a system crash during the 'Send & Print' process. The fix prevents the system from incorrectly syncing orphaned attachments, ensuring invoices can be printed without errors. This improves invoice processing reliability.
Original PR description
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError:…
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError: `proforma_pdf_attachment` Cause: Adding an image via log note sets it as the main attachment, but it is intentionally orphaned (res_model=False) to prevent UI clutter. `documents_account` incorrectly syncs this unlinked file, creating a workspace document with a missing model. During "Send & Print", the official invoice PDF replaces the image as the main attachment. The document versioning logic intercepts this swap and attempts to re-parent the new PDF to match the orphaned document. This destroys the PDF's linkage to the invoice, causing a crash when the system later attempts to fetch the PDF. Solution: Since the base module now suppresses premature document creation during the message post, we explicitly handle the sync ourselves. We override `_fix_attachments_on_record_from_files_data` to iterate over the validated attachments and trigger document creation only for files that retained their `res_model`. We also add a check inside `_update_or_create_document` to strictly block orphaned attachments. opw-5930888 Forward-Port-Of: odoo/enterprise#116397 Forward-Port-Of: odoo/enterprise#115065
This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices. Specifically, a problem with how the system handled multiple currency lines led to incorrect balance calculations and hidden displays. The fix ensures accurate balance calculations and visibility during reconciliation processes.
Original PR description
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366 Forward-Port-Of: odoo/enterprise#115101
This update clarifies how customer credits are displayed and used during invoicing. Previously, credits weren't shown on the PaymentScreen and invoices incorrectly reflected total due. Now, the system automatically reconciles credits in invoices, ensuring accurate payment tracking and a clearer view of customer balances.
Original PR description
Before this commit: =================== - There were no details of customer credits on the PaymentScreen - Also, when we use the customer credits and print an invoice, it shows that amount paid as `Total Due` instead of `Paid using Customer Account.` After this commit: ================== - In the PaymentMethod Section, for the `pay_later` type payment methods, if the order has a partner, we will display their current balance in their customer account. - If the customer has credits and uses those credits in the same session, while invoicing in a future session, we will use the reversal entry of that order. - If the customer doesn't have credits and use customer account, the invoice will be due. - If the customer has credits from the past session and uses those credits in the current session, and generates an invoice in the same session, we will auto-reconcile those credits in this invoice and mark the invoice as paid. Task: 5243233
Code cleanup and technical improvements
This update modernizes Odoo's reporting engine by making it more adaptable and user-friendly. Previously, a single engine was hardcoded, limiting the ability to add new reporting options. Now, users can select their preferred reporting engine for various reports, enhancing flexibility and future expansion.
Original PR description
We currently force the use of WKHTML, since it's hardcoded we can't add new reporting engines easily. Here, we : - modularize the reporting engines - make accounting use the same generation pipeline - allow user to choose their reporting engine by company/action report/accounting report https://github.com/odoo/odoo/pull/259626
6 changes
Resolved issues and error corrections
This update fixes a bug that caused errors when setting up expense rules with non-"Payable" debit accounts. The fix ensures the correct company information is used, resolving inconsistencies in payroll calculations and preventing misleading error messages. This improves the accuracy of expense reporting within Odoo Enterprise.
Original PR description
### Steps to reproduce: - Create a salary rule for expenses - Set a debit account for this rule with a type other than 'Payable' - Create an expense for an employee and report it for the next payslip - Create a payslip for this employee - Notice an error is shown that 'No debit account for Expenses rules' - Go to the expense rules and change the debit account type to 'Payable' - Go back to the payslip and notice the error didn't disappear and a new warning showed up ### Cause: When changing the type of an account_debit that is linked to an expense rule we will try to recompute the errors and issues but the env company will be set to be equal to the default company of the env user. So if this company is different than the payslips' company it won't be able to fetch the correct account_debit in the rule ### Fix: Access account_debit and journal_id using with_company() to make sure we get the correct company-related value. opw-6013423
This update fixes an issue where the end date on payslip PDFs was displayed incorrectly. The problem stemmed from a formatting error in the XML file, which has now been corrected to ensure consistent date presentation. This ensures accurate and professional payslip generation for employees.
Original PR description
ٍSteps: - Go to the payslip tabs under payroll app - Create a payslip and preview the generated PDF - The end date format is messed up Cause: The format was different because the end date was being overriden in the xml file and being displayed in the xml through t-out tag instead of span and t-field tags. Solution: Matching the format of the start date and end date of the payslip template. Task: 6168607
This update resolves an error that occurred when calculating overtime deductions for employees with specific filing statuses (other than 'single' or 'jointly'). The fix ensures the system handles a wider range of filing statuses correctly, preventing a crash. It improves the reliability of overtime calculations for a subset of users.
Original PR description
Issue: ---------------------------------------- When having an employee with `l10n_us_filing_status` not in `['single', 'jointly']` and evaluating the rule parameter…
Issue: ---------------------------------------- When having an employee with `l10n_us_filing_status` not in `['single', 'jointly']` and evaluating the rule parameter `l10n_us_qualified_overtime_deduction_cap` an error occurs. Cause: ---------------------------------------- `l10n_us_filing_status` can have 5 values: `['single', 'jointly', 'separately', 'head', 'survivor']` But only `['single', 'jointly']` are defined for `l10n_us_qualified_overtime_deduction_cap` ([src](https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_rule_parameters_data.xml#L48)). When running the rule "Qualified Overtime", the custom Python crashes because we read a key that is not there: https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L56 Solution: ---------------------------------------- In the custom Python condition, we first check if the key is there. The custom Python computation also tries to read the key, but it is run only if the condition is validated. So we don't need to change it. Also fixed indentation of test 069. opw-6129657
This update resolves an error that prevented users from reconciling bank statements on smaller screens (like mobile devices). The issue stemmed from incorrect data passing within the Odoo application, specifically related to how the 'Reconcile' button was handled in the bank reconciliation dialog. This change ensures the application functions correctly across all screen sizes.
Original PR description
When clicking on the "Reconcile" button of a bank statement line on a small screen (ex: mobile) threw an OwlError "Invalid props for component 'KanbanController': unknown key 'bankRecInfo'". BankRecSelectCreateDialog injected `bankRecInfo` into `baseViewProps`, which is spread into the embedded view regardless of its type. On desktop the embedded view is a list (patched to accept `bankRecInfo`), but on small screens SelectCreateDialog falls back to a kanban view, whose controller does not declare that prop, triggering Owl's props validation. Only forward `bankRecInfo` when the inner view is a list by overriding `viewProps` instead of mutating `baseViewProps`. Steps to reproduce: - Enable the developer mode. - Open Bank Reconciliation. - Resize the window to a small/mobile width (or open from a mobile device). - On a statement line, click the "Reconcile" button to open the dialog. - OwlError is thrown opw-6070573
This update resolves a bug that prevented the balance from being displayed correctly when reconciling foreign currency invoices within the bank reconciliation feature. Specifically, a problem with how the system handled multiple currency selections was corrected, ensuring accurate balance calculations and display across different reconciliation scenarios.
Original PR description
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction…
### Issue: When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected ### Cause: In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it There is no reason to block the sum of lines with the same currency When there is no selectedLines, the function returns early and doesn't unhide the balance ### Steps to reproduce: - Install `account_accountant` with demo data - Enable a foreign currency like EUR - Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€) - Go to the Dashboard, and select Bank - Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$) - Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency` - Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$) - Switch to the Kanban View and Reconcile the line Multi-currencies - Select your 2 invoices one by one Before the fix, after selecting the second invoice, the balance is displayed as `/` For the additional case: - Unselect all lines - Select a line in another currency (e.g., USD), then unselect it The balance remains hidden opw-6063366 Forward-Port-Of: odoo/enterprise#115101
This update corrects a bug in the Mod 349 report for Spanish tax filings. Previously, transactions with amounts less than 1 EUR were not displayed. The fix ensures that all financial transactions, regardless of their value, are accurately included in the report, improving data accuracy for tax compliance.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#116102 Forward-Port-Of: odoo/enterprise#114776
8 changes
Resolved issues and error corrections
This update fixes a limitation in how Odoo updates its UNSPSC product codes. Previously, new codes could only be added during initial module installation. Now, an upgrade script automatically adds new codes to the database when updates are applied, ensuring our product data remains current with industry standards.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#112652
This update optimizes the process of excluding accounts during reconciliation in Odoo. Previously, a less efficient method was used, hindering database performance. Now, users can directly override account conditions for exclusion, leading to faster and more reliable reconciliation processes.
Original PR description
See https://github.com/odoo/enterprise/pull/115581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update significantly speeds up the stock reconciliation process by optimizing how the system filters financial records. The previous method was inefficient, but a new index has been added to dramatically reduce the time it takes to process these records, improving overall system performance.
Original PR description
Currently to exclude valuation accounts from the reconciliation we modify the domain by adding a second condition on the field account_id of the account_move_line table to exclude these accounts…
Currently to exclude valuation accounts from the reconciliation we modify the domain by adding a second condition on the field account_id of the account_move_line table to exclude these accounts while including them in a first condition in the method we override.
This is not very efficient as it prevents the use of indexes on that second NOT IN condition.
Indeed PostgreSQL prioritizes the use of the index on the IN condition and then applies the NOT IN condition in a filtering step, which is very costly when there are many account_move_line records belonging to the inventory valuation accounts.
Here is an example of the before after on a database with 87 million account_move_line records total and 9.5 million account_move_line records matching the first IN condition via an index while only 1 million remain after applying the filtering of the NOT IN condition.
All measures are performed with a warmed up cache
[Explain Before](https://explain.dalibo.com/plan/d0d14efbe51ch359)
### Benchmark:
<table>
<thead>
<tr>
<th># of aml</th>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<td>87713812</td>
<td>~9s</td>
<td>~1.5s</td>
</tr>
</tbody>
</table>
[Explain After](https://explain.dalibo.com/plan/e882cf62d1ga6955)
## Potential further improvement:
Add a partial index:
```SQL
CREATE INDEX CONCURRENTLY idx_aml_company_id_account_id_unreconciled_posted
ON account_move_line (company_id, account_id)
WHERE parent_state = 'posted'
AND (reconciled IS NULL OR reconciled = FALSE)
AND (display_type IS NULL OR display_type NOT IN ('line_section', 'line_note'));
```
### Benchmark:
<table>
<thead>
<tr>
<th># of aml</th>
<th>Before</th>
<th>After</th>
</tr>
</thead>
<tbody>
<tr>
<td>87713812</td>
<td>~1.5s</td>
<td>~900ms</td>
</tr>
</tbody>
</table>
[Explain After + Index](https://explain.dalibo.com/plan/56dfdh554668ed43)
Part of https://github.com/odoo/odoo/pull/261931This update resolves an issue where icons for Studio apps weren't appearing in the activity feed. The fix ensures that icons from the Studio app are correctly rendered, improving the user experience when viewing activities related to Studio projects. This enhancement allows users to easily identify and track activities within the Studio environment.
Original PR description
Step to reproduce: 1. Install `web_studio` 2. Create two apps, one with upload image and one with fa icon 3. Both apps should have chatter 4. Now create activities from both apps 5. See Activity from…
Step to reproduce:
1. Install `web_studio`
2. Create two apps, one with upload image and one with fa icon
3. Both apps should have chatter
4. Now create activities from both apps
5. See Activity from the top right clock icon
Issue:
- Icons of studio apps are not rendered
Cause:
- As of now, we do not support studio app's icons to render in the activity tab
Solution:
- Fetch the studio_customisation app's icons from the menu
<table>
<tr>
<th colspan="2">Before</th>
</tr>
<tr>
<td colspan="2">
<img width="1127" height="289"
alt="Before"
src="https://github.com/user-attachments/assets/1c30a356-e752-4436-a429-1e0b4555045e" />
</td>
</tr>
<tr>
<th colspan="2">After</th>
</tr>
<tr>
<td colspan="2">
<img width="1152" height="295"
alt="After"
src="https://github.com/user-attachments/assets/a9981cd1-50f1-404b-8ff6-0b9e0f50a8bb" />
</td>
</tr>
</table>
opw-5848298This update resolves an issue where the stock warehouse module wasn't correctly handling existing picking type IDs during an upgrade. Specifically, when a warehouse already had an `in_type_id` or `out_type_id` set, the upgrade process would fail. This fix ensures the system properly recognizes and utilizes these existing IDs, preventing errors and maintaining data integrity.
Original PR description
The method `_create_or_update_sequences_and_picking_types()` from model `stock.warehouse` is returning data for the newly set picking types. So if warehouse has already `{in,out}_type_id` set, [this]…
The method `_create_or_update_sequences_and_picking_types()` from model `stock.warehouse` is returning data for the newly set picking types. So if warehouse has already `{in,out}_type_id` set, [this] will not return data for those picking types. It means, we might get an issue while we try to read the `{in,out}_type_id` [here].
Issue discovered during upgrade.
Steps to reproduce:
1. Install `l10n_ro_saft` and `stock_account` in 17.0
2. Upgrade to 18.0
- `l10n_ro_saft_stock` is [auto_install], so it will be installed
- `_create_or_update_sequences_and_picking_types()` will get extension from `l1on_ro_saft_stack`
- during the upgrade in this [script] it will cause traceback like this
For fixing the issue, we check if the `{in,out}_type_id` are existing in warehous_data.
```
2026-04-22 07:15:39,016 3390451 CRITICAL romanian_warehouse_test odoo.service.server: Failed to initialize database `romanian_warehouse_test`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1366, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/.pyenv/versions/3.12.2/lib/python3.12/site-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 523, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 222, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/18.0/odoo/modules/migration.py", line 259, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/upgrade/migrations/stock/saas~17.3.1.1/end-migrate.py", line 16, in migrate
new_types_vals = warehouse._create_or_update_sequences_and_picking_types()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/18.0/l10n_ro_saft_stock/models/stock_warehouse.py", line 15, in _create_or_update_sequences_and_picking_types
PickingType.browse(warehouse_data['in_type_id']).write({
~~~~~~~~~~~~~~^^^^^^^^^^^^^^
KeyError: 'in_type_id'
```
tbg-2609
[this]: https://github.com/odoo/odoo/blob/006367bed13a0145e81bf0f5105e8f51cd0610d5/addons/stock/models/stock_warehouse.py#L325
[here]: https://github.com/odoo/enterprise/blob/5acaad71fd2b75ede9df8708e54e0f988522b58a/l10n_ro_saft_stock/models/stock_warehouse.py#L10
[script]: https://github.com/odoo/upgrade/blob/4b74a6df5f3f725cbef1b9eb1d98c536ea228abe/migrations/stock/saas~17.3.1.1/end-migrate.py#L16
[auto_install]: https://github.com/odoo/enterprise/blob/a8eea67ba89bb8eb96d2843734a8e0f7f44547c9/l10n_ro_saft_stock/__manifest__.py#L25This update corrects a bug in the Mod 349 report for Spanish tax filings. Previously, amounts less than 1 Euro were incorrectly excluded, preventing the report from displaying relevant journal entries. The fix ensures that all financial lines, including those with small values, are accurately included in the report.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#114776
This update fixes an issue where the Point of Sale system wouldn't correctly manage multiple open rescue sessions. Now, when multiple sessions exist, a list view is displayed to select the appropriate one. If only one session is open, the system uses the standard direct form view for easier management.
Original PR description
When multiple rescue sessions existed for a POS config, calling `open_opened_rescue_session_form` raised a ValueError ("Expected singleton") because `.id` was accessed on a multi-record set.
Now opens a filtered list view titled "Rescue Sessions" when multiple open rescue sessions are found, and a direct form view when there is only one.
opw-6184661
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262829This update fixes an issue where users could modify product descriptions within confirmed Sales Orders. A new condition has been implemented to restrict this editing capability, ensuring data integrity and preventing potential errors in order processing. This change improves the reliability of our sales order management system.
Original PR description
## **Steps to Reproduce:** - Create a Sales Order and confirm it. - In the order lines, use the column toggle to hide the Product field. - Try editing the description of the product line. ## **With this commit:** A condition has been added to prevent editing the description when the Sales Order is in the `sale` state. Reference Video : [Video](https://drive.google.com/file/d/1wFDZDQrdhfVM9gIDfvS4TJv-Es-nNLbQ/view?usp=drive_link) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr