Friday, May 9, 2025
11 changes · 17.0
Resolved issues and error corrections
When an IoT device is disconnected from a database, it now clears display orientation, browser URL, and handler cache settings. This helps businesses switch between test or runbot databases more smoothly and prevents devices from getting stuck pointing to an unavailable customer display.
Original PR description
This PR adds the reset of: 1) screen orientation 2) browser_url 3) iot_handlers_etag when disconnecting a database This allows to switch between the different versions of the database more easily and avoid getting stuck with a non existent runbot db instance pos customer display for example
This fix replaces a confusing system traceback with a clear validation message when a required Swiss withholding tax institution is missing. Payroll users can now understand what setup information needs to be completed, reducing troubleshooting time and support requests.
Original PR description
Currently a traceback occurs if no QST instutions were defined, making it hard for users to understand where the error is coming from, in this PR we specify the missing institution.
Swiss payroll insurance screens now show the company linked to each insurance record. This helps businesses operating multiple companies set up the required separate insurance records more clearly and reduces confusion during payroll administration.
Original PR description
To ease multi-company usage, we introduce the company_id field on insurance views since one insurance per company has to be created
Miscellaneous changes
Steps to reporduce: - Make two orderlines that are cannot be merged with same product (add a comment, combo, etc ...) - Open the split bill screen - Selecet any of the orderlines and try to unselect it - Impossible to unselect the orderlines with same product but different line Fix: Calculate the line quantity selected based on the linked order line quantity and not the total number of same product in the order. Description of the issue/feature this PR addresses: Current behavior
Original PR description
Steps to reporduce: - Make two orderlines that are cannot be merged with same product (add a comment, combo, etc ...) - Open the split bill screen - Selecet any of the orderlines and try to unselect it - Impossible to unselect the orderlines with same product but different line Fix: Calculate the line quantity selected based on the linked order line quantity and not the total number of same product in the order. 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#208640
Steps to reproduce the problem: - Go to developer mode. - Select several invoices. - Press on Action > Resequence - Put a different sequence, and press Confirm. You get a message saying that the sequence is not unique, and all the sequences in the message appear as '/', being them the invoices we are trying to resequence. Explanation: On the resequence wizard, all the selected moves are being set to have '/' as name, and doing the flushing. https://github.com/odoo/odoo/blob/166a55
Original PR description
Steps to reproduce the problem:
- Go to developer mode.
- Select several invoices.
- Press on Action > Resequence
- Put a different sequence, and press Confirm.
You get a message saying that the sequence is not unique, and all the sequences in the message appear as '/', being them the invoices we are trying to resequence.
Explanation: On the resequence wizard, all the selected moves are being set to have '/' as name, and doing the flushing.
https://github.com/odoo/odoo/blob/166a55f159dca1fba29fe9b1aed2a923994a6672/addons/account/wizard/account_resequence.py#L154
After that, the Python check is triggering the problem.
On runbot, it's not directly reproducible while you don't uninstall `account_sequence` module, which nullifies the constraint.
The solution found is to exclude '/' from the check.
@Tecnativa
Forward-Port-Of: odoo/odoo#204574Since [1], the website visitor update in the login process uses the request's environment, which might not yet have the user in the cursor for auto-provisioning modules like LDAP, where the user is created in a different cursor. Steps to reproduce: 1. Install auth_ldap & website 2. Configure the website to have the correct domain 3. Configure the LDAP connection to create users 4. Logout and navigate to a website page (to create a visitor) 5. Login with an LDAP user -> traceback 6. Logi
Original PR description
Since [1], the website visitor update in the login process uses the request's environment, which might not yet have the user in the cursor for auto-provisioning modules like LDAP, where the user is created in a different cursor. Steps to reproduce: 1. Install auth_ldap & website 2. Configure the website to have the correct domain 3. Configure the LDAP connection to create users 4. Logout and navigate to a website page (to create a visitor) 5. Login with an LDAP user -> traceback 6. Login again -> works After this commit: As the website visitor is not business-critical, the visitor is not updated to ensure no deadlock is reintroduced. opw-4378487 cc @thle-odoo [1]: https://github.com/odoo/odoo/commit/b241cf7de9329af1410b9dd45b161aa41926effb Forward-Port-Of: odoo/odoo#203913
Before this patch, it was impossible to resequence vendor bills if already sent to SII/tbai. However, it is required to be able to resequence them, and the move name isn't sent anymore since https://github.com/odoo/odoo/pull/195113 was merged. Thus, here I'm lifting that constraint to allow accountants do the resequencing. @moduon MT-8728 OPW-4567144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197284
Original PR description
Before this patch, it was impossible to resequence vendor bills if already sent to SII/tbai. However, it is required to be able to resequence them, and the move name isn't sent anymore since https://github.com/odoo/odoo/pull/195113 was merged. Thus, here I'm lifting that constraint to allow accountants do the resequencing. @moduon MT-8728 OPW-4567144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197284
Description of the issue/feature this PR addresses: The "Quantities Available" field (shown in the product form vie smart button and the prognosis) can sometimes over-estimate the amounts actually available due to rounding. For example in the following case: Product-A is made via Kit-BoM from 2 Units of Product-B. There are 3 units of Product-B in stock. The precision of the "Unit" UoM, used for Product-A, is set to 1 (only integer amounts). The actual amount of units available is 1.5, this is
Original PR description
Description of the issue/feature this PR addresses: The "Quantities Available" field (shown in the product form vie smart button and the prognosis) can sometimes over-estimate the amounts actually…
Description of the issue/feature this PR addresses: The "Quantities Available" field (shown in the product form vie smart button and the prognosis) can sometimes over-estimate the amounts actually available due to rounding. For example in the following case: Product-A is made via Kit-BoM from 2 Units of Product-B. There are 3 units of Product-B in stock. The precision of the "Unit" UoM, used for Product-A, is set to 1 (only integer amounts). The actual amount of units available is 1.5, this is rounded as Half-Up to 2 Units. This is misleading, since only one unit of Product-A could be shipped. Current behavior before PR: For Kit-BoM Products, the quantities in _compute_quantities_dict() are all rounded with HALF-UP, potentially rounding up and claiming a higher availability than actually supported. Desired behavior after PR is merged: _compute_quantities_dict() rounds down to ensure it doesn't over-promise. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208374
When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3). However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing
Original PR description
When creating a record for any model that overrides `utm.source.mixin` and additionally passing default_name in the context, the `utm.source.mixin` model creates a UTM source record and handles duplicates by appending (2), (3). However, the name is removed from the values after source creation in the create method, the `default_get` function retrieves the `default_name` from the context. Since the field is related, it overwrites the source name with the name field of the mixin model, causing a unique constraint violation if the same name already exists. This PR removes `default_name` from the context. Task-3901336 Forward-Port-Of: odoo/odoo#208362
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#208890
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#208890
In this PR: ## [FIX] tools: don't export attributes that aren't translated anyway PR #162079 made the list of translated attributes shared between QWeb and OWL templates. In hindsight, this was not a good idea, since: - some attributes are exclusive to QWeb (e.g.: string) - t-attf- variants of attributes are not translated in OWL - it does not reflect the list of attributes that OWL actually translates ## [IMP] tools: add missing ARIA attributes to OWL_TRANSLATED_ATTRS https://github
Original PR description
In this PR: ## [FIX] tools: don't export attributes that aren't translated anyway PR #162079 made the list of translated attributes shared between QWeb and OWL templates. In hindsight, this was not a…
In this PR: ## [FIX] tools: don't export attributes that aren't translated anyway PR #162079 made the list of translated attributes shared between QWeb and OWL templates. In hindsight, this was not a good idea, since: - some attributes are exclusive to QWeb (e.g.: string) - t-attf- variants of attributes are not translated in OWL - it does not reflect the list of attributes that OWL actually translates ## [IMP] tools: add missing ARIA attributes to OWL_TRANSLATED_ATTRS https://github.com/odoo/owl/pull/1679 made human-readable ARIA attributes translated by Owl. This commit updates OWL_TRANSLATED_ATTRS so that ARIA attributes are also correctly exported for translation, and will therefore be fully translatable when the next version of Owl is released. ## [IMP] tools: make 'confirm-label' and 'cancel-label' translatable 'cancel-label' and 'confirm-label' are missing from the list of attributes to export for translation. This commit adds them to the list. Forward-Port-Of: odoo/odoo#204692