Tuesday, January 28, 2025
15 changes · 18.0
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
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
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
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
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
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.
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