Daily updates from Odoo
Navigate
Branch
Monday, September 29, 2025
249 changes
25 changes
Security fixes and vulnerability patches
Shared MP4 files can no longer be previewed by anyone with a public viewer link. This prevents hosted videos from being accessible as public previews and helps avoid using Documents as a video streaming platform.
Original PR description
**Issue:** When sharing an MP4 video with "Anyone with the link" viewer access, the video is available to preview without login. **Steps to reproduce:** 1. Install documents 2. Upload an MP4 video 3. Share it with the smart button with anyone with the link viewer access 4. Copy link and paste it in incognito in chrome **Result:** - Video preview option is available **Cause:** - The method get_previewable_file_extensions allows 'mp4' videos to be previewed. **Solution:** - Remove the 'mp4' extension from the previewable list. **NOTE:** - We do not want to be 'used' as a video streaming platform. We do not do it for our own eLearning videos, so we can't do it here, Preview file should simply not be publically available for videos we host. opw-4926384 Forward-Port-Of: odoo/enterprise#90158
Enhancements to existing features
The tax search view now includes the tax amount field, so users can find taxes by entering their configured percentage or fixed amount in the search bar. This makes tax setup easier to navigate and reduces time spent locating the right tax records.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
Hong Kong Payroll users can now download the IR56B report as an XML file directly from the relevant payroll screens. This makes statutory reporting preparation easier by reducing manual steps to retrieve the required file.
Original PR description
Add ir56b report download button for downloading .xml file in Hong Kong Payroll. task - 5081474 Forward-Port-Of: odoo/enterprise#95294 Forward-Port-Of: odoo/enterprise#95013
Resolved issues and error corrections
This fixes test coverage for product barcode lookup so product weight is validated when available and the correct product variant permissions are used. It helps ensure barcode lookup product data is handled reliably without changing day-to-day user workflows.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so we can't set them. - The variant rights were not passed correctly for the first basic test. After this commit: ----------------------- - We have updated the test and checked that weight is correctly set when present in the view. - Now we have passed the correct variant right for the test. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155 Forward-Port-Of: odoo/enterprise#95590 Forward-Port-Of: odoo/enterprise#93075
This fix prevents Field Service tasks from failing when a previously created worksheet template remains after the app is uninstalled and reinstalled. User-created worksheet templates are now cleaned up during uninstall, avoiding broken template references and improving reliability for teams using worksheets.
Original PR description
When user uninstalls and reinstalls `industry_fsm` the user created template is not removed causing `model_id` for the worksheet template turning `False` and raising a key error when indexing via `model_id`. **Replication steps:** * Install `industry_fsm` * Field Service>Configuration>Settings>Enable Worksheet templates * Configuration>Templates>Create New Template * Uninstall and reinstall `Field Service` * Field Service>New Task>Set worksheet template to the one you created `KeyError: False` **Solution:** * Unlink user created worksheet template on uninstallation of the application. **Sentry-6615576986** Forward-Port-Of: odoo/enterprise#86084
This fix stops cashiers from repeatedly pressing Validate while an online payment order is still syncing on slow networks. It prevents payment validation errors and makes point-of-sale checkout more reliable when connectivity is poor.
Original PR description
Currently, an error occurs when validating an online payment if the network is slow. **Steps to Reproduce:** 1) Install POS (with demo data) and the Demo Payment module. 2) Go to Payment Methods and…
Currently, an error occurs when validating an online payment if the network is slow.
**Steps to Reproduce:**
1) Install POS (with demo data) and the Demo Payment module.
2) Go to Payment Methods and create a new online payment method for any shop (e.g., a clothing shop). Set the Payment Provider to `Demo`.
3) Open a POS session for the clothing shop, select any product, and proceed to payment.
4) Open Inspect → Network tab, create a custom slow network profile(e.g., `set both download and upload speed to 1 KB/s`), and switch to that network.
5) Select the online payment method you just created and continuously click on Validate.
Error:
ValueError: Expected singleton: pos.order('p', 'o', 's', '.', 'o', 'r', 'd', 'e', 'r', '_', '4')
**Root Cause:**
When an online payment is validated, the `_isOrderValid` and `addNewPaymentLine` methods are called.
- With a slow network, the order ID is still temporary(e.g., e74a3369-7dcd-4234-b35e-04daa149ffe6) as the order is not synced completely, when the code at [1] is executed.
- Due to multiple clicks, `_isOrderValid` forces a call to `update_online_payments_data_with_server` at [2] before order is synced.
- This eventually passes the temporary ID to `get_and_set_online_payments_data` at [3], causing the issue.
**Fix:**
Prevent multiple clicks on Validate until the order is successfully synced.
[1]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L11-L17
[2]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L87
[3]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/models/pos_store.js#L18-L26
**sentry-6849786792**
Forward-Port-Of: odoo/odoo#227967
Forward-Port-Of: odoo/odoo#225371This fix prevents a self-ordering test from trying to cancel orders that are already finalized, such as paid demo orders. By limiting cancellations to draft orders, the test runs more reliably and avoids false failures in validation environments.
Original PR description
Before this commit: = - Previously, `test_self_order_mobile` set all orders to cancel, causing errors with finalized orders (e.g., paid orders from demo data). After this commit: = - Only draft orders are cancelled, preventing errors and ensuring correct test behavior. Runboat Error: 224197 Forward-Port-Of: odoo/odoo#214935
Dark mode styling was adjusted so key icons and text remain easy to read in Point of Sale and appointment views. This improves usability for staff working with dark mode by preventing low-contrast or hard-to-see interface elements.
Original PR description
In this commit: ------------------- - Added a dark mode color for the star icon. - Changed the text color to white in light mode, which is reflected as black in dark mode. This fixes the issue of the text not being properly visible in dark mode. task:4943078 Forward-Port-Of: odoo/enterprise#93993
UAE invoice printouts have been corrected so the amount column is no longer shown twice when taxes are included. This makes Proforma and Tax invoice reports clearer and avoids confusion for customers and accounting teams.
Original PR description
**Step to reproduce:** - install account module with localization "UAE" - go to Settings > Tax Included - create a invoice (make sure a tax is applied) - print any invoice (Proforma or Tax)…
**Step to reproduce:**
- install account module with localization "UAE"
- go to Settings > Tax Included
- create a invoice (make sure a tax is applied)
- print any invoice (Proforma or Tax)
**Observation:**
- the amount is being displayed twice in the Amount column.
**Cause:**
- A change was introduced in 18.0 to add additional column right after Amount
column, [1] in l10n_ae module
- Another commit [2] in saas-18.3 introduces same column in main account module
- hence we have two columns printing same information
**Fix:**
- Removed and fixed a faulty xpath from view, as after commit [2]
base layout provides same logic
[1] https://github.com/odoo/odoo/commit/fe68fa30b18f90411043fc6e2314fd376ddaed0c
[2] https://github.com/odoo/odoo/commit/1bf232c22f430d282aaadd858c5e61fed12f4da6
**Before:**
<img width="774" height="146" alt="image" src="https://github.com/user-attachments/assets/a9eb6af2-81b3-4989-bf6e-6676eafe10f8" />
**After:**
<img width="813" height="143" alt="image" src="https://github.com/user-attachments/assets/fb019516-de7d-4dd3-b7dd-3fd14322b031" />
opw-4976410
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#223382Support Document Credit Notes in Colombian electronic invoicing now use the required internal reference identification format, avoiding DIAN rejection errors. This helps businesses submit these credit notes successfully even when product barcodes or UNSPSC codes are configured.
Original PR description
Before this PR:
- Support Document Credit Notes sent barcode (scheme 010) when available, causing DIAN `NSAZ13` error and document rejection.
After this PR:
- Although a product has all of these 3 fields configured (barcode, UNSPSC, internal reference), still, for a Support Document Credit Note, the `cac:StandardItemIdentification` is always sent with the Internal Reference information ('999', 'Estándar de adopción del contribuyente').
- If internal reference is not configured, then barcode or UNSPSC code is sent with scheme ('999', 'Estándar de adopción del contribuyente').
task-4796034
Forward-Port-Of: odoo/enterprise#94140This fix prevents manufacturing planning from failing when an operation or work order has an extremely small duration value. It ensures schedules can still be calculated reliably instead of triggering an error during availability checks.
Original PR description
Operation & Workorder duration is a float with 2 decimal digits to be expressed in minutes, meaning minimal duration is 1sec. However one can encounter numbers like 0.001, 0.00001, ... This can lead to : AttributeError: 'NoneType' object has no attribute 'astimezone' in function _get_first_available_slot task: 5090338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227253
Employees and contract templates using a working schedule now require Working Hours before saving. This prevents errors in employee forms and version lists, helping HR teams keep work entry data complete and reliable.
Original PR description
#### Steps to Reproduce 1. Go to Employees. 2. Select an employee with Work Entry Source = "Working Schedule". 3. Clear the "Working Hours" field. 4. Try to save. #### Issues Fixed - Traceback in employee version list view (`hr.version`) when "Working Hours" is empty for calendar-based employees. - Traceback in employee form view when saving without a working schedule for a calendar-based employee. - Resource Calendar (`resource_calendar_id`) is now required conditionally in: * Employee form view * Contract template form view * Version list view #### Fix Made `resource_calendar_id` required conditionally in the inherited `hr.employee`, `hr_contract_template` and `hr.version` views and added a placeholder. task-5068798
Invoice and report lines now show both the product name and the added description instead of replacing the product name with the description. This helps customers and staff identify billed items more clearly on printed documents.
Original PR description
Step to reproduce: - install account - create a invoice with any product - add description - print any report Observation: - We see that only description is printed, not the name of product in…
Step to reproduce: - install account - create a invoice with any product - add description - print any report Observation: - We see that only description is printed, not the name of product in description column of report Expected: - The name and description, both should be printed Cause: - the `ProductNameAndDescriptionField` component is introduced in [1] sets label as only description or product name, instead of including it both if they are available https://github.com/odoo/odoo/blob/f74cdf84ffbaccea2fbf03bfb17a9e7bfcaae524/addons/product/static/src/product_name_and_description/product_name_and_description.js#L131-L136 Fix: - we fix the `updateLabel` method for `ProductNameAndDescriptionField` to get the expected outcome i.e `productname+\n+description` Before: <img width="297" height="175" alt="image" src="https://github.com/user-attachments/assets/803b53ce-c031-4192-874c-11ebfd8c7e9b" /> After: <img width="281" height="184" alt="image" src="https://github.com/user-attachments/assets/0dce4f67-94bf-42f2-bf09-c03a07c800d0" /> [1]: https://github.com/odoo/odoo/commit/7e553d25890d1e236123f0fa7e11ce86f59448ab opw-5063048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents email signature formatting, such as resized images, from being damaged when messages are prepared for Outlook compatibility. Users should see more consistent email appearance between chatter messages and the full email composer.
Original PR description
Problem: `_hideForOutlook` breaks the last style when appending `mso-hide: all;` if the style string does not end with `;`. Example: `width: 100%` → `width: 100% mso-hide: all;` Solution: Ensure the new attribute is appended correctly at the end of the styles, regardless of whether the last style ends with `;`. Note: The problem might be only observed on `18.4` because the composer doesn't use the user signature before `18.4`. Steps to reproduce in 18.4: 1. Open "My Profile". 2. Add an image to "email signature" with reduced scaling (25%, 50%). 3. Open any record with chatter (task, SO, invoice, etc.). 4. Type a message in chatter and click "Send". 5. Click "Open Full Compositor" and send a message from the email compositor. 6. Open the runbot's MailHog and observe the differences between the two emails. opw-5046573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224985
This fixes an issue where an online order could switch to the wrong pricelist after a shopper created an account without an address. The website now keeps using the shopper's detected country when recalculating prices, helping ensure country-specific pricing remains accurate.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st…
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st pricelist be incompatible w/ the current GeoIP location; 5. open a cart as a public user; 6. check pricelist in back-end (should be correct); 7. go to "Sign In" & create a new portal account without address; 8. check pricelist in back-end (should still be correct); 9. go back to cart with portal account; 10. check pricelist in back-end. Issue ----- The first pricelist is assigned to the order, which shouldn't be compatibly with the partner's current GeoIP location. Cause ----- The pricelist is recomputed on changing the `partner_id` on a sale order. Commit 6504c0624b990 added a check on the `country_code` context value when retrieving the `property_product_pricelist` for a partner. This context value is currently not getting added during `_compute_pricelist_id`. Because all pricelists are restricted to a country group, when the pricelist gets recomputed on `partner_id` change, there's no location-independent pricelist to fall back on, which is why the first pricelist is used regardless of country restrictions. Solution -------- Add a `_compute_pricelist_id` override which adds the current GeoIP country code to the context when computing the field for website orders. opw-5000198 Forward-Port-Of: odoo/odoo#228909 Forward-Port-Of: odoo/odoo#225582
The AI field picker now prevents users from selecting the same field more than once and clearly marks fields that are already selected. Long field paths also wrap correctly, making them easier to remove and reducing user frustration when configuring AI prompts.
Original PR description
before this commit: When you press Enter in the field picker, it will always pick the same field again, even if it is not visible. After this commit: A field can only be selected once, and it stays visible in the list. Added a visual check to show that the field is already selected. Forward-Port-Of: odoo/enterprise#93890
Importing certain electronic invoice files could fail when a quantity field was set to zero. This fix prevents that error so affected UBL/CII invoices can be imported more reliably in Accounting.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Customers / Invoices" - Import a UBL file having a value of 0 for a `<cbc:BaseQuantity>` element **Issue:** The import fails due to a division by 0 at: `price_unit = (net_price_unit + rebate) / basis_qty` **Cause:** "basis_qty" is retrieved as followed: `basis_qty = float(self._find_value(xpath_dict['basis_qty'], tree) or 1)` If the element is not defined, it will fall back on 1. But if the element exists with a value of 0, the "_find_value" method will retrieve the string "0" which is not False and will not fall back on 1. Then it will become `0.0` once converted to float. opw-5062985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227446
Project users can no longer create new task stages from the task list when they do not have the required permissions. This keeps project workflows controlled by authorized managers and prevents unintended changes to task stage setup.
Original PR description
Steps to reproduce: - Go to a project - Open the task list view - Select a task - In the `Stage` field, attempt to create a new stage Issue: - Project users were able to create new task stages from…
Steps to reproduce: - Go to a project - Open the task list view - Select a task - In the `Stage` field, attempt to create a new stage Issue: - Project users were able to create new task stages from the task list view, despite not having the required permissions. Cause: - The `_default_user_id` method assigns the current user as the owner `user_id` of a new stage only when `default_project_id` is not present in the context. As a result, the method returned the current user’s ID, unintentionally making them the owner of the stage. This allowed project users to bypass the intended access rules and create new stages. Solution: - Use the `no_create` option for users outside the project manager group to prevent them from creating new stages. - Updated the `stage_id` field in the task list view to explicitly include `default_project_id` in the context, ensuring proper access control of that stage. task-4628666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228766 Forward-Port-Of: odoo/odoo#206407
Rental orders can now be confirmed even if a planned resource is unavailable, as long as rental-to-shift synchronization is turned off. This prevents unnecessary blocking in the portal and rental app for businesses that do not use shift synchronization.
Original PR description
Step to reproduce: - Set up a role with a resource not available this week - Not activate the option to sync Rental order - Shift - Set up a rental-service product, with an auto-plan for this role Issue: - Rental orders could not be confirmed from the portal or the rental app if the required resource was unavailable, even when the `sync_shift_rental` option was not disabled. Cause: - The logic in `_planning_slot_vals_list_per_sol` treated all unavailable resources as problematic, without checking whether the shift synchronization was enabled (`sync_shift_rental`), resulting in unnecessary blocking of the order confirmation. Solution: - Added a condition to check if `sync_shift_rental` is enabled before marking a service as problematic. This allows rental orders to be confirmed when shift sync is disabled. task-5072920
This fixes a rounding mismatch in Mexican electronic invoice validation, where Odoo calculated totals with more precision than the XML validation expected. The change helps prevent valid invoices from being rejected due to tiny decimal differences.
Original PR description
The validation in the XML are made based on values rounded to 6 digits. However in Odoo, we do the computation without any rounding. 352.2413793103448 + 876.7435344827586 + 162.92327586206898 + 198.73706896551727 + 526.0383620689655 + 17.241379310344826 = 2133.925 ~= 2133.93 352.241379 + 876.743534 + 162.923276 + 198.737069 + 526.038362 + 17.241379 = 2133.924999 ~= 2133.92 != 2133.93 opw-5096249 Forward-Port-Of: odoo/enterprise#95413
Payment terminal messages printed at the bottom of POS receipts now use the correct text size. This makes receipt details easier for customers and staff to read while keeping the on-screen receipt display consistent.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228775
Invoice Analysis now calculates product quantities, average prices, margins, and inventory values correctly when invoices include packaged products. This helps businesses rely on accurate reporting for sales performance, profitability, and stock valuation after the unit-of-measure packaging changes.
Original PR description
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost,…
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost, and it differs from sales price - In the sales sheet, add a packaging - Create a sale order - Add the product using the package - Confirm - Go to delivery, validate - Back to sale order create an invoice and confirm it - Go to "Invoice Analysis" - Go to Pivot View - In "Measures" select: - Average Price, - Inventory Value, - Margin, - Product Quantity - In "Total" select: - Product #### Current behavior: - Those fields display wrong values as they were miscalculated: - Average Price line_balance / number_of_packages * number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages / number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages / number_of_unit_in_package - Product Quantity number_of_packages / number_of_unit_in_package #### Expected behavior: - These fields should be right: - Average Price line_balance / number_of_packages / number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages * number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages * number_of_unit_in_package - Product Quantity number_of_packages * number_of_unit_in_package #### Cause of the issue: - As per the refactor of the UoM and packaging, the uom factor field is now the mathematical inverse of the previous uom factor field. This model wasn't updated and used wrong formulas. opw-5031495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227489
Point of Sale kitchen and preparation tickets now handle order notes consistently across multiple printers. This prevents printing failures caused by different note formats, helping restaurant staff receive complete tickets without interruption.
Original PR description
Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers. Steps to reproduce:…
Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers.
Steps to reproduce:
-------------------
* Configure two preparation printers for a pos_restaurant with food categorie.
* Create an order with a note in that restaurant.
* Send the order to the kitchen.
> Observation:
The second printer fails to print the ticket with an (uncaught) JSON parse error (Unexpected token), while the first prints correctly.
Why the fix:
------------
`getStrNotes()` assumed notes were always JSON strings like [{"text":"...","colorIndex":0}]. In practice, notes can be plain strings or already-parsed arrays depending on the update path and last printed changes.
The function now:
- returns joined texts for arrays,
- tries to parse JSON strings and joins texts if it’s an array,
- falls back to the raw string if parsing fails. This makes note rendering stable across printers and prevents the error, ensuring tickets are printed consistently.
opw-5029870
Forward-Port-Of: odoo/odoo#227430The Time Off calendar now shows the selected employee's working schedule instead of the schedule of the person viewing it. This prevents incorrect day-off visibility when managers or HR users review employees with different work patterns.
Original PR description
Steps to reproduce: - In the Employee app, select an employee with a different working schedule than yours - Click on the "Time Off" smartbutton - Switch from Kanban to Calendar view - The displayed working schedule is yours and not the employee's (easier to see if you and the employee have different days off) Reason: The employee_id field in the context used by the Python method was null instead of an ID, which caused the Python method to default to not use the employee's working schedule but the working schedule of the user viewing it. How it was fixed: By using a different field already present in the context, the employee's ID is correctly retrieved and used to display the calendar. Task ID: 4987732 Forward-Port-Of: odoo/odoo#225839
This fixes an issue where reinstalling the Danish Nemhandel module could leave it broken. Businesses using Danish electronic invoicing can reinstall or recover the module without disrupting its setup.
Original PR description
**Description of the issue/feature this PR addresses:** Reinstalling the module breaks it. Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228747
21 changes
Security fixes and vulnerability patches
Shared MP4 videos in Documents can no longer be previewed by anyone with the link. This prevents Odoo-hosted files from being used for public video streaming and better protects video content shared through Documents.
Original PR description
**Issue:** When sharing an MP4 video with "Anyone with the link" viewer access, the video is available to preview without login. **Steps to reproduce:** 1. Install documents 2. Upload an MP4 video 3. Share it with the smart button with anyone with the link viewer access 4. Copy link and paste it in incognito in chrome **Result:** - Video preview option is available **Cause:** - The method get_previewable_file_extensions allows 'mp4' videos to be previewed. **Solution:** - Remove the 'mp4' extension from the previewable list. **NOTE:** - We do not want to be 'used' as a video streaming platform. We do not do it for our own eLearning videos, so we can't do it here, Preview file should simply not be publically available for videos we host. opw-4926384 Forward-Port-Of: odoo/enterprise#90158
Enhancements to existing features
Tax records can now be found by entering their configured percentage or fixed amount in the search bar. This makes it faster for accounting users to locate the right tax setup without browsing through tax lists manually.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
Hong Kong Payroll now includes a button to download IR56B report files in XML format. This makes it easier for payroll teams to retrieve the required tax reporting file directly from the relevant report screen.
Original PR description
Add ir56b report download button for downloading .xml file in Hong Kong Payroll. task - 5081474 Forward-Port-Of: odoo/enterprise#95294 Forward-Port-Of: odoo/enterprise#95013
Resolved issues and error corrections
This fixes an issue where custom worksheet templates left behind during a Field Service uninstall could break task setup after reinstalling the app. Custom templates are now removed during uninstall, preventing errors when users assign a worksheet template to a task.
Original PR description
When user uninstalls and reinstalls `industry_fsm` the user created template is not removed causing `model_id` for the worksheet template turning `False` and raising a key error when indexing via `model_id`. **Replication steps:** * Install `industry_fsm` * Field Service>Configuration>Settings>Enable Worksheet templates * Configuration>Templates>Create New Template * Uninstall and reinstall `Field Service` * Field Service>New Task>Set worksheet template to the one you created `KeyError: False` **Solution:** * Unlink user created worksheet template on uninstallation of the application. **Sentry-6615576986** Forward-Port-Of: odoo/enterprise#86084
Support Document Credit Notes in Colombian electronic invoicing now use the required internal reference format for product identification. This prevents DIAN rejection errors when products also have barcodes or UNSPSC codes configured, improving successful submission of these documents.
Original PR description
Before this PR:
- Support Document Credit Notes sent barcode (scheme 010) when available, causing DIAN `NSAZ13` error and document rejection.
After this PR:
- Although a product has all of these 3 fields configured (barcode, UNSPSC, internal reference), still, for a Support Document Credit Note, the `cac:StandardItemIdentification` is always sent with the Internal Reference information ('999', 'Estándar de adopción del contribuyente').
- If internal reference is not configured, then barcode or UNSPSC code is sent with scheme ('999', 'Estándar de adopción del contribuyente').
task-4796034
Forward-Port-Of: odoo/enterprise#94140This fixes an issue where repeatedly pressing Validate for an online POS payment on a slow network could cause the order validation to fail. The button is now protected until the order has finished syncing, reducing checkout errors and improving reliability for cashiers and customers.
Original PR description
Currently, an error occurs when validating an online payment if the network is slow. **Steps to Reproduce:** 1) Install POS (with demo data) and the Demo Payment module. 2) Go to Payment Methods and…
Currently, an error occurs when validating an online payment if the network is slow.
**Steps to Reproduce:**
1) Install POS (with demo data) and the Demo Payment module.
2) Go to Payment Methods and create a new online payment method for any shop (e.g., a clothing shop). Set the Payment Provider to `Demo`.
3) Open a POS session for the clothing shop, select any product, and proceed to payment.
4) Open Inspect → Network tab, create a custom slow network profile(e.g., `set both download and upload speed to 1 KB/s`), and switch to that network.
5) Select the online payment method you just created and continuously click on Validate.
Error:
ValueError: Expected singleton: pos.order('p', 'o', 's', '.', 'o', 'r', 'd', 'e', 'r', '_', '4')
**Root Cause:**
When an online payment is validated, the `_isOrderValid` and `addNewPaymentLine` methods are called.
- With a slow network, the order ID is still temporary(e.g., e74a3369-7dcd-4234-b35e-04daa149ffe6) as the order is not synced completely, when the code at [1] is executed.
- Due to multiple clicks, `_isOrderValid` forces a call to `update_online_payments_data_with_server` at [2] before order is synced.
- This eventually passes the temporary ID to `get_and_set_online_payments_data` at [3], causing the issue.
**Fix:**
Prevent multiple clicks on Validate until the order is successfully synced.
[1]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L11-L17
[2]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L87
[3]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/models/pos_store.js#L18-L26
**sentry-6849786792**
Forward-Port-Of: odoo/odoo#227967
Forward-Port-Of: odoo/odoo#225371This fix updates checks around product barcode lookup so product weight is correctly handled when available on the product form. It also corrects test permissions for product variants, helping prevent false failures in automated validation.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so we can't set them. - The variant rights were not passed correctly for the first basic test. After this commit: ----------------------- - We have updated the test and checked that weight is correctly set when present in the view. - Now we have passed the correct variant right for the test. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155 Forward-Port-Of: odoo/enterprise#95590 Forward-Port-Of: odoo/enterprise#93075
Orders paid online from the kiosk are now sent to the preparation display after payment. This prevents paid customer orders from being missed by kitchen staff, improving fulfillment reliability.
Original PR description
Currently, when using online payment with the kiosk. The order is marked as paid in the backedn but never redirected to the kitchen. Steps to reproduce: ------------------- * Create an online payment method (use demo for example) * Change the kiosk settings to use those it * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ The following commit is forwarded. It had been stopped before 18.2 since orders were sent to the kitchen before being paid. That behavior was changed again in the next version thus the fix needs to be forwarded as well. https://github.com/odoo/odoo/commit/6d8ec9948f1d0924ca92e2a9492b9882ae3338c0 opw-5096094
This fixes an issue where kiosk orders paid online were confirmed to customers but not sent to the kitchen preparation display. Restaurants using kiosk online payments can now rely on paid orders appearing for preparation as expected.
Original PR description
Currently, when using online payment with the kiosk. The order is marked as paid in the backend but never redirected to the kitchen. Steps to reproduce: ------------------- * Create an online payment method (use demo for example) * Change the kiosk settings to use those it * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ The following commit is forwarded. It had been stopped before 18.2 since orders were sent to the kitchen before being paid. That behavior was changed again in the next version thus the fix needs to be forwarded as well. https://github.com/odoo/enterprise/commit/bb25c6226e746f292274c77fa0c05108e6938907 opw-5096094
The bank reconciliation widget now avoids repeating the same date on every transaction line when several entries share a date. This makes the list easier to scan and reduces visual clutter while still showing the date at the start of each date group or statement.
Original PR description
When you have several transactions on the same date, it's not really necessary to repeat the date on each line. It bloats the widget. We will now only show it if it's the first transaction at that date or if it's the first of a statement. task-4749339
Greek VAT numbers that start with the common 'EL' prefix are now treated as Greek VAT numbers during validation. This ensures customer country information is filled correctly in exports such as DATEV accounting files, reducing manual corrections and reporting errors.
Original PR description
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer…
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer from Greece with VAT number EL033910442 2. Create an invoice for that customer 3. Navigate to Accounting > Reporting > General Ledger 4. Download Datev Data through the gear icon 5. Open EXTF_Customer_accounts.csv 6. Notice that EL was not recognised as the country code **Root Cause** The VAT validation logic `simple_vat_check` first tries to find a country-specific check function `check_vat_EL`, but such a function does not exist. For Greece, the correct function is `check_vat_GR` (since the ISO country code is `GR`). When `EL` is passed directly, no check function is found, validation fails, and the VAT country is left empty. **Fix** Normalize the VAT prefix before validation by mapping EL → GR, ensuring Greek VAT numbers prefixed with EL are validated with the existing check_vat_GR logic. Opw-4982164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225422
Field service tasks now use the customer’s assigned pricelist when creating service lines on sales orders. This prevents incorrect default product pricing and helps ensure customers are billed according to their agreed pricing.
Original PR description
Before this commit, the service line on the sale order ignored the customer’s pricelist and used the product’s default price. Steps to reproduce: - Assign a fixed-price pricelist to a customer. - Create an FSM task for them and add a timesheet. - Validate the task and check the service line price. After this commit, the service line correctly reflects the price from the assigned pricelist. task-4830183 Forward-Port-Of: odoo/enterprise#88039
This fixes an issue where email signature formatting could be damaged when messages were prepared for Outlook, especially for resized images. Users should see more consistent email appearance between the chatter composer and full email composer.
Original PR description
Problem: `_hideForOutlook` breaks the last style when appending `mso-hide: all;` if the style string does not end with `;`. Example: `width: 100%` → `width: 100% mso-hide: all;` Solution: Ensure the new attribute is appended correctly at the end of the styles, regardless of whether the last style ends with `;`. Note: The problem might be only observed on `18.4` because the composer doesn't use the user signature before `18.4`. Steps to reproduce in 18.4: 1. Open "My Profile". 2. Add an image to "email signature" with reduced scaling (25%, 50%). 3. Open any record with chatter (task, SO, invoice, etc.). 4. Type a message in chatter and click "Send". 5. Click "Open Full Compositor" and send a message from the email compositor. 6. Open the runbot's MailHog and observe the differences between the two emails. opw-5046573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224985
Online store carts now keep the correct pricelist when a shopper signs in or creates an account without an address. This prevents customers from being assigned pricing that does not match their detected country, improving pricing accuracy for GeoIP-based eCommerce setups.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st…
Versions -------- - 17.0+ Steps ----- 1. Have GeoIP enabled/mocked; 2. have at least 2 pricelists available in eCommerce; 3. have all pricelists restricted to a certain country group; 4. have the 1st pricelist be incompatible w/ the current GeoIP location; 5. open a cart as a public user; 6. check pricelist in back-end (should be correct); 7. go to "Sign In" & create a new portal account without address; 8. check pricelist in back-end (should still be correct); 9. go back to cart with portal account; 10. check pricelist in back-end. Issue ----- The first pricelist is assigned to the order, which shouldn't be compatibly with the partner's current GeoIP location. Cause ----- The pricelist is recomputed on changing the `partner_id` on a sale order. Commit 6504c0624b990 added a check on the `country_code` context value when retrieving the `property_product_pricelist` for a partner. This context value is currently not getting added during `_compute_pricelist_id`. Because all pricelists are restricted to a country group, when the pricelist gets recomputed on `partner_id` change, there's no location-independent pricelist to fall back on, which is why the first pricelist is used regardless of country restrictions. Solution -------- Add a `_compute_pricelist_id` override which adds the current GeoIP country code to the context when computing the field for website orders. opw-5000198 Forward-Port-Of: odoo/odoo#228909 Forward-Port-Of: odoo/odoo#225582
This fix prevents UBL invoice imports from failing when an imported file contains a zero value for the base quantity. Businesses can now import affected customer invoices without interruption, improving reliability for electronic invoicing workflows.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Customers / Invoices" - Import a UBL file having a value of 0 for a `<cbc:BaseQuantity>` element **Issue:** The import fails due to a division by 0 at: `price_unit = (net_price_unit + rebate) / basis_qty` **Cause:** "basis_qty" is retrieved as followed: `basis_qty = float(self._find_value(xpath_dict['basis_qty'], tree) or 1)` If the element is not defined, it will fall back on 1. But if the element exists with a value of 0, the "_find_value" method will retrieve the string "0" which is not False and will not fall back on 1. Then it will become `0.0` once converted to float. opw-5062985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227446
Point of Sale users can once again print invoice PDFs through connected IoT printers instead of only downloading them. The change restores expected printing behavior after a previous invoice download update and reuses a cleaner printer selection flow.
Original PR description
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself. - **[REF] iot: extract printer select into separate function** Before this commit, the printer…
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.
- **[REF] iot: extract printer select into separate function**
Before this commit, the printer selection wizard was tightly coupled to
the IoT report handler, and the call to send to the printer was
duplicated in the wizard and the handler.
After this commit, the printer selection wizard is contained in a
function that will always return the selected printers directly to the
caller, whether the dialog needs to be opened or not. The wizard is
simplified as a result and the print call always occurs in the handler.
This refactoring will allow other places to use the printer selection
wizard, namely for invoice printing.
- **[FIX] pos_iot: print invoices via IoT**
In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
bypass the `ir.actions.report` model, instead working directly via an
action on the invoice model. A side effect of this is that it broke
printing invoices via the IoT, as it relies on the report printing
action to function.
To fix this, this commit introduces an override in `pos_iot` for the
`account_move_service`, which will print the invoice PDF via the IoT
instead of downloading it directly (if a printer is associated with the
report).
task-5109814
Forward-Port-Of: odoo/enterprise#95616
Forward-Port-Of: odoo/enterprise#95586This fix prevents the website preview from briefly showing old page styling when a page reloads after theme changes. Business users get a smoother editing experience with less visual flicker when updating layouts or background colors.
Original PR description
In this [commit], fallback iframe was added to avoid flickering between iframe reloads. But the flicker still happens if we change page's style, since we do not apply the new styles to the fallback iframe. To reproduce the issue: - Open Website and start editing - Move to the 'Theme' tab - Change page layout to 'Boxed' - Set background color to a non-transparent color, e.g. red - Save, and do any action to reload the iframe, e.g. go to /contactus => The iframe flickers from the previous color to red, which shouldn't be the case. Task-4985472 [commit]: https://github.com/odoo/odoo/commit/7b19831e1c624b483008feb526ba773ec8b23009 Forward-Port-Of: odoo/odoo#221391
Invoice Analysis now calculates product quantity, average price, margin, and inventory value correctly when invoices include packaged products. This prevents misleading reporting for sales and profitability when products are sold by package rather than individual unit.
Original PR description
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost,…
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost, and it differs from sales price - In the sales sheet, add a packaging - Create a sale order - Add the product using the package - Confirm - Go to delivery, validate - Back to sale order create an invoice and confirm it - Go to "Invoice Analysis" - Go to Pivot View - In "Measures" select: - Average Price, - Inventory Value, - Margin, - Product Quantity - In "Total" select: - Product #### Current behavior: - Those fields display wrong values as they were miscalculated: - Average Price line_balance / number_of_packages * number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages / number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages / number_of_unit_in_package - Product Quantity number_of_packages / number_of_unit_in_package #### Expected behavior: - These fields should be right: - Average Price line_balance / number_of_packages / number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages * number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages * number_of_unit_in_package - Product Quantity number_of_packages * number_of_unit_in_package #### Cause of the issue: - As per the refactor of the UoM and packaging, the uom factor field is now the mathematical inverse of the previous uom factor field. This model wasn't updated and used wrong formulas. opw-5031495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227489
Payment terminal messages printed at the bottom of POS receipts now use the correct font size. This makes important payment information easier to read on printed receipts while keeping the on-screen receipt display consistent.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228775
This fix stops time off requests marked as worked time from appearing as time off entries in timesheets. It keeps timesheet records cleaner and avoids misleading time off reporting for employees and managers.
Original PR description
_______________________________________ ## Short functional explanation of the error When creating a leave of type "worked time", a time off timesheet is generated. ## Reproduction Steps 1. Go to time off. Hit configuration, then time off types. 2. Create a new type of time off. Set the Kind of Time off as Worked Time. Make sure the time off doesn't require allocation. 3. Hit My Time > My Time off. Click on new, and as a time off type, select the one you just created. Save then validate. 4. Go to timesheets and click on the list view. ### Expected behavior As the type of time off is set as Worked Time, it shouldn't appear as time off. It shouldn't appear at all in the timesheets if created from the time off app. ### Unexpected behavior The time off shows in the timesheets as "Time Off". ## Origin of the issue Timesheets were created for each time off request, regardless of their type. _________________________________________ opw-5050838 ---
A test for financial reports now targets the exact report being checked instead of potentially switching to a related variant. This improves confidence in report validation without changing day-to-day product behavior.
Original PR description
the test test_custom_engines_related_groupby needs a slight improvement to target the report it is called with, rather than possible variants of the report. This can be achieved using the key 'no_report_reroute'.
5 changes
Security fixes and vulnerability patches
Shared MP4 video files in Documents can no longer be previewed by anyone with a public link. This prevents Odoo-hosted videos from being accessed like a streaming service and better protects shared video content.
Original PR description
**Issue:** When sharing an MP4 video with "Anyone with the link" viewer access, the video is available to preview without login. **Steps to reproduce:** 1. Install documents 2. Upload an MP4 video 3. Share it with the smart button with anyone with the link viewer access 4. Copy link and paste it in incognito in chrome **Result:** - Video preview option is available **Cause:** - The method get_previewable_file_extensions allows 'mp4' videos to be previewed. **Solution:** - Remove the 'mp4' extension from the previewable list. **NOTE:** - We do not want to be 'used' as a video streaming platform. We do not do it for our own eLearning videos, so we can't do it here, Preview file should simply not be publically available for videos we host. opw-4926384 Forward-Port-Of: odoo/enterprise#90158
Resolved issues and error corrections
This fix prevents Field Service tasks from failing when a worksheet template created by a user remains after uninstalling and reinstalling the Field Service app. User-created worksheet templates are now removed during uninstallation, avoiding broken template references and allowing tasks to be assigned templates reliably.
Original PR description
When user uninstalls and reinstalls `industry_fsm` the user created template is not removed causing `model_id` for the worksheet template turning `False` and raising a key error when indexing via `model_id`. **Replication steps:** * Install `industry_fsm` * Field Service>Configuration>Settings>Enable Worksheet templates * Configuration>Templates>Create New Template * Uninstall and reinstall `Field Service` * Field Service>New Task>Set worksheet template to the one you created `KeyError: False` **Solution:** * Unlink user created worksheet template on uninstallation of the application. **Sentry-6615576986** Forward-Port-Of: odoo/enterprise#86084
Support Document Credit Notes in Colombia now consistently use the required internal reference format for product identification. This prevents DIAN rejection errors when products also have barcodes or UNSPSC codes configured, improving successful electronic document submission.
Original PR description
Before this PR:
- Support Document Credit Notes sent barcode (scheme 010) when available, causing DIAN `NSAZ13` error and document rejection.
After this PR:
- Although a product has all of these 3 fields configured (barcode, UNSPSC, internal reference), still, for a Support Document Credit Note, the `cac:StandardItemIdentification` is always sent with the Internal Reference information ('999', 'Estándar de adopción del contribuyente').
- If internal reference is not configured, then barcode or UNSPSC code is sent with scheme ('999', 'Estándar de adopción del contribuyente').
task-4796034
Forward-Port-Of: odoo/enterprise#94140Field service service lines now use the customer’s assigned pricelist instead of the product’s default price. This ensures invoices and sales orders reflect agreed customer pricing when tasks with timesheets are validated.
Original PR description
Before this commit, the service line on the sale order ignored the customer’s pricelist and used the product’s default price. Steps to reproduce: - Assign a fixed-price pricelist to a customer. - Create an FSM task for them and add a timesheet. - Validate the task and check the service line price. After this commit, the service line correctly reflects the price from the assigned pricelist. task-4830183 Forward-Port-Of: odoo/enterprise#88039
Helpdesk team settings now only show internal users when assigning team members for tag-based ticket dispatching. This prevents portal users from being selected by mistake, keeping automatic ticket assignment limited to the right staff.
Original PR description
**Steps to Reproduce:** 1. Go to Helpdesk → Overview. 2. Open a team (e.g., 'Customer Care') and click on 'Settings'. 3. In the team settings, enable 'Automatic Assignment' → 'Dispatch tickets based on tags'. 4. Configure tags handled by team members. 5. In the 'Team Members' field, try to assign users. **Issue:** Portal users are displayed in the 'Team Members' selection list, even though they should not be assignable to helpdesk team tags. **Current behaviour:** - The 'Team Members' field shows all users, including portal users. **Expected behaviour:** - Only internal users should be selectable as 'Team Members'. - Portal users should not appear in the many2many list. **Fix:** Added a domain on the 'user_ids' field to exclude portal users from the 'Team Members' selection. **task-5093188**
25 changes
Security fixes and vulnerability patches
Shared MP4 videos can no longer be previewed through public document links. This prevents publicly shared document links from being used to stream hosted videos without login.
Original PR description
**Issue:** When sharing an MP4 video with "Anyone with the link" viewer access, the video is available to preview without login. **Steps to reproduce:** 1. Install documents 2. Upload an MP4 video 3. Share it with the smart button with anyone with the link viewer access 4. Copy link and paste it in incognito in chrome **Result:** - Video preview option is available **Cause:** - The method get_previewable_file_extensions allows 'mp4' videos to be previewed. **Solution:** - Remove the 'mp4' extension from the previewable list. **NOTE:** - We do not want to be 'used' as a video streaming platform. We do not do it for our own eLearning videos, so we can't do it here, Preview file should simply not be publically available for videos we host. opw-4926384 Forward-Port-Of: odoo/enterprise#90158
Enhancements to existing features
The German DateV export has been optimized to process large accounting exports much faster. This reduces waiting time for finance teams when exporting high-volume accounting data, with testing showing export time cut by more than half on around one million entries.
Original PR description
The DateV export implementation is known to be slow. This commit improves performance by relying on SQL queries to fetch the data instead of using the ORM. Based on profiler results, the `record.__get__()` call was the slowest part. By converting records to dicts, we avoid `record.__get__()` completely, resulting in a massive performance improvement. - Tested with ~1M move lines: performance improved from ~150s to ~70s
The Belgian payroll accounting test was updated to reflect that a work entry type is now required. This keeps internal validation aligned with the latest payroll requirements and helps prevent test failures during future changes.
Original PR description
Adjusted the test in order to follow the new requirement of work entry type Task-5075308
The Helpdesk demo data now includes realistic message exchanges for three sample tickets, helping users better understand response time metrics in demo environments. The update also ensures ticket acknowledgment emails appear before the customer conversation, making the sample ticket history clearer and more accurate.
Original PR description
[IMP] helpdesk: add demo data in helpdesk module - Added messages in 3 tickets for demo data of the first hour to respond and the average hour to respond. - ticket 1: Warranty (Sent 2 hours later,…
[IMP] helpdesk: add demo data in helpdesk module - Added messages in 3 tickets for demo data of the first hour to respond and the average hour to respond. - ticket 1: Warranty (Sent 2 hours later, ticket creation) User: Thank you for your inquiry. Our products typically come with a one-year limited warranty. For more details, could you specify which product you're interested in? (Sent 30 minutes later) Customer: I'm interested in purchasing a desk. Does the warranty cover assembly-related issues? (Sent 1.5 hours later) User: Yes, our warranty covers any defects related to assembly or materials. Please let us know if you need assistance with your purchase. (Sent 2 hours later) Customer: That's great to hear. Could you also provide information on extended warranty options? (Sent 1 hour later) User: We offer extended warranty options for up to three years. Feel free to contact us for more details and pricing. (Sent 1 hour later) Customer: Thank you for the information. I'll consider the extended warranty option for my desk purchase. - same as the above ticket added messages in the below two tickets: 1. Lost key 2. Table legs are unbalanced task-3566757
Field service tasks marked as under warranty now set related sales order line prices to zero when appropriate. If the warranty status is removed, the original product pricing is restored, helping ensure customers are billed correctly without manual price changes.
Original PR description
- When a task is marked as under warranty, the related sale order line's price is set to 0, unless the task is completed, the sale order is locked, or the order line has already been fully invoiced. - If the warranty is removed, the original product prices are restored. task-4755822
Internal users can now access Helpdesk tickets when they are directly connected to them, such as being the creator, linked customer contact, or a follower. This helps employees see the tickets relevant to their work while keeping access limited to appropriate records.
Original PR description
This rule ensures internal users can access helpdesk tickets if: - They are the creator of the ticket, - They are the partner linked to the ticket, - They are followers via the team or directly on the ticket. task-4586753
The Indian reports module now shows the IRN number in a more appropriate location on vendor bill forms instead of disrupting the title area. This keeps the bill layout consistent with standard Odoo forms and makes the number easier to copy when needed.
Original PR description
During testing in 19, I saw that the IRN field was in the title and that totally disturbs the standard layout of how a vendor bill form should look like in Odoo. In order to easily copy paste we add a class text-break (l10n_ec_edi has the same case for the authorization number) Forward-Port-Of: odoo/enterprise#95454
Resolved issues and error corrections
This fix prevents Field Service tasks from crashing when a previously created worksheet template is selected after the Field Service app has been uninstalled and reinstalled. User-created worksheet templates tied to the removed setup are now cleaned up during uninstallation, avoiding broken templates and improving reliability.
Original PR description
When user uninstalls and reinstalls `industry_fsm` the user created template is not removed causing `model_id` for the worksheet template turning `False` and raising a key error when indexing via `model_id`. **Replication steps:** * Install `industry_fsm` * Field Service>Configuration>Settings>Enable Worksheet templates * Configuration>Templates>Create New Template * Uninstall and reinstall `Field Service` * Field Service>New Task>Set worksheet template to the one you created `KeyError: False` **Solution:** * Unlink user created worksheet template on uninstallation of the application. **Sentry-6615576986** Forward-Port-Of: odoo/enterprise#86084
Payroll payments created from payslips now use the correct bank account when tax partner lines are involved. This helps prevent payments from being assigned to the wrong recipient bank details and adds checks to avoid regressions.
Original PR description
In the `hr_payroll` module, when creating the payments based on a payslip, the property `partner_bank_id` of the created payments is not always set to the correct bank account. From now on, when a payment will be created for a tax partner line, the `partner_id` of the payment is set to the tax partner, the `partner_bank_id` will now contain the bank account of the employee. We added the `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account. Odoo: odoo/odoo#222608 Task link: https://www.odoo.com/odoo/my-tasks/4979220 task-4979220
Support Document Credit Notes in Colombian electronic invoicing now consistently use the required internal reference format when sent to DIAN. This prevents rejection errors caused by sending barcode or UNSPSC identifiers with unsupported schemes.
Original PR description
Before this PR:
- Support Document Credit Notes sent barcode (scheme 010) when available, causing DIAN `NSAZ13` error and document rejection.
After this PR:
- Although a product has all of these 3 fields configured (barcode, UNSPSC, internal reference), still, for a Support Document Credit Note, the `cac:StandardItemIdentification` is always sent with the Internal Reference information ('999', 'Estándar de adopción del contribuyente').
- If internal reference is not configured, then barcode or UNSPSC code is sent with scheme ('999', 'Estándar de adopción del contribuyente').
task-4796034
Forward-Port-Of: odoo/enterprise#94140VAT payment instructions sent through the mail composer now display more neatly in the chatter. This prevents awkward word breaks and misaligned fields, making the information easier to read and more professional for Belgian and Dutch reporting workflows.
Original PR description
Issue: -VAT payment instructions sent via mail composer were shown in the chatter with poor formatting. -Words could be split in half and fields were misaligned. Fix: -Updated the layout to improve text wrapping and field alignment in the chatter. Impact: -Ensures VAT payment instructions are displayed clearly and professionally in the chatter. task-5065873 Forward-Port-Of: odoo/enterprise#93986
This fixes Swedish tax reporting so non-EU goods purchases with VAT are correctly marked as deductible input VAT. It helps ensure VAT reports reflect the right amounts for Swedish compliance and avoids related reporting test failures.
Original PR description
The Swedish taxes "EX G" (VAT Purchase of goods outside EU) with a non-zero amount should have the tag se_48 (Input VAT to be deducted). opw-4916405
New users can now load demo data in the Appraisal module without running into an access-related error. This makes onboarding and trial setup smoother for users who do not have administrator rights.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module. Steps to reproduce: --- - Install `hr_appraisal` module (without demo data) - Create NEW user > Login…
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.
Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`
Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
<field name="user_id" ref="base.user_admin"/>
<field name="name">Appraisal of Emma Granger</field>
<field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'), ref('hr.work_contact_eg')])]"/>
<field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
<field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
<field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
<field name="res_model">hr.appraisal</field>
<field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
</record>
ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n <field name="user_id" ref="base.user_admin"/>\n <field name="name">Appraisal of Emma Granger</field>\n <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'), ref(\'hr.work_contact_eg\')])]"/>\n <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n <field name="res_model">hr.appraisal</field>\n <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n </record>') while evaluating
'action = model._load_demo_data()'
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
Forward-Port-Of: odoo/enterprise#95622
Forward-Port-Of: odoo/enterprise#93461The Chilean F29 tax report proposal has been reorganized to better match reporting needs, including clearer sections, updated calculations, and improved submission handling. This helps businesses prepare VAT and withholding information more accurately and reduces upgrade issues from older report fields.
Original PR description
https://github.com/odoo/odoo/pull/191572
The AI field picker now prevents the same field from being selected more than once and clearly marks fields that are already chosen. Long field names also wrap correctly, making them easier to review and remove when needed.
Original PR description
before this commit: When you press Enter in the field picker, it will always pick the same field again, even if it is not visible. After this commit: A field can only be selected once, and it stays visible in the list. Added a visual check to show that the field is already selected. Forward-Port-Of: odoo/enterprise#93890
The Mexican DIOT report download now places the “exempt imports” and “exempt” values in the correct columns. This prevents confusion or filing issues caused by the two correctly calculated values appearing in the wrong positions.
Original PR description
The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. This Pr changes the order of the columns in the downloadable file (txt) and corrects the tests due to the change. Task-id: 5096808 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95679 Forward-Port-Of: odoo/enterprise#95383
Fixes an issue in Brazilian electronic invoicing where confirming several invoices at the same time could fail unexpectedly. This helps accounting teams process batches of invoices more reliably without manual retries or interruptions.
Original PR description
opw-5107516 Forward-Port-Of: odoo/enterprise#95532 Forward-Port-Of: odoo/enterprise#95511
Chilean electronic invoice imports now correctly treat lines marked with exemption code 6 as negative amounts. This prevents vendor bills from being imported with overstated positive values, improving accounting accuracy and compliance with Chilean e-invoicing rules.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723 Forward-Port-Of: odoo/enterprise#95405 Forward-Port-Of: odoo/enterprise#93393
The barcode kanban view now only shows existing inventory records instead of allowing new stock quantity records to be created. This prevents accidental inventory entries and helps keep stock data accurate when users scan or type product barcodes.
Original PR description
Steps to reproduce: - Scan or type product barcode - Navigate to Kanban View Problem: - New `stock.quants` are not supposed to be created from `stock.quant.kanban.barcode`, its only to supposed to show existing ones. Forward-Port-Of: odoo/enterprise#95487 Forward-Port-Of: odoo/enterprise#94802
This fix improves how salary amounts and currency symbols are displayed in the salary configurator, making contract offers easier to read. It also ensures part-time gross salary details keep all related values, preventing incomplete employer cost information.
Original PR description
The salary configurator had several UI inconsistencies that impacted the readability of contract offers:
- Replaced complex input-group styling with flexbox layout in resume_sidebar.xml to properly align currency symbols and values using Bootstrap's fs-5 and fw-normal classes
- Added align-items-center and justify-content-end for consistent spacing
- Changed tuple reconstruction in main.py to use (_('Gross (Part Time)'), *salary_tuple[1:]) to preserve all salary_tuple values (positions 1-5) instead of truncating to only first 3 elements
task-5063224
Forward-Port-Of: odoo/enterprise#94453This fix prevents an error that could occur when a currency rate filter is closed after the accounting report view has already been left or removed. It helps keep financial reports stable during navigation and avoids disruptive crashes for users.
Original PR description
For the currency rate filter, applyFilters is called when the dropdown is closed. It might heppen that we have the dropdown open then we click on something that trigger the destruction of the report view but that still trigger applyFilters which try to apply filter on a destroyed component which is illegal. To prevent this we check if the component is destroyed before reloading the controller. Forward-Port-Of: odoo/enterprise#94530 Forward-Port-Of: odoo/enterprise#94313
Tax return reports for UK and New Zealand now follow the company’s configured fiscal year instead of assuming a calendar year. This prevents transactions from being included in the wrong quarter when the fiscal year ends on a date other than December 31.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_uk_reports - Switch to a British company (e.g. UK Company) - In Accounting settings, set the last day of the fiscal year to another date than "December 31" (e.g. "January 31") - Create some invoices with tax between the 1st of January and the 30th of April - Go to "Accounting / Accounting / Closing / Tax Returns" - Open the "Tax Report (GB)" for the first quarter (i.e. Tax Q1) **Issue: (same issue for NZ localization)** The Tax Report is ignoring the configured date of the fiscal year. All the invoices from January are included and those from April are excluded. It should be the opposite. **Solution:** Override the "_get_start_date_elements" method for the British tax report that allows to define the start date. opw-4939971 opw-5067877 Forward-Port-Of: odoo/enterprise#94936 Forward-Port-Of: odoo/enterprise#94793
This fix prevents hidden editor cursor markers in Knowledge comments from multiplying and causing errors. It helps keep comment editing stable and avoids unexpected crashes when working with Knowledge articles.
Original PR description
Context: `\ufeff` characters are used in the editor to handle how the cursor behaves when using arrow keys. In the case of knowledge comments, we want to have 2 cursor positions at each comment…
Context: `\ufeff` characters are used in the editor to handle how the cursor behaves when using arrow keys. In the case of knowledge comments, we want to have 2 cursor positions at each comment boundary. I.e.: at the first beacon, we want a cursor position before the anchor (outside of the comment), and one after (inside of the comment). Issue: Since this [commit], empty links receive 2 `zwnbsp` nodes to allow the user to type inside, instead of 1 previously. However knowledge comments beacons are not editable and only need one `zwnbsp`, since we never want to type inside. Furthermore, having 2 and nothing in between them would cause an issue when their content is normalized, which may lead to a traceback: - `link_plugin` executes `selection.anchorNode.parentNode.normalize();` which merges 2 FEFF together. However the function `isZwnbsp` does return true for one text node with 2 FEFF characters. This means that during the next "add feffs" phase, new text nodes with one `FEFF` characters will be added, creating a growing loop generating new `FEFF` at every normalization phase. - Furthermore, merging the nodes in one text node may not result in a new step in some cases, which prevent the `history_plugin` from registering the new node in time in its `nodeMap`, which may lead to a serialization traceback. Resolution: This commit stops using the deprecated `padLinkWithZwnbsp` method to ensure that there are 3 `zwnbsp` characters for each beacon: 2 around it, and one inside. [commit]: https://github.com/odoo/odoo/commit/f0eaeb6 task-5046068 Forward-Port-Of: odoo/enterprise#95550
This update stabilizes an automated test in the equity module by checking each cap table record individually instead of depending on record order. It reduces false test failures and helps keep development and release validation more dependable without changing user-facing behavior.
Original PR description
The test `test_option_into_share` was failing because `assertRecordValues` compares lists in order, and the records returned by the `cap.table` search were not in the same sequence as the expected values in the test. This commit makes the test deterministic by replacing list-based `assertRecordValues` calls with individual assertions per record. [RB-232585](https://runbot.odoo.com/odoo/error/232585) Forward-Port-Of: odoo/enterprise#95187
Code cleanup and technical improvements
This change removes unnecessary internal setup steps from automated test cases. It helps keep the test suite simpler and easier to maintain without changing how users experience Odoo.
16 changes
Security fixes and vulnerability patches
Shared MP4 videos in Documents can no longer be previewed by anyone with only a public link. This reduces unintended public viewing and helps prevent the system from being used as a video streaming service.
Original PR description
**Issue:** When sharing an MP4 video with "Anyone with the link" viewer access, the video is available to preview without login. **Steps to reproduce:** 1. Install documents 2. Upload an MP4 video 3. Share it with the smart button with anyone with the link viewer access 4. Copy link and paste it in incognito in chrome **Result:** - Video preview option is available **Cause:** - The method get_previewable_file_extensions allows 'mp4' videos to be previewed. **Solution:** - Remove the 'mp4' extension from the previewable list. **NOTE:** - We do not want to be 'used' as a video streaming platform. We do not do it for our own eLearning videos, so we can't do it here, Preview file should simply not be publically available for videos we host. opw-4926384 Forward-Port-Of: odoo/enterprise#90158
Enhancements to existing features
Hong Kong Payroll now includes a dedicated button to download IR56B report files in XML format. This makes it easier for payroll users to retrieve the required tax reporting file directly from the relevant screens.
Original PR description
Add ir56b report download button for downloading .xml file in Hong Kong Payroll. task - 5081474 Forward-Port-Of: odoo/enterprise#95294 Forward-Port-Of: odoo/enterprise#95013
The tax search screen now includes the configured tax amount in search results. This makes it easier for users to quickly find taxes by their percentage rate or fixed amount directly from the search bar.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
Resolved issues and error corrections
This fix prevents errors when assigning a previously created worksheet template after Field Service has been uninstalled and reinstalled. User-created worksheet templates are now removed during uninstall so invalid leftover templates do not disrupt task creation.
Original PR description
When user uninstalls and reinstalls `industry_fsm` the user created template is not removed causing `model_id` for the worksheet template turning `False` and raising a key error when indexing via `model_id`. **Replication steps:** * Install `industry_fsm` * Field Service>Configuration>Settings>Enable Worksheet templates * Configuration>Templates>Create New Template * Uninstall and reinstall `Field Service` * Field Service>New Task>Set worksheet template to the one you created `KeyError: False` **Solution:** * Unlink user created worksheet template on uninstallation of the application. **Sentry-6615576986** Forward-Port-Of: odoo/enterprise#86084
UAE invoice reports no longer show the amount column twice when tax-inclusive pricing is enabled. This makes printed proforma and tax invoices clearer and avoids confusing duplicate totals for customers and staff.
Original PR description
**Step to reproduce:** - install account module with localization "UAE" - go to Settings > Tax Included - create a invoice (make sure a tax is applied) - print any invoice (Proforma or Tax)…
**Step to reproduce:**
- install account module with localization "UAE"
- go to Settings > Tax Included
- create a invoice (make sure a tax is applied)
- print any invoice (Proforma or Tax)
**Observation:**
- the amount is being displayed twice in the Amount column.
**Cause:**
- A change was introduced in 18.0 to add additional column right after Amount
column, [1] in l10n_ae module
- Another commit [2] in saas-18.3 introduces same column in main account module
- hence we have two columns printing same information
**Fix:**
- Removed and fixed a faulty xpath from view, as after commit [2]
base layout provides same logic
[1] https://github.com/odoo/odoo/commit/fe68fa30b18f90411043fc6e2314fd376ddaed0c
[2] https://github.com/odoo/odoo/commit/1bf232c22f430d282aaadd858c5e61fed12f4da6
**Before:**
<img width="774" height="146" alt="image" src="https://github.com/user-attachments/assets/a9eb6af2-81b3-4989-bf6e-6676eafe10f8" />
**After:**
<img width="813" height="143" alt="image" src="https://github.com/user-attachments/assets/fb019516-de7d-4dd3-b7dd-3fd14322b031" />
opw-4976410
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#223382The self-ordering test now cancels only orders that are still in draft status, instead of trying to cancel every order. This prevents test failures when finalized or paid demo orders are present, helping keep validation runs stable.
Original PR description
Before this commit: = - Previously, `test_self_order_mobile` set all orders to cancel, causing errors with finalized orders (e.g., paid orders from demo data). After this commit: = - Only draft orders are cancelled, preventing errors and ensuring correct test behavior. Runboat Error: 224197 Forward-Port-Of: odoo/odoo#214935
A redundant navigation step was removed from a Point of Sale test flow to prevent intermittent test failures. This improves reliability of automated checks without changing business functionality or user workflows.
Original PR description
Before this commit: ================= The `test_draft_pos_order_linked_sale_order` test fails intermittently with a `psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the…
Before this commit:
=================
The `test_draft_pos_order_linked_sale_order` test fails intermittently with a
`psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the
browser tour navigates back to the backend.
After this commit:
=====================
The problematic navigation step is removed from the `PosSettleOrder5` tour,
stabilizing the test and preventing the runbot error.
Cause:
========
The `Chrome.clickMenuOption("Backend", { expectUnloadPage: true })` step
forces an immediate database flush (`self.cr.flush()`) during the test's
authentication phase.
This forced flush happens when the records are in an intermediate state (after
loading the Sale Order but before payment/validation). This specific
intermediate state, combined with the subsequent recomputation of computed
fields (like `qty_delivered` through `sale_mrp` and `sale_margin`), exposes an
underlying bug in Odoo's ORM cursor management, leading to the
`psycopg2.ProgrammingError`.
Since the backend navigation is not necessary for the test's assertion logic,
removing this step prevents the premature flush and resolves the failure.
Runbot Error: 226521
Task: 4974084
Forward-Port-Of: odoo/odoo#228799
Forward-Port-Of: odoo/odoo#228193Failed webpage scraping in the AI module is now recorded as a warning instead of an error. This avoids unnecessary error alerts while still informing users when a webpage cannot be processed.
Original PR description
Currently, an error can occur on unsuccessful scrapping of URL.
**Error:**
`Error scraping URL https://agenciavirtualpy.com: HTTPError('403 Client Error: Forbidden for url: https://agenciavirtualpy.com/')`
- Instead of logging an error, we log only warning during unsuccessful URL
scraping because it is not a blocking point in the code.
- On unsuccessful scraping, we log warnings [1] and raise a UserError [2] to
inform the user about the failed URL scraping. Therefore, we should log a
warning as the UserError is already present.
[1]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L258
[2]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L283-L285
sentry-6634525990
Forward-Port-Of: odoo/enterprise#94002Colombian Support Document Credit Notes now send product identification in the format expected by DIAN, even when barcode or UNSPSC data is available. This prevents avoidable document rejections and helps businesses submit compliant supplier credit notes more reliably.
Original PR description
Before this PR:
- Support Document Credit Notes sent barcode (scheme 010) when available, causing DIAN `NSAZ13` error and document rejection.
After this PR:
- Although a product has all of these 3 fields configured (barcode, UNSPSC, internal reference), still, for a Support Document Credit Note, the `cac:StandardItemIdentification` is always sent with the Internal Reference information ('999', 'Estándar de adopción del contribuyente').
- If internal reference is not configured, then barcode or UNSPSC code is sent with scheme ('999', 'Estándar de adopción del contribuyente').
task-4796034
Forward-Port-Of: odoo/enterprise#94140The POS payment screen now prevents repeated Validate clicks while an online payment order is still syncing. This avoids checkout errors on slow networks and helps cashiers complete online payments more reliably.
Original PR description
Currently, an error occurs when validating an online payment if the network is slow. **Steps to Reproduce:** 1) Install POS (with demo data) and the Demo Payment module. 2) Go to Payment Methods and…
Currently, an error occurs when validating an online payment if the network is slow.
**Steps to Reproduce:**
1) Install POS (with demo data) and the Demo Payment module.
2) Go to Payment Methods and create a new online payment method for any shop (e.g., a clothing shop). Set the Payment Provider to `Demo`.
3) Open a POS session for the clothing shop, select any product, and proceed to payment.
4) Open Inspect → Network tab, create a custom slow network profile(e.g., `set both download and upload speed to 1 KB/s`), and switch to that network.
5) Select the online payment method you just created and continuously click on Validate.
Error:
ValueError: Expected singleton: pos.order('p', 'o', 's', '.', 'o', 'r', 'd', 'e', 'r', '_', '4')
**Root Cause:**
When an online payment is validated, the `_isOrderValid` and `addNewPaymentLine` methods are called.
- With a slow network, the order ID is still temporary(e.g., e74a3369-7dcd-4234-b35e-04daa149ffe6) as the order is not synced completely, when the code at [1] is executed.
- Due to multiple clicks, `_isOrderValid` forces a call to `update_online_payments_data_with_server` at [2] before order is synced.
- This eventually passes the temporary ID to `get_and_set_online_payments_data` at [3], causing the issue.
**Fix:**
Prevent multiple clicks on Validate until the order is successfully synced.
[1]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L11-L17
[2]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L87
[3]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/models/pos_store.js#L18-L26
**sentry-6849786792**
Forward-Port-Of: odoo/odoo#227967
Forward-Port-Of: odoo/odoo#225371This update resolves several user-facing issues across Odoo, including clearer payment error handling, correct website category breadcrumbs, safer signature submission, and fixes for localized document handling. These changes reduce confusion, prevent duplicate attendance actions, and improve reliability in day-to-day workflows.
Original PR description
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 fix makes Turkish Nilvera e-invoice imports save progress after each document is processed. If an import times out or hits an error, already imported documents are kept instead of being rolled back, reducing the need to repeat work.
Original PR description
Following bcab79c0ba9b550726164d80a22b50e689a2789c we are no longer committing changes in `_l10n_tr_nilvera_get_documents` as we loop through documents. The idea behind having that commit inside the loop was to avoid having to rollback all changes if we timeout or an error occurs. This is especially important when importing the current maximum amount of documents (30). This commit restores that behavior. No Task ID. Forward-Port-Of: odoo/odoo#228616
This fix restores the correct VAT return status workflow for French, Danish, and Latvian reports. It helps ensure users see and use the proper return states when preparing VAT filings, reducing the risk of process errors.
Original PR description
*: fr, dk, lt In a3083e9db2534d649bfc2d02dac79582ebb6397a a new field `states_workflow` was added which determined the states possible for the return. The commit also incorrectly set the wrong value for this field in the XML for French, Danish and Latvian VAT returns. This fixes it. no task-id
Timesheet approvers with the right permissions can now see other users' timesheets on private project tasks they follow. This fixes a visibility gap so managers and approvers can review relevant time entries consistently in task views and reports.
Original PR description
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security…
**Issue:** Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself. **Cause:** The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access. https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76 https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117 **Steps to reproduce:** 1. Create a private project (`privacy_visibility == 'followers'`) 2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access 3. Add Marc Demo as a follower of a task in that private project 4. Have another user log time on that task 5. Log in as Marc Demo Marc cannot see the other user's timesheets, neither on the task form nor in reporting. opw-5022877 Forward-Port-Of: odoo/odoo#226948 Forward-Port-Of: odoo/odoo#224025
This fix swaps the placement of the “exempt” and “exempt imports” fields in the Mexican DIOT report so each value appears in the legally expected column. The amounts were already calculated correctly, but the corrected layout helps avoid confusion and reporting mistakes.
Original PR description
Description of the issue/feature this PR addresses: The description of the columns “exempt imports” and “exempt” is somewhat ambiguous, so when developing the diot, there was a small error in the order of the columns. The values are calculated correctly, but columns 49 and 50 were inadvertently swapped. Current behavior before PR: “exempt” is column 49 “exempt imports” is column 50 Desired behavior after PR is merged: “exempt” is column 50 “exempt imports” is column 49 Task-id: 5096808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228882 Forward-Port-Of: odoo/odoo#228303
Dark mode display issues were corrected in Point of Sale and appointment screens. Icons and text now use colors that remain readable across light and dark themes, making the interface easier to use for staff.
Original PR description
In this commit: ------------------- - Added a dark mode color for the star icon. - Changed the text color to white in light mode, which is reflected as black in dark mode. This fixes the issue of the text not being properly visible in dark mode. task:4943078 Forward-Port-Of: odoo/enterprise#93993
4 changes
New functionality added to Odoo
Adds a new connector to import orders from multiple TikTok Shop or Tokopedia Shop accounts into Odoo. It matches orders to products, supports both seller-fulfilled and platform-fulfilled flows, and can synchronize delivery and stock information for seller-fulfilled orders.
Original PR description
- Import orders from multiple accounts - Orders are matched with Odoo products based on their internal reference (item_id or SKU ID in Tokopedia | Shop) - Support for both Fulfillment by TikTok/Tokopedia | Shop (FBT), Fulfillment by Seller (FBS): - FBT: Importing the completed orders - FBS: Delivery information is fetched from Tokopedia | Shop, track and synchronize the stock level to Tokopedia | Shop Task ID: 3690836
This adds support for carrying Taiwan ECPay e-invoice details from point-of-sale and online checkout through to invoice creation. It helps Taiwanese businesses capture the right invoice information during sales, reducing manual follow-up and improving compliance workflows.
Original PR description
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
Enhancements to existing features
The tax search now includes the configured tax amount, so users can quickly find taxes by entering a percentage or fixed amount in the search bar. This makes tax setup and review faster, especially for companies with many tax records.
Original PR description
This commit improves the usability of the tax search view by including the `amount` field. Users can filter taxes based on their configured percentage or amount directly from the search bar. task-5088050 Forward-Port-Of: odoo/odoo#227131
Resolved issues and error corrections
Applicants who schedule their own interview through the Appointment app are now correctly linked to their recruitment record. This ensures the applicant profile shows the right meeting count, helping recruiters track interviews accurately.
Original PR description
In this bug, the number of interview meeting of applicant is not shown correctly. The meetings which are scheduled by applicant in appointment app, are not take into account. To reproduce: 1- Create a db with appointment and recruitment installed. 2- Create a new job position, with email template to let applicant schedule a meeting. 3- Move forward the applicant to interviewing stage, and use the link provided to the applicant to set an appointment. 4- Open applicant. As you see, the smart button is showing: `No Meeting` This bug, is result of not setting `applicant_id` in the `calender.event` when the event is set by the applicant. When db user schedules the event, the context has a default value `default_applicant_id`, but this is missing for the case when applicant sets the interview themsevles resulting `applicant_id` to be empty. opw-4784349
4 changes
Resolved issues and error corrections
This update fixes an automated test so it selects the correct first available option when barcode manufacturing flows are checked. It helps keep validation stable after related purchase lookup behavior changed, reducing false test failures without changing day-to-day user functionality.
Original PR description
## Versions 17.0+ ## Issue Test wants to click the first dropped down element which changes because of Purchase lookup behavior opw-5025352
Purchase order lines now find matching products regardless of letter casing, aligning their behavior with sales orders. This helps buyers see all relevant product matches when creating RFQs or purchase orders, reducing missed selections caused by case-sensitive internal references.
Original PR description
## Versions 17.0+ ## Issue Inconsistent product lookup behavior between Sales Orders and Purchase Orders. When searching for a product in a Sales Order line, all matching products are suggested,…
## Versions
17.0+
## Issue
Inconsistent product lookup behavior between Sales Orders and Purchase Orders.
When searching for a product in a Sales Order line, all matching products are suggested, regardless of letter casing.
However, in Purchase Orders, the same search behaves differently. If "Variant Grid Entry" is **unchecked**, only an exact (case-sensitive) match is returned.
## Steps to reproduce
*Ensure Sales app is installed*
- Create 2 products:
- Product 1:
- Name: TEST;
- Internal Reference: Aa1.
- Product 2:
- Name: TEST;
- Internal Reference: aA1.
- Create a SO for any customer:
- Add product by looking for "Aa1", and see both "TEST" products.
- Go to Purchase's settings:
- Uncheck "Variant Grid Entry" if checked.
- Create a RFQ for any customer:
- Add product by looking for "Aa1", and see only one "TEST" product.
## Cause
POs use `product_id` while SOs use `product_template_id`:
https://github.com/odoo/odoo/blob/777f4e8e716db0cdc30c7d7c593e1cbf4a7ae12c/addons/purchase/views/purchase_views.xml#L276
https://github.com/odoo/odoo/blob/777f4e8e716db0cdc30c7d7c593e1cbf4a7ae12c/addons/sale/views/sale_order_views.xml#L492
This means a PO calls `ProductTemplate`'s `_name_search` method while an SO calls `ProductProduct`'s `_name_search` method:
https://github.com/odoo/odoo/blob/777f4e8e716db0cdc30c7d7c593e1cbf4a7ae12c/addons/product/models/product_template.py#L549-L599
https://github.com/odoo/odoo/blob/777f4e8e716db0cdc30c7d7c593e1cbf4a7ae12c/addons/product/models/product_product.py#L543-L591
## Fix
These 2 methods are acting differently but are used in complex flows (like for Barcode app). Adding a more open domain only on Purchase's `ProductProduct` model allows to target specific spots to apply the `ilike` search.
opw-5025352The update ensures DATEV main account settings are applied only to companies based in Germany, preventing incorrect accounting behavior for companies in other countries. It also improves how debit and credit lines are gathered, making the process more efficient for larger accounting entries.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`.
Uploaded files added to field service worksheet templates are now shown when the worksheet is opened for portal signing. This prevents missing attachments in customer-facing reports and ensures technicians' uploaded files remain visible during the signing process.
Original PR description
Steps to reproduce: ------- - Install industry_fsm_report module - Open FSM app - Select worksheets from settings in the configuration - Go to worksheet templates in the configuration - Create a worksheet template - Click the design template button. You arrive in the studio - Add file field and close it - Create a new task and select a newly created template in the worksheet template - Click the worksheet button in the control panel - Upload a file and save it - Click on the sign report button - Here file field is not visible Issue: ------- The file field is not visible in the worksheet portal. Cause: ------ The view of the file field is not created for the worksheet portal. Solution: ------- Created the view of the file field to display in the worksheet portal. task-3691529