Thursday, June 12, 2025
7 changes · saas-18.3
Resolved issues and error corrections
The VoIP keypad search now handles contacts whose names are blank or otherwise missing without causing an error. This prevents interruptions when users search for phone contacts and improves reliability for edge-case contact data.
Original PR description
This commit fixes a bug that happens when the partner name is a falsy value like a `" "`. This made the `t9_name` to be `false` and then to give an error when trying to access the `trim()` function. A solution for this was to guard it with a condition to check if the t9_name is falsy or not.
This fix ensures Brazilian tax IDs are sent in the format Avatax expects when creating accounts, preventing setup failures caused by automatic formatting changes. Electronic invoice and point-of-sale tax integrations continue using the compact format required for their API calls.
Original PR description
Since [^1] VAT values are automatically compacted to the smallest form without any dots and dashes. For account creation in Avatax we must uncompress the VAT before sending to the API. Funny enough, Avatax requires compacted values for EDI api calls, as such the compression code will be removed in master. task-4817278 [^1]: https://github.com/odoo/odoo/pull/179078
A stability issue in the Belgian Codabox connection setup was fixed so new setup records no longer trigger an error when company VAT details are missing. This helps keep automated checks and setup flows reliable, especially for companies that have not yet filled in all registration information.
Original PR description
The test `test_computed_fields_without_dependencies` triggers all compute methods on new records (model.new()).
In `_compute_company_vat`, we had:
`re.sub(r'[^0-9]', '', wizard.company_id.vat or wizard.company_id.company_registry)`
When running on a new record, both `vat` and `company_registry` are `False`, so:
`re.sub(..., False)`
This causes `TypeError: expected string or bytes-like object, got 'bool'`.
We fix this by explicitly passing a string fallback.
[runbot-164199](https://runbot.odoo.com/odoo/error/164199)Emission factors no longer need to be tied to a specific company, making it easier to use shared factor databases across multi-company setups. This prevents duplicate imports and reduces confusion when sources appear to have no linked factors because of company restrictions. The change applies to new databases or after an upgrade.
Original PR description
Having a mandatory company on factors comes with multiple problems. The main one is that users rely on factors imported from huge databases, that would therefore have to be imported once per company. The current dabatase model is incidentally built around factors being available in all companies, which means one cannot actually import the factors multiple times. Another is that users could see sources (which are not company dependent) that are seemingly linked to no factors because they are in other companies, which can be confusing. To alleviate those problems, this PR makes the field non required. Note that this will only take effect for new databases or after an upgrade.
Fixes an error that appeared when users opened the Details view for sales commissions. This restores access to commission breakdowns by removing a reference to outdated data that no longer exists.
Original PR description
When user clicks on Details in the commissions, A traceback will appear. Steps to reproduce the error: - Install ``sale_commission`` with demo data - Go to Sales > Commissions > My Commissions - Click on ``Details`` of any record Traceback: ``` UndefinedColumn: column "team_id" does not exist LINE 21: AND team_id in (1) ``` ``team_id`` field was removed in the commit: https://github.com/odoo/enterprise/commit/b1e41f9b23aa62bfd6f9be1feb1059b3507f2ce5 https://github.com/odoo/enterprise/blob/9d3a15d4d38fce8a2746778146c58123bc09178d/sale_commission/report/achievement_report.py#L341 Here, ``team_id`` field is still used. ``sale.commission.achievement`` model does not ``team_id`` field. So, It will lead to the above traceback. sentry-6378493886
This update corrects migrated Luxembourg and Canada financial report definitions that could fail to open after a syntax change. It removes outdated internal settings that were no longer needed, helping affected reports load reliably in version 18.3.
Original PR description
Some aggregation expressions used to have 'cross_report' as subformula. Though, it was useless (since the aggregation only uses terms from the same report), and the subformula was removed from the data file without explicitly resetting it to False. This became a problem in 18.3, because the cross_report syntax changes. Because of that, a migrated report failed to open, since it still was using the old syntax on that expression. We fix that by explicitly emptying the subformula. This was done in https://github.com/odoo/odoo/commit/bbba54a08c56e0a4d040fc8035996d9d7cafedad for the monthly Luxembourgish tax report ; but some other occurrences needed to be fixed.
Using a Sign template layout on a new document now keeps grouped radio button choices connected. This preserves the expected single-choice behavior for signers and prevents copied template fields from becoming unusable.
Original PR description
_____________________________________________________ ## Short functional explanation of the error Using the layout of a template document, containing radio buttons, on a new document will unlink…
_____________________________________________________ ## Short functional explanation of the error Using the layout of a template document, containing radio buttons, on a new document will unlink radio buttons, making them useless. ## Reproduction Steps 1. Go to the Sign module, and click on the Templates tab. 2. Click on the "Upload PDF" purple button, and upload a PDF of your choice. 3. On the left side of the screen, there's a panel where we can drag and drop sign items. Drag and drop a Radio button. 2 buttons will automatically show, and a yellow link will appear between the buttons. This link indicates that, when a user opens the document to sign, when clicking on a radio button, the other one will automatically be unselected if previously selected. 4. Save and return to the Templates window. 5. A new row has appeared with the name of the document. On the right side of this row, hover the house next to the share button and click on the 3 dots. Then, click on Use Layout. 6. Upload a PDF of your choice. 7. When the PDF shows, there's no yellow link between the radio buttons, unlike on the template from which the layout was used. ## Causes of the problem In the file sign/models/sign_document.py, in the method _copy_sign_items_to(self, new_document), we copy every sign item from the template to the new document. However, the copy method we call doesn't take into consideration the special link between radio buttons, replicating the buttons correctly but not the link. This link is expressed by the radio set to which the radio buttons belong: indeed, after the copy of sign items, each radio button belongs to a different radio set, separating them. ## Explanation of the fix The fix consists of a rework of the _copy_sign_items_to method and a brand-new method specifically used to copy radio buttons. To keep the link between them, we assign all the buttons of the same set on the original documents to the same brand new radio set. The first button is copied normally: this creates a new radio set. Then, for the remaining buttons, we call copy_radio_item, to which we pass the button created first to use the information the next buttons will share with it. ______________________________________________________________ opw-4842590 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr