Daily updates from Odoo
Thursday, August 14, 2025
12 changes · 18.0
Enhancements to existing features
Point of Sale now avoids repeating the same product preparation work when loading loyalty rewards. This significantly reduces startup time for businesses with many loyalty programs and products, helping staff open POS sessions faster.
Original PR description
In databases with many Loyalty Rewards and products, the POS loading time can become very slow due to repeated product serialization in the `compute_discount_product_ids` function. This commit stores serialized and non-serialized versions of the product list once to avoid redundant serialization. On a DB with 144 programs and ~6500 products, loading time was reduced from 55s to 14s with this change. opw-4986057
Subscriptions that were churned now return to active status when their invoice is paid, including payments made by bank transfer or manually. This helps avoid paid customers remaining incorrectly marked as churned, while still respecting the allowed automatic closing period.
Original PR description
Before: - A subscription is reopened only when a customer pays through the portal. - Manual payments do not reopen the subscription. - invoice is paid but subscription remains churned. After: - Subscriptions now reopen when invoice paid through bank transfer. - Additionally, reopening is the subscription will only reopen if the next_invoice_date is within the allowed automatic closing limit (next_invoice_date >= today - automatic closing limit). Impact: - Paid invoices now always bring the subscription back to active status task-4277444
Belgian Annual Accounts exports from the General Ledger now generate an XML file instead of a fixed-format TXT file. This better matches official formatting expectations and improves compatibility for downstream processing, including account balances, multilingual descriptions, and related metadata.
Original PR description
The previous Annual Accounts export in the General Ledger generated a TXT file with a fixed column order, which did not meet the structural or formatting requirements for downstream usage. This commit replaces the TXT export with an XML export conforming to the official format, including fields such as account code, debit, credit, multilingual descriptions, and metadata. task-5005345 Forward-Port-Of: odoo/enterprise#92071
Resolved issues and error corrections
Purchase catalog prices are now converted from the vendor's currency into the purchase order currency. This prevents buyers from seeing mismatched prices when adding products through the catalog, improving accuracy for requests for quotation and purchase orders.
Original PR description
Before this commit, the unit price in the catalog for purchase order wasn't converted from other currencies to the order one It was just set to the price regardless of the vendor currency This fix will automatically convert the catalog prices from seller's currency to purchase.order's currency Steps to reproduce: - Create a product to Purchase - Add a vendor in the Purchase Tab - Set quantity to 1, price to 100 and currency to EUR - Create a RFQ - Select the Vendor from the product created - Check to currency to be USD - Add the product and take note of the Unit Price - Remove the product line - Go to Catalog - Compare the Price with the Unit Price (They doesn't match before the fix) opw-4909789
Non-admin users can now update settings on recurring calendar meetings without being blocked by an access error. This keeps everyday calendar management working smoothly for users who do not have administrative permissions.
Original PR description
**Issue:** An access error occurs when a non-admin user attempts to modify the meeting settings of a recurring calendar event. **Steps to reproduce:** - Log in as non admin user - Go to Calendar > Create new meeting. - Set Reminders - Check the Recurrent checkbox and save the event. - Edit the Recurring Event settings and save again (2–3 times) An access error is raised as non admin users aren't allowed to read ir.cron.trigger opw-4899572
Confirming a sales order for a service that creates a project no longer removes analytic accounts that users already added manually. This prevents extra rework and helps mandatory accounting allocations remain in place for invoicing.
Original PR description
Problem: When a user creates an analytic distribution model and is applied to a product that creates a project when ordered, any other analytic account, that are not included in the distribution…
Problem: When a user creates an analytic distribution model and is applied to a product that creates a project when ordered, any other analytic account, that are not included in the distribution model, added to the quotation will get overwritten upon confirming the quotation. The override on `_compute_analytic_distribution` in sale_project depends on the order's project. In the case where a project gets created upon order, the compute will trigger, which effectively recomputes the analytic distribution based on the model, overwriting other analytic account not defined on the model. Solution: The override on `compute_analytic_distribution` in sale_project should not call `super` when it gets triggered based on any change to the order's project. If the compute is triggered based on a change to the order's project, only the project's analytic account should get added onto the existing analytic distribution on the sale order line. This will ensure that any other analytic accounts added to the sale order line will not get overwritten by the recompute. Purpose: Implementing this change will save the user the extra step of needing to add the mandated analytic accounts again to the sale order line. Before the change, the user will need to add the mandated analytic account in order to confirm the quotation. Since the mandated analytic account gets overwritten from the compute based on the distribution models, the user will have to add the mandated analytic account back to the sale order line in order to create an invoice. Steps to Reproduce on Runbot: 1. Install Sales, Accounting, Project 2. Enable Analyic Accounting in Settings > Analytic Accounting 3. Create an Analytic Distribution Model with 2 different analytic account and set the product category to All 4. Create a new analytic plan that is mandatory 5. Create a new analytic account linked to the new analytic plan 6. Create a new product that is a service under the 'All' category and creates a project on order 7. Create a sales order with the new product and notice that the analytic distribution is from the model and not from the mandated analytic plan. 8. manually Add the mandated analytic account 9. Confirm the sales order and notice that the mandated analytic account is gone opw-4934291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Timesheet entries under one hour now reduce a project's remaining time by the exact number of minutes entered instead of rounding to whole hours. This gives users more accurate project time tracking and prevents misleading remaining-time estimates.
Original PR description
_______________________________________ ## Short functional explanation of the error When a user encodes an amount of minutes below 30, the estimated time remaining for the task doesn't change. But…
_______________________________________ ## Short functional explanation of the error When a user encodes an amount of minutes below 30, the estimated time remaining for the task doesn't change. But when the user encodes an amount above 30, but below 1 hour, the estimated time decreases of 1 hour. ## Reproduction Steps 1. Go to the Timesheets application. Click on the Timesheets tab and click on "All timesheets". 2. For any user, click on "Add a line" and create a test project. 3. Click on the project you created and set the allocated time to 8 hours, for example. 4. Go back to all timesheets. You should be able to see the remaining time. 5. For this project, add an entry of 15 or 45 minutes, depending on the case you would like to test. 6. Refresh the page. ### Expected behavior If the entry was set at 45 minutes, the estimated remaining time should be 7:15. If the entry was set at 15 minutes, the estimated remaining time should be at 7h45. ### Unexpected behavior If the entry was set at 45 minutes, the estimated remaining time shown is 7:00. If the entry was set at 15 minutes, the estimated remaining time shown is 8h00. ## Origin of the issue The estimated time was an integer which was rounded in the code. _________________________________________ opw-4988446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr 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
Card mailing recipients who share the same email address are no longer incorrectly treated as duplicates when their personalized card links differ. This helps ensure intended recipients receive their individualized card messages instead of being skipped during batch sending.
Original PR description
When sending a card mailing to recipients with duplicate emails, they are always considered duplicate emails. This is because: 1) We use "body" to detect duplicate emails, but "body" is never updated with the individualized card url. We now update the "body" as in the context of a mailing, "body_html" is just a copy of "body". 2) Mailings consider that all emails are always the same, meaning if it's detected that a mail was already sent to an email address during the mailing (in a previous batch) it would skip the actual duplicate body check. We disable that feature for card mailings. task-5009229
Confirmed repair orders can now keep kit components added after confirmation. This prevents those kit parts from disappearing after saving, helping repair teams maintain accurate component lists and avoid rework.
Original PR description
Steps to reproduce the bug: - Create a repair order with any component. - Confirm the order. - Try to add a kit as a component. Problem: After saving, the kit disappears. When a kit is added to a confirmed repair order, its move should be confirmed and therefore exploded. However, the moves created from this kit move are just copies of the original move. Fields with copy=False are not copied, including the repair_id field. In this case, repair_id must be added to link the move to the repair order, so it needs to be set manually. opw-4937817
This fix prevents serial numbers from being duplicated on point-of-sale order lines after a page refresh. It ensures tracked product serial details are saved and removed correctly, reducing order confusion and improving checkout accuracy.
Original PR description
**Step to reproduce:** - start pos - add product tracked with serial number - refresh the page **Observation:** - serial number is attached twice in same orderline **Issue:** currently, when dealing…
**Step to reproduce:**
- start pos
- add product tracked with serial number
- refresh the page
**Observation:**
- serial number is attached twice in same orderline
**Issue:**
currently, when dealing with tracked product, we add the lots in values
values.pack_lot_ids = packLotLine.map((lot) => ["create", lot])
these values are used to create pos_order_line.
Now, in case of product tracked by 'serial' , we again call `setPackLotLines`
https://github.com/odoo/odoo/blob/b3b0a0959ae12f53f702c359c1205d89a8e92ffb/addons/point_of_sale/static/src/app/store/pos_store.js#L897-L901
there, we remove the initially added lot and again add the same lot, (with new id).
but the old one is not properly unlinked from indexed db.
```
for (const lotLine of lotLinesToRemove) {
this.pack_lot_ids = this.pack_lot_ids.filter((pll) => pll.id !== lotLine.id);
}
```
hence on refresh, same lot (with different id) is attached to orderline.
**Fix:**
this pr tries to fix the issue at both places, we will add the lot only once
and also unlink the lot properly.
Note: issue only in 18.0, in higher version, SN vanishes after refresh
opw-4897882
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change reverts a recent sales update that could cause rental order creation to fail when currency information was missing or inconsistent. It unblocks the planning-to-rental flow needed for hotel industry rental demos and restores expected order creation behavior.
Original PR description
"line.currency_id" might be empty or contain more than 1 value, resulting in a crash of the method. This reverts commit ced1335c38834d5ac31f27705a2f7a0047ca8cc2. Traceback discovered when creating a rental order from a resource (planning flow). <img width="1607" height="907" alt="image" src="https://github.com/user-attachments/assets/0980b89b-fc2a-4bfe-a4c7-a290c92bb0e4" /> Quick revert needed to unblock the flow and allow a demo of hotel industry rentals.
Subscription invoices now link only the timesheets that belong before the next invoice date. This prevents hours from the next billing period from being attached to the current invoice and accidentally excluded from future billing.
Original PR description
Problem: When the user invoices a product based on timesheet from a subscription in a given month, the timesheets linked to the invoice incorrectly includes timesheets dated the same as the next…
Problem: When the user invoices a product based on timesheet from a subscription in a given month, the timesheets linked to the invoice incorrectly includes timesheets dated the same as the next invoice date of the subscription. This occurs if the client does not specify a timesheet period when creating the invoice. For example, the user invoices a subscription for the period of July 1st to July 31st and the next invoice date of the subscription is August 1st. There are timesheets dated in July and a timesheet dated August 1st. The quantity delivered for the invoice will only include timesheets within the July period. However, the linked timesheet to the invoice will mistakenly include the timesheet from August 1st. Purpose: Although the linked timesheet has no effect on the computation of qty_delivered for the current period, the timesheets dated the same as the next_invoice_date will get linked to the invoice and no longer be considered as delivered hours for the next period, which could cause gaps in hours delivered. The next_invoice_date should not be included in the date range when linking timesheets within the period of the invoice, since these hours were not included in the computation of quantity delivered. Steps to reproduce on Runbot: 1. Install Sales, Project, Timesheet 2. Enable Timesheet in Project > Settings 3. Create a service product that is based on timesheet and creates project and task on order 4. Create a quotation for the service product and set the recurrence to be monthly and set the start date to be the first of the past month 5. Confirm the quotation and set the next invoice date to be the first of the current month 6. Create timesheet hours within the period and one dated to be the first of the current month 7. Create an invoice for the subscription and notice that the timesheet from the first of the current month is linked to the invoice. opw-4689894