Monday, December 18, 2023
58 changes · master
Enhancements to existing features
Discuss conversations are now assigned to their sidebar categories automatically instead of being sorted after updates. This should make the sidebar handling more efficient and reliable without changing how users interact with Discuss or Live Chat.
Original PR description
*: im_livechat. Before this commit, discuss sidebar categories were filled by listening to thread updates. This is suboptimal since thread types never change. This commit make use of the discuss record inverses to assign the thread to its category automatically. part of task-3640730 enterprise: https://github.com/odoo/enterprise/pull/52888
This update removes an unused internal method from the base user management area. It helps keep the system code cleaner and easier to maintain, with no expected impact on day-to-day users.
Original PR description
Introduced at 774ea74c38
Mexico HR now uses the existing employee social security number field instead of keeping a separate Mexico-specific field. This reduces duplicate data entry and keeps employee records more consistent across the system.
Original PR description
- Remove l10n_mx_nss from hr.employee model since in that model already exists the field ssnid to save the social security number so it is not necessary to add another field just for Mexico. - Add ssnid field to the employee form instead of l10n_mx_nss. Original PR from Vauxoo: https://github.com/odoo/odoo/pull/145873 that we took on to add the required upgrade script.
The Mexican HR employee form now uses Odoo's existing social security number field instead of a separate Mexico-specific field. This avoids duplicate employee data and keeps social security information in one standard place.
Original PR description
- Remove l10n_mx_nss from hr.employee model since in that model already exists the field ssnid to save the social security number so it is not necessary to add another field just for Mexico. - Add ssnid field to the employee form instead of l10n_mx_nss. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds automated checks to ensure planning shifts keep their linked project, task, and sales order details when an archived employee's shifts are converted into open shifts. It also verifies that newly created resources receive an initials-based avatar, helping preserve clear scheduling information and resource identification.
Original PR description
This commit adds some tests for checking those behaviours :
- When an employee is archived, the project, task, SOL should be
copied when converting his shifts into open shifts
- When a resource is creatly on the fly, an avatar with their
initials should be automatically generated
taskid:3387301The worksheet template field on field service tasks is now hidden until a customer is selected and worksheets are enabled. This reduces confusion for project users by only showing the setting when it can actually be used.
Original PR description
Before these commit: When worksheet is enable and customer field is empty in project task, worksheet template field is visible in project task which confuses the project user where they still do not see the worksheet and when changing worksheet template field they need to select the customer field. After these commit: Now worksheet is enable and customer field is selected then worksheet template field is visible to project user in project task , and if customer field is not selected then worksheet template field will not visible to project user. task-3494496
Resolved issues and error corrections
This update makes automated tests less dependent on optional demo data across several Odoo apps. That helps reduce false failures and improves confidence that accounting, CRM, calendar, authentication, and other workflows behave consistently in different setups.
Code cleanup and technical improvements
This update streamlines how Odoo's Discuss and related chat features load conversation data. It reduces duplicated browser-side processing by using information already provided by the server, which should make the code easier to maintain without changing day-to-day user workflows.
Original PR description
Reduce LOCs in JS by relying more on server data to immediately insert in client-side modelling. In most cases the data were already complete enough.
Miscellaneous changes
Before this commit, when the user tried to quick create a record in a grouped kanban view (by clicking on the "+" icon of a column, for instance), and then clicked on the "Edit" button of the quick create, if the name_create rpc failed, the webclient switched to the form view and an error was displayed. The displayed error was about a destroyed component trying to do an rpc, namely the kanban controller. This is because it does 2 things when the name_create failed: it opened the form view in
Original PR description
Before this commit, when the user tried to quick create a record in a grouped kanban view (by clicking on the "+" icon of a column, for instance), and then clicked on the "Edit" button of the quick…
Before this commit, when the user tried to quick create a record in a grouped kanban view (by clicking on the "+" icon of a column, for instance), and then clicked on the "Edit" button of the quick create, if the name_create rpc failed, the webclient switched to the form view and an error was displayed. The displayed error was about a destroyed component trying to do an rpc, namely the kanban controller. This is because it does 2 things when the name_create failed: it opened the form view in a dialog and it also switched to the form view. The latter was unwanted: in case of errors, we don't want to switch to the form view but rather to quick create from a dialog. The error was actually caused by a small mistake: we use the record variable to determine if the quick create succeeded and if we can switch to the quick created record. However, that same variable was already set before, for another purpose. OPW 3620671 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#145981 Forward-Port-Of: odoo/odoo#145877
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 update makes automated tests less dependent on preloaded demo data, so they produce more consistent results across environments. It helps reduce false failures and improves confidence when validating accounting, appointments, delivery, documents, and other business workflows.
Cohort reports now keep their action buttons visible even when filters or measure changes return no data. This helps users adjust the report without getting stuck on an empty-results screen.
Original PR description
This commit fixes an issue with the cohort view buttons which are not accessible when there is no data to display. This is annoying because it may happen when one changes the measures of the cohort view to one that won't display any data. This case has become quite common since https://github.com/odoo/enterprise/pull/46693/commits/684754430bc7062d7b69ea5b37e8aadc808c225c due to the fact that rows of null values are no longer sent by the python to be displayed in the cohort. The fix here is therefore to move the cohort view buttons from the renderer to the controller so that they can be displayed above the no content helper and are therefore always visible even when the renderer is not present due to empty data. Steps to reproduce: - go to any cohort view (ex: Helpdesk -> Reporting -> Tickets Analysis) - filter records with a giberish filter task-3626278
Issue: ====== When we have a product with `out of stock:continue selling` disabled, accessing the shop page will give an access error. Steps to reproduce the issue: ============================= - Make sure to have a storable product with `out of stock: continue selling` disabled in the sales tab of the product. - Log out and go to shop - Access error related to warehouse records Origin of the issue: ==================== The function `_website_show_quick_add` being called from the
Original PR description
Issue: ====== When we have a product with `out of stock:continue selling` disabled, accessing the shop page will give an access error. Steps to reproduce the issue: ============================= - Make sure to have a storable product with `out of stock: continue selling` disabled in the sales tab of the product. - Log out and go to shop - Access error related to warehouse records Origin of the issue: ==================== The function `_website_show_quick_add` being called from the template in odoo/addons/website_sale/views/templates.xml to display the shopping card button in at the bottom of the product. Since the user is public he doesn't have the right to access the record in warehouse to see if the product is out of stock or not. The test `test_back_in_stock_notification_product` already tests the fix and doesn't work without this fix , so no need to add extra test. opw-3620172 Forward-Port-Of: odoo/odoo#145916
Description of the issue/feature this PR addresses: Within the project task form view, in the timesheet notebook, the "Remaining Hours on SO" label becomes misaligned when the planned hours are set to 0. Fix: To ensure proper alignment, add a condition for the label. task:3468392 Forward-Port-Of: odoo/odoo#146334 Forward-Port-Of: odoo/odoo#134078
Original PR description
Description of the issue/feature this PR addresses: Within the project task form view, in the timesheet notebook, the "Remaining Hours on SO" label becomes misaligned when the planned hours are set to 0. Fix: To ensure proper alignment, add a condition for the label. task:3468392 Forward-Port-Of: odoo/odoo#146334 Forward-Port-Of: odoo/odoo#134078
Since [1] when website was moved to backend, with the introduction of the iframe, the preset previews are replicating the CSS of the page. In [2] the mechanism was adapted to make it faster, but in the new replication the `border-color` of buttons was wrongly copied from the `background-color` of the buttons. This commit uses the right variable instead. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b [2]: https://github.com/odoo/odoo/commit/7f5a9d04034804
Original PR description
Since [1] when website was moved to backend, with the introduction of the iframe, the preset previews are replicating the CSS of the page. In [2] the mechanism was adapted to make it faster, but in the new replication the `border-color` of buttons was wrongly copied from the `background-color` of the buttons. This commit uses the right variable instead. [1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b [2]: https://github.com/odoo/odoo/commit/7f5a9d040348048990b25c271875c77d2c314e4d task-3642550 Forward-Port-Of: odoo/odoo#146510
### Steps to reproduce issue: 1. Select non english language 2. Open a POS session 3. Select a product 4. Got to payment UI 5. "Customer" is not translated ### Explanation: Concerned element uses a `t-out` with an `or` operator, translation can not apply to it. ### Suggested fix: Use of distinct tags with `t-if` and `t-else` instead, to make translation work. (Due to a field having the same key and the affected file already being referenced, the .pot file does not need upda
Original PR description
### Steps to reproduce issue: 1. Select non english language 2. Open a POS session 3. Select a product 4. Got to payment UI 5. "Customer" is not translated ### Explanation: Concerned element uses a `t-out` with an `or` operator, translation can not apply to it. ### Suggested fix: Use of distinct tags with `t-if` and `t-else` instead, to make translation work. (Due to a field having the same key and the affected file already being referenced, the .pot file does not need updates.) opw-3636234 Forward-Port-Of: odoo/odoo#146292
### Summary Currently, when you send an invoice, every recipient receives the link including the access token. Only the invoice's customer and manually added recipients should receive the token. ### Steps to reproduce * Create and validate an invoice * Add a follower `F `to the invoice * Click on the Send & Print button, then add a recipient `R` who is not the customer associated with the invoice * Proceed to send the invoice. * Access the emails that were sent * Using an incogn
Original PR description
### Summary Currently, when you send an invoice, every recipient receives the link including the access token. Only the invoice's customer and manually added recipients should receive the token. ###…
### Summary Currently, when you send an invoice, every recipient receives the link including the access token. Only the invoice's customer and manually added recipients should receive the token. ### Steps to reproduce * Create and validate an invoice * Add a follower `F `to the invoice * Click on the Send & Print button, then add a recipient `R` who is not the customer associated with the invoice * Proceed to send the invoice. * Access the emails that were sent * Using an incognito or private browsing window, open the `View Invoice` link for each of the 3 recipients. You should see that all the links give access to the invoice. What should happen is that only partner `R` and the invoice's customer should haveaccess to the invoice. `F` should be asked to login. ### Cause Issue was introduced by https://github.com/odoo/odoo/commit/95c585f67bd37e1202c57b3e9eed09b0a964472c ### Fix Add a new notification group for partners that were manually added as recipients, and give that group access to the invoice. opw-3385302 Forward-Port-Of: odoo/odoo#146496 Forward-Port-Of: odoo/odoo#142473
[FIX] web_editor: close iframe document after write [FIX] web_editor: remove observerUnactive before adding tooltip task-3537756 This PR is the 17.0+ version of https://github.com/odoo/odoo/pull/138039. While the changes are essentially the same, the motivation (commit messages) changed, due to the fact that, in 17.0: - the use of Bootstrap tooltip.js was replaced by web/'s own Tooltip component - the module loader error report relies on the same `document.readyState` to be "complete"
Original PR description
[FIX] web_editor: close iframe document after write [FIX] web_editor: remove observerUnactive before adding tooltip task-3537756 This PR is the 17.0+ version of https://github.com/odoo/odoo/pull/138039. While the changes are essentially the same, the motivation (commit messages) changed, due to the fact that, in 17.0: - the use of Bootstrap tooltip.js was replaced by web/'s own Tooltip component - the module loader error report relies on the same `document.readyState` to be "complete" (or the "DOMContentLoaded" event) in order to display the error message. Forward-Port-Of: odoo/odoo#141882
Earlier PR improved ACLs in Discuss [1]. Route `/mail/load_message_failures` was made in non-sudo as to take ACLs into account, so that we don't get mail failures that we don't have access [2] However, checking ACLs on `mail.message` from `search` on `mail.notification` is very slow [3], to the point where the RPC takes minutes and results in a `memoryerror`. Ideally we should have non-sudo and make checking ACLs more performant. As a quick fix in a stable version, we revert to using `s
Original PR description
Earlier PR improved ACLs in Discuss [1]. Route `/mail/load_message_failures` was made in non-sudo as to take ACLs into account, so that we don't get mail failures that we don't have access [2] However, checking ACLs on `mail.message` from `search` on `mail.notification` is very slow [3], to the point where the RPC takes minutes and results in a `memoryerror`. Ideally we should have non-sudo and make checking ACLs more performant. As a quick fix in a stable version, we revert to using `sudo`, which results in same quick results as before. [1]: https://github.com/odoo/odoo/pull/138330 [2]: https://github.com/odoo/odoo/pull/138330/files#diff-6be51f3695e69474a19cf6857370c8bb9b529a15d568952258cec9a0ae519fc4R23 [3]: https://github.com/odoo/odoo/blob/17.0/addons/mail/models/res_partner.py#L251 Forward-Port-Of: odoo/odoo#146184
This PR improves phone_validation tooling * fix issue when adding or removing a 'phone.blacklist' record with a void number; * improve parsing, try to be defensive with input number to recover from some commonly found issues with '+' or '00' prefixes; * add tooling to extract region information from a number. See sub commits for more details. Task-3608129 (Whatsapp: Moultifix !) Forward-Port-Of: odoo/odoo#146398 Forward-Port-Of: odoo/odoo#145554
Original PR description
This PR improves phone_validation tooling
* fix issue when adding or removing a 'phone.blacklist' record
with a void number;
* improve parsing, try to be defensive with input number to recover
from some commonly found issues with '+' or '00' prefixes;
* add tooling to extract region information from a number.
See sub commits for more details.
Task-3608129 (Whatsapp: Moultifix !)
Forward-Port-Of: odoo/odoo#146398
Forward-Port-Of: odoo/odoo#145554After the previous fix introducing a deepcopy, the pregenerate of the assets became slower because of the many call to get_manifest (in loop, recursively) Since the manifest is immutable here and won't go outside of the call, we can use the lower level version. Forward-Port-Of: odoo/odoo#145965 Forward-Port-Of: odoo/odoo#144723
Original PR description
After the previous fix introducing a deepcopy, the pregenerate of the assets became slower because of the many call to get_manifest (in loop, recursively) Since the manifest is immutable here and won't go outside of the call, we can use the lower level version. Forward-Port-Of: odoo/odoo#145965 Forward-Port-Of: odoo/odoo#144723
Description of the issue/feature this PR addresses: Change the accuracy of https://github.com/odoo/odoo/blob/2c5ce41c423e6ab92053b1f082086035bdc151f8/addons/product/data/product_data.xml#L37 Current behavior before PR: The accuracy of Min. Quantity of pricelist rules does not change Desired behavior after PR is merged: The accuracy of Min. Quantity of pricelist rules is changed EDIT: same with field `product.supplierinfo.min_qty` (https://github.com/odoo/odoo/blob/3363e55cac2a121c29
Original PR description
Description of the issue/feature this PR addresses: Change the accuracy of https://github.com/odoo/odoo/blob/2c5ce41c423e6ab92053b1f082086035bdc151f8/addons/product/data/product_data.xml#L37 Current behavior before PR: The accuracy of Min. Quantity of pricelist rules does not change Desired behavior after PR is merged: The accuracy of Min. Quantity of pricelist rules is changed EDIT: same with field `product.supplierinfo.min_qty` (https://github.com/odoo/odoo/blob/3363e55cac2a121c29842a0b2463f940bdd866a4/addons/product/models/product_supplierinfo.py#L45), noticed thanks to https://github.com/odoo/odoo/pull/145191#pullrequestreview-1771801838 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145191
**Description of the issue/feature this PR addresses**: Add groups to product tree view to prevent ACLs error with quantity fields. **Current behavior before PR**: - Create a product A. - Update the available quantity of the product. - Create a basic user without Inventory permissions. - Go to the product list (`product.product` or `product.template`) and get an error when access to stock.move records to set the `qty_available` field (for example). **Desired behavior after PR is merge
Original PR description
**Description of the issue/feature this PR addresses**: Add groups to product tree view to prevent ACLs error with quantity fields. **Current behavior before PR**: - Create a product A. - Update the available quantity of the product. - Create a basic user without Inventory permissions. - Go to the product list (`product.product` or `product.template`) and get an error when access to stock.move records to set the `qty_available` field (for example). **Desired behavior after PR is merged**: No `stock.move` access error displayed in product list. @Tecnativa TT45220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142472 Forward-Port-Of: odoo/odoo#136603
This traceback arises when the user tries to click on 'Lot/ serial Number' in Create Move Line To reproduce this issue: 1. install `stock` 2. Open `inventory>products>Lots/Serial Numbers` 3. create a product `A` in the current serial number 4. Try to save the record `operations>transfers>deliveries` 5. Create a new record in current product `A` try to save the record and click on `Mark as Todo` 6. In the stock picking view open stock move 7. Add a line from the current produc
Original PR description
This traceback arises when the user tries to click on 'Lot/ serial Number' in Create Move Line To reproduce this issue: 1. install `stock` 2. Open `inventory>products>Lots/Serial Numbers` 3. create a…
This traceback arises when the user tries to click on 'Lot/ serial Number' in Create Move Line
To reproduce this issue:
1. install `stock`
2. Open `inventory>products>Lots/Serial Numbers`
3. create a product `A` in the current serial number
4. Try to save the record `operations>transfers>deliveries`
5. Create a new record in current product `A` try to save the record and click
on `Mark as Todo`
6. In the stock picking view open stock move
7. Add a line from the current product `A`
8. Click on new and give the value of `Lot/serial Number` in Create Move Line
ValueError:
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5830, in ensure_one
_id, = self._ids
ValueError: Expected singleton: stock.quant(5, 24)
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 1062, in onchange
record._apply_onchange_methods(field_name, result)
File "odoo/models.py", line 6884, in _apply_onchange_methods
res = method(self)
File "addons/stock/models/stock_quant.py", line 920, in _onchange_location_or_product_id
self.quantity = quant.filtered(lambda q: q.lot_id == self.lot_id).quantity
File "odoo/fields.py", line 1147, in __get__
record.ensure_one()
File "odoo/models.py", line 5833, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
when the user tries to click on 'Lot/serial Number' in Create Move Line
a value error occurs because getting many values excepted single value
Which leads to the traceback from here
https://github.com/odoo/odoo/blob/230b680bf92583c9f5e4a3739be1d8602df44331/addons/stock/models/stock_quant.py#L905-L929
After applying this commit will resolve the issue of getting a sum of quantity mapped with the quant
sentry-4715604118
Forward-Port-Of: odoo/odoo#146152Before this PR: Since the record marked as archived, the allowed_records does not stores that particular record which ultimately results in lost activites. After this PR: Activities made on the archived record are allowed and shown in the system-tray activity menu. task-3458597 Forward-Port-Of: odoo/odoo#146462 Forward-Port-Of: odoo/odoo#138783
Original PR description
Before this PR: Since the record marked as archived, the allowed_records does not stores that particular record which ultimately results in lost activites. After this PR: Activities made on the archived record are allowed and shown in the system-tray activity menu. task-3458597 Forward-Port-Of: odoo/odoo#146462 Forward-Port-Of: odoo/odoo#138783
This commit fixes 2 issues with the domain in field tooltips, in debug mode. 1) it only displayed the domain defined on the field in the model, not the domain set in attrs in the view, if any. 2) when the domain was the empty array, `domain: ` was displayed. opw 3455119 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/sub
Original PR description
This commit fixes 2 issues with the domain in field tooltips, in debug mode. 1) it only displayed the domain defined on the field in the model, not the domain set in attrs in the view, if any. 2) when the domain was the empty array, `domain: ` was displayed. opw 3455119 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#146563 Forward-Port-Of: odoo/odoo#146443
**Steps to reproduce:** - open kanban view of department from employee module. - click on 'Allocation Requests' and 'Time Off Requests'. --- **Issue:** - When viewing the department's allocation and time-off requests in the employee module, all department data is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate
Original PR description
**Steps to reproduce:** - open kanban view of department from employee module. - click on 'Allocation Requests' and 'Time Off Requests'. --- **Issue:** - When viewing the department's allocation and time-off requests in the employee module, all department data is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate department-specific request information. Task-3541358 Forward-Port-Of: odoo/odoo#145334 Forward-Port-Of: odoo/odoo#138992
Before this commit, columns in list views could be manually resized only if there were records in the table. For the ungrouped case it makes sense, as the table is empty anyway. However, for the grouped case (either with empty groups, or with all groups being folded), the list contains no records, but resizing could make sense as there could be aggregate values displayed on group headers. Technically speaking, there's no reason to restrict the resize feature if the table is empty. Functionall
Original PR description
Before this commit, columns in list views could be manually resized only if there were records in the table. For the ungrouped case it makes sense, as the table is empty anyway. However, for the…
Before this commit, columns in list views could be manually resized only if there were records in the table. For the ungrouped case it makes sense, as the table is empty anyway. However, for the grouped case (either with empty groups, or with all groups being folded), the list contains no records, but resizing could make sense as there could be aggregate values displayed on group headers. Technically speaking, there's no reason to restrict the resize feature if the table is empty. Functionally wise, a user could get confused if the feature is sometimes available, and sometimes not. For that reason, this commit simply removes the isEmpty condition, meaning that resizing columns is now always available, even if the table is empty. Task 3621490 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#144767
On device which are primarily recognized as "touch", when using a mouse-like pointer, the tooltip can't be opened both on "touch" and on "hover" (withe the mouse). This commit fixes it by removing the escaping that prevented the mouse events' listeners from being registered on touch-enabled devices. Steps to reproduce: 1. Using Chrome, open the developer tools and click on "Toggle device toolbar" 2. Install Contacts 3. Go to Contacts and open the form view of any contact 4. Now
Original PR description
On device which are primarily recognized as "touch", when using a mouse-like pointer, the tooltip can't be opened both on "touch" and on "hover" (withe the mouse). This commit fixes it by removing the escaping that prevented the mouse events' listeners from being registered on touch-enabled devices. Steps to reproduce: 1. Using Chrome, open the developer tools and click on "Toggle device toolbar" 2. Install Contacts 3. Go to Contacts and open the form view of any contact 4. Now click again on "Toggle device toolbar" to disable it but do not reload the page: touch device capabilities will be loaded but you will be able to use a mouse 5. Click on the question mark next to "Tax ID", nothing happens opw-3493571 Forward-Port-Of: odoo/odoo#140263
[FIX] website: fix button snippet The commit [1] of this PR [2] has been merged requesting some changes to be made later, which are fixes to the button that can now be dropped onto the page from the snippet menu. This commit makes the following changes requested: - Before this commit, when we duplicated a button (by clicking on the "duplicate" button), the style of the new button was generated again in Javascript in the "_adaptButtons" function even though it is not necessary since
Original PR description
[FIX] website: fix button snippet The commit [1] of this PR [2] has been merged requesting some changes to be made later, which are fixes to the button that can now be dropped onto the page from the…
[FIX] website: fix button snippet The commit [1] of this PR [2] has been merged requesting some changes to be made later, which are fixes to the button that can now be dropped onto the page from the snippet menu. This commit makes the following changes requested: - Before this commit, when we duplicated a button (by clicking on the "duplicate" button), the style of the new button was generated again in Javascript in the "_adaptButtons" function even though it is not necessary since we duplicate the HTML of the copied button. That is why this commit adds the "adaptAppearance" parameter for the "_adaptButtons" function. - Prior to this commit, when a button was dropped between two buttons, the style of the next button was copied as a priority. After this commit , the style of the previous button is now copied as a priority. [1]: https://github.com/odoo/odoo/commit/507b80a12574ce19bcb925d88868fb377b1c4b06 [2]: https://github.com/odoo/odoo/pull/126717 task-3555413 Forward-Port-Of: odoo/odoo#139621
Description: payslip state label description was not visible inside form view of timeoff Improvement: after adding widget payslip state label description is made visible. task-3475416 Forward-Port-Of: odoo/odoo#136901
Original PR description
Description:
payslip state label description was not visible inside form view of timeoff
Improvement:
after adding widget payslip state label description is made visible.
task-3475416
Forward-Port-Of: odoo/odoo#136901The Content-Security-Policy[^1] http header was only set on the response generated by controllers but it was missing from the `/<module>/static/` route. It is not strictly necessary to set that header on the responses comming from that routes as it is not possible to add new static files or edit existing ones via the interface (not even as admin). Only the developers and system administrator can access those files. It is also worth mentionning that using the Odoo internal web server to del
Original PR description
The Content-Security-Policy[^1] http header was only set on the response generated by controllers but it was missing from the `/<module>/static/` route. It is not strictly necessary to set that header on the responses comming from that routes as it is not possible to add new static files or edit existing ones via the interface (not even as admin). Only the developers and system administrator can access those files. It is also worth mentionning that using the Odoo internal web server to deliver static files is suboptimal. Outside of a dev environment, those files will typically be delivered via a web server[^2] and sysadmins should configure their web server to set the CSP header on static images. [^1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP [^2]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachments Forward-Port-Of: odoo/odoo#131700
The `test_01_multi_domain_assets_generation` was introduced in PR [1]. But afterward, the commit [2] introduced a unique constraint on the `domain` field. With this additional constraint, this test broke when run with multiple existing websites as it assigns the same domain for each of them. 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. [1]: https://github
Original PR description
The `test_01_multi_domain_assets_generation` was introduced in PR [1]. But afterward, the commit [2] introduced a unique constraint on the `domain` field. With this additional constraint, this test broke when run with multiple existing websites as it assigns the same domain for each of them. 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. [1]: https://github.com/odoo/odoo/pull/118526 [2]: https://github.com/odoo/odoo/commit/507db4e179514d171ec82e8ea0cbaf2323a6c30d runbot-20848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145370
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#146650
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#146650
Steps: - Open Planning - Select configuration, then roles - In Roles search action - Avatars are not correctly displayed in the action helper Issue: - In action helper the avatars are not correctly displayed and avatar is not displayed when there is no demo data. Cause: - For images, we need to add the newly added 'o_avatar' class, which is currently missing in the image tag. - we use a dynamic image source link for the avatar, and that's why it doesn't display when there
Original PR description
Steps: - Open Planning - Select configuration, then roles - In Roles search action - Avatars are not correctly displayed in the action helper Issue: - In action helper the avatars are not correctly displayed and avatar is not displayed when there is no demo data. Cause: - For images, we need to add the newly added 'o_avatar' class, which is currently missing in the image tag. - we use a dynamic image source link for the avatar, and that's why it doesn't display when there is no demo data Fix: - By adding the Bootstrap class to the image tag, avatars are displayed correctly. - By providing a static source link for the image, the avatar is displayed even when there is no demo data task-3491748 Forward-Port-Of: odoo/enterprise#47351
**HOW TO REPRODUCE:** - Open timesheet - Go to All timesheets - Add a line for a user and set a date corresponding to the saturday visible on the grid views - save and close **--> ISSUE**: Notification is displayed and we need a refresh to display the created line **FIX:** - delete condition that prevent rerender. This condition was checking if the selected date was the last visible day in the grid view (i.e. saturday) taskid:360
Original PR description
**HOW TO REPRODUCE:**
- Open timesheet
- Go to All timesheets
- Add a line for a user and set a date corresponding to the saturday
visible on the grid views
- save and close
**--> ISSUE**: Notification is displayed and we need a refresh to
display the created line
**FIX:**
- delete condition that prevent rerender. This condition was
checking if the selected date was the last visible day in the grid
view (i.e. saturday)
taskid:3609373
Forward-Port-Of: odoo/enterprise#51407Some condition in the helpdesk team dashboard kanban-menu prevented to display some options if the widget was not editable by the user, which makes sense for the settings/color options but not that much for the View > tickets or Reporting > Tickets Analysis/ SLA Status Analysis since those are available in the Rporting menu anyway In terms of implementation: Removed the widget.editable condition for those Changed the style for the Reporting column to take as much place has needed, this shou
Original PR description
Some condition in the helpdesk team dashboard kanban-menu prevented to display some options if the widget was not editable by the user, which makes sense for the settings/color options but not that much for the View > tickets or Reporting > Tickets Analysis/ SLA Status Analysis since those are available in the Rporting menu anyway In terms of implementation: Removed the widget.editable condition for those Changed the style for the Reporting column to take as much place has needed, this shoudl prevent the longer text from shrinking and won't change anythin if the colorpicker/Settings menu are available for the user Task-3599248 Forward-Port-Of: odoo/enterprise#51146
Steps: - Open Field service - In configuration worksheet template - Then Device Installation and Maintenance - Design template - In the view,show invisible Elements Then - Select text And Close,after refresh Issue: - When we enter a string without spaces, it shows as a single line. However, when we enter a string with spaces, it appears on another line. - The width of the title line is very small Cause: - Because we given the 'oe_title' class inside of the group, Accordin
Original PR description
Steps: - Open Field service - In configuration worksheet template - Then Device Installation and Maintenance - Design template - In the view,show invisible Elements Then - Select text And Close,after refresh Issue: - When we enter a string without spaces, it shows as a single line. However, when we enter a string with spaces, it appears on another line. - The width of the title line is very small Cause: - Because we given the 'oe_title' class inside of the group, According to the 'Web-form group' when we given in side of the group it is effecting Fix: - Removing the group for the 'oe_title',The issue is resolved and Add the 'text-break' class the title is overflow when we given without space task-3512366 Forward-Port-Of: odoo/enterprise#47895
To reproduce ============ - create task in Fields service and share it with portal user - portal user gets server error when opening the task Problem ======= the template `portal_my_task` in `industry_fsm` uses some fields that are not defined in `industry_fsm` a feature was reverted in `industry_fsm` and this code part was inadvertently left in wrong place, and this commit corrects that oversight. See https://github.com/odoo/enterprise/pull/44632 opw-3630553 Forward-Port-Of: od
Original PR description
To reproduce ============ - create task in Fields service and share it with portal user - portal user gets server error when opening the task Problem ======= the template `portal_my_task` in `industry_fsm` uses some fields that are not defined in `industry_fsm` a feature was reverted in `industry_fsm` and this code part was inadvertently left in wrong place, and this commit corrects that oversight. See https://github.com/odoo/enterprise/pull/44632 opw-3630553 Forward-Port-Of: odoo/enterprise#52870
When the partner is not set on the statement line but retrieved in another way (partner's name, bank account etc), the suggested account on the auto_balance line should be the ones coming from the retrieved partner. Forward-Port-Of: odoo/enterprise#52894 Forward-Port-Of: odoo/enterprise#52691
Original PR description
When the partner is not set on the statement line but retrieved in another way (partner's name, bank account etc), the suggested account on the auto_balance line should be the ones coming from the retrieved partner. Forward-Port-Of: odoo/enterprise#52894 Forward-Port-Of: odoo/enterprise#52691
Description : payslip state label description was not visible inside form view of timeoff Improvement: after adding widget payslip state label description is made visible. taskID:3475416 Forward-Port-Of: odoo/enterprise#48060
Original PR description
Description : payslip state label description was not visible inside form view of timeoff Improvement: after adding widget payslip state label description is made visible. taskID:3475416 Forward-Port-Of: odoo/enterprise#48060
### Version 16.0 ### Steps to reproduce: 1. Create a sale order with a non-recurring product. 2. Click on the send by email button then send email. 3. Add recurring product and recurrence in the sale order and save it. 4. Remove recurrence and recurring product from the sale order, then click on save manually. ### Issue: Error raised after removing both recurring products and recurring in quotation send state and not able to save the record. ### Cause: While saving the sale o
Original PR description
### Version 16.0 ### Steps to reproduce: 1. Create a sale order with a non-recurring product. 2. Click on the send by email button then send email. 3. Add recurring product and recurrence in the sale order and save it. 4. Remove recurrence and recurring product from the sale order, then click on save manually. ### Issue: Error raised after removing both recurring products and recurring in quotation send state and not able to save the record. ### Cause: While saving the sale order, the recurring product is not deleted from the database, it is only removed from the UI. ### Solution: While updating the record, it does not check for recurrence and recurring products in the quotation sent state. (fixed point-4) task-3501381 Forward-Port-Of: odoo/enterprise#52044 Forward-Port-Of: odoo/enterprise#48277
Update of CNSS rule to follow the law : https://www.cnss.ma/fr/content/paiement-de-vos-cotisations-sociales paragraph : Barèmes et taux de cotisation Add some tests about this issue task : 3498945 Forward-Port-Of: odoo/enterprise#52260 Forward-Port-Of: odoo/enterprise#49741
Original PR description
Update of CNSS rule to follow the law : https://www.cnss.ma/fr/content/paiement-de-vos-cotisations-sociales paragraph : Barèmes et taux de cotisation Add some tests about this issue task : 3498945 Forward-Port-Of: odoo/enterprise#52260 Forward-Port-Of: odoo/enterprise#49741
Opening the Shop Floor from a workorder failed because the workcenter list may be empty (local storage not initialised) or not containing the workorder's workcenter. This commit ensures the workcenter related to the active workorder is selected at the shop floor opening Forward-Port-Of: odoo/enterprise#52886
Original PR description
Opening the Shop Floor from a workorder failed because the workcenter list may be empty (local storage not initialised) or not containing the workorder's workcenter. This commit ensures the workcenter related to the active workorder is selected at the shop floor opening Forward-Port-Of: odoo/enterprise#52886
Steps to reproduce the bug: - Create a storable product “C1” tracked by lot - Create a storable product “P1” with BoM: - Quantity: 3 - component: - 1 unit of C1 - in another line 2 units of C1 - Create a Mo and use the P1 BoM - Confirm the MO - Two quality check of “Register consumed materials” type is created because C1 is tracked - Try to add one line of C1 with 3 units - The 3 “stock.move” is merged into the first move - Try to set the qty producing of P
Original PR description
Steps to reproduce the bug: - Create a storable product “C1” tracked by lot - Create a storable product “P1” with BoM: - Quantity: 3 - component: - 1 unit of C1 - in another line 2 units of C1 -…
Steps to reproduce the bug:
- Create a storable product “C1” tracked by lot
- Create a storable product “P1” with BoM:
- Quantity: 3
- component:
- 1 unit of C1
- in another line 2 units of C1
- Create a Mo and use the P1 BoM
- Confirm the MO
- Two quality check of “Register consumed materials” type is created because C1 is tracked
- Try to add one line of C1 with 3 units
- The 3 “stock.move” is merged into the first move
- Try to set the qty producing of P1 to 2
Problem:
A traceback is triggered in `_float_check_precision`:
“assert precision_rounding is None or precision_rounding > 0,\ AssertionError: precision_rounding must be positive, got 0.0”
When the moves are merged into the first one, the other moves are cancelled but their quality checks persist.
So when we change the qty producing, we start the workorder and the component quantity is updated: https://github.com/odoo/enterprise/blob/1d99f3005f96672fd863541d50e5f81229365c32/mrp_workorder/models/mrp_workorder.py#L100-L102
So, we access the move, but since the move was removed, the rounding value is set to 0. Consequently, when float_round is called, an error is raised:
https://github.com/odoo/enterprise/blob/1a6abc731071f39e22693f0c1d54889e3ffdc5ff/mrp_workorder/models/quality.py#L441
https://github.com/odoo/enterprise/blob/1a6abc731071f39e22693f0c1d54889e3ffdc5ff/mrp_workorder/models/quality.py#L445
opw-3484016
Forward-Port-Of: odoo/enterprise#51616
Forward-Port-Of: odoo/enterprise#50688How to reproduce: 1) go to a form view 2) Open studio 3) Add Smart Button 4) Select a related field through the View All Dialog Before this commit, the selection of field through View All when adding a smart button on studio is not working. After this commit, the update of the Many2XAutocompletion is reading the display_name with an orm call. I reproduce the behaviour of the many2one_field. Bugfix Task ID: 3618289 Forward-Port-Of: odoo/enterprise#52900 Forward-Port-Of: odoo/enterpr
Original PR description
How to reproduce: 1) go to a form view 2) Open studio 3) Add Smart Button 4) Select a related field through the View All Dialog Before this commit, the selection of field through View All when adding a smart button on studio is not working. After this commit, the update of the Many2XAutocompletion is reading the display_name with an orm call. I reproduce the behaviour of the many2one_field. Bugfix Task ID: 3618289 Forward-Port-Of: odoo/enterprise#52900 Forward-Port-Of: odoo/enterprise#52128
Purpose of this PR is to aggregate several fixes for the whatsapp module introduced in 16.3. It also contains some test cleaning, as well as new tests for fixed issues. See sub-commits for more details, as there are quite a lot of fixes. Task-3608129 (Whatsapp: Moultifix !) Forward-Port-Of: odoo/enterprise#52840 Forward-Port-Of: odoo/enterprise#51001
Original PR description
Purpose of this PR is to aggregate several fixes for the whatsapp module introduced in 16.3. It also contains some test cleaning, as well as new tests for fixed issues. See sub-commits for more details, as there are quite a lot of fixes. Task-3608129 (Whatsapp: Moultifix !) Forward-Port-Of: odoo/enterprise#52840 Forward-Port-Of: odoo/enterprise#51001
Cron_trigger on saas can take up to 15-20min to start as there is only one thread responsible for waking up cron for thousands of databases. Hence the async fetch we did in v17 is not really good in practice (clicking on manual fetch and triggering a cron_trigger might take 20 mins and import 0 transactions). Now we will, on manual import, fetch the first 100 transactions (by date), process them and show them to the user. Then, a cron will asyncronously check if other transactions have to be
Original PR description
Cron_trigger on saas can take up to 15-20min to start as there is only one thread responsible for waking up cron for thousands of databases. Hence the async fetch we did in v17 is not really good in practice (clicking on manual fetch and triggering a cron_trigger might take 20 mins and import 0 transactions). Now we will, on manual import, fetch the first 100 transactions (by date), process them and show them to the user. Then, a cron will asyncronously check if other transactions have to be imported. task-3613030 Forward-Port-Of: odoo/enterprise#52772
In Guatemala the practice is to use the exchange rates provided by the Bank of Guatemala. They offer a webservice to fetch the daily rates that we are adding as a Currency Rate Provider in this commit. Further we are cleaning up the Current Rate Provider list by adding the country code in front of the label and sorting alphabetically. [task-3581837](https://www.odoo.com/web#id=3581837&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/ent
Original PR description
In Guatemala the practice is to use the exchange rates provided by the Bank of Guatemala. They offer a webservice to fetch the daily rates that we are adding as a Currency Rate Provider in this commit. Further we are cleaning up the Current Rate Provider list by adding the country code in front of the label and sorting alphabetically. [task-3581837](https://www.odoo.com/web#id=3581837&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#52646 Forward-Port-Of: odoo/enterprise#50686
When the user clicks on the option "Restore from Trash" option from the "more options" panel of the Knowledge editor, the system calls the `action_unarchive_article` action and execute the action returned. Currently the action `action_unarchive_article` does not return any action, causing the action service to receive `undefined` and subsequently trigger an error. This commit will address this issue by reloading the view instead of executing the action returned by `action_unarchive_article`.
Original PR description
When the user clicks on the option "Restore from Trash" option from the "more options" panel of the Knowledge editor, the system calls the `action_unarchive_article` action and execute the action…
When the user clicks on the option "Restore from Trash" option from the "more options" panel of the Knowledge editor, the system calls the `action_unarchive_article` action and execute the action returned. Currently the action `action_unarchive_article` does not return any action, causing the action service to receive `undefined` and subsequently trigger an error. This commit will address this issue by reloading the view instead of executing the action returned by `action_unarchive_article`. Steps to reproduce the issue: 1. Open an article in the editor 2. Click on "Delete" button from the "more options" menu 3. Click on "Open the Trash" 4. Click on the article you deleted 5. Click on "Restore from Trash" from the "more options" menu => TypeError: `action` is undefined TO BE: The editor is expected to reload the record and update the view. Additionally, the banner warning users about the imminent deletion of the article should be removed upon restoration. task-3619503 Forward-Port-Of: odoo/enterprise#52814 Forward-Port-Of: odoo/enterprise#51856
This PR removes the extra space on the right side of an embedded view. The extra space was added in https://github.com/odoo/enterprise/commit/3f5487f89e27, but we don't need that space for comments in the case of embedded views. Therefore, we are removing it. **Task**-3619543 Forward-Port-Of: odoo/enterprise#52133
Original PR description
This PR removes the extra space on the right side of an embedded view. The extra space was added in https://github.com/odoo/enterprise/commit/3f5487f89e27, but we don't need that space for comments in the case of embedded views. Therefore, we are removing it. **Task**-3619543 Forward-Port-Of: odoo/enterprise#52133
invoiced subscription Steps to reproduce: - Enable Analytical Account - Create a billable project with the Analytical Account selected - Make an SO of a subscription, with the AA selected - Invoice - Close the subscription - Go to the project and click on the update Issues: Traceback is shown opw-3566915 Forward-Port-Of: odoo/enterprise#52447 Forward-Port-Of: odoo/enterprise#51888
Original PR description
invoiced subscription Steps to reproduce: - Enable Analytical Account - Create a billable project with the Analytical Account selected - Make an SO of a subscription, with the AA selected - Invoice - Close the subscription - Go to the project and click on the update Issues: Traceback is shown opw-3566915 Forward-Port-Of: odoo/enterprise#52447 Forward-Port-Of: odoo/enterprise#51888
taskid: 3635467 Forward-Port-Of: odoo/enterprise#52581
Original PR description
taskid: 3635467 Forward-Port-Of: odoo/enterprise#52581
This commit, when the SO was closed with a reason, the end_date was kept. This commit makes sure that the end_date is always equal to today to avoid end_date in the future. taskid: 3635467 Forward-Port-Of: odoo/enterprise#52588
Original PR description
This commit, when the SO was closed with a reason, the end_date was kept. This commit makes sure that the end_date is always equal to today to avoid end_date in the future. taskid: 3635467 Forward-Port-Of: odoo/enterprise#52588
The field edi_format_ids is only part of the module account_edi. The dependency between l10n_mx_edi and account_edi has been removed in 16.4. Linked to runbot error 52360 Forward-Port-Of: odoo/enterprise#52606
Original PR description
The field edi_format_ids is only part of the module account_edi. The dependency between l10n_mx_edi and account_edi has been removed in 16.4. Linked to runbot error 52360 Forward-Port-Of: odoo/enterprise#52606
In case the foreign currency is missing on the bank transaction, a partial could be suggested to the user with an exchange difference. This commit allows the user to remove the exchange difference to spare the generation of an exchange difference entry and the creation of a write-off line on the bank reco widget. Suppose: 1200.0 comp_curr = 2400.0 foreign_curr in 2017 (rate 1:2) 1200.0 comp_curr = 3600.0 foreign_curr in 2016 (rate 1:3) a statement line of 1200 comp_curr and an invoice of 360
Original PR description
In case the foreign currency is missing on the bank transaction, a partial could be suggested to the user with an exchange difference. This commit allows the user to remove the exchange difference to…
In case the foreign currency is missing on the bank transaction, a partial could be suggested to the user with an exchange difference. This commit allows the user to remove the exchange difference to spare the generation of an exchange difference entry and the creation of a write-off line on the bank reco widget. Suppose: 1200.0 comp_curr = 2400.0 foreign_curr in 2017 (rate 1:2) 1200.0 comp_curr = 3600.0 foreign_curr in 2016 (rate 1:3) a statement line of 1200 comp_curr and an invoice of 3600.0 foreign_curr. | Line | foreign_curr | comp_curr | | -----------| ------------ | --------- | | liquidity | | 1200.0 | | new_aml | -2400.0 | -800.0 | | exch diff | | -400.0 | ...creating a partial reconcile on the invoice. After removing the partial, you are forced to create a write-off: | Line | foreign_curr | comp_curr | | -----------| ------------ | --------- | | liquidity | | 1200.0 | | new_aml | -3600.0 | -1200.0 | | exch diff | | -600.0 | | write-off | | 600.0 | After this commit, you are able to remove the exchange difference: | Line | foreign_curr | comp_curr | | -----------| ------------ | --------- | | liquidity | | 1200.0 | | new_aml | -3600.0 | -1200.0 | ...allowing to fully reconcile the invoice without any additional exchange difference entry. task: 3628473 Forward-Port-Of: odoo/enterprise#52645 Forward-Port-Of: odoo/enterprise#52228
Before this commit, when a churned order was reopened by portal payment, the end_date was left untouched. The expiration cron could close it the same day than the reopening. This commit remove the end date. We need to remove it and notify because we can't track all the possibilities: * order reaches the end date, auto close, customer pay to reopen it: --> we want to remove the end_date * 2 years order is closed by customer after a few months, it was a mistake. We want to reopen it but the
Original PR description
Before this commit, when a churned order was reopened by portal payment, the end_date was left untouched. The expiration cron could close it the same day than the reopening. This commit remove the end date. We need to remove it and notify because we can't track all the possibilities: * order reaches the end date, auto close, customer pay to reopen it: --> we want to remove the end_date * 2 years order is closed by customer after a few months, it was a mistake. We want to reopen it but the end date should be preserved. It is not possible to distinguish easily these 2 cases and the others. As we want to keep the flow simple, we decide to let the salesperson decide. opw-ticket 3614318 Forward-Port-Of: odoo/enterprise#52599 Forward-Port-Of: odoo/enterprise#51732
The 'Add a column' button was missing when editing a consolidation. The 'Consolidation balance' button was not needed when editing a consolidation. opw-3587724 Forward-Port-Of: odoo/enterprise#51660 Forward-Port-Of: odoo/enterprise#51398
Original PR description
The 'Add a column' button was missing when editing a consolidation. The 'Consolidation balance' button was not needed when editing a consolidation. opw-3587724 Forward-Port-Of: odoo/enterprise#51660 Forward-Port-Of: odoo/enterprise#51398
This issue occur when the user tries to create an order, and when the order is successfully placed at the point of sale and sent via WhatsApp to receive the order to the user, an error will be generated due to WhatsApp template was deleted. step to reproduce: - Install the `WhatsApp-POS` module. - Open the `WhatsApp`. - Configuration Menu > WhatsApp Business Accounts > create the account. - After the complete Configuration of account > delete the `POS Receipt` record. - Open the `Point O
Original PR description
This issue occur when the user tries to create an order, and when the order is successfully placed at the point of sale and sent via WhatsApp to receive the order to the user, an error will be…
This issue occur when the user tries to create an order, and when the order is successfully placed at the point of sale and sent via WhatsApp to receive the order to the user, an error will be generated due to WhatsApp template was deleted.
step to reproduce:
- Install the `WhatsApp-POS` module.
- Open the `WhatsApp`.
- Configuration Menu > WhatsApp Business Accounts > create the account.
- After the complete Configuration of account > delete the `POS Receipt` record.
- Open the `Point Of Sale`.
- Go to Dashboard > Shop (New session).
- Open session > create the one order.
- Enter the number in WhatsApp Receipt > click on WhatsApp symbol.
- The error will be generated.
sentry traceback-
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5457, in ensure_one
_id, = self._ids
ValueError: Expected singleton: whatsapp.template()
File "odoo/http.py", line 2139, in __call__
response = request._serve_db()
File "odoo/http.py", line 1715, 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 1742, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1943, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, 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 "home/odoo/src/enterprise/saas-16.4/whatsapp_pos/models/pos_order.py", line 31, in action_sent_receipt_on_whatsapp
whatsapp_composer._send_whatsapp_template()
File "home/odoo/src/enterprise/saas-16.4/whatsapp/wizard/whatsapp_composer.py", line 228, in _send_whatsapp_template
body = self._get_html_preview_whatsapp(rec=rec)
File "home/odoo/src/enterprise/saas-16.4/whatsapp/wizard/whatsapp_composer.py", line 281, in _get_html_preview_whatsapp
return self.wa_template_id._get_formatted_body(variable_values=template_variables_value)
File "home/odoo/src/enterprise/saas-16.4/whatsapp/models/whatsapp_template.py", line 733, in _get_formatted_body
self.ensure_one()
File "odoo/models.py", line 5460, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
If the user deletes the WhatsApp template after this commit, it will prevent the
traceback while sending the receipt through WhatsApp.
sentry-4583290175
Forward-Port-Of: odoo/enterprise#49817