Daily updates from Odoo
Friday, September 19, 2025
9 changes · saas-18.3
Resolved issues and error corrections
Opening Knowledge activities now filters the article list to the articles that actually have matching activities. This prevents users from landing on an unfiltered list of all articles and helps them find the relevant work faster.
Original PR description
Currently, when the user tries to open any activity of the knowledge article, it opens all articles instead of the one which has an activity assigned to them. **Steps to reproduce this issue:** 1) Install the Knowledge module 2) Set up an activity for yourself on a Knowledge article 3) Open the activities from Activities (top left corner) **Issue:** You will end up in the all articles list, with no filters applied. **Cause:** When the user clicks on the activities, a default search filter is added in the context, which is then applied on the view. But in the knowledge article, we don't have any search filters for the activities. Therefore, it renders all knowledge article records. **Solution:** Add search filters for the knowledge articles. opw-4997201 Forward-Port-Of: odoo/enterprise#93609
This fixes an error that appeared when opening the barcode scanner in Attendance kiosk mode while debug mode was enabled. The scanner now uses the standard barcode scanning flow, preventing the crash and improving reliability for users managing attendance check-ins.
Original PR description
**Step to reproduce:** - install Attendances app - turn on debug mode - go to Attendance -> kiosk mode - open the scanner **Observation:** - We get a traceback **Cause:** - we pass a extra prop `token` to BarcodeDialog component, which is not accepted by it https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L12 - this raises issue from OWL when we have debug-mode on **Fix:** - reuse the actual `scanBarcode` method and remove the faulty one. https://github.com/odoo/odoo/blob/178dff30131a93680dfd994fd22b29a766ee9354/addons/web/static/src/core/barcode/barcode_dialog.js#L47-L60 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227551 Forward-Port-Of: odoo/odoo#225738
This update brings the spreadsheet component to its latest maintenance version. It fixes incorrect error messaging, improves handling of empty spreadsheet data, and corrects pivot table calculated measures so business reports remain accurate.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b64ee85e0 [REL] 18.3.21 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b64ee85e0 [REL] 18.3.21 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/a9e5756c6 [FIX] functions: wrong error message for `SORT` [Task: 5085267](https://www.odoo.com/odoo/2328/tasks/5085267) https://github.com/odoo/o-spreadsheet/commit/679819e2f [FIX] helpers: preserve sparse(empty) elements in removeIndexesFromArray [Task: 4977932](https://www.odoo.com/odoo/2328/tasks/4977932) https://github.com/odoo/o-spreadsheet/commit/c405bca1b [FIX] package: add swc binaries to optional dependencies [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3a578beaa [FIX] pivot: calculated measure from totals [Task: 5061631](https://www.odoo.com/odoo/2328/tasks/5061631) https://github.com/odoo/o-spreadsheet/commit/906bf4c28 [FIX] pivot: add aggregator to calculated measure id [Task: 5061631](https://www.odoo.com/odoo/2328/tasks/5061631) 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: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@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>
Purchase entries in the Indian GSTR-3B report now include credit notes, receipts, and other relevant purchase records. This improves tax report accuracy and removes unrelated purchase data from the POS reporting area.
Original PR description
Currently, purchase entries are not displaying the correct data because the credit notes and receipts were not included. This PR removes purchase-related data from `l10n_in_reports_gstr_pos` (as POS has no relation to purchase records) and ensures that credit note data and other purchase records are properly displayed in the GSTR-3B report. **opw**-5079401 Forward-Port-Of: odoo/enterprise#95079 Forward-Port-Of: odoo/enterprise#94582
Creating a field service task from a template now correctly keeps the template's Under Warranty setting. This helps teams avoid missed warranty coverage details and reduces manual corrections after task creation.
Original PR description
**Steps to reproduce:**
- Install industry_fsm_sale
- Create a task template with "Under Warranty" enabled
- Create a task from that template
**Issue:**
The created task does not carry over the "Under Warranty" value from the task template.
**Cause:**
The `under_warranty` field has `copy=False`, so the value is not transferred.
**Fix:**
Updated the copy method to check for `copy_from_template` in the context. If the task template has "Under Warranty" enabled, the field is explicitly set on the new task.
task: 5083386The Planning and Timesheet Analysis report now calculates planned and remaining hours using each employee's actual working schedule. This prevents incorrect totals for employees who do not work the standard company weekdays, improving reliability of planning reports.
Original PR description
To reproduce: ============= - set the company calendar to 40h/week (Mon to Fri) - create an employee with a 32h/week working schedule (doesn't work on Fri) - on planning app, create a shift for this employee for ex from 01/09 to 15/09 with 2h allocated - go to Planning / Timesheet Analysis report and check report for this employee on september -> planned hours and remaining hours are wrong Problem: ======== when querying the data for the desired period, we divide the allocated hours by the number of weekdays (Mon to Fri) in the period, but we should divide by the number of working days according to the employee's working schedule Solution: ========= we compute the number of working days based on the resource calendar of the employee and use this number to compute the planned hours and remaining hours opw-5008066
This change rolls back earlier updates to manufacturing unbuild valuation because they introduced accounting inconsistencies and errors in some cost scenarios. The team will restart with a different approach to better handle stock valuation without creating incorrect balances.
Original PR description
This commit reverts [1], [2], [3], and [4]. (It actually results in minimal changes since those commits were already removing parts of each other.) Issue before those commits: 1. Setup a auto-fifo…
This commit reverts [1], [2], [3], and [4]. (It actually results in minimal changes since those commits were already removing parts of each other.) Issue before those commits: 1. Setup a auto-fifo category and two storable products (a component and a finished product) 2. Receive one compo at 10, then one at 25 3. Produce two MO with one finished product 4. Unbuild the second one Error: - For the component, we just use the value of the consumed components: IN 1 @ 25 - For the finished product, we process it as a classic out. Reminder, we are in FIFO: OUT 1 @ 10 As a result, thanks to the unbuild, we have created - A over-valuation of the stock (+15) - An outstanding balance of the "Cost of Production" This is why [1] has been merged. However, it brought some other issues, cf [2], [3] and [4]. Unfortunately, it still has some issues - After the above use case, the difference between the debit and the credit of the stock valuation account is no longer the sum of the remaining values of the layers - Adding some landed costs on MOs will lead to a traceback when undbuilding - The over-valuation of the stock (that was already present before [1], cf above) is still present Following some discussions with R&D and the product owners, we have decided to start over from scratch, which means: - Revert all commits - Try another approach (if so, the new PR will be linked to the PR related with this commit) [2], [3], and [4] are partially reverted: the tests can remain, as they were only failing due to a sequence of changes. [1] https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3 [2] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c [3] https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47 [4] https://github.com/odoo/odoo/commit/fb30cde9a320c245cf1321c9dc2ea2e67a53d0a0 OPW-5036574 Forward-Port-Of: odoo/odoo#226380 Forward-Port-Of: odoo/odoo#225728
This update prevents crashes when Odoo loads records in rare invalid or mixed states. It makes the core data layer more consistent and reliable, reducing unexpected errors for users and administrators.
Original PR description
This commit addresses two corner cases that cause `fetch()` to crash: Mixing new and real records: - Issue: If a recordset contains both new and real records, `fetch()` raises an `AccessError`. - Rationale: While we typically assume that new and real records are never mixed, certain recordset operations can inadvertently lead to this state. Handling this case improves the overall robustness of the ORM. Using `False` as a record id: - Issue: Using a record with a `False` id, such as `browse([False])`, causes a SQL error when `fetch()` is called. - Rationale: Other operations, like `browse([False]).name`, work without crashing. To ensure consistency across the ORM, `fetch()` should also handle `False` ids without error. Forward-Port-Of: odoo/odoo#227447
This fix prevents the messaging editor from crashing when a user presses ArrowUp while editing an attachment-only message. It keeps the composer stable in this edge case, improving reliability without changing normal messaging behavior.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Pressing the ArrowUp key in the editing composer when it is empty while editing a message with only an attachment caused a JavaScript traceback. This happened because the composer was not associated with a thread, and the code tried to access `composer.thread.lastEditableMessageOfSelf`. **Current behavior before PR:** --------------------------------- - Pressing ArrowUp in the empty editing composer triggers a TypeError - The error occurs when editing a message that only has an attachment - The composer does not have a thread reference **Desired behavior after PR is merged:** ----------------------------------------- - Pressing ArrowUp in this scenario safely checks if a thread exists - No TypeError occurs, and the composer remains stable **Task:** 5068553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr