Tuesday, November 28, 2023
41 changes · master
Enhancements to existing features
Yearly recurring calendar events now keep their yearly setting instead of being converted into a 12-month monthly repeat. This avoids confusing changes in the calendar interface after saving and keeps recurrence details clearer for users.
Original PR description
Before this commit, when a yearly recurrence was created in Odoo, it was transformed into a monthly recurrence with a 12 month interval. It would bring confusion in the UI as the recurrence type would be updated upon save. task id 3572232 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet notifications can now show different levels such as warnings, errors, information, and success messages. They can also be set to stay visible or disappear automatically, giving users clearer and more appropriate feedback in the interface.
Original PR description
This commit improves the notifications that can be sent to the user interface in three ways 1 - change responsibilities Spreadsheet has been developed so that it isn't possible to notify several times with the same message. We believe that this feature should not be general but specific to each notifying element. Technically, this means no longer using "tag" on the notifyUser payload 2 - Have different notification categories. The spreadsheet integration currently allows having only one level of notification. We would like to have several such as: - danger - warning - info - success 3 - Notify user with sticky and no sticky notifications odoo task id 3414653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users edit multiple records in a list, Odoo now keeps those records selected afterward. This makes it easier to apply additional changes to the same group without manually selecting everything again.
Original PR description
Before this commit : After selecting and editing multiple records in a list view, the selected records are no longer selected. You must therefore reselect them if you want to apply a modification to them again. After this commit : The selection is not reset. We can therefore apply another modification to the same selection. task-3373140 https://github.com/odoo/enterprise/pull/51580
Users who select multiple records in a list can now keep that selection after applying a mass edit. This saves time when making several updates to the same group of records, since users no longer need to reselect them each time.
Original PR description
Before this commit : After selecting and editing multiple records in a list view, the selected records are no longer selected. You must therefore reselect them if you want to apply a modification to them again. After this commit : The selection is not reset. We can therefore apply another modification to the same selection. task-3373140 https://github.com/odoo/odoo/pull/142296
Spreadsheet notifications can now show clearer message types such as warnings, errors, information, and success messages. They can also be shown as temporary or persistent alerts, giving users better feedback at the right level of importance.
Original PR description
This commit improves the notifications that can be sent to the user interface in three ways 1 - change responsibilities Spreadsheet has been developed so that it isn't possible to notify several times with the same message. We believe that this feature should not be general but specific to each notifying element. Technically, this means no longer using "tag" on the notifyUser payload 2 - Have different notification categories. The spreadsheet integration currently allows having only one level of notification. We would like to have several such as: - danger - warning - info - success 3 - Notify user with sticky and no sticky notifications odoo task id 3414653
The Peru electronic invoicing module description was updated to clarify that invoices can be sent through OSE providers beyond Digiflow. This helps businesses understand the module supports broader provider options without changing core functionality.
Original PR description
…ides Digiflow
Resolved issues and error corrections
This fixes an internal automated test that was failing after a previously checked partner field was removed. The change keeps the test focused on valid model information, helping maintain reliable quality checks without affecting users.
Original PR description
Since [1] the `date` field has been removed from the `res.partner` model. This `test_access_all_model_fields` test checks that some model fields are retrieved as part of the model definition. Among those field, the field date was checked arbitrarily. Since this field was removed, this test is now failing. This PR adapts the test not to rely on this field. [1]: https://github.com/odoo/odoo/pull/112769 fixes runbot-45913
Features or functions removed from Odoo
This removes an outdated and misleading internal note and related legacy check in the core server code. The change reduces maintenance confusion without affecting everyday user workflows, because the old workaround is no longer needed in supported Python versions.
Original PR description
The TODO added in https://github.com/odoo/odoo/pull/29706 is confusing and asks to remove the `_handle_request_noblock` method completely. In fact, the TODO only targets the first if of the method. Why the confusion? It was merged at the same time as https://github.com/odoo/odoo/pull/37238, which reuses the same hook for another feature. Remove the confusing comment, and the first `if` of the method, as the fix is in all supported Python versions https://github.com/python/cpython/commit/10cb3760e8631a27f5db1e51b05494e29306c671).
Code cleanup and technical improvements
Many-to-one fields now use the same context rules as other context-dependent fields, combining relevant global, backend, and view-defined settings. This makes field behavior more consistent across the interface while preserving the special handling needed when opening a record form.
Original PR description
The goal of this commit is for the Many2oneField to use the same context as the other context-dependent fields (x2manyField, ...). To do this, we need to pass the context generated by dynamicInfo.context, which corresponds to the union of the global context, the backend field and the context defined on the <field> in the view arch. In Many2oneField, we just have to make an exception for the context used in order to open the record in form view (openAction), in this case, we have to ignore the global context. 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
Miscellaneous changes
When using account.root (through account.account().root_id or account.move.line().account_root_id) in read_group, we can have inconsistent results because of how account.root is defined. account_root is a view with the id field computed out of account codes, but there can be the same account for several companies, so we can have several same ID for different rows => this is not expected by the ORM who expects one record by ID => in result, we get for example the values in the pivot tabl
Original PR description
When using account.root (through account.account().root_id or account.move.line().account_root_id) in read_group, we can have inconsistent results because of how account.root is defined. account_root…
This restores a previously lost correction in the Point of Sale sales order management area. It helps keep sale order handling in POS working as intended after a merge accidentally removed the fix.
Original PR description
During a merge conflict in the 136bb1d commit, the fix from commit 6212fe2 was lost. In this commit we add back said fix. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Live chat operators are now represented using the same persona model used elsewhere in messaging, replacing a harder-to-manage internal format. This should make operator names more consistent and give businesses better control over the live chat username shown to visitors.
Original PR description
Before this PR, livechat operator used an obscure format. This PR transform the operator in persona and add a better controle over `user_livechat_username`.
This change stops kanban views from automatically saving every field when no special save setting is provided. It helps ensure fields marked as read-only remain protected, reducing the risk of unintended data changes while preserving expected progress bar behavior through tests.
Original PR description
In commit 47e66bf49f30b47c0883e718a4e483053417071a, we decided to pass all the fields in a kanban view in forceSave = true mode if nothing is specified in the arch. This choice was made for the ProgressBarField. We believe that this historical decision is wrong because a field that is readonly on the server side should not be editable. In this commit, we are therefore going to remove this choice. 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
Many2one fields now use the same combined context information as other related fields, helping forms behave more consistently across views. This reduces the risk of mismatched defaults or filtering rules while preserving the correct behavior when opening records directly.
Original PR description
The goal of this commit is for the Many2oneField to use the same context as the other context-dependent fields (x2manyField, ...). To do this, we need to pass the context generated by dynamicInfo.context, which corresponds to the union of the global context, the backend field and the context defined on the <field> in the view arch. In Many2oneField, we just have to make an exception for the context used in order to open the record in form view (openAction), in this case, we have to ignore the global context.
When using account.root (through account.account().root_id or account.move.line().account_root_id) in read_group, we can have inconsistent results because of how account.root is defined. account_root is a view with the id field computed out of account codes, but there can be the same account for several companies, so we can have several same ID for different rows => this is not expected by the ORM who expects one record by ID => in result, we get for example the values in the pivot table of journal items be multiplied by the number of companies if we group by "Account Root". With this changeset, we add a small optimisation in ORM so if a group by is ordered by a many2one, if the order of the many2one is "id" we don't add a left join for ordering. note: without the change, the added tests failed: - in account, with 1000 as balance, and 2 as number of root with id=90090 - in test_read_group with a query containing a left join to o2m table opw-[2282699](https://www.odoo.com/web#id=2282699&view_type=form&model=project.task) opw-[2289440](https://www.odoo.com/web#id=2289440&view_type=form&model=project.task) opw-[3288390](https://www.odoo.com/web#id=3288390&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#143257 Forward-Port-Of: odoo/odoo#120595
This issue occurs when the customer creates an operation with a 0.0 expected duration fields. An error is then generated when the customer creates a manufacturing order and selects that operation due to expected duration fields is set zero. step to reproduce - - Install the `Manufacturing` - Click on `Configuration > Operations ` - Create New Operations. - Select the Bill of Material (ex - [FURN_8621] Plastic Laminate) - Default Duration fields must be 0.0 - click on `Operations
Original PR description
This issue occurs when the customer creates an operation with a 0.0 expected duration fields. An error is then generated when the customer creates a manufacturing order and selects that operation due…
This issue occurs when the customer creates an operation with a 0.0 expected duration fields. An error is then generated when the customer creates a manufacturing order and selects that operation due to expected duration fields is set zero.
step to reproduce -
- Install the `Manufacturing`
- Click on `Configuration > Operations `
- Create New Operations.
- Select the Bill of Material (ex - [FURN_8621] Plastic Laminate)
- Default Duration fields must be 0.0
- click on `Operations > Manufacturing Orders`
- Create New Manufacturing Orders.
- Select the Product (select the product which you selects while creating operation ex. FURN_8621] Plastic Laminate)
- Click on the `Overview` button.
sentry traceback-
```
ZeroDivisionError: float division by zero
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 462, in call_kw
result = _call_kw_model(method, model, args, kwargs)
File "odoo/api.py", line 435, in _call_kw_model
result = method(recs, *args, **kwargs)
File "addons/mrp/report/mrp_report_mo_overview.py", line 19, in get_report_values
'data': self._get_report_data(production_id),
File "addons/mrp/report/mrp_report_mo_overview.py", line 78, in _get_report_data
operations = self._get_operations_data(production, level=1, current_index='')
File "addons/mrp/report/mrp_report_mo_overview.py", line 268, in _get_operations_data
real_cost = expected_cost / workorder.duration_expected * bom_duration_expected
```
https://github.com/odoo/odoo/blob/8adb65993e77150ac711d8e64d1768284bfb49fb/addons/mrp/report/mrp_report_mo_overview.py#L268
after this commit, the customer will be able to set 0.0 in expected duration.
sentry-4657725988
Forward-Port-Of: odoo/odoo#143490### Steps to reproduce * install the German localization * create and print an invoice You should see that the 'total' block and payment reference are not correctly aligned opw-3524254 Before:  After:  Forward-Port-Of: odoo/odoo#141945
Original PR description
### Steps to reproduce * install the German localization * create and print an invoice You should see that the 'total' block and payment reference are not correctly aligned opw-3524254 Before:  After:  Forward-Port-Of: odoo/odoo#141945
For multi language website, when request http:/localhost/en/something, Odoo reroutes from the requested path /en/something to the new path /something with lang=en_US in context. If the new path is a unicode string like http:/localhost/vi/xin-chào, http:/localhost/ru/привет, a error should occur at werkzeug._compat.wsgi_decoding_dance() because the path was not latin1 string. The utf-8 encoding followed by a latin-1 decoding is required by the WSGI specification[^1]. latin-1 is used as an e
Original PR description
For multi language website, when request http:/localhost/en/something, Odoo reroutes from the requested path /en/something to the new path /something with lang=en_US in context. If the new path is a…
For multi language website, when request http:/localhost/en/something, Odoo reroutes from the requested path /en/something to the new path /something with lang=en_US in context. If the new path is a unicode string like http:/localhost/vi/xin-chào, http:/localhost/ru/привет, a error should occur at werkzeug._compat.wsgi_decoding_dance() because the path was not latin1 string. The utf-8 encoding followed by a latin-1 decoding is required by the WSGI specification[^1]. latin-1 is used as an encoding passthrought: that encoding has a representation for all the 256 bytes, i.e. it is impossible that decoding a text will raise a ValueError. The WSGI spec uses this trick to save values until the actual charset (present in the Content-Type header) in known. [^1]: https://peps.python.org/pep-3333/#a-note-on-string-types X-original-commit: 81e0f23 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#143234
add l10n_es_type 'ignore' on Subtract Base (DUA) -100% tax so that it can be ignored when creating Libros export enterprise-PR: https://github.com/odoo/enterprise/pull/51366 task-id: 3604971 Forward-Port-Of: odoo/odoo#143314
Original PR description
add l10n_es_type 'ignore' on Subtract Base (DUA) -100% tax so that it can be ignored when creating Libros export enterprise-PR: https://github.com/odoo/enterprise/pull/51366 task-id: 3604971 Forward-Port-Of: odoo/odoo#143314
Currently after confirmation on picking. The details operations button is mixed in the trash icon. The view needs a refresh to be correct. This is cleaned by moving all the buttons together and introducing the custom column before the last buttons group. 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:
Original PR description
Currently after confirmation on picking. The details operations button is mixed in the trash icon. The view needs a refresh to be correct. This is cleaned by moving all the buttons together and introducing the custom column before the last buttons group. 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#140663
Steps to reproduce: - Go to website (in "Edit" mode) > Drop a new popup snippet > Make it visible on all pages ("Show On" = "All Pages") > Save. - Add a new language (e.g. fr) > Try to translate the page > A warning is displayed: "Action 'get_page_option' was not able to be handled." - Try to save > The "save" button just keeps loading and the same warning is displayed again. Now let's try to do the following actions [1]: - Go to website (in "Edit" mode) > Drop a countdown snip
Original PR description
Steps to reproduce: - Go to website (in "Edit" mode) > Drop a new popup snippet > Make it visible on all pages ("Show On" = "All Pages") > Save. - Add a new language (e.g. fr) > Try to translate the…
Steps to reproduce:
- Go to website (in "Edit" mode) > Drop a new popup snippet > Make it
visible on all pages ("Show On" = "All Pages") > Save.
- Add a new language (e.g. fr) > Try to translate the page > A warning
is displayed: "Action 'get_page_option' was not able to be handled."
- Try to save > The "save" button just keeps loading and the same
warning is displayed again.
Now let's try to do the following actions [1]:
- Go to website (in "Edit" mode) > Drop a countdown snippet in the
footer > Set a conditional visibility on it (e.g. "Visibility" =
"Conditionally" = "Visible for Logged In") > Save.
- Try to translate the page > Save > We get the same error described
above.
Technical details:
Starting from [2], user has the possibility to translate invisible
blocks by allowing `_updateInvisibleDOM()` in "Translate" mode, which
makes them accessible in the edit bar.
In the case of an "All page" popup (The snippet is moved to the
`<footer/>` element to make it available on all pages...), the snippet
editor will be created with the parent's one (`<footer/>` in this
case) leading to the following behaviour when saving the page content
in "Translate" mode:
A- `cleanForSave()` called for all snippets...
B- `toggleTargetVisibility()` is then called for the `<footer/>` (which
doesn't have a `o_snippet_invisible` class).
C- `onTargetShow()` is consequently called allowing `_isShown()` to
check the footer visibility via the `get_page_option` action.
Since the navbar action widget (`ContentMenu` in this case) that handles
the action is not available in "Translate" mode, the action demand will
be aborted and we get the warning above.
Implemented solution:
- In "Edit" mode (for `s_popup` snippets):
The initial goal of this commit was to fix this behaviour by excluding
the parents when creation the `s_popup` editor in "Translate" mode.
But after some discussion, we prevent this behaviour for all `s_popup`
snippets (even in "Edit" mode) since they should not display their
parents options.
- In "Translate" mode (for all invisible snippets):
As described in [1], the issue will always occur if an invisible element
enables a parent option that needs action handers... And since we only
need to hide / display invisible elements to translate them, we also
prevent creating parents editors in "Translate" mode.
[2]: https://github.com/odoo/odoo/commit/04409af0571ed763c5712dbf857ea7dda81b2374
opw-3485565
Forward-Port-Of: odoo/odoo#143269
Forward-Port-Of: odoo/odoo#136160'field' is the name of a variable and shouldn't be translated Forward-Port-Of: odoo/odoo#143035 Forward-Port-Of: odoo/odoo#142809
Original PR description
'field' is the name of a variable and shouldn't be translated Forward-Port-Of: odoo/odoo#143035 Forward-Port-Of: odoo/odoo#142809
Prior to this commit, products without assigned categories were not displayed in the sales details report. This issue was due to the report's logic excluding products that did not fall under any specific POS category. This commit introduces a change where products without categories are now considered under a default category named "Not Categorized" in the sales report. This ensures that all products, regardless of category status, are accounted for and visible in the sales details, improving
Original PR description
Prior to this commit, products without assigned categories were not displayed in the sales details report. This issue was due to the report's logic excluding products that did not fall under any specific POS category. This commit introduces a change where products without categories are now considered under a default category named "Not Categorized" in the sales report. This ensures that all products, regardless of category status, are accounted for and visible in the sales details, improving the comprehensiveness and accuracy of the report. opw-3594985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142749
before PR: when searching a product that doesn't exist in the shop, the error message "no results found for ..." appears, but when searching another failed product, we hit the cache and the same "..." is displayed. after PR: avoid using the cache for the empty results message opw-3496581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143359
Original PR description
before PR: when searching a product that doesn't exist in the shop, the error message "no results found for ..." appears, but when searching another failed product, we hit the cache and the same "..." is displayed. after PR: avoid using the cache for the empty results message opw-3496581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143359
This commit fixes an issue where the quickcreate button was missing from the kanban view when it was grouped by a non many2one field and contained no record yet (so that no column is shown yet). Steps to reproduce: -Go to a kanban view on a model with no record -Group by as scalar value (eg: Description) ->The "New" button disappears OPW-3459808 Forward-Port-Of: odoo/odoo#143673 Forward-Port-Of: odoo/odoo#143355
Original PR description
This commit fixes an issue where the quickcreate button was missing from the kanban view when it was grouped by a non many2one field and contained no record yet (so that no column is shown yet). Steps to reproduce: -Go to a kanban view on a model with no record -Group by as scalar value (eg: Description) ->The "New" button disappears OPW-3459808 Forward-Port-Of: odoo/odoo#143673 Forward-Port-Of: odoo/odoo#143355
Steps to reproduce: - Install Stock and Project - Create a new project with current company as customer (3 dots menu on project overview to set the customer) - Create a new warehouse for the current company - Error pops Bug: since commit[1] check company is enforced on the project_id field of partners in bothways when creating a new warehouse CheckCompany fields are editted on the partner if set (property_stock_customer/supplier) the issue is if the partner's company_id is False while p
Original PR description
Steps to reproduce: - Install Stock and Project - Create a new project with current company as customer (3 dots menu on project overview to set the customer) - Create a new warehouse for the current…
Steps to reproduce: - Install Stock and Project - Create a new project with current company as customer (3 dots menu on project overview to set the customer) - Create a new warehouse for the current company - Error pops Bug: since commit[1] check company is enforced on the project_id field of partners in bothways when creating a new warehouse CheckCompany fields are editted on the partner if set (property_stock_customer/supplier) the issue is if the partner's company_id is False while project belongs to company "_check_company" fails Fix: Relax condition on check company to allow for company False to pass for corecords alternatives: - Set partner's company to the project company when adding it as a customer - Add a domain to only allow partners that belongs to the current company - Remove check company on project_ids from the partner's side opw-3507952 [1]:https://github.com/odoo/odoo/pull/109464 Forward-Port-Of: odoo/odoo#143679 Forward-Port-Of: odoo/odoo#138398
Steps to reproduce: - Enable the "Cookies bar" in website configuration > Go to website (Edit mode). - Select the cookies bar > Change its layout to "Popup" > The modal container becomes visible in edit mode only. The `#website_cookies_bar` element will automatically get one line height (equivalent to its current `line-height` value) because of the `contenteditable="true"` added to it, which makes it visible in edit mode (The container has this default height in all layouts, but it's
Original PR description
Steps to reproduce: - Enable the "Cookies bar" in website configuration > Go to website (Edit mode). - Select the cookies bar > Change its layout to "Popup" > The modal container becomes visible in edit mode only. The `#website_cookies_bar` element will automatically get one line height (equivalent to its current `line-height` value) because of the `contenteditable="true"` added to it, which makes it visible in edit mode (The container has this default height in all layouts, but it's hidden by the cookies bar content in "Discrete" and "Classic" modes). The goal of this commit is to simply hide this element to prevent this behaviour. Remark: The same issue occurred on a `.s_popup` parent with an inner `.modal` element and was fixed in [1] by keeping their visibility synchronized. [1]: https://github.com/odoo/odoo/commit/cfd53b8fae3ad9f677df49a03fe6d2945dbb5da2 linked to opw-3485565 Forward-Port-Of: odoo/odoo#143618 Forward-Port-Of: odoo/odoo#143221
Recent commit [1] in Odoo 15 (which is a backport of commit [2] which was merged in Odoo 17) introduced a security layer on forms but only for forms which are inside `ir.ui.view`. The forms inside HTML fields are thus not working anymore, because those don't receive the required signature. For the record: - `ir.ui.view` = `website.page` pages, some part of the controller pages - HTML fields = the most part of the editable areas in controller pages [1]: https://github.com/odoo/odoo/commit
Original PR description
Recent commit [1] in Odoo 15 (which is a backport of commit [2] which was merged in Odoo 17) introduced a security layer on forms but only for forms which are inside `ir.ui.view`. The forms inside HTML fields are thus not working anymore, because those don't receive the required signature. For the record: - `ir.ui.view` = `website.page` pages, some part of the controller pages - HTML fields = the most part of the editable areas in controller pages [1]: https://github.com/odoo/odoo/commit/17c6f6f30bf13bd3c303b28d9a314bd76dd8f4dc [2]: https://github.com/odoo/odoo/commit/7d25e7bf9243367c87b1b2005587ae728730b49c opw-3586333 Forward-Port-Of: odoo/odoo#143748 Forward-Port-Of: odoo/odoo#143139
Before this commit, a studio qunit test ("edit/delete menus") sometimes failed on runbot, because it tried to click on a button in a modal footer, but it found 3 of them, because another dialog which was expected to be closed at that moment, was still opened. There was no guarantee for the dialog to be closed because of the way browser.fetch was mocked. The fetching part was ok, but the function returned a Response object, whose `json` method is async (setTimeout-like async, i.e. "real" ticks
Original PR description
Before this commit, a studio qunit test ("edit/delete menus") sometimes failed on runbot, because it tried to click on a button in a modal footer, but it found 3 of them, because another dialog which…
Before this commit, a studio qunit test ("edit/delete menus") sometimes failed on runbot, because it tried to click on a button in a modal footer, but it found 3 of them, because another dialog which was expected to be closed at that moment, was still opened.
There was no guarantee for the dialog to be closed because of the way browser.fetch was mocked. The fetching part was ok, but the function returned a Response object, whose `json` method is async (setTimeout-like async, i.e. "real" ticks).
This commit mocks some functions of the returned Response instance to ensure that, by calling nextTick after a click or whatever, the fetch operation has been done, the body has been decoded, potential renderings are finished and the DOM has been patched.
Runbot error 23054
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#143813This traceback arises when the current day of the date is `31` , while the schedule action `(Generate Monthly Sales Closing)` runs. Scenarios to produce the issue: `[1]` * Imagine the `date_stop` value is `31-10-2023` * When the scheduled action `('Generate Monthly Sales Closing')` runs * The value of the `month_target` will be `9` and `year_target` remains same * The value of `interval_from` will be `31-09-2023` (an invalid date). `[2]` * Imagine the `date_stop` value is `31-03-2
Original PR description
This traceback arises when the current day of the date is `31` , while the schedule action `(Generate Monthly Sales Closing)` runs. Scenarios to produce the issue: `[1]` * Imagine the `date_stop`…
This traceback arises when the current day of the date is `31` ,
while the schedule action `(Generate Monthly Sales Closing)` runs.
Scenarios to produce the issue:
`[1]`
* Imagine the `date_stop` value is `31-10-2023`
* When the scheduled action `('Generate Monthly Sales Closing')` runs
* The value of the `month_target` will be `9` and `year_target` remains same
* The value of `interval_from` will be `31-09-2023` (an invalid date).
`[2]`
* Imagine the `date_stop` value is `31-03-2023`
* The value of `interval_from` will be `31-02-2023` (an invalid date)
It leads to the traceback
Error:
```
ValueError: day is out of range for month
File "odoo/tools/safe_eval.py", line 365, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(791,)", line 1, in <module>
File "addons/l10n_fr_pos_cert/models/account_closing.py", line 163, in _automated_closing
values = self._compute_amounts(frequency, company)
File "addons/l10n_fr_pos_cert/models/account_closing.py", line 77, in _compute_amounts
interval_dates = self._interval_dates(frequency, company)
File "addons/l10n_fr_pos_cert/models/account_closing.py", line 134, in _interval_dates
interval_from = date_stop.replace(year=year_target, month=month_target)
ValueError: <class 'ValueError'>: "day is out of range for month" while evaluating
"model._automated_closing('monthly')"
File "odoo/addons/base/models/ir_cron.py", line 373, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 688, in run
res = runner(run_self, eval_context=eval_context)
File "addons/website/models/ir_actions_server.py", line 61, in _run_action_code_multi
res = super(ServerAction, self)._run_action_code_multi(eval_context)
File "odoo/addons/base/models/ir_actions.py", line 558, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 379, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
See:-
https://github.com/odoo/odoo/blob/5fb9825384895fd303bd15c3e4f8dbc55d35904f/addons/l10n_fr_pos_cert/models/account_closing.py#L124-L134
After applying this commit, it will resolve the issue by calculating a valid date in all scenarios.
sentry-4589899768
Forward-Port-Of: odoo/odoo#140652Currently there is no margin between the top edge and the image below in the DIN5008 layout. Thus the image may be cut off when printing the page. This commit adds a 10mm margin. opw-3599133 Forward-Port-Of: odoo/odoo#143383
Original PR description
Currently there is no margin between the top edge and the image below in the DIN5008 layout. Thus the image may be cut off when printing the page. This commit adds a 10mm margin. opw-3599133 Forward-Port-Of: odoo/odoo#143383
This PR changes the 'cursor-like' icon visible on hovering over a dashboard in dashboard search panel to a 'pointing hand-like' icon. Task ID : 3597552 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142700
Original PR description
This PR changes the 'cursor-like' icon visible on hovering over a dashboard in dashboard search panel to a 'pointing hand-like' icon. Task ID : 3597552 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142700
Test was breaking during the night. Most likely due to the same issue as the one that odoo/odoo#131389 fixes, so we apply the same fix. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143921
Original PR description
Test was breaking during the night. Most likely due to the same issue as the one that odoo/odoo#131389 fixes, so we apply the same fix. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143921
The values in the "Total" measure are all displayed in the move currency. Due to this amounts in different currencies are added together. As a workaround we introduce the possibility to group by move currency. Thus the user can choose to seperate the values by currency. The "Total" column was renamed to "Total in Currency" to avoid confusion There is a remaining problem. The totals of the individual groups are still added up to form a total. Previously it was tried to convert the va
Original PR description
The values in the "Total" measure are all displayed in the move currency. Due to this amounts in different currencies are added together. As a workaround we introduce the possibility to group by move currency. Thus the user can choose to seperate the values by currency. The "Total" column was renamed to "Total in Currency" to avoid confusion There is a remaining problem. The totals of the individual groups are still added up to form a total. Previously it was tried to convert the values from the move currency to the move company currency and then to the active company currency. The problem is that there is no efficient way to do it correctly. task-3613358 Forward-Port-Of: odoo/odoo#143981 Forward-Port-Of: odoo/odoo#143834
Issue: ------ When we create a ticket from website form with an attachment, the portal user no longer has access to his attachment. This is problematic because he may think that it has not been sent correctly. Cause: ------ The document has no `access_token`. Solution: --------- Give an `acces_token` to the document linked to the ticket. In this way, the document will appear in the portal view's chat. opw-3601205 Forward-Port-Of: odoo/enterprise#51438
Original PR description
Issue: ------ When we create a ticket from website form with an attachment, the portal user no longer has access to his attachment. This is problematic because he may think that it has not been sent correctly. Cause: ------ The document has no `access_token`. Solution: --------- Give an `acces_token` to the document linked to the ticket. In this way, the document will appear in the portal view's chat. opw-3601205 Forward-Port-Of: odoo/enterprise#51438
MPS does not fully consider product variants. Steps to reproduce: - create component 1 - create component 2 - create finished product P, attribute 'version', values 'V1' & 'V2' - create bill of material for P with lines: - component 1 applying on variant 'V1' - component 2 applying on variant 'V2' - add P - V1 and its bom in MPS - add P - V2 and its bom in MPS - set forecasted demand of P - V1 to 10 : indirect demand forecast of component 1 goes to 10 : ok - set forecasted
Original PR description
MPS does not fully consider product variants.
Steps to reproduce:
- create component 1
- create component 2
- create finished product P, attribute 'version', values 'V1' & 'V2'
- create bill of material for P with lines:
- component 1 applying on variant 'V1'
- component 2 applying on variant 'V2'
- add P - V1 and its bom in MPS
- add P - V2 and its bom in MPS
- set forecasted demand of P - V1 to 10
: indirect demand forecast of component 1 goes to 10
: ok
- set forecasted demand of P - V2 to 10
: indirect demand forecast of component 2 goes to 20
: ! should be 10 !
task: 3556620
Forward-Port-Of: odoo/enterprise#51394Prior to this commit, inside the Point of Sale, clicking the Create button on the partner screen to create a new partner resulted in an error, preventing the creation process. This issue was traced back to the recent refactor of the 'formatFloat' function (https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8). The refactor changed '(value || 0)' to 'value', leading to problems when the value is undefined. This commit resolves the issue by ensuring that 'undefined' valu
Original PR description
Prior to this commit, inside the Point of Sale, clicking the Create button on the partner screen to create a new partner resulted in an error, preventing the creation process. This issue was traced back to the recent refactor of the 'formatFloat' function (https://github.com/odoo/odoo/commit/054ca0a19aaf297f420a1b478b93ae26f1b943b8). The refactor changed '(value || 0)' to 'value', leading to problems when the value is undefined. This commit resolves the issue by ensuring that 'undefined' values are properly handled and prevented from being sent during the partner creation process. opw-3594167 Forward-Port-Of: odoo/enterprise#51288
Following the quantity-pocalypse, the way quantities are counted in the stock moved lines have changed, meaning we can't simply add new move lines to the inter-company reception as it was done before. Instead clears the old move lines and replaces them with ones having values from the original delivery. Forward-Port-Of: odoo/enterprise#50281
Original PR description
Following the quantity-pocalypse, the way quantities are counted in the stock moved lines have changed, meaning we can't simply add new move lines to the inter-company reception as it was done before. Instead clears the old move lines and replaces them with ones having values from the original delivery. Forward-Port-Of: odoo/enterprise#50281
When looping over the tax in report line's tax_ids, sometimes the tax we receive is a group tax, which consist of 2 children tax inside it. They all have different id, and that causes the sheet_line_vals dictionary that depend on the id to be inaccurate. This commit register all of the children inside the tax group to the sheet_line_vals, by applying a `flatten_taxes_hierarchy` on the tax_ids This commit also adds an improvement where tax with l10n_es_type of 'ignore' are now ignored (for
Original PR description
When looping over the tax in report line's tax_ids, sometimes the tax we receive is a group tax, which consist of 2 children tax inside it. They all have different id, and that causes the sheet_line_vals dictionary that depend on the id to be inaccurate. This commit register all of the children inside the tax group to the sheet_line_vals, by applying a `flatten_taxes_hierarchy` on the tax_ids This commit also adds an improvement where tax with l10n_es_type of 'ignore' are now ignored (for example: DUA's 'Subtract Base' line), and DUA line should have a type of 'F5' instead in `exp_line_vals` community-PR: https://github.com/odoo/odoo/pull/143314 task-id: 3604971 Forward-Port-Of: odoo/enterprise#51366
Before this commit, default dates were used for renting. Launching this test just before midnight, start date and end dates are different, although the remaining of the test relies on the fact that hours are defined for the same day. This commit makes sure the renting start date is the same as the end date. Fixes build error 28629 Forward-Port-Of: odoo/enterprise#51567
Original PR description
Before this commit, default dates were used for renting. Launching this test just before midnight, start date and end dates are different, although the remaining of the test relies on the fact that hours are defined for the same day. This commit makes sure the renting start date is the same as the end date. Fixes build error 28629 Forward-Port-Of: odoo/enterprise#51567
Prior to this commit, when two preparation display received the same order, it was then impossible to delete this order as the order would come back to the first stage when trying to delete it. This is now solved by virtually hiding the order when it is deleted and really delete it when the order is deleted in all preparation display. Forward-Port-Of: odoo/enterprise#51260
Original PR description
Prior to this commit, when two preparation display received the same order, it was then impossible to delete this order as the order would come back to the first stage when trying to delete it. This is now solved by virtually hiding the order when it is deleted and really delete it when the order is deleted in all preparation display. Forward-Port-Of: odoo/enterprise#51260
The "Scan your badge" login option was not working properly when trying to log in to the POS shop. The barcode scanner styles were missing which caused the issue. opw-3509075 Forward-Port-Of: odoo/enterprise#48169
Original PR description
The "Scan your badge" login option was not working properly when trying to log in to the POS shop. The barcode scanner styles were missing which caused the issue. opw-3509075 Forward-Port-Of: odoo/enterprise#48169