Tuesday, January 28, 2025
25 changes · saas-17.4
Enhancements to existing features
Accounting upload areas now only appear when users drag actual files, not selected text. This reduces confusion and helps prevent accidental interactions when working in bill and document upload views.
Original PR description
This commit change a bit the behaviour of drag & drop feature in multiple account view. The main goal is to avoid users to drag and drop text in files drop zones. So now, if a user is dragging a text, we hide the files drop zones. Linked:https://github.com/odoo/enterprise/pull/76565 opw-4366605
Resolved issues and error corrections
This fix prevents an error when users accidentally drag a partner name over the bank statement import area during reconciliation. The import dropzone now only appears when a file is being dragged, reducing interruptions and making the workflow more reliable.
Original PR description
Before this commit, if you drag and drop a partner name from the form view of bank_reconciliation in the file import dropzone, a traceback is raise. This commit fix this issue by hiding the dropzone when user is not dragging a file. Linked:https://github.com/odoo/odoo/pull/193355 opw-4366605
Miscellaneous changes
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 Forward-Port-Of: odoo/odoo#191056
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 Forward-Port-Of: odoo/odoo#191056
### 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
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
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
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
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
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, 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
Issue: If we have a X2many that allows to have inactive records (with `context={'active_test': False}` on the field definition) and we specify a specific order for this X2many in this view, web_read won't respect the context of the field and will filter out inactive records. This is because to apply a specific order in the web_read, we use search(), which will filter out inactive records from the `corecords` recordset. Fix: We fix this by forcing active_test=False before calling search a
Original PR description
Issue:
If we have a X2many that allows to have inactive records (with `context={'active_test': False}` on the field definition) and we specify a specific order for this X2many in this view, web_read won't respect the context of the field and will filter out inactive records.
This is because to apply a specific order in the web_read, we use search(), which will filter out inactive records from the `corecords` recordset.
Fix:
We fix this by forcing active_test=False before calling search and reapplying the previous context immediately after.
Closes #194311
Forward-Port-Of: odoo/odoo#194379Followup 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
[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#193973Before this commit, when a user without access to certain orders attempted to load paid orders, the process would fail and result in an error. This was particularly problematic if a POS order was linked to a sale order that the user did not have permission to access, causing the entire loading process to halt. This commit addresses the issue by filtering out paid orders that the user cannot access. opw-4108044 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.c
Original PR description
Before this commit, when a user without access to certain orders attempted to load paid orders, the process would fail and result in an error. This was particularly problematic if a POS order was linked to a sale order that the user did not have permission to access, causing the entire loading process to halt. This commit addresses the issue by filtering out paid orders that the user cannot access. opw-4108044 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193418 Forward-Port-Of: odoo/odoo#177592
The `MRR Evolution` dashboard contained a relation filter that would wrongly refer to the model `sale.temporal.recurrence` even tough its field matching pointed towards `sale.subscription.plan`. From a setup POV, the filter was invalid but the only part we use is the field matching, which was correct in itself. The issue came when we wanted to edit the filter in a database which did not have the model `sale.temporal.recurrence`. task-4467133 opw-4432567 Forward-Port-Of: odoo/enterprise#7687
Original PR description
The `MRR Evolution` dashboard contained a relation filter that would wrongly refer to the model `sale.temporal.recurrence` even tough its field matching pointed towards `sale.subscription.plan`. From a setup POV, the filter was invalid but the only part we use is the field matching, which was correct in itself. The issue came when we wanted to edit the filter in a database which did not have the model `sale.temporal.recurrence`. task-4467133 opw-4432567 Forward-Port-Of: odoo/enterprise#76877
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#77892
Original PR description
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#77892
Steps to reproduce: - Create an invoice with a due date 20 days prior and an amount of $100 - Create a payment of 120$ - Create an invoice of 100$ - Reconcile the second invoice with the payment - Go to the follow-up report Issue: The "In Need of Action" red banner does not appear, even though the overdue amount is positive Cause: The calculation does not account for the already allocated/reconciled payment amount. In this case, the payment shows a balance of -$120, despite being p
Original PR description
Steps to reproduce: - Create an invoice with a due date 20 days prior and an amount of $100 - Create a payment of 120$ - Create an invoice of 100$ - Reconcile the second invoice with the payment - Go to the follow-up report Issue: The "In Need of Action" red banner does not appear, even though the overdue amount is positive Cause: The calculation does not account for the already allocated/reconciled payment amount. In this case, the payment shows a balance of -$120, despite being partially reconciled. -120 + 100 = -20 ≤ 0, which prevents the status from being set to "In Need of Action." Solution: Replace the balance-based calculation with one that uses the `amount_residual` field. opw-4299170 Forward-Port-Of: odoo/enterprise#77679 Forward-Port-Of: odoo/enterprise#76082
Steps to reproduce the bug: - Log in as Mitchel Admin. - Create a storable product with BoM: - Operation: OP1 - Create a Manufacturing order to produce one unit of P1 - Confirm the MO - Assign Mark demo to the OP1 - Validate the MO Problem: The work center productivity record is created using the employee linked to the current user rather than the one assigned to the operation. opw-4416940 Forward-Port-Of: odoo/enterprise#75900
Original PR description
Steps to reproduce the bug:
- Log in as Mitchel Admin.
- Create a storable product with BoM:
- Operation: OP1
- Create a Manufacturing order to produce one unit of P1
- Confirm the MO
- Assign Mark demo to the OP1
- Validate the MO
Problem:
The work center productivity record is created using the employee linked to the current user rather than the one assigned to the operation.
opw-4416940
Forward-Port-Of: odoo/enterprise#75900When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue. Also, the report will show a traceback. This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue. Forward-Port-Of: odoo/enterprise#77424 Forward-Port-Of: odoo/enterprise#76788
Original PR description
When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue. Also, the report will show a traceback. This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue. Forward-Port-Of: odoo/enterprise#77424 Forward-Port-Of: odoo/enterprise#76788
When changes are made through studio, the view needs to be normalized first which in turn requires the use of `difflib.ndiff` that is notorious for slowness in some cases. Refer to this issue on `difflib` https://github.com/python/cpython/issues/119105 for an analysis of why it is slow. In our case, we only care about added and removed lines, not replaced lines, which means `ndiff` is not needed. Instead `unified_diff` is used which is much faster. This PR adapts the module to use `difflib.un
Original PR description
When changes are made through studio, the view needs to be normalized first which in turn requires the use of `difflib.ndiff` that is notorious for slowness in some cases. Refer to this issue on `difflib` https://github.com/python/cpython/issues/119105 for an analysis of why it is slow. In our case, we only care about added and removed lines, not replaced lines, which means `ndiff` is not needed. Instead `unified_diff` is used which is much faster. This PR adapts the module to use `difflib.unified_diff` over `difflib.ndiff` to speedup `edit_view` requests when making any modifications to the view. |no. diff lines|before | after| ------------------|-----------|------------ |~4670 | ~1.4 minutes | ~2.5 sec| opw-4054294 Original PR: https://github.com/odoo/enterprise/pull/67203 Forward-Port-Of: odoo/enterprise#77688
**Steps to reproduce:** - Install stock_barcode and Sales - In Inventory settings, enable "Multi-Step Routes" - Go to "Inventory / Configuration / Warehouse Management / Routes" - Configure the rule of "Deliver in 1 step (ship)": * Propagation of Procurement Group: Fixed * Fixed Procurement Group: [create a new one] - Create a product tracked by lot - Update the quantity (e.g. 100) of the created product and assign it to a lot - Create a SO for a customer with the created product -
Original PR description
**Steps to reproduce:** - Install stock_barcode and Sales - In Inventory settings, enable "Multi-Step Routes" - Go to "Inventory / Configuration / Warehouse Management / Routes" - Configure the rule…
**Steps to reproduce:** - Install stock_barcode and Sales - In Inventory settings, enable "Multi-Step Routes" - Go to "Inventory / Configuration / Warehouse Management / Routes" - Configure the rule of "Deliver in 1 step (ship)": * Propagation of Procurement Group: Fixed * Fixed Procurement Group: [create a new one] - Create a product tracked by lot - Update the quantity (e.g. 100) of the created product and assign it to a lot - Create a SO for a customer with the created product - Confirm the SO - Create another SO for the same customer with the same product => A delivery order should be created with 2 operations with the same product - Open the delivery order in Barcode - Scan the source location - Select the 2nd line - Scan the lot **Issue:** The first line is incremented instead of the second one. Even when all the products for the first line will be scanned, it will not be possible to scan the lot to increment the second line. **Cause:** The selected line is not taken into account when searching the line on which the scanned lot should be applied. **Solution:** Unshift the selected line to the first position of the array of lines to prioritize it when searching for the adequate line for a scanned lot. opw-4208612 Forward-Port-Of: odoo/enterprise#77788 Forward-Port-Of: odoo/enterprise#76713
Steps to reproduce the bug: - Create a storable product "P1" with a BoM. - Go to ECO stage > In Progress > add two approvals: - approval 1: Mitchel admin + Marc Demo - approval 2: Mitchel admin + Marc Demo - Navigate to PLM > BoM Update and create a new ECO: - Create a new ECO: - Type: BoM Update - Apply On: BoM - Product P1 - Start the revision - Move the ECO to In Progress. Problem: A validation error occurs: “The operation cannot be completed: Error
Original PR description
Steps to reproduce the bug:
- Create a storable product "P1" with a BoM.
- Go to ECO stage > In Progress > add two approvals:
- approval 1: Mitchel admin + Marc Demo
- approval 2: Mitchel admin + Marc Demo
- Navigate to PLM > BoM Update and create a new ECO:
- Create a new ECO:
- Type: BoM Update
- Apply On: BoM
- Product P1
- Start the revision
- Move the ECO to In Progress.
Problem:
A validation error occurs:
“The operation cannot be completed: Error, a partner cannot follow twice the same object.”
opw-4421352
Forward-Port-Of: odoo/enterprise#77252
Forward-Port-Of: odoo/enterprise#76232To 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
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) ``` Forward-Port-Of: odoo/enterprise#76792
Steps to reproduce the bug: - Create a storable product “C1”: - MTO + Manufacture - BoM: - Component: 1 unit of C2 - Create a storable product “P1” - Component: 1 unit of C1 - Create a MO to produce one unit of P1: - Confirm - A child MO with one unit of C1 is created - Update the qty producing of P1 to 2 - A new MO to produce one unit of C1 is created Problem: The MO of P1 is linked only to the last MO of C1. This occurs because the “created_productio
Original PR description
Steps to reproduce the bug: - Create a storable product “C1”: - MTO + Manufacture - BoM: - Component: 1 unit of C2 - Create a storable product “P1” - Component: 1 unit of C1 - Create a MO to produce…
Steps to reproduce the bug:
- Create a storable product “C1”:
- MTO + Manufacture
- BoM:
- Component: 1 unit of C2
- Create a storable product “P1”
- Component: 1 unit of C1
- Create a MO to produce one unit of P1:
- Confirm
- A child MO with one unit of C1 is created
- Update the qty producing of P1 to 2
- A new MO to produce one unit of C1 is created
Problem:
The MO of P1 is linked only to the last MO of C1.
This occurs because the “created_production_id” field in the stock move of C1 (associated with the MO of P1) is updated to reference the most recent MO of C1. Additionally, since the following fix:
https://github.com/odoo/odoo/commit/c5b3f41fbd442def9e97acb023a00862e7d03eb3#diff-6d86bc8c3e9aa22586656b702849c5bbbb00c9b97ffd08bc0842e0e68f8948f9R74
Each new MO has its own procurement group.
As a result, when using the _get_children method:
- The method retrieves stock moves linked to the current procurement group.
- It uses their created_production_id to fetch the associated procurement group and then retrieves the related production_id.
However, since the two child MOs of C1 belong to different procurement groups, only the latest MO is returned.
opw-4450210
Forward-Port-Of: odoo/odoo#193952
Forward-Port-Of: odoo/odoo#192952To 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