Tuesday, May 12, 2026
4 changes · 17.0
Resolved issues and error corrections
This update resolves an issue where employees archived through HR wouldn't be properly checked out of attendance. The fix utilizes a 'sudo' method to grant necessary permissions during archiving, ensuring accurate attendance updates and preventing access errors. This improves data consistency and reliability for employee records.
Original PR description
- Attendance checkout
- Step to reproduce: with attendance installed and an employee checked in, archive that employee by HR user. If missing attendance rights, the employee will be archived but not checked out from its ongoing attendance.
- Cause: if no role set for Attendance (default), no permission to update the employee attendance while archiving.
- Solution: using sudo method so that any user with sufficient rights to archive an employee, can trigger check out of the corresponding attendance.
- Planning access error (fixed in 18.0 by https://github.com/odoo/odoo/pull/219395)
- Step to reproduce: with attendance and planning installed, archive an employee having planning slots. If missing planning rights, an access error is raised
- Cause: on employee archive, the corresponding planning.slots are updated and some fields recomputed with insufficient rights.
- Solution: using sudo method for recompute.
Task: 6131692This update fixes an issue where unsubscribe links in emails were incorrectly generated for users in different companies. The change ensures the correct website domain is used to construct the unsubscribe URL, resolving redirection problems and ensuring users are directed to the proper unsubscribe page.
Original PR description
Problem: In a multi-company scenario and multi-website domain scenario when website domain 1 belongs to company 1 and website domain 2 belongs to company 2, if we send a mailing based on the contacts…
Problem: In a multi-company scenario and multi-website domain scenario when website domain 1 belongs to company 1 and website domain 2 belongs to company 2, if we send a mailing based on the contacts model, the base url is currently being computed using the mailing instead of the recipient model. Due to this, the unsubscribe link in the email is generated such that website domain 1 is computed as the base url. This leads to an issue when a user belonging to company 2 clicks on the unsubscribe link and gets redirected to the login page because the email has the “unsubscribe_from_list” link instead of the “confirm_unsubscribe” link. Purpose: The unsubscribe link takes the recipient model and computes its base url. This ensures that the “unsubscribe_from_list” in the email body gets correctly substituted with the unsubscribe_url computed above and the user gets the correct email url link for unsubscribing. Steps to Reproduce on Runbot/locally: 1. Create two companies A and B 2. Create two websites A and B belonging to the companies A and B respectively. Assign different domains to them. (For example: http://localhost:8569 for website A and http://1.localhost:8569 for B) 3. Check that the web.base.url system parameter is http://localhost:8569 (i.e domain of website A) 4. Create a new test contact belonging to company B. 5. Create a new mailing in email marketing and in the recipient model, choose Contacts and put a filter that chooses the contact we created in step 2 6. Choose any template that has the unsubscribe option and save the mailing. 7. Send it to all. 8. Go to scheduled actions and search for “Mail Marketing: Process queue” and run manually 9. The emails will be sent out. Open MailHog in an incognito browser and check the email sent. Click on the unsubscribe link, it takes us to the login screen instead of the unsubscribe page. opw-4914203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the French FEC report only displayed invoices from the main company. The change ensures that invoices from both the parent company and any associated branches are now included in the generated report. This improves the accuracy of financial reporting for multi-branch businesses.
Original PR description
Issue: Report is exported only with the main company data. Steps to reproduce (require Accounting App): - create a French company - create and confirm an invoice for the previous month - create a branch in France for this company - create and confirm an invoice for the previous month in the branch - in the parent company, with both parent and branch selected - go to Reporting -> FEC - select the previous month - generate report Current behavior: - Only the invoice from the parent company is in the report Expected behavior: - invoices from the parent and branch are in the report Cause: From PR odoo/odoo#240981, the FEC report is streamed to the client. However, as this is treated in a second thread, it loses which company are selected, therefore, the report is sent for the current company only opw-6123080
This update optimizes a key database query used in Point of Sale reporting, resulting in significantly faster report generation. By adding the journal to the search criteria, the system now leverages an existing database index, dramatically reducing the time required to retrieve data. This change improves the overall performance and responsiveness of the POS system.
Original PR description
Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field. Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods. All measures are performed with a warmed up cache [Explain Before](https://explain.dalibo.com/plan/h8edf56c09d7dfd7) ### Benchmark: <table> <thead> <tr> <th># of am</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>38982635</td> <td>~17s</td> <td>~22ms</td> </tr> </tbody> </table> [Explain After](https://explain.dalibo.com/plan/be2397f176a6b29d) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr