Saturday, March 30, 2024
6 changes · saas-17.2
Miscellaneous changes
*: stock Strings within inline templates are not translatable, so we convert these templates into standard templates so that they can be. Task-3761551 Forward-Port-Of: odoo/odoo#159790 Forward-Port-Of: odoo/odoo#158844
Original PR description
*: stock Strings within inline templates are not translatable, so we convert these templates into standard templates so that they can be. Task-3761551 Forward-Port-Of: odoo/odoo#159790 Forward-Port-Of: odoo/odoo#158844
Before that commit, the search defaults were removed from the WithSearch prop context by the WithSearch (search model). Fix that problem brings another one (that we also fix): The search defaults are not filtered when the WithSearch is started with a search model state or updated by its parent. Forward-Port-Of: odoo/odoo#159545 Forward-Port-Of: odoo/odoo#158833
Original PR description
Before that commit, the search defaults were removed from the WithSearch prop context by the WithSearch (search model). Fix that problem brings another one (that we also fix): The search defaults are not filtered when the WithSearch is started with a search model state or updated by its parent. Forward-Port-Of: odoo/odoo#159545 Forward-Port-Of: odoo/odoo#158833
The intended behavior to only update tags and no other fields on existing accounts during CoA loading was originally introduced in https://github.com/odoo/odoo/pull/125320 and has recently been broken by commit f2861b9d8d50 (https://github.com/odoo/odoo/pull/155256). This has been recognized because of failing requests in the upgrade platform when it tried to update the `code` field, which lead to excessive recomputations and in turn to MemoryErrors. The problem is that the tests, if the curr
Original PR description
The intended behavior to only update tags and no other fields on existing accounts during CoA loading was originally introduced in https://github.com/odoo/odoo/pull/125320 and has recently been…
The intended behavior to only update tags and no other fields on existing accounts during CoA loading was originally introduced in https://github.com/odoo/odoo/pull/125320 and has recently been broken by commit f2861b9d8d50 (https://github.com/odoo/odoo/pull/155256). This has been recognized because of failing requests in the upgrade platform when it tried to update the `code` field, which lead to excessive recomputations and in turn to MemoryErrors.
The problem is that the tests, if the current `xmlid` constitutes a record update or a new record[^1], need to be correct, no matter if the code above[^2] managed to update the `xmlid` pointer or not. Thus, restore the previous logic regarding that by only assigning the alternative record to the `account` var if it is not None.
[^1]: https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L312
and
https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L314
[^2]: https://github.com/odoo/odoo/blob/35bb495d5e5a8dac563ba4dee1702d77e4b71461/addons/account/models/chart_template.py#L303
Forward-Port-Of: odoo/odoo#159866### Steps to reproduce: - Go to the project application and click on any project with a task - Hover over the task and click on the "assign button" #### > inactive users can be assigned to the task ### Cause of the issue: Clicking on the "assign button" will call of the `name_search` method on `res.users` to determine which user can be added as a task assignee. Since the domain of the `user_ids` field of the `project.task` model: https://github.com/odoo/odoo/blob/331d8451d9011aff6a
Original PR description
### Steps to reproduce: - Go to the project application and click on any project with a task - Hover over the task and click on the "assign button" #### > inactive users can be assigned to the task…
### Steps to reproduce: - Go to the project application and click on any project with a task - Hover over the task and click on the "assign button" #### > inactive users can be assigned to the task ### Cause of the issue: Clicking on the "assign button" will call of the `name_search` method on `res.users` to determine which user can be added as a task assignee. Since the domain of the `user_ids` field of the `project.task` model: https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170 is overriden in the view: https://github.com/odoo/odoo/blob/fcd66ee3321649405cf21bc1d625d71abf3d5819/addons/project/views/project_task_views.xml#L649 inactive users will not be filtered out by the domain. On the other hand, they chould still be filtered out during this call because inactive records should automatically be filtered out by the `_where_calc` method, unless explicitely asked for: https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5389 https://github.com/odoo/odoo/blob/9134358b579361ef5d7e4da43d4778027564adc9/odoo/models.py#L5091-L5093 However, since the `'active_test'` is set to `False` in the context of the the `user_ids` field: https://github.com/odoo/odoo/blob/331d8451d9011aff6a8290c473a52fa77b30b358/addons/project/models/project_task.py#L169-L170 the inactive records will also not be filtered out by the call of the `_where_calc` method. #### Note: Prior to version 17.0, the flow worked "as expected" since the context set in the `user_ids` was not properly taken into account and inactive records were therefore filtered out by the call of this `_where_calc` method. Thanks to commit c3e497f this context is now relevant. opw-3796425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158824
The issue: A new fix has been introduced to solve the mimtype issue with creating an XML file: https://github.com/odoo/odoo/pull/124507 since the attachment create_uid now is the SUPERUSER_ID, when a user with the accounting role (not admin) tried to register a payment on any account.move type (invoice, credit note...) an access error is thrown The fix: remove the unused attachment as sudo opw-3787008 Forward-Port-Of: odoo/odoo#158881
Original PR description
The issue: A new fix has been introduced to solve the mimtype issue with creating an XML file: https://github.com/odoo/odoo/pull/124507 since the attachment create_uid now is the SUPERUSER_ID, when a user with the accounting role (not admin) tried to register a payment on any account.move type (invoice, credit note...) an access error is thrown The fix: remove the unused attachment as sudo opw-3787008 Forward-Port-Of: odoo/odoo#158881
Currently we assume that all imported invoices are incoming (i.e. bills). This was i.e. done since the tax agency only sends users bills. But some clients import invoices from other software (i.e. onboarding/starting). After this PR we decide whether the invoice is outgoing or ingoing and import the invoice correctly in either case. Link: https://www.odoo.com/web#model=project.task&id=3650355 task-3650355 Forward-Port-Of: odoo/odoo#160021 Forward-Port-Of: odoo/odoo#151139
Original PR description
Currently we assume that all imported invoices are incoming (i.e. bills). This was i.e. done since the tax agency only sends users bills. But some clients import invoices from other software (i.e. onboarding/starting). After this PR we decide whether the invoice is outgoing or ingoing and import the invoice correctly in either case. Link: https://www.odoo.com/web#model=project.task&id=3650355 task-3650355 Forward-Port-Of: odoo/odoo#160021 Forward-Port-Of: odoo/odoo#151139