Daily updates from Odoo
Wednesday, December 3, 2025
11 changes
1 change
Enhancements to existing features
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key partner data changes. A new feature has been added for Belgium, leveraging the VAT number to automatically identify the Peppol identifier, streamlining data entry and validation.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. task: 5172378 Forward-Port-Of: odoo/odoo#238251 Forward-Port-Of: odoo/odoo#233160
6 changes
Enhancements to existing features
This update simplifies website creation by grouping options into a dropdown menu for a cleaner user interface. Additionally, the website generator now automatically creates a website immediately upon request, preventing unnecessary and potentially problematic creations. This change improves the overall user experience and reliability of website setup.
Original PR description
Added a new dropdown to group the two options of creating or importing a website into a more elegant UI. Also changed the behavior of the website generator so that it creates the website on reception of the request. This avoids potentially making a useless one in case of an error or the user exiting the view.
This update adapts the US payroll system (l10n_us_hr_payroll) to a new flexible benefits structure based on salary rules, introduced in Odoo 19.0. This change streamlines benefit calculations and aligns with updated payroll regulations for US businesses.
Original PR description
In 19.0 a new system of flexible benefits coming from salary rules was introduced. This commit serves to adapt the l10n for the united states to the new format. task-5122330
This update enhances the user interface for selecting online accounts within the Odoo Enterprise system. The previous radio button component was removed, streamlining the selection process and improving usability. This change focuses on a better user experience for managing online accounts.
Original PR description
This commit refactor the online account selection widget to have a better ui. task-5090281
This update has consolidated salary-related information from the `hr_recruitment_integration_base` module into the `hr_recruitment` module. This change streamlines the recruitment process and improves data organization within Odoo, enhancing the overall user experience.
Original PR description
In this PR we have moved salary related fields from `hr_recruitment_integration_base` to `hr_recruitment` module Task-5212975
This update allows users to search for achievements more efficiently by searching using the name of the related record. This change simplifies finding specific achievements linked to other records, leading to a better user experience and reduced search times. It's a key improvement for sales and reporting workflows.
Original PR description
Before: - Users could not search for achievements using the name of the related record in the achievement search view. After: - Users can now search for achievements using the related record’s name, making it easier and faster to find the desired records. Impact: - Improves user experience in the achievement search view. - Saves time when looking for records linked to specific related items. task-5176601
This update significantly speeds up the calculation of complex reports by optimizing how aggregations are processed. The system now intelligently prioritizes calculations based on data availability, reducing processing times from 20 seconds to less than 1 second. This enhancement improves report generation performance and overall system responsiveness.
Original PR description
(aka MAGA: Make Aggregations Great Again) When a report contained many aggregations to evaluate, with complex interdependencies, the way the computation was done was to naïve. This happened with a…
(aka MAGA: Make Aggregations Great Again) When a report contained many aggregations to evaluate, with complex interdependencies, the way the computation was done was to naïve. This happened with a new Japanese report we're currently implementing, which contains multiple sections referencing each other with cross_report aggregations. Basically, we used to make a queue of all aggregations to evaluate, pop the first one, try to evaluate it, and if it was still missing some data, enqueue it back. We kept on looping like that until every formula got evaluated. On the (extreme) case we faced, it took 20 seconds just to compute aggregations on a database with only demo data ! We solve this by rewriting the aggregation engine in such a way that it only tries to evaluate the expressions it has enough data to compute. Essentially, we now keep track of the number of dependencies to other aggregations that still need to be resolved before being able to evalutate a formula, and we only evalute the ones whose associated count is 0. On our test example with the Japanese report on a db with only demo data, the computation of aggregations went from 20 seconds to less than 1 with this commit. To make this refactoring possible, some restrictions needed to be added to cross_report aggregations: 1) By default, a cross_report aggregation does not force its date_scope to the terms it calls anymore. This was only done for Balance Sheets calling the P&L, and induced a LOT of complexity, and the possibility of many unintended corner cases, some of which working purely by chance, some others simply breaking, none of which seeing any actual use in the standard data. I it still possible to force the date_scope for an aggregation really needing to do so, but it needs to be specifically asked in the subformula. The syntax for that is now: cross_report(report_id, force_date_scope). When a cross_report aggregation is to be evaluated without forced date scope, it will use the date scope of each of its terms, just as if all those expressions had been part of the current report. On top of the technical benefits, it's also functionally clearer for the users customizing reports by hand. 2) cross_report aggregations with a forced date_scope do not allow referencing other cross_report aggregations anymore. Doing that would allow for triangle dependencies between reports, and proper propagation of the forced date scopes would require additional complexity that we don't want. We now prevent this with a constraint. None of the standard report needed to be adapted ; if some custom-made report fails because of this change, it's anyway possible to reference directly the expression(s) they want instead of counting on an additional indirection. task-5243334
3 changes
Enhancements to existing features
This update ensures that invoices for B2G transactions in Germany comply with local regulations. It adds a mandatory 'Leitweg-ID' to the UBL invoice format, correctly directing invoices to the appropriate government entity. This improves compliance and accuracy for German accounting processes.
Original PR description
*= l10n_account_edi_ubl_cii_tests For B2G transactions in Germany, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. Adding this Leitweg-ID for the UBL syntax. task-5194484 Description of the issue/feature this PR addresses: For electronic invoicing in Germany, for B2G transactions, the Leitweg-ID is a mandatory routing identifier to direct the invoice to the correct public entity. We want to add this identifier for the XRechnung format. Current behavior before PR: The Leitweg-ID is not present in the UBL xml format. Desired behavior after PR is merged: The Leitweg-ID is added in the header of the invoice in the cbc:BuyerReference tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238255 Forward-Port-Of: odoo/odoo#236333
This update enhances the Odoo call menu by adding mute and deafen controls, improving the user experience for calls. The visual design of the call menu has also been updated for a cleaner and more modern look. This change provides a more intuitive and effective way to manage calls within Odoo.
Original PR description
Currently, there is no way that we can deafen or mute in call menu directly. This commit adds mute and deafen button in call menu for better user experience. Also, adjust the call menu UI for better visual effect. task-5262772 before: <img width="260" height="51" alt="image" src="https://github.com/user-attachments/assets/206b3b3d-cafa-492f-95ed-db8075f16298" /> after:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key partner data changes. A new feature has been added specifically for Belgium, leveraging the VAT number to automatically populate the Peppol identifier through the company registry endpoint, streamlining data entry and validation.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. task: 5172378 Forward-Port-Of: odoo/odoo#238251 Forward-Port-Of: odoo/odoo#233160
1 change
Enhancements to existing features
This update enhances the system's ability to access information related to signed documents (o2m relationships). Previously, limitations prevented developers from leveraging these relationships, now they can be customized, allowing for more comprehensive sign management. This improves the flexibility and functionality of our sign workflows.
Original PR description
The class `SignerX2Many` is inheritable, but if we need another value from the o2m, we can't use it because the `signerX2Many` is not exportable. Enable `signerX2Many` customization, allowing more fields to be read from the `sign.send.request.signer` model.