Tuesday, April 9, 2024
33 changes · saas-17.2
Resolved issues and error corrections
Uploading a file in a newly opened live chat now works reliably instead of causing an error. The system now saves the chat on the server before starting the upload, improving the support experience for users and agents.
Original PR description
Before this PR, uploading a file to a temporary thread would lead to errors because the thread only exists locally. This PR ensures the thread is saved on the server before uploading like it's done when a message is posted. This PR adapts the attachment upload service to rely on models instead of components: - Service should not be coupled to views - Thread is updated when calling `uploadFile` so the hook passed to this function is outdated and we cannot access the new thread hook (it's not even mounted yet). Steps to reproduce the issue: - Log in as admin - Go to the live chat support page - Open a chat - Click on upload file and upload one - Crash occurs https://github.com/odoo/enterprise/pull/60165
This fix centralizes a key background communication method used by Odoo's web services. It helps messaging, live chat, and related interface actions run more consistently, reducing the risk of errors in day-to-day communication workflows.
Reloading a product page opened from Physical Inventory no longer triggers an error page. This keeps inventory workflows stable and prevents customers from being interrupted by a traceback when refreshing the browser.
Original PR description
When the customer opens the product from Physical Inventory and tries to reload the page, a traceback will appear. Steps to reproduce the error: - Go to Inventory > Operations > Physical Inventory -…
When the customer opens the product from Physical Inventory and tries to reload
the page, a traceback will appear.
Steps to reproduce the error:
- Go to Inventory > Operations > Physical Inventory
- Open any product > reload the page
Traceback:
```
KeyError: 'display_name'
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, 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 1825, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, 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 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 74, in load_breadcrumbs
name = act['display_name'] if any(view[1] != 'form' and view[1] != 'search' for view in act['views']) else None
```
https://github.com/odoo/odoo/blob/853bd97eda1f4eca5f9f63ef1c5909fddaa98d27/addons/stock/models/stock_quant.py#L388-L396
Here, 'display_name' key is not present.
https://github.com/odoo/odoo/blob/853bd97eda1f4eca5f9f63ef1c5909fddaa98d27/addons/web/controllers/action.py#L74 When Customer reloads the page,
It will try to access 'display_name' here, but it is not present.
So, It will lead to the above traceback.
sentry-5132471164
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix ensures test communication channels are closed after each test run. It helps prevent memory buildup and keeps the test environment stable over repeated runs.
Original PR description
Before this PR, broadcast channels opened during a test would never be closed. This can lead to memory leak. Moreover, subscriptions to the message event are not cleaned as well so subscriptions would keep growing test after test. This PR ensures the channels are properly closed at the end of each test.
This fix corrects how message notification IDs are tracked in testing and mail-related services, preventing older notifications from overriding newer unread message counts. It helps ensure more reliable behavior and test coverage for messaging features.
Original PR description
Follow up of https://github.com/odoo/odoo/pull/160700 Follow up of HOOT commits In hoot mock server, values are stored "per model", which means the counter is stored in bus model and not in `this`. This issue made impossible to detect the last value (always undefined) and basically "diff" notifications were never discarded, which was not covered by any test, but it is better to fix it for future tests. `lastBusNotificationId` should be incremented before and not after assigning the id, as the initial counter should be 0, and the first notif should be 1. This is what was done on the legacy mock server. This becomes an issue in this commit as fixing the read of the last value (first point of commit) means "diff" notif were always discarded. Forgot to check the bus id with `needaction_inbox_counter` in `mail.message/mark_as_read`. Old `mail.message/mark_as_read` notifications could therefore alter the result of a more recent init value.
This fix makes Odoo's web test environment better match the real system when loading actions. It helps prevent misleading test results by supporting action lookup by both internal ID and XML identifier, including server actions that run immediately.
Original PR description
Before this commit, the mocked route was only able to load actions from their id. The actual route also allows to load them from their xml_id. Moreover, since a recent commit [1], server actions are directly run. [1] odoo/odoo@c3bfdfb0ae51e083e46b3d084d5f86e7083fcdd6 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 fixes an internal test timing issue in the Mail app so automated checks run more reliably. It helps prevent false test failures and supports smoother delivery of future mail-related updates, with no direct change for end users.
Original PR description
HOOT currently does not isolate tests, and the promise used in `loadEmoji` is never discarded, leading to the RPC potentially being called after the end of the test. Waiting for the message to be present ensures the RPC is done within the correct test. runbot-60638 runbot-60673 runbot-61164 runbot-61261
Miscellaneous changes
### Steps to reproduce issue: 1. Select a boxed layout document 2. Create an invoice and add lines until the pdf version is on two pages 3. Print the pdf 4. On every page except the first one, the body of the document is cropped by the header ### Explanation: The PDF consists of three parts: the header, the footer and the body, and they are added separately. The body is delimited by the paper format and margins. Those do not depend on the size of the header and the footer. In the bo
Original PR description
### Steps to reproduce issue: 1. Select a boxed layout document 2. Create an invoice and add lines until the pdf version is on two pages 3. Print the pdf 4. On every page except the first one, the body of the document is cropped by the header ### Explanation: The PDF consists of three parts: the header, the footer and the body, and they are added separately. The body is delimited by the paper format and margins. Those do not depend on the size of the header and the footer. In the boxed layout, the height of the header is bigger than the default size of the top margin of the body. Because of that, it covers a part of the body. ### Suggested fix: By removing some whitespace, the header size has been reduced to a size smaller than the default margins of the document while keeping every information readable. opw-3768511 Forward-Port-Of: odoo/odoo#160770 Forward-Port-Of: odoo/odoo#159125
Small improvements on the download logs button in the Iot App: - Log file contains the IoT name and date of generation - Internal server error araise if the logfile config is missing - Internal server error aised if the log file is missin Was meant to be part of: https://github.com/odoo/odoo/pull/159186 opw-3827121 Forward-Port-Of: odoo/odoo#160645
Original PR description
Small improvements on the download logs button in the Iot App: - Log file contains the IoT name and date of generation - Internal server error araise if the logfile config is missing - Internal server error aised if the log file is missin Was meant to be part of: https://github.com/odoo/odoo/pull/159186 opw-3827121 Forward-Port-Of: odoo/odoo#160645
### Steps to reproduce issue: 1. Download two languages, set one as the user's language, the other as the website's 2. Make sure MailHog is running 3. Create a Mailing Contact with two different Mailing Lists 4. Create a mail with a link to unsubscribe 5. Send mail to one of the Contact's Mailing lists 6. Through MailHog, click on the subscription cancelling link 7. The first line is in the user's language and the others in the website's language ### Explanation: While most of the
Original PR description
### Steps to reproduce issue: 1. Download two languages, set one as the user's language, the other as the website's 2. Make sure MailHog is running 3. Create a Mailing Contact with two different…
### Steps to reproduce issue: 1. Download two languages, set one as the user's language, the other as the website's 2. Make sure MailHog is running 3. Create a Mailing Contact with two different Mailing Lists 4. Create a mail with a link to unsubscribe 5. Send mail to one of the Contact's Mailing lists 6. Through MailHog, click on the subscription cancelling link 7. The first line is in the user's language and the others in the website's language ### Explanation: While most of the webpage originates from an XML file, translated using the language of the website. https://github.com/odoo/odoo/blob/2ad911dab1f34b1b6dda1016cc189f0fea64b12c/addons/mass_mailing/views/mass_mailing_templates_portal.xml#L118 The first line is passed through javascript and translated on the fly. https://github.com/odoo/odoo/blob/efd178daee689192d4e930a075475587038b3e0d/addons/mass_mailing/static/src/js/unsubscribe.js#L50-L55 The line is translated thanks to an object fetched at the load of the page. The url where the object is located can receive parameters including the language, but defaults to the user's and is not set in our case. https://github.com/odoo/odoo/blob/0ca2ca9e8914dda77166b62dc8c2e9dc1ca1d3a4/addons/web/static/src/legacy/js/core/translation.js#L73-L78 ### Suggested fix: The language can be passed through the attribute `lang` of the document. https://github.com/odoo/odoo/blob/658bc65b22dba86a35f6bba0f892427e1be4aed1/addons/web/static/src/legacy/js/core/session.js#L205-L211 https://github.com/odoo/odoo/blob/e251354ce4b7df1763247385413e98f975981479/addons/web/views/webclient_templates.xml#L10 This option is already used in `website` and, [since 16.0](https://github.com/odoo/odoo/commit/5136ac7e4daaadda396c45c8538a81f8d6c44c0e), is inherited once `website` is installed. https://github.com/odoo/odoo/blob/c3c8003c6d1c4d694531c93e803e7e9cd7ebaa83/addons/website/views/website_templates.xml#L39-L50 opw-3748027 Forward-Port-Of: odoo/odoo#160697 Forward-Port-Of: odoo/odoo#159341
Issue: ===== double scrollbar appears in notes. Steps to reproduce the issue: ============================= - Go to notes - Insert a table - Add some columns and try to stretch the last one to the right until it goes outside the width of the editable. - Click on the last cell to the right in the table and scroll left - Another scrollbar will appear. Origin of the issue: ==================== The part of the table that is invisible in the editor is considered as overflow for the
Original PR description
Issue: ===== double scrollbar appears in notes. Steps to reproduce the issue: ============================= - Go to notes - Insert a table - Add some columns and try to stretch the last one to the right until it goes outside the width of the editable. - Click on the last cell to the right in the table and scroll left - Another scrollbar will appear. Origin of the issue: ==================== The part of the table that is invisible in the editor is considered as overflow for the `html_field` so it will show a scrollbar which is not needed since we already have a scrollbar in the edtibale. Solution: ========= We mark hide the overflow in `html_field` and let the editable takes care of the overflow. task-3721794 Forward-Port-Of: odoo/odoo#160674 Forward-Port-Of: odoo/odoo#157675
Currently, when creating a purchase order, if the product has multiple vendor lines (with the vendor selected on the PO), the product description uses information from all the vendor lines; instead of using information from the vendor line that is used for the price. Steps to reproduce: ------------------- * Go to the **Purchase** App * Go to **Products** * Select any product * Select the **Purchase** tab * Add `Vendor Product Name` and `Vendor Product Code` in additional line fields *
Original PR description
Currently, when creating a purchase order, if the product has multiple vendor lines (with the vendor selected on the PO), the product description uses information from all the vendor lines; instead…
Currently, when creating a purchase order, if the product has multiple vendor lines (with the vendor selected on the PO), the product description uses information from all the vendor lines; instead of using information from the vendor line that is used for the price.
Steps to reproduce:
-------------------
* Go to the **Purchase** App
* Go to **Products**
* Select any product
* Select the **Purchase** tab
* Add `Vendor Product Name` and `Vendor Product Code` in additional line fields
* Add two vendor lines
* Line 1:
`Vendor`: Vendor1
`Vendor Product Name`: P1
`Vendor Product Code`: A
`Price`: 1
* Line 2:
`Vendor`: Vendor 1
`Vendor Product Name`: P1 bis
`Vendor Product Code`: B
`Price`: 5
* Select **Orders** > **Request for quotation**
* Create a new quotation
* Select Vendor 1, add the product for which we just added the two vendor lines
> **Observation**: The description of the product shows information from both vendor lines added.
Why the fix:
------------
This behavior was introduced when `name_get` was removed to use `dispay_name` instead.
* https://github.com/odoo/odoo/pull/122085/commits/a8b15c7ab5e2d850d0551a6eb4213bb20a30b210
* https://github.com/odoo/odoo/pull/122085/commits/a8b15c7ab5e2d850d0551a6eb4213bb20a30b210
When adding a product to the purchase order, the onchange on `product_id` is called. The onchange calls the function `_product_id_change`, which itself calls `_get_product_purchase_description`. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1224 https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1401-L1407
The line `name = product_lang.display_name` calls the function `_compute_display_name`.
* We do have a parnter_id in the context as we have selected a vendor on the purchase order. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L434
* We don't have a supplierinfo in the context yet but we have multiple supplierinfo with the same partner_id. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L466-L467 Here we thus have 2 sellers.
* Ultimately, the display name joins the different display names computer for each seller. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/product/models/product_product.py#L473-L483
Coming back to the line `self.name = self._get_product_purchase_description(product_lang)`, we now have the name of the purchase order line set as the concatenation of display names from the supplierinfo, i.e `'[A] P1, [B] P1 bis'`.
Once the onchange is called, the function `_compute_price_unit_and_date_planned_and_name` is being called. https://github.com/odoo/odoo/blob/7e9b9494a8d6c4bb8b3800cc0e25fcd3596db75d/addons/purchase/models/purchase.py#L1295-L1302 In the current state, we do not meet the if condition. Indeed, the line has a name (`'[A] P1, [B] P1 bis'`) but it isn't in the default_names (`['[A] P1', '[B] P1 bis']`). It somehow corresponds to a setting where the name of the purchase order line was setup by the user.
With this current fix, the call to `_product_id_change` will set the name of the line with the product information from the company; and not the partner/seller. We also need to add this name to the `default_names` in `_compute_price_unit_and_date_planned_and_name` so that the description gets recomputed with regards to the seller, if any.
I tested the scenario where:
* The second supplierinfo has a smaller unit price when buying 10 products. On the sale order line, when I set the quantity to 20, the unit price is updated as well as the description. The description is updated as `line.name` is indeed in `default_names`.
opw-3802182
Forward-Port-Of: odoo/odoo#160778
Forward-Port-Of: odoo/odoo#158398When creating a new company from a move, if the tax ID is repeated, a warning is displayed. The warning includes the company name, address and VAT, if those have been added. In this case, address is shown in an extra line, which looks broken. This commit removes additional partner information by updating the context, displaying only the partner name. It also slightly rewords the warning, from "are you sure to create a new one?" to "are you sure you want to create a new one?". To replica
Original PR description
When creating a new company from a move, if the tax ID is repeated, a warning is displayed. The warning includes the company name, address and VAT, if those have been added. In this case, address is shown in an extra line, which looks broken. This commit removes additional partner information by updating the context, displaying only the partner name. It also slightly rewords the warning, from "are you sure to create a new one?" to "are you sure you want to create a new one?". To replicate the issue: 1. Create an invoice 2. Click on the empty field next to Customer, type a new name and click "Create and edit..." 3. Add a Tax ID that is already in use (e.g. US12345673) 4. Warning of duplicate Tax ID shows, displaying company name, address and VAT task-3829641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160373
## Issue: - When we have open tickets from anyone with the email domain @proton.me, they are linked together even though this domain is generic, not a private one. same issue with @cegetel.net and @dbmail.com ## Steps To Reproduce: - Create three tickets with "@proton.me" domain but different addresses. - See that in the smart button, the tickets are linked to each other even though the customers are different. ## Solution: - in `_compute_partner_ticket_count` we check if the email d
Original PR description
## Issue: - When we have open tickets from anyone with the email domain @proton.me, they are linked together even though this domain is generic, not a private one. same issue with @cegetel.net and…
## Issue: - When we have open tickets from anyone with the email domain @proton.me, they are linked together even though this domain is generic, not a private one. same issue with @cegetel.net and @dbmail.com ## Steps To Reproduce: - Create three tickets with "@proton.me" domain but different addresses. - See that in the smart button, the tickets are linked to each other even though the customers are different. ## Solution: - in `_compute_partner_ticket_count` we check if the email domain of the partner is in `iap_tools._MAIL_DOMAIN_BLACKLIST `, if not, we considers the email to be a company email which tickets can be grouped by. - the `_MAIL_DOMAIN_BLACKLIST` is a list of generic email providers on which IAP services should not run. Retrieving company information from them makes no sense. - To fix this issue I added `proton.me` , `cegetel.net` and `dbmail.com` to `_MAIL_DOMAIN_BLACKLIST` opw-3786308 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159321
In mobile, having a somewhat 'large price' (like a few thousands currency units) can cause the bottom of the card to overflow (esp. if buttons like 'add to card' or 'add to wishlist' are present). This commit modifies the card template so that content is normally spaced and can wrap to a new line if need be. opw-3706637 Forward-Port-Of: odoo/odoo#160628
Original PR description
In mobile, having a somewhat 'large price' (like a few thousands currency units) can cause the bottom of the card to overflow (esp. if buttons like 'add to card' or 'add to wishlist' are present). This commit modifies the card template so that content is normally spaced and can wrap to a new line if need be. opw-3706637 Forward-Port-Of: odoo/odoo#160628
Before this commit, we didn't correctly detect when to prefix the value of an url field for the href of its link. 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#160623 Forward-Port-Of: odoo/odoo#160536
Original PR description
Before this commit, we didn't correctly detect when to prefix the value of an url field for the href of its link. 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#160623 Forward-Port-Of: odoo/odoo#160536
### Steps to reproduce issue: 1. In settings, activate Timesheets and Project Stages 2. Create Project with Timesheets enabled 3. In the project, create a new task in the kanban view 4. Give the task a title 5. Choose an Asignee 6. The title disappeared ### Explanation: The title field, `display_name`, is a computed field that gets its value from `name`. This compute has dependencies coming from other computed values. One of them, `allocated_hours` has a dependency to user_ids, mak
Original PR description
### Steps to reproduce issue: 1. In settings, activate Timesheets and Project Stages 2. Create Project with Timesheets enabled 3. In the project, create a new task in the kanban view 4. Give the task…
### Steps to reproduce issue: 1. In settings, activate Timesheets and Project Stages 2. Create Project with Timesheets enabled 3. In the project, create a new task in the kanban view 4. Give the task a title 5. Choose an Asignee 6. The title disappeared ### Explanation: The title field, `display_name`, is a computed field that gets its value from `name`. This compute has dependencies coming from other computed values. One of them, `allocated_hours` has a dependency to user_ids, making the whole chain trigger when a user is added to or removed from the Assignees. https://github.com/odoo/enterprise/blob/c2dde10834b1ef31fe4564a49c90c461a348b392/project_enterprise/models/project_task.py#L83-L84 ### Suggested fix: `display_name` is used in very few situations, either in the kanban view or in a dropdown menu. Those two cases do not require reactiveness from the compute method. As a matter of fact, except for the current issue, `_compute_display_name` does not seem to be called by another field's onchange. Fix in Community, Test in Enterprise opw-3823040 Forward-Port-Of: odoo/odoo#159682
Create a SO with the following lines: 1. Price Unit 10000, tax 20% 2. Price Unit 10000, tax 20% 3. Price Unit 10000, tax 20% 4. Price Unit 50, tax 20% Confirm, Create a downpayment of 840.0 Check the downpayment Issue: Amount will be 840.01 This occurs because we compute the downpayment values aggregating so line amounts line by line, each time multiplying for the downpayment percentage and rounding the result. Over multiple lines this mechanism may accumulate a rounding error.
Original PR description
Create a SO with the following lines: 1. Price Unit 10000, tax 20% 2. Price Unit 10000, tax 20% 3. Price Unit 10000, tax 20% 4. Price Unit 50, tax 20% Confirm, Create a downpayment of 840.0 Check the downpayment Issue: Amount will be 840.01 This occurs because we compute the downpayment values aggregating so line amounts line by line, each time multiplying for the downpayment percentage and rounding the result. Over multiple lines this mechanism may accumulate a rounding error. opw-3812925 Forward-Port-Of: odoo/odoo#160797 Forward-Port-Of: odoo/odoo#160521
If an error happens when a website page is being saved, the error message is displayed as a popup on the edited block. Unfortunately, an error dialog is also displayed. This commit prevents that dialog from being displayed when the error is already shown to the user. task-3599890 Forward-Port-Of: odoo/odoo#155057 Forward-Port-Of: odoo/odoo#154050
Original PR description
If an error happens when a website page is being saved, the error message is displayed as a popup on the edited block. Unfortunately, an error dialog is also displayed. This commit prevents that dialog from being displayed when the error is already shown to the user. task-3599890 Forward-Port-Of: odoo/odoo#155057 Forward-Port-Of: odoo/odoo#154050
Create an expired loyalty program with code Open POS session Add product Apply code Issue: code is applied even if expired opw-3624670 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#160685 Forward-Port-Of: odoo/odoo#145609
Original PR description
Create an expired loyalty program with code Open POS session Add product Apply code Issue: code is applied even if expired opw-3624670 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#160685 Forward-Port-Of: odoo/odoo#145609
Steps to reproduce: - Create a storable kit product - Update on hand quantity: only the components are displayed(correct behavior) - In Inventory tab open Inventory Adjustement - Possible to edit kit quantity Bug: In the product tab when trying to update qty the kit product is replaced with its components instead but it is still Possible to edit kit quantity directly in the inventory app Fix: introduced python constraint to prevent user from directly editing the kit product qty op
Original PR description
Steps to reproduce: - Create a storable kit product - Update on hand quantity: only the components are displayed(correct behavior) - In Inventory tab open Inventory Adjustement - Possible to edit kit quantity Bug: In the product tab when trying to update qty the kit product is replaced with its components instead but it is still Possible to edit kit quantity directly in the inventory app Fix: introduced python constraint to prevent user from directly editing the kit product qty opw-3681703 Forward-Port-Of: odoo/odoo#160978 Forward-Port-Of: odoo/odoo#157061
When the user adds a valid Mauritius phone number, it is not correctly parsed by the phonenumbers library, resulting in a user error while sending a WhatsApp message to that number. Steps to produce: - Create a new contact with the Mauritius country selected. - Add a phone number (e.g., '+23057654321'). - Try to send WhatsApp messages using this phone number. - This will throw an Invalid number error. Problem: `phonenumbers==8.12.1` python library is used in odoo for parsing phone
Original PR description
When the user adds a valid Mauritius phone number, it is not correctly parsed by the phonenumbers library, resulting in a user error while sending a WhatsApp message to that number. Steps to produce: - Create a new contact with the Mauritius country selected. - Add a phone number (e.g., '+23057654321'). - Try to send WhatsApp messages using this phone number. - This will throw an Invalid number error. Problem: `phonenumbers==8.12.1` python library is used in odoo for parsing phone numbers. The `8.12.1` version is too old and cannot parse Mauritius phone numbers correctly. Solution: The `8.12.13` version accurately parses Mauritius phone numbers. Currently, The latest version of the phonenumbers library is `8.13.31`. Hence, the latest code from the latest version of the phonenumbers library is monkey-patched into the system. Task - 3799632 Forward-Port-Of: odoo/odoo#160956 Forward-Port-Of: odoo/odoo#157504
Issue ----- In a POS session, some buttons of the numpad and some fields in the client editor form are not translated. **opw-3783252 opw-3756593** Forward-Port-Of: odoo/odoo#157806 Forward-Port-Of: odoo/odoo#157509
Original PR description
Issue ----- In a POS session, some buttons of the numpad and some fields in the client editor form are not translated. **opw-3783252 opw-3756593** Forward-Port-Of: odoo/odoo#157806 Forward-Port-Of: odoo/odoo#157509
The name of some accounts is ambiguous and too generic. For example, the account 3388 was named "Others" which is difficult for non Vietnamese accountants to understand. Some foreigners doing business in Vietnam usually get upset with these ambiguous names --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159550 Forward-Port-Of: odoo/odoo#133266
Original PR description
The name of some accounts is ambiguous and too generic. For example, the account 3388 was named "Others" which is difficult for non Vietnamese accountants to understand. Some foreigners doing business in Vietnam usually get upset with these ambiguous names --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159550 Forward-Port-Of: odoo/odoo#133266
Resolves an issue with Afterpay via Stripe not receiving correct shipping address details, causing transaction failures. Now, ensures shipping address from the order or invoice is accurately sent to Stripe if we have it. backport of this PR: #157828 opw-3419984 Forward-Port-Of: odoo/odoo#160300
Original PR description
Resolves an issue with Afterpay via Stripe not receiving correct shipping address details, causing transaction failures. Now, ensures shipping address from the order or invoice is accurately sent to Stripe if we have it. backport of this PR: #157828 opw-3419984 Forward-Port-Of: odoo/odoo#160300
*: hr_expense Strings within inline templates are not translatable, so we convert these templates into standard templates so that they can be. Task-3761551 enterprise pr: https://github.com/odoo/enterprise/pull/59877 Forward-Port-Of: odoo/odoo#160835 Forward-Port-Of: odoo/odoo#159892
Original PR description
*: hr_expense Strings within inline templates are not translatable, so we convert these templates into standard templates so that they can be. Task-3761551 enterprise pr: https://github.com/odoo/enterprise/pull/59877 Forward-Port-Of: odoo/odoo#160835 Forward-Port-Of: odoo/odoo#159892
When the aggregated value is 0 (9000 + -9000 = 0), it displays an empty cell in spreadsheet, instead of zero. Task: 3827502 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160279 Forward-Port-Of: odoo/odoo#159148
Original PR description
When the aggregated value is 0 (9000 + -9000 = 0), it displays an empty cell in spreadsheet, instead of zero. Task: 3827502 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160279 Forward-Port-Of: odoo/odoo#159148
In Spain, "Cooperativas" have their own variant of the Spanish chart of accounts. In order to support these businesses, we add two extra CoA templates: Cooperatives - SMEs and Cooperatives - Complete. [task-3803050](https://www.odoo.com/web#id=3803050&cids=1&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159357
Original PR description
In Spain, "Cooperativas" have their own variant of the Spanish chart of accounts. In order to support these businesses, we add two extra CoA templates: Cooperatives - SMEs and Cooperatives - Complete. [task-3803050](https://www.odoo.com/web#id=3803050&cids=1&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159357
Prior to this commit, scanning a customer's barcode was not functioning as expected. This fix ensures that customer barcodes can be successfully scanned. opw-3825471 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160177
Original PR description
Prior to this commit, scanning a customer's barcode was not functioning as expected. This fix ensures that customer barcodes can be successfully scanned. opw-3825471 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160177
Prior to this commit, a product search using a barcode would also display additional results matching via fuzzy search. This could lead to irrelevant results being displayed. With this commit, if a search term matches a product's barcode, only the exact match is displayed, excluding fuzzy search results. Additionally, the 'Internal Reference' field has been added to the exact search parameters, further enhancing the precision of product searches. opw-3849376 --- I confirm I have signed
Original PR description
Prior to this commit, a product search using a barcode would also display additional results matching via fuzzy search. This could lead to irrelevant results being displayed. With this commit, if a search term matches a product's barcode, only the exact match is displayed, excluding fuzzy search results. Additionally, the 'Internal Reference' field has been added to the exact search parameters, further enhancing the precision of product searches. opw-3849376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160451
To reproduce the issue: -Drag and drop the rating snippet. -Change the score from options. -Notice that spaces between icons disappear. Specification: In the release notes[[1]]( https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/) of jQuery 3.5.0, it's stated that security fixes related to the HTML parser were implemented. Consequently, self-closing e.g. `<i/>` tags inside function arguments were replaced with e.g. `<i></i>`. As a result, trailing spaces lost significance, causi
Original PR description
To reproduce the issue: -Drag and drop the rating snippet. -Change the score from options. -Notice that spaces between icons disappear. Specification: In the release notes[[1]](…
To reproduce the issue: -Drag and drop the rating snippet. -Change the score from options. -Notice that spaces between icons disappear. Specification: In the release notes[[1]]( https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/) of jQuery 3.5.0, it's stated that security fixes related to the HTML parser were implemented. Consequently, self-closing e.g. `<i/>` tags inside function arguments were replaced with e.g. `<i></i>`. As a result, trailing spaces lost significance, causing icons to stick together. Prior to Odoo 16.2, jQuery 3.3.1 was utilized, which allowed the use of self-closing tags in the append function. This behavior was as expected.However, starting from Odoo 16.2, jQuery version 3.6.3 was adopted. After this PR: Instead of using self-closing `<i/>` tags, `<i></i> ` with a trailing space was used. This trailing space gained significance due to the prefilter no longer ignoring it. Consequently, icons no longer stick together after changing the score. task-3576760 Forward-Port-Of: odoo/odoo#160061
This commit fixes the 'og:site_name' metadata, which previously defaulted to the company name (see [1]), causing issues for multi-site setups. Now, the metadata actually uses the site name. Steps to reproduce: - Navigate to any page - Right-click and select "View Page Source" - In the <head> section, observe the meta property "og:site_name" set to "MyCompany". [1]: https://github.com/odoo/odoo/commit/156955de6b4e6288ac606d29b843081842154eff opw-3791082 Forward-Port-Of: odoo/odoo#1
Original PR description
This commit fixes the 'og:site_name' metadata, which previously defaulted to the company name (see [1]), causing issues for multi-site setups. Now, the metadata actually uses the site name. Steps to reproduce: - Navigate to any page - Right-click and select "View Page Source" - In the <head> section, observe the meta property "og:site_name" set to "MyCompany". [1]: https://github.com/odoo/odoo/commit/156955de6b4e6288ac606d29b843081842154eff opw-3791082 Forward-Port-Of: odoo/odoo#160454
When a register payment is made with a writeoff in foreign currency and when the user set manually an exchange difference account, don't create a write-off. Instead, 2 cases to consider: - When the payment is expressed in a foreign currency different than the invoice's one, play with the rate between amount_currency and balance and let odoo making an exchange difference accordingly. That way, the payment has no write-off and the invoice is fully paid. - When the payment is expressed in co
Original PR description
When a register payment is made with a writeoff in foreign currency and when the user set manually an exchange difference account, don't create a write-off. Instead, 2 cases to consider: - When the payment is expressed in a foreign currency different than the invoice's one, play with the rate between amount_currency and balance and let odoo making an exchange difference accordingly. That way, the payment has no write-off and the invoice is fully paid. - When the payment is expressed in company currency but the invoice has a foreign currency, force the exchange difference to use a rate that will fully paid the invoice without creating any write-off line on the payment. task_id: 3717436 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157398