Friday, October 31, 2025
7 changes · 17.0
Enhancements to existing features
Stock availability calculations now avoid unnecessary repeated checks when many incoming and outgoing stock moves are linked. This can make large picking reports much faster, reducing wait times for users reviewing product availability.
Original PR description
Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings…
Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings containing moves linked to many incoming and outgoing moves, the `reconcile_out_with_ins` function caused performance issues. The reconciliation logic worked as follows: 1. For each `out_move`, attempt to match it with an `in_move` if the `in_move` references the `out_move` in its `move_dests`. 2. If the demand of the `out_move` is not fully satisfied, add it to `unreconciled_outs`. 3. Loop over `unreconciled_outs` (after attempting to reconcile them using the initial prodcedure) to reconcile against the remaining `in_moves`. The performance bottleneck was that even when an `in_move` directly referenced an `out_move`, the code would unnecessarily loop over **all** `in_moves` to filter out the `in_moves` that has the `out_move` in its `move_dest`. --- To improve performance, an **inverse mapping** from `out_move` IDs to their corresponding `in_moves` is introduced. - Reconciliation now starts by iterating only over the relevant `in_moves`. - If the demand is still unmet, the algorithm attempts reconciliation against the remaining `in_moves`. - This reduces the time complexity to **O(N + M)**, since `in_moves` with zero quantities are removed and never revisited. **Implementation details:** - An `OrderedSet` is used for the inverse mapping to preserve the original query order. - Benefits of `OrderedSet`: - **O(1)** removal (assuming no collisions) - Maintains insertion order, ensuring the same order as the query result. --- | Metric | Before PR | After PR | |---------------|-----------|----------| | Execution Time| ~90 sec | ~10 sec | The benchmark above is done on a `stock.picking` record that queried in the `_get_report_lines` method **5331** `out_moves` and **8922** `in_moves`. opw-4951469
Resolved issues and error corrections
This fixes cases where a renamed document still showed its old file name in the preview window. Users will now see the correct document name immediately and consistently when previewing files, reducing confusion when managing documents.
Original PR description
# Issues There are a total of 3 different flows by which we observe the common issue (name not updating in the fileviewer) ----------------------------- ### 1st flow 1. click on any image to preview…
# Issues There are a total of 3 different flows by which we observe the common issue (name not updating in the fileviewer) ----------------------------- ### 1st flow 1. click on any image to preview it. 2. close the preview. 3. now just select the same document. 4. change it's name from the inspector and hit ENTER. 5. now keeping it selected, preview it again. 6. you will notice the file name has not been updated in the file viewer. issue: - the existing IF condition which is present only checks for the datapoint ID (which changes only when we replace the existing document with a new document). reason: - but in our case, since the document is same the ID remains the same. - as a result, the code inside the IF block does not get executed and the document store is not updated. but we still need to update the document store with the newly updated document. fix: - we remove the IF condition so that we ensure that the document store is updated everytime we PREVIEW any document. ---------------------------------------------------- ### 2nd flow 1. click on any image to preview it. (do not select it) 2. change it's name from the inspector and hit ENTER. 3. close the PREVIEW. 4. PREVIEW the same document again. 4. you will notice the file name has not been updated in the file viewer. issue: - for some reason the existing `record.save()` fails to save/update the root records. fix: - we find that record from the root and save it from the root. ---------------------------------------------------------- ### 3rd flow 1. click on any image to preview it. 2. change it's name from the inspector and hit ENTER. 3. you will notice the file name has not been updated in the file viewer. issue: - the `previewStore` object is formed/updated only when we preview any document. it is this `previewStore` object which contains the list of documents to preview. - but when we update the file name from the inspector, the code to update the `previewStore` is absent. fix: - on updating the values from the inspector, we now update the `previewStore` as well. which then goes on to update the name in the FILEVIEWER. Task-4605750
Planning analysis reports no longer count hours from a shift that falls outside an employee's working schedule just because it crosses into a new month. This prevents planned hours from being overstated in the wrong reporting period, improving accuracy for capacity and timesheet planning.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052
Company logo lookup now uses Odoo's enrichment service instead of fetching logos directly in the user's browser. This should make partner enrichment more reliable while removing logo display from the initial search results.
Original PR description
Before this commit- We used to rely on clearbit to fetch the logo of the company on the client side After this commit- We replace it with logo.dev and remove the fetching of logo from client side and move it to the IAP task-5126337 IAP PR- https://github.com/odoo/iap-apps/pull/1234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Copying an email template now also creates separate copies of its attachments, instead of sharing the same files across templates. This prevents attachment changes from unintentionally affecting other copied templates and helps avoid access issues where attachment permissions depend on the specific template.
Original PR description
Copying tmeplates should copy their attachments. Otherwise they are
shared, which means
* wrong res_id: ACL check on attachments relies on a specific
template, as res_model / res_id is used in access check;
* propagated changes: changing one attachment changes it on all
duplicated templates;
If custom rules on templates are implemented, this means notably
ACL issues when accessing attachments. It is not the case in standard
Odoo 17 as everyone can read templates but this notably changes in
future versions of Odoo.
While being there, also fix 'default' usage in copy override. User
given values should not be erased by default computation of name.
Task-5128863This fix keeps the bill of materials selection in sync when a user changes the product on a scrap order. It prevents scrap orders from showing a zero quantity while still moving the original quantity, reducing inventory inconsistencies.
Original PR description
Problem: When a user changes the product on a scrap order, the bom_id field does not get updated. If they update the product from a product that has BoM to a product that doesn’t have one, then the bom_id field is hidden and remains set. This will cause the scrap quantity to be set to 0 when they validate the scrap. However, the product move actually happens for the correct quantity causing an inconsistency. Purpose: This will either set the bom_id field to False if the new product doesn’t have a valid BoM, or it will update it to the first available BoM. Steps to Reproduce on Runbot: 1. Create a scrap order for a product that has a kit type BoM and set the kit field. 2. Change the product to a product without a kit type BoM. 3. Validate the scrap order. 4. Observe the quantity field is set to 0, but there are product moves for the correct quantity. opw-5122880 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Swiss payroll now avoids applying AHV/IV/EO deductions when a retired employee’s AVS salary becomes negative due to variable pay and exemption thresholds. This prevents an incorrect increase to net salary and keeps payslip calculations aligned with expected payroll rules.
Original PR description
**Issue:** For retired employees with AHV Insurance and variable pay, if their pay previously exceeded the exempt amount but is below the exempt amount on the current payslip, the AVS Salary will be…
**Issue:** For retired employees with AHV Insurance and variable pay, if their pay previously exceeded the exempt amount but is below the exempt amount on the current payslip, the AVS Salary will be negative, which is expected. However, the AVS deduction is still calculated based on this negative amount and adds to the Net Salary, which is incorrect. Instead, no deduction should be applied. **Steps to Reproduce:** 1) Install l10n_ch_hr_payroll_elm_transmission 2) Change to My Swiss Company and enable the Switzerland Fiscal Package 3) Go to Payroll > Configuration > AVS/AC Insurances 4) Create a new record, fill in the empty required fields with any data 5) Create a new employee 6) Create a contract for the employee starting January 1, with: - Contract Type = Permanent contract with monthly salary - Has Monthly Wage = True, 500.00 7) On the contract under Insurances tab, set: - AVS/AC Insurance = The Insurance created in (4) - AVS Special Status = Retired 8) Create a payslip for January, compute sheet, and post draft entries. -> AVSSALARY = 0 (Correct) 9) Change the Monthly Wage and repeat payslip creation and posting for the following months: - February: 800 - March: 1,200 - April & May: 3,000 - June: 800 -> On the June payslip, notice that the AVS Salary is negative (correct) but the AVS Deduction is positive and adds to net salary (wrong) **Solution:** Modify the AHV/IV/EO contribution and AHV/IV/EO Employer contribution rules so that if the AVS Salary is less than 0, no deduction is made. opw-5042175