Daily updates from Odoo
Tuesday, January 28, 2025
15 changes · saas-17.2
Resolved issues and error corrections
The calendar view now displays more consistently after a recent calendar component update. This resolves visual issues such as missing or doubled borders and cropped text in month views, making schedules easier to read.
Original PR description
Since the update of FullCalendar some styling was not properly applied. Which leads to the following issues: - Missing borders - Cropped text in month views - Double borders task-3833841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
[FIX] web_editor: adapt `border-style` value based on border widths **Problem**: Outlook always displays the border of an element if `border-style` is set to `solid`, even when all border widths are 0. **Solution**: Change `border-style` to `none` if all border widths are 0. **Steps to Reproduce**: 1. Open the "Event: Registration Confirmation" email template in the web editor. 2. Add a character and save the template. 3. Check the saved `body_html`. -> All t
Original PR description
[FIX] web_editor: adapt `border-style` value based on border widths
**Problem**:
Outlook always displays the border of an element if `border-style` is set
to `solid`, even when all border widths are 0.
**Solution**:
Change `border-style` to `none` if all border widths are 0.
**Steps to Reproduce**:
1. Open the "Event: Registration Confirmation" email template in the web editor.
2. Add a character and save the template.
3. Check the saved `body_html`.
-> All table elements will have `border-style: solid;` added as inline styling,
causing borders to appear in Outlook.
opw-4211794
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195074
Forward-Port-Of: odoo/odoo#193973To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the recor
Original PR description
To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Tax Group (account.tax.group) Field: Name (name) ``` 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#193013
Before this commit, the search functionality might not retrieve the desired number of products due to the loop condition. This fix ensures that the search retrieves up to the specified limit of products if there are enough available. opw-4426797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191501
Original PR description
Before this commit, the search functionality might not retrieve the desired number of products due to the loop condition. This fix ensures that the search retrieves up to the specified limit of products if there are enough available. opw-4426797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191501
Followup of odoo/odoo#134682 but for code added notably during odoo/odoo@f685e70616e8fe357690cd8e6cfa4543c1d0df24 Also fix the test, as it was not testing the real issue (wrong model used in test). Task-3743525 Forward-Port-Of: odoo/odoo#195301
Original PR description
Followup of odoo/odoo#134682 but for code added notably during odoo/odoo@f685e70616e8fe357690cd8e6cfa4543c1d0df24 Also fix the test, as it was not testing the real issue (wrong model used in test). Task-3743525 Forward-Port-Of: odoo/odoo#195301
Before this commit, syncing a Google Calendar that includes an all-day recurrent event—one of which is rescheduled—would fail entirely. This happened because `full_recurring_event_id` only handled events with a specific date-time format (`T...Z`), causing the regex to break for date-only IDs. opw-4443780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194176
Original PR description
Before this commit, syncing a Google Calendar that includes an all-day recurrent event—one of which is rescheduled—would fail entirely. This happened because `full_recurring_event_id` only handled events with a specific date-time format (`T...Z`), causing the regex to break for date-only IDs. opw-4443780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194176
during refactoring of `hr_holidays` for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a), the `_get_days_request` function has been removed in the `hr_holidays` module, but it is still overridden in `hr_holidays_attendance` Forward-Port-Of: odoo/odoo#190472
Original PR description
during refactoring of `hr_holidays` for 17.0 (commit https://github.com/odoo/odoo/commit/8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a), the `_get_days_request` function has been removed in the `hr_holidays` module, but it is still overridden in `hr_holidays_attendance` Forward-Port-Of: odoo/odoo#190472
Before this commit, the resource_ref field of a server action can disappear when the action is saved. This is due to the following: - the update_related_model_id is a computed stored READONLY field which leads to it not being included in the web_save rpc and is therefore not saved on the record The fix consists to ensure the update_related_model_id is saved by making it readonly=False, which is usually what we want when we have a computed stored field. Task: opw-4513803 Forward-Port-O
Original PR description
Before this commit, the resource_ref field of a server action can disappear when the action is saved. This is due to the following: - the update_related_model_id is a computed stored READONLY field which leads to it not being included in the web_save rpc and is therefore not saved on the record The fix consists to ensure the update_related_model_id is saved by making it readonly=False, which is usually what we want when we have a computed stored field. Task: opw-4513803 Forward-Port-Of: odoo/odoo#195124
Forward-Port-Of: odoo/odoo#194174 Forward-Port-Of: odoo/odoo#193276
Original PR description
Forward-Port-Of: odoo/odoo#194174 Forward-Port-Of: odoo/odoo#193276
This commit add support for comprenhension expression on assign node Forward-Port-Of: odoo/odoo#194878
Original PR description
This commit add support for comprenhension expression on assign node Forward-Port-Of: odoo/odoo#194878
Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before this commit, it crashed with error "Component is destroyed". The reason is that when the dialog closes itself, the ui service focusses the previously active element (an element that was behind the dialog), which in turn blurs the current active element (the input that we edited), which fires the "cha
Original PR description
Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before…
Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before this commit, it crashed with error "Component is destroyed". The reason is that when the dialog closes itself, the ui service focusses the previously active element (an element that was behind the dialog), which in turn blurs the current active element (the input that we edited), which fires the "change" event. However, at that point, the form controller is already destroyed, hence the error. In that flow, we don't want to perform the onchange as we're discarding the form. Actually, we don't want the field to listen to the "change" event anymore. We delay for a micro-tick the activation of the previously active element, to wait for owl to have called destroy on the whole component hierarchy, and thus for the "change" handler to be removed (in input_field_hook). The issue could be reproduced in Studio: - click on Edit menu - open a menu to edit it - change its name but to not blur/click out - press Esc This is a backport of odoo/odoo#195238, where we add a test (hoot). The faulty scenario could not be reproduced in the QUnit suite because we do not precisely enough mock events that occur when focusing/bluring elements. opw-4490577 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#195242
Description of the issue/feature this PR addresses: The "Recycle" repair type wasn't integrated properly into the report template Current behavior before PR: Repair lines with "Recycle" type create empty lines on the repair order report   Desired behavior after PR is merged: Repair lines with "Recycle" type have
Original PR description
Description of the issue/feature this PR addresses: The "Recycle" repair type wasn't integrated properly into the report template Current behavior before PR: Repair lines with "Recycle" type create empty lines on the repair order report   Desired behavior after PR is merged: Repair lines with "Recycle" type have their product description printed on the report --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193502
Steps ----- 1. Add an item to the cart (ensure the total price has decimals). 2. During checkout, apply a coupon (e.g., a 50% discount). 3. Attempt to validate the payment. Issue ----- The frontend user encounters the following error: "Cannot process payment: applied reward was changed or has expired." Cause ----- In some cases, the comparison between initial_amount and the new amount_total fails due to a small decimal difference (e.g., 0.00002). Solution -------- Use the f
Original PR description
Steps ----- 1. Add an item to the cart (ensure the total price has decimals). 2. During checkout, apply a coupon (e.g., a 50% discount). 3. Attempt to validate the payment. Issue ----- The frontend user encounters the following error: "Cannot process payment: applied reward was changed or has expired." Cause ----- In some cases, the comparison between initial_amount and the new amount_total fails due to a small decimal difference (e.g., 0.00002). Solution -------- Use the float_compare function to handle precise rounding. 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#195266
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195241 Forward-Port-Of: odoo/odoo#194500
Original PR description
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195241 Forward-Port-Of: odoo/odoo#194500
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_ 2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020 3. Install _Argentina - Payment Withholdings_ 4. The following issue occurs: ### Explanation: In `_l10n
Original PR description
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina -…
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_ 2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020 3. Install _Argentina - Payment Withholdings_ 4. The following issue occurs: ### Explanation: In `_l10n_ar_withholding_post_init`, for each company, we will compare a previously created dict to the existing accounts. If an account already exists, the data is removed from the dict, and since it is created before we start looping through the Companies to make the comparison, any removed data is removed for the companies that follow as well. ### Fix reasoning: We will copy the original dict to keep a safe version of the data and only modify the copy during the comparison process. opw-4446501 Forward-Port-Of: odoo/odoo#194329