Monday, February 17, 2025
13 changes · saas-17.4
Resolved issues and error corrections
The invoice screen now shows the FACe/Factura-e section only when the related company is located in Spain. This avoids confusing or irrelevant Spanish e-invoicing fields for companies in other countries.
Original PR description
We should only show the FACe/Factura-e section on invoice when the related company is located in Spain. opw-4397651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now archive an inherited view from the main view screen without preventing the main record from being saved. This avoids a workflow interruption for administrators managing technical views in Odoo.
Original PR description
Before this commit, when archiving an inheriting view from a main one (via the list and the form), the main record was not savable. This is due to 6f06420e4a9443c52dc0cb427f8f55eb4aecabce which automatically adds missing but useful fields in a view in readonly mode. This commit adds that field manually to be able to save the active field. opw-4534225 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
This fix allows empty view modifier expressions to be treated safely instead of causing validation errors. It helps upgrades to newer Odoo versions proceed smoothly when placeholder expressions exist in custom or existing views.
Original PR description
When the modifier is empty we don't get any error in the fronted. It's just assumed as `False`. Since 6f06420e we have a new mechanism that adds fields to views as long as they are used in an modifier's expression. This unfortunately fails with a syntax error if the expression is empty. OTOH having an empty expression could be useful for development as a placeholder for further changes. The presence of empty expressions causes issues during the upgrade from <17.4 to higher versions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Embedded actions no longer fail when their filter setting is intentionally left empty. This prevents errors for users opening those embedded actions and keeps the default behavior as an empty filter.
Original PR description
Steps:
- Set domain of an embedded action to false
- this override the default value
- Try to use the embedded action
Actual result:
- Error due to invalid domain
Expected result:
- Embedded action work and use empty domain as default
opw-4529210
opw-4563505This fix prevents incoming payments that require a partner bank account from also requiring that bank account to be approved for outgoing payments. It avoids confusion and payment setup issues for Italian RiBa payments, where money is received rather than sent.
Original PR description
The require_partner_bank_account flag on the payment shouldn't require the allow_out_payment flag on it when the payment type is inbound as it leads to confusion. This generates an issue with the l10n_it_riba RiBa payment method. It requires the bank account, but the money is incoming, not outgoing. Community PR: odoo/odoo#197141 Old Enterprise PR: odoo/enterprise#77901 Task [link](https://www.odoo.com/odoo/project/967/tasks/) task-4497749
Miscellaneous changes
Handling special tax amount across different tax groups was not done correctly before this commit. task-4536450 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196263
Original PR description
Handling special tax amount across different tax groups was not done correctly before this commit. task-4536450 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196263
Certain nondeterministic JS tests can be more easily reproducible if the browser CPU is throttled. For example: rd-112019 https://github.com/odoo/odoo/pull/196980 Chrome does allow CPU throttling using the command: https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setCPUThrottlingRate An environment variable can also be used to ease the usage in a given dedicated environment. task-4559442 Forward-Port-Of: odoo/odoo#197640 Forward-Port-Of: odoo/odoo#197007
Original PR description
Certain nondeterministic JS tests can be more easily reproducible if the browser CPU is throttled. For example: rd-112019 https://github.com/odoo/odoo/pull/196980 Chrome does allow CPU throttling using the command: https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setCPUThrottlingRate An environment variable can also be used to ease the usage in a given dedicated environment. task-4559442 Forward-Port-Of: odoo/odoo#197640 Forward-Port-Of: odoo/odoo#197007
### Issue: The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive quantity for that package. ### Steps to reproduce (issue in barcode): - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable product - Update the on hand quantity: - 10 units in package PK in WH/STOCK - Inventory > Configuration > Warehouse Management > L
Original PR description
### Issue: The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive…
### Issue:
The curent compute method of the location_id field of quant packages is not accurate as it is currently set to the first existing quant and not to the only existing quant with a positive quantity for that package.
### Steps to reproduce (issue in barcode):
- In the settings enable: Multi-Step Routes, Operations > Packages
- Create a storable product
- Update the on hand quantity:
- 10 units in package PK in WH/STOCK
- Inventory > Configuration > Warehouse Management > Locations
- Create 2 warehouse locations: WH/LOC1, WH/LOC2
- Go to the barcode app and proceed with the scans: i. Scan the internal transfer picking type ii. Scan WH/STOCK as a source location iii. Scan the package name (PK) iv. Scan WH/LOC1 as destination location
- Leave the barcode app without validation
- Go to the barcode app and proceed with the scans: i -> iii, iv'. Scan WH/LOC2 as destination location
- Validate the picking
- Proceed an other picking via the barcode app to follow up: i. Scan the internal transfer picking type ii. Scan WH/LOC2 as a source location iii. Scan the package name (PK)
#### > the package is not found and added. You rather trigger a notification: no package You are expected to scan one or more products or a package available at the picking location
### Cause of the issue:
After the picking validation, the location_id of the package should havebeen updated to WH/LOC2 but it is still WH/Stock since you have a reserved quantity on that quant and it was not cleaned:
https://github.com/odoo/odoo/blob/081215d1220d6a362087aa33c304a452893b1dca/addons/stock/models/stock_quant.py#L1482-L1490
opw-4574169
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#197735- update the `co2_fee_min, health_indice` paramters values Task: 4563950 Forward-Port-Of: odoo/enterprise#78999
Original PR description
- update the `co2_fee_min, health_indice` paramters values Task: 4563950 Forward-Port-Of: odoo/enterprise#78999
steps to reproduce: - Install the module approvals_purchase - As admin user - go to approvals - create a new approval for RFQ request - attribute the approval to an user without any access rights - put yourself as the approver - submit and validate the approval - click on the button Create RFQ's - create the RFQ - logout and connect as the user without access rights - try to access your approval -> Access Error related infos: first appeared with: https://github.com/odoo/enterprise
Original PR description
steps to reproduce: - Install the module approvals_purchase - As admin user - go to approvals - create a new approval for RFQ request - attribute the approval to an user without any access rights -…
steps to reproduce: - Install the module approvals_purchase - As admin user - go to approvals - create a new approval for RFQ request - attribute the approval to an user without any access rights - put yourself as the approver - submit and validate the approval - click on the button Create RFQ's - create the RFQ - logout and connect as the user without access rights - try to access your approval -> Access Error related infos: first appeared with: https://github.com/odoo/enterprise/commit/4220723e0779287e5a8e301553e1a870cd3c4ca5 in task: 2040710 Reason: No group where set on the button 'Purchase Orders' which is used to access the RFQ from the approval this button needs a protected field to be able to be displaed properly in addition to that no default value was set if the user has no rights to read the 'purchase.order.line' model. Expected behavior: The button should not be displayed if the user has no access rights to the RFQ and thus grand access to the approval of the user FIX add a default value if the user has no read rights on the model 'purchase.order.line' ultimatly making everything related to it in the form view invisible Also add a group to it in the view to permit to remove the default value in master task-3561514 Forward-Port-Of: odoo/enterprise#79098 Forward-Port-Of: odoo/enterprise#78275
Before this commit, the context of the action was just ignored in the grid view and so the default values stored inside that context are not taken into account during `grid_update_cell` method. Steps to reproduce the issue ---------------------------- 0. Install timesheet_grid module 1. Open Employees app 2. Click on an employee to open the form view 3. Click on the timesheets smart button to view the timesheet grid view for that employee 4. Navigate to a week that already contains hour
Original PR description
Before this commit, the context of the action was just ignored in the grid view and so the default values stored inside that context are not taken into account during `grid_update_cell` method. Steps…
Before this commit, the context of the action was just ignored in the grid view and so the default values stored inside that context are not taken into account during `grid_update_cell` method. Steps to reproduce the issue ---------------------------- 0. Install timesheet_grid module 1. Open Employees app 2. Click on an employee to open the form view 3. Click on the timesheets smart button to view the timesheet grid view for that employee 4. Navigate to a week that already contains hours for the current user 5. Update the grid cell containing a timesheet to reduce the number of hours for instance 6. Update another cell without any timesheets linked and set a hour Current Behavior ---------------- After refreshing the page and going to the same week, the changes made in step 5 and 6 are no longer applied. The reason is because those changes have generated new timesheets for the current user instead of the employee displayed in the form view before doing the step 3. Expected behavior ----------------- The grid view should be unchanged after refreshing the page, the changes made in 5 and 6 should be applied without any issues. opw-4491850 Forward-Port-Of: odoo/enterprise#79113
Bug === In some situation, it's possible that the `is_template` raises when it shouldn't. It's more consistent to check it after the creation (super call). Task-4571151 Forward-Port-Of: odoo/enterprise#79173
Original PR description
Bug === In some situation, it's possible that the `is_template` raises when it shouldn't. It's more consistent to check it after the creation (super call). Task-4571151 Forward-Port-Of: odoo/enterprise#79173
An error occurs when triggering a cron job for posting all pending posts. ```ValueError: Expected singleton: social.post(14, 13)``` A singleton error occurs when the system tries to get a value of 'post_method' from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/5e968dfce025102bc27f01ba9b07304477835b47/social_push_notifications/models/social_post.py#L26 To avoid the singleton error, we can use the ```mapped()``` function to retrieve a list of values from a
Original PR description
An error occurs when triggering a cron job for posting all pending posts. ```ValueError: Expected singleton: social.post(14, 13)``` A singleton error occurs when the system tries to get a value of 'post_method' from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/5e968dfce025102bc27f01ba9b07304477835b47/social_push_notifications/models/social_post.py#L26 To avoid the singleton error, we can use the ```mapped()``` function to retrieve a list of values from all the records and check the condition across them. Sentry-6055370689 Forward-Port-Of: odoo/enterprise#74698