Friday, March 20, 2026
7 changes · 19.0
Enhancements to existing features
This update prioritizes synchronization of a user's databases, ensuring they see their key performance indicators (KPIs) first. By changing the synchronization order, it reduces the risk of databases being queued unnecessarily, leading to a smoother and more responsive experience for users.
Original PR description
The aim of this commit is to make sure the dbs from the current user are synchronized first allowing the user to see his db kpi first. Before this commit: The dbs were synchronized according to the default order of `project.project`. After this commit: The user dbs get synchronized first reducing the risk for those to be queued in the CRON. task-id: 5951983
Resolved issues and error corrections
This update resolves an issue where payslips for former employees were failing to calculate unpaid hours correctly. The change ensures that version history is accessed properly even after an employee is archived, allowing accurate calculation of worked hours for final paychecks. This was driven by a related change in the Odoo community.
Original PR description
Before this commit, when the user creates a payslip for an employee who left the company to pay him the remaining hours worked unpaid, the version date is no longer found since now the versions linked to an employee are also archived once the employee is archived. So, active_test has to be used to make sure we can find the date_start of the employee to compute to worked hours to pay in the payslip. This commit uses active_test once the employee is archived to be able to fetch the versions related since they are also archived thanks to the changes made in community. Community PR: odoo/odoo#243248 task-5349397
This update ensures that follow-up emails are consistently sent to customers, even when a large number of emails are queued. The system now automatically re-triggers the email sending process if there are still outstanding follow-ups. A new setting allows users to adjust the number of emails processed in each batch, optimizing performance.
Original PR description
In case there is a lot of followup to process, the followup cron doesn't retrigger and we have to wait the next day for them to be sent. This commit make use of the ir.cron progress API so that the cron is retriggered if there are followup left to be sent. We also make the batch_size configurable to that a user could tune it on the cron. opw-6042472
This update resolves issues related to how client IDs are formatted, specifically incorporating a hash for enhanced identification. The change ensures consistent handling of client IDs, particularly in payroll processing, and addresses previous errors related to connection attempts and configuration settings. This improves the reliability of the system.
This update allows users to access and view canceled signature requests within the Odoo Enterprise portal. Previously, canceled requests were hidden, preventing access to important communication details. Now, users will see the document and can review the request's history, improving transparency and usability.
Original PR description
Previously, users were redirected to the home page if they tried to access a signature request in the 'canceled' state. This prevented them from viewing the communication history or the document metadata. This commit: - Removes the 'canceled' state restriction in the portal controller. - Updates the portal template to show "View Document" instead of "Sign" for canceled requests, similar to the completed state. Task: 6034621
This update resolves an error that occurred when using the 'hr_expense_stripe' module with unsupported currencies like INR. The fix prevents the creation of a problematic journal entry, ensuring the invoicing dashboard can be opened without errors. It utilizes a fallback currency to ensure a valid currency is applied.
Original PR description
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to…
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. Steps to reproduce: (19.0) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` - Create New company > Set `Country` and `Currency` (eg: India and INR) > Switch to New company > Open `Invoicing` you will get the error. Steps to reproduce: (saas-19.1) - Install `account` module - Set Company currency to `INR` and deactivate `USD` in currencies. - Install `hr_expense_stripe` > Open `Invoicing` you will get the error. Traceback: `ValueError: Expected singleton: res.currency()` In this [PR], the behavior is such that if `company.stripe_currency_id` is not set, we do not create the "Stripe Issuing". In 19.0, `@template` was executed after the post-init hook, and we were preventing the creation of the [journal] at that stage. However, when a new company is created, the template data is automatically loaded for companies with a matching chart of accounts. As a result, the `stripe_issuing_journal` is created, which leads to the error. However, in saas-19.1, due to recent improvements in a [commit], the `@template` will now loads data for companies without post init hook. As a result, the `stripe_issuing_journal` is being created, and we are encountering an error. Solution: - The`Stripe Issuing` journal will no longer be created on installing the module. - For existing databases, we will use the company currency as a fallback value to ensure that a valid currency is applied. [PR]: https://github.com/odoo/enterprise/pull/96271 [journal]: https://github.com/odoo/enterprise/blob/fea009f98885a97439edfea75376b7323c8c9a03/hr_expense_stripe/models/res_company.py#L186-L187 [commit]: https://github.com/odoo/odoo/pull/228950/changes/21fd14ed5e8bdd2cf203d466069437a62a87f2bd sentry-7284934493
This update significantly speeds up the process of expanding project tasks to include users. Previously, a slow method triggered frequent database queries, impacting performance with a large number of tasks. The change now uses a more efficient search method, reducing task expansion time from 30 seconds to just 1.4 seconds for 300,000 tasks.
Original PR description
Before this commit, expanding the `user_ids` involved fetching all the tasks satisfying a domain by a search call and returning only the active users by accessing the field `user_ids` from the fetched recordset of tasks. This approach introduced slowness with a big number of `project.task` since for each batch of **1000** records, a `__get__` call on the field will trigger an `SQL` query. I have updated the code to have the inverse field `task_ids` in the `res.users` model and did the search, the other way around searching directly the `res.users` model. | Tasks | Before | After | | :--- | :--- | :--- | | 300K | 30s | 1.4s | opw-5942477