Tuesday, December 23, 2025
20 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where manually adjusted prices on customer invoices were being reset when the invoice's fiscal position was changed. The fix ensures that prices remain as the user intended, mirroring the behavior of Sale Orders. This improves accuracy and reduces manual intervention for users.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Create a customer invoice with at least one product line. * Manually adjust the **price_unit** on the invoice line. * Change the fiscal position on the invoice. * Click the **Update Taxes and Accounts** button. **Observed behavior:** * The manually adjusted price is reset to the product’s default sales price (e.g., 1000). * This occurs even though neither the product nor the UoM changed. * In contrast, **Sale Orders correctly preserve** manually edited prices in the same situation. **Cause:** * `action_update_fpos_values` method call the recomputation of unit price each time when we click update taxes and accounts button on invoice. **Fix:** * Add a condition to **skip price recomputation** when fiscal position changes. * This preserves manual prices when only the fiscal position changes. opw-5252832 Forward-Port-Of: odoo/odoo#240813 Forward-Port-Of: odoo/odoo#237914
This update resolves a visual issue where the Sales 3 menu on the website would overflow when certain menu items were added. The fix prevents the parent element from overflowing, ensuring the menu displays correctly regardless of the number of items. This improves the user experience for customers navigating the website.
Original PR description
Scenario: - edit the website navbar and set template "Sales - 3" (penultimate) - edit menu to add several menu items that will be larger than possible Result: the menu overflows Cause: a parent element of the menu doesn't overflow, so when computing autoHideMenu where we compute what overflow the list of menu, nothing overflows it since the overflow already happened in the limitless parent element. Fix: using CSS to prevent the parent from overflowing. opw-5178552 __pr note:__ this is happening in 17.0 but I'm targeting 18.0 since the ticket is in 18.0 and code is the same in 18.0 up to master. Forward-Port-Of: odoo/odoo#240433
This update allows businesses using the Mexican tax reporting (MX) module to define a custom sequence prefix for GI CFDI invoices issued on branch offices. Previously, the system always used the root company's sequence, which is now configurable to ensure accurate tax reporting for branch operations. This change improves compliance and reduces potential errors related to invoice numbering.
Original PR description
Add a way to set a custom prefix for GI sequences on the settings for MX. Get this sequence first on the branch before looking to the one on root company. opw-5096687 Forward-Port-Of: odoo/enterprise#100017
This update fixes an issue where product attributes weren't displayed on order lines. The change ensures that all product attribute names are now correctly shown, providing a more complete view of the order for users. This improvement was made by updating how product attribute strings are constructed.
Original PR description
Before this commit: --- - When an order was placed with product attributes, the attribute details were not shown on the order line. After this commit: --- - The product attribute names are now correctly displayed on the order line. Cause: --- - Until saas-18.2, the attribute string was built using the product’s display name and `attribute_line_ids`, which only included never type PTAV entries. - Starting from saas-18.2, the attribute string is constructed solely from `attribute_line_ids`, which now includes all PTAVs. task-5244869 Forward-Port-Of: odoo/enterprise#99007
This update fixes an issue where invoice due dates were incorrectly calculated when users had their timezones set to UTC. The change removes a timezone conversion step, ensuring due dates are accurately displayed based on the user's local time. This prevents discrepancies and ensures invoices are presented with the correct payment deadlines.
Original PR description
This commit fixes the incorrect due date calculation of invoices. If user timezone is set to any UTC-* timezone, then the due date is calculated as the previous day to the actual due date. This is because the function `deserializeDateTime` was used, which considers the input date as UTC timezone and converts it to system timezone. For example, if the due date is "2025-11-20 00:00:00" and the system timezone is UTC-3, then the calculated due date is "2025-11-19 21:00:00". So when getting the difference from today's date (assuming today is "2025-11-20"), the difference is 1 day (which is not the expected value). This commit replaces the call of `deserializeDateTime` with `deserializeDate`, which removes the system timezone conversion. opw-5160764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240785 Forward-Port-Of: odoo/odoo#236769
This update fixes an issue where mobile users were seeing both purchase and sales tax options when creating invoices. The fix copies the tax domain settings from the desktop version, ensuring mobile users see the appropriate tax types based on the invoice type. This improves the user experience and accuracy of invoice creation on mobile devices.
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Create an new invoice - Add an invoice line - Click on the Taxes field => Both purchase and sales taxes are available Solution ======== Copy the domain from the desktop list view https://github.com/odoo/odoo/blob/fcc677e900c2fccb9fa0bd88ef01c559cadfa08a/addons/account/views/account_move_views.xml#L1051-L1055 We also add the corresponding context and options opw-5124536 Forward-Port-Of: odoo/odoo#239505 Forward-Port-Of: odoo/odoo#237724
This update resolves a test failure within the Odoo Enterprise system. The issue stemmed from an incorrect count of employee analytic accounts during a test run, caused by a scheduling error. This fix ensures accurate account creation and prevents future test failures.
Original PR description
fixing runbot error https://runbot.odoo.com/odoo/runbot.build.error/234639 on test test_mrp_analytic_account_employee_from_widget introduced by this PR https://github.com/odoo/enterprise/pull/85517
**cause of the error:**
Because there is a resource.calendar.leave without calendar_id,
without resource_id and at a date after today :
during the setupclass, when the employee is created,
_create_future_public_holidays_timesheets() creates an account.analytic.line.
So at the end of the test ,
self.env["account.analytic.line"].search([('employee_id', '=', self.employee1.id)])
returns 2 records instead of 1.
runbot-234639
Forward-Port-Of: odoo/enterprise#102338
Forward-Port-Of: odoo/enterprise#102282This update resolves a bug where the 'convert to task' option repeatedly appeared for converted Todo items. The fix hides this option when a project is assigned, streamlining the task conversion process and preventing user confusion. This improves the overall user experience and efficiency.
Original PR description
Steps to reproduce: - Create a Todo and convert into task using cog Menu option. - Todo is converted to task and is displayed. - Through breadcrumb go back to Todo - Try to convert it again Issue: - The converted todo is again converted (change of project etc) Fix: - Hiding the convert cog menu when a project is set. task-5075327 Forward-Port-Of: odoo/odoo#240750 Forward-Port-Of: odoo/odoo#230031
This update fixes a misleading error message displayed when deleting sale orders with associated appointments. Previously, users received an incorrect instruction to reduce order quantities. Now, the system correctly informs users they must cancel the order before deletion, aligning with expected behavior and improving the user experience.
Original PR description
Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed.…
Problem: When the module is installed and there are bookings with answers linked to sale orders, the order lines are deleted before the order, causing the wrong error message to be displayed. Solution: The order lines should not be manually unlinked from the sale order. It should be the bookings linked to the order lines that should be unlinked before the sale order deletion. Expected Behavior: When deleting a sale order whose lines have bookings, the following error message shoud be displayed: "You can not delete a sent quotation or a confirmed sales order. You must first cancel it." Current Behavior: When deleting a sale order whose lines have bookings, the following error message is displayed: "Once a sales order is confirmed, you can't remove one of its lines (we need to track if something gets invoiced or delivered). Set the quantity to 0 instead." Steps to reproduce on Runbot: 1. Install Appointments and ecommerce 2. For the dental care appointment, edit and enable "Up-front payment" 3. On the website, book an appointment for dental care and proceed to payment 4. Delete the sale order with the booking 5. Observe the incorrect error message being displayed opw-5092349 Forward-Port-Of: odoo/enterprise#100371
This update fixes a minor inconvenience for users. Previously, clicking 'Jump to Present' would cause the composer to lose focus, requiring manual adjustment. Now, the composer automatically regains focus on desktop after this action, improving the user experience.
Original PR description
**Current behavior before PR:** clicking "Jump to Present" caused the composer to lose focus, forcing users to manually focus the input before typing. **Desired behavior after PR is merged:** The composer automatically regains focus on desktop after clicking "Jump to Present". task-[5035977](https://www.odoo.com/odoo/project/1519/tasks/5035977) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240743 Forward-Port-Of: odoo/odoo#227781
This update fixes a visual inconsistency in the Point of Sale (POS) interface. Previously, product images were always displayed in combo product configurations, regardless of the overall image visibility setting. Now, combo products correctly respect the configured image settings, ensuring a consistent and professional user experience.
Original PR description
Before this commit: ==================== In POS, when product images were configured to be hidden, the setting was correctly applied to normal products. However, in the combo product configurator, product images were still displayed, causing inconsistency with the configured behavior. After this commit: ====================== The combo product configurator now respects the product image visibility configuration, ensuring consistent behavior across all product types in the POS interface. Task-5163955 Forward-Port-Of: odoo/odoo#231366
This update resolves critical issues preventing incorrect credit note submissions to the Kenya Revenue Authority (KRA). Specifically, the system now validates that credit notes match the original invoice's customer PIN and that the credit note date is not before the invoice date, ensuring accurate tax reporting.
Original PR description
* Prevent credit note with customer PIN different than the submitted invoice. * Prevent credit note to be dated before the original invoice date. task-5160113 Forward-Port-Of: odoo/enterprise#102475 Forward-Port-Of: odoo/enterprise#100480
This update resolves a validation error that occurred when starting work orders with flexible resources, particularly when the time was set to a late part of the day. The fix ensures that attendance intervals are correctly aligned, preventing the 'start date' from being after the 'end date' and improving the accuracy of time tracking for flexible workers.
Original PR description
**Steps to reproduce** On a local DB, with demo data: - Change your machine's time to a late part of the day (e.g. 6pm) - Install `mrp_workorder` - Set the "Standard 40 hours/week" (used by a…
**Steps to reproduce** On a local DB, with demo data: - Change your machine's time to a late part of the day (e.g. 6pm) - Install `mrp_workorder` - Set the "Standard 40 hours/week" (used by a workcenter) as flexible. - From the Shop Floor, start the "WH/MO/00003 - Manual Assembly" workorder. "Validation Error: The start date of the time off must be earlier than the end date." **Cause** `_calculate_date_finished` in mrp is calling `plan_hours` and under certain conditions with a flexible resource, it is possible for `plan_hours` to return a datetime before the `day_dt` parameter. This happens because for flexible resources, `_attendance_intervals_batch` can return attendance intervals with start or end datetimes outside of the start_dt -> end_dt window. For example, a flexible calendar with 8h/day will return the 8:00->16:00 interval, even if start_dt is later than 8:00. **Change** Don't return attendance intervals outside of the [start_dt, end_dt] interval by shifting them if necessary. opw-5123230 Forward-Port-Of: odoo/odoo#233169
This update fixes an issue where multiple loyalty programs on a single order weren't always applied correctly. The fix uses a locking mechanism to ensure only one update process runs at a time, guaranteeing all loyalty discounts are applied consistently. This improves the accuracy of POS order calculations.
Original PR description
When adding a lot of loyalty programs with discounts to an order the updatePrograms method could be called multiple times in parallel, that would cause an issue where some of the programs were not…
When adding a lot of loyalty programs with discounts to an order the updatePrograms method could be called multiple times in parallel, that would cause an issue where some of the programs were not applied correctly. Steps to reproduce: ------------------- * Create 7 loyalty programs that apply on the same product, each with a discount reward of 10%. (Give them different name) * Create a POS order with 1 unit of that product. > Observation: Only the 6 first programs are applied. Why the fix: ------------ The issue is happening because the updatePrograms is called multiple times in parallel, and when coming to this block of code : https://github.com/odoo/odoo/blob/f3e74f9b840efef7c567ba31acd6ac61c79b5d6d/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L182-L188 The last program has 2 coupons in the `couponPointChanges`, so it will proceed to delete all the coupons of the concerned program. To avoid this we use a mutex to ensure that only one call to updatePrograms is happening at a time. opw-4974788 Forward-Port-Of: odoo/odoo#240639 Forward-Port-Of: odoo/odoo#239662
This update fixes a minor issue with the self-order ticket layout in Odoo. Previously, important details like table numbers and configuration names were missing, and order information wasn't displayed correctly. Now, all necessary information is included, ensuring clearer and more accurate preparation tickets for self-order transactions.
Original PR description
Before this commit: =================== - Some details were missing from the preparation tickets, such as the table number and configuration name. - The order reference and time were not displayed in the correct positions. After this commit: ================== - Added the configuration name and table number to the receipt. - Corrected the placement of the order reference and time. Task: 5268966 | Before this PR | After this PR | |--------|--------| | <img width="511" height="431" alt="before" src="https://github.com/user-attachments/assets/ac5b2c45-5210-4a4e-86c7-953e2ab89eb1" /> |<img width="514" height="448" alt="after" src="https://github.com/user-attachments/assets/f1feb317-d5fe-469a-ab70-cf1dd793dce5" />|
This update fixes an issue where product templates were incorrectly calculating discounted prices, leading to inflated prices being displayed. The fix ensures that discounted prices are accurately calculated for products sold through templates, preventing pricing errors for users. This improves the accuracy of product pricing in the catalog.
Original PR description
Steps to reproduce: 1- Add a product that has variants to a vendor pricelist. 2- Set the vendor's unit for this product to a one different than the product's unit. 3- Create an RFQ with from that vendor. 4- Open the catalog. Issue: `discounted_price` is miscalculated and causes wrong price calculation, it shows the price multiplied by its factor. i.e if a price of pack of 6 is 10$, it will be shown as 60$. Cause: We only check for `product_id` not for `product_tmpl_id` when computing the `price_discounted`, so if its a template, `product_id` is false, and its sent with `_compute_price()` and the same price is returned since there's no unit and after that its sent to `_get_product_price_and_data` where its converted to the new unit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240519
This update fixes an issue where the total price in Point of Sale orders was incorrect when using products tracked by 'LOT' with groupable UoMs. The fix ensures that the price unit is consistently applied to the converted quantity, accurately calculating the order total. This improves the reliability of sales transactions.
Original PR description
Steps to reproduce ------------------ 1. Make a product tracked by 'LOT' and having a groupable in pos UoM 2. Make a SO with that product, choosing another UoM from the same category (if we chose Kg in first step, choose gram here, etc) 3. Settle the order in PoS. We observe that the order's total amount is totally off, we explain why below. Why it's happening ------------------ The `lot_remaining_quantity` is quantity after converting to the original UoM (that of step 1, not that of step 2). We are using that quantity for lines having products tracked by 'LOT' and a groupable UoM; however, we are keeping price unit as if we are using the quantity before conversion, i.e. the quantity in the UoM of step 2. That creates a mismatch between the UoM and thus we miscalculte the total price. The fix ------- When using the converted quantity, also use the converted price unit. opw-5144326 Forward-Port-Of: odoo/odoo#240956 Forward-Port-Of: odoo/odoo#239858
This update fixes a critical bug that caused Odoo to crash when sending invoices via Peppol with invoice lines lacking a product name. Now, the system gracefully displays an error message, guiding users to ensure each invoice line has a product or label before sending. This improves invoice processing reliability and prevents data loss.
Original PR description
Before this commit: When sending an invoice via Peppol with an invoice line that has no product name, the system crashes with a TypeError instead of showing a error message. Steps to reproduce: 1. Go to Accounting 2. Navigate to Customers > Invoices 3. Create a new invoice 4. Add an invoice line without entering a product name 5. Click 'Send' 6. Select 'by Peppol (Demo)' 7. Click 'Send' -> TypeError: 'NoneType' object is not subscriptable After this commit: System validates that the product name exists before accessing its text content. Users see a clear, error message: `Each invoice line should have a product or a label.` task-5432061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240908
This update fixes an inaccuracy in the documentation for Odoo's phone number features. The previous documentation incorrectly referenced a method that didn't exist, and has now been updated to reflect the correct method used in the codebase. This ensures clarity and accuracy for developers.
Original PR description
A mention to `_voip_get_phone_field` appeared in [1] but this seems to never have existed. In any case, `_phone_get_number_fields` was used by the codebase in the end and should thus be the one mentioned. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd
This update expands the supported countries for itsme authentication within Odoo Enterprise to align with the official itsme coverage. This ensures compliance and allows users in more regions to seamlessly access Odoo using itsme, improving user experience and operational efficiency. The change addresses a previous limitation.
Original PR description
Extend itsme availability beyond BE and NL to match the official itsme coverage: https://www.itsme-id.com/en-BE/business/coverage task-5424818 Forward-Port-Of: odoo/enterprise#102423