Daily updates from Odoo
Wednesday, January 7, 2026
66 changes · saas-19.1
Resolved issues and error corrections
This update corrects a bug in the Vietnamese VAT invoice generation process. Previously, the system would encounter errors when handling exchange rates with many decimal places. The fix rounds these rates to two decimal places, aligning with documentation requirements and ensuring accurate invoice calculations. This prevents invoice generation failures and improves data integrity.
Original PR description
* STEP TO REPRODUCE: create USD invoice to issue sinvoice, have currency rate like 26337.9186666777 , when issue we will get error because too many decimal * SOLUTION: round exchange rate up to 2 decimal because documentation said that is maximum Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241061
This update fixes an issue where the list view of vendor bills linked to analytic accounts didn't accurately reflect the number of bills available. The change ensures that all vendor bills and receipts are displayed, aligning the button count with the actual number of expenses. This improves the user experience when managing expenses.
Original PR description
Currently, when the user clicks the vendor bill smart button from analytic accounts, the list view shows no records even though the button count is greater than 0. **Steps to replicate:** * Install…
Currently, when the user clicks the vendor bill smart button from analytic accounts, the list view shows no records even though the button count is greater than 0. **Steps to replicate:** * Install `accountant` and `hr_expense` with demo. * Enable analytic accounting from settings. * Expense > Approve and Post submitted expense * Analytic Accounts > Nebula > Vendor Bills **Observed Behaviour:** * Even though the smart button shows a count of 1 there are no records displayed in the list view. **Root cause:** * After PR [1], vendor bills were changed to receipts. Since [2] counts receipts too, the button shows a different count than the list view, as [3] does not include receipts. **Solution:** * Show purchase receipts along with the vendor bills which correctly matches with the vendor bill count. [1]: https://github.com/odoo/odoo/pull/217758 [2]: https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L36 [3]: https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/account/models/account_analytic_account.py#L68 opw-5359320 Forward-Port-Of: odoo/odoo#238282
This update resolves an issue where product amounts remained at zero after removing optional items from a sales order. The fix ensures that when optional items are unset, the product quantities and prices are correctly restored, providing accurate order totals. This improves the reliability of sales order calculations.
Original PR description
**Steps to produce:** - Install the `Sales` module. - Create a Sales Order. - Add a section and some products under it. - In the section menu (three dots), click Set Optional. - Again, open the…
**Steps to produce:** - Install the `Sales` module. - Create a Sales Order. - Add a section and some products under it. - In the section menu (three dots), click Set Optional. - Again, open the section menu and click Unset Optional. **Issue:** - After unsetting the optional, the product amounts remain `0`. **Root cause:** - At[1], when setting options, both quantity and price are reset to `0`. - When unsetting optional, only the quantity is restored, leaving the price at `0`. **Solution:** - When unsetting optional, explicitly trigger the onchange on the field `product_uom_qty` using `.update()`. [1]https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/sale_management/static/src/fields/sale_order_line_field/sale_order_line_field.js#L138-L140 Before: <img width="1198" height="476" alt="image" src="https://github.com/user-attachments/assets/01dee1d6-2870-4222-8a6c-724fbfff8da1" /> After: <img width="1214" height="453" alt="image" src="https://github.com/user-attachments/assets/63ed4eb4-27cf-4b15-a957-c28a46a3ca42" /> opw-5368488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239805
This update resolves an issue where database neutralization inadvertently wiped out records from the res.users model due to a broad database truncation operation. The fix now selectively deletes only the 'mail.partner.device' records, preventing unintended data loss during testing and upgrades. This ensures a more stable and predictable database environment.
Original PR description
### Step to reproduce: 1. Create db in version 17.0 and create a many2one field with ``mail.partner.device`` 2. neturalize the db. All records of res.users will be vanish due to ``TRUNCATE…
### Step to reproduce:
1. Create db in version 17.0 and create a many2one field
with ``mail.partner.device``
2. neturalize the db. All records of res.users will be vanish due to ``TRUNCATE mail_partner_device CASCADE;``
### Issue:
during neutralize if there is any custom/studio field many2one with ``mail.partner.device`` even if the mail partner device
record won't used it in particular model still it will wipe out all the records of that model on neutrilizing
which can issue during testing on neutrlized db
**To fix it :**
[here](https://github.com/odoo/odoo/pull/133560/files#diff-284b40b100919f9b1d4f7bee50740387fea5f11815210baa5f6de9cbf317ca6dR14) want to delete only partner device. So, adjusted query using ``DELETE FROM mail_partner_device`` instead of truncate.
below traceback will generate due to this during upgrade.
```
Traceback (most recent call last):
File "/home/odoo/bin/misc/update_module_list.py", line 25, in <module>
env["ir.module.module"].update_list()
File "<decorator-gen-87>", line 2, in update_list
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_module.py", line 71, in check_and_log
log_data = (method.__name__, self.sudo().mapped('display_name'), user.login, user.id, origin)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1188, in __get__
raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: res.users(1,), User: 1)
[ERROR]::Error during the upgrade:
```
opw-5443072
upg-3712726
Forward-Port-Of: odoo/odoo#242081
Forward-Port-Of: odoo/odoo#241535This update resolves an issue where closing the event registration wizard in sales orders caused a technical error. The fix ensures that when an event selection is dismissed, the associated product is also removed from the sales order, preventing data inconsistencies. This improves the reliability of the sales order process.
Original PR description
**Steps to produce:** - Install `Events and Sales` modules. - Go to `sale > sale order > Open any SO > Add product > Event registration`. - When the wizard opens, dismiss it by either clicking the X…
**Steps to produce:**
- Install `Events and Sales` modules.
- Go to `sale > sale order > Open any SO > Add product > Event registration`.
- When the wizard opens, dismiss it by either clicking the X button in the
top-right corner of the modal or by pressing the `Escape` key.
**Traceback:**
`TypeError: Cannot convert undefined or null to object.`
**Root cause:**
- In this [commit], the `{ dismiss: true }` option was added to the `dismiss` call.
- At [1], when `onClose` is triggered, we only check `!closeInfo || closeInfo.special`.
Since `{ dismiss: true }` does not satisfy either condition, the code falls into the `else` branch,
where `update` is called with an `undefined` value.
**Solution:**
- Now, we also check the condition `closeInfo.dismiss`.
- So, now that we have closed the selection of the event, our product is also removed from the SO line.
[commit]: https://github.com/odoo/odoo/commit/31c00161fd3a77c9fbd260754cb8c142fcb0d652
[1]https://github.com/odoo/odoo/blob/01a896557ec2bada04db60195926c6fa61375b10/addons/event_sale/static/src/js/sale_product_field.js#L40
**opw-5349732**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#238061This update resolves an issue where deleting a specific product (Booking Fees) caused an access error due to company-related permissions. The fix uses `sudo()` to ensure the product template can be accessed regardless of the current company's settings, improving stability and preventing data loss.
Original PR description
**Steps to produce:** - Install `appointment_account_payment` and `l10n_be` with demo data. - Go to product `Booking Fees` and assign company `YourCompany`. - Switch the current company to `Belgium Company`. - Try to delete any product. **Issue:** - An access error is raised when deleting a product. **Root cause:** - During product deletion, method `_unlink_except_booking_fee_product_template` is executed [1]. - If the 'Booking Fees' product is assigned to another company, the current company cannot access its record, which triggers an access error. **Solution:** - Use `sudo()` when fetching the "Booking Fees" product template so that the record can be accessed regardless of the current company. [1]: https://github.com/odoo/enterprise/blob/0ba44def7fd961e1c17aa218e1a86a48f0918371/appointment_account_payment/models/product_template.py#L9-L15 opw-5255991 --- Forward-Port-Of: odoo/enterprise#101582
A technical issue causing a traceback when canceling orders with a specific default preset was fixed. The update redirects users to the correct screen before deletion and prevents new orders from being created, ensuring a smoother order cancellation process for restaurant staff. This improves the overall user experience.
Original PR description
### step to reproduce: - Set default preset to "Takeout or Delivery" in restaurant config. - Open restaurant . - Open any table and add a product. - Cancel the order using the action button. ### issue: - A popup appears asking to select a partner/floating order name, followed by a traceback. ### cause: - Traceback occures as next screen is loaded after order deletion. ### fix: - Redirect to the default screen before deleting the order. - Ensure that no new order is created when the next screen is the floor screen. task: 5092951 Forward-Port-Of: odoo/odoo#238158 Forward-Port-Of: odoo/odoo#227925
A recent update prevented a crash that occurred when opening salary package simulations with part-time settings. The fix involved correcting a JavaScript error related to the working schedule dropdown, ensuring smoother operation for part-time employee simulations. This improves the stability and usability of the HR module.
Original PR description
Version: - 19.0 Steps to reproduce: - Open the salary package simulation form. - Add &part=True to the URL. Issue: - Opening the salary package simulation with `&part=True` in the URL caused a JavaScript error. - The working schedule dropdown was created incorrectly, leading to a crash. Fix: - Use ownerDocument.createElement to correctly create the wrapper element in JS. - Ensure new_calendar is always defined before accessing its id when preparing payslip values. task-5265734 Forward-Port-Of: odoo/enterprise#99641
This update fixes an issue where UBL XML invoices were incorrectly including 'Invoice address' in the partner name. The change ensures that the commercial partner's name is used, aligning with standard Odoo XML generation and improving invoice accuracy. This ensures consistent and correct invoice formatting.
Original PR description
The dict-to-xml helpers were still using `partner.display_name` which includes the 'Invoice address' suffix. Changed to use `partner.commercial_partner_id.display_name` when partner name is not available, to match the fix in https://github.com/odoo/odoo/pull/232819 for the standard XML generation. task-4614564 Forward-Port-Of: odoo/odoo#242059 Forward-Port-Of: odoo/odoo#241250
This pull request addresses a minor issue with the Invoicing Payroll module. It corrects inconsistencies in report templates and wizards related to payroll payment reports, ensuring accurate and reliable reporting for tax compliance in Russia. This update improves the functionality of the HR Payroll module.
This update prevents the accounting application from automatically contacting our external Odoo Fin server when opened. Previously, it was making calls to production.odoofin.com to display favorite institutions. This change improves performance and reduces unnecessary external communication.
Original PR description
The aim of this commit is making sure that the click all won't try to contact our external server odoo fin when the accounting application is opened. Indeed, the accounting application is displaying the favorite institutions for a particular country in the accounting dashboard which is doing a call to production.odoofin.com. This commit adds a mock using _request_handler to patch the call to odoo fin. runbot-error-231151 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223680 Forward-Port-Of: odoo/odoo#223602
This update fixes a bug that prevented users from registering for event slots from pages other than the event registration page. Now, the 'register' button displays available slots on all event pages, improving the user experience and making it easier for attendees to sign up for sessions. This ensures consistent registration options across the event website.
Original PR description
* = event, event_booth, event_exhibitor, event_track, event_track_quiz The "register" button displays open slots only on the registration page of an event, and not on the other pages of this one. This PR fixes this issue by making available the open slots from the event.event model for the modal_slot_registration template as an instance of this one is always present in the context of those pages. Reproduce: Create an event with the "Multiple Slots" option checked and link it to a slot of tomorrow. The "register" button will display the slot on the registration page of the event but not on the page of the talks. Task-5083175 Forward-Port-Of: odoo/odoo#226635
This update fixes an issue where allocated leave time wasn't accurately displayed in the system, showing incorrect remaining balances. The fix removes unnecessary privilege escalation and ensures the system correctly calculates leave balances based on the intended allocation date, resolving a display discrepancy.
Original PR description
Bug: - Create a new employee (also reproducible with existing employees) - Create a Paid Time Off allocation that becomes available in the future - Create a Time Off request for this employee at a…
Bug:
- Create a new employee (also reproducible with existing employees)
- Create a Paid Time Off allocation that becomes available in the future
- Create a Time Off request for this employee at a future date
- When selecting the Time Off type, it shows “0 remaining out of 0 days” even though leave has been allocated
Reason:
In `_compute_display_name`, the record is accessed using `self.sudo().` Switching to superuser triggers `_compute_leaves`, but the context is lost and therefore the `target_date` is lost as well.
In `get_allocation_data`, because target_date is False, it is replaced with today’s date. This causes `max_leaves` and `virtual_remaining_leaves` to be computed as of today instead of the intended future date.
Fix:
Remove the `sudo() `and use the current user context instead.
-------------------------------------------------------------------------------
Test fix: `test_allocation_dropdown_after_period`
Bug:
After removing `sudo() `from `_compute_display_name`, the test fails and shows “0 remaining out of 0” instead of “9 remaining out of 9”.
Reason:
The test user (Admin) did not have the employee’s company in their allowed companies.
The `name_search` method triggers `_compute_display_name`, which triggers the computation of virtual_remaining_leaves.
Before the fix, `_compute_display_name` used `sudo()`, which propagated superuser privileges down to `_compute_leaves` and `get_allocation_data`. This masked the fact that the test user did not have access to the employee’s company (multi-company rule).
After removing `sudo(),` the user no longer had access to the allocation when running `name_search`, causing the test to fail.
Fix:
Add the employee’s company to the user’s company_ids. This allows allocations and `name_search` to work correctly without using `sudo().`
-----------------------------------------------------------------------
Known limitation:
When booking time off from the employee calendar view, the default value of `holiday_status_id` in the Time Off request widget still calculates remaining days based on today’s date instead of date_from.
To avoid confusion, the display name does not include “(x days remaining out of y days)” in this context.
However, when opening the selection dropdown, the display name is correct and uses the proper date-based calculation.This update fixes inconsistencies in the discount dialog and number popup appearance. The dialog title has been simplified for clarity, and the number popup styling has been standardized. Additionally, the width of the number pop-up dialogs has been adjusted to match previous versions, ensuring a consistent user experience.
Original PR description
Before this commit: =================== - The dialog title was `Discount Percentage`, even though the global discount can be applied either as a fixed amount or as a percentage. - The NumberPopup has double primary buttons (Type and Confirm buttons), which leads to an inconsistent UI - Also, since this commit https://github.com/odoo/odoo/commit/01741aa2619998078bd19aca848146ac75c027fc, the PoS NumberPopup dialogs have some extra width. After this commit: ================== - We renamed the dialog title to `Discount` to make it more generic. - We updated the NumberPopup type selector styling to make UI consistent. - Also reduced the width for the number pop-up dialogs, same as the previous version. Task: 5424805 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where UrbanPiper receipts displayed duplicate customer addresses. Now, the UrbanPiper receipt correctly shows the delivery address from the `pos_urban_piper` module, while the standard `point_of_sale` address is hidden. This ensures accurate and consistent receipt information for UrbanPiper customers.
Original PR description
### Before this commit: - Address details were already displayed from the `point_of_sale` module, but `pos_urban_piper` was also displaying them, causing the address to appear twice. ### After this commit: - For the UrbanPiper receipt, the `point_of_sale` address is hidden, and the `pos_urban_piper` delivery address is shown. Task:5353203
This update prevents the creation of duplicate bank accounts when using the bank reconciliation widget. It ensures that if an account number is already in use by another active partner, a new account won't be created, reducing confusion and streamlining the reconciliation process. This change is specifically focused on the reconciliation flow.
Original PR description
When using the bank reconciliation widget, avoid creating a new bank account on the selected partner if the same account number already exists on another active partner. This change is intentionally limited to the reconciliation flow only, to reduce noise caused by duplicate bank accounts, and does not affect other partner or bank account creation use cases. task- 5236503 Forward-Port-Of: odoo/odoo#234531
This update corrects an issue with how invoices are formatted for electronic delivery to ECPay in Taiwan. The change removes the company name from the EDI address and uses a simplified, comma-separated format. This ensures compliance with ECPay requirements and improves the accuracy of invoice transmission.
Original PR description
In this commit: --- Update EDI address formatting to remove the company name and send a comma-separated single-line address. task-5410619 Forward-Port-Of: odoo/odoo#241964 Forward-Port-Of: odoo/odoo#241108
This update fixes a rounding issue in the sales timesheet calculation, ensuring accurate remaining time displayed on Sales Orders. Previously, slight rounding errors accumulated, leading to inaccurate time overconsumption. The fix eliminates intermediate rounding to provide a precise and consistent calculation.
Original PR description
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order…
Steps to reproduce: - Create service product with UoM 'pack of 20 hours' and prepaid policy - Sell the product and confirm the Sales Order - Create a helpdesk ticket/task linked to the Sales Order Line - Log 22:00 on timesheets Current behavior: Sales Order Line shows '-2:01 remaining' Expected behavior: Should show '-02:00' to reflect two hours overconsumed without rounding. Root cause: Python's float type follows the IEEE 754 double-precision standard, where only base-2 fractions can be stored precisely. Base-10 fractions cannot be represented exactly, introducing tiny rounding errors. During chained operations such as multiple conversions or subtractions, these small errors accumulate into larger discrepancies. The float_round() function uses a small constant epsilon to correct rounding noise, but as arithmetic chains grow, errors exceed epsilon's tolerance and it can no longer correct them. Since a single global epsilon cannot handle every case (small vs. large values, chained vs. single operations, or regressions), rounding drift is inevitable when rounding happens repeatedly. Fix: To prevent these rounding errors from compounding, the solution is to stop intermediate rounding altogether. By using conversions with round=False, all arithmetic is done in the base unit (hours) with full float precision, and rounding is applied only once when displaying the final value. This eliminates error accumulation and ensures consistent, drift-free results. task-5090240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241120 Forward-Port-Of: odoo/odoo#229282
This update resolves an issue where deleting a used payroll rule section caused errors and prevented updates to related salary rules. The fix ensures that rule sections linked to active contracts or payslips cannot be deleted, maintaining data integrity and preventing disruptions to payroll processing.
Original PR description
### Steps to Reproduce 1. Create a Salary Rule Section. 2. Link it to a Salary Rule and add it to a contract or payslip. 3. Delete the Rule Section. 4. Go back to the Salary Rule. 5. The section field is invalid/readonly, making it impossible to assign a new section or fix the rule. ### Reason Deleting a section linked to a Salary Rule breaks the link without clearing it, leaving the rule in a broken, unusable state. ### Solution Prevent the deletion of Salary Rule Sections if they are linked to a Rule that is actively used as an input in a contract or payslip. Task: 5390387 Forward-Port-Of: odoo/enterprise#102222
This update ensures that new Odoo users automatically have access to VoIP groups (admin and officer) during upgrades. Previously, these groups were only added to new databases, leading to inconsistencies. This change enforces a consistent approach, simplifying future upgrades and preventing potential access issues.
Original PR description
Commit [1] introduced new groups for VoIP: admin and officer. Before that, the related rights came with the base admin group of Odoo. With that in mind, it made the new groups implied by the base…
Commit [1] introduced new groups for VoIP: admin and officer. Before that, the related rights came with the base admin group of Odoo. With that in mind, it made the new groups implied by the base admin group, but put them in a noupdate area of the security XML file, meaning only new databases would get the new groups assigned to the admin group. There were two possibles solutions: - An upgrade script to add the new groups to admin users (and/or the fact it is implied by the admin group). - Move the group definitions to a non-noupdate area, which re-forces the fact the VoIP groups are implied by the admin group at each upgrade, to any Odoo version. There is no guideline about this in Odoo and it is left to a per-app per-group choice. After consultation, the second solution was chosen: we prefer to enforce the fact that each new VoIP codebase, each version, relies on the fact admins are supposed to have those VoIP rights; forcing any customization of that fact to re-check it is working at each Odoo upgrade (and/or make a proper customization with custom apps instead of user manipulation). [1]: https://github.com/odoo/enterprise/commit/88b8de95e1a28a8037a386fc8fb6a044a98217e7 task-5440305 Forward-Port-Of: odoo/enterprise#103348
This update corrects a visual issue where resizing images within the HTML editor would cause a brief flicker. The problem stemmed from inconsistent mouse coordinate tracking between the iframe and the main window. The fix ensures accurate coordinate calculations during resizing, providing a smoother user experience.
Original PR description
Problem: After 3b28df9eb22a3eb9af129a7f756986f54b983fc3, resizing an image during transform causes a visible flicker. Cause: The same mousemove handler is attached to listeners on both the iframe and the window. When the mouse moves from the iframe to the window, `ev.pageX` and `ev.pageY` differ between the two contexts, leading to incorrect position calculations and visual flickering. Solution: When `mousemove` is triggered, correctly recompute `pageX` and `pageY` when transitioning between iframe and window contexts, ensuring consistent coordinates during resize. Steps to reproduce: - Open website/jobs. - Try to transform and resize the image on the right. - Observe a flicker while resizing. opw-5368040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240935
This update corrects an issue where the numbers displayed as carousel indicators were unreadable and misaligned. The fix ensures the correct sizing and color of number indicators when positioned outside the carousel, resolving alignment problems with the navigation buttons.
Original PR description
The css rules for indicators outside the carousel were not adapted for number indicators, and used the button color intended for dots and bar as background of the numbers, making them unreadable and…
The css rules for indicators outside the carousel were not adapted for number indicators, and used the button color intended for dots and bar as background of the numbers, making them unreadable and ugly. The height of the indicators when outside influences the margin needed to align the bottom of the prev/next buttons. That caused the bottom of the next/prev buttons to not reach the bottom of the slide with "Numbers" or "Hidden" as indicators. This commit adds the necessary css rules to correctly size and colors the number indicators (and the hidden one) when positioned outside. Steps to reproduce - Add a carousel - Set "Indicators" to "Numbers" - Set "Style" to "Indicators outside" - Bug: The colors are all wrong, we cannot see the numbers - Bug: The bottom of the previous/next buttons do not reach the bottom of the carousel - Set "Indicators" to "Hidden" - Bug: The bottom of the previous/next buttons is even further from the bottom of the carousel task- 5358507 Forward-Port-Of: odoo/odoo#237397
This update corrects a visual issue where the label for OCR data in expense records appeared incorrectly within the grid layout. The fix removes an unnecessary label that only displayed in debug mode, resolving the misalignment and improving the user experience when viewing OCR-processed expenses. This ensures consistent and accurate display of expense information.
Original PR description
Prerequisites ------------- To test this scenario you need either OCR credits, a free trial or to use the IAP account we have in the spreadsheet. Steps To Reproduce ------------------ 1- Go to Expenses > My Expenses. 2- Upload a receipt to trigger OCR. 3- Open the expense in Normal Mode (It works fine in Debug Mode). Issue ----- "Payment Method" field is misaligned - label appears in the value column and field appears in the label column. Cause ----- The label for "ID of the request to IAP-OCR" (`extract_document_uuid`) is visible when OCR data exists, but its field is only visible in Debug Mode. This orphan label breaks the grid layout. opw-5369619 Forward-Port-Of: odoo/enterprise#103189
This update resolves an issue where the analytic distribution field in Odoo contained unexpected data types (like '__update__'), causing errors during account ID retrieval. The fix now safely processes only strings that can be interpreted as numbers, ensuring data integrity and preventing future processing problems.
Original PR description
Issue: Before this commit, the analytic distribution field contained a mix of integers (account IDs) and strings (such as '__update__'). When attempting to retrieve the account ID, converting the '__update__' string to an integer caused an error. Fix: As a generic solution, instead of skipping only the '__update__' key—which may not be the only non-numeric string in the future—we now process only the strings that can be safely interpreted as numbers. opw-5450293 Forward-Port-Of: odoo/odoo#242021
This update fixes an issue where vendor names in imported UBL invoices were incorrectly displaying contact person details instead of the company's legal name. The change prioritizes the company's official registration name, ensuring accurate vendor identification as per UBL standards. This improves data consistency and compliance.
Original PR description
Steps To Reproduce ------------------ 1- Go to Accounting > Vendors > Bills. 2- Upload a UBL XML file containing both RegistrationName and Contact/Name (you can use one of the two attached in the…
Steps To Reproduce ------------------ 1- Go to Accounting > Vendors > Bills. 2- Upload a UBL XML file containing both RegistrationName and Contact/Name (you can use one of the two attached in the ticked). 3- Check the Vendor field. Issue ----- The vendor name is set to the contact person name instead of the company's legal name. Cause ----- In `_import_retrieve_partner_vals`, the XPath prioritizes `cac:Contact//cbc:Name` (contact person) over `cbc:RegistrationName` (company legal name). Fix --- Swap the priority to check `RegistrationName` first, falling back to `Contact/Name` only when no registration name exists. Legal/Standards Proof (OASIS UBL 2.1 Specification) according to sources: https://www.datypic.com/sc/ubl21/e-cac_PartyLegalEntity.html - cbc:RegistrationName: "The name of the party as registered with the relevant legal authority." http://www.datypic.com/sc/ubl21/e-cac_Contact.html - cac:Contact/cbc:Name: "The name of this contact. It is recommended that this be used for a functional name and not a personal name." The RegistrationName is the official legal company name, while Contact/Name is just a contact point at the company. Test ------ For the test I updated a test file so that `test_import_partner_fields` fails without these changes. opw-5392139 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242046
This update fixes a visual inconsistency in the Point of Sale system. Previously, when searching for partners, the system would display a 'x partners found' message but not show the results in the list. This change adds support for wildcard searches, ensuring that the system accurately reflects the number of partners found and displays them correctly.
Original PR description
When the client typed `a%t%` into the search bar and pressed 'Enter', we load the partners from the backend using `getNewPartners` and showed a dialog "x partners found", however, we never show those results in the partner list since the search bar didn't support the wildcard ilike pattern. This commit adds support for searching wildcard patterns, to match the SQL behavior more or less. Clients now won't be confused by seeing "x partners loaded" and at the same time seeing an empty list. opw-5395340 Forward-Port-Of: odoo/odoo#242371 Forward-Port-Of: odoo/odoo#240541
This update fixes an issue where job offer emails didn't include the employee's name in the subject line. Now, the email subject will automatically include the employee's name, improving clarity and personalization for candidates. This enhancement ensures a more professional and informative communication process.
Original PR description
**Steps to reproduce:** - Go to Employees app and select any employee - Press "Offers" smart button - Create a new job offer and send it by email **Issue:** The employee name is not populated in the email subject. Task: 5407028 Forward-Port-Of: odoo/enterprise#102628
This update resolves a technical issue that prevented the POS Enterprise list view from loading correctly when in debug mode. The fix addressed a type mismatch between data fields, which was causing an error. This ensures a stable and reliable user experience for POS Enterprise users.
Original PR description
In this commit, --- - Removed the color option from the Stages field. - The color_field option only supports Integer fields, while the stage color field was of type Char. - This mismatch caused a traceback when opening the list view in debug mode. Fixing this ensures the list view loads correctly without errors. task-5446781
This update resolves an issue where sale order information wasn't consistently linked to the delivery moves associated with a picking. The change ensures that when a sale order is linked to a delivery, the correct delivery move references are maintained, improving order tracking and reporting accuracy. This fix was implemented to prevent discrepancies in inventory management and sales data.
Original PR description
### Steps to reproduce: - Create a picking with a move for any product #### Issue 1: > A procurement group is created and linked to the transfer - Add a second move on the picking and save #### Issue 2: > The procurement group of the picking is lost ### Cause of the issue: The `_set_sale_id` set method creates a procurment group and links it to the picking no matter if the `sale_id` is set or not. https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L90-L93 https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/sale_stock/models/stock.py#L100-L113 opw-5386424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240426 Forward-Port-Of: odoo/odoo#239697
This update fixes an issue where the order of products was incorrect on delivery slips. The fix ensures that products are printed in the correct sequence, as intended by the delivery process. This improves the accuracy and reliability of delivery slip reports.
Original PR description
**Steps to reproduce:** - Add 2 products in a delivery - Add the second's product move lines before the first one. - Validate and print delivery slip **Issue:** We iterate the `move_line_ids` directly which means if we have a new move line for a move with a lower id, it will push the product to the end of the delivery slip. **Example:** If we have `stock.move(1,)` with `stock.move_line(52,)` and `stock.move(2,)` with `stock.move_line(51,)`. `stock.move_line(51,)` will be printed first, which introduces a change in the order of the delivery slip. **Fix:** Iterate on `move_ids` and access `move_line_ids` through it, to print `move_lines_ids` in the same order of the `move_id`. Task: 4570203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242166 Forward-Port-Of: odoo/odoo#213400
This update corrects a discrepancy in the calculation of Belgian withholding taxes within the Odoo Enterprise system. The changes ensure that tax rates and regulations are accurately reflected up to the year 2026, improving the financial reporting for businesses using the Belgian localization module. This is a critical fix to maintain compliance.
Original PR description
TaskID: 5403525 Forward-Port-Of: odoo/enterprise#103271 Forward-Port-Of: odoo/enterprise#103215
A bug preventing users from searching within sign templates has been fixed. Previously, the search function within PDF templates was not working. This update removes a technical issue that blocked users from entering text into the search box, now allowing them to effectively search within the PDF documents.
Original PR description
Currently when the user is viewing sign templates, they are unable to search within a PDF. **Steps to replicate:** * Install `sign` with demo data * Sign > Templates > Open a template * Try searching using the magnifying glass button **Observed Behavior:** * User is unable to type anything in the PDF search box. **Root cause:** * This error happens because `preventDefault()` is called during a `keydown` event. At [1], calling `event.preventDefault()` stops the key’s normal behavior, so the typed character is not added to the input field. **Solution:** * Remove the `preventDefault` call which allows the search to work again. [1]: https://github.com/odoo/enterprise/blob/3df585779e6ede664279331c4531043688dadf17/sign/static/src/backend_components/editable_pdf_iframe_mixin.js#L623 opw-5366074 Forward-Port-Of: odoo/enterprise#102749
This update corrects a problem where new offers created from partially signed applicant agreements lacked the necessary sign template, preventing salary configuration. The fix ensures the correct sign template is applied when a new offer is generated from a partially signed agreement, streamlining the offer creation process for applicants.
Original PR description
steps to reproduce: - an applicant have signed with a company car + a car to order - go to Recruitment < Offers < Partially signed < Find the applicant - click on Contract Details to access the version - create a new offer through the smart button - the offer doesn't have a sign template so the salary configurator is not accessible Fix: use `sign_template_id` instead of `contract_update_template_id` as the sign template of the offer if the version is not active (because it is created from an offer which is half signed and it's basically a new offer not an offer for contract update) task-id: 5401539 Forward-Port-Of: odoo/enterprise#101724
This update resolves an issue where salary reimbursement amounts for public and train transport didn't reset to zero when the benefit was unchecked. The configuration now correctly clears the reimbursed amount field, ensuring accurate salary calculations and reducing potential errors in employee compensation. This improves data integrity and simplifies salary management.
Original PR description
Issue: public and train transport reimbursed amounts not reseting after unchecking them Steps to reproduce: - open salary configurator - check public(train) transportation - change the value in the input field - uncheck public(train) transportation - the value for the reimbursed amount doesn't reset to 0 Fix: - made the value reset for public and train transport to 0 in the ui of the configurator - made the employee amount reset to 0 in the employee form if the benefit is unchecked task-id: 5386766 Forward-Port-Of: odoo/enterprise#101592
This update resolves an issue where tax grouping keys could sometimes be unexpectedly empty in certain configurations. This fix ensures accurate tax calculations and reporting, particularly when generating invoices and exports. A minor correction was also made related to excise taxes.
Original PR description
Some overrides assign a value to the tax's grouping_key after the super call. However, the returned value could be None. Also fix a little mistake regarding excise taxes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239959 Forward-Port-Of: odoo/odoo#239954
This update resolves an issue where users were encountering an error when previewing XML files containing embedded PDFs. The fix ensures that thumbnails are only generated for valid PDF files, preventing the error and improving the Documents kanban view functionality. This ensures a smoother user experience when working with documents.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Upload an XML file that contains an embedded PDF in base64. 3. Click on the `Info & Tags` icon on the top right in the Documents kanban view 4. Open the imported XML file Issue: - An `Invalid Operation: Only PDF files can have thumbnail` error occurs. Cause: - The `Attachment` model attempts to generate a thumbnail for the XML file because it contains PDF data. However, as of now, thumbnails are only generated for valid PDFs, so the `generatePdfThumbnail` function returns `isPdfValid: false` but `setPdfThumbnail` method fails to handle this `false` value in resulting invalid rpc call. Solution: - Update the condition in `setPdfThumbnail` to consider only valid PDFs. File: [Link](https://drive.google.com/file/d/19OxVJeqj9i-VgH9D6Aqk0P9Tuf6zlPwB/view?usp=sharing) opw-5374529 Forward-Port-Of: odoo/odoo#240546
This update adjusts the timeout duration in the SMTPD tests, preventing unnecessary test failures caused by overly strict timing requirements. Increasing the timeout allows the tests to complete successfully, reducing the risk of automated failures and improving overall system stability. This change ensures smoother operation of the email infrastructure.
Original PR description
There are multiple cases where the SMTPD tests fail due to a timeout error. It is much worse to get a red runbot due to a silly timeout than to sometime wait a bit longer than .1 second. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242214
This update fixes an issue where attachments added to activity notes in the chatter wouldn't show their overview (the blue box). The team temporarily reverted a planned change to static rendering to ensure attachment overviews are consistently displayed in the chatter, improving the user experience. This ensures users can easily see the attachments associated with their activities.
Original PR description
--- ## Short functional explanation of the error When in the chatter, we can create an activity. If we add an attachment to the notes of this activity and save it, the overview of the attachment won't show in the chatter. ## Reproduction Steps 1. Open an app that gives you access to the chatter, for instance, an invoice in Accounting. 2. Click on Activity. Click on Log a Note... and on the button Upload a file. Upload an attachment and save. ### Expected behavior The overview of the file (blue box with the name of the attachment) should appear. ### Unexpected behavior The overview doesn't appear ## Origin of the issue Since 19.0, we want to replace static rendering with embedded components everywhere for rendering attachments, but this creates issues for the rendering of the overview in the chatter. Therefore, after internal discussion, we agreed to keep rendering overviews statically. opw-5356016 Forward-Port-Of: odoo/odoo#240114
This update fixes a bug in the Belgian payroll module that prevented accurate commission loss calculations during specific contract end and holiday scenarios. The issue was resolved by ensuring the code correctly processed conditions related to contract termination and public holidays, now accurately calculating and applying commission losses.
Original PR description
When we enter in the conditions regarding the the end of a contract and the public holidays, it return and does not enter in the part of the code that handle the loss of commission on public holidays. So instead of returning the res, we just continue to the next condition. Forward-Port-Of: odoo/enterprise#102963
This update fixes an issue preventing users from updating payment methods on unpaid orders created through the kiosk POS system. Previously, a printed ticket blocked payment changes. The change ensures payments are completed before restricting payment method modifications, allowing for accurate order management from the kiosk.
Original PR description
We have a check when validating an order on the POS that would not let you change the payment method if a ticket is already printed. This makes it impossible to create payments from POS for unpaid orders from the kiosk. I added an extra check during the validation to see that the payments are actually done, and only then forbid changing the payment method. Task-[5388807](https://www.odoo.com/odoo/project/1737/tasks/5388807) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238888
This update fixes an issue where website modules weren't correctly identified for translation. Previously, only modules starting with 'website' were added, causing translations to be missed for modules like 'ai_website'. Now, all website-related modules are included, ensuring all content is properly translated.
Original PR description
Current behavior before PR: Only the modules with names starting with 'website' were added to the website translated modules. Causing modules such as 'ai_website' to miss translations. Desired behavior after PR is merged: All the modules related to 'website' are selected and added. task-5375210 parent support task-5210084 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242229
This update ensures that IoT Box records are correctly updated during upgrades from Odoo 19.0 to newer versions. Specifically, the IoT Box must now provide its MAC address alongside its serial number, allowing the system to transition from using the MAC address to the serial number as the primary identifier. This improves data accuracy and consistency.
Original PR description
When upgrading from <v19.0 to v19.0+, the IoT Box needs to provide its mac address along with its serial number in order for the IoT Box record in the db updates the identifier from mac to serial no. see odoo/enterprise#103331 Forward-Port-Of: odoo/odoo#242212
This update fixes an issue where IoT Box identification was unreliable after database upgrades. Now, the system correctly identifies IoT Boxes using either their MAC address or serial number, ensuring accurate tracking and management. This improves the reliability of our IoT data collection.
Original PR description
After upgrading a db, the IoT Box updates. Before v19.0, the IoT identifier was its mac address, after it's the serial number. We now search boxes idenfied by both mac address or serial number and update accordingly. see odoo/odoo#242212 Forward-Port-Of: odoo/enterprise#103331
This update resolves an issue where users couldn't answer incoming calls when opening email or SMS wizards. The fix adjusts the software's layering to ensure the softphone is always visible and clickable when a call is active. This improves the user experience and allows for immediate call handling.
Original PR description
If you get a call when opening any modal/composer like email/sms wizard, you won't be able to pick up the call as the softphone is not clickable. This is because the z-index of the softphone is less than the modal. This commit fixes that issue by making the softphone above modals only if there is a pending call. [Task-4018118](https://www.odoo.com/odoo/project.task/4018118) Forward-Port-Of: odoo/enterprise#103121 Forward-Port-Of: odoo/enterprise#103072
This update optimizes the payroll calculation process by reducing unnecessary computations and streamlining data filtering. The changes enhance the system's performance and stability, particularly within the HR payroll module. This ensures accurate and efficient payroll processing.
Original PR description
## [FIX] hr_payroll: improve performance of _compute_issues Before this commit, the compute of issues field in `hr.payslip` model computes more than expected, that is, that compute computes other records than the ones contained in self. This part is not really needed since those payslips will surely be triggered afterwards thanks to the fields dependencies set on the compute method. That compute does a lot of filtered to almost do the same filter. The translation of each warning are called for payslips in which we detect there is an issue/warning. This commit reviews the compute method to reduce the computation cost. ## [FIX] hr_payroll: add hook to be able to alter the condition in filtered This commit adds a hook to be able to easily change the condition made in a filtered instead of doing 2 times the filtered.
This update resolves an issue where the 'View Reactions' button in the customer portal was causing errors. Now, users can reliably click this button and access the reactions list for messages without encountering technical problems. This improves the overall user experience and ensures consistent functionality.
Original PR description
Before this PR: - Clicking the 'View Reactions' button from the message right-click menu was throwing an error. After this PR: - Clicking the 'View Reactions' button from the message right-click menu now opens the reactions list correctly without errors. task-5449199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where push notifications could fail due to incorrect device registration settings. Specifically, it handles cases where the old subscription data isn't available during push subscription changes, and addresses issues with invalid domain names (like `.invalid`) used in push notification endpoints.
Original PR description
[FIX] mail: avoid error on service worker push subscription change Sometimes, the `pushsubscriptionchange` event is called without an `oldSubscription` defined, which can lead to an error occurring…
[FIX] mail: avoid error on service worker push subscription change Sometimes, the `pushsubscriptionchange` event is called without an `oldSubscription` defined, which can lead to an error occurring inside the service worker. Steps to reproduce: 1. Enable notification in Odoo. 2. Reset the permission in the Chrome interface 3. Re-enable the permission inside the discuss systray by clicking on the Odoobot message. => The pushsubscriptionchange is called without an oldSubscription [FIX] mail: ir_cron_web_push_notification are now more robust With a user having 5 registered devices for push notifications if a browser registers with an endpoint that has a wrong domain such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX the cron job cannot resolve the invalid domain of the endpoint and ends up disabling it. [FIX] mail: push_to_end_point method to support .invalid TLD if a browser registers with an endpoint that has a TLD `.invalid` such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX The TLD `.invalid`[1] is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The cron job cannot resolve the invalid domain of the endpoint and ends up disabling it. So we need to unregister a device with an endpoint with a `.invalid` TLD. [1]: https://datatracker.ietf.org/doc/html/rfc2606#section-2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242428 Forward-Port-Of: odoo/odoo#240502
This update corrects a visual inconsistency in the Odoo chatter interface. Previously, paragraphs added in the composer didn't maintain their bottom margin when posted to the chat, leading to a mismatched appearance. This fix ensures that the spacing between paragraphs in the chatter matches the composer and sent emails, improving the overall user experience.
Original PR description
Problem: When adding a paragraph in the composer and sending the message, the paragraph posted in the chatter has a `margin-bottom` of 0. Cause: Paragraphs in the chatter rendering override the default bottom margin, resulting in inconsistent spacing compared to the composer and the sent email. Solution: Update selector to only target the last `p`. Steps to reproduce: - Open the chatter composer. - Add a paragraph using "/Paragraph". - Add some text. - Send the message. - Observe that the message posted in the chatter has no bottom margin, unlike in the composer. opw-5378129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240082
This update fixes a limitation in the HTML editor where code blocks with syntax highlighting couldn't be easily converted back to regular paragraphs. A new button has been added to allow users to seamlessly switch between syntax highlighting and standard paragraph formatting within code blocks, improving note editing flexibility.
Original PR description
When syntax highlighting is activated on code blocks, neither the powerbox nor the toolbar is available inside the block, making it impossible to convert it back into a paragraph. This commit adds a button to convert such code blocks back into paragraphs. Steps to reproduce: - Go to a "To Do" note - Insert a code block with `/code` => There was no way to convert it back to a paragraph task-5241467 Forward-Port-Of: odoo/odoo#240692
This update resolves a technical issue that was causing duplicate test runs, leading to instability in the Odoo base module tests. The fix ensures tests run correctly and reliably, improving the overall quality and stability of the Odoo platform. This change primarily impacts the internal testing process.
This update fixes an issue where discount values were calculated incorrectly when using promotion programs on specific products with tax included. The fix ensures that discounts are applied accurately to the product's base price, leading to more reliable pricing and promotions in the Point of Sale system. This improves the accuracy of sales calculations.
Original PR description
When using a promotion program applied only on specific products with tax included prices, the discount value was incorrect. Steps to reproduce: ------------------- * Create a product with a price of…
When using a promotion program applied only on specific products with tax included prices, the discount value was incorrect. Steps to reproduce: ------------------- * Create a product with a price of 100$ and tax of 10% included * Create a promotion program with: - Apply on: Specific Products (the product created above) - Discount Type: $ Fixed Discount - Discount Value: 10$ * Open PoS and add the product to the order * Apply the promotion code > Observation: The value of the discount is 9.09$ instead of 10$ The same steps also applies to the discount reward applied on the whole order. Why the fix: ------------ When computing the discountable amount for the promotion it would take the amount excluding tax instead of the base price. The base price should be the unit price of the product multiplied by the quantity. As it was before here : https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/point_of_sale/static/src/app/models/pos_order_line.js#L470-L474 https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/pos_loyalty/static/src/app/models/pos_order.js#L1112 To do so we modified the accounting helpers to provide this value instead of computing it manually. opw-[5260067](https://www.odoo.com/web#id=5260067&view_type=form&model=project.task) opw-[5242194](https://www.odoo.com/web#id=5242194&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#240289
This update resolves an issue where stat buttons appearing within bottom sheets were sometimes displaying incorrectly, particularly in modules like Sale Project and Timesheet. This fix ensures that stat buttons function reliably within bottom sheet displays, improving the user experience.
Original PR description
when a stat button is displayed inside a bottom sheet, it can appear broken (e.g., in sale_project, sale_timesheet). task-5359751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238162
This update fixes a bug in the Point of Sale (POS) system where variant names weren't correctly displayed when a combo product was selected. Previously, if a combo contained a variant, the variant's name wouldn't appear on the order. This change ensures that variant names are accurately shown, improving the user experience and order accuracy.
Original PR description
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order ### Steps to reproduce: * Create a product with instantly generated variants * Create…
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order ### Steps to reproduce: * Create a product with instantly generated variants * Create a combo choice and add one of his variants * Create a combo product and add the combo * Open an store that sells this combo * Select the combo and choose the product with variant and confirm the selection Issue : On the left size in the order the variant name will not appear. ### Observation: When it tries to retrieve the attribute information for the variant https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/services/pos_store.js#L1048 It is empty since during the call of computeComboItems the attribute was not retrieved for this scenario. https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L31-L33 ------------ When adding a always variant to a combo they are considered like their own product, and attribute.extra_price should not be considered. The extra price for an always variant is setup in the combo with comboItem.extra_price like stand alone products. opw-5037355 Forward-Port-Of: odoo/odoo#239314 Forward-Port-Of: odoo/odoo#227176
This update fixes a previous issue where the 'Space' key wasn't functioning correctly when creating records in Odoo's Kanban views. Now, users can reliably use the 'Space' key, and 'Shift+Space', to navigate the 'Edit' and 'Trash' options, improving workflow efficiency.
Original PR description
In kanban's quick create record, the 'Space' key is not working on 'Edit' and 'Trash' buttons as earlier versions. After this commit 'Space' key will work as expected. Task-5319051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239478
This update fixes a recurring test failure in the MRP planning module. The change creates the planning leave manually instead of relying on a complex calculation, making the test more reliable and consistent. This improves the overall stability of the Odoo system.
Original PR description
Before this commit: Introduced in https://github.com/odoo/odoo/commit/d06dcfbca96273b540c87252b9188603879ac1b4, the test was failing on runbot in some cases. The issue is deterministic, but requires a specific set of modules installed to fail. After this commit: Use a more robust approach in the test, by creating the leave manually instead of computing the number of operations needed. runbot-234638 Forward-Port-Of: odoo/odoo#241928 Forward-Port-Of: odoo/odoo#239717
This update resolves an issue where arrow keys didn't function properly when adjusting range values (like intensity) in certain Odoo features. The fix replaces a flawed conversion method with a more accurate one, ensuring that fractional steps are handled correctly. This improves usability for users adjusting these settings.
Original PR description
**Problem** Arrow-keys don't work properly on `BuilderRange` if the `step` value is fractional. **How to reproduce** The problem is present on every `BuilderRange` having fractional `step`. For example: snippet `s_parallax` -> set "Scroll Effect" to "Parallax to Top" -> "Intensity" range. **Why the problem happens** The method `BuilderRange.onKeydown` retrieves the range value as a string, converts it to a number using `parseInt`, and then adds or subtracts the step value. Of course, `parseInt` is inappropriate when the value is expected to be fractional. **Fix** `parseInt` has been replaced by `parseFloat`. task-5405036 Forward-Port-Of: odoo/odoo#241141 Forward-Port-Of: odoo/odoo#239428
This update corrects a bug where changes made to nested website snippets (accordions and blockquotes) unintentionally affected other nested instances. The fix ensures that edits are applied only to the specific snippet being edited, improving the consistency and reliability of the website builder. This resolves a previous issue impacting user customization.
Original PR description
This commit fixes some issues that occur when editing nested instances of `s_accordion` and `s_blockquote` snippets. In all cases, changes applied to a parent unintentionally propagate to nested…
This commit fixes some issues that occur when editing nested instances of `s_accordion` and `s_blockquote` snippets. In all cases, changes applied to a parent unintentionally propagate to nested snippets. **Accordion issues** How to reproduce: drop two nested `s_accordion` snippets. Then: 1. Change the outer "Style" from "boxed" to "highlight active" -> both accordion change, 2. Change the outer "Round Corners" -> both accordion change, 3. Change the outer "Icon Position" -> both accordion change, 4. Change the outer "Icons" style -> both accordion change. **Blockquote issues** How to reproduce: drop two nested `s_blockquote` snippets. Then: 1. Change the outer "Decoration" -> both blockquotes change, 2. Set the inner "Decoration" to "Icon" -> works only if the outer snippet has icon too, 3. Change the outer "Author Alignment" -> only the inner blockquote changes. **Cause** The above issues occur because certain `applyTo` and certain CSS selectors match all nested elements rather than restricting the scope only to the snippet being edited. **Fix** The relevant `applyTo` and CSS rules now use more specific selectors. **Note** See also https://github.com/odoo/odoo/pull/237733 task-5362171 Forward-Port-Of: odoo/odoo#242077
This update resolves an issue where IoT devices were incorrectly attempting to retrieve their MAC addresses. The change ensures the system correctly obtains the MAC address, improving the functionality of the IoT integration. This ensures reliable data transmission from IoT devices to Odoo.
Original PR description
odoo/odoo#242356 fw port introduced an issue where the iot tries to get the mac address from `helpers` instead of `system`.
This update corrects a technical issue within the IoT Box image build process. The fix ensures the necessary software components are included, preventing a potential error that could have impacted image deployment. This resolves a minor technical problem without affecting core functionality.
Original PR description
As the image is built on a "non-RPI" linux machine, gatt isn't installed at build time. It requires the image to update itself to get the package. Even if the gatt package is only used for bluetooth caliper devices that are not widely used, this fix avoids a traceback.
This update fixes an issue where combo line prices were incorrectly set to 'automatic'. The change ensures combo line price types remain as originally defined, preventing conflicts with price updates and improving the accuracy of sales calculations. This ensures consistent pricing for combo products within the Point of Sale system.
Original PR description
After commit https://github.com/odoo/odoo/commit/69057e41fb4cd800d23401ead8ae11bf7cba7c64, the price type of combo lines was changed to 'automatic' when creating the combo line. This caused the set pricelist logic to update the price of combo lines with automatic price type, which conflicts with the intended behavior. This commit ensures that the price type of combo lines is preserved as original in cases where we want to update the price, and only set to automatic in cases like loading a sale order or refunding an order. opw-5240429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241737 Forward-Port-Of: odoo/odoo#234575
This update fixes a bug that caused confusing error messages when using QWeb with `etree` nodes. The improved logging now includes the surrounding code snippet, providing immediate context for developers and significantly simplifying the debugging process.
Original PR description
This PR fixes the error logging when QWeb is used with an `etree` node instead of a standard xmlid or id, to display the path of the directives (xml node) crossed. I have also improved the logging output when running with `--dev=qweb`: the error message now includes the generated code snippet surrounding the line that caused the error. This should make debugging much more intuitive by providing immediate context for the failure. Forward-Port-Of: odoo/odoo#242251
This update corrects a redundant permission check within the VoIP CRM module. Previously, access was granted based on a broader group, but it's now limited to the more specific 'salesman' group. This ensures only authorized users can access VoIP CRM features, enhancing overall system security.
Original PR description
`group_sale_manager` implies `group_sale_salesman`[1] [2]. Just checking `group_sale_salesman` is enough. [1]: https://github.com/odoo/odoo/blob/54681272e9f00a171fe49f690979e2a8353ff5fb/addons/sales_team/security/sales_team_security.xml#L25-L33 [2]: https://github.com/odoo/odoo/blob/54681272e9f00a171fe49f690979e2a8353ff5fb/addons/sales_team/security/sales_team_security.xml#L17-L23i Task-5461729 Forward-Port-Of: odoo/enterprise#103378
This update resolves an issue where UI tours were failing due to a change in how the product column was displayed on invoices and bills. The fix ensures the column is visible by default within the tours, restoring their intended functionality and improving the user experience. Runbot tests have confirmed the fix.
Original PR description
Commit 9c8e012 changed the visibility of the product column on invoices and bills. This caused several tours to fail as they expected the column to be visible by default. This commit fixes the failures by explicitly toggling the column visibility within the affected tours when required. runbot-234710 runbot-234871 runbot-234872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242247
This update fixes several issues within the spreadsheet component, ensuring smoother operation and improved data handling. Specifically, it addresses problems with date validation, grid resizing, and error recovery, enhancing the overall user experience. This is a routine maintenance update to maintain the stability of the spreadsheet functionality.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/febc3e9dbf [REL] 19.1.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/febc3e9dbf [REL] 19.1.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3b078a53a3 [FIX] session: always return a Promise [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5a41fa94fc [FIX] session: recover from errors when sending messages [Task: 5469116](https://www.odoo.com/odoo/2328/tasks/5469116) https://github.com/odoo/o-spreadsheet/commit/a2e90fb875 [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580) https://github.com/odoo/o-spreadsheet/commit/287f807aba [FIX] dashboard: properly handle grid resize in dashboard mode [Task: 5223156](https://www.odoo.com/odoo/2328/tasks/5223156) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a bug that caused data loss when users disconnected during spreadsheet revisions. The system now automatically retries sending messages, ensuring that all changes are successfully transmitted and preventing data loss due to interruptions. This enhances the overall stability and reliability of the spreadsheet feature.
Original PR description
If, for any reason, the sending of a revision creates an error b.e. when the user is disconnected, we never reset the "waitingForAck" flag, and all future messages will be queued but never send. The result of this behavior was that any user action during any disconnection will set the spreadsheet in a state where all changes from that point are lost. This fix handles the error while sending a message and always reset the flag, so that at next change, we will try to re-send the same message until it works. Task: 5469116
This update resolves an issue where creating a new spreadsheet template within the Quality Control app would trigger a validation error due to a missing default name. The fix provides a default name, ensuring the template creation process functions correctly and avoids user frustration.
Original PR description
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control…
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control Points. 3. Click "New". 4. Set the type to "Spreadsheet". 5. Click on Spreadsheet Template > Search More. 6. Click "New". -> A validation error is raised. **Cause** In `quality_view`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/quality_control/views/quality_views.xml#L840C17-L845C19 the `many2one_spreadsheet` widget (see [`many2one_spreadsheet_field.js`](https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L36)) overrides "Create and Edit" to create a new spreadsheet through `Many2XSpreadsheetAutocomplete`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L11C9-L14C51 This flow does not set a default value for the required `name` field, nor does `action_open_new_spreadsheet`:https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/spreadsheet_edition/models/spreadsheet_mixin.py#L348 Since `name` is required: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/quality_control/models/quality_spreadsheet_template.py#L12 validation fails. **Solution** Provide a default value for the `name` field, using the same default as in `documents_document.py`: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/documents_spreadsheet/models/documents_document.py#L321 opw-5340710 Forward-Port-Of: odoo/enterprise#101671