Tuesday, October 31, 2023
38 changes · 17.0
Enhancements to existing features
Odoo now stores model inheritance information directly in the database instead of relying on a prebuilt list during upgrades. This makes upgrades easier to maintain and better supports databases with custom or non-standard modules.
Original PR description
This will help the upgrade process. Currently, there is an harcoded[^1] inherit tree stored in the upgrade source. By storing this information in the databases, we: - avoid this hardcoded list. - support more than the standard modules. task-3504720 [^1]: hardcoded, but autogenerated. 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
Printer issues in self-order kiosks are now hidden from customers during order confirmation. This keeps the kiosk experience smoother when operational problems occur, such as a printer running out of paper.
Original PR description
In this commit we hide the printing errors in `pos_self_order`. At the moment, they are show to the user, but that is not desirable behavior in a kiosk environment. Such printing errors might, for example, be encountered when the printer is out of paper. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The subscription log generation code has been cleaned up and reorganized for better readability. Additionally, the system now correctly prevents free subscriptions (negative amounts) from creating unnecessary log records, reducing clutter in the system.
Original PR description
Clean the so.log generation code to be more readable. The code is also moved to the sale_order_log model.
The category filter in the POS preparation display is now hidden by default, simplifying the user interface for kitchen staff. This improvement reduces visual clutter and streamlines the preparation workflow by removing an optional filter that most users don't need to access regularly.
Original PR description
Hides preparation display category filter by default. task-id: 3572362
This update improves how data validation works in the Documents Spreadsheet module by moving from a post-installation test to an automatic constraint. This ensures data integrity is checked continuously rather than just during setup, making the system more reliable and maintainable.
Original PR description
See community PR. The validation is now done with an `api.constrains` instead of a post-install test. Task: 3577092
Resolved issues and error corrections
The stock picking screen no longer shows advanced forecast information by default. This keeps the view simpler for everyday warehouse users while still preserving the underlying functionality for cases where it is needed.
Original PR description
It adds advanced data on the picking view. It's not needed by default so we hide it 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
Steps to reproduce: - Configure a payment provider (e.g. Stripe) - Go to the portal account of an user (e.g. Marc Demo) - Click on "Manage payment methods" - Save a payment method to create a payment token - /!\ Go back to payment provider configuration and make a typo in the credentials (This will be needed later to trigger a payment transaction error) - Go to Accounting and create an invoice for Marc Demo - Confirm the invoice - Register payment: * Payment Method: Stripe * Saved
Original PR description
Steps to reproduce: - Configure a payment provider (e.g. Stripe) - Go to the portal account of an user (e.g. Marc Demo) - Click on "Manage payment methods" - Save a payment method to create a payment…
Steps to reproduce: - Configure a payment provider (e.g. Stripe) - Go to the portal account of an user (e.g. Marc Demo) - Click on "Manage payment methods" - Save a payment method to create a payment token - /!\ Go back to payment provider configuration and make a typo in the credentials (This will be needed later to trigger a payment transaction error) - Go to Accounting and create an invoice for Marc Demo - Confirm the invoice - Register payment: * Payment Method: Stripe * Saved payment token: [payment token of Marc Demo] - Create payment [1st issue] The payment transaction fails (as the credentials are incorrect), but no information about it appears on the invoice. [2nd issue] It is not possible to register another payment (with the payment provider) because there is an unique constraint on the reference field of "payment.transaction" model and each attempt of registering a payment uses the same reference. Solution: [1st issue] Link invoice to payment transaction. Messages related to payment transaction will be logged on the invoice automatically. [2nd issue] Generate reference with "_compute_reference" method instead of always using the same one. opw-3499200 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139982 Forward-Port-Of: odoo/odoo#139700
This update exports and refreshes the source translation terms across 20+ Odoo modules. This ensures that all user-facing text in the system is properly prepared for translation into different languages, maintaining consistency and completeness of the translation framework.
Opening a discussion channel that no longer exists now fails gracefully instead of causing an error. This helps users stay in the messaging area without disruption when links or channel data are outdated.
This fix restores proper formatting for error messages shown when sending electronic invoices. Users now see readable errors both in pop-up alerts and in the document chatter, reducing confusion during invoice processing.
Original PR description
…sage formatting With https://github.com/odoo/odoo/pull/139311, we broke the formatting of errors. We need to handle two formats: - one for the raised Error, likely formatted with \n - one for the chatter, likely formatted with html ### Before the fix  ### After the fix  
The Put In Pack button on stock picking forms is now shown on the right and uses a secondary visual style. This makes the action less visually dominant while keeping it available in a more appropriate place for warehouse users.
Original PR description
Main changes:
Change the style and postion of the Put In Pack Button on the stock.picking form view
Before:
Button is aligned on the left and has the style primary
After:
Button is aligned on the right and has the style secondary
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prManufacturing order lists now hide duration fields that are not needed by default, reducing visual clutter for users. The bill of materials overview also hides component availability unless opened from the manufacturing forecast, so teams see that detail only where it is most relevant.
Original PR description
This commit fixes: - hide `read_duration` and `expected_duration` in MO list view. - hide `component availability` byt default in bom overview, unless if coming from mrp forecast. task-3547356 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 fixes a small visual issue where disabled arrow-shaped buttons appeared darker when hovered. Users now see a more consistent disabled state, reducing visual confusion in the interface.
Original PR description
This commit fixes an issue where the interior of the arrow of the disabled `o_arrow_button` was darker on hover task-3573542 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where images from the Images Wall could keep a hover overlay when opened in the slideshow. This keeps website image galleries looking clean and consistent for visitors after editing.
Original PR description
Steps to reproduce the bug: - In Website edit mode, drag and drop an `Images Wall` snippet onto the page. - Click on the first image of this snippet. - In the "Animation" options of the image, select "On Hover". - Save the page. - Click on the first image of the `Images Wall` snippet. - Bug: The image in the slideshow still has the overlay that appeared due to the hover effect. This commit fixes this issue by resetting images to their original source in the slideshow. task-3562305
This update corrects how formatted content is combined in mass mailing lists, preserving the intended markup instead of accidentally stripping it. It helps ensure mailing-related content is rendered consistently without changing user workflows.
Original PR description
- using a string to join `Markup`s is useless, that just strips out the `Markup` - the entire toplevel `Markup` can be formatted in one shot
Payment summaries with long text now wrap properly and use adjusted sizing to avoid layout problems. This helps customers and portal users read payment information clearly without broken or overflowing page content.
Original PR description
Prior to this commit, the content of the payment summary did not include line breaks when the text was too long, creating layout issue. To fix that, this commit adapts the font size and forces the text to break. task-3576830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds test coverage to ensure invalid pivot spreadsheet expressions are detected correctly. It helps reduce the risk of spreadsheet errors reaching users by guarding against a previously discussed edge case.
Original PR description
See https://github.com/odoo/odoo/pull/139871#discussion_r1377199846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Barcode scans for valid command-style actions no longer show an unnecessary warning when another module handles the action. This avoids confusing users who successfully scan operational barcodes, such as stock menu shortcuts, but previously still saw an alert.
Original PR description
Before this commit, when a barcode starting with "O-CMD." is scanned, the barcode handler checks if it knows a command and either calls it if it exists, either displays a notification. The issue with the notification is that some modules can use barcodes starting with "O-CMD." (`stock_barcode` with "O-CMD.MAIN-MENU" for example), meaning scanning one of those will display a warning notification even if the action linked to the barcode is correctly called. Since there is no notification in case a scanned "O-BTN." does nothing, it seems not so crazy to make the CMD part to not display a notification in case there is no command for the scanned barcode.
Removing all social links from the website header no longer triggers an error. This keeps website editing stable when businesses choose not to display social media links.
Original PR description
Prior to this commit, when you removed all social links in the header, there was an error. This is because `website.header_social_links_no_color` targets selectors that don't exist in this situation. This commit adapts this template so that it works even if we remove all social links. task-3572219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The checkout page now works even when no payment provider supports express checkout. This prevents customers from seeing a broken checkout form in stores where express checkout is unavailable or not configured.
Original PR description
The express checkout form template could not be rendered when no payment provider supporting express checkout was passed.
This update fixes a bug where the return button was incorrectly appearing in the barcode scanning interface in two situations: when viewing picking details and when processing completed manufacturing orders. The button now only displays when it should be available, improving the user experience and reducing confusion.
Original PR description
Fixes 2 cases of the return button in barcode showing when it shouldn't. - when in the "info" view of the picking then the button was showing on top of the chatter when it shouldn't show in this view at all - in done manufacturing orders Note that a getter isn't added to the JS to handle whether or not the button should be shown because mrp_model extends the picking_model and batch pickings do not currently offer the "Return" option in the backend, so it didn't seem necessary to create a getter to only override it to be "False" for mrp_model only. Forward-Port-Of: odoo/enterprise#49824
This fix eliminates false warning notifications that appeared when scanning certain barcodes used by the stock barcode system. Previously, valid barcode commands were triggering warning messages even though they were working correctly. The update ensures that recognized barcode commands no longer display unnecessary alerts to users.
Original PR description
Before this commit, when a barcode starting with "O-CMD." is scanned, the barcode handler checks if it knows a command and either calls it if it exists, either displays a notification if not. The issue with the notification is that some modules can use barcodes starting with "O-CMD." (`stock_barcode` with "O-CMD.MAIN-MENU" for example), meaning scanning one of those will display a warning notification even if the action linked to the barcode is correctly called. This commit adds an empty function for each "O-CMD." barcode used by `stock_barcode` to let `barcodeGenericHandlers` know those commands exist and should not trigger a warning.
A traceback is generated if config currencies are none. This is because we are trying to access the 0 index which does not exist in a None object. Steps to reproduce: 1. Go to studio. 2. Click on reports. 3. Search for sale details. 4. Click on sale details report. Current Behavior: As we click on the sales details report, a traceback pops up. Expected Behavior: There should be no traceback and the report editor should open smoothly if nothing wrong. Note: We also remove Timez
Original PR description
A traceback is generated if config currencies are none. This is because we are trying to access the 0 index which does not exist in a None object. Steps to reproduce: 1. Go to studio. 2. Click on reports. 3. Search for sale details. 4. Click on sale details report. Current Behavior: As we click on the sales details report, a traceback pops up. Expected Behavior: There should be no traceback and the report editor should open smoothly if nothing wrong. Note: We also remove Timezone information from the start_date to match the format of the date when it's provided by the user. e.g. : "23/05/2024 08:25:34" instead of "23/05/2024 08:25:34 TZInfo" OPW-3501650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140477 Forward-Port-Of: odoo/odoo#139574
No description available.
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140407
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140407
`''.join` would strip the `Markup` out, so the markup would appear literally in the result instead of being interpreted as HTML. Also switch to using dict-style formatting, it's a touch clearer (and shorter) for this case, since `e` is already a dict (hopefully). Forward-Port-Of: odoo/odoo#140427
Original PR description
`''.join` would strip the `Markup` out, so the markup would appear literally in the result instead of being interpreted as HTML. Also switch to using dict-style formatting, it's a touch clearer (and shorter) for this case, since `e` is already a dict (hopefully). Forward-Port-Of: odoo/odoo#140427
Currently, although the journals are filtered to only show purchase journals, there is no constraint preventing users from creating a new journal of any other type. This commit adds a constraint. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140344
Original PR description
Currently, although the journals are filtered to only show purchase journals, there is no constraint preventing users from creating a new journal of any other type. This commit adds a constraint. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140344
Steps to reproduce: 1. Install Inventory app. 2. Enable "Storage Locations" in Inventory settings. 3. Create a new product known as "X". Set it's tracking to "By Unique Serial Number". 4. In Inventory -> Configuration -> Operation Types -> Receipts, set "Use Existing Ones" to true. 5. Create a new Receipt, add a new line of product X. 6. In the "Details" page of the X line, click "Import Serials/Lots". 7. Enter at least two lines of two serial numbers and import. Bug: Notice that the
Original PR description
Steps to reproduce: 1. Install Inventory app. 2. Enable "Storage Locations" in Inventory settings. 3. Create a new product known as "X". Set it's tracking to "By Unique Serial Number". 4. In…
Steps to reproduce: 1. Install Inventory app. 2. Enable "Storage Locations" in Inventory settings. 3. Create a new product known as "X". Set it's tracking to "By Unique Serial Number". 4. In Inventory -> Configuration -> Operation Types -> Receipts, set "Use Existing Ones" to true. 5. Create a new Receipt, add a new line of product X. 6. In the "Details" page of the X line, click "Import Serials/Lots". 7. Enter at least two lines of two serial numbers and import. Bug: Notice that the "Lot/Serial Number" column on each row are blank. This is happening because the view used for stock move lines here will display either the lot_id field of a sml, or the lot_name field, based on varying conditions. In this case, setting "Use Existing Ones" to true will cause the lot_id field to be displayed (and the lot_name field to be invisible). When importing lots, only the lot_name is set with the user's input but the lot_id is left blank. So because lot_id is empty, the column is empty. But this works as expected when "Use Existing Ones" is false because it displays the correctly set lot_name. When the receipt is validated, the lot is created and lot_id for each of the smls is set, so now it displays properly. Fix: when "Use Existing Ones" is set first check if lot exists and set it in that case, otherwise create and set a new lot at that moment opw-3498812 Forward-Port-Of: odoo/odoo#139247
Before this commit, the "OdooBot has a request" notification in the Messaging Menu -- which suggest to enable push notifications -- had a muted style, which looks as if the item is unimportant and was read by the current user. This is an important notification, at an equivalent level of importance than needaction notifications. This was already highlighted by this item contributing to the global Messaging Menu counter. This is an important notification, at an equivalent level of importance
Original PR description
Before this commit, the "OdooBot has a request" notification in the Messaging Menu -- which suggest to enable push notifications -- had a muted style, which looks as if the item is unimportant and…
Before this commit, the "OdooBot has a request" notification in the Messaging Menu -- which suggest to enable push notifications -- had a muted style, which looks as if the item is unimportant and was read by the current user. This is an important notification, at an equivalent level of importance than needaction notifications. This was already highlighted by this item contributing to the global Messaging Menu counter. This is an important notification, at an equivalent level of importance than needaction notifications. This was already highlighted by this item contributing to the global Messaging Menu counter. This commit fixes the issue by not muting this notification. To do so, it enhances prop `muted` on `NotificationItem` component: - 0 (default): the notif is unmuted - 1: the notif is slightly muted - 2: the notif is hard-muted 0/1 are equivalent to the different muted style of notification in 16.4, while `muted: 2` shows a hard-muted notification when the user choose to manually mute a channel, as to not receive any notification from it. Some logic related to "mark as read"/"counter" logic has been moved to this muted prop concern, as not all notification that have mark as read or a counter necessarily must be muted, e.g. with "OdooBot has a request". Task-3566799 Before  After  Forward-Port-Of: odoo/odoo#140326
**Current behavior before PR:** Channel was not getting unpinned after being deleted. **Desired behavior after PR is merged:** Channel gets unpinned for all the channel members after being deleted. Task-2814440 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137624 Forward-Port-Of: odoo/odoo#107001
Original PR description
**Current behavior before PR:** Channel was not getting unpinned after being deleted. **Desired behavior after PR is merged:** Channel gets unpinned for all the channel members after being deleted. Task-2814440 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#137624 Forward-Port-Of: odoo/odoo#107001
Steps: - Install `website_sale` - Enable `On-site payment & picking` - Set 200$ for on-site picking fees - Go to /shop - Put a product in the cart and go to checkout If you click in the element box containing on-site picking it will compute the delivery fees, but if you select it with the radio button it will not. Forward-Port-Of: odoo/odoo#139562
Original PR description
Steps: - Install `website_sale` - Enable `On-site payment & picking` - Set 200$ for on-site picking fees - Go to /shop - Put a product in the cart and go to checkout If you click in the element box containing on-site picking it will compute the delivery fees, but if you select it with the radio button it will not. Forward-Port-Of: odoo/odoo#139562
The live chat relies on `session.origin` to send its requests to the server when its embed in an external page. `web.base.url` is only set when a user authenticates and is wrong when no user connected yet. This results in a crash when opening the website with live chat enabled on a fresh instance of odoo. This commit removes the use of `session.origin` in the frontend code since it is useless anyway. Steps to reproduce: - Create a new odoo database with website_livechat installed - Go to th
Original PR description
The live chat relies on `session.origin` to send its requests to the server when its embed in an external page. `web.base.url` is only set when a user authenticates and is wrong when no user connected yet. This results in a crash when opening the website with live chat enabled on a fresh instance of odoo. This commit removes the use of `session.origin` in the frontend code since it is useless anyway. Steps to reproduce: - Create a new odoo database with website_livechat installed - Go to the log in page - A crash occurs Forward-Port-Of: odoo/odoo#140077
In views with a searchbar, we want the filters to be displayed directly when they are activated, without waiting for the view to be reloaded. This is to provide a direct feedback to the user. Before this commit, this didn't work in grouped kanban view with progressbar. The regression has been introduced by [1] which moves the progressbar logic out of the model. With [1], the rendering of the KanbanController waits for the progressbar data to be loaded in onWillUpdateProps, thus delaying the r
Original PR description
In views with a searchbar, we want the filters to be displayed directly when they are activated, without waiting for the view to be reloaded. This is to provide a direct feedback to the user. Before…
In views with a searchbar, we want the filters to be displayed directly when they are activated, without waiting for the view to be reloaded. This is to provide a direct feedback to the user. Before this commit, this didn't work in grouped kanban view with progressbar. The regression has been introduced by [1] which moves the progressbar logic out of the model. With [1], the rendering of the KanbanController waits for the progressbar data to be loaded in onWillUpdateProps, thus delaying the rendering coming from the WithSearch when a filter is toggled. This commit applies the same logic as for the model: we do not wait for the loading promise in onWillUpdateProps. That way, the rendering coming from WithSearch is synchronous, but a reload is initiated and another rendering will be scheduled by the Controller itself when the data will be loaded. This commit also adds a test for the model case, as it appears that this wasn't tested. [1] 58ca40b03215ef4c6c575267494dc8bccc30a033 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#139446 Forward-Port-Of: odoo/odoo#139425
Before this PR, newly created direct message would be added at the bottom of the list instead of the top. This PR fix the issues by sorting the direct messages when creating a new direct message channel. Task-3566728 Forward-Port-Of: odoo/odoo#139769 Forward-Port-Of: odoo/odoo#139704
Original PR description
Before this PR, newly created direct message would be added at the bottom of the list instead of the top. This PR fix the issues by sorting the direct messages when creating a new direct message channel. Task-3566728 Forward-Port-Of: odoo/odoo#139769 Forward-Port-Of: odoo/odoo#139704
The leading slash of the font awesome URL is missing in the live chat module. This results in an incorrect link so font awesome is not correctly loaded. This commit fixes this issue. Forward-Port-Of: odoo/odoo#140424
Original PR description
The leading slash of the font awesome URL is missing in the live chat module. This results in an incorrect link so font awesome is not correctly loaded. This commit fixes this issue. Forward-Port-Of: odoo/odoo#140424
Cleanup of commit d65e03a867d0adb3bc23f9503191cc13bf992e4a Forward-Port-Of: odoo/odoo#139565
Original PR description
Cleanup of commit d65e03a867d0adb3bc23f9503191cc13bf992e4a Forward-Port-Of: odoo/odoo#139565
## [IMP] sale_project: Include Archived Project in stat-button related views. ### [Context] Sales Order can be connected to projects. Before this commit archived projects were counted in the stat-button, but not in the related to stat-button project kanban view. We want to show archived (i.e. "non active") projects in both. ### [Reproduce behaviour before this commit]: - run odoo 15 with: sale_management,project,timesheet_grid - In Project, create: - project A - project B - In S
Original PR description
## [IMP] sale_project: Include Archived Project in stat-button related views. ### [Context] Sales Order can be connected to projects. Before this commit archived projects were counted in the…
## [IMP] sale_project: Include Archived Project in stat-button related views. ### [Context] Sales Order can be connected to projects. Before this commit archived projects were counted in the stat-button, but not in the related to stat-button project kanban view. We want to show archived (i.e. "non active") projects in both. ### [Reproduce behaviour before this commit]: - run odoo 15 with: sale_management,project,timesheet_grid - In Project, create: - project A - project B - In Sales/Products/Products, create: - product A (set: type="Service", Create on Order="Task", project="project A") - product B (set: type="Service", Create on Order="Task", project="project B") - In Salse/Orders/Quotations: - Create Quotation - add "product A" and "product B" - save & Confirm - OBSERVE: stat-button "projects" shows 2 projects - Click on: stat-button "projects" - OBSERVE: kanban view shows 2 projects - Archive one of project - go Project/"Project A"/Edit/Action/Archive (require debug mode) - Go back to created Quotation - OBSERVE (Desired): stat-button "projects" shows 2 projects - Click on: stat-button "projects" and OBSERVE - OBSERVE (Not-Desired): kanban view shows 1 projects (it excluded archived one) ### [Fix] Modified domain in the function/action related to the stat-button. opw-3500711 ## Some More context Originally this PR was supposed to exclude archived projects from count in the stat-button. Initial PR description below for context. > ## [FIX] sale_project: Archived Project Shall Not Be Counted In Smart Button > > ### [Context] > Archived Projects shouldn't be counted. If you associated 2 projects with some Sales Order and one project got archived, magic button counter (located on sale order form view) should get decreased to show only active projects. > > ### [To Reproduce]: > - run odoo 15 with: sale_management,project,timesheet_grid > - In Project, create: > - project A > - project B > - In Sales/Products/Products, create: > - product A (set: type="Service", Create on Order="Task", project="project A") > - product B (set: type="Service", Create on Order="Task", project="project B") > - In Salse/Orders/Quotations: > - Create Quotation > - add "product A" and "product B" > - save & Confirm > - OBSERVE: magic-button "projects" shows 2 projects > - Archive one project > - go Project/"Project A"/Edit/Action/Archive (require debug mode) > - Go back to created Quotation > - OBSERVE BUG: magic-button "projects" shows 2 projects (still) > > ### [Fix] > I'm performing additional filtering to explude archived (not active) projects. > > opw-3500711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#140018 Forward-Port-Of: odoo/odoo#138074
Current behavior before PR: On creating link in debug mode produces prop validation error, and link dialog doesn't appear Desired behavior after PR is merged: Now the issue is resolved and link dialog appears. task-3571940 Forward-Port-Of: odoo/odoo#139851
Original PR description
Current behavior before PR: On creating link in debug mode produces prop validation error, and link dialog doesn't appear Desired behavior after PR is merged: Now the issue is resolved and link dialog appears. task-3571940 Forward-Port-Of: odoo/odoo#139851