Daily updates from Odoo
Monday, March 23, 2026
15 changes
6 changes
Enhancements to existing features
This update aligns signature actions (request, resend, sign) within the Activity Popover with standard Chatter, providing a more consistent user experience. The changes also include technical improvements like syncing activity deadlines and preventing duplicate activity deletion, ensuring accurate and reliable signature workflows.
Original PR description
This PR brings feature parity to the signature Activity Popover by aligning its buttons with the standard Chatter, allowing users to request, resend, or sign documents directly from the popover. To achieve this cleanly, the PR also includes: - **Refactoring:** Moves shared signature logic (like `requestSignature`) into the `Activity` frontend model, eliminating duplicated JS code across UI components. - **Date Sync Fix:** Adds Python overrides to keep the `mail.activity` deadline perfectly synced with the `sign.request` validity date on creation and modification. - **Unlink activities Fix:** unlink activities on sign_request cancel and prevent double-delete error Task: 5989542
This update ensures that product SKUs (or default codes) are now included in product listings on the website. It also streamlines the variant display, allowing users to see newly created variants directly without the previous import-only issue. This improves product visibility and simplifies the process for users managing product variations.
Original PR description
An important change for the products to include the SKU (or default_code in Odoo) to the products. Also now set the variant setting on so that the user can see the variants created directly without having this confusing in-between where we import variants but they cannot see them. Forward-Port-Of: odoo/enterprise#111317
This update ensures that follow-up reminders are consistently sent to customers, even when a large volume of reminders are queued. The system now automatically re-triggers the reminder process if there are still outstanding reminders, preventing delays and improving customer communication. A configurable batch size allows users to optimize the process for their specific needs.
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 Forward-Port-Of: odoo/enterprise#110918
This update enhances the security and reliability of exporting large spreadsheet data from Odoo. It adds logging for key export actions like XLSX downloads and clipboard copies, and restricts access to frozen/XLSX downloads to authorized users. This ensures data integrity and protects sensitive information.
Original PR description
Forward-Port-Of: odoo/enterprise#109138 Forward-Port-Of: odoo/enterprise#85888
This update enhances the import of vendor bills by automatically extracting the vehicle's chassis number from XML files. This improves data accuracy and streamlines the process of associating vehicle information with invoices, particularly for businesses dealing with vehicle maintenance and parts.
Original PR description
[IMP] account_edi_ubl_cii: Import vehicle data from vendor bill xml This commit adds a path to read chassis number from vendor bill xml and adapt a bit the searching logic task-5979603
This update enhances the spreadsheet module by adding detailed logging when exporting large datasets, particularly during spreadsheet downloads, copy-pasting, and printing. It also restricts access to frozen or XLSX spreadsheets to authorized users, improving data security and control.
Original PR description
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#251345 Forward-Port-Of: odoo/odoo#210592
2 changes
Enhancements to existing features
This update ensures that follow-up reminders are consistently sent to customers, even when a large volume of reminders are queued. The system now automatically re-triggers the reminder process if there are still outstanding reminders, preventing delays and improving customer communication. A configurable batch size allows users to optimize the process for their specific needs.
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 Forward-Port-Of: odoo/enterprise#110918
This update allows HR staff to create leave entries for Swiss employees even when payroll impacts are present, offering greater flexibility in managing employee time off. The change relaxes previous restrictions based on payroll data, ensuring accurate leave tracking while accommodating various Swiss payroll scenarios. This improves the usability of the HR module for our Swiss clients.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
1 change
Enhancements to existing features
This update loosens restrictions on creating leave for employees with Swiss payroll, allowing leave entries even when payroll impacts are present under specific conditions. Previously, leave creation was blocked if a payslip was validated. Now, certain scenarios – primarily related to continued pay percentages – are permitted, improving flexibility for HR processes.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
4 changes
Enhancements to existing features
This update enhances the pay run workflow's user interface for better readability and ease of use. Changes include simplified data labels, adjusted table styles for clearer highlighting, and streamlined resource calendar names across various payroll localizations. These improvements aim to reduce confusion and improve the overall user experience.
Original PR description
Improvements to the pay run workflow UI. Change the table column names, highlight the entire cell instead of changing the text color, shorten the names of resource calendars for localisations. Task: 5979729
This update simplifies how tracking data is managed within Odoo, making it easier for developers to add tracking functionality to modules and ensuring consistent tracking behavior across the system. It focuses on reducing manual data manipulation and improving testability, ultimately leading to more reliable tracking information for reporting and analysis.
Original PR description
Main purposes * cover various use cases of tracking in addons. Several addons are doing manual calls to tracking API: '_mail_track' (generating tracking values), '_message_track' (generating valu and…
Main purposes * cover various use cases of tracking in addons. Several addons are doing manual calls to tracking API: '_mail_track' (generating tracking values), '_message_track' (generating valu and a tracking message) or calling 'message_post' or '_message_log' with tracking values manually generated. Logging on a parent model is also a frequen need (e.g. move line change on move, esg factor line changes on factor, ...). Those should be covered by tests to assess the behavior. * update tracking API to remove low-level data manipulation and use simpler methods. Addons should not have to manipulate tracking values in any form. * locate tracking code being currently both generic for BaseModel and specific to mail.thread in a middle-ground mixin. Specifications Test various use case of tracking, notably when doing manual calls to _message_track (which generates a tracking message), _mail_track (which generates tracking values, to be included in a message_post) or logging a message using either manually crafted tracking values or a rendered body looking like tracking values. Update docstring and arguments of tracking API. Add type annotations to ease understanding of the various structures used in code. Add a 'mail.track.mixin' mixin that allows to generate tracking values without depending on 'mail.thread'. It also allows to remove part of the code that was on BaseModel just for models not inheriting from 'mail.thread'. Thread now mainly adds the posting capabilities based on tracking. Update tracking API. Introduce '_track_add' when adding a manual tracking on some values. Introduce '_track_record' when sending the tracking values on another model (e.g. a parent for logging purpose). Fix various crashing code bits discovered when adding tracking tests. Note that most are going to be backported, hence may disappear from this PR at merge time. Youpie. Task-5935695 ([mail, various] Cleanup and test tracking usage) Prepares Task-3645865 ([mail] In-body tracking) Co-Authored-By: Prakash Prajapati <ppr@odoo.com>
This update ensures that product information in the website generator includes the product SKU (or default code), improving data accuracy and clarity. It also streamlines the variant display, allowing users to see newly created variants directly without needing to import them first.
Original PR description
An important change for the products to include the SKU (or default_code in Odoo) to the products. Also now set the variant setting on so that the user can see the variants created directly without having this confusing in-between where we import variants but they cannot see them. Forward-Port-Of: odoo/enterprise#111317
This update introduces the ability to generate images using AI through the Media Dialog, leveraging a state-of-the-art model for improved quality and speed. The changes also include bug fixes related to prompt handling and access controls, ensuring a more reliable and secure AI experience.
Original PR description
- Unify API of AI methods: including `_get_direct_response`, `_generate_next_response`, and `_generate_single_response` to accept and return parts. Parts represent a list of dicts where each dict has…
- Unify API of AI methods: including `_get_direct_response`, `_generate_next_response`, and `_generate_single_response` to accept and return parts. Parts represent a list of dicts where each dict has a type such as 'text' or 'inline_data' and a content dict.
- By returning structured AIMessageParts, the system can now support images alongside text.
- Allow image generation using AI from Media Dialog
- Introduce a tool to allow image generation using Gemini Nano Banana which is the state of the art model for image generation in terms of quality, speed and prompt adherence.
- Introduce logic inside `ai.attachment.vacuum` to remove unused AI generated images to avoid bloating the DB with large files.
- Duplicate some code from `ir.binary` into `image_tools` to be able to retrieve attachments from paths that have one of the forms:
- `/web/image/....` for attachments.
- `/<module_name>/static/...` for files from addons, for example
/ai/static/description/icon.png
- Introduce messages quick action buttons to perform the same save logic of the `MediaDialog` and `CustomMediaDialog` by passing the save method from the media dialog to the `discuss_channel`.
- Fix the following bugs:
- After https://github.com/odoo/enterprise/commit/2acc1178663d3607e96b64c17ea54f1f5c2e86f3, users have the ability to define prompts for ai.prompt.button records instead of using the name field as the prompt. However, the VoiceTranscription component wasn't updated to use the new prompt field.
- The _render_prompt method should return the 'name' of the 'ai.prompt.button' if no 'prompt' is defined or no rendering_record is passed to the method. However, this check didn't take into account that 'prompt' may contain empty HTML, for example `Markup(<p></p>)`.
- Accessing render_model field on 'ai.prompt.button' records raises AccessError for non-admin users.
- An error would occur if a public user (or portal) tried to chat with the AI using the live chat.
- The order of prompt buttons in the discuss channel/transcription component was arbitrary. Now, they are sorted based on their sequence.
- The composer retrieved by the TranscriptionComponent doesn't take the model of the current record into consideration.
- Composers should be retrieved based on the interface key and record_model but get_direct_response retrieved composers based on interface key only. While not a bug because the only usage of the endpoint (website_seo_ai composer) will always be opened from the SEO component on the website, the retrieval of composers should be consistent everywhere.
- Misc
- Move some utils from the `ai_fields` module into the `ai` module. The logic defined in `tools.py` in `ai_fields` is now used in the `ai` module. So, the logic is moved into the `ai` module as it is the base for other ai related modules. The code is moved into 'ai_fields_tools.py'.
- Previously, it was only possible to generate text using AI and AI actions such as 'Log as Note' and 'Send Message' only took text into account. Given that the AI now is capable of generating attachments i.e. images, the actions are updated to take the attachments into account.
task-51538461 change
Enhancements to existing features
This update enhances debugging capabilities by capturing detailed Chrome logs, particularly when crashes occur. Instead of generic error messages, developers now receive specific information about Chrome issues, like tab kills, which helps quickly identify and resolve stability problems. The logging level is configurable to balance detail with noise.
Original PR description
Followup and partial revert of #232612: turns out chrome's stderr is worthless at best and confusing at worst (because it logs a bunch of dbus errors which don't actually matter), however chrome…
Followup and partial revert of #232612: turns out chrome's stderr is worthless at best and confusing at worst (because it logs a bunch of dbus errors which don't actually matter), however chrome turns out to have pretty extensive debug logging facilities which are somewhat valuable: https://www.chromium.org/for-testers/enable-logging/
For instance if the oomkiller decides to nuke a chrome tab (example selected for no reason whatsoever), the debug log will have an entry along the lines of
[...:WARNING::chrome/browser/ui/sad_tab.cc:256] Tab Killed: http://127.0.0.1:8069/
which is a much more helpful hint than just being told a test timed out (to say nothing of being told that chrome was not able to do dbus stuff when we never asked for that).
Because it can be useful for all sort of debugging, this log is saved not just when chrome fails to start, but also when a Chrome completes, successfully or unsucessfully (in the latter case it's logged as RUNBOT to be available from the runbot UI).
The chrome logging facilities are controlled by a new envvar `ODOO_BROWSER_LOG_VERBOSITY`, it can be set to `-1` to disable logging, or a strictly positive integer for ever increasing amounts of logging. At `1` chrome will log every network request it attempts which can be useful for debugging some races but is already extremely noisy.
Forward-Port-Of: odoo/odoo#255117
Forward-Port-Of: odoo/odoo#2550541 change
Enhancements to existing features
This update enhances Odoo's debugging capabilities by capturing detailed Chrome logs, particularly when Chrome tabs unexpectedly terminate. These logs provide more specific information than previous error messages, aiding in identifying and resolving stability issues. Administrators can control the level of logging through a new environment variable.
Original PR description
Followup and partial revert of #232612: turns out chrome's stderr is worthless at best and confusing at worst (because it logs a bunch of dbus errors which don't actually matter), however chrome…
Followup and partial revert of #232612: turns out chrome's stderr is worthless at best and confusing at worst (because it logs a bunch of dbus errors which don't actually matter), however chrome turns out to have pretty extensive debug logging facilities which are somewhat valuable: https://www.chromium.org/for-testers/enable-logging/
For instance if the oomkiller decides to nuke a chrome tab (example selected for no reason whatsoever), the debug log will have an entry along the lines of
[...:WARNING::chrome/browser/ui/sad_tab.cc:256] Tab Killed: http://127.0.0.1:8069/
which is a much more helpful hint than just being told a test timed out (to say nothing of being told that chrome was not able to do dbus stuff when we never asked for that).
Because it can be useful for all sort of debugging, this log is saved not just when chrome fails to start, but also when a Chrome completes, successfully or unsucessfully (in the latter case it's logged as RUNBOT to be available from the runbot UI).
The chrome logging facilities are controlled by a new envvar `ODOO_BROWSER_LOG_VERBOSITY`, it can be set to `-1` to disable logging, or a strictly positive integer for ever increasing amounts of logging. At `1` chrome will log every network request it attempts which can be useful for debugging some races but is already extremely noisy.
Forward-Port-Of: odoo/odoo#255054