Saturday, March 30, 2024
10 changes · saas-17.2
Miscellaneous changes
follow up to https://github.com/odoo/enterprise/pull/58895 Steps to reproduce: - Install ups_rest - Configure the new ups shipping method as admin - Create an SO and try to add ups delivery as demo - Access error Bug: if a new acces token is requested we need sudo accesn to update the carrier access token opw-3771840 Forward-Port-Of: odoo/enterprise#59811
Original PR description
follow up to https://github.com/odoo/enterprise/pull/58895 Steps to reproduce: - Install ups_rest - Configure the new ups shipping method as admin - Create an SO and try to add ups delivery as demo - Access error Bug: if a new acces token is requested we need sudo accesn to update the carrier access token opw-3771840 Forward-Port-Of: odoo/enterprise#59811
The issue: Go to Accounting > Reporting > Journal Report, if you have a tax with a distribution invoice/refund line that has a zero percent line, this will cause a Division By Zero traceback The fix: Ignore the lines with the zero percent opw-3785700 Forward-Port-Of: odoo/enterprise#58444
Original PR description
The issue: Go to Accounting > Reporting > Journal Report, if you have a tax with a distribution invoice/refund line that has a zero percent line, this will cause a Division By Zero traceback The fix: Ignore the lines with the zero percent opw-3785700 Forward-Port-Of: odoo/enterprise#58444
**Bug 1:** - Select a document and add Marc Demo as a follower - Use the 'View Document' link in the notification email to access the document. - The form view still has a button named 'Archive' instead of 'Move to trash'. However, the 'Archive' button moves the document to trash. This PR changes the string of button from 'Archive' to 'Move to trash' and the title of web ribbon from 'Archived' to 'Moved to trash' respectively. **Bug 2:** - Open the documens module. - Go to Config
Original PR description
**Bug 1:** - Select a document and add Marc Demo as a follower - Use the 'View Document' link in the notification email to access the document. - The form view still has a button named 'Archive'…
**Bug 1:** - Select a document and add Marc Demo as a follower - Use the 'View Document' link in the notification email to access the document. - The form view still has a button named 'Archive' instead of 'Move to trash'. However, the 'Archive' button moves the document to trash. This PR changes the string of button from 'Archive' to 'Move to trash' and the title of web ribbon from 'Archived' to 'Moved to trash' respectively. **Bug 2:** - Open the documens module. - Go to Configuration -> Workspaces - Click on the search view dropdown - The filters section still has a filter named 'Archived Workspace' instead of 'Moved to trash' even though it displays trashed workspaces. This PR changes the string of filter from 'Archived Workspace' to 'Moved to trash'. Task: [3787404](https://www.odoo.com/web#id=3787404&cids=2&menu_id=4720&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#59768 Forward-Port-Of: odoo/enterprise#58248
**Before this PR:** When user tried to delete an archived document from the activity view, it led to a traceback. This same traceback was also encountered when a user changed the workspace of a document from activity view. This issue arose because the 'activity renderer' tried to display records of all resIds obtained from activity data, including the record of the document currently in preview, which would be deleted already. Thus, leading to the aforementioned traceback. **After this
Original PR description
**Before this PR:** When user tried to delete an archived document from the activity view, it led to a traceback. This same traceback was also encountered when a user changed the workspace of a…
**Before this PR:** When user tried to delete an archived document from the activity view, it led to a traceback. This same traceback was also encountered when a user changed the workspace of a document from activity view. This issue arose because the 'activity renderer' tried to display records of all resIds obtained from activity data, including the record of the document currently in preview, which would be deleted already. Thus, leading to the aforementioned traceback. **After this PR:** The issue has been addressed by updating the behavior of the 'ActivityRenderer' to retrieve and display the updated activity records in order to ensure accuracy. Apart from that, the progress bar was not updated after the docs were deleted. This PR solves that issue by calling the 'load' method of activity model along with the 'rootParams', and then calling the 'notify' method to update the data correctly. Task: [3714544](https://www.odoo.com/web#id=3714544&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#59740 Forward-Port-Of: odoo/enterprise#56357
*: 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