Daily updates from Odoo
Wednesday, December 31, 2025
55 changes
12 changes
Resolved issues and error corrections
This update fixes an issue where multiple order lines were incorrectly refunded when a user initiated a refund. Now, only the selected line is refunded, and deleting a refund order correctly restores the ticket screen. This ensures accurate and reliable refund processing for our POS users.
Original PR description
Steps to reproduce: - In POS, select a paid order in the ticket screen with multiple lines. - Select the first line, choose a quantity to refund, and click Refund. - Return to the ticket screen, select the same paid order again. - Select another line and quantity, and click Refund. Issue: - In the second refund, all order lines were being refunded, even though only one line was selected. - After deleting a refund order, the ticket screen still showed messages like "Refunding x quantities in xyz order." Fix: - Only the selected lines are refunded. - Deleting a refund order restores the state of the linked order correctly. Task-5095578 Forward-Port-Of: odoo/odoo#241600 Forward-Port-Of: odoo/odoo#227937
This update resolves an issue that caused a technical error when users clicked on the 'Extra Hours' time off type in the dashboard. The problem stemmed from a missing piece of information in the system's data, which triggered an error. This fix ensures a smoother user experience when selecting this time off option.
Original PR description
Steps to reproduce: -------------------------- 1. Install hr_holidays_attendance. 2. Go to Time Off > Dashboard 3. Try to click on "Extra Hours" Issue: -------- A traceback occurs: ```python…
Steps to reproduce: -------------------------- 1. Install hr_holidays_attendance. 2. Go to Time Off > Dashboard 3. Try to click on "Extra Hours" Issue: -------- A traceback occurs: ```python InvalidDomainError: Invalid domain representation: holiday_status_id,=,5,company_id,=,,user_id,=,2 ``` Cause: --------- After 0aeaa2b (hr_holidays), clicking a time off type sends [employee_company](https://github.com/odoo/odoo/blob/84b137098ee46b1dab679fa8d99dbf368929413d/addons/hr_holidays/models/hr_leave_type.py#L539) in the domain. https://github.com/odoo/odoo/blob/84b137098ee46b1dab679fa8d99dbf368929413d/addons/hr_holidays/static/src/dashboard/time_off_card.js#L70-L74 However, the hour-based time off type created by `hr_holidays_attendance` does not define `employee_company`, so the domain contains **undefined,** triggering `InvalidDomainError.` Solution: ----------- Add the missing employee_company value in hr_holidays_attendance to resolve the issue. opw-5358682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239185
This update resolves an issue where adding lot-tracked products to Point of Sale orders would sometimes trigger an error if the picking type wasn't correctly configured. This fix ensures a smoother ordering process for products tracked by lot, improving reliability and preventing order disruptions. It addresses a technical bug related to inventory management.
Original PR description
When adding a lot-tracked product to an orderline, if the picking type does not set to create lots or use existing ones, an error was raised when adding the lot-tracked product twice. opw-5385476 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240548
This update streamlines how product images are loaded within the Point of Sale (POS) system. Previously, images were unnecessarily loaded and then converted to booleans, slowing down performance. Now, images are only loaded when needed, resulting in faster loading times and a smoother user experience.
Original PR description
Before this commit, when loading products in POS, images were loaded and then changed to boolean values. This was causing unnecessary data to be loaded from the database, impacting performance. This commit modifies the product loading methods to avoid loading images initially. Instead, by setting the 'bin_size' context key to True when loading products, images are not fetched from the database, and the size of binary fields is returned instead. opw-5392423 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241239 Forward-Port-Of: odoo/odoo#240420
This update reverses a recent change that restricted access to cash in/out functionality within Point of Sale. Previously, users needing to manage cash transactions required invoicing permissions. This reversion ensures that users with invoicing rights can also handle cash in/out operations, aligning with standard business processes.
Original PR description
This commit reverts the changes made in https://github.com/odoo/odoo/pull/190342/commits/d47b256a10713618a853d9eeacb2c1665330ed4f as they are not wanted. The user that wants to have access to cash in/out should have the invoicing rights at least. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228595 Forward-Port-Of: odoo/odoo#212994
This update resolves an issue where receipt attachments sent via email were broken, preventing users from receiving and viewing the correct receipts. The fix ensures receipt images are properly returned, allowing for accurate attachments in both email and the order log.
Original PR description
Steps to reproduce ------------ - Open register and create an order. - Send the receipt by email. - Check the backend order log - Receipt attachment is broken. Issue ------------- Sending a receipt created a broken attachment because the generated ticket image was not correctly returned. Fix --------- Return receipt image properly so the email and backend order show a correct attachment. -------- Task-5269024
This update ensures that Brazilian Point of Sale (POS) orders are correctly named according to the NFC-e sequence defined in the POS configuration. Previously, order names were not reflecting the correct sequence number, leading to potential issues with reporting and tracking. This fix aligns the order naming with Brazilian regulations.
Original PR description
Brazilian order shoud follow the NFC-e sequence defined in the POS config. Steps to reproduce: ------------------- * Setup a POS in Brazil with NFC-e sequence (set the sequence to 1234) * Create a new order in the POS * Validate the order * Check the order name in backend > Observation: The order name is like: POS-00001 instead of POS-1234 Why the fix: ------------ We adapt the method _compute_order_name to get the correct sequence number if the country is Brazil. opw-5243454 Forward-Port-Of: odoo/odoo#240273
This update ensures that Brazilian Point of Sale (POS) orders are named correctly, reflecting the required NFC-e sequence defined in the POS configuration. Previously, order names were incorrectly generated. This fix ensures compliance with Brazilian regulations and accurate order tracking.
Original PR description
Brazilian order shoud follow the NFC-e sequence defined in the POS config. Steps to reproduce: ------------------- * Setup a POS in Brazil with NFC-e sequence (set the sequence to 1234) * Create a new order in the POS * Validate the order * Check the order name in backend > Observation: The order name is like: POS-00001 instead of POS-1234 Why the fix: ------------ We adapt the method _compute_order_name to get the correct sequence number if the country is Brazil. opw-5243454 Forward-Port-Of: odoo/enterprise#102275
This update fixes an issue where image columns in the website editor appeared too small, particularly on mobile devices. The fix ensures that background images are correctly considered when calculating grid item sizes, resulting in a more consistent and visually appealing layout. This improves the overall user experience for website design.
Original PR description
Steps to reproduce: =================== - In website edit mode, drop the "Split Intro" snippet. - Toggle it to grid mode. => the image column is smaller than expected. - Switch to mobile view => the image column is really small. Cause & solution: ================= When toggling a snippet to grid mode, when computing the size of the grid items, the padding of a column is taken into account only if it has a background color (`o_cc` class), in order to look as close as possible as before. The background images are therefore not considered, so the size is computed without the padding, resulting in a grid-area smaller than expected, and the default grid item padding (which is why it is that small in mobile view). This commit fixes that by including the background image class (`oe_img_bg`) in the check used to consider the padding. opw-5374492 Forward-Port-Of: odoo/odoo#241474 Forward-Port-Of: odoo/odoo#240573
This update resolves an issue where videos displayed on the website were appearing smaller than intended. The team adjusted the layout to ensure videos fill the available space, providing a better visual experience for users. This change improves the presentation of video content.
Original PR description
Steps to reproduce: - Drop "s_picture" snippet. - Replace the image with a video. - Video is clearly small than the original image. This commit fixes the issue by adding a "w-100" class to the figure element wrapping the image. task-5136212 Forward-Port-Of: odoo/odoo#240588
This update resolves a random error that prevented the 'Tip After Payment' tour from running correctly in the Point of Sale module. The fix ensures the system waits for the feedback screen to appear after tip validation, improving the user experience and preventing tour failures.
Original PR description
The PosTipAfterPaymentTour tour would fail randomly because it was not waiting for the feedback screen to be shown after validating the tip screen. runbot-234734
This update corrects a restriction imposed by Mexican tax authorities (SAT) on the format of the CuentaPredial field in our Odoo Enterprise software. The change ensures compliance with the latest SAT regulations, preventing potential errors and ensuring accurate tax reporting for Mexican businesses using this module. This fix maintains the integrity of financial data and avoids potential penalties.
Original PR description
SAT has declared the restriction [0-9a-zA-Z]{1,150} for CuentaPredial node
Specification: https://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd
Forward-Port-Of: odoo/enterprise#1029818 changes
Resolved issues and error corrections
This update resolves an issue that caused a technical error when users clicked on the 'Extra Hours' time off type in the dashboard. The problem stemmed from a missing piece of information in the system's data, which triggered an error. This fix ensures a smoother experience for users accessing time off requests.
Original PR description
Steps to reproduce: -------------------------- 1. Install hr_holidays_attendance. 2. Go to Time Off > Dashboard 3. Try to click on "Extra Hours" Issue: -------- A traceback occurs: ```python…
Steps to reproduce: -------------------------- 1. Install hr_holidays_attendance. 2. Go to Time Off > Dashboard 3. Try to click on "Extra Hours" Issue: -------- A traceback occurs: ```python InvalidDomainError: Invalid domain representation: holiday_status_id,=,5,company_id,=,,user_id,=,2 ``` Cause: --------- After 0aeaa2b (hr_holidays), clicking a time off type sends [employee_company](https://github.com/odoo/odoo/blob/84b137098ee46b1dab679fa8d99dbf368929413d/addons/hr_holidays/models/hr_leave_type.py#L539) in the domain. https://github.com/odoo/odoo/blob/84b137098ee46b1dab679fa8d99dbf368929413d/addons/hr_holidays/static/src/dashboard/time_off_card.js#L70-L74 However, the hour-based time off type created by `hr_holidays_attendance` does not define `employee_company`, so the domain contains **undefined,** triggering `InvalidDomainError.` Solution: ----------- Add the missing employee_company value in hr_holidays_attendance to resolve the issue. opw-5358682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239185
This update resolves an issue where Employee Officers were experiencing access errors when editing employee records. By restricting access to salary offer information to HR Managers, the system now functions smoothly for all roles, ensuring data integrity and preventing unauthorized access.
Original PR description
Before: - Editing an employee form as an Employee Officer triggered an AccessError due to mail tracking attempting to read salary_offer_ids on hr.version. After: - salary_offer_ids is now restricted to HR Managers, preventing unauthorized reads during tracking when saving the employee form. Impact: - Employee Officers can edit employee records without encountering access errors. - Access to salary offers remains limited to appropriate managerial roles. Task: 5404676
This update resolves an issue where copying and pasting content from the Knowledge editor resulted in a loss of plain text formatting. The fix restores the ability to correctly paste text into other applications, ensuring users can accurately copy and paste content from the editor. This improves the usability of the Knowledge feature.
Original PR description
Since [1] when `vnd.odoo.odoo-editor` was added to the `HtmlViewer` clipboard, the `text/plain` mimetype was lost. This commit restores the plain text version of the clipboard. Steps to reproduce: - In knowledge, lock a page - Select some content - Copy - Paste into a plain text editor => No content was pasted [1]: https://github.com/odoo/odoo/commit/62a7c50b434e3f47ad58e20e96970cbd90b979b6 task-5449435 Forward-Port-Of: odoo/odoo#241642
This update automatically marks UrbanPiper orders as paid in Odoo when they are marked as 'dispatched'. This prevents order cancellations due to cashier oversight and ensures accurate order status tracking, improving the POS process.
Original PR description
*= urban_piper, black_box_be In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. - Also, we are adding this urban piper order to the blackbox, if it was not recorded in it. Task: 5261892 X-original-commit: 808cf7b3f8c185053dac5cbf75307efa67fd6e90 Forward-Port Of:odoo/enterprise#99513
This update fixes an issue where users could inadvertently change product taxes while items were already in their shopping cart. Now, users can still modify product details but tax updates are restricted when a product is in the cart, ensuring order accuracy and consistency.
Original PR description
- When a product is already in the cart, prevent updating its taxes from the frontend product edit popup. This avoids inconsistencies between the product taxes and the taxes applied to the order line. - Now we can still edit other fields of the product. task-id: 4943650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures invoices exported with distance selling correctly use the foreign VAT number defined for the customer's fiscal position. Previously, the company's VAT was incorrectly used, leading to inaccurate VAT reporting. This fix improves invoice accuracy and compliance with EU regulations.
Original PR description
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1.…
When exporting invoices, the VAT number of the company could be wrong if the fiscal position of the invoice defines a foreign VAT number. In that case we need to use it. Steps to reproduce: 1. Install a European localization (ex: l10n_at) 2. Enable EU Intra-community Distance Selling. You should now have new OSS fiscal positions. Update the one you want to use with a foreign VAT. 3. Create a valid foreign customer. (within the EU) 4. Create and send an invoice for this customer. 5. In the PDF, there is an embedded factur-x file. Notice how the VAT number under the SellerTradeParty corresponds to the company's VAT, not the foreign VAT number defined on the fiscal position. This is more apparent because we use the correct VAT number in the PDF file but not in the corresponding XML. This commit fixes this issue by first checking if we have a foreign VAT number defined on the fiscal position of the invoice. If so, we use it. opw-5182837 Forward-Port-Of: odoo/odoo#237666 Forward-Port-Of: odoo/odoo#236692
This update resolves a technical issue related to the Mexican tax reporting system (l10n_mx_edi) to comply with a recent regulation from the SAT (Mexican tax authority). The previous regex for 'CuentaPredial' accounts was too restrictive, and this change ensures accurate data input according to the latest SAT specifications. This ensures proper tax reporting compliance.
Original PR description
SAT has declared the restriction [0-9a-zA-Z]{1,150} for CuentaPredial node
Specification: https://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd
Forward-Port-Of: odoo/enterprise#102981This update resolves an issue where Odoo invoices with discounts generated for Nemhandel failed validation. The fix ensures that discounts are correctly accounted for in the invoice data, allowing these invoices to be successfully transmitted to customers. This improves the reliability of our Nemhandel integration.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241614
9 changes
Resolved issues and error corrections
This update ensures that product descriptions are correctly updated in UrbanPiper whenever the menu is synchronized. Previously, changes to product descriptions weren't reflected in UrbanPiper, leading to outdated information. This fix resolves that issue, maintaining accurate product details for our UrbanPiper integration.
Original PR description
Before this commit: --- When we sync the menu with the product description and later update the product description, re-syncing the menu does not update the product description in UrbanPiper. After this commit: --- This fix ensures that any change in the product description is properly sent to UrbanPiper during menu synchronization. task-5439271 Forward-Port-Of: odoo/enterprise#102846
This update resolves an installation problem that prevented users from correctly setting up the Mauritius localization within Odoo. The issue stemmed from a missing configuration setting, which has now been added to the module manifest to ensure proper installation and functionality. This ensures smooth setup for users utilizing the Mauritius fiscal localization.
Original PR description
Steps to reproduce: 1. Install 'accountant' 2. Create a new company without a country and switch to that company 3. Accounting > Configuration > Fiscal Localization 4. Select Mauritius and save Issue: It gives a traceback: KeyError: 'mu' Cause: 'auto_install' is not present in the manifest file. Solution: Add 'auto_install': ['account'] in the manifest as it is done in other localization modules. opw-5231064 Forward-Port-Of: odoo/odoo#239881 Forward-Port-Of: odoo/odoo#236207
This update resolves an issue that caused a technical error when users clicked on the 'Extra Hours' time off type in the dashboard. The problem stemmed from a missing piece of information in the system's data, which triggered an error. This fix ensures a smoother user experience when selecting this time off option.
Original PR description
Steps to reproduce: -------------------------- 1. Install hr_holidays_attendance. 2. Go to Time Off > Dashboard 3. Try to click on "Extra Hours" Issue: -------- A traceback occurs: ```python…
Steps to reproduce: -------------------------- 1. Install hr_holidays_attendance. 2. Go to Time Off > Dashboard 3. Try to click on "Extra Hours" Issue: -------- A traceback occurs: ```python InvalidDomainError: Invalid domain representation: holiday_status_id,=,5,company_id,=,,user_id,=,2 ``` Cause: --------- After 0aeaa2b (hr_holidays), clicking a time off type sends [employee_company](https://github.com/odoo/odoo/blob/84b137098ee46b1dab679fa8d99dbf368929413d/addons/hr_holidays/models/hr_leave_type.py#L539) in the domain. https://github.com/odoo/odoo/blob/84b137098ee46b1dab679fa8d99dbf368929413d/addons/hr_holidays/static/src/dashboard/time_off_card.js#L70-L74 However, the hour-based time off type created by `hr_holidays_attendance` does not define `employee_company`, so the domain contains **undefined,** triggering `InvalidDomainError.` Solution: ----------- Add the missing employee_company value in hr_holidays_attendance to resolve the issue. opw-5358682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239185
This update fixes an issue where combo line prices were incorrectly set to 'automatic' after order creation. The change ensures combo line price types remain as originally intended, preventing conflicts with price updates and maintaining accurate pricing for combo sales. This improves the reliability of point-of-sale transactions.
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#239748 Forward-Port-Of: odoo/odoo#234575
This update resolves an issue where Odoo invoices with discounts generated through Nemhandel would fail validation. The change ensures that discounts are correctly accounted for in invoice calculations, allowing invoices with discounts to be successfully sent to customers via Nemhandel. This improves the functionality of the Nemhandel integration.
Original PR description
Before this fix, all the OIOUBL invoices with a discount generated by Odoo would fail the schematron validation, meaning they can't be sent to the customer through Nemhandel. The schematron enforces that the discount is taken into account at the PriceAmount, to keep the rules on lineExtensionAmount working. Also changes the import to understand that it's a discount. opw-5379474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241614
This update resolves an issue where large .docx files weren't being correctly identified with their proper file type (like .docx) when using the `python-magic` library. Previously, the system incorrectly guessed 'application/zip' for these files. This change increases the data sent to the file type guesser, ensuring accurate identification and proper handling of large documents.
Original PR description
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open…
### Description of the issue/feature this PR addresses: The current number of bytes (1024) sent to the mimetype guesser function is not enough for a correct guess on big .docx files (maybe other open office files too) whenever `python-magic` is installed. If `python-magic` is not installed, it falls back to a [simpler implementation (by odoo)](https://github.com/odoo/odoo/pull/233266/files#diff-706296f6593337a9ff88c0e33e0e090eec75f63a22f9825dd31833ba17922840R145) that actually works correctly. But in odoo.SH it seems that `python-magic` is always installed and in that case, it returns the mimetype "application/zip" for big .docx files. The issue is not reproducible in runbot, so I'm assuming `python-magic` is not present in that environment. I've tested it with double the amount of bytes and it seems to work correctly. Please check the [following ticket](https://www.odoo.com/odoo/project.task/5125592) for more details. ### Current behavior before PR: <img width="1141" height="674" alt="image" src="https://github.com/user-attachments/assets/a3d28757-c55a-4b0f-9ee5-042777943635" /> ### Desired behavior after PR is merged: The uploaded file's mimetype is correctly identified for big (>40mb) open office files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239045 Forward-Port-Of: odoo/odoo#233266
This update corrects a restriction imposed by Mexican tax authorities (SAT) on the ‘CuentaPredial’ field in our software. The change ensures Odoo correctly handles the required format for this field, aligning with current SAT regulations. This is necessary for accurate tax reporting and compliance in Mexico.
Original PR description
SAT has declared the restriction [0-9a-zA-Z]{1,150} for CuentaPredial node
Specification: https://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd
Forward-Port-Of: odoo/enterprise#102981This update resolves an issue where users couldn't answer incoming calls when opening modals like 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 by allowing 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)
This update resolves an issue where delivery validation would fail after splitting a stock move line within a delivery order. Now, the system correctly recognizes that the new move line is associated with the original picked move, allowing validation to proceed smoothly. This ensures accurate order processing and prevents unnecessary backorder warnings.
Original PR description
Scenario: * create a delivery with quantity 3 and mark as TODO * mark the stock move as picked * open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new…
Scenario: * create a delivery with quantity 3 and mark as TODO * mark the stock move as picked * open the "Details" popup and split the stock move line into quantities 1 and 2, e.g. by adding a new package or a new lot * exit the popup and try to validate the delivery Behavior before this commit: * the stock move in the delivery form remains picked * validation shows a backorder popup, warning of missing quantity Reason: the newly created stock move line is not picked, but this information is not displayed anywhere, so users are not aware of the cause of this issue After this commit: * the stock move is no longer picked after a new move line is added * users can click the "Picked" checkbox in the delivery form manually, which marks all stock move lines as picked as well * after this action, delivery validation proceeds without backorders opw-5345579 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#239089
3 changes
Resolved issues and error corrections
This update corrects a typo in the l10n_ec_edi_pos module, ensuring that the correct partner (Deco Addict) is selected when processing refunds in the Point of Sale system. The previous error caused the system to default to a generic 'Consumidor Final' option, leading to incorrect reporting. This fix ensures accurate financial transactions.
Original PR description
Step to reproduce: - install l10n_ec_edi_pos - start pos and settle order with specific partner(ex. Deco Addict) - process the refund for this order Observation: - on product screen, "Consumidor Final" is selected instead of Deco addict. Cause and Fix: - Fixed a typo: it used `final_consumer_id` instead of `_final_consumer_id` opw-5412346 Forward-Port-Of: odoo/enterprise#102202
This update resolves an issue that prevented users from creating payslips for contracts without a defined work schedule in the Belgian payroll module. The fix ensures that the system defaults to the company's standard calendar when a contract lacks a specific schedule, preventing a technical error and allowing payslips to be generated correctly.
Original PR description
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll…
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 2) Create an employee with no working hours. 3) Create a contract for that employee with: - Work entry source as Attendance - No Working Schedule - State should be open/running 4) Click the Payslip smart button to create a new payslip for that contract. 5) A traceback occurs **Error:** ``` ValueError: Expected singleton: resource.calendar() ``` **Cause:** When creating a payslip for a contract with no resource_calendar_id, the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` through self.resource_calendar_id. Since the contract's calendar lacks a resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472 **Solution:** If the contract or employee does not have a resource_calendar_id, use the default resource_calendar_id from the company instead. opw-5237559 Forward-Port-Of: odoo/enterprise#99217
This update resolves a restriction imposed by Mexican tax authorities (SAT) regarding the format of CuentaPredial numbers. The previous regex was no longer compliant, and this change ensures Odoo correctly processes these numbers according to current SAT regulations. This update maintains compliance and avoids potential issues with tax reporting.
Original PR description
SAT has declared the restriction [0-9a-zA-Z]{1,150} for CuentaPredial node
Specification: https://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd
Forward-Port-Of: odoo/enterprise#1029817 changes
Resolved issues and error corrections
This update fixes an issue where payslips were not displaying currency symbols correctly. A small, hidden field was added to the payslip form to ensure accurate monetary formatting and display of currency information. This ensures all payroll data is presented accurately for reporting and financial analysis.
Original PR description
The properties widget relies on the presence of the currency field in the view. Add an invisible currency_id field to the payslip form to properly display monetary symbols. task-5357836 Forward-Port-Of: odoo/enterprise#102896
This update removes a specific test patch related to the `l10n_eg` driver. As the driver has been moved to a central location within Odoo, this patch is no longer required. This change improves test stability and reduces complexity.
Original PR description
As we move `l10n_eg` driver to a controller in `odoo.iot_drivers`, we no longer need to patch it. see odoo/odoo#240043
This update fixes a visual issue where warning tooltips were incorrectly displayed across the entire payrun status. Now, tooltips only appear on the specific stage where a warning exists, leading to a clearer and more accurate representation of payrun status for users. This enhances usability and reduces potential confusion.
Original PR description
Issue: The warning tooltip appeared on all stages of the payrun, even when the warning existed only in the current stage. Fix: Show the warning tooltip only on the active stage where the warning or error bubble actually exists. Impact: Makes the payrun status bubbles clearer and prevents users from misunderstanding where warnings actually are. task-5406861 Forward-Port-Of: odoo/enterprise#101812
This update ensures that a permanent link to newly created support tickets is displayed within the live chat window after a ticket is generated. Previously, this information was only visible temporarily. This change enhances the user experience by making it easier for customers to access and manage their support requests directly from the chat.
Original PR description
**purpose of this PR:** when a ticket is created from a livechat, post a message in the chat with a link for permanently. before this msg was sent as a transient bus notification, so it was not visible after chat refresh. Additionally, the message type has been changed from **comment** to **notification**. task - [5117552](https://www.odoo.com/odoo/project/1519/tasks/5117552) task - [4241782](https://www.odoo.com/odoo/project/1519/tasks/4241782)
This update enhances the clarity of duplicate records within the POS Enterprise module. A '(copy)' tag has been added to the names of duplicated records, making it easier for users to differentiate between them when using the POS prep display feature. This improves organization and reduces potential confusion.
Original PR description
In this commit: ------------------ - We have appended `(copy)` to the record name when duplicating a record, making it easier to distinguish duplicate entries in `pos_prep_display` model. Related PR: https://github.com/odoo/odoo/pull/238615 task: 5380927
This update ensures that Brazilian Point of Sale (POS) orders are named correctly, reflecting the required NFC-e sequence defined in the POS configuration. Previously, order names were not matching the sequence number, leading to potential reporting issues. The fix updates a key method to accurately generate the order name based on the country setting.
Original PR description
Brazilian order shoud follow the NFC-e sequence defined in the POS config. Steps to reproduce: ------------------- * Setup a POS in Brazil with NFC-e sequence (set the sequence to 1234) * Create a new order in the POS * Validate the order * Check the order name in backend > Observation: The order name is like: POS-00001 instead of POS-1234 Why the fix: ------------ We adapt the method _compute_order_name to get the correct sequence number if the country is Brazil. opw-5243454 Forward-Port-Of: odoo/enterprise#102275
This update corrects a restriction imposed by Mexican tax authorities (SAT) on the format of CuentaPredial numbers. The change ensures Odoo Enterprise complies with current SAT regulations, preventing potential issues with tax reporting. This update impacts the l10n_mx_edi module.
Original PR description
SAT has declared the restriction [0-9a-zA-Z]{1,150} for CuentaPredial node
Specification: https://www.sat.gob.mx/sitio_internet/cfd/4/cfdv40.xsd
Forward-Port-Of: odoo/enterprise#1029813 changes
Resolved issues and error corrections
This update enhances the preparation display filters in the Point of Sale module, offering more flexible options for managing order preparation. Specifically, it adds multi-select time and preset filters, and ensures the category filter is always visible, streamlining the process for staff.
Original PR description
- Time filter: * Remove "All" option (now default) * Add "Now" option for unscheduled and next-slot orders * Allow multi-selection - Preset filter: * Add multi-select preset filter * Only shown if related POS configs use presets - Category/Product filter: * Always show pos.category filter (even if no preparation card contains this category) * Move category/product filters below Time and Preset filters task: https://www.odoo.com/odoo/project/1737/tasks/5060221 community PR: https://github.com/odoo/odoo/pull/233920 Forward-Port-Of: odoo/enterprise#95136
This update fixes an issue where certain POS presets weren't correctly displayed in self-service ordering modes (kiosk and mobile). Now, presets are only shown if they're available in self-service and, in specific cases, require a slight configuration change to ensure they appear correctly.
Original PR description
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset…
*: pos_self_order, pos_online_payment_self_order Two things will change with this PR. First, before this commit, when a pos config had only one available preset (and set as default) and this preset was not available in self, this preset was used as the default one. But now, it's not the case anymore. We only use it if, and only if, it is available in self. The second thing was to fix the "Dine In" preset availability in the eating location choices. A dine-in preset is a preset which have service_at == table as attribute. If this preset (is `available_in_self`) and has `service_at === table`, we only show it when there is a table_identifier in the URL or when we are in the kiosk. In all other cases, it'll never be shown. If user wants to see this preset in the kiosk or in the mobile menu without table_identifier, user needs to change the `service_at` field at `counter` (or `delivery`) and put the product as `available in self` as well. task-id: 5190541 community pr:https://github.com/odoo/odoo/pull/234522
This update corrects a technical problem that could occur when duplicating Odoo databases. The fix ensures that a calculation within the HR Job Post module handles recordsets of multiple records correctly, preventing an error that would have disrupted database operations. This improves database stability and reliability.
Original PR description
These two computes assume a recordset of size 1. When duplicating databases, the recordset for this method might be more than 1, causing a "Expected singleton" traceback. See opw-5226545 (and linked TOTD thread) Forward-Port-Of: odoo/enterprise#99424
8 changes
Resolved issues and error corrections
A bug in the TPAR report test was resolved by updating the test to use dynamic dates based on the current user's date. This prevents failures caused by hardcoded dates, ensuring the test runs correctly regardless of the current year and future deployments. This improves test reliability.
Original PR description
Behavior before:
The TPAR report test used hardcoded dates ('2025-01-01' to '2025-12-31'). When running tests with Faketime or on future deployments, this caused failures because the test did not adapt to the current date.
Behavior after:
The test now uses dynamic dates based on `fields.Date.context_today(self.env.user)`. This ensures the test runs correctly regardless of the current year and avoids issues with hardcoded dates.
Root Cause:
Hardcoded dates in the test conflicted with Faketime, causing the test environment to simulate a future year and fail.
Runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/237547
Forward-Port-Of: odoo/enterprise#102960This update resolves an issue where images in image galleries with links were left-aligned instead of centered. The fix ensures images remain correctly centered within gallery links, particularly with smaller images. A CSS adjustment was implemented to address this alignment problem, providing a reliable solution.
Original PR description
Problem: When adding a link to an image in an image gallery, the image becomes left-aligned instead of centered. This issue is most noticeable with images that have a small width. Cause: The image is…
Problem: When adding a link to an image in an image gallery, the image becomes left-aligned instead of centered. This issue is most noticeable with images that have a small width. Cause: The image is centered using the `mx-auto` class. However, when the image is wrapped in an anchor (`<a>`), the anchor does not take up the full width of the container. As a result, the image is no longer centered and shifts to the left. Before: <img width="836" height="586" alt="image" src="https://github.com/user-attachments/assets/f51fed85-727d-4391-a186-8a966f71657a" /> After: <img width="747" height="583" alt="image" src="https://github.com/user-attachments/assets/6a3bd724-5b9c-4160-b0a4-73e8d7fdd1ec" /> Steps to reproduce: - Add an image gallery block. - Replace an image with one that has a small width. - Add a link to the image. - The image is no longer centered and aligns to the left. The issue occurs because the direct parent of the link-image uses `display: flex`. In this commit, a CSS rule was added so that links wrapping an image with Bootstrap margin classes (`mx-auto`, etc.) applied by the image alignment option also get the same margins. This is only done when the direct parent of the link uses `display: flex` which is the case for elements like `carousel-item`. We also targeted parents with the `d-flex` class to fix a similar issue in the `Blockquote` snippet, where the "avatar" image has a `d-flex` parent and becomes misaligned when wrapped in a link. A JavaScript fix was initially considered, by detecting in the image alignment or link application options whether the link’s parent used `display: flex`. That approach would have been more precise to detect a `display: flex` parent, but it wouldn’t cover manually added/moved images. The CSS solution covers all known cases, can still be improved, and has the advantage of working reliably in all situations. opw-4985504 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where refund alerts were triggered incorrectly due to rounding differences between order totals and line item sums. The change ensures accurate comparisons, preventing false alerts and improving the reliability of the Point of Sale (POS) system. This update focuses on a technical fix related to financial reporting accuracy.
Original PR description
Before this commit, if the total amount of the order had rounding differences compared to the sum of its lines, the system could incorrectly trigger an alert stating that the refund amount exceeds the original order amount. This was due to a direct comparison between the two amounts without considering potential rounding issues. opw-5402240
This update prevents a payment error that occurred when invoices with missing due dates were processed. The fix ensures correct invoice calculations and payment processing by prioritizing invoice lines with due dates, resolving a potential disruption to financial operations.
Original PR description
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting`…
Currently, an error occurs when a user attempts to pay an invoice. **Steps to Reproduce ([Video](https://drive.google.com/file/d/1onmo1mxeZgH6fkQOoueGCgC67HPjYHX6/view)):** - Install the `Accounting` module. - Go to `Payment Terms` and create `a new Payment Term` with at `least two Due Term lines`. - Go to `Invoices` and `create a new Invoice`. - Add one invoice line and set the `Payment Term` to the `newly created payment term`. - In the `Journal Items` tab > `Enable the Due Date` column (optional hidden). - From the two `Receivable journal items`, remove the `Due Date` from one of the `receivable lines`. - Now `Confirm the invoice` and `Click on Pay`. **Error:** `TypeError: '<' not supported between instances of 'datetime.date' and 'bool'` **Cause:** This error occurs when the user clicks Pay, than it going to calculate the total amount to pay from here [1]. If the payment term has more than one term line, it creates more than one receivable invoice line, and the receivable invoice lines are sorted from here [2]. When two or more invoice lines have the same move_id, they are sorted based on the due date. However, if one of the receivable lines does not have a due date, the error is raised. Similarly, as shown in [3], when the system retrieves the installment data, it sorts the lines based on the due date and raises the same error. **Fix:** This commit ensures that when there is no due date on any receivable invoice line and two lines belong to the same invoice, the comparison uses the maximum date as like here [4] and places that line at the end for that invoice, thereby maintaining the correct flow. The same fix is applied while retrieving the installment data, as described above. [1]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L703 [2]- https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/wizard/account_payment_register.py#L635 [3]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L3305 [4]: https://github.com/odoo/odoo/blob/92a9f6b19670685dfe9fb1714bf01449768e5f62/addons/account/models/account_move_line.py#L522 sentry-713241246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update optimizes how Odoo handles web socket connections, particularly under heavy load. By delaying cursor acquisition attempts, the system reduces connection failures and improves overall responsiveness, especially when dealing with a large number of simultaneous users.
Original PR description
Benchmarking with 4k connected clients, 1 message per second. | | Message dispatching | Cursor analysis | |-- |-- | -- | | Before|<img width="600" alt="image" src="https://github.com/user-attachments/assets/f02e7efc-4611-4356-8bef-386ff2b0a7da" />|<img width="600" alt="2_current_implementation__cursor_analysis" src="https://github.com/user-attachments/assets/04dce96e-74a6-4f1b-9918-a6c61913e7c4" />| |After|<img width="600" alt="image" src="https://github.com/user-attachments/assets/a9463484-7f69-4fcb-a248-5692893a8893" />|<img width="600" height="997" alt="8_tweak_delay_both_sleep__cursor_analysis" src="https://github.com/user-attachments/assets/34a2c233-5c36-4597-a55b-cfb89a41efcf" />| Forward-Port-Of: odoo/odoo#241330
This update optimizes how product category information is loaded in the product screen, resolving a performance bottleneck. Previously, the loading process was slow and inefficient, particularly when dealing with many product categories. This change significantly improves the speed and responsiveness of the product screen, enhancing the user experience.
Original PR description
Before this commit, the product category info loading was done in O(n^2) time complexity due to nested loops. It caused performance issues when loading a large number of product categories. opw-5442894 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where warnings from the IoT were incorrectly treated as errors. Now, warnings are displayed as notifications, providing clearer feedback to users about the status of transactions. This improves the user experience and ensures accurate reporting.
Original PR description
Before this commit, all errors returned by the iot after a call to the blackbox were considered as errors. Actually, the errors are only the ones that do not start with 0 (no error) or 1 (warning). This commit changes the behaviour when handling warning. We now show a notification. task-id: 5062178 Forward-Port-Of: odoo/enterprise#93896
This update resolves an error that prevented users from opening the employee form within the Point of Sale (POS) frontend. The fix disables the employee selection field on the frontend only, allowing the form to function correctly in the backend where all necessary data is available. This ensures a smoother user experience for POS operations.
Original PR description
Opening employee form in the frontend was throwing an error, since not all thre required assets were available on the PoS frontend. So in this commit 57aba149b6e6927f9055124e58bed03f842329d5, we disabled openening the employee form by making the employee_id field unclikcable, both in forntend and backend!! It was enough however to only macking it unclikcable on the frontend, since it was working fine on the backend where all the required assets were loaded anyway. This commit restores the functionality on the backend, but overriding the `Many2OneField` used by the `employee_id`, and making it unclickable only on the frontned. opw-5252486
5 changes
Resolved issues and error corrections
This update resolves a bug where website options (like showing/hiding text elements) didn't correctly reset to the original template after being toggled on. The fix ensures that changes made through the website editor are properly restored, preventing unexpected content display. This improves the user experience and data consistency.
Original PR description
Fix an issue where toggling a website option that controls a view with reset enabled (e.g., "Show/hide text element" in Header) fails to restore the original template on the first toggle cycle. Steps…
Fix an issue where toggling a website option that controls a view with
reset enabled (e.g., "Show/hide text element" in Header) fails to
restore the original template on the first toggle cycle.
Steps to reproduce:
1. Edit the phonr number element in the Header.
2. Toggle OFF the "Show/hide text element" option.
3. Toggle ON the option.
Current Behavior: The text does not reset; the edited version reappears.
4. Toggle OFF and ON again.
Current Behavior: Only now does the text reset to the original version.
Reason:
When disabling an option, the backend resets the view as expected.
However, the frontend editor triggers an auto-save of the user's changes
shortly after. This save operation overwrites the recently reset view
with the old "dirty" content, leaving the view inactive but modified.
Consequently, re-enabling the option simply activates this modified
version instead of the clean template.
Fix:
Explicitly force a hard reset of the view architecture during the
'enable' phase if `reset_view_arch` is requested. This ensures the
content is always restored to its original state when the view becomes
visible, preventing any stale edited content from persisting.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update removes a redundant design option from the planning module. Previously, a specific layout choice was required for a field, but this has been updated to a simpler selection method. This change improves the overall efficiency and clarity of the planning interface.
Original PR description
Previously, the template_id field was using the radio widget, which required the horizontal option. In a below commit, the radio widget was replaced with selection_badge, making the horizontal option unused. Commit-https://github.com/odoo/enterprise/pull/7970/commits/2b587a0f8951df5dc40d7536a79def926717f2ff
This update addresses a technical issue that could occasionally cause notifications to fail to send. The fix ensures that WebSocket connections are properly closed, preventing a race condition that led to operating system errors. This improves the reliability of notification delivery within Odoo.
Original PR description
Since [1], sockets used to wake up the websocket coroutines are properly closed upon termination. However, there can be a race where the dispatcher coroutine tries to write on the notif socket, leading to OS error. This commit fixes this error. [1]: https://github.com/odoo/odoo/pull/241330 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a crash that occurred when users switched tabs while a receipt was being generated in Point of Sale. The fix ensures the receipt component is reliably loaded and accessible, preventing the printing process from failing. This improves the overall reliability of the PoS system.
Original PR description
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay…
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay button. 3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed). 4. Come back to the initial page, a traceback will appear and the ticket is not printed. Why it happens: --------------- The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`! The fix ------- Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`. opw-5124585
This update fixes an issue where searching for serial numbers in the stock barcode view could return incorrect results. By adding a context, the system now correctly handles searches from the list view, ensuring more accurate and reliable stock tracking. This improves data integrity and user confidence.
Original PR description
Issue --> On the Lots/Serial Numbers view, with GS1 enabled, searching by a serial number can cause search arguments to get warped, unbeknownst to the end user. This can return unexpected results in the list view. Solution --> Add a context that skips the _preprocess_gs1_search_args method if the search is done from the list/graph view. This solution retains usage for any other purposes of the method. Community PR --> https://github.com/odoo/enterprise/pull/82989 opw-4574666