Monday, February 14, 2022
32 changes · master
Enhancements to existing features
Portal users can now use more task-related buttons in shared projects, including links to accessible sales orders and parent tasks, making project collaboration smoother. Portal project and task links were also made more consistent, with internal cleanup to support reuse across sales, invoices, and project pages.
Original PR description
Follow up of tasks 2379518 and 2633229 (#73341 and #77156). Purpose ======= The main goal is to allow the portal user to click on some stat button shown in the task form view in the project sharing…
Follow up of tasks 2379518 and 2633229 (#73341 and #77156). Purpose ======= The main goal is to allow the portal user to click on some stat button shown in the task form view in the project sharing feature. Those stat button will redirect to a portal view if the portal user has access to the document(s). Then, some refactoring is made to easily use the existing code for one route to another one and review the code for the project sharing tour. Finally, the `/my/project` and `/my/task` routes have been renamed to follow the same *naming* in the another routes. That is, those routes will be named `/my/projects` and `/my/tasks`. ## Details of the implementation - Allow the portal user to click on the sale order stat button in task form view. This stat button will be clickable if the user has access to the sale order of the current task shown in the form view, otherwise the stat button will be invisible. If a portal user clicks on this button, then he will be redirect to `/my/orders/<id of the sale order>`. - Allow to show the parent task from another project than the one shown in project sharing. If the portal user has access to the other project than there is no reason to not allow him to see the parent task. - Rename the `/my/project` route into `/my/projects`. - Rename the `/my/task` route into `/my/tasks`. - Create hook methods to avoid duplicating code when we want to use this code to another route. It will be the case for a new route used in the project sharing feature. - Create hook method in controller of account module to easily reuse the existing code for another route for project sharing feature. - Refactor tour js for project sharing feature to remove the duplicating code. - Revert the disable click on avatar. This changes was initially done for project sharing feature. However, this changes is made `web` module instead of the `project`. Since this changes is no longer used in project sharing feature and no used in backend code, the changes is reverted. - Move the `invoice_count` field from `sale_project` module to `industry_fsm_sale` one because it seems this field is only used in that module and not anywhere before installing that module. task-2648955 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Error messages shown during sales and stock-related order validation have been rewritten to be clearer and easier to understand. This helps users identify what went wrong and how to resolve it without needing technical support.
Original PR description
Currently, User/validation errors are sometimes not correct in English and/or quite obscure and don't help the user understand/solve the issue. So in this commit, do some copywriting to make the experience better. task-2615469 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The VoIP calling component was cleaned up to make future upgrades easier and safer. There is no expected change for users now, but this reduces maintenance risk ahead of a planned calling library update.
Original PR description
This commit prepares the ground for the update of the SIP.js library (see https://github.com/odoo/enterprise/pull/24160)
Portal users can now open task-related tickets, quotations, and invoices directly from shared project task pages when they have permission to view them. The update also standardizes task page URLs and makes timesheet totals reflect only the entries each portal user is allowed to see.
Original PR description
Follow up of tasks 2379518 (community PR odoo/odoo#73341 and enterprise one #19483) and 2633229 (community PR odoo/odoo#77156 and enterprise one #21155). Purpose ======= The main goal is to allow the…
Follow up of tasks 2379518 (community PR odoo/odoo#73341 and enterprise one #19483) and 2633229 (community PR odoo/odoo#77156 and enterprise one #21155). Purpose ======= The main goal is to allow the portal user to click on some stat button shown in the task form view in the project sharing feature. Those stat button will redirect to a portal view if the portal user has access to the document(s). Then, some refactoring is made to easily use the existing code for one route to another one and review the code for the project sharing tour. Finally, the `/my/project` and `/my/task` routes have been renamed to follow the same *naming* in the another routes. That is, those routes will be named `/my/projects` and `/my/tasks`. ## Details of the implementation - Allow portal user to click on ticket stat button shown in the task form view. This stat button will be clickable if the user has access to the ticket, otherwise the stat button will be invisible. If the portal user clicks on this stat button, he will be redirected to `/my/ticket/<id of the ticket>` route. - Rename `/my/task/<task_id>/*` into `/my/tasks/<task_id>/*` - Allow portal user to click on the quotation stat button shown in the task form view if he has access at least to one quotation. When the portal user clicks on this button, he will be redirected the route displaying the quotes related to the task which he can see. - Move the `invoice_count` field from `sale_project` module to `industry_fsm_sale` one because it seems this field is only used in that module and not anywhere before installing that module. - Allow portal user to see invoices of task, that is the portal user can clicks on the invoices stat button to see the invoices related to the task. However, this button will be clickable only if the user has access to at least an invoice is accessible for this user. Also the `invoice_count` in project sharing will count only the invoices the user can see. - Filter timesheets in project sharing based on the `sale.invoiced_timesheet`. Indeed, when the `sale.invoiced_timesheet` setting is equal to `approved` then the portal can only see the validated timesheets. Before this changes is correctly the case, but the total of effective hours shown into the task form view is not the total one of the timesheets he can see into the view but all the timesheets related to this task. - Fix the calculation of `quotation_count` field in project.task model to only count the quotations added via the `Create Quotation` button shown in the `project.task` form view instead of counting all the quotations related to the task. task-2648955 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Error messages in project worksheets and field service flows were rewritten to be clearer and more helpful, making it easier for users to understand and resolve issues. The update also prevents problematic worksheet template duplication and allows quantities to be reduced when delivery is still pending, reducing avoidable validation blockers.
Original PR description
Currently, User/validation errors are sometimes not correct in English and/or quite obscure and don't help the user understand/solve the issue. also there is constraint error on duplication of the worksheet template So in this commit, do some copywriting to make the experience better and inherit the view of demo data in the proper place and hide the duplicate option from the action of worksheet view. task-261546
Spreadsheet cell selection is now managed by a central processor so editing, formulas, and selection inputs no longer interfere with each other. This makes cell selection behavior more reliable and helps prevent incorrect cursor movement after editing.
Original PR description
When a user selects cells in the grid, it can be used by multiple components/plugins: selection itself, composer, selection input. Each one of them should be independent and decoupled. They currently…
When a user selects cells in the grid, it can be used by multiple components/plugins: selection itself, composer, selection input. Each one of them should be independent and decoupled. They currently are not independent and it's a mess because only one of them can be "focused" at the same time. The focused component is determined implicitly with a set of flags/modes in different plugins. E.g. Go on A1. Start the edition and select a cell distant from the edited cell. Once you validate the edition, the selection on the grid has been moved to the last selected cell but it should be in A2. Problem 1 --------- When one component/plugin is focused, it needs to tell others to defocus by "manually" dispatching precise commands which resets their flags/modes. It's hard to follow, it's fragile and it's easy to forget to dispatch the proper command(s) which would lead to an inconsistent state. Problem 2 --------- Selection commands are currently dispatched to all plugins (multi-casted) which needs to decide if they should handle it or not based on their own state and the state of other plugins. Changing the state of one plugin can affect (and potentially break) others. Solution -------- With this commit, we introduce a centralized mechanism to manage the focused element. This centralized mechanism is called the "selection processor". Plugins no longer needs to know each other and are now decoupled. By design, only one component can be focused at the same time. The selection processor: - processes all user inputs and computes the new/updated anchor zone based on the current anchor zone. The new anchor zone is then dispatched in the form of an event to the focused plugin. All business logic of computing the next anchor zone is encapsulated there. Plugins only need to know what is the next anchor and (sometimes) the user intention (add the zone to the selection, reset the selection, etc.). *This addresses the second problem since the flow is now split. Updating the* *selection is a simple method call and the resulting event is sent to the unique* *focused (uni-cast)*. - notifies the focused plugin when another captures the focus, no more need to dispatch specific commands in several places. The plugin is responsible of itself. *Solves the first problem*. - is usually called by the UI(components). - will work with a state provided by the focused plugin which allows a better granularity and the independency of states of each plugin. e.g. When edition is focused, there is only one zone (reference) registered at a time, even if the cell contains several of them. Task 2698011 Co-authored-by: Lucas Lefèvre <lul@odoo.com>
Accounting reports were adjusted to work correctly with a related platform update in Odoo. This helps keep financial reporting reliable after underlying system changes.
Original PR description
link to https://github.com/odoo/odoo/pull/83687
Resolved issues and error corrections
This fix restores the correct icon format in the Chilean localization demo data after an accidental conversion. It helps ensure the related partner demo information displays as intended without missing visual elements.
Original PR description
Fix of rev 10a5796d4b86a679f905be14a. An icon should not have been converted to SVG. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The es-check help specify that the `--module` optional argument as to be given at the end of the cli. After an update to version `6.2.1` it led to errors on runbot's where the Dockerfile was updated. The error was like if the `--module` cli argument was not given at all. e.g.: `error: SyntaxError: 'import' and 'export' may appear only with 'sourceType: module'` With this commit, the argument is given at the end of the cli as expected. Forward-Port-Of: odoo/odoo#84365
Original PR description
The es-check help specify that the `--module` optional argument as to be given at the end of the cli. After an update to version `6.2.1` it led to errors on runbot's where the Dockerfile was updated. The error was like if the `--module` cli argument was not given at all. e.g.: `error: SyntaxError: 'import' and 'export' may appear only with 'sourceType: module'` With this commit, the argument is given at the end of the cli as expected. Forward-Port-Of: odoo/odoo#84365
This update fixes internal tests for spreadsheet pivot formulas so they correctly wait for background calculations to finish. It helps keep the Documents Spreadsheet feature stable by preventing false test failures after recent timing changes.
Original PR description
Formulas `PIVOT`and `PIVOT.HEADER` have a potential async behaviour since they require an RPC and a subsequent evaluation before they are properly updated. Since ea20394e4820b12cc2b3f026c379b1ae6426f38f, we introduced a debounce and with it the necessity to run an additional nextTick to ensure that the cells are evaluated after the RPC promise is solved. In this commit, we use the helper `waitForEvaluation`that was added for that purpose. task 2764761
Forward-Port-Of: odoo/odoo#84320
Original PR description
Forward-Port-Of: odoo/odoo#84320
Steps to Reproduce: - Install 'account' module - Go to Settings and set a token for Google Drive - Activate Google Spreadsheet - Go to Invoicing -> Invoices - Under Search bar, click on Favorites -> Add to Google Spreadsheet Issue: A spreadsheet does open but with no data (no formula or config). Cause: The V3 API we were using was turned down in August 2021 and therefore not able to use the api to write on the spreadsheet. https://cloud.google.com/blog/prod
Original PR description
Steps to Reproduce: - Install 'account' module - Go to Settings and set a token for Google Drive - Activate Google Spreadsheet - Go to Invoicing -> Invoices - Under Search bar, click on Favorites ->…
Steps to Reproduce: - Install 'account' module - Go to Settings and set a token for Google Drive - Activate Google Spreadsheet - Go to Invoicing -> Invoices - Under Search bar, click on Favorites -> Add to Google Spreadsheet Issue: A spreadsheet does open but with no data (no formula or config). Cause: The V3 API we were using was turned down in August 2021 and therefore not able to use the api to write on the spreadsheet. https://cloud.google.com/blog/products/g-suite/migrate-your-apps-use-latest-sheets-api) Note: In case that the system parameters `google_drive_client_id` and `google_drive_client_secret` has been changed (and therefore also the default templates), it must be ensured that the `client` has the Google Sheet API (v4) activated and the scope `[https://www.googleapis.com/auth/spreadsheets`](https://www.googleapis.com/auth/spreadsheets%60) set. API activation and configuration available here : https://console.developers.google.com/apis/dashboard?project=[PROJECT] https://console.developers.google.com/apis/credentials/consent/edit?project=[PROJECT] **[PROJECT]** : Google project that will be linked to `google_drive_client_id`. opw-[2633951](https://www.odoo.com/web#id=2633951&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#84436 Forward-Port-Of: odoo/odoo#83856
Commit 57701b2 resulted in another bug as links could not longer be edited. This refines it so it fixes the bug it solved without the nefarious side effect. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84428
Original PR description
Commit 57701b2 resulted in another bug as links could not longer be edited. This refines it so it fixes the bug it solved without the nefarious side effect. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84428
This commit ensures that changes are applied in the same order as the events are triggered on the we-matrix. This was not the case because of another bug we had to consider and which is not there anymore, this is why this fix is done in 15.0 and not before. This commit is the continuation of [1] which applied the same change for we-input. [1]: https://github.com/odoo/odoo/pull/79295/commits/be96612c753e8c2ec857972f03473f94eb853017 task-2761187 -- I confirm I have signed the CLA
Original PR description
This commit ensures that changes are applied in the same order as the events are triggered on the we-matrix. This was not the case because of another bug we had to consider and which is not there anymore, this is why this fix is done in 15.0 and not before. This commit is the continuation of [1] which applied the same change for we-input. [1]: https://github.com/odoo/odoo/pull/79295/commits/be96612c753e8c2ec857972f03473f94eb853017 task-2761187 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84337
Before this commit: a coupon's start and end dates were compared with the order date. When a customer adds a product to the cart, it creates an order on the website. If the customer makes an order, it will remain active until he completes it, even when the coupon is expired. To reproduce the problem, add a product to the cart, create a coupon, and set its end date to present time. Now you can use the coupon after the end date has passed. So it's better to check the date with the current
Original PR description
Before this commit: a coupon's start and end dates were compared with the order date. When a customer adds a product to the cart, it creates an order on the website. If the customer makes an order, it will remain active until he completes it, even when the coupon is expired. To reproduce the problem, add a product to the cart, create a coupon, and set its end date to present time. Now you can use the coupon after the end date has passed. So it's better to check the date with the current time. opw-2711987 Forward-Port-Of: odoo/odoo#84120 Forward-Port-Of: odoo/odoo#82399
In order to respect the good practices of HTML, it is preferable that the IDs of HTML elements do not start with a number. This makes it easier to handle CSS selectors etc. see https://github.com/odoo/odoo/pull/80217#discussion_r787636826 task-2760205 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84345 Forward-Port-Of: odoo/odoo#84236
Original PR description
In order to respect the good practices of HTML, it is preferable that the IDs of HTML elements do not start with a number. This makes it easier to handle CSS selectors etc. see https://github.com/odoo/odoo/pull/80217#discussion_r787636826 task-2760205 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84345 Forward-Port-Of: odoo/odoo#84236
Forward-Port-Of: odoo/odoo#84453
Original PR description
Forward-Port-Of: odoo/odoo#84453
Description of the issue/feature this PR addresses: - Create a sale.order with a product with an optional product - Confirm order A - Copy this order A, a new order B is created --> Issue: the new line of order B are linked with an line of order A @tivisse @tde-banana-odoo Note the best solution is (maybe for master): ```python class SaleOrder(): order_line = One2many(copy=False) def copy(self, default=None): new_order = super().copy(default) map_l
Original PR description
Description of the issue/feature this PR addresses: - Create a sale.order with a product with an optional product - Confirm order A - Copy this order A, a new order B is created --> Issue: the new…
Description of the issue/feature this PR addresses:
- Create a sale.order with a product with an optional product
- Confirm order A
- Copy this order A, a new order B is created
--> Issue: the new line of order B are linked with an line of order A
@tivisse @tde-banana-odoo
Note the best solution is (maybe for master):
```python
class SaleOrder():
order_line = One2many(copy=False)
def copy(self, default=None):
new_order = super().copy(default)
map_line = {}
map_line_linked = {}
for line in self.order_line:
new_line = line.copy({'order_id': new_order.id}
map_line[line] = new_line
map_line_linked[new_line] = line.linked_line_id
for line in new_order.order_line:
linked = map_line_linked.get(line)
if linked:
line.linked_line_id = map_line[linked]
return new_order
```
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#84431
Forward-Port-Of: odoo/odoo#83536This generally improves the performance of `convert_inline` so `mass_mailing` can load and save faster. Tested on the saving of the "newsletter" template on runbot, the conversion is about **13.5x faster** with this PR than before (from 2.99s to 220.91ms). - Some tests depended on a variable to be defined, which was only defined in other tests. - `__extraAssetsForIframe` had been kept in `mass_mailing` and `web_editor` for historical reasons but was not used anymore. This removes it. - `
Original PR description
This generally improves the performance of `convert_inline` so `mass_mailing` can load and save faster. Tested on the saving of the "newsletter" template on runbot, the conversion is about **13.5x…
This generally improves the performance of `convert_inline` so `mass_mailing` can load and save faster. Tested on the saving of the "newsletter" template on runbot, the conversion is about **13.5x faster** with this PR than before (from 2.99s to 220.91ms). - Some tests depended on a variable to be defined, which was only defined in other tests. - `__extraAssetsForIframe` had been kept in `mass_mailing` and `web_editor` for historical reasons but was not used anymore. This removes it. - `web.assets_frontend` was called in `wysiwyg_iframe_editor_assets` _and_ in `iframe_css_assets_edit`. As a result, they were loaded twice in edit mode. - This batches all writes in the `classToStyle` method of `convert_inline` so as to minimize layout thrashing and therefore improve performance. - This batches all writes in the `formatTables` method of `convert_inline` so as to minimize layout thrashing and therefore improve performance. - `convert_inline` used to do some style adaptations that seem to only have been needed due to improper css assets loading, which was fixed in a previous commit. - Since some css was loaded twice, when parsing rules, we grouped similar rules in order to minimize the amount of rules on which to iterate during conversion, so as to improve performance. This is not needed anymore now css is loaded only once, so we can remove this extra processing. - This improves performance of `classToStyle` by first selecting which nodes and which rules will be concerned. When parsing the css rules, we computed their specificity and normalized their styles one by one. This applies these processes only on the concerned rules, all at once. - Rules used to be applied in the DOM sequencially, in traversal order. This is slow and confusing to debug. Meanwhile, most functions had been adapted to process the rules in a simple loop on the concerned nodes. This commit does that for `classToStyle`, the last remaining function that wasn't doing it yet, and removes the utility function `applyOverDescendants` altogether. - This refactors the cache of cssRules. - jQuery was used extensively in `convert_inline`, slowing it down by a factor of more than 2. This replaces all use of jQuery with vanilla javascript so as to improve performance significantly. - The conversion of the comparison snippet for mail compatibility involves heavy changes in the html. In order to preserve the style, some style changes were needed as well. This change to the style of cards allows us to restore the border around the snippet. - The final mail to be sent will have to use a mail-safe font everywhere so we can't allow other fonts to be applied in some elements. Because of the way the css was declared, we still had other fonts on some elements, like .btn. As a result, we had a different look between readonly and edit modes. - Icons converted to images were improperly aligned because as inline elements their vertical-align style property used their first block ancestor as reference. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84465 Forward-Port-Of: odoo/odoo#84088
**Description of the issue/feature this PR addresses:** **Use Case:** Google Spreadsheet Odoo Script Access (XML-RPC API), ~~not sure which change triggered this behavior, but~~ there was and is a point of failure in case no lang context key is defined. EDIT: Using the wrong configuration for the base url in Google Spreadsheets like https://yourdomain.tld/ instead of https://yourdomain.tld will trigger this error... **Current behavior before PR:** <details> <summary>Traceback</s
Original PR description
**Description of the issue/feature this PR addresses:** **Use Case:** Google Spreadsheet Odoo Script Access (XML-RPC API), ~~not sure which change triggered this behavior, but~~ there was and is a…
**Description of the issue/feature this PR addresses:**
**Use Case:**
Google Spreadsheet Odoo Script Access (XML-RPC API), ~~not sure which change triggered this behavior, but~~ there was and is a point of failure in case no lang context key is defined.
EDIT:
Using the wrong configuration for the base url in Google Spreadsheets like https://yourdomain.tld/ instead of https://yourdomain.tld will trigger this error...
**Current behavior before PR:**
<details>
<summary>Traceback</summary>
```
Error on request:
Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/werkzeug/serving.py", line 270, in run_wsgi
execute(self.server.app)
File "/usr/local/lib/python3.6/site-packages/werkzeug/serving.py", line 258, in execute
application_iter = app(environ, start_response)
File "/opt/odoo/custom/src/odoo/odoo/service/wsgi_server.py", line 140, in application
return ProxyFix(application_unproxied)(environ, start_response)
File "/usr/local/lib/python3.6/site-packages/werkzeug/contrib/fixers.py", line 152, in __call__
return self.app(environ, start_response)
File "/opt/odoo/custom/src/odoo/odoo/service/wsgi_server.py", line 117, in application_unproxied
result = odoo.http.root(environ, start_response)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 1287, in __call__
return self.dispatch(environ, start_response)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 1257, in __call__
return self.app(environ, start_wrapped)
File "/usr/local/lib/python3.6/site-packages/werkzeug/wsgi.py", line 766, in __call__
return self.app(environ, start_response)
File "/opt/odoo/custom/src/odoo/odoo/http.py", line 1456, in dispatch
result = ir_http._dispatch()
File "/opt/odoo/custom/src/odoo/addons/website_sale/models/ir_http.py", line 15, in _dispatch
return super(IrHttp, cls)._dispatch()
File "/opt/odoo/custom/src/odoo/addons/website/models/ir_http.py", line 172, in _dispatch
response = super(Http, cls)._dispatch()
File "/opt/odoo/custom/src/odoo/addons/auth_signup/models/ir_http.py", line 19, in _dispatch
return super(Http, cls)._dispatch()
File "/opt/odoo/custom/src/odoo/addons/web_editor/models/ir_http.py", line 21, in _dispatch
return super(IrHttp, cls)._dispatch()
File "/opt/odoo/custom/src/odoo/addons/utm/models/ir_http.py", line 29, in _dispatch
response = super(IrHttp, cls)._dispatch()
File "/opt/odoo/custom/src/odoo/addons/http_routing/models/ir_http.py", line 469, in _dispatch
cls._add_dispatch_parameters(func)
File "/opt/odoo/custom/src/odoo/addons/website/models/ir_http.py", line 211, in _add_dispatch_parameters
super(Http, cls)._add_dispatch_parameters(func)
File "/opt/odoo/custom/src/odoo/addons/http_routing/models/ir_http.py", line 405, in _add_dispatch_parameters
nearest_ctx_lg = not is_a_bot and cls.get_nearest_lang(request.env.context['lang'])
KeyError: 'lang'
```
</details>
**Desired behavior after PR is merged:**
No Traceback
Info: @wt-io-it
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#83880## goal: The aim of this commit is to set partner on anglosaxon aml in order to help our client in their stock reconciliation process in case it hasn't been done automatically. ## Before this commit: anglosaxon line were created without partner ## After this commit: A partner is set when anglosaxon line are created **ticket**: 2692308 **Community-PR**: https://github.com/odoo/odoo/pull/84468 Forward-Port-Of: odoo/odoo#84468
Original PR description
## goal: The aim of this commit is to set partner on anglosaxon aml in order to help our client in their stock reconciliation process in case it hasn't been done automatically. ## Before this commit: anglosaxon line were created without partner ## After this commit: A partner is set when anglosaxon line are created **ticket**: 2692308 **Community-PR**: https://github.com/odoo/odoo/pull/84468 Forward-Port-Of: odoo/odoo#84468
When a test fails and asks for a screenshot, it seems that in some conditions, the browser has already navigated to the blank page when capturing the screenshot, resulting in a useless blank screenshot. With this commit, all the futures are awaited to avoid this race condition. Forward-Port-Of: odoo/odoo#84524
Original PR description
When a test fails and asks for a screenshot, it seems that in some conditions, the browser has already navigated to the blank page when capturing the screenshot, resulting in a useless blank screenshot. With this commit, all the futures are awaited to avoid this race condition. Forward-Port-Of: odoo/odoo#84524
Description of the issue/feature this PR addresses: While calling `_stock_account_prepare_anglo_saxon_out_lines_vals`, the line `credit_expense_account = accounts['expense'] or self.journal_id.default_account_id` can cause a 'Expected singleton' error. During upgrades from v13 and earlier, the value used for `accounts['expense']` is always `None`. If the recordset in `self` contains more than one record, the error will happen. By replacing `self` with the iteration object `move`, this
Original PR description
Description of the issue/feature this PR addresses: While calling `_stock_account_prepare_anglo_saxon_out_lines_vals`, the line `credit_expense_account = accounts['expense'] or…
Description of the issue/feature this PR addresses:
While calling `_stock_account_prepare_anglo_saxon_out_lines_vals`, the line
`credit_expense_account = accounts['expense'] or self.journal_id.default_account_id`
can cause a 'Expected singleton' error. During upgrades from v13 and earlier, the value used for `accounts['expense']` is always `None`. If the recordset in `self` contains more than one record, the error will happen.
By replacing `self` with the iteration object `move`, this error is averted.
Current behavior before PR:
The error happened during an upgrade from v13. Since the value assigned to `accounts['expense']` doesn't exist in that version, it goes to `self.journal_id.default_account_id` to grab it. If `self` has more than one record, the error happens.
Traceback:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1199, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 475, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
migrate(self.cr, installed_version)
File "/tmp/tmpae3wx5o6/migrations/account/saas~13.4.1.1/end-09-payment-refactoring.py", line 618, in migrate
util.iter_browse(env["account.move"].with_context(**ctx), ids, chunk_size=1024).action_post()
File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in caller
return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in <listcomp>
return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
File "/home/odoo/src/odoo/14.0/addons/sale/models/account_move.py", line 14, in action_post
res = super(AccountMove, self).action_post()
File "/home/odoo/src/odoo/14.0/addons/account/models/account_move.py", line 2715, in action_post
self._post(soft=False)
File "/home/odoo/src/enterprise/14.0/l10n_mx_edi_landing/models/account_move.py", line 26, in _post
return super()._post(soft)
File "/home/odoo/src/enterprise/14.0/l10n_mx_edi/models/account_move.py", line 456, in _post
return super()._post(soft=soft)
File "/home/odoo/src/odoo/14.0/addons/sale/models/account_invoice.py", line 75, in _post
posted = super()._post(soft)
File "/home/odoo/src/odoo/14.0/addons/purchase_stock/models/account_invoice.py", line 171, in _post
return super()._post(soft)
File "/home/odoo/src/enterprise/14.0/account_reports/models/account_activity.py", line 75, in _post
return super()._post(soft)
File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 49, in _post
self.env['account.move.line'].create(self._stock_account_prepare_anglo_saxon_out_lines_vals())
File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 158, in _stock_account_prepare_anglo_saxon_out_lines_vals
'account_id': credit_expense_account.id,
File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 3821, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.account(1383, 38, 30)
```
Desired behavior after PR is merged:
During normal use behavior should be the same. This particular upgrade should be fixed.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#83739The function `arrayToString` did not properly support domains containing arrays of booleans, for instance `[["val", "in", [true, false]]]`. The array containing the boolean was directly JSON stringified without being converted to its python equivalent. Co-authored-by: Lucas Lefèvre <lul@odoo.com> 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 guideline
Original PR description
The function `arrayToString` did not properly support domains containing arrays of booleans, for instance `[["val", "in", [true, false]]]`. The array containing the boolean was directly JSON stringified without being converted to its python equivalent. Co-authored-by: Lucas Lefèvre <lul@odoo.com> 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#84425 Forward-Port-Of: odoo/odoo#83817
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#84544
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#84544
Current behavior: When trying to open the gift card list you get an access error if one of the cards has been used in another company. This error appears because you cannot access SO from another company and the used gift cards were linked to a SO. So shouldn't be able to use a gift card that was created in another company. Steps to reproduce: - Create a gift card in company A - Use it in company B - Try to access it from company A opw-2732973 -- I confirm I have signed the CLA a
Original PR description
Current behavior: When trying to open the gift card list you get an access error if one of the cards has been used in another company. This error appears because you cannot access SO from another company and the used gift cards were linked to a SO. So shouldn't be able to use a gift card that was created in another company. Steps to reproduce: - Create a gift card in company A - Use it in company B - Try to access it from company A opw-2732973 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83901
Prior to this commit, when a user searches with an upper case search term of more than 3 characters, the search was considered as a fuzzy search even if the result was an exact match. Since the search is always lowered when there are more than 3 characters, the search is considered as fuzzy only when the search and fuzzy term are case insensitively distinct. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84433
Original PR description
Prior to this commit, when a user searches with an upper case search term of more than 3 characters, the search was considered as a fuzzy search even if the result was an exact match. Since the search is always lowered when there are more than 3 characters, the search is considered as fuzzy only when the search and fuzzy term are case insensitively distinct. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84433
When the user has the planning and Sales apps installed and created an open shift (a shift without any resource set) and he published and sends the planning to his employees, the employees can see the SOL linked to this shift. However, if the user installs the Project app, the `project_forecast` module is installed to make the bridge between the `Planning` and `Project` apps. This module overrides the template shown to the employees to see the planning. This override erases the SOL field sh
Original PR description
When the user has the planning and Sales apps installed and created an open shift (a shift without any resource set) and he published and sends the planning to his employees, the employees can see…
When the user has the planning and Sales apps installed and created an open shift (a shift without any resource set) and he published and sends the planning to his employees, the employees can see the SOL linked to this shift. However, if the user installs the Project app, the `project_forecast` module is installed to make the bridge between the `Planning` and `Project` apps. This module overrides the template shown to the employees to see the planning. This override erases the SOL field shown in this template. Steps to reproduce: Install Planning and Sales apps Go to the planning app Add a new shift and set an SOL When we are in the Gantt view of the Planning app, clicks on the Publish button and send the planning to an employee Check the mail sent and go to the mail sent with the planning and click on the link to redirect to the planning. Normally we see the SOL linked to the shift Install the Project app Go back to the planning URL sent to the employee Actual Behaviour: The SOL linked to the shift is no longer visible. Expected Behaviour: The SOL linked should be visible in that template. closes #23705 task-2742510 Forward-Port-Of: odoo/enterprise#23705
Not awaiting for the `_processData` to resolve results to random error in the test tours. This is because `pos_coupon` depends on the existence of `promo_programs` field as an array, which is only properly initialized at `_processData`. Forward-Port-Of: odoo/enterprise#24303
Original PR description
Not awaiting for the `_processData` to resolve results to random error in the test tours. This is because `pos_coupon` depends on the existence of `promo_programs` field as an array, which is only properly initialized at `_processData`. Forward-Port-Of: odoo/enterprise#24303
Forward-Port-Of: odoo/enterprise#24276
Original PR description
Forward-Port-Of: odoo/enterprise#24276
Since commit e3af30c9e169549b25e6ea1d8510ada712d3d7cd We browse the move_dest_ids on stock.move to evaluate delay to the stock location to be able to handle the internal rules delays. However some move in the chain could be return and thus create a loop in the moves chain. This is the expected behavior. It will create an infinite loop in our case since it's not expected. This commit only browse the move_dest_ids not related to a return opw-2753223 Forward-Port-Of: odoo/enterprise
Original PR description
Since commit e3af30c9e169549b25e6ea1d8510ada712d3d7cd We browse the move_dest_ids on stock.move to evaluate delay to the stock location to be able to handle the internal rules delays. However some move in the chain could be return and thus create a loop in the moves chain. This is the expected behavior. It will create an infinite loop in our case since it's not expected. This commit only browse the move_dest_ids not related to a return opw-2753223 Forward-Port-Of: odoo/enterprise#24217
When you click on the pager to edit the index of the page, the background changes to white and the text remains white, which makes the page difficult to read. This pr changes the color of the text at this time to make it black opw-2737042 Forward-Port-Of: odoo/enterprise#24053
Original PR description
When you click on the pager to edit the index of the page, the background changes to white and the text remains white, which makes the page difficult to read. This pr changes the color of the text at this time to make it black opw-2737042 Forward-Port-Of: odoo/enterprise#24053