Wednesday, December 20, 2023
19 changes · 17.0
Resolved issues and error corrections
The cart now shows the product reference price based on the unit price rather than the full line total. This prevents misleading price information when customers buy multiple quantities of the same product.
Original PR description
Before this commit, the product reference price was computed based on the total amount and not on the unit price. Now, the product reference price is computed based on the quotient of the total amount by the quantity.
This update fixes an internal automated test related to mail channel invitations. It helps prevent occasional false failures in the testing system, supporting more reliable development and releases without changing user-facing behavior.
Original PR description
This PR fixes a test that ensures the bus subscriptions are updated when a member is invited to a channel. This test waits some time before checking if the subscription is done. Sometimes, a tick is not enough and the test fails. This PR adds a deferred that resolves when the subscription is done that can be awaited to ensure the timing is always right. fixes runbot-46941
New live chats no longer trigger an unnecessary message-loading request immediately after creation. This reduces avoidable server calls and helps the live chat experience start more efficiently without changing visible behavior for users.
Original PR description
When a live chat is created on the server, the `/mail/thread/messages` route is called. This is not required since we know for a fact the thread was just created. This PR prevent this useless request. task-3646201
This update corrects wording in stock and manufacturing screens so users see clearer labels for where items are picked from and stored to. It also adjusts the byproduct list view to show the destination location, helping warehouse and manufacturing teams avoid confusion during operations.
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
This fix prevents an error when users remove the starting or ending value while editing account groups in Accounting. It makes the form handle empty range fields correctly, so users can continue creating or updating account groups without interruption.
Original PR description
This traceback arises when the user removes the `from` or `to` values. To reproduce this traceback: 1) Install `account_accountant` and make sure the debugger mode is on 2) Open…
This traceback arises when the user removes the `from` or `to` values.
To reproduce this traceback:
1) Install `account_accountant` and make sure the debugger mode is on
2) Open `Accounting/Configuration/Account Groups`
3) Create a new record
4) Give the `from` value and then remove the `to` value
Error:-
```
TypeError: '>' not supported between instances of 'str' and 'bool'
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 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "addons/web/models/models.py", line 1069, in onchange
todo = [
File "addons/web/models/models.py", line 1072, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1185, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6584, in __getitem__
return self._fields[key].__get__(self, type(self))
File "odoo/fields.py", line 1151, in __get__
self.recompute(record)
File "odoo/fields.py", line 1366, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1339, in apply_except_missing
func(records)
File "odoo/fields.py", line 1388, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4858, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 101, in determine
return needle(*args)
File "addons/account/models/account_account.py", line 841, in _compute_code_prefix_start
if not group.code_prefix_start or group.code_prefix_start > group.code_prefix_end:
```
When removing the `to` value `code_prefix_end` will be False.
It leads to the above traceback from here.
https://github.com/odoo/odoo/blob/230b680bf92583c9f5e4a3739be1d8602df44331/addons/account/models/account_account.py#L838-L842
sentry-4715927815Users can now edit existing labels in the Documents app without seeing an error. The fix opens the correct editing screen, helping teams maintain their document organization labels smoothly.
Original PR description
Steps to reproduce: - Install the documents app - Open it - Try to edit an existing label Issues: An error is displayed, and you cannot edit the label. Solution: Open the correct view for the model. opw-3637418
This fix improves error messages in the Knowledge module by displaying the article name when users encounter issues while moving articles. Previously, error messages were incomplete and didn't show which article caused the problem, making it harder for users to identify and resolve issues.
Original PR description
Some error message parameters were missing for the `move_to` operation, preventing the user from seeing the article name related to the erroneous operation. task-3640010 Forward-Port-Of: odoo/enterprise#52979 Forward-Port-Of: odoo/enterprise#52761
This update corrects how salary offers are displayed in the system. Previously, the offer display was showing the validity date, which was confusing. Now it correctly shows the creation date of the offer, making it clearer when the offer was actually created and sent to employees.
Original PR description
Currently, when sending an offer the display name of the offer uses the validity date of the offer instead of the create date. This commit fixes this as displaying the validity date does not make sense. task-3619108 Forward-Port-Of: odoo/enterprise#51959
This update resolves an issue where the self-assignment button was appearing twice in the Planning schedule form. The fix removes unnecessary user group restrictions on the button and ensures it properly respects visibility settings, providing a cleaner user interface.
Original PR description
Before this PR, header button for self assigning display twice inside the planning.slot form view. In this PR, fixes the issue by removing user group access on the button. as well as button get invisible on 'invisible' attribute condition and ignore 'attrs' conditions. task-3475975 Forward-Port-Of: odoo/enterprise#46462
This update removes unwanted extra spacing that was appearing in warning messages displayed during barcode scanning operations. The issue was caused by formatting characters in the message text and has been corrected to improve the visual presentation of these important user notifications.
Original PR description
Extra spacing was appearing between two sentences in warning message. Steps to reproduce: ------------------- * Install 'barcode' * On barcode, close the blue message under 'Barcode Scanning' Why the fix: ------------ Since 16.0 the message is shown in 'white-space: pre-wrap style'. Character '\ ' was causing extra spacing. NOTE: ----- The fix doesn't brake translations. Translations weren't working prior to the fix anyway. opw-3608979 Forward-Port-Of: odoo/enterprise#52927 Forward-Port-Of: odoo/enterprise#52867
Miscellaneous changes
Carriers with no/invalid/incompatible rules shouldn't be displayed in the checkout process. Cherry-picked from https://github.com/odoo/odoo/commit/5052b9e4a15155c694cf005fdf330997770c6cac and added tests. task-3284612 opw-3413820 Forward-Port-Of: odoo/odoo#146956 Forward-Port-Of: odoo/odoo#142136
Original PR description
Carriers with no/invalid/incompatible rules shouldn't be displayed in the checkout process. Cherry-picked from https://github.com/odoo/odoo/commit/5052b9e4a15155c694cf005fdf330997770c6cac and added tests. task-3284612 opw-3413820 Forward-Port-Of: odoo/odoo#146956 Forward-Port-Of: odoo/odoo#142136
The `test_01_shop_mail_tour` test was modified in commit [1] to make it independent of demo data. But the unique constraint on `domain` field (cf. commit [2]) make it break when run with 3 or more websites. This commit made the dummy domain assigned in this test non-unique, which doesn't alter the original meaning of the test but, allows to run it with multiple existing websites. Note: this fix is similar to commit [3]. runbot-52417 [1]: https://github.com/odoo/odoo/commit/ad6e975fb1
Original PR description
The `test_01_shop_mail_tour` test was modified in commit [1] to make it independent of demo data. But the unique constraint on `domain` field (cf. commit [2]) make it break when run with 3 or more websites. This commit made the dummy domain assigned in this test non-unique, which doesn't alter the original meaning of the test but, allows to run it with multiple existing websites. Note: this fix is similar to commit [3]. runbot-52417 [1]: https://github.com/odoo/odoo/commit/ad6e975fb1bf12c744764d40ed64e990bc0a9440 [2]: https://github.com/odoo/odoo/commit/507db4e179514d171ec82e8ea0cbaf2323a6c30d [3]: https://github.com/odoo/odoo/commit/0c522e42a82ec596e69611c556c4fc0d50e6e978 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146842
The balance check doesn't work when a line is being moved from one move to another because we never notified the move owning the lines at the start that the lines are being modified. To reproduce using a simple CSV to import: ```csv "line_ids/id","line_ids/product_id" "__export__.account_move_line_9_25fb2fbf","[FURN_7777] Office Chair" ``` To reproduce using a simple server action: ```python self.env['account.move'].create({'line_ids': [(4, 9)]}) ``` We now notify the original mo
Original PR description
The balance check doesn't work when a line is being moved from one move to another because we never notified the move owning the lines at the start that the lines are being modified.
To reproduce using a simple CSV to import:
```csv
"line_ids/id","line_ids/product_id"
"__export__.account_move_line_9_25fb2fbf","[FURN_7777] Office Chair"
```
To reproduce using a simple server action:
```python
self.env['account.move'].create({'line_ids': [(4, 9)]})
```
We now notify the original move also, triggering everything that needs to be triggered: sync of dynamic lines and the check for the balance.
Forward-Port-Of: odoo/odoo#146529When we start dragging an element with an open mega menu, the dropzones should only appear: - inside the mega menu: we therefore should not be able to drop a mega menu element outside of it. - after the clone of the element, so we can still drop it where we started the drag (if it does not come from the mega menu). This is well the case for normal dropzones but the grid dropzones case was forgotten. Some "clone dropzones" are also not added for inner contents that are in a grid mode snippe
Original PR description
When we start dragging an element with an open mega menu, the dropzones should only appear: - inside the mega menu: we therefore should not be able to drop a mega menu element outside of it. - after…
When we start dragging an element with an open mega menu, the dropzones should only appear: - inside the mega menu: we therefore should not be able to drop a mega menu element outside of it. - after the clone of the element, so we can still drop it where we started the drag (if it does not come from the mega menu). This is well the case for normal dropzones but the grid dropzones case was forgotten. Some "clone dropzones" are also not added for inner contents that are in a grid mode snippet. Steps to reproduce: 1) - Add a mega menu with the menu editor. - In edit mode, drop the "Text-Image" snippet and toggle the grid mode. - Open the mega menu and start dragging one of its columns (note that it toggles the grid mode). => A grid dropzone appeared in the "Text-Image" snippet, outside the mega menu. 2) - Drop an "Alert" snippet in "Text-Image". - Open the mega menu. - Start dragging the "Alert" snippet. => No dropzone appeared where we started the drag (so after the clone). This commit fixes these issues. The first issue is solved by properly filtering the `selectorGrids` when a modal or a dropdown (so the mega menu) is open. They were already filtered for the modal case (see commit [1] which was then refactored in [2]) but it should have been done in `_activateInsertionZones` at the already dedicated place, instead of before the call to this function in `_onDragAndDropStart`. This made the siblings and children selectors filtering redundant and this code was therefore removed. The second issue was happening because the "clone dropzone" was only added if there was no "closest" grid, instead of only checking the parent. This therefore prevented it for inner contents inside grid items instead of only for grid items. This commit fixes that. For the case where we are dragging a grid item (still with an open mega menu), a grid dropzone is added. [1]: https://github.com/odoo/odoo/commit/cc406afcea7bf5846233a9f97a4a8ac5f618f3ec [2]: https://github.com/odoo/odoo/commit/34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d task-3594979 Forward-Port-Of: odoo/odoo#145438
### Steps to reproduce issue: 1. Create two companies, **A** and **B**. 2. Create employee *X* in **A**. 3. Create a contract, assign it to *X* and change its state to Running. 4. Duplicate *X* to create employee *Y* 5. Change *Y*'s company to **B** (bypass warnings and errors). 6. Try to access Payroll Dashboard. 7. A Multi-Company access error is raised ### Explanation: When duplicating *X*, the value from `contract_id` is copied to *Y*. After *Y*'s company is changed to **B*
Original PR description
### Steps to reproduce issue: 1. Create two companies, **A** and **B**. 2. Create employee *X* in **A**. 3. Create a contract, assign it to *X* and change its state to Running. 4. Duplicate *X* to create employee *Y* 5. Change *Y*'s company to **B** (bypass warnings and errors). 6. Try to access Payroll Dashboard. 7. A Multi-Company access error is raised ### Explanation: When duplicating *X*, the value from `contract_id` is copied to *Y*. After *Y*'s company is changed to **B**, Payroll Dashboard tries to retrieve data from its `contract_id` and, the contract still being related to **A**, a Multi-Company access error occurs. ### Suggested fix: Preventing the value being copied solves the problem. It also lines up with the `contract_ids` not being copied. opw-3623483 Forward-Port-Of: odoo/odoo#146708 Forward-Port-Of: odoo/odoo#146156
Steps to reproduce --> 1) Have the Returns operation return type set to Delivery Order 2) Create an SO -> Deliver with a shipping carrier 3) Return the delivery and re-return with the same shipping carrier (need to manually update this field value) Solution --> Keep track of `next_moves` that have been accessed This PR is an extension of https://github.com/odoo/odoo/pull/142942 opw-3588205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-
Original PR description
Steps to reproduce --> 1) Have the Returns operation return type set to Delivery Order 2) Create an SO -> Deliver with a shipping carrier 3) Return the delivery and re-return with the same shipping carrier (need to manually update this field value) Solution --> Keep track of `next_moves` that have been accessed This PR is an extension of https://github.com/odoo/odoo/pull/142942 opw-3588205 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146590
The _search method of the portal search panel uses the currently selected dropdown item to retrieve the search criteria ; however, when using a search criteria that is not displayed in the dropdown menu, the replace method causes a traceback, since calling attr on the empty jquery selector object returns undefined. The _search method was changed to use optional chaining before accessing the replace method, and to replace the search_in value by an empty string in case the result of the express
Original PR description
The _search method of the portal search panel uses the currently selected dropdown item to retrieve the search criteria ; however, when using a search criteria that is not displayed in the dropdown menu, the replace method causes a traceback, since calling attr on the empty jquery selector object returns undefined. The _search method was changed to use optional chaining before accessing the replace method, and to replace the search_in value by an empty string in case the result of the expression is undefined. Forward-Port-Of: odoo/odoo#144329
This PR fixes a link issue on Safari. Because `<tr>` elements in this browser don't support `position: relative` and our links have a `.stretched-link` class, the last link in the list was the one being clicked wherever you clicked. We've also fixes some mobile issues such as the "New Post" button overflowing and the burger button alignment. | Before | After | |-----|-----| | <img width="380" alt="Screenshot 2023-11-28 at 10 14 20" src="https://github.com/odoo/odoo/assets/19491443/19475
Original PR description
This PR fixes a link issue on Safari. Because `<tr>` elements in this browser don't support `position: relative` and our links have a `.stretched-link` class, the last link in the list was the one…
This PR fixes a link issue on Safari. Because `<tr>` elements in this browser don't support `position: relative` and our links have a `.stretched-link` class, the last link in the list was the one being clicked wherever you clicked. We've also fixes some mobile issues such as the "New Post" button overflowing and the burger button alignment. | Before | After | |-----|-----| | <img width="380" alt="Screenshot 2023-11-28 at 10 14 20" src="https://github.com/odoo/odoo/assets/19491443/19475aaf-a736-4df7-b4bd-9d9cd68bd293"> | <img width="371" alt="Screenshot 2023-11-28 at 09 53 12" src="https://github.com/odoo/odoo/assets/19491443/c91da79f-e971-4f11-b7d7-39512e70b56d"> | Some changes have been made for the design to function better with the web editor. The breadcrumb for example : if ever the user were to change the size of the `h5` heading with the website builder, the `/` would not be the same size as the text preceding and following it. This is because the text is inside an `h5` but not the `/`. By removing the `h5` and giving the size to the wrapping parent element we fix this issue. | Before | After | |-----|-----| | <img width="329" alt="Screenshot 2023-11-28 at 10 08 05" src="https://github.com/odoo/odoo/assets/19491443/d50065af-af63-4cd8-bbeb-eb9e4ac7d797"> | <img width="444" alt="Screenshot 2023-11-28 at 10 08 53" src="https://github.com/odoo/odoo/assets/19491443/7efb11a4-2911-4032-991e-e82e90b5106f"> | task-3555851 Forward-Port-Of: odoo/odoo#139206
Since Chrome 120 (specifically Chromium build 1208985), an empty message is received from the CDT at the end of a test run, which obviously cannot be parsed as JSON. This is due to a fix made in Chromium [1] where ChromeDriver didn't send the CLOSE frame in response to the CLOSE frame sent by the client. The websocket-client library we use to talk with the CDT interprets this frame as a empty string when receiving message (cf. in `_core.py` [2]). As we don't need to interpret more com
Original PR description
Since Chrome 120 (specifically Chromium build 1208985), an empty message is received from the CDT at the end of a test run, which obviously cannot be parsed as JSON. This is due to a fix made in…
Since Chrome 120 (specifically Chromium build 1208985), an empty message is received from the CDT at the end of a test run, which obviously cannot be parsed as JSON. This is due to a fix made in Chromium [1] where ChromeDriver didn't send the CLOSE frame in response to the CLOSE frame sent by the client. The websocket-client library we use to talk with the CDT interprets this frame as a empty string when receiving message (cf. in `_core.py` [2]). As we don't need to interpret more complex low-level messages, this commit simply skips the empty message (which was already implicitly done in 15.0 [3]). [1]: https://bugs.chromium.org/p/chromedriver/issues/detail?id=4499 [2]: https://github.com/websocket-client/websocket-client/blob/69e470fee083cd4d5f42bccaff3a6168bfeee863/websocket/_core.py#L379-L399 [3]: https://github.com/odoo/odoo/blob/b5b069564c0a0246f3f263804088d40c3990633a/odoo/tests/common.py#L1169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146770