Daily updates from Odoo
Thursday, May 7, 2026
46 changes · saas-19.3
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
This update aligns Odoo's data with the latest ISO 3166-2 standards by adding Georgian states. The address format has also been updated to display state names instead of codes, improving data clarity and accuracy for users. This ensures consistent and reliable address information.
Original PR description
Added the states in Georgia to align with official ISO 3166-2 standards. task-6119824 Forward-Port-Of: odoo/odoo#261689
This update backports the PL Bank Account Verification feature, which allows businesses to securely verify bank accounts against Polish government APIs. This improves compliance with local regulations and streamlines the process of connecting bank accounts within the Odoo system. It builds upon previous work tracked in odoo/odoo#250400.
Original PR description
[ADD] l10n_pl_bank_verification: Backport bank account verification Backport of the feature that implements PL Bank Account Verification against the government API See odoo/odoo#250400 task-4637086 Forward-Port-Of: odoo/odoo#262518
Enhancements to existing features
This update enhances the display of online order notifications on smaller devices. By using a full-width layout and improved alignment, the notifications are now more visible and easier to read for customers. This ensures a better user experience when placing orders through the online portal.
Original PR description
In this commit: ------------------- - Use a full-width layout on small screens by removing container padding and improving alignment with `justify-content-between`. task: 6054267 Forward-Port-Of: odoo/enterprise#111614
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
This update corrects a previous issue where reminder attachments were incorrectly set to lower follow-up levels for invoices. The change ensures that invoices are always linked to the correct follow-up level, improving the accuracy of reminder workflows and preventing mismatched alerts. This enhances the reliability of our accounting processes.
Original PR description
Previously(https://github.com/odoo/enterprise/commit/105d3bff49d486b8ecd943e77d635fe011b5e361), `_update_followup_line_on_move_lines` could downgrade AMLs when executed with a lower follow-up level, as all lines were recomputed without considering their current level. Additionally, invoices with a higher follow-up level were also included in lower level reminder attachments. With this commit, `unreconciled_aml_ids` are filtered to exclude lines that already have a higher follow-up level, preventing downgrade and aligning the attachments with the triggered follow-up level.
This update resolves a few minor issues related to appointment scheduling within the Odoo Enterprise system. Specifically, it ensures resources are correctly filtered based on appointment types, addresses a warning in the search filter component, and corrects a problem where the wrong customer form was used when booking appointments from the Gantt view. These changes enhance the user experience and data accuracy.
Original PR description
1. Filter resources based on the appointment type When adding a closing day from the Gantt view, every resource could be selected, even those not related to the current appointment type. Now, if a default appointment type is set in the context, resources are filtered to only show those related to that appointment type. 2. Warning with PosAppointmentSearchFilter A console warning was logged because the empty props of the PosAppointmentSearchFilter component were not explicitly declared. 3. Change partner form view when booking from the Gantt view When creating or editing a booking from the Gantt view, we could select a customer, but the default partner form was used instead of the one already created for the PartnerList component. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6147711
This update resolves a technical glitch where a tour triggered incorrectly in the VoIP settings. The fix narrows the trigger to only activate when using the keypad tab, ensuring a smoother user experience. This prevents the tour from appearing unexpectedly.
Original PR description
Similar as [1], trigger `.o-voip-Softphone .o-voip-countryFlag` can be found on both recent and keypad tab. It's possible to find it before dom actually change to keypad tab. In this commit, we narrow down the trigger so that it can only be found on keypad tab. [1]: d838dd6dccdaeb8e9d6676ef4ccb5bbced4441a9
This update corrects a visual issue in the maintenance request form where the 'Block Workcenter' field was incorrectly positioned. The change ensures the field appears in the correct location after recent UI updates, improving the user experience. This fix addresses a minor layout discrepancy.
Original PR description
Issue: ---------------------------- In the maintenance request form view, the 'Block Workcenter' field was displayed near the priority field in the top-right corner. Steps to Reproduce:…
Issue: ---------------------------- In the maintenance request form view, the 'Block Workcenter' field was displayed near the priority field in the top-right corner. Steps to Reproduce: ---------------------------- - Install `mrp_maintenance` module. - Open a maintenance request linked to a work center. - Notice that the 'Block Workcenter' field appears beside the priority field in the top-right section. Cause of the issue: ---------------------------- Following the UI changes introduced in [PR](https://github.com/odoo/odoo/pull/251761), the position of the priority field was updated. However, the inherited XPath used for the 'Block Workcenter' field was still targeting the priority field, causing the field to be inserted at an incorrect position. With this commit: ---------------------------- Update the XPath to match the new form view structure, ensuring that the 'Block Workcenter' field is displayed in the correct location and aligned with the updated UI layout.
This update resolves an issue causing instability in the Point of Sale (POS) tour. By making the tour predictable and ensuring it correctly identifies the order, the problem is fixed. A minor typo in a test was also corrected to improve reliability.
Original PR description
Remove the `undeterministicTour_doNotCopy` key from `OrderFlowTour` and make the tour deterministic by properly selecting the order. Also, fix a typo in the assertion in `test_01_order_flow`. Task-6065459 Forward-Port-Of: odoo/enterprise#111915
This update fixes an issue where the cost of kits was incorrectly calculated in sales orders. Specifically, when a kit BoM had multiple components, the system was multiplying the cost by the batch size instead of the correct component quantity. This change ensures accurate cost calculations for kits, preventing overcharging on sales.
Original PR description
### Issue: When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360…
### Issue: When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30. ### Cause: The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`. ### Steps to Reproduce: - Costing Method = AVCO, Inventory Valuation = Automated - Comp A (cost 10), Comp B (cost 20), Kit X (cost 0) - Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B - Create and confirm a SO for 1 x Kit X - Expected SO line cost: 30 - Actual SO line cost: 360 Solution: This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs. opw-5969310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259005 Forward-Port-Of: odoo/odoo#253406
This update fixes a minor calculation error in the Swiss payroll module (l10n_ch_hr_payroll) related to the reversal of source tax. The change ensures accurate tax reporting for Swiss businesses, aligning with local regulations. This improves the reliability of payroll reporting.
Original PR description
opw 6133391 Fix for the source tax correction following PR #114463 Forward-Port-Of: odoo/enterprise#115585
This update fixes an issue where a blank box was sometimes visible on smaller screens when rental dates weren't entered. The change ensures the display is only shown when rental dates are present, improving the user experience and visual consistency across devices. This is a minor fix to enhance usability.
Original PR description
Previously, the `<div>` was displayed even when its content was hidden due to the "invisible" attribute. To fix this, we move the visibility condition to the parent. This works since the `<button>` (in charge of updating rental line prices) already has a stricter invisibility condition. Note that `.o_input_box` doesn't exist anymore. Related commit: https://github.com/odoo/enterprise/commit/7cdfe5bd1541380d746f3208bc198fb89f7cb22a
This update prevents unauthorized users from viewing or modifying assets linked to invoices. Previously, users without the correct access groups could cause errors when interacting with invoices containing assets. This change ensures only authorized users can access asset information, improving data security and preventing potential misuse.
Original PR description
Only groups `account.group_account_readonly`, `account.group_account_invoice` or higher have access to model `account.asset`, therefore if an user goes to see an invoice with assets and they are not on either group, they will receive an error and won't be able to access said invoice. How to reproduce: - Create a vendor bill - Create an account.asset and link it to said account.move - Go to the form view with an user that it's on group "Purchase: User" for example --> They get a traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#115053 Forward-Port-Of: odoo/enterprise#112890
This pull request corrects a technical issue where a duplicate email snippet template was introduced. The change removes this redundant template, ensuring consistent email formatting and preventing potential errors in mass mailing campaigns. This improves the reliability of our email communications.
Original PR description
A duplicated snippet template was introduced in a prior [commit], and is removed through this commit. [commit]: https://github.com/odoo/odoo/commit/81e43a8dd70ffa2746740f7bd5904007e76d2260 task-5959046 Forward-Port-Of: odoo/odoo#262980
This update resolves an issue where the 'Back to edit mode' link in the land portal invoice section of the Invoicing app was incorrectly directing users to the wrong application. Switching to the correct action ensures users always access the Invoicing app, improving usability and data accuracy. This was a minor fix to ensure proper functionality.
Original PR description
The "Back to edit mode" link used action_move_out_invoice_type, which isn't bound to any menu, so the backend fell back to whichever app happened to match (e.g. Website when installed) instead of Invoicing. Switch to action_move_out_invoice (the one referenced by the Invoicing menu) so the webclient resolves the correct app automatically. task-5882256 Forward-Port-Of: odoo/odoo#259263 Forward-Port-Of: odoo/odoo#257841
This update resolves an issue where inactive reports were appearing in search results, and a bug impacting VAT Return reports in the Czech language. The fix ensures accurate report filtering and correct navigation, improving the user experience and data accuracy.
Original PR description
When searching for reports through the search panel inactive reports still show up in the result, this change hide the inactive variant reports from the search result. Also, fixes a minor bug related the l10n_cz, When search for VAT Return (CZ) it would cause a bug due to missing the target report to look into. task: 6149101
This update ensures payrun steps are reliably marked as complete after the 'Continue' action. Previously, errors could linger, making it appear like steps weren't processed correctly. Now, the system validates completed steps, providing a clearer picture of payrun status and improving data accuracy.
Original PR description
## Before: - Clicking Continue moved the payrun to the next step, but the previous step could remain in `error` if anomalies were still present. - This made explicitly passed steps (version/time/attendance) look unresolved. ## After: - Continue marks the passed step as `valid`. - because if the user willfully ignore an error, then it's ok to put it as validated. - This is applied consistently for all payrun step state points. Task-6053982
This update fixes an error in the manufacturing report that incorrectly calculated quantities and costs when products were produced in different units of measure (e.g., Kg vs. Ton). The fix ensures accurate reporting of production quantities and costs, providing more reliable data for financial analysis.
Original PR description
Steps to reproduce:
- Create a product W1 with UoM = Kg with the following BoM:
- Component C1: 1 unit, cost = $1
- Create and confirm MO1:
- Produce 1 Kg of W1 → total cost = $1
- Create and confirm MO2:
- Produce 1 Ton of W1 → total cost = $1000
- Open the Manufacturing Report and group results
Problem:
- qty_produced ≈ 1.001 instead of 1001
- unit_cost average ≈ 1000 instead of 1
Expected behavior:
- qty_produced = 1001
- unit_cost average = 1 (consistent across MOs)
The manufacturing report (`mrp.report`) incorrectly converts quantities from move UoM to product UoM, leading to wrong `qty_produced` and `qty_demanded` values when different units of measure are used
The current implementation uses:
sm.quantity / uom.factor * uom_prod.factor
This inverts the conversion ratio. As a result:
- 1 Ton is converted to 0.001 Kg instead of 1000 Kg
opw-6097098
Forward-Port-Of: odoo/enterprise#116322
Forward-Port-Of: odoo/enterprise#113979This update fixes an issue where multiple documents with the same subject wouldn't all be included in the downloaded zip file. The change ensures that all signed documents with identical subjects are correctly bundled together, resolving a potential data loss scenario. This improves the reliability of the Sign app's document download feature.
Original PR description
## Issue In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file. ## Steps to reproduce 1. Install *Sign* (`sign`)…
## Issue
In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file.
## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sign a same template twice, using the same subject S1. This gives us Documents D1 an D2.
3. (Optionally), sign the same template a third time, using a different subject S2, creating document D3.
4. In Sign > Documents, select the 2 (3) signed documents and click *Download*.
5. **In the resulting zip file, there's one folder S1 containing a single pdf document (D1) (and one folder S2 containing D3). Document D2 is missing from the zip file.**
## Cause
When generating the zip file, the path used for each document is `{subject}/{doc_name}`.
https://github.com/odoo/enterprise/blob/863abc99469c12acdebcab05788d566c370bb46f/sign/controllers/main.py#L276-L286
Neither of this attribute are unique, which means that two signed documents with the same name and subject can be downloaded simultaneously, but will then overwrite each other.
## Fix
Before version 18.3, the zip file would contain folders named with the (unique) request id, which would consistently make them distinct from one another. This behavior was changed by https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b to use the `sign_request.subject` instead. This commit adds the `request.id` after the subject to keep the clarity of the subject, and add the uniqueness of the id.
opw-6143128
Forward-Port-Of: odoo/enterprise#116179
Forward-Port-Of: odoo/enterprise#116013This update corrects a problem that prevented Odoo from properly submitting Dutch VAT returns (SBR) when dealing with multiple companies within a single VAT unit. The fix ensures the correct closing entry is used, resolving a technical error that caused submission failures. This improves the reliability of the Dutch VAT reporting process.
Original PR description
In a multi-company/multi-branch setup where multiple entities form a single VAT unit, Odoo generates a closing entry for each branch/company during the tax closing process. When attempting to submit the Dutch VAT return via Digipoort (SBR), the wizard gathers these entries via `closing_move_ids`. However, the code subsequently tries to set the resulting recordset as `closing_entry_id` on `l10n_nl_reports.sbr.status.service`, which results in a traceback: `ValueError: Expected singleton: account.move(id1, id2, ...)` This occurs because `closing_entry_id` is a `Many2one` which requires a single record (singleton), but the system provides all closing moves from the tax group. This commit fixes the issue by filtering the closing moves to only target the one associated with the return company, ensuring a singleton is passed to the message posting logic. Issue introduced by: 647699eeb4b8a1cc37ca074fa57844871c5086c1 opw-6106081 Forward-Port-Of: odoo/enterprise#116237
This update resolves an error that was preventing the generation of the Swiss Master Data report. The issue stemmed from a formatting error in the report's template, which has now been corrected. This ensures accurate reporting for Swiss payroll data.
Original PR description
Currently, generating the Swiss Master Data report raises an error ### **Steps to reproduce:** 1) Install `l10n_ch_hr_payroll` with demo data. 2) Switch to a Swiss company. 3) Navigate to `Payroll >…
Currently, generating the Swiss Master Data report raises an error ### **Steps to reproduce:** 1) Install `l10n_ch_hr_payroll` with demo data. 2) Switch to a Swiss company. 3) Navigate to `Payroll > Reporting > Master Data`. 4) Create a new report and click Generate Data. ### **Error:** IndentationError: expected an indented block after 'else' statement on line 116 ### **Root Cause:** The QWeb template had a conditional block using `t-elif` followed by an empty `t-else` at [1]. During template compilation, this generated a Python `else` statement without a body, leading to an IndentationError. [1]- https://github.com/odoo/enterprise/blob/b77984b3a9fb1b35c07e152a0f86aaf4d430e2c0/l10n_ch_hr_payroll/report/l10n_ch_wage_type_report.xml#L44 ### **Fix:** This commit prevents the error by removing the empty `t-else` block and ensuring `category_ids` are properly evaluated by computing their codes and checking if they include `BASIC`, `ALW`, or `DED`. **opw-6107565** Forward-Port-Of: odoo/enterprise#113808
This pull request contains several fixes and improvements to the o_spreadsheet module, primarily focused on enhancing chart rendering and stability. These changes address issues like clipping, error messages, layout problems, and data handling, resulting in a more reliable and user-friendly spreadsheet experience. The updates improve chart visibility and prevent common errors.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d13c0d7cf6 [FIX] chart: ensure chart values remain visible (remove clipping) [Task:…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d13c0d7cf6 [FIX] chart: ensure chart values remain visible (remove clipping) [Task: 5993132](https://www.odoo.com/odoo/2328/tasks/5993132) https://github.com/odoo/o-spreadsheet/commit/59869606fd [FIX] Gauge chart: error message in the side panel [Task: 6179300](https://www.odoo.com/odoo/2328/tasks/6179300) https://github.com/odoo/o-spreadsheet/commit/64089ca63b [FIX] pivot: fix design panel layout [Task: 6148708](https://www.odoo.com/odoo/2328/tasks/6148708) https://github.com/odoo/o-spreadsheet/commit/2c7a21e5a1 [FIX] grid overlay: unhide buttons visibility [Task: 6127335](https://www.odoo.com/odoo/2328/tasks/6127335) https://github.com/odoo/o-spreadsheet/commit/ada24eeeb1 [FIX] Charts: Do not cast dates x-values as numbers [Task: 6146610](https://www.odoo.com/odoo/2328/tasks/6146610) https://github.com/odoo/o-spreadsheet/commit/af21534b71 [FIX] charts: Do not cast empty values as 'count' [Task: 6146610](https://www.odoo.com/odoo/2328/tasks/6146610) https://github.com/odoo/o-spreadsheet/commit/168e9b0bae [FIX] package: add missing types dependency [Task: 6140820](https://www.odoo.com/odoo/2328/tasks/6140820) https://github.com/odoo/o-spreadsheet/commit/a00c3c07d5 [FIX] pivot: `getPivotCellFromPosition` will throw on invalid formula [Task: 6109696](https://www.odoo.com/odoo/2328/tasks/6109696) https://github.com/odoo/o-spreadsheet/commit/f47a77b7f0 [FIX] zoom: scorecard chart rendering with zoom [Task: 6072348](https://www.odoo.com/odoo/2328/tasks/6072348) https://github.com/odoo/o-spreadsheet/commit/f031b4bd17 [FIX] format: don't humanize scientific format [Task: 6068353](https://www.odoo.com/odoo/2328/tasks/6068353) https://github.com/odoo/o-spreadsheet/commit/9c1ffd5e50 [FIX] Data filter : clear/select all button [Task: 6075166](https://www.odoo.com/odoo/2328/tasks/6075166) https://github.com/odoo/o-spreadsheet/commit/231c82e9f5 [FIX] chart: figure sometime still exist after chart deletion [Task: 6107235](https://www.odoo.com/odoo/2328/tasks/6107235) https://github.com/odoo/o-spreadsheet/commit/3fbd43465d [FIX] side_panel: preserve spaces in DV values and fix color mapping [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) https://github.com/odoo/o-spreadsheet/commit/8ae166d5d8 [FIX] side_panel: stabilize list criterion color sync [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a crash that occurred when preparing future online food delivery orders. The issue stemmed from an incorrect date format, which has now been corrected to ensure smooth preparation display functionality. This improves the reliability of order preparation workflows.
Original PR description
### In this commit: Fixes a crash in the preparation display when handling future online food delivery orders. The issue was caused by an invalid delivery time format. This is resolved by properly passing the delivery time as a Number in the utils. Task-[5960176](https://www.odoo.com/odoo/project/1737/tasks/5960176) Forward-Port-Of: odoo/enterprise#116517 Forward-Port-Of: odoo/enterprise#108298
This update resolves an issue where a key form element, `.o_input_box`, was removed from the Odoo system. The change adapts the form views for the MRP and POS Self-Order modules to ensure proper functionality and data input. This ensures these features continue to operate as expected.
Original PR description
`.o_input_box` doesn't exist anymore, and this commit adapts the form view accordingly. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes unnecessary code that previously handled multiple formats for receiving electronic invoices from Belgium (BE). Previously, the system was unsure which format to use, leading to complexity. Now, the system consistently uses the standard 0208 format, simplifying the process and improving efficiency.
Original PR description
When adding peppol, we didn't know if we needed to use the 9925:BE or 0208. Therefore, we switched between them if the endpoint was not found. This has no more use today as we use 0208. opw-5976574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261307 Forward-Port-Of: odoo/odoo#258297
This update fixes a limitation in how Odoo Enterprise updates its UNSPSC product codes. Previously, new codes required a full module installation, but now an upgrade script automatically adds missing codes to the database during module updates. Existing 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#116063 Forward-Port-Of: odoo/enterprise#112652
This update fixes an issue where the 'Time Remaining' value in task timesheets was incorrectly highlighted in red, even when the time was positive. The fix ensures the color accurately reflects negative time values, improving the clarity and usability of the timesheet. It also corrects alignment of time remaining on sales orders.
Original PR description
_* = sale_timesheet **Steps to reproduce:** - Open form view of any task. - Go to the Timesheets tab. - Observe the Time Remaining value. - Observe the Time remaining on SO. **Issue:** - The Time Remaining value becomes red even when the value is positive, which incorrectly suggests a warning. - The Time remaining on SO is not properly aligned. **Issue from :** - https://github.com/odoo/odoo/pull/192366 **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red only when the value is negative. - Positive values now display with normal styling. - Adjusted the logic to ensure Time remaining on SO is displayed properly. **Task-id: 5404009** Forward-Port-Of: odoo/odoo#239610