Daily updates from Odoo
Monday, September 29, 2025
207 changes
32 changes
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
This fix makes an automated website test wait more reliably when the test environment is running slowly. It reduces false test failures, helping keep development and release validation smoother without changing user-facing website behavior.
Original PR description
__Current behavior before commit:__ The timeout in `waitForReposition` is sometimes reached if runbot is on heavy load making the test fail. __Description of the fix:__ Remove `waitForReposition` and use `waitUntil` instead. This should wait more time if runbot is on heavy load. The timeout has been increased for security. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/232802
The barcode kanban view now only displays existing inventory quantities instead of allowing new ones to be created by mistake. This helps avoid inaccurate stock records when users scan or type product barcodes and switch to the kanban view.
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
The website builder now opens the edit dialog for the specific submenu a user selected, instead of defaulting to the top-level menu. This prevents confusion and helps website editors update event or nested navigation menus more accurately.
Original PR description
With the initial [website builder refactor], when user wanted to edit sub-menu with "Edit Menu", it opened the dialog to edit the top-level menu. This commit fixes that behavior by looking up the id of the containing menu (if any) Steps to reproduce: - On `/event/<some-event>`, open website builder - Click on a link in the menu of the event (not the top menu) - Click on "Edit Menu" button in the link popover - Bug: the edit menu dialog opens for the top level menu [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
Website editors can now use the "On Hover" animation option on images even after applying a shape. The option is only hidden when the chosen shape already includes its own animation, preventing conflicts while preserving more design flexibility.
Original PR description
Applying a shape to an image unintentionally disabled the "On Hover" animation option. This commit restores the option with proper checks, ensuring it remains disabled only when the applied shape includes an animation. The related code was also refactored slightly for improved readability. Steps to reproduce: 1. Enter edit mode in Website. 2. Add an image and apply a shape. 3. Notice that the "On Hover" animation option is incorrectly hidden.
Turkish Nilvera e-invoice imports now save progress after each document is processed. This reduces the chance of losing all imported documents if a timeout or error occurs during larger imports.
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
The rating form now hides placeholder words like “by” and “on” when there is no related comment or publisher information to show. This removes confusing leftover text and makes rating records easier for users to read.
Original PR description
Steps to Reproduce: 1. Navigate to a rating record form view 2. View ratings without publisher comments 3. Notice confusing 'by on' text fragments appearing Current Behavior: - 'by on' text shows even when there's no comment or publisher information - Text fragments remain visible after comments are removed Expected Behavior: - 'by' and 'on' text should only appear when there's actual content to display - Proper conditional visibility based on comment presence Changes Made: - Added conditional visibility to rating form view text elements - Improved XML structure for better maintainability - Fixed persistent text display issues when comments are removed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225300
This fixes an automated website menu test that could fail in smaller single-app test builds because the menu did not contain enough items. The change helps keep website test results reliable without affecting end users.
Original PR description
Following this [commit], this tour would fail whenever it is run in single-app test builds. This happened because there were not enough items in the nav for the tour to function properly. Also, removed the "@odoo/hoot-dom" dependency. Build error-231699 [commit]: https://github.com/odoo/odoo/commit/7279c92fcb999f621fd9725c2339247c620ed378
This fix replaces a technical crash with a clearer, user-friendly message when users or customizations try to search unsupported non-stored many-to-many relationship fields. It helps administrators and developers understand the issue faster without exposing confusing internal errors.
Original PR description
When searching non-stored many2many fields, fail with a user-friendly message.
`self.env['account.payment'].search([('reconciled_invoice_ids', '=', 1)])` today results in an AttributeError when trying to get the SQL for the bridge table name.
task-5061329
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe event registration email template now keeps QR codes at the correct size after template edits or previews. This prevents distorted QR codes, helping attendees reliably scan their registration details.
Original PR description
### Steps to reproduce: 1. Set up an event registration with atleast 1 attendee. 2. Go to email templates and search for "Event: Registration Confirmation". (or any with QR code in it) 3. Check the preview of the email template. 4. Edit any text inside the template and check the Preview again. (QR code stop taking the proper height) ### Issue: During the rendering of the email template, the QR code image html is changing provoking the QR to not have the proper aspect ratio and look stretched. ### Fix: We can make sure we're always taking the 100% height of the container by adding a style attribute to the image tag, thus not losing the aspect ratio of the QR code. opw-4976893 Forward-Port-Of: odoo/odoo#223774
This fixes a restaurant point of sale issue where newly added items could appear saved but not be fully synced before being sent to the kitchen printer or preparation display. Staff should no longer encounter the "Order Outdated" error in this workflow, reducing ordering disruptions and inconsistencies.
Original PR description
Before this commit, if an order had no changes and no preparation display was active, adding items to the order in the restaurant PoS and then returning to the tables would sync the order to the server and mark it as not dirty. As a result, reopening the order and clicking the order button to send it to the preparation display or printer would not sync the updated changes. This caused inconsistencies and errors. Steps to reproduce: 1. Open a table, place an order, and send it to the kitchen printer 2. Add more products but instead of placing the order, go back 3. Re-enter the table, place the order, and send it 4. When placing another order, the error "Order Outdated" appears This commit fixes the syncing logic to ensure that last changes are properly synced, avoiding the "Order Outdated" error. opw-5097566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228680 Forward-Port-Of: odoo/odoo#227824
25 changes
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'.
This update fixes a problem where reinstalling the Danish Nemhandel module could leave it broken. It helps businesses using Danish electronic invoicing keep the module reliable during maintenance or reinstallation.
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
The barcode Kanban view now only displays existing inventory quantities instead of allowing new ones to be created. This prevents accidental inventory records and helps keep stock data accurate when users scan or enter 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
The Australian TPAR report now excludes unrelated customer payments from the Gross Paid amount. This prevents overstated supplier payment reporting and helps businesses produce more accurate annual taxable payments reports.
Original PR description
Customer payment shoudn't be included in the TPAR report Steps: - Unarchive 10% TPAR tax - Make a bill for a partner X, set 10% TPAR tax on the invoice line and confirm - Create and confirm a customer payment for partner X - Go to 'Taxable Payments Annual Reports (TPAR)' -> The column 'Gross Paid' includes the customer payment Before this commit, we took all line from bank or cash journal to calculate the gross paid value. With this commit, we also restrict the lines to include only the one with 'asset_current' or 'liablility_current' account type. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457) opw-5045457 Forward-Port-Of: odoo/enterprise#95592 Forward-Port-Of: odoo/enterprise#95029
This fix makes Turkish Nilvera e-invoice imports save progress after each document is processed. If an import times out or encounters an error, already imported documents are kept instead of being rolled back, reducing rework and improving reliability for larger batches.
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
The web testing tool now distinguishes between different levels of errors and warnings, so issues are reported with the right urgency. This helps developers see important problems earlier while preventing expected or lower-priority test issues from disrupting test runs unnecessarily.
Original PR description
This commit associates separate "issue levels" to the test runner's internal logger. These affect the logging and reporting of issues, i.e. errors and warnings: - suppressed (by 'test.todo'): issues are traced in the console but not reported in test results; - trace (default in test runs): issues are traced in the console and reported in test results; - global: issues are warned/errored in the console with "HOOT" prefix (i.e. won't interrupt the test run); - critical (default outside of test runs): issues are warned/errored in the console without "HOOT" prefix, thus interrupting the whole test run. This fix should hopefully solve errors that were too quiet before test run, or too "important" during the run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228674
Resetting a submitted tax return now correctly removes the previously generated tax journal entry and related attachments. This prevents old and new entries from being counted together when the return is submitted again, reducing the risk of incorrect tax amounts.
Original PR description
- Create a journal entry for a period. - In Tax return, submit the tax return for the period. - Reset the tax return (bypassing the lock date): the tax journal entry generated by the tax return is not deleted. - Resubmit the tax return: both the old and the new journal entries are taken into account for the tax return value. Commit https://github.com/odoo/enterprise/commit/123ae45cbc966f6a2c03050899058aff175f92dd (in account_return.py) mistakenly removed the line unlinking the closing move and attachments at reset. We reintroduce them here. opw-4972892
Event registration confirmation emails now keep QR codes at the correct size and proportions after the template is edited or previewed. This prevents stretched QR codes, helping attendees reliably scan their tickets or registration details.
Original PR description
### Steps to reproduce: 1. Set up an event registration with atleast 1 attendee. 2. Go to email templates and search for "Event: Registration Confirmation". (or any with QR code in it) 3. Check the preview of the email template. 4. Edit any text inside the template and check the Preview again. (QR code stop taking the proper height) ### Issue: During the rendering of the email template, the QR code image html is changing provoking the QR to not have the proper aspect ratio and look stretched. ### Fix: We can make sure we're always taking the 100% height of the container by adding a style attribute to the image tag, thus not losing the aspect ratio of the QR code. opw-4976893 Forward-Port-Of: odoo/odoo#223774
5 changes
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**
Self-order point of sale orders will no longer be sent for preparation when the customer payment did not complete successfully. This avoids staff preparing unpaid orders and reduces operational confusion.
Original PR description
backport of : [#213493](https://github.com/odoo/enterprise/pull/87173) opw-4974253
17 changes
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
14 changes
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
The Mexican DIOT report export now places the “exempt imports” and “exempt” values in the correct columns. This prevents confusion when businesses submit or review the downloaded TXT file, while the underlying calculated amounts remain unchanged.
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
1 change
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
6 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
The CRM Periodic Digest tip now shows the correct number of free credits for targeted lead generation. This avoids misleading users by stating 20 credits instead of the incorrect 200 credits.
Original PR description
## Versions 17.0+ ## Issue The Periodic Digest contains wrong information in a tip. 20 credits are given for specific target lead generation, not 200. opw-5114252
The partner ledger now keeps partner names and expand arrows properly aligned on phones and tablets. This makes the report easier to read and use on smaller screens without changing its functionality.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889