Thursday, June 20, 2024
27 changes · saas-17.2
Resolved issues and error corrections
Spreadsheet views now load with the correct size in the edition module, ensuring cells are visible and interactive. This prevents automated test failures and reduces the risk of spreadsheet screens appearing blank or unusable in affected setups.
Original PR description
… module Steps to reproduces: - install module `test_spreadsheet_edition` - run js tests => some tests fail. The reason is we are trying to click or hover some cells in those tests. But the spreadsheet (its viewport) size is 0. The cells are not visible. This commit moves some scss from module `documents_spreadsheet` to `spreadsheet_edition`. This css ensures the spreadsheet takes all the available space and be sized properly. runbot errors 65775, 65774, 65773, 65772
The applicants kanban view now shows the empty-state message in white so it remains readable when there are no applications. This improves clarity for users viewing referral applicants and avoids confusion on an otherwise empty screen.
Original PR description
In applicants kanban view, when there is no applications, the text was unreadable, so it is white now. Task: 3786280
This update resolves a problem that could cause the Odoo iOS app to reload unexpectedly when handling the web client's color scheme. It improves stability for mobile users without changing business workflows.
Closing a live chat window while the chatbot is still processing no longer triggers an error. This makes the chat experience more reliable for users and avoids unnecessary system error reports.
Original PR description
When bot is processing steps and you close the `chatwindow` it throws error as the thread has been deleted so it won't be able to process next steps. This PR fixes the issue by adding necessary checks. Runbot Issue:-[64922](https://runbot.odoo.com/web/#id=64922&view_type=form&model=runbot.build.error&menu_id=405&cids=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
[IMP] documents_account: Add selection of journal in Document Action 'import bank statement' Backport of: https://github.com/odoo/enterprise/pull/46482/commits/d2a95d7ffa3ef2976172ed17eaf93056ea0f8c6c For now we didn't chose the bank journal because we assume that only coda file where push like this, and in the coda file we can find in which journal to send it. But Coda is limited to BE and lot of user import CSV file for bank. Add the selection of the journal (not mandatory) for Docume
Original PR description
[IMP] documents_account: Add selection of journal in Document Action 'import bank statement' Backport of: https://github.com/odoo/enterprise/pull/46482/commits/d2a95d7ffa3ef2976172ed17eaf93056ea0f8c6c For now we didn't chose the bank journal because we assume that only coda file where push like this, and in the coda file we can find in which journal to send it. But Coda is limited to BE and lot of user import CSV file for bank. Add the selection of the journal (not mandatory) for Document action, and inject CSV in the journal selected. If no journal selected inject the CSV in the first one of the list. If it's a coda file, keep as now and don't take care of the journal selected. Task-3932055 Forward-Port-Of: odoo/enterprise#64997 Forward-Port-Of: odoo/enterprise#62752
Since the introduction of the new model/record, the `record` props of fields can be updated to another `resId` without triggering `onWillUpdateProps`. Instead a new hook called `useRecordObserver` was introduced. This PR introduces multiple technical corrections related to the new model/record. * `openArticle` can use the `Record.save` with `nextId` this will avoid re-loading the current record's data just before switching to another record. * Behaviors in an article body can be destroyed
Original PR description
Since the introduction of the new model/record, the `record` props of fields can be updated to another `resId` without triggering `onWillUpdateProps`. Instead a new hook called `useRecordObserver` was introduced. This PR introduces multiple technical corrections related to the new model/record. * `openArticle` can use the `Record.save` with `nextId` this will avoid re-loading the current record's data just before switching to another record. * Behaviors in an article body can be destroyed sooner using `useRecordObserver`. * Topbar, Sidebar, Comments and Cover are adjusted to properly interact with the `Record` they handle * Ensure that a title is extracted from the body at the right timings if applicable (`beforeLeave` and `openArticle`) * Reduce flickering when switching article task-3875521 Forward-Port-Of: odoo/enterprise#64896 Forward-Port-Of: odoo/enterprise#60960
Issue: ====== Sign items are in english in sign Steps to reproduce the issue: ============================= - Create a user with Finnish language (or any other) - Create a sign request and add a date sign item - Send it to the Finnish customer - Open the link - The date doesn't fill automatically and the placeholders are all in english Origin of the issue: ==================== We don't use the language of the partner when fetching the sign items. The date field doesn't fill autom
Original PR description
Issue:
======
Sign items are in english in sign
Steps to reproduce the issue:
=============================
- Create a user with Finnish language (or any other)
- Create a sign request and add a date sign item
- Send it to the Finnish customer
- Open the link
- The date doesn't fill automatically and the placeholders are all in english
Origin of the issue:
====================
We don't use the language of the partner when fetching the sign items. The date field doesn't fill automatically is a consequence of this because we check `type.name === _t("Date")` but we have `type.name` in english and not the lang of the partner so we don't go into the condition to add the automatic fill for the date field here [1].
[1]: https://github.com/odoo/enterprise/blob/15.0/sign/static/src/js/sign_common.js#L1646
opw-3871779
Forward-Port-Of: odoo/enterprise#64824
Forward-Port-Of: odoo/enterprise#61744## Issue: - For an inventory operation, if a product quantity is less than 1 (eg. 0.5), the "+" button in the Barcode app will display "+1" instead of "+ 0.5". ## Steps To Reproduce: - In Inventory, create a transfer (Receipts) with a product where the quantity is 0.5 and "Mark As Todo". - In the Barcode app, go to that operation and notice that the "Add Quantity" button shows "+1" instead of "+0.5". ## Solution: - I modified the `getIncrementQuantity` function to change the minimum qu
Original PR description
## Issue: - For an inventory operation, if a product quantity is less than 1 (eg. 0.5), the "+" button in the Barcode app will display "+1" instead of "+ 0.5". ## Steps To Reproduce: - In Inventory, create a transfer (Receipts) with a product where the quantity is 0.5 and "Mark As Todo". - In the Barcode app, go to that operation and notice that the "Add Quantity" button shows "+1" instead of "+0.5". ## Solution: - I modified the `getIncrementQuantity` function to change the minimum quantity from 1 to 0. This ensures that for product quantities less than 1, the "+" button in the Barcode app will display the correct increment. OPW-3880380 Forward-Port-Of: odoo/enterprise#64812 Forward-Port-Of: odoo/enterprise#62770
- When clicking on an account that hasn't been mapped, the help message shown in the tree view contained HTML code (tags explicitly shown). - We fix that by directly executing the action returned by the server, which then gets the proper markup and properly interprets the returned HTML code. task: 3715833 Forward-Port-Of: odoo/enterprise#64979 Forward-Port-Of: odoo/enterprise#63376
Original PR description
- When clicking on an account that hasn't been mapped, the help message shown in the tree view contained HTML code (tags explicitly shown). - We fix that by directly executing the action returned by the server, which then gets the proper markup and properly interprets the returned HTML code. task: 3715833 Forward-Port-Of: odoo/enterprise#64979 Forward-Port-Of: odoo/enterprise#63376
Task-3610647 Forward-Port-Of: odoo/enterprise#64909 Forward-Port-Of: odoo/enterprise#64267
Original PR description
Task-3610647 Forward-Port-Of: odoo/enterprise#64909 Forward-Port-Of: odoo/enterprise#64267
When timezone of user is empty and the user clicks on Add a Leave button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save - Install 'Appointments' - Go to Appointments > Schedule > Resource Bookings > Add a Leave Traceback: ``` AttributeError: 'bool' object has no attribute 'upper' File "odoo/http.py", line 2254, in __call__ response = request._serve_db() File "odoo/http.py", line 1829, in _serve_db
Original PR description
When timezone of user is empty and the user clicks on Add a Leave button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save -…
When timezone of user is empty and the user clicks on Add a Leave button,
a traceback will appear.
Steps to reproduce the error:
- Open Profile > Preferences > Select empty in timezone > Save
- Install 'Appointments'
- Go to Appointments > Schedule > Resource Bookings > Add a Leave
Traceback:
```
AttributeError: 'bool' object has no attribute 'upper'
File "odoo/http.py", line 2254, in __call__
response = request._serve_db()
File "odoo/http.py", line 1829, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1849, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1827, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1834, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2059, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 871, in onchange
defaults = self.default_get(missing_names)
File "odoo/models.py", line 1524, in default_get
defaults[name] = field.default(self)
File "home/odoo/src/enterprise/saas-17.2/appointment/wizard/appointment_manage_leaves.py", line 20, in <lambda>
leave_start_dt = fields.Datetime('Start Date', required=True, default=lambda self: self._default_time(0, 0))
File "home/odoo/src/enterprise/saas-17.2/appointment/wizard/appointment_manage_leaves.py", line 14, in _default_time
user_timezone = pytz.timezone(self.env.user.tz or self.env.context.get('tz', 'utc'))
File "odoo/tools/_monkeypatches_pytz.py", line 129, in timezone
return original_pytz_timezone(name)
File "__init__.py", line 183, in timezone
if zone.upper() == 'UTC':
```
https://github.com/odoo/enterprise/blob/7640860f415028d2d516a2df5e4bc26d9d6dd3b4/appointment/wizard/appointment_manage_leaves.py#L14 When the user selects an empty timezone, tz will be False.
So, It will lead to the above traceback.
sentry-5443573507
Forward-Port-Of: odoo/enterprise#63858**Steps to reproduce:** - Install Sale and Project modules - Create a project with 1 or 2 stages - Create more than 1 task in this project - Assign those tasks to a Sale order - Go to this sale order and click on tasks smart button **Current behavior before PR:** When clicking on the task smart button in a sale order you will see lots of stages that are not associated with the shown tasks' project. This is happening because the value assigned to default_project_id in the context is
Original PR description
**Steps to reproduce:** - Install Sale and Project modules - Create a project with 1 or 2 stages - Create more than 1 task in this project - Assign those tasks to a Sale order - Go to this sale order and click on tasks smart button **Current behavior before PR:** When clicking on the task smart button in a sale order you will see lots of stages that are not associated with the shown tasks' project. This is happening because the value assigned to default_project_id in the context is False. https://github.com/odoo/odoo/blob/saas-16.4/addons/sale_project/models/sale_order.py#L166 **Desired behavior after PR is merged:** We are now just showing the stages associated with the shown tasks' project by assigning those tasks' project id to the default_project_id value in context. opw-3929012 Forward-Port-Of: odoo/odoo#169684 Forward-Port-Of: odoo/odoo#168035
During a fw-port, an error was made and the "or" became an "and". This fixes it, to hide the tab if the move is not from a polish company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168502
Original PR description
During a fw-port, an error was made and the "or" became an "and". This fixes it, to hide the tab if the move is not from a polish company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168502
The issue: When creating an invoice from multiple sale orders, each invoice line is going to be linked to the appropriate sale order line from each sale order, which will cause a singleton traceback when trying to access the is_downpayment field Expected behavior: to confirm the invoice Current Behavior: Singleton traceback opw-3878327 Forward-Port-Of: odoo/odoo#167064 Forward-Port-Of: odoo/odoo#163766
Original PR description
The issue: When creating an invoice from multiple sale orders, each invoice line is going to be linked to the appropriate sale order line from each sale order, which will cause a singleton traceback when trying to access the is_downpayment field Expected behavior: to confirm the invoice Current Behavior: Singleton traceback opw-3878327 Forward-Port-Of: odoo/odoo#167064 Forward-Port-Of: odoo/odoo#163766
When demo data is loaded by user from UI, the same records are created as is done with loading demo data, ideally they should have same attributes but loading through python function doesn't result in same because noupdate flag is not set. And when ORM tries to remove these records it ends up causing an error. similar:https://github.com/odoo/odoo/pull/162080 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
When demo data is loaded by user from UI, the same records are created as is done with loading demo data, ideally they should have same attributes but loading through python function doesn't result in same because noupdate flag is not set. And when ORM tries to remove these records it ends up causing an error. similar:https://github.com/odoo/odoo/pull/162080 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#168726
Before commit: When creating an expense through an email alias, it can sometimes have no product_id set. This usually causes a clean error message to pop up, but here there was a traceback due to the use of product_uom_id.rounding before we get to show the error message After commit: The traceback is solved and the correct error message is shown opw-3921278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165552
Original PR description
Before commit: When creating an expense through an email alias, it can sometimes have no product_id set. This usually causes a clean error message to pop up, but here there was a traceback due to the use of product_uom_id.rounding before we get to show the error message After commit: The traceback is solved and the correct error message is shown opw-3921278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165552
Currently, a traceback occurs when the user changes the type of a product. Steps to reproduce:- 1) Install sale, POS 2) Create a confirmed sale order with a product 2) Now change the product type for the above created `SO` product Error:- ``` TypeError: 'NoneType' object does not support item assignment ``` In the [1] commit there is no return type, So it by default returns None. Because of no return type, the value of `res` would be `None` at [2]. It leads to a traceback wh
Original PR description
Currently, a traceback occurs when the user changes the type of a product. Steps to reproduce:- 1) Install sale, POS 2) Create a confirmed sale order with a product 2) Now change the product type for the above created `SO` product Error:- ``` TypeError: 'NoneType' object does not support item assignment ``` In the [1] commit there is no return type, So it by default returns None. Because of no return type, the value of `res` would be `None` at [2]. It leads to a traceback when assigning a value to `res`, which is a `NoneType` at [3]. [1] https://github.com/odoo/odoo/commit/d9c5d163f251f59829b00decae94044941ee44e4 [2] https://github.com/odoo/odoo/blob/a142a51faa8ab8cce9c9ae4a14e15646c2118f5e/addons/sale/models/product_template.py#L95 [3] https://github.com/odoo/odoo/blob/a142a51faa8ab8cce9c9ae4a14e15646c2118f5e/addons/sale/models/product_template.py#L97 sentry-5488262774 Forward-Port-Of: odoo/odoo#169376
The certificate issuer name in the Factura-e XML needs to be formatted in a very specific way. Else it fails the validators of the Basque Region in Spain. This commit changes the format to be the same as in module l10n_es_edi_tbai . task-3990176 Forward-Port-Of: odoo/odoo#169609
Original PR description
The certificate issuer name in the Factura-e XML needs to be formatted in a very specific way. Else it fails the validators of the Basque Region in Spain. This commit changes the format to be the same as in module l10n_es_edi_tbai . task-3990176 Forward-Port-Of: odoo/odoo#169609
Current behavior: When the restaurant is opened and "Self Ordering" is set to "QR menu", the banner "We're currently closed." is shown. Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" module - Start a restaurant session and go to the backend - In the settings, set "Self Ordering" to "QR menu" and save - Click on "Preview Web interface" - Problem: The banner is shown Solutions: Display the banner if the session is not opened rather than when we have a token (in
Original PR description
Current behavior: When the restaurant is opened and "Self Ordering" is set to "QR menu", the banner "We're currently closed." is shown. Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" module - Start a restaurant session and go to the backend - In the settings, set "Self Ordering" to "QR menu" and save - Click on "Preview Web interface" - Problem: The banner is shown Solutions: Display the banner if the session is not opened rather than when we have a token (in mode "QR menu", there is no token) opw-3854839 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169618
The tour is not actually ran in this version, and is blocked before in other versions. We should fix it in an other PR. This typo causes a check on available steps to fail in master. runbot-68355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169973 Forward-Port-Of: odoo/odoo#169646
Original PR description
The tour is not actually ran in this version, and is blocked before in other versions. We should fix it in an other PR. This typo causes a check on available steps to fail in master. runbot-68355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169973 Forward-Port-Of: odoo/odoo#169646
Credit notes shoudn't make the down payment reference disappear from the matching down payment SO line. opw-3904918 See #168418 for further details Forward-Port-Of: odoo/odoo#169859 Forward-Port-Of: odoo/odoo#169779
Original PR description
Credit notes shoudn't make the down payment reference disappear from the matching down payment SO line. opw-3904918 See #168418 for further details Forward-Port-Of: odoo/odoo#169859 Forward-Port-Of: odoo/odoo#169779
Before this PR: When loggin into a company, it would simply add the new company in the list of the currently selected/active companies, this made it harder to use or stay in single-company mode. After this PR: Logging into a company will now switch companies if we are in single-company mode, essentially making the user stay in single-company mode. The user can still toggle companies to enter multi-company mode. *This behaviour got lost when adding the branches system in the company s
Original PR description
Before this PR: When loggin into a company, it would simply add the new company in the list of the currently selected/active companies, this made it harder to use or stay in single-company mode. After this PR: Logging into a company will now switch companies if we are in single-company mode, essentially making the user stay in single-company mode. The user can still toggle companies to enter multi-company mode. *This behaviour got lost when adding the branches system in the company service.* Task ID: 3927141 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169716 Forward-Port-Of: odoo/odoo#165227
This commit import payment_token file in __init__ which was missed by [1] PR to properly execute it's code and do not return any token for express checkout. [1]: https://github.com/odoo/odoo/pull/107788 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#169942
Original PR description
This commit import payment_token file in __init__ which was missed by [1] PR to properly execute it's code and do not return any token for express checkout. [1]: https://github.com/odoo/odoo/pull/107788 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#169942
Versions -------- - 15.0+ Steps ----- 1. Go to Sale / Configuration / Units of Measure Categories; 2. go to Working Time; 3. set rounding precision of Hours to 1.0; 4. create a SO, selling 10 hours of timesheeted service; 5. click confirm; 6. add 9.1 hours to a timesheet for the SO. Issue ----- The sale order line displays 9 hours delivered, while a smart button displays 10 hours recorded. Cause ----- The smart button displays the value of the `timesheet_total_duration` fie
Original PR description
Versions -------- - 15.0+ Steps ----- 1. Go to Sale / Configuration / Units of Measure Categories; 2. go to Working Time; 3. set rounding precision of Hours to 1.0; 4. create a SO, selling 10 hours…
Versions -------- - 15.0+ Steps ----- 1. Go to Sale / Configuration / Units of Measure Categories; 2. go to Working Time; 3. set rounding precision of Hours to 1.0; 4. create a SO, selling 10 hours of timesheeted service; 5. click confirm; 6. add 9.1 hours to a timesheet for the SO. Issue ----- The sale order line displays 9 hours delivered, while a smart button displays 10 hours recorded. Cause ----- The smart button displays the value of the `timesheet_total_duration` field, this field gets computed with `_compute_quantity` method of `uom.uom`, which defaults to the `UP` rounding method: https://github.com/odoo/odoo/blob/b724fbcf6f348ed7a9109a325d366be69c052d1c/addons/uom/models/uom_uom.py#L216 In contrast, the SOL displays the result of `_get_delivered_quantity_by_analytic`, which uses the same `uom.uom` method, but with the `HALF-UP` rounding method: https://github.com/odoo/odoo/blob/b724fbcf6f348ed7a9109a325d366be69c052d1c/addons/sale/models/sale_order_line.py#L387 Solution -------- Modify the `_compute_timesheet_total_duration` methods of `account.move` and `sale.order` to use the same rounding method as the `_get_delivered_quantity_by_analytic` method. opw-3949986 Forward-Port-Of: odoo/odoo#169900 Forward-Port-Of: odoo/odoo#167607
Before this commit, the restricted editor would see the "Edit" button regardless of the current language. This led to unpredictable results: no editable content, editing the source, or editing the translation. Now, we display the correct buttons for translating and editing. Previously, if you edited a blog in French while your website's default language was English, it would overwrite the French source instead of translating it. Now, it correctly translates the content. X-original-commi
Original PR description
Before this commit, the restricted editor would see the "Edit" button regardless of the current language. This led to unpredictable results: no editable content, editing the source, or editing the translation. Now, we display the correct buttons for translating and editing. Previously, if you edited a blog in French while your website's default language was English, it would overwrite the French source instead of translating it. Now, it correctly translates the content. X-original-commit: 1bcc0733c9af52c6cf38b12f24ff6ed96314bec4 Forward-Port-Of: odoo/odoo#170109
Use case: - LOT A 20 units in stock - LOT B 20 units in stock - Do an outgoing picking for 10 units - Reserve - Remove the `stock.move.line` - Add a new line of B Current behavior: Line is prefilled for 20 units Expected: Line only takes the 10 units missing It's due to commit [1] enforcing the computation on the origin move and not the current situation [1] commit 383d4eb98ba4bfbcb384b3d1ee27393da00226e7 Description of the issue/feature this PR addresses: Current beha
Original PR description
Use case: - LOT A 20 units in stock - LOT B 20 units in stock - Do an outgoing picking for 10 units - Reserve - Remove the `stock.move.line` - Add a new line of B Current behavior: Line is prefilled for 20 units Expected: Line only takes the 10 units missing It's due to commit [1] enforcing the computation on the origin move and not the current situation [1] commit 383d4eb98ba4bfbcb384b3d1ee27393da00226e7 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#168162
The live chat uses cookies to save data about the ongoing conversation, such as the thread name. When this information contains non-ASCII characters, the behavior of the cookie is not consistent across browsers. Safari does not store it properly, and trying to parse it later on results in a crash. Until version 17 ([1]), the fix relied on encoding the data using the `encodeURIComponent` method. However, cookie size is limited to 4096 bytes, and this limit can be reached. Starting with v
Original PR description
The live chat uses cookies to save data about the ongoing conversation, such as the thread name. When this information contains non-ASCII characters, the behavior of the cookie is not consistent across browsers. Safari does not store it properly, and trying to parse it later on results in a crash. Until version 17 ([1]), the fix relied on encoding the data using the `encodeURIComponent` method. However, cookie size is limited to 4096 bytes, and this limit can be reached. Starting with version 17.3, the live chat does not use cookies anymore ([2]). This PR backports this behavior to fix the issue. opw-3968341 [1]: https://github.com/odoo/odoo/pull/168524 [2]: https://github.com/odoo/odoo/pull/167495 Forward-Port-Of: odoo/odoo#169395