Monday, March 2, 2026
6 changes · saas-18.2
Resolved issues and error corrections
Users who finish a chatbot conversation will no longer see an unnecessary warning when closing or continuing after the conversation has already ended. This reduces confusion by showing the leave warning only when a live chat is still active.
Original PR description
Before this commit: When a user finishes a chatbot script and the conversation is already ended, clicking on close / continue still triggers the leave conversation warning. After this commit: The leave conversation warning is no longer shown when the chatbot conversation is already closed or ended. The warning is only shown for active conversations. [Task-5882084](https://www.odoo.com/odoo/project/1519/tasks/5882084) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247918
This update prevents live chat from depending on a newer browser feature that is not available in this Odoo version. It helps ensure visitor chats are created reliably without duplicate conversations or failures caused by missing support.
Original PR description
In [1], the live chat service uses `Promise.resolvers` to avoid duplicated chat creation. However, there is no polyfill in this version. It's better to stick to the `Deferred` class. [1]: https://github.com/odoo/odoo/pull/250374 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 Forward-Port-Of: odoo/odoo#250877
When users add a subtask from the project Kanban view, it now appears after existing subtasks instead of jumping to the top. This keeps the task list in a more natural creation order and reduces confusion when tracking work.
Original PR description
### Steps to reproduce: - Create a project and a task in this project - Create a subtask for the created task - Go for the kanban view and add another subtask - Notice the last created subtask is on the top of the list ### Cause: This is happening as we show the list of the subtasks as it is without sorting it. ### Fix: We sort the closedList for subtasks ascendingly according to their IDs opw-5943741 Forward-Port-Of: odoo/odoo#250447
The Bulgarian localization now uses corrected tax names and sets the standard default purchase tax to the appropriate 20% FTC option. This helps businesses using Bulgarian accounting avoid mislabeled taxes and more reliably apply the right purchase tax by default.
Original PR description
Fixing incorrect tax names and changing the default purchase tax to 20% FTC instead of 20% PTC. task-5935754 Forward-Port-Of: odoo/odoo#250130 Forward-Port-Of: odoo/odoo#249269
This update resolves an issue where HR document sharing links wouldn't work for employees without a user account. The fix ensures that documents can be shared correctly, even when an employee leaves the company, streamlining the offboarding process.
Original PR description
purpose: when an employee leaves the company, it's expected to send the HR Documents Access Link. But, an error occurs if the employee is not linked to a user. fix: - made the error appear only when the employee doesn't have a private email and not depend on the employee being linked to a user - made the documents check for `work_contact_id` to get the partner related to the employee instead of `user_partner_id` task-id: 5876084 Forward-Port-Of: odoo/enterprise#105652
The Activity Logs report was incorrectly appearing in the Sign Template list view, causing errors. This fix corrects a misconfiguration in the report's model settings, ensuring it now displays correctly within the Sign Request view. This improves report accessibility and prevents technical errors.
Original PR description
Version: - saas-18.2 Issue: - The "Activity Logs" report was showing in the Sign Template list view. When clicking it, a traceback occurred because the report tried to read a `sign.request` record from a `sign.template` context. Cause: - The report model was set to `sign.request`, but the`binding_model_id` was set to `model_sign_template`. - This mismatch caused the report to appear in the wrong place. Solution: - Updated the `binding_model_id` to `model_sign_request` so the report now appears in the Sign Request view, which matches the report model and prevents the error. task-5984137