Daily updates from Odoo
Wednesday, March 25, 2026
12 changes
3 changes
Enhancements to existing features
This update enhances the Project Side Panel by allowing more detailed budget information to be displayed. By enabling inheritance of a key method, the system now includes a broader range of budget items, providing project managers with a more complete financial overview. This improves decision-making related to project costs.
Original PR description
Enabling the inheritance of the method _get_budget_items to include more budget information, by adding a method for the budget items domain. Forward-Port-Of: odoo/enterprise#107466
This update adapts the French accounting import process to changes in how data is delivered from the system. Instead of downloading entire files, data is now streamed, improving efficiency and reducing download times. This ensures accurate and timely reporting for French-speaking customers.
Original PR description
This commit aims to adapt the usage of 'account.fr.fec' to the changes made in community. In particular `fec_data` field is not used any more. and we use `_get_fec_stream` to stream the content of the file. task-5404142 Forward-Port-Of: odoo/enterprise#111153 Forward-Port-Of: odoo/enterprise#102783
This update enhances debugging of Odoo's Chrome browser integration by capturing detailed logs when Chrome encounters issues, such as tab terminations. These logs provide more specific information than previous methods, aiding in identifying and resolving stability problems. The logging level can be adjusted for control and noise reduction.
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#255548
Forward-Port-Of: odoo/odoo#2550543 changes
Enhancements to existing features
This update improves the Project Side Panel by allowing more budget details to be displayed. Specifically, it enables inheritance to include additional budget information, enhancing the visibility of project financial data. This change provides greater insight into project spending.
Original PR description
Enabling the inheritance of the method _get_budget_items to include more budget information, by adding a method for the budget items domain. Forward-Port-Of: odoo/enterprise#107466
This update enhances debugging of Chrome within Odoo by capturing detailed logs when Chrome encounters issues, such as tab terminations. These logs provide more specific information than previous methods, aiding in identifying and resolving stability problems. 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#255548
Forward-Port-Of: odoo/odoo#255054This update streamlines the process for generating IoT driver tokens in Egypt. Previously, a modal prompted users for tokens, which was found to be unnecessary for this region. Now, tokens are automatically generated and stored in the database, improving efficiency and user experience.
Original PR description
Proxy token generation was removed to avoid showing a modal with a token nobody cares about except Egypt. We reintroduce token generation, but send it to the database instead of showing a modal. see odoo/enterprise#111496 Forward-Port-Of: odoo/odoo#255121
3 changes
Enhancements to existing features
This update adds a new system for calculating and managing professional tax deductions for employees in Russia. The change combines existing logic for LWF deductions and introduces flexible payment cycles (monthly, quarterly, etc.) to simplify tax processing and improve accuracy. This enhancement ensures compliance with Russian tax regulations.
Original PR description
[IMP] l10n_in_hr_payroll: professional tax deduction cycle
1 - New deduction cycle field is added for professional tax (monthly, quarterly, half_yearly, yearly)
1.1 - It is added form view of employee just below of Professional Tax in Tax Deductions
2 - There was a written logic for LWF deductions in the code already _l10n_in_apply_lwf.
2.1 - Since the logic was almost same, I combined both professional tax deduction and lwf tax deduction and made a small refactor.
task - 4978408This update improves the speed and reliability of refreshing social media data (Facebook and Instagram) by using batch API requests. It also ensures consistent engagement trend calculations across platforms, leading to more accurate reporting and a better user experience. The changes focus on efficiency and data accuracy.
Original PR description
Purpose ======= The Meta API supports batch requests: > https://developers.facebook.com/docs/graph-api/batch-requests This can reduce a lot the HTTP calls we make, and makes the module faster to…
Purpose ======= The Meta API supports batch requests: > https://developers.facebook.com/docs/graph-api/batch-requests This can reduce a lot the HTTP calls we make, and makes the module faster to refresh. We could have been way more aggressive in the optimization (eg, fetch the stats and the posts at the same time), but it will deteriorate the readability, so we just batched API calls in loop, and stuff like that. Time of a refresh for 6 Facebook pages and 1 Instagram page: <img width="881" height="71" alt="a" src="https://github.com/user-attachments/assets/ec319c4a-c51d-49b8-a6ab-3ee879cf63b4" /> After: <img width="886" height="103" alt="b" src="https://github.com/user-attachments/assets/0b707b72-f30f-4e00-a38c-614feea6e204" /> Use `total_interactions` instead of `reach` for the engagement trend of Instagram. Show the view and saved statistic for Instagram. Do misc UI improvement. Fix an inconsistency for the engagement trend computation between Facebook and Instagram. Task-4865381
This update simplifies the tracking of materials within MRP components by removing unnecessary packaging fields from the SML form. These fields were previously visible but are not used when components are consumed unpacked, preventing user confusion and ensuring data accuracy. This change improves the user experience and data integrity.
Original PR description
Hide the `Destination Package` and `Destination Container Package` fields in the SML form for MO components in the Barcode app, as they are always consumed unpacked. Keeping these fields visible can mislead users into entering information with no functional meaning. Community PR:- odoo/odoo#243072 TaskID-4068485
2 changes
Enhancements to existing features
This update automatically updates the DGI (Uruguayan tax authority) state for stock pickings, ensuring compliance with local regulations. When a picking is rejected by the DGI, the system now logs the issue and notifies users for manual review, improving accuracy and reducing manual effort.
Original PR description
This pull request introduces an automated process to periodically update the DGI (Dirección General Impositiva) state for Uruguayan electronic stock pickings, along with improvements to error…
This pull request introduces an automated process to periodically update the DGI (Dirección General Impositiva) state for Uruguayan electronic stock pickings, along with improvements to error handling and logging when a picking is rejected. The main changes are the addition of a scheduled cron job, enhanced logging, and user notifications for rejected pickings. **Automated DGI State Updates:** * Added a new scheduled cron job (`ir_cron_update_dgi_state_pickings`) that runs every 10 minutes to update the DGI state of stock pickings with electronic documents in the "received" state. (`l10n_uy_edi_stock/data/ir_cron.xml`, `l10n_uy_edi_stock/__manifest__.py`) [[1]](diffhunk://#diff-36f19bab7c2edeb0f43a1db1639b72e8508deed19652e0b1142ebfce688b9d3eR1-R11) [[2]](diffhunk://#diff-370a6cfd5890d6504958deb4a225d69ec84e84fa59deeeb52c96a849f3fdfc22R14) * Implemented the `_l10n_uy_edi_stock_cron_update_dgi_state` method in `stock_picking.py` to process batches of pickings and trigger itself again if more records remain. (`l10n_uy_edi_stock/models/stock_picking.py`) **Error Handling and Notifications:** * Enhanced the `l10n_uy_edi_action_update_dgi_state` method to log rejected pickings and post a message in the chatter to notify users when a picking has been rejected by DGI, prompting manual review and correction. (`l10n_uy_edi_stock/models/stock_picking.py`) * Introduced logging setup for the module to support the new logging functionality. (`l10n_uy_edi_stock/models/stock_picking.py`) [[1]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R2) [[2]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R14)
This update enables users to efficiently manage database tags by allowing them to apply one or multiple tags to several databases simultaneously. This streamlines the process of organizing and categorizing databases, improving operational efficiency. It simplifies a previously manual and time-consuming task.
Original PR description
The aim of this commit is to allow users to mass edit the list of database to add one or several tag on several dbs at once. task-id: 6046088
1 change
Enhancements to existing features
This update ensures that invoice tax information displays the correct label, aligning with the tax's defined 'invoice_label' field. This is particularly important for accurate tax reporting in different regions where invoice labels may not match internal tax names. The change improves the clarity and accuracy of invoices.
Original PR description
When computing taxes for invoice lines, the system should use the `invoice_label` field instead of the default `name` field to display tax information. This allows invoices to show more appropriate…
When computing taxes for invoice lines, the system should use the `invoice_label` field instead of the default `name` field to display tax information. This allows invoices to show more appropriate tax labels that may differ from the internal tax name. Technical details: - Added `is_invoice` context when calling `tax_ids.compute_all()` in `account.move.line._compute_all_tax()` method - Modified `account.tax.compute_all()` to check for `is_invoice` context and select appropriate field name (`invoice_label` for invoices, `name` for other documents) - The selected field name is used when building the tax values dictionary returned by `compute_all()` This change ensures that invoice tax lines display the correct label as defined in the tax's `invoice_label` field, which is particularly useful for localized tax reporting requirements where the invoice label may differ from the internal tax name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236497