Tuesday, February 18, 2025
26 changes
2 changes
Resolved issues and error corrections
This fix prevents plain text messages from being mistaken for HTML content, such as links or other rich message features. Users should see fewer incorrect highlights or message behaviors when searching and viewing messages in Discuss and mail-related areas.
Original PR description
When message content is not markup(), it will not render its content as HTML but as text when using t-out. This case was not taken into account when manually processing the content, leading to incorrectly detecting links or other features within purely text content. Those are now properly ignored.
Users can now add or remove columns in Accounting Report list views and see the change right away. This avoids the need for a manual page refresh, making report customization smoother and less confusing.
Original PR description
When toggling columns in any Accounting Report list view, it requires a manual refresh to see the changes. this is caused because this [commit](https://github.com/odoo/enterprise/pull/56589/commits/adc4bb7394cd7f25cffd15330fa699777bf2aac1) removed automatic reactivity, so we need to explicitly recompute the columns after updating `optionalActiveFields` Steps to reproduce: 0. Activate developer mode 1. Navigate to the 'Accounting Reports' menu in accounting. 2. Open a report (e.g. the balance sheet) 3. Use the column selector to add or remove additional columns OPW-4352833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
24 changes
Resolved issues and error corrections
This fixes a restaurant point of sale issue where adding a kitchen note and sending it still left the order button visible and the line marked as changed. Staff now get clearer order status after notes are sent to preparation screens, reducing confusion and duplicate actions.
Original PR description
Steps to Reproduce: - Open POS restaurant. - Select a table. - Order some food. - Return to the floor plan. - Select the same table again. - Add a kitchen note to a line. - Click Order. - The note update is correctly sent to the preparation display. The "order" button is still displayed and the line with the note is still marked as “changed”.
The point of sale customer display now automatically scrolls as new order items are added, so customers can see the latest products even when the list is longer than the screen. This fixes a restaurant POS display issue when using a separate customer-facing device.
Original PR description
Steps to reproduce: - Install pos_restaurant - In restaurant's configs, set 'Customer Display' to 'Another device' - Open the customer display in another tab, and start adding products from the main display -> The list of products on the customer display doesn't auto scroll when the products overlow the view. Explanation: The last `OrderLine` is supposed to be pass a `selected` prop, so it can be targeted from JavaScript and scrolled into the view [1]. However, this prop was removed in 1bc90a18807c43206c4620d7faad2579a3a61fc9. Now we add it back. [1]: https://github.com/odoo/odoo/blob/18.0/addons/point_of_sale/static/src/app/generic_components/order_widget/order_widget.js#L28-L30 opw-4458215
This fix allows non-administrator users to open the stock replenishment view without encountering an access error. It corrects a permission issue introduced by a prior change, helping inventory teams continue replenishment work normally.
Original PR description
odoo/odoo#192897 introduced a new bug when trying to access the replenishment view without administrator rights due to a call to `ir.config.parameter` method `get_param` without sudo rights. opw-4583651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes several automated website, point-of-sale, barcode, and eLearning test journeys more stable by improving how they wait for pages, animations, and interface elements. It reduces false test failures, helping teams validate changes with more confidence without changing normal customer-facing behavior.
Original PR description
Here is description of modifications for each tour: modified: addons/barcodes/static/src/barcode_handlers.js Use hoot event instead of custom event defined in macro.js to uniform code and behaviors.…
Here is description of modifications for each tour:
modified: addons/barcodes/static/src/barcode_handlers.js
Use hoot event instead of custom event defined in macro.js to
uniform code and behaviors.
modified: addons/l10n_br_website_sale/static/tests/tours/brazilian_address.js
Add a delay to wait the form is loaded to avoid problem with
_selectState(id) function.
modified: addons/point_of_sale/static/tests/tours/utils/chrome_util.js
Use waitFor in run of step because .fa-circle-o-notch should not
appears ... then of course body:not(:has(.fa-circle-o-notch)) also
not and then tour crashes.
modified: addons/pos_self_order/static/tests/tours/self_order_kiosk_tour.js
Because of the background animation, clicking on order now
may not do anything... so we'll click until we get to take out.
modified: addons/pos_self_order/tests/test_self_order_kiosk.py
Let's see comment of previous file ... We could need more time
for the tours.
modified: addons/test_website/static/tests/tours/restricted_editor.js
:contains(text) => Check that textContent.test(regex)
:has(class) => Check the element classList contains the class
modified: addons/website/static/tests/tours/html_editor.js
Additionnal steps to ensure tour take the good way.
modified: addons/website_slides/static/tests/tours/slides_tour_tools.js
Uniformize the behavior for two tours with clickOnAddTagDropdown
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-prFixes two issues in the HTML editor: deleting selected content no longer creates unwanted empty blocks, and the ChatGPT alternatives dialog no longer disrupts the user's text selection. This makes editing content more predictable and prevents accidental changes while the dialog is open.
Original PR description
In the following HTML: ```html <h1>[test</h1><p>content]</p>\n ``` The "\n" text node is invisible whitespace. When deleting the selection, failing to account for that, the content of the heading was…
In the following HTML: ```html <h1>[test</h1><p>content]</p>\n ``` The "\n" text node is invisible whitespace. When deleting the selection, failing to account for that, the content of the heading was "joined" with the invisible text node so that the heading's first child was that text node. This enventually snowballed when inserting new content as the start container was now a text node at offset 0, signalling to `insert` to do its insertion before its parent, and we ended up with an empty block after our insertion. This fixes it by correcting `getJoinableFragment` so it doesn't join with an invisible text node. ----- This prevents the default behavior of a mousedown event on the ChatGPT alternatives dialog so it doesn't cancel the user's text selection in the editor. This way, like with every other dialog, whenever it's open nothing can happen in the background. task-4258167 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale product searches now treat accented and unaccented text consistently. This helps cashiers find products with accented names more reliably, reducing checkout delays and missed search results.
Original PR description
Currently, if you have a product named "clémentines" and input "clémentine" in the search bar it will not be found. Steps to reproduce: ------------------- * Create a product sold in POS named clémentine * Open a shop which does not restrict categories * Input in the search bar "clémentine" > Observation: No product for "clémentine" Why the fix: ------------ The product `searchString` is `unaccent` and `toLowerCase` while the searchWord is only `toLowerCase`. https://github.com/odoo/odoo/blob/f82f768729d897fa54b04789f4e0637ed1bb27f4/addons/point_of_sale/static/src/app/screens/product_screen/product_screen.js#L397-L397 opw-4558898
This fixes an automated website setup check that could fail depending on which website apps were installed. The tour now only opens the link editor when needed, making website testing more reliable without changing customer-facing behavior.
Original PR description
The following PR: https://github.com/odoo/odoo/pull/190321 introduced a new website tour. However, one of the step make the tour consistently fail with a single app website install. The reason for the fail is that the "edit link" sub-window is opened by default if the link is not open through the "extra menu". Clicking the button (what currently do the test) do close the sub-window making the input not clickable in the following step.  *single-app website build screenshot* the URL input is open by default *multi-app build screenshot* the URL input is not shown by default as the mega-menu menu-item is shown in the "extra menu" due to the amount of menu added by other website related app After this PR: The "edit link" button is pressed only if the input is not visible rb-111286
The manufacturing BoM overview no longer crashes when viewing products that use dynamically created variants. If a specific product variant does not yet exist, variant-specific operation details are safely skipped so users can still access the overview.
Original PR description
Steps to reproduce the bug: - Ceate a product - add a new attribute with "variant creation mode" = "Dynamic" - create a BoM for this product - make sure to add an operation in the operational lines…
Steps to reproduce the bug: - Ceate a product - add a new attribute with "variant creation mode" = "Dynamic" - create a BoM for this product - make sure to add an operation in the operational lines of the bom - Click on the BoM smart button then BoM overview smart button Problem: Traceback is raise, because in the BoM overview it creates a BoM report, and it adds the operational lines(operations) to the report, some operations are skipped based on the function `_match_all_variant_values` that checks if the product has all the variant values. This function expects a product to run on, but in case of dynamic attribute a product will only be created if it is included in a sales order, hence the product is empty and the function raise the exception. Since the BoM report is for the product variants, then we can skip the operational line if no product is used in the BoM, and hence the `_match_all_variant_values` won't be called over empty product. opw-4518723 **Possible approaches for the Issue**: 1- Change the product variable in the bom object in the _get_bom_data function to be the product.template instead of the concrete product, this will affect many other functions in the generating of the bom report as **_get_resupply_route_info** function that calls **_get_rules_from_location** which is not a function on the 'product.template' model. Considering that approach requires anticipating the case of having the product.template in the bom in all the sections in the bom report. 2- Keep the porduct in the bom object empty one since we don't have with dynamic attributes. And we just skip operational lines if the porduct is empty so the **_match_all_variant_values** is not called. [**IMPLEMENTED**] (This change doesn't require more changes as everything will be still working with the expected model type 'product.product' but the operations and other data will be empty in the report which make sense because they are variant related ) Current behavior before PR: the app show error whenever a BoM overview smart button is clicked for a BoM of a product with dynamic attribute variants Desired behavior after PR is merged: The BoM overview report should be shown normally with no problems. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the mobile call screen so the push-to-talk button keeps the correct size instead of expanding over the call view. Mobile users can now access call controls without the interface being blocked by an oversized button.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/189657, the mobile push-to-talk button was also affected by the aspect ratio affecting all buttons of the call action list. This was making the button too big and covering the whole call view. This commit fixes this issue by introducing a dedicated selector for the bar part of the call action list. before:  after: 
Chat bubbles in spreadsheets now stay fully visible when the filters panel is hidden. This prevents conversations from being partially covered by the spreadsheet scrollbar, making chat easier to use while working in spreadsheets.
Original PR description
Before this commit, when using spreadsheet with some chat bubbles, the chat bubbles were cut with horizontal scrollbar of spreadsheet. Steps to reproduce: - make a spreadsheet - put a chat in chat…
Before this commit, when using spreadsheet with some chat bubbles, the chat bubbles were cut with horizontal scrollbar of spreadsheet. Steps to reproduce: - make a spreadsheet - put a chat in chat bubble (e.g. from click on messaging menu) - remove the "filters" panel of the spreadsheet This happens because the horizontal scrollbar of spreadsheet uses a `z-index: 15` while chat bubble uses `z-index: 10`. The `z-index` of chat bubble is relative to navigable list, and since the value was exactly slightly offset from navigable list, this commit fixes by shifting the `$o-mail-NavigableList-zIndex`. It was `11`, now it's `21`. As a result, the chat bubble `z-index` is being changed from `10` to `20`, which is greater to `15` from spreadsheet horizontal scrollbar. Task-4547672 Before / After <img width="106" alt="Screenshot 2025-02-17 at 17 10 28" src="https://github.com/user-attachments/assets/caf3d9f8-59d4-4b2b-9981-d2e5ed68a510" /> <img width="97" alt="Screenshot 2025-02-17 at 17 11 14" src="https://github.com/user-attachments/assets/1c9376bc-ca24-42dd-8864-eee0878fc1c7" />
This fix ensures portal chatter components wait until all required background services are ready, including when parts of the page are loaded later. It reduces the chance of unpredictable loading behavior or broken chatter interactions for portal users.
Original PR description
When loading portal chatter, because the chatter bundle is lazy loading, it could happen that some components are added to the main_components registry while the services are not fully updated. In non-lazy loading scenarios, this doesn't happen because before lunching the main components, the code waits for all services to start, but with lazy loading, the services update happens again with the lazily loaded bundle, and if there are some main components in that bundle, they will be added to the MainComponentsContainer regardless of the updating services. As a result, this could lead to a main component being added randomly before or after the services are loaded. This commit, by postponing the lunching of the MainComponentsContainer until after the lazy loading is complete, ensures that if there are other lazily loaded services, the main components will wait for them to be updated.
Simplified invoices sent to TicketBAI now leave out recipient details when the customer does not have a VAT/NIF number. This prevents validation failures and helps Spanish companies submit these invoices successfully.
Original PR description
Since Odoo 18.0, the recipient is always included when sending a simplified invoice. While this is allowed by TicketBAI, it is only valid if the partner has a VAT number (NIF). Steps to reproduce: Install the l10n_es_edi_tbai module and setup an ES company Create a simplified invoice with the partner "Simplified Invoice Partner (ES)" Send the invoice to TicketBAI The following error will be returned: "B4_1000002: Todos los registros incluidos en la petición son incorrectos." The Fix: For simplified invoices, this fix ensures that the recipient is only included in the XML if the partner has a VAT/NIF. If not, the recipient is omitted to avoid TicketBAI validation errors. Ticket [link 1](https://www.odoo.com/odoo/project/967/tasks/4525875), [link 2](https://www.odoo.com/odoo/project/967/tasks/4522938), [link 3](https://www.odoo.com/odoo/project/967/tasks/4553030) opw-4525875 opw-4522938 opw-4553030
Accounting settings now block invalid fiscal year dates, such as February 29 in non-leap years. This prevents invoice creation from failing later with a confusing system error and gives users clear feedback when configuring fiscal periods.
Original PR description
Currently, An error occurs when attempting to create an invoice, and the user entered an invalid date in the `Fiscal Periods` of the accounting settings. Step to produce: - Install the `accountant`…
Currently, An error occurs when attempting to create an invoice, and the user entered an invalid date in the `Fiscal Periods` of the accounting settings. Step to produce: - Install the `accountant` module (without demo data). - Go to Settings / Technical / Sequences & Identifiers / Sequences, And delete all records. - Go to Accounting settings, Set the month to February and the day to 29 in the `Fiscal Periods` section, - Go to Invoicing / Customers / Invoices, Try to create a new invoice. `ValueError: day is out of range for month` The issue occurs because the system attempts to get a 29th February at [1], But 29th February is not available in all years(e.g '2025'). Link [1]: https://github.com/odoo/odoo/blob/0f507a8982a29bf1c35aaf9f8f97fc3d5381226c/addons/account/models/account_move.py#L3487 To resolve this, raise a validation error if the user enters an invalid date in the `Fiscal Year` of the accounting settings. Sentry-6190026432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Point of Sale product search has been updated to match the newer search behavior after fuzzy search was removed. Users should now see all relevant product results instead of being limited to only exact matches, making it easier to find items during checkout.
Original PR description
Since the fuzzy search has been removed, it is no longer necessary to exclusively display only exact match results. This commit updates the search functionality to adopt and return all relevant search results, ensuring consistency with the new behavior. opw-4535250 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a French accounting setup issue caused by a module split in Odoo 18. The change ensures existing tax tags are preserved using the correct French accounting module, helping avoid configuration inconsistencies during updates.
Original PR description
I found this bug while reading the code of l10n_fr_account. In v18, the module l10n_fr was split between l10n_fr and l10n_fr_account. When calling preserve_existing_tags_on_taxes(), we need to pass the module name l10n_fr_account because account.account.tag are now defined in l10n_fr_account, cf https://github.com/odoo/odoo/blob/18.0/addons/l10n_fr_account/data/account_chart_template_data.xml#L3 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
In https://github.com/odoo/odoo/commit/b42c99abd362c15e86f6a745399979dd3236b75a, we changed the xml_id but we forgot to change that in the pot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
In https://github.com/odoo/odoo/commit/b42c99abd362c15e86f6a745399979dd3236b75a, we changed the xml_id but we forgot to change that in the pot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where exporting selected records could fail after using the “select all” option in list views. This makes export actions more reliable, including inventory stock reporting exports.
Original PR description
The domain was incorrectly initialized in the `getExportedFields` method after this commit https://github.com/odoo/odoo/pull/174366/files#diff-a3a01eded3e54743e243ef83e4c7dc682ddc91630015fa1f986e20346e7b84caR521-R530. The domain now defaults to an empty array (`[]`) when `parentParams` is undefined, preventing unexpected errors during export operations. This ensures consistent handling of record selection and domain construction. Steps to reproduce Go to Inventory / Reporting / Stock Change the number of records displayed to be less than the total When you try to select all in the list view it shows the select all button. Click it. Actions / Export / Stock Quant Open this there is a video that explain in the [ticket](https://www.odoo.com/odoo/project.task/4333244) opw-4333244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures formatted comments in restaurant booking views display as intended in Point of Sale. It adds the required editor support so staff can read rich text notes properly during booking workflows.
Original PR description
Before this commit comment field in calendar_event_view_form_gantt_booking used in pos restaurant does not display properly html field. Fixed by importing the html editor to the point_of_sale manifest. task-4547369 https://github.com/odoo/enterprise/pull/78536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several issues in the WinBooks import process so accounting data imports more accurately and with fewer manual corrections. It improves handling of draft entries, missing accounts, and analytic accounting details, including using the correct analytic plan names and enabling analytic features when needed.
Original PR description
Details in various commits
The version history panel no longer offers a redundant rename menu action that could trigger an error. Users can still rename a spreadsheet version directly by clicking the editable name, making the experience simpler and more reliable.
Original PR description
Clicking 'Name this version' in the version history panel causes a traceback because the `el` of TextInput is not found. We have two possible solutions: 1. Forward the refs of TextInput and VersionHistoryItem explicitly using `useChildRef` and `useForwardRefToParent`, or use a callback to retrieve the ref for focusing the input. 2. Remove the menu item, as the cursor already changes to a text pointer on hover, indicating the name is editable. I think the second approach is better since it is simpler and more intuitive. Task: 4563422
Accounting settings now reject invalid fiscal year dates, such as February 29 when it would cause errors in non-leap years. This prevents users from encountering an invoice creation failure caused by an unsupported fiscal period configuration.
Original PR description
Currently, An error occurs when attempting to create an invoice, and the user entered an invalid date in the 'Fiscal Periods' of the accounting settings. Step to produce: - Install the `accountant` module (without demo data). - Go to Accounting settings, Set the month to February and the day to 29 in the Fiscal Periods section, - Go to Invoicing / Customers / Invoices, Try to create a new invoice. `ValueError: day is out of range for month` The issue occurs because the system attempts to get a 29th February at [1], But 29th February is not available in all years(e.g '2025'). Link [1]: https://github.com/odoo/odoo/blob/0f507a8982a29bf1c35aaf9f8f97fc3d5381226c/addons/account/models/account_move.py#L3487 To resolve this, raise a validation error if the user enters an invalid date in 'Fiscal Year' to ensure that users cannot enter an invalid date. Sentry-6190026432
Creating a share link from an appointment type no longer clears the user’s current filters. This keeps users in their existing view and avoids unnecessary reloading while managing appointment sharing.
Original PR description
Steps to reproduce ================== - Got to appointment type; - Apply some filter. - Now create a share link. - Filter is lost. Technical =========== https://github.com/odoo/enterprise/pull/63046/commits/492296e91e9c0b1106a7bc6852010be426d2abe8 Here we are loading the action while creating or updating the share link to reflect the changes without refreshing. It is not required when we create a share link from other places instead of a Share link menu. After this commit ================== This commit addresses the issue and now the filter will not lost when we create a share link from appointment_type. Task-4138356
When a Mexican electronic payment document is canceled, Odoo now also cancels the linked payment record. This prevents payments from incorrectly remaining posted after the official CFDI cancellation process.
Original PR description
Since Odoo 18.0, account.payment no longer inherits from account.move. As a result, canceling a payment with `_l10n_mx_edi_cfdi_move_post_cancel` does not automatically cancel the associated payment record. Steps to reproduce: 1. Ensure the Mexican localization is installed and properly configured. 2. Generate an invoice and sign it with the government (CFDI). 3. Create and sign a payment for the invoice. 4. Cancel the payment from the CFDI table. Current behavior: - Odoo cancels the move, but the related payment remains posted. Expected behavior: - The payment should also be canceled when the move is canceled. This fix ensures that the associated payment is canceled correctly. opw-4528910
Batch picking screens now show tracked product lines grouped correctly, making warehouse operations easier to review and process. This fixes a display issue that could make batch picking confusing when lot or serial tracked items were involved.
Original PR description
opw-4291149