Thursday, January 4, 2024
28 changes · 17.0
New functionality added to Odoo
This update refreshes the translation files for the Argentine localization reports module, ensuring that Spanish language content is current and accurate. The changes maintain consistency across different versions of the software and improve the user experience for Spanish-speaking users in Argentina.
Original PR description
Manual Fowardport latam task 1097 Forward-Port-Of: https://github.com/odoo/enterprise/pull/48754 Forward-Port-Of: https://github.com/odoo/enterprise/pull/47967
Enhancements to existing features
Point of Sale now supports creating tax base lines for selected order lines. This enables a specific Mexican electronic invoicing workflow, helping ensure the required invoice data can be produced correctly.
Original PR description
…r lines This is needed for a specific global invoice flow in l10n_mx_edi. task: 3638126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes a crash that could happen in free trial setups after installing Restaurant POS and then changing the accounting chart through demo data. The system now also checks archived POS configurations, so old linked records are cleaned up properly and the setup continues without interruption.
Original PR description
When you install point_of_sale and then pos_restaurant, you end up with a pos_config with an archived journal. Then, if you change the chart of account via demo data, it doesn't delete the archived log and crashes. To correct this problem, we add `with_context(active_test=False)` to the pos.config search.
Documentation and clarification updates
This pull request updates the corporate Contributor License Agreement signature record for Optesis. It is a legal documentation update that helps keep contribution permissions current and does not affect product functionality.
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
Miscellaneous changes
*: hr_attendance, survey, website_sale This commit fixes all found occurrences of such a case: ```xml <t t-set="classes">some_classes</t> ``` => CSS classes being marked for translation by mistake. A breaking case was found via task-3636009, where the arabic language has a translated class on some element which makes some JS crash because of it. Steps to reproduce (only for 17.0): - Create a website with the "Arabic" language as the default language - Go to the shop page in Arabic
Original PR description
A new accounting test checks that reconciliation continues to work correctly even in rare cases where matching loops occur. This helps protect financial matching reliability when future performance changes are made.
Original PR description
Although it is not a common case, it could happen that some loops are created in reconciliation. This test is added to make sure all implementations still work in that case. It was added after an optimization on the code was attempted to use `UNION ALL` instead of `UNION` in `_update_matching_number`
Fixes an issue where automated actions that show a warning could fail with a server error instead of displaying the message. This restores the expected warning dialog behavior, helping users receive guidance without interruptions.
Original PR description
Before the refactoring introduced at 0a744ac, it was possible to return a warning from a `code`-type base automation with the `action` variable:
```py
if len(record.name) > 20:
action = {
"warning": {
"title": "Name too long",
"message": "The name of the record is too long",
}
}
```
This would trigger a visual dialog with the title and message in the client.
Due to a louche `+=` operator change in the refacto, this kind of automation raises a key error on the server, as the additive part of the operator will try to access the 'warning' key in the result dict, which may not (and usually will not) exist.
I assume this was done in an attempt to 'accumulate' warnings, but the warnings in questions are dict that are not really additive anyway. Better to support the *last* returned warning rather than none at all.
This commit basically returns to the previous situation for onchange warnings.Mobile users can now tap message attachments to preview them when multiple files are attached. The download and delete quick actions are hidden on small screens to prevent them from blocking the preview area, restoring expected attachment access.
Original PR description
When a message had more than 1 attachment, it was not possible to preview the attachment on a mobile device. This happens because the hover buttons for delete/download the file took the whole clickable area of attachment to see the preview. To enable quick actions in mobile, this require non-trivial UI tweaking. To match behaviour of version 16.0, these quick-actions have been disabled in mobile. opw-3664795 Before  After 
The India localization now sets the default sales and purchase tax back to GST 5% instead of the accidentally changed IGST 18%. This helps Indian companies start with the correct standard tax setup and avoid incorrect tax amounts on new transactions.
Original PR description
Problem --------- Before, the default tax for sale and purchase was: GST 5%. Commit 084408a9bb26dcc1ac54986802b08638c72b6235, modfied by accident the default tax to IGST 18%. Objective --------- Revert the deault taxes back to GST 5%. Solution --------- Update the default taxes in the l10n_in template file. task-3634577 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mobile visitors registering for events can now clearly see the quantity selected for each ticket when multiple ticket options are available. This helps prevent registration mistakes and improves the checkout experience on smaller screens.
Original PR description
Issue:
- In mobile when we have multiple tickets, the quantity of
selected tickets is not visible
Steps to reproduce the issue:
- Go to events
- Select any event with multiple tickets
- Go to website
- Click on register now
- Notice in mobile the quantity of selected tickets is not visible
Solution:
- Add style to the quantity of selected tickets
opw-3602057
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update records that GitHub user paulogomes has signed the required Contributor License Agreement. It is an administrative/legal change that helps ensure contributions can be accepted under Odoo's contribution rules.
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 pull request records Sunarc Technologies' signed Contributor License Agreement. It supports Odoo's contribution process by documenting the legal permission needed for their contributions to be accepted.
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 pull request records that GitHub user takliwala has signed Odoo's Contributor License Agreement. This is an administrative/legal update that helps ensure contributions can be accepted under the project's licensing rules.
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
*: hr_attendance, survey, website_sale This commit fixes all found occurrences of such a case: ```xml <t t-set="classes">some_classes</t> ``` => CSS classes being marked for translation by mistake. A…
*: hr_attendance, survey, website_sale This commit fixes all found occurrences of such a case: ```xml <t t-set="classes">some_classes</t> ``` => CSS classes being marked for translation by mistake. A breaking case was found via task-3636009, where the arabic language has a translated class on some element which makes some JS crash because of it. Steps to reproduce (only for 17.0): - Create a website with the "Arabic" language as the default language - Go to the shop page in Arabic - If you are in grid view, click on the "switch to list view" button and if you are in list view, click on the "switch to grid view" button => Crash Note that commit [1] already did something similar a while ago (but more generically than this commit). In this commit here, broken occurrences were found using this regex: ``` <t\s+t-set=["']\w+lass(es)?["']\s*> ``` [1]: https://github.com/odoo/odoo/commit/98678199a32b3ba9af999f76980a6110546ec0fc task-3636009 Forward-Port-Of: odoo/odoo#147631 Forward-Port-Of: odoo/odoo#147490
## Description Saving a new `res.config.settings` (for ex: checking "Use QR code on ticket") can be extremely slow on database with a large number of `pos.order`. ## Analysis Saving a new `res.config.settings` creates a new instance of the config. This will invoke a check on the python constraints calling eventually `_check_currencies` of `pos.config`, which will invoke the compute of `currency_id` setting the field as dirty. The `_compute_currency_rate` of `pos.order` depends on the `curre
Original PR description
## Description Saving a new `res.config.settings` (for ex: checking "Use QR code on ticket") can be extremely slow on database with a large number of `pos.order`. ## Analysis Saving a new…
## Description Saving a new `res.config.settings` (for ex: checking "Use QR code on ticket") can be extremely slow on database with a large number of `pos.order`. ## Analysis Saving a new `res.config.settings` creates a new instance of the config. This will invoke a check on the python constraints calling eventually `_check_currencies` of `pos.config`, which will invoke the compute of `currency_id` setting the field as dirty. The `_compute_currency_rate` of `pos.order` depends on the `currency_id` of the current `pos.config` (via a related). This means the compute will be called with *all* `pos.order` ever made. As the compute itself makes a few calls to `_get_conversion_rate`, which makes a query, it can become slow when the method is called frequently. ## Solution Memoize the call to `_get_conversion_rate`, as similarly done in `account.move.line` from d8d47f9ff8554f4b39487fd2f13c153c7d6f958d to reduce the number queries necessary. ## Benchmark The `create` request to `res.config.settings` on a database with over 240k `pos.order` took | | Before | After | |-------------|-----------|----------| | Timing | 36.9 secs | 4.3 secs | | Query count | 47k | 627 | ## Reference opw-3632273 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147957 Forward-Port-Of: odoo/odoo#145810
Issue - Admin unable to change related user on employee profile due to restricted access to bank account. Steps to reproduce 1- In the Employee app, go to the HR settings tab of an employee. 2- Remove the related user from this profile. 3- Set that removed user as the related user on a different employee profile and save (expect no error). 4- Attempt to revert back to the original user. 5- Encounter an access error. resolution - Added sudo() in the browse operation to prevent
Original PR description
Issue - Admin unable to change related user on employee profile due to restricted access to bank account. Steps to reproduce 1- In the Employee app, go to the HR settings tab of an employee. 2- Remove the related user from this profile. 3- Set that removed user as the related user on a different employee profile and save (expect no error). 4- Attempt to revert back to the original user. 5- Encounter an access error. resolution - Added sudo() in the browse operation to prevent access errors. opw-3578412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144467
Cannot select Working Hour if it doesn't have a company to set up default Working Hour for a company Setps: 1. `Standard 38 hours/week` data doesn't have a company 2. Employees menu > Configuration > Settings 3. cannot select `Standard 38 hours/week` to set --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147860 Forward-Port-Of: odoo/odoo#147794
Original PR description
Cannot select Working Hour if it doesn't have a company to set up default Working Hour for a company Setps: 1. `Standard 38 hours/week` data doesn't have a company 2. Employees menu > Configuration > Settings 3. cannot select `Standard 38 hours/week` to set --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147860 Forward-Port-Of: odoo/odoo#147794
Description of the issue/feature this PR addresses: change "es.po" files to "es_419.po" files to properly make translations for latam --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Description of the issue/feature this PR addresses: change "es.po" files to "es_419.po" files to properly make translations for latam --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes #131211 Forward-Port-Of: odoo/odoo#147821
Original PR description
Fixes #131211 Forward-Port-Of: odoo/odoo#147821
To reproduce: -Create a product with 1 on hand quant -Enable 3 step delivery -Create a SO with product and 1 quant the SO -The forecast widget shows that there is qty available in stock -Create 2nd SO with product and 1 quant -Unreserve the 1st SO pick and reserve pick of 2nd SO Current Behavior: Forecast widget on 2nd SO says no stock available despite being reserved and shows available stock for 1st SO Expected Behavior: Forecast widget on 2nd SO says available stock and no stock
Original PR description
To reproduce: -Create a product with 1 on hand quant -Enable 3 step delivery -Create a SO with product and 1 quant the SO -The forecast widget shows that there is qty available in stock -Create 2nd SO with product and 1 quant -Unreserve the 1st SO pick and reserve pick of 2nd SO Current Behavior: Forecast widget on 2nd SO says no stock available despite being reserved and shows available stock for 1st SO Expected Behavior: Forecast widget on 2nd SO says available stock and no stock for the 1st SO, basically, the reserved SO should have qty in stock on the widget. opw-3590385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144196
Description of the issue/feature this PR addresses: The webhook URLs used by MercadoPago are not sanitized and cause the payment to fail when the URL contains spaces or other non-ASCII characters. Steps to reproduce the bug: 1. Instal the Argentine localization and configure "payment_mercado_pago" as the payment method (test or production). 2. Create an invoice and generate a payment link (the reference will be something like "FA-C 0001-000133444"). 3. Initiate the payment process and it w
Original PR description
Description of the issue/feature this PR addresses: The webhook URLs used by MercadoPago are not sanitized and cause the payment to fail when the URL contains spaces or other non-ASCII characters.…
Description of the issue/feature this PR addresses: The webhook URLs used by MercadoPago are not sanitized and cause the payment to fail when the URL contains spaces or other non-ASCII characters. Steps to reproduce the bug: 1. Instal the Argentine localization and configure "payment_mercado_pago" as the payment method (test or production). 2. Create an invoice and generate a payment link (the reference will be something like "FA-C 0001-000133444"). 3. Initiate the payment process and it will generate an error in the last stage of payment (on the MercadoPago website). - Mercadopago tests credentials TEST-4811719641145832-020115-c5caffc149634e3e9d72fde2b74544d8__LD_LA__-172837665 - Used payment methods: https://www.mercadopago.com.ar/developers/es/docs/checkout-api/additional-content/your-integrations/test/cards - Credencial de test usada TEST-4811719641145832-020115-c5caffc149634e3e9d72fde2b74544d8__LD_LA__-172837665 - Metodo de pago usados: https://www.mercadopago.com.ar/developers/es/docs/checkout-api/additional-content/your-integrations/test/cards Current behavior before PR: Payment in MercadoPago cannot be confirmed when the reference contains spaces. Desired behavior after PR is merged: Payment in MercadoPago is confirmed even when the reference contains spaces. Adhoc Ticket: 68591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147848
**[FIX] website_forum: fix the invalid URL link** How to reproduce: - Login as a portal user, create a new post by adding a URL link - Post Your Question - Login as admin to validate the post - Click on 'To Validate' from the moderation tool - Click on the mentioned URL Throws a Traceback and redirects to the about:blank#blocked page. Technical Reason: The '_update_content' method performs a regular expression on the link by using the escape method, which is later convert the bac
Original PR description
**[FIX] website_forum: fix the invalid URL link** How to reproduce: - Login as a portal user, create a new post by adding a URL link - Post Your Question - Login as admin to validate the post - Click on 'To Validate' from the moderation tool - Click on the mentioned URL Throws a Traceback and redirects to the about:blank#blocked page. Technical Reason: The '_update_content' method performs a regular expression on the link by using the escape method, which is later convert the backslash '\' into '%5C' while html_sanitize. After this commit: Clicking on the mentioned link redirects to the correct URL Task-3472776 Forward-Port-Of: odoo/odoo#147964 Forward-Port-Of: odoo/odoo#141416
Right now, when a turnstile error occurs, the user is displayed a CORS error, which is incorrect. This commit fixes that by displaying a more accurate error message. The fix requires the addition of a small trick which is to use the turnstile error handler system to catch and rethrow the error. It seems useless, but it is actually required as errors thrown by files coming from external domains will be set by the browser as "Script error" and stripped of any further info. So for better
Original PR description
Right now, when a turnstile error occurs, the user is displayed a CORS error, which is incorrect. This commit fixes that by displaying a more accurate error message. The fix requires the addition of a small trick which is to use the turnstile error handler system to catch and rethrow the error. It seems useless, but it is actually required as errors thrown by files coming from external domains will be set by the browser as "Script error" and stripped of any further info. So for better error handling, these few lines are worth it. The error is most likely to happen when duplicating a database as turnstile requires a specific domain name in its cloudflare settings. This improved message will hopefully help support manage better this situation. Hopefully, we can make something in the DB duplication tool to avoid the issue entirely and have this error message displayed only for "real" but rare errors. Forward-Port-Of: odoo/odoo#147886
The "grid images" are grid items that only contain an image (i.e. the image is alone in its column). This distinction with other images in grid mode allows to set the `object-fit` CSS property to `cover` so they take the whole space of the grid item (see commits [1] and [2]). In commit [3], the "Position" option has been added, allowing to switch between the `cover` and `contain` values for this property, to have the possibility to still choose to display the entire image, so it can keep its rat
Original PR description
The "grid images" are grid items that only contain an image (i.e. the image is alone in its column). This distinction with other images in grid mode allows to set the `object-fit` CSS property to…
The "grid images" are grid items that only contain an image (i.e. the image is alone in its column). This distinction with other images in grid mode allows to set the `object-fit` CSS property to `cover` so they take the whole space of the grid item (see commits [1] and [2]). In commit [3], the "Position" option has been added, allowing to switch between the `cover` and `contain` values for this property, to have the possibility to still choose to display the entire image, so it can keep its ratio. However, only the images that are direct children of the column have been considered when checking if it was a grid image and in the related CSS rules. This means that an image with a link cannot be one, since the image is the child of an anchor element `<a>` in that case. It can therefore not be set as "cover" or have the "Position" option. This commit adds the support for images with a link set on them, so they can be considered as grid images too. Steps to reproduce: - Drop the "Masonry" snippet. - Click on the image and set a link on it. => The image is now "contain" and the "Position" option disappeared from the right panel so we cannot change it. [1]: https://github.com/odoo/odoo/commit/e9c7e020daf88022d6e02de0a5620074e8417b5a [2]: https://github.com/odoo/odoo/commit/d8c374e3e6b31bf88aa42952aadf3379936f7600 [3]: https://github.com/odoo/odoo/commit/faf19ef7f87fc043fb9a814516e01b8eeafd9b61 opw-3580128 Forward-Port-Of: odoo/odoo#147884
Before: In chrome, you can see the message "[DOM] Input elements should have autocomplete attributes (suggested: "username"): (More info: https://goo.gl/9p2vKq)". After: The message does not appear. Also, This maintains consistency with the password input which has the attribute autocomplete.  --- I confirm I have signed the CLA and read the PR guid
Original PR description
Before: In chrome, you can see the message "[DOM] Input elements should have autocomplete attributes (suggested: "username"): (More info: https://goo.gl/9p2vKq)". After: The message does not appear. Also, This maintains consistency with the password input which has the attribute autocomplete.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146934 Forward-Port-Of: odoo/odoo#146037
Steps to reproduce ================== Make sure your resolution is around '1368 x 768'. 1. Open/create an opportunity and assign a partner (Joel wills). 2. Go to Joel's portal view. 3. Click on the Opportunity and go to the priority. The priority's alignment is distorted. After this PR ================= Align priority correctly on the portal view of opportunities. Task-3607070 Forward-Port-Of: odoo/odoo#147903 Forward-Port-Of: odoo/odoo#145383
Original PR description
Steps to reproduce ================== Make sure your resolution is around '1368 x 768'. 1. Open/create an opportunity and assign a partner (Joel wills). 2. Go to Joel's portal view. 3. Click on the Opportunity and go to the priority. The priority's alignment is distorted. After this PR ================= Align priority correctly on the portal view of opportunities. Task-3607070 Forward-Port-Of: odoo/odoo#147903 Forward-Port-Of: odoo/odoo#145383
The email_to field of the contactus form have to be dynamic except if the user manually set it via the form options. Unfortunately, the website signature task broke this feature. This commit fixes it and adds a test to prevent this regression in the future. Steps to reproduce the bug: - Go to the contactus page - Edit the page - Add a field on the form - Save the page - Change the company email address via the settings => The contactus form still send the email to the old email add
Original PR description
The email_to field of the contactus form have to be dynamic except if the user manually set it via the form options. Unfortunately, the website signature task broke this feature. This commit fixes it…
The email_to field of the contactus form have to be dynamic except if the user manually set it via the form options. Unfortunately, the website signature task broke this feature. This commit fixes it and adds a test to prevent this regression in the future. Steps to reproduce the bug: - Go to the contactus page - Edit the page - Add a field on the form - Save the page - Change the company email address via the settings => The contactus form still send the email to the old email address. --- Since [this other commit], the recipient email option of the form on the `/contactus` page is not filled correctly with the company email. By chance, the form signature task fixed the bug but introduced another one. The previous commit fixed the bug introduced by the form signature task but reintroduced the inital bug. This commit fixes the initial bug and adds a test. By default, the form on the `/contactus` page sends emails to the email address of the company. Unfortunately, before this commit, when a user entered edit mode, the Recipient E-mail option always displayed "info@yourcompany.example.com" even when the company's e-mail address was different. This commit corrects this by displaying the dynamic value of `company.email` in the Recipient E-mail option coming from the data-for. Steps to reproduce the issue fixed by this commit: - Go to Settings > General Settings - Update the company's email address - Go to /contactus and edit - Click on the form => The recipient email value is still "info@yourcompany.example.com" instead of the company's email address. This commit fixes the issue, adds a test to ensure the recipient email option is correct and adds a utility to parse the data-for data. Bonus: this commit also fixes the following issue catched by sentry: - Go to /contactus - Click on Edit - In the Form option, remove the content of the 'Recipient Email' field. - Save - Fill and submit the form => An error is generated in the log. [this other commit]: https://github.com/odoo/odoo/commit/043e1fdf923d2037dd8da128ab99388f0c92e544 --- task-3382195 sentry-4633940473 Forward-Port-Of: odoo/odoo#147759 Forward-Port-Of: odoo/odoo#126508
Before this PR: Previously, when the command palette was opened and a navigation command ("/") was being executed with single or multiple dialog boxes behind it, only the command palette would close. This left the dialog boxes open. After this PR: Now, when a navigation command ("/" ) is being executed from the command palette, all the dialog boxes and the command palette close simultaneously. Task-3441132 Description of the issue/feature this PR addresses: Current behavior before
Original PR description
Before this PR:
Previously, when the command palette was opened and a navigation command ("/") was being executed with single or multiple dialog boxes behind it, only the command palette would close. This left the dialog boxes open.
After this PR:
Now, when a navigation command ("/" ) is being executed from the command palette, all the dialog boxes and the command palette close simultaneously.
Task-3441132
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#147399
Forward-Port-Of: odoo/odoo#147113[FIX] l10n_ar_edi, l10n_ar_reports: add missing translations Issue: spanish_ar translation is missing for some menu items and template names in the accounting app Steps to reproduce: 1- install l10n_ar 2- switch language to Spanish(AR) 3- Open accounting app 4- check menu items Solution: Issue was that the translation file was called es.po and for spanish (AR) language it should fallback to es_419 As per the translation code found here in in 'translate.py' in odoo tools https:/
Original PR description
[FIX] l10n_ar_edi, l10n_ar_reports: add missing translations Issue: spanish_ar translation is missing for some menu items and template names in the accounting app Steps to reproduce: 1- install l10n_ar 2- switch language to Spanish(AR) 3- Open accounting app 4- check menu items Solution: Issue was that the translation file was called es.po and for spanish (AR) language it should fallback to es_419 As per the translation code found here in in 'translate.py' in odoo tools https://github.com/odoo/odoo/blob/20a3998c3073af8a5d95f8303283107363caed85/odoo/tools/translate.py#L1565-L1574 opw-3601556