Daily updates from Odoo
Navigate
Branch
Tuesday, January 28, 2025
71 changes
2 changes
Miscellaneous changes
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
15 changes
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
32 changes
Enhancements to existing features
This update refreshes translation files and related report labels across multiple country-specific Odoo modules. It improves language consistency for users working with local tax, payroll, EDI, and financial reporting features, with no expected change to business workflows.
Accounting reports now visually distinguish draft or unposted entries when users choose to include them. This makes reports clearer and more consistent with the rest of Odoo, helping users avoid mistaking draft figures for posted accounting data.
Original PR description
Before that, when you toggled the option to see the unposted entries in accounting reports, they'd appear but, unlike in the rest of Odoo, they wouldn't stand out. They now have the same styling as in list view task-4443453
Subscription plans now support plural wording, so labels and invoice-related text can read more naturally for customers and staff. This improves clarity across subscription sales, renewals, payments, upsells, and stock-related subscription flows without changing the core business process.
The rental and subscription website shop pages no longer reuse outdated product metadata from the standard shop flow. This keeps the page structure cleaner and better aligned with current website sale behavior, with no expected change to the customer shopping experience.
Original PR description
task-3866937 See also: - https://github.com/odoo/odoo/pull/189289
Point of Sale orders no longer rely on a separate “Invoiced” status; the system now checks the linked invoice directly. This makes invoice tracking more reliable and also prevents refund quantities from being counted twice in affected localized Point of Sale flows.
Original PR description
*: l10n_cl_edi_pos, l10n_de_pos_cert, l10n_pe_edi_pos In this commit: ========== - We are removing the `Invoiced` state from the Point of Sale order and using the `account_move` field to check if the order has been invoiced. - Removed problematic single-line code which caused an issue that refund quantity was updated twice during the refund process. Related PR: - Community: https://github.com/odoo/odoo/pull/187549 - Upgrade: https://github.com/odoo/upgrade/pull/6903 task-4184446
Belgian reporting now includes automatic reminders when companies may need to file an EC Sales List or Partner VAT Listing. This helps reduce missed mandatory filings and supports compliance with Belgian tax reporting requirements.
Original PR description
Helps ensure compliance with Belgian reporting requirements by introducing activities for mandatory reports: * EC Sales List: Triggered when fields 44, 46, or 48 in the tax report are filled * Partner VAT Listing: Prompted when the client_nihil field in the December VAT declaration is False while the closing entry is made in Q4 The idea is to reduce the risk of oversight. Task ID: 4291228
Sales order cancellations no longer use a separate cancellation email wizard, reducing confusion around whether customers should be notified automatically. Related planning and subscription tests were adjusted so these apps continue to work with the updated sales flow.
Original PR description
The sale order cancel wizard has been removed as it was deemed unnecessary and confusing to send cancellation mails when cancelling an order. A message can always be sent through the chatter when necessary. task-4212816
Resolved issues and error corrections
The appraisal report now uses the correct status values when assigning colors. This ensures report visuals accurately reflect each appraisal's state, reducing confusion for HR users reviewing appraisal progress.
Original PR description
- update the appraisal state values in the `COLORS_BY_STATE` dict inm the report Task: 4521549
Code cleanup and technical improvements
HR-related screens now use the employee-specific avatar field instead of a user avatar field when showing employees. This is an internal cleanup that keeps employee displays consistent and reduces custom technical maintenance, with little expected day-to-day impact for users.
Original PR description
This commit replaces fields `many2*_avatar_user` by `many2*_avatar_employee` when it's used on `hr.employee` fields. This allows to remove a patch on `Many2*AvatarUserField` to support `hr.employee` features. This patch could be useless since we already have a field with those features.
Website appointment widgets were adapted to work with Odoo's newer interaction system, keeping booking and search snippets compatible as the platform evolves. A related subscription portal test was also adjusted so automated checks continue to match the updated page structure.
Original PR description
The public widget system is being replaced by a new Interaction class (see pull request https://github.com/odoo/odoo/pull/185998). This PR is the corresponding enterprise change necessary to make it work. Note that it only adapts some code. The rest of public widgets will be refactored soon, after this PR lands.
This update removes redundant cleanup code that did not affect how the software works. It keeps the codebase simpler and easier to maintain, with no expected change for end users.
Original PR description
Not sure who "innovated" that, but it's essentially a complicated no-op.
Miscellaneous changes
This pull request is marked as work in progress and only shows a generic test file change, so there is no clear business-facing product change yet. It appears to be a minor internal or placeholder update with no expected impact on day-to-day Odoo usage.
NB: both commits must be updated in FW port for change in company root owner. [FIX] documents: ensure access after upload in Company Otherwise, documents are only accessible by superusers as the document is not shared with anyone and owned by OdooBot. [IMP] documents: improve backend UI Based on users feedback, * partial revert of 78b21e99 regarding the search panel. * Redirect uploads in Recent and All to My Drive. * Increase visibility of record parent folder. Note that this
Original PR description
NB: both commits must be updated in FW port for change in company root owner. [FIX] documents: ensure access after upload in Company Otherwise, documents are only accessible by superusers as the document is not shared with anyone and owned by OdooBot. [IMP] documents: improve backend UI Based on users feedback, * partial revert of 78b21e99 regarding the search panel. * Redirect uploads in Recent and All to My Drive. * Increase visibility of record parent folder. Note that this will only occur after the views are updated. Task-4485969 Forward-Port-Of: odoo/enterprise#77846 Forward-Port-Of: odoo/enterprise#77293
Purpose ======= Allow managing documents version like it was done in 17.4. We created a new action for it, that will open a dialog in which we can download and delete versions, but also upload new ones. Reorder the actions we can do when selecting documents. Add "Export" and "Insert In Spreadsheet" actions, for consistency with other views, those actions are available only in the list view. Task-4480340 Forward-Port-Of: odoo/enterprise#77899 Forward-Port-Of: odoo/enterprise#77327
Original PR description
Purpose ======= Allow managing documents version like it was done in 17.4. We created a new action for it, that will open a dialog in which we can download and delete versions, but also upload new ones. Reorder the actions we can do when selecting documents. Add "Export" and "Insert In Spreadsheet" actions, for consistency with other views, those actions are available only in the list view. Task-4480340 Forward-Port-Of: odoo/enterprise#77899 Forward-Port-Of: odoo/enterprise#77327
Steps ----- 1. Sign > 'Upload a PDF & Sign' 2. Choose a PDF with a large amount of pages (typically 40 pages should trigger the issue). 3. The PDF is not visible, the viewer is fully white. Cause ----- The `canvas` HTML element `#canvas_layer_0` used to display information related to radio buttons crashes if its height is too important because there are a lot of pages in the PDF. There's no issue with the PDF itself, when dragging a sign item over the document, the canvas is hidden and
Original PR description
Steps ----- 1. Sign > 'Upload a PDF & Sign' 2. Choose a PDF with a large amount of pages (typically 40 pages should trigger the issue). 3. The PDF is not visible, the viewer is fully white. Cause ----- The `canvas` HTML element `#canvas_layer_0` used to display information related to radio buttons crashes if its height is too important because there are a lot of pages in the PDF. There's no issue with the PDF itself, when dragging a sign item over the document, the canvas is hidden and the PDF appears correctly. The exact problematic value depends on browser and environment, see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/canvas#maximum_canvas_size Solution ----- Use a maximum canvas size but keep the styling of the canvas element to cover all the PDF viewer. This means a scaling factor needs to be applied to the position of the sign items between which the lines are drawn. opw-4407698 Forward-Port-Of: odoo/enterprise#75765
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#77296 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#77296
Forward-Port-Of: odoo/enterprise#75900This commit ensures that the websocket connection is established when receiving a connect or initialized event. This can happen in multitab use of Odoo. Forward-Port-Of: odoo/enterprise#77619 Forward-Port-Of: odoo/enterprise#77416
Original PR description
This commit ensures that the websocket connection is established when receiving a connect or initialized event. This can happen in multitab use of Odoo. Forward-Port-Of: odoo/enterprise#77619 Forward-Port-Of: odoo/enterprise#77416
When you had tax closing entries that depended on a main closing entry, the posting of that main entry would log a message on each depending entry containing a link to the main closing entry. In [this commit] the way that message is constructed was changed, making it safer but also causing the link HTML to be escaped. It would just show raw HTML in the logged message instead of a link. This commit constructs the message in a correct and safe way so the link works again in the logged messag
Original PR description
When you had tax closing entries that depended on a main closing entry, the posting of that main entry would log a message on each depending entry containing a link to the main closing entry. In [this commit] the way that message is constructed was changed, making it safer but also causing the link HTML to be escaped. It would just show raw HTML in the logged message instead of a link. This commit constructs the message in a correct and safe way so the link works again in the logged message. [this commit]: https://github.com/odoo/enterprise/commit/09f5b35493bee7b63e96e8b28ad741aeb5ee80e5 Forward-Port-Of: odoo/enterprise#77826
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
version: - 18.0 Steps to reproduce: - Install the Project and Sign modules. - Open a project. - Click on the "Signature Request" action. - Select a document and click "Sign Now." - Complete the signing process. - Click the "Back to Project" button. Issue: - Clicking "Back to Project" opens a new wizard instead of returning to the project view. Cause: - The project view is set to always open in a new target. Solution: - Update the target to "current" to ensure the button red
Original PR description
version: - 18.0 Steps to reproduce: - Install the Project and Sign modules. - Open a project. - Click on the "Signature Request" action. - Select a document and click "Sign Now." - Complete the signing process. - Click the "Back to Project" button. Issue: - Clicking "Back to Project" opens a new wizard instead of returning to the project view. Cause: - The project view is set to always open in a new target. Solution: - Update the target to "current" to ensure the button redirects correctly to the project view. task:4431882 Forward-Port-Of: odoo/enterprise#76321
Steps to reproduce: 1. Install l10n_mx on runbot and go to MX company 2. Set rates for Day 1 (19.839 MXN/USD) and Day 2 (19.9338 MXN/USD) 3. Create an invoice with date Day 1 for 23,664 USD 4. Add a payment for 9 USD on Day 1 5. Create a bank transaction for a large MXN amount (let's say 600,000) on Day 2 6. Click "Match" for this transaction 7. In reconciliation widget, select invoice created before 8. Change amount in currency reconciled from invoice to 6,954.76 USD (amount in MXN shou
Original PR description
Steps to reproduce: 1. Install l10n_mx on runbot and go to MX company 2. Set rates for Day 1 (19.839 MXN/USD) and Day 2 (19.9338 MXN/USD) 3. Create an invoice with date Day 1 for 23,664 USD 4. Add a…
Steps to reproduce: 1. Install l10n_mx on runbot and go to MX company 2. Set rates for Day 1 (19.839 MXN/USD) and Day 2 (19.9338 MXN/USD) 3. Create an invoice with date Day 1 for 23,664 USD 4. Add a payment for 9 USD on Day 1 5. Create a bank transaction for a large MXN amount (let's say 600,000) on Day 2 6. Click "Match" for this transaction 7. In reconciliation widget, select invoice created before 8. Change amount in currency reconciled from invoice to 6,954.76 USD (amount in MXN should update to 137,975.49) 9. Validate the reconciliation 10. Go to the journal items and show items from journal entry linked to invoice > check partial reconciliation. The reconciled item has a residual of -0.01 and not 0. Analysis: During reconciliation, the rate used is always that of the invoice, not the rate of the invoice residuals. https://github.com/odoo/odoo/blob/4e724323d811dec76c186b5cfff6e4b0135b2128/addons/account/models/account_move_line.py#L1874 However, in the bank reconciliation widget, the residuals' rate was being used to compute the company currency balance of the new AML to create. This led to a different amount than the amount that can actually be reconciled. See [this google sheet](https://docs.google.com/spreadsheets/d/1IoKfuOmSeBS9MrU_DkH_73PGtJd7tb73KuAKm5QsrqI/edit?usp=sharing) for analysis Solution: Use the invoice rate in the bank reconciliation widget. opw-4222310 Forward-Port-Of: odoo/enterprise#77780 Forward-Port-Of: odoo/enterprise#76935
Missing indexes: - `whatsapp.message.parent_id` is hit during Fkey lookup during unlinking to set the value to null during `whatsapp.message`'s GC. - `marketing.trace.whatsapp_message_id` is the inverse of the One2many `marketing_trace_ids`, index will be hit when the ORM reads the O2m field. `marketing_trace` is usually a large table, a `Seq.Scan` should be avoided. Would also be hit during whatsapp's GC Forward-Port-Of: odoo/enterprise#77907
Original PR description
Missing indexes: - `whatsapp.message.parent_id` is hit during Fkey lookup during unlinking to set the value to null during `whatsapp.message`'s GC. - `marketing.trace.whatsapp_message_id` is the inverse of the One2many `marketing_trace_ids`, index will be hit when the ORM reads the O2m field. `marketing_trace` is usually a large table, a `Seq.Scan` should be avoided. Would also be hit during whatsapp's GC Forward-Port-Of: odoo/enterprise#77907
Fix traceback when changing the date in the find duplicate tool When the user changes the date in the find duplicate tool, a traceback occurs when transitioning from no rows displayed to rows being displayed. This issue is caused by the `getRowClass` function referencing the outdated `firstIdsInGroup` field, which is never updated. If there were no values initially, the function attempts to call `includes` on a `false` value, resulting in the error. This commit resolves the issue by rem
Original PR description
Fix traceback when changing the date in the find duplicate tool When the user changes the date in the find duplicate tool, a traceback occurs when transitioning from no rows displayed to rows being displayed. This issue is caused by the `getRowClass` function referencing the outdated `firstIdsInGroup` field, which is never updated. If there were no values initially, the function attempts to call `includes` on a `false` value, resulting in the error. This commit resolves the issue by removing the obsolete `firstIdsInGroup` field and adding a condition to ensure that the value being checked is an array, preventing any traceback. no task id Forward-Port-Of: odoo/enterprise#77856
Steps to reproduce: 1. In the Odoo home menu, switch to the mobile view 2. Don't refresh the page 3. Click on the document app 4. Traceback occurs Technical Reason: without refreshing the template was not updating according to mobile view and in 'documents.SearchPanel' was replacing 'we.SeachPanel.Small' with 'web.SearchPanel.Section' and 'we.SeachPanel.Small' is only called if 'env.isSmall'. After this commit: No traceback will occur while opening the document app in mobile view.
Original PR description
Steps to reproduce: 1. In the Odoo home menu, switch to the mobile view 2. Don't refresh the page 3. Click on the document app 4. Traceback occurs Technical Reason: without refreshing the template was not updating according to mobile view and in 'documents.SearchPanel' was replacing 'we.SeachPanel.Small' with 'web.SearchPanel.Section' and 'we.SeachPanel.Small' is only called if 'env.isSmall'. After this commit: No traceback will occur while opening the document app in mobile view. Task-4437768 Forward-Port-Of: odoo/enterprise#76355
Before this commit, the quantity invoiced in _prepare_invoice_line would be compted based on the result of _get_subscription_qty_invoiced for a future period. For product invoiced based on ordered quantity, it makes no sense as the quantity is the ordered quantity. This commit split the logic to reuse code when we need to know which quantity must be invoiced or which quantity have been invoiced in the past. Forward-Port-Of: odoo/enterprise#75150
Original PR description
Before this commit, the quantity invoiced in _prepare_invoice_line would be compted based on the result of _get_subscription_qty_invoiced for a future period. For product invoiced based on ordered quantity, it makes no sense as the quantity is the ordered quantity. This commit split the logic to reuse code when we need to know which quantity must be invoiced or which quantity have been invoiced in the past. Forward-Port-Of: odoo/enterprise#75150
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document (same checksum) as a sign template in the Sign app. attempting to send it, gives an access error. ### Steps to reproduce: 1. Upload a document to Documents app with a user (ie. Mitchell Admin). 2. by default, the document is uploaded with view access to all internal users. 3. login as another
Original PR description
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document…
### Issue: - when a user uploads a document to the Documents app, and grants only view access to that document to other internal users (default behavior). - if another user uploads the same document (same checksum) as a sign template in the Sign app. attempting to send it, gives an access error. ### Steps to reproduce: 1. Upload a document to Documents app with a user (ie. Mitchell Admin). 2. by default, the document is uploaded with view access to all internal users. 3. login as another internal user (ie. Mark Demo) and upload the same document as a sign template in the Sign app. 4. set the template's `signed document folder` to the same folder as the document uploaded by Mitchell Admin. 5. attempt to send the document for signing. 6. an access error is raised. ### Solution: - Prior to the fix, the `create` method, relied solely on matching the `checksum` of the `sign_requets` attachment with existing documents which resulted in documents not related to the sign request being set as the `reference document`. - The fix now gets the correct document by searching for documents with the same `attachment_id` as the sign request's template attachment. OPW-4421368 Forward-Port-Of: odoo/enterprise#77520
Having no manual sequence on report lines/columns might be problematic in case of DB upgrade, if the line order changed in the xml files, as the report won't adapt and update the sequence field. Setting auto_sequence will ensure that this won't ever be a problem anymore (and avoid the tedious task of manually setting the sequence on each line/column) Forward-Port-Of: odoo/enterprise#77487
Original PR description
Having no manual sequence on report lines/columns might be problematic in case of DB upgrade, if the line order changed in the xml files, as the report won't adapt and update the sequence field. Setting auto_sequence will ensure that this won't ever be a problem anymore (and avoid the tedious task of manually setting the sequence on each line/column) Forward-Port-Of: odoo/enterprise#77487
Issue: ========== A traceback occurs when validating the quantity produced through the Barcode app, causing the process to fail. Steps to Reproduce: ======================= 1. Create a new database and install the Manufacturing module. 2. Create and confirm a manufacturing order (MO) from the backend. 3. Open the Barcode app, access the MO, edit the quantity produced, and validate. With this commit: ==================== Prevent error when lot_producing_id is undefined during f
Original PR description
Issue: ========== A traceback occurs when validating the quantity produced through the Barcode app, causing the process to fail. Steps to Reproduce: ======================= 1. Create a new database and install the Manufacturing module. 2. Create and confirm a manufacturing order (MO) from the backend. 3. Open the Barcode app, access the MO, edit the quantity produced, and validate. With this commit: ==================== Prevent error when lot_producing_id is undefined during form save and allow smooth validation of produced quantities. task-4443489 Forward-Port-Of: odoo/enterprise#77806 Forward-Port-Of: odoo/enterprise#76426
How to reproduce ================ - Have no batch for receipt at least one delivery batch; - Go to the Barcode app > Operations > Receipts; - On the Batches button, you can see a wrong count number, this number takes in account all batches regardless their picking type. Cause of the issue ================== For the batches, the picking type wasn't used by the `search_count` in the method responsible of this count (`get_model_records_count`.) Forward-Port-Of: odoo/enterprise#77736
Original PR description
How to reproduce ================ - Have no batch for receipt at least one delivery batch; - Go to the Barcode app > Operations > Receipts; - On the Batches button, you can see a wrong count number, this number takes in account all batches regardless their picking type. Cause of the issue ================== For the batches, the picking type wasn't used by the `search_count` in the method responsible of this count (`get_model_records_count`.) Forward-Port-Of: odoo/enterprise#77736
This PR adds non regression tests for the integration of monster in hr_recruitment. These tests also cover at the same time the code of the hr_recruitment_integration_base module. The PR also fixes a bug in the hr_recruitment_integration_base module which was found thanks to the tests. The bugfix is about fixing variable names in the _start_new_campaign to match the fields of the module. task-4199469 Forward-Port-Of: odoo/enterprise#77491 Forward-Port-Of: odoo/enterprise#77152
Original PR description
This PR adds non regression tests for the integration of monster in hr_recruitment. These tests also cover at the same time the code of the hr_recruitment_integration_base module. The PR also fixes a bug in the hr_recruitment_integration_base module which was found thanks to the tests. The bugfix is about fixing variable names in the _start_new_campaign to match the fields of the module. task-4199469 Forward-Port-Of: odoo/enterprise#77491 Forward-Port-Of: odoo/enterprise#77152
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense. - Go back to the expenses list view Issue: Notice this expense is at the top of the list and grayed out Cause: The order is determined by the extract_state_processed field: https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_ext
Original PR description
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and…
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense. - Go back to the expenses list view Issue: Notice this expense is at the top of the list and grayed out Cause: The order is determined by the extract_state_processed field: https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_extract/models/hr_expense.py#L21 An expense is muted when this field is set to `True`: https://github.com/odoo/enterprise/blob/1df090289f3c45c200d133734989a6d9a8073145/hr_recruitment_extract/views/hr_applicant_views.xml#L67 Solution: We override `iap_extract` method https://github.com/odoo/enterprise/blob/2e3113562309bf4d440e12ab09eaf94d0b302f1f/iap_extract/models/extract_mixin.py#L69 If the expense is not in draft, it indicates that the process continued without waiting for the extraction process to complete (values were manually entered). To ensure a consistent extraction state, we extend the "Check OCR Status" logic to prevent an infinite waiting_extraction status. opw-4239404 Forward-Port-Of: odoo/enterprise#76015 Forward-Port-Of: odoo/enterprise#75202
### Steps to reproduce: - In Accounting, create a new Customer invoice - Create a payment for this invoice - In Customer > Batch Payments create a new batch payment - Select the payment you created - In the Dashboard click on the three dots of the "Bank" block and click on transactions - Create a new transaction with the same amount as the invoice - Click "Match" on the right - In the "Batch Payments" tab select the Batch payment previously created - Validate - Back in the Dashboard, c
Original PR description
### Steps to reproduce: - In Accounting, create a new Customer invoice - Create a payment for this invoice - In Customer > Batch Payments create a new batch payment - Select the payment you created - In the Dashboard click on the three dots of the "Bank" block and click on transactions - Create a new transaction with the same amount as the invoice - Click "Match" on the right - In the "Batch Payments" tab select the Batch payment previously created - Validate - Back in the Dashboard, click on the reconcile button of the Bank block - In the "Batch Payments" tab the batch payment is still here even if it is reconciled ### Cause: There are no domain to filter the batch payments. ### Solution: Add a domain to check the state of the batch payments, do not display if it is "reconciled". opw-4461341 Forward-Port-Of: odoo/enterprise#77017
22 changes
Enhancements to existing features
The Mexican payroll sample data has been refreshed for demo employees, including updated records and profile images. This helps make demonstrations and testing of Mexican HR payroll scenarios more accurate and representative.
Original PR description
This commit modifies Elvera and Roque demo data for hr mexican localization target: 17.0 -> master task-4486643
Resolved issues and error corrections
PayPal checkout buttons are now disabled when customers are not yet allowed to pay, such as when required terms and conditions have not been accepted. This prevents customers from bypassing checkout requirements and makes PayPal behavior consistent with other payment methods.
Original PR description
Prior to this commit, the PayPal SDK was used to render a single payment button that replaced the generic submit button of the payment form. This prevented disabling the button when the conditions were not met to allow the payment (e.g., the "Terms and Conditions checkbox was not ticked) as this mechanism relies on the PaymentButton public widget, which was incompatible with PayPal's custom buttons. This commit ensures that PayPal buttons, too, are disabled when the payment is not allowed by making the PaymentButton widget attach itself to the PayPal button container, creating two PayPal buttons - one enabled and one permanently disabled - instead of one, and alternately showing them depending on whether the payment is allowed. opw-4354267
This fixes an issue where users could receive a validation error after changing the bank journal and selecting SEPA Direct Debit while registering an invoice payment. The system now keeps the selected valid journal and payment method, allowing payments to be created as expected.
Original PR description
Steps: - Install `account_sepa_drect_debit` - Duplicate the default bank journal and add a bank account - Create an invoice for a partner with valid mandate - Open the payment register wizard - Change journal from default one to the duplicated one - Select 'SEPA Direct Debit' as payment method - Click on 'Create payments' -> Validation Error: "The selected payment method is not available ..." Cause: In `account_sepa_direct_debit.action_create_payments`, the `journal_id` is recomputed when calling the `write` method on the wizard. Fix: Dont recompute the `journal_id` if it is already in `available_journal_ids` Note: We do the same for `payment_method_line_id` opw-4485191
This fix prevents an unwanted horizontal scrollbar from appearing in mobile self-order when a product has a very long name and no image. Long product names are now shortened visually, keeping the ordering screen easier to use on phones.
Original PR description
- Fix issue when in self order on mobile a weird horizontal scroll bar appears when a product with a long name (and no image) was sell. - Now we just truncate the product name to avoid this issue. task-id: 4510206 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 fix ensures point-of-sale receipts and payment screens calculate cash rounding correctly when a customer pays more than the order total and receives change. It prevents missing or incorrect rounding amounts, helping cashiers provide accurate totals and receipts in cash-rounding setups.
Original PR description
Check the commit message for description.
Demo data for Point of Sale and Restaurant now includes the unique identifiers required by the user interface. This prevents demo orders and restaurant sessions from failing or behaving incorrectly when loaded in the frontend.
Original PR description
Before this commit, demo data had no uuid, which is necessary for the rontend to function properly. A fix had been merged by adding a default value to the uuid field, but this did not work. The frontend is responsible for creating UUIDs, so we added the uuid to the demo data.
This fixes several guided product walkthroughs that could behave inconsistently during testing or demonstrations. The changes make the tours wait for pages, dialogs, chat areas, and interface loading states before continuing, reducing flaky behavior and improving confidence in automated checks.
Original PR description
In this commit, we fix multiple tours on step that can cause non deterministic behaviors: - show_expense_receipt_tour: Wait the chatter is loaded to prevent lost focus on the input targetted on the next step. - discuss_channel_tour: use hover helper to concat three steps. - website_gray_color_palette: use range hoot helper and wait ui loading appears before to wait it disappears... In the goal to change tour engine and base it on waitFor instead of MutationObserver, these additionnal steps are crucial. - website_form_contactus_submit: wait livechat if module is installed. - course_member: wait the modal is shown before click on element inside. 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
Point of Sale now correctly validates orders where payments bring the total to zero, such as purchases fully covered by an eWallet. This prevents confusing prompts for an extra zero-value payment and helps cashiers complete affected sales smoothly.
Original PR description
Before this commit, a rounding error could leading to scenarios where orders with a zero total could not be validated. For instance, adding a product priced at $70 with a 15% tax included and then applying an eWallet payment in PoS would result in a zero total. However, during the payment step, the system erroneously prompted for an additional zero-amount payment line, causing confusion and preventing order validation. opw-4487591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Odoo from repeatedly marking normal email template content as quoted text during message processing. As a result, emails sent from chatter or automated field-change notifications should display correctly without unnecessary "Read more" breaks.
Original PR description
Some mail templates are having an issue where read more is getting redundant. This happens when we either send the template as mail in chatter or in some cases when an automatic mail is sent when a…
Some mail templates are having an issue where read more is getting redundant. This happens when we either send the template as mail in chatter or in some cases when an automatic mail is sent when a tracked field is changed. Technical Info: - Generally when a template is processed/added it is sanitized as xml (sanitize mode as 'email_outgoing'). - The body(a HTML field) is being sanitized. - Then when sending a message in chatter is again sanitized again into field `body_html` in `mail.message.compose`. - The `mail.message.compose` is further copied into `mail.message` where the field is again sanitized. Now that problem is that when we sanitized the template of `mail.template` we dont sanitize any of the tags as at this step the targetted output is a xml (beacause can contain any tags as opposed to as html). In this very step we do a clean up of tags which is causing the problem (in method 'tag_quote') which adds the read-more inducing tag called `data-o-mail-quote`. When this template is again sanitized now the due to the [condition](https://github.com/odoo/odoo/blob/db3b2671efaf7cb84dce93eefd9c3f12c0e6a65c/odoo/tools/mail.py#L221) here every other node is set to be having the tag `data-o-mail-quote`. When a break(`<br />`) tag has this tag it induces the `read more`. Solution: - The main culprit is quote detection causing all the issues. So a condition to stop it mutilating the main content of html which keeps on adding unnecessary css classes distorting the html displayed. task-4331146
This change makes an automated Web Studio test more stable by adding a short wait where timing could previously vary. It helps reduce false test failures, supporting smoother development and release validation without changing user-facing behavior.
Original PR description
Before this commit their was a little undeterminism in a tour. Adding a bit of delay within a step should do the trick. runbot-error-112182
Manufacturing order overviews now calculate expected BoM costs using the same work center timing factors as the BoM overview, including efficiency, setup, and cleanup time. This gives users a more reliable cost baseline to compare against actual production costs when parameters change during manufacturing.
Original PR description
Steps to reproduce the bug:
- Create a workcenter “WC1”:
- Cost by hour: 60
- Setup time: 10 min
- Cleanup time: 10 min
- Time Efficiency: 85
- Create a storable product “P1” with the following BoM:
- Operation: OP1 -> 60 min in WC1
- Create a MO to produce one unit of P1:
- Confirm the MO
- Go to the MO overview
Problem:
Time Efficiency, setup, and cleanup times are not taken into account in the BoM Cost calculation.
The calculation should be the same as in the BoM overview. The purpose of the BoM cost in the MO overview is to provide information for comparison with the real cost, in case the user has modified certain parameters during production.
opw-4478070This fixes an issue where users could not create SEPA Direct Debit payments after switching to a duplicated bank journal in the payment wizard. The selected journal is now kept when it is valid, preventing an incorrect validation error and allowing payment creation to continue.
Original PR description
Steps: - Duplicate the default bank journal and add a bank account - Create an invoice for a partner with valid mandate - Open the payment register wizard - Change journal from default one to the duplicated one - Select 'SEPA Direct Debit' as payment method - Click on 'Create payments' -> Validation Error: "The selected payment method is not available ..." Cause: In `action_create_payments`, the `journal_id` is recomputed when calling the `write` method on the wizard. Fix: Adding the `journal_id` in the write vals avoids it to be recomputed opw-4485191
This fixes a broken automated tour related to Knowledge article commands in read-only mode. The change helps keep quality checks reliable so issues in the Knowledge app can be caught before reaching users.
Code cleanup and technical improvements
The default waiting time between automated tour checks has been shortened, making test tours run faster while keeping their behavior reliable. This mainly benefits development and quality assurance by reducing feedback time for website and event-related checks.
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
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
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
To reproduce: ============= - create an event on calendar with description containing html - on calendar view, click on the event to open the popover and hover on the description field -> the tooltip is displayed with raw html content Fix: ==== hide the tooltip on html fields in calendar popover as it's not needed opw-4356581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194750 Forward-Port-Of: odoo/odoo#192104
Original PR description
To reproduce: ============= - create an event on calendar with description containing html - on calendar view, click on the event to open the popover and hover on the description field -> the tooltip is displayed with raw html content Fix: ==== hide the tooltip on html fields in calendar popover as it's not needed opw-4356581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194750 Forward-Port-Of: odoo/odoo#192104
**Problem**: When we have `<b t-field="html">`, it is rendered in the DOM as `<b data-oe-attr="..."><p>content</p></b>`. When this is converted to a string and parsed in the backend, the `html.fromstring` method removes the `p` from the `b` because `b` is an inline element and cannot contain block elements. This results in: `<b data-oe-attr="..."></b><p>content</p>`. Since this structure has two root elements, the parser wraps them in a block element (`div`), generating: `<div><b data
Original PR description
**Problem**: When we have `<b t-field="html">`, it is rendered in the DOM as `<b data-oe-attr="..."><p>content</p></b>`. When this is converted to a string and parsed in the backend, the `html.fromstring` method removes the `p` from the `b` because `b` is an inline element and cannot contain block elements. This results in: `<b data-oe-attr="..."></b><p>content</p>`. Since this structure has two root elements, the parser wraps them in a block element (`div`), generating: `<div><b data-oe-attr="..."></b><p>content</p></div>`. This causes a traceback when trying to access `data-oe` attributes, as they are expected to be in the root element. **Solution**: Convert any `b` elements used as HTML fields to `div` elements before saving. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194872
**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the signature UI being saved, missing the logic and props of the original component. 2. If the signature component is saved with other fields, it gets duplicated upon saving due to `<owl-component />` behavior. This re-renders every saved component and mounts those passed as props, c
Original PR description
**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the…
**Problem:** When editing the "Sign & Pay" modal in customer preview for a sale order, changes are not saved due to multiple issues: 1. Saving the signature component directly results in only the signature UI being saved, missing the logic and props of the original component. 2. If the signature component is saved with other fields, it gets duplicated upon saving due to `<owl-component />` behavior. This re-renders every saved component and mounts those passed as props, causing duplication and breaking functionality. - Reference: public_component_service.js **Solution:** 1. Hide the signature component during editing to prevent saving its UI-only state, preserving its logic and props. **Steps to Reproduce:** 1. Create a sale order. 2. Click on "Customer Preview." 3. Enable edit mode. 4. Open the "Sign & Pay" modal, modify the content, and save. - The signature UI duplicates **opw-4216372** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187707
…footer Before this commit, when in the report editor, trying to add a field in the footer, the main doc's fields were proposed. This was wrong because header and footer are generic views that can treat any record at once. They just set an internal variable for the company of the record, which should be the only available model to add fields from. After this commit, it is not possible to add fields from anything else than the "company" variable opw-4471868 Forward-Port-Of: odoo/ente
Original PR description
…footer Before this commit, when in the report editor, trying to add a field in the footer, the main doc's fields were proposed. This was wrong because header and footer are generic views that can treat any record at once. They just set an internal variable for the company of the record, which should be the only available model to add fields from. After this commit, it is not possible to add fields from anything else than the "company" variable opw-4471868 Forward-Port-Of: odoo/enterprise#77594 Forward-Port-Of: odoo/enterprise#77234
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 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#75900