Monday, May 12, 2025
6 changes · saas-18.3
Resolved issues and error corrections
The live chat sample data now uses the same timing information that reports rely on. This prevents demo dashboards from showing unrealistic chat durations or response times, making demonstrations and evaluations more trustworthy.
Original PR description
Live chat demo data creation previously used the "date" field on messages to simulate chats at different times. However, the reporting query relies on the "create_date" field. This discrepancy led to unrealistic durations. This commit fixes the issue. task-4753018 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 update keeps formatted names consistent by using the newer tab and newline markers everywhere they are displayed. It prevents names or addresses from showing outdated placeholder text, improving readability for users without changing business workflows.
Original PR description
The formatted display_name feature introduced in [1] used `<tab>` and `<br>` as "indent 4 spaces" and newline identifiers. Commit [2] then changed those two identifiers into `\t` and `\n`. This commit adapts an override of `_compute_display_name` that had been forgotten, but also the docstring of the function to apply the formatting. [1] https://github.com/odoo/odoo/pull/206217 [2] https://github.com/odoo/odoo/pull/207672 Followup of 4749554 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 prevents formatting markers like <tab> and <br> from appearing as plain text in selection fields. Users will now see cleaner, properly spaced account and country labels, reducing confusion during data entry.
Original PR description
[1] introduces the new "odoomark" syntax where \<tab\> is supposed to be displayed as a tab in m2o fields, notably. [2] changes \<tab\> to \t and \<br\> to \n but does not update some uses. This lead to \<tab\> and \<br\> appearing in plain text in the m2o selection. task-4783344 [1]: f18bbfa6748c4be7f2f22ade479d00b1c1443468 [2]: 5effbe451d580c268c7e524fbf71640552111e18
The VoIP call screen no longer shows a transfer button for a feature that is not yet available. This prevents users from clicking an action that would not work and reduces confusion during calls.
Original PR description
The feature is not implemented yet. Don't show buttons that aren't mapped to anything.
This fix restores required planning information on the sales order form so the planned hours button can open correctly. Users can now confirm quotations and access related planning details without encountering an error.
Original PR description
Before this commit, due to a cleaning of sale order views, the `planning_first_sale_line_id` and `planning_initial_date` has been removed from the sale order form view but those fields have to be…
Before this commit, due to a cleaning of sale order views, the `planning_first_sale_line_id` and `planning_initial_date` has been removed from the sale order form view but those fields have to be loaded in the form view to be used as default values when the user clicks on `Planned\n x Hours` stat button, otherwise a traceback will be occurred. This commit introduces again those fields in the sale order form view to be sure those fields are defined and used as default value for the `Planned\n x Hours` stat button. Steps to reproduce ------------------ 0. Install sale_planning module 1. Go to Sales app 2. Create a quotation with a product in which slots will be generated 3. Confirm the quotation 4. Click on `Planned\n x Hours` stat button Current behavior ---------------- A traceback is occurred because `planning_first_sale_line_id` and `planning_initial_date` fields are not defined in the form view. Expected behavior ----------------- The action of the stat button should be executed without any issue. task-4781696
The Documents app now updates the favorite icon as soon as a user marks or unmarks a document. This removes a confusing delay where the action seemed not to work, making document organization feel more reliable.
Original PR description
Steps to reproduce: 1. Go to documents 2. Try to mark your favourite document 3. It will ghost you. Technical Reason: Used record.load() as value was not updating instantly in the UI. 'this.props.record.data[this.props.name] = result' fetched correct value, but didn’t trigger re-render. After this commit: favorite icon state updates instantly. Task-4766725