Wednesday, July 24, 2024
8 changes · 17.0
Resolved issues and error corrections
Fixes an issue where text highlight controls could remain visible after selecting different text while translating website pages. This keeps the editing toolbar accurate and reduces confusion for users managing multilingual website content.
Original PR description
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the…
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the highlighted text > The text highlight options are shown. - Select a text without any option > The highlight options remain displayed. Starting from [1], we allow using text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. Another fix (from [2]) was added later to exceptionally authorize the editor's creation for "invisible" elements in translate mode, with a small adaptation on `_activateSnippet()` to prevent activating invisible snippets when their related sidebar buttons are clicked. This code unintentionally leads to keeping the old editors created for a text snippet when switching to another one in the DOM. To fix this behaviour, we still need to ensure existing editors are destroyed so we only create the ones we need in translate mode. [1]: https://github.com/odoo/odoo/commit/3a149e36f7e6deaf156a7ee35e654aad61cf2e5d [2]: https://github.com/odoo/odoo/commit/67efd1d98072f36caf9c473e97984631eb6bc8a3 task-3975683
Updating a date or date-time field now keeps the selected value visible while the system processes related changes. This removes a brief blank-state flicker, making forms feel smoother and less confusing for users.
Original PR description
Before this PR, when selecting a new date in a date(time)_field, the value would first be reset before performing the "onchange" call, resulting in a flicker (selected value -> null -> new value after onchange). Now, the value is not reset and is simply left as selected when performing the onchange call, as to not trigger any flicker. Part of task [3471424](https://www.odoo.com/odoo/333/tasks/3471424) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where portal users could not set the Customer field while creating a new subtask, even though it became editable after saving. The change keeps the Customer field available immediately, making subtask creation smoother and avoiding unnecessary extra steps.
Original PR description
Steps: - Login as portal, and to to a task form, page sub-tasks. - Make Customer column visible. - Add a line and try to edit that field. Issue: You can't. But after saving, you can. Cause: The new record doesn't have a project (it will be given to it on save). Yet this PR odoo#111335 added the condition that it should be invisible if no project. The reason why it caused no issue in 16.3 (where it was merged) was that there was a default project in `child_ids`'s context. Solution: In this case, the condition is not needed. Subtasks always have a project : private tasks can't have subtasks and deleting project field on a non-private task's subtask will actually give it its parent project. So the solution is simple: remove the condition. task-3713729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Long text in website editor banners now remains inside the banner area instead of spilling out. This improves readability and keeps banner designs visually consistent for users editing pages.
Original PR description
**Current behavior before PR:** Long texts overflowed beyond the banner's boundaries. **Desired behavior after PR is merged:** Ensure that text remains within the banner's limits to improve readability and visual consistency. task-4037185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Manage Attachments option now includes generated invoice files that were previously hidden. This helps users find and manage all attachments linked to a record from the same place.
Original PR description
### Issue:
Generated invoices does not appear in the page 'Manage Attachments'.
### Steps to reproduce:
- Activate the developer mode
- In Accounting > Customers > Invoices create a new one
- Confirm and click on Send & Print, an invoice is generated and can be seen in the attachment of the chatter
- Click on the debug icon, then on 'Manage Attachments'
- The attachment does not show up
### Cause:
The domain used for the 'Manage Attachments' search does not contain restriction on res_field and id. So a new condition is added: ('res_field', '=', False). The logic behind this functionality is explained in this commit: https://github.com/odoo/odoo/commit/1bb61c970ed63eabe3821d21f3ed6f99c4b16daa In the case of invoices res_field is equal to invoice_pdf_report_file, so the invoice does not appear.
### Solution:
Add a context to the search request to skip the res_field test. Thus showing all attachments.
opw-3997094Activity view dates such as Created and Due On now use the date and time format configured for the user's language. This keeps activity information consistent with the rest of Odoo and avoids confusion for users working with localized or custom date formats.
Original PR description
Issue ---- The date fields in the activity view aren't displayed according to the language's date/time formats. Steps ----- - Go to Settings -> Translations -> Language. - Use a custom date & time format. - Create a new model that has an activity view, say a project task. You'll see the task's deadline is displayed according to your format (correct behavior). - Add an activity and set a due date. - The "Created" & "Due On" dates don't match your custom format. Cause ----- In the activity component, the dates weren't formated according to the current language's date/time format but rather a hard-coded one. opw-3929864
The Project kanban progress bar now keeps the correct color when users filter or group tasks marked as done. This makes task status views clearer and avoids confusion when reviewing completed work.
Original PR description
Steps to reproduce: - Open Project - Go into any project in kanban view - Mark any task as done. - From the progress bar click on done section Issue: - You can see that the color is does not apply while grouping tasks using progress-bar. Cause: - Missing css-kanban-filter which supplies the color to be applied while grouping by progressbar. - Adding CSS-filter is not done because success-done i.e. color of done tasks is not from standard CSS library(I.e. Bootstrap). Solution: - Add the CSS filter for done stage name as success-done. task-3852596
Repair operation types are no longer shown as selectable options when setting up quality control points. This prevents users from choosing an operation that would not create quality checks in this version, reducing confusion during setup.
Original PR description
Description of the issue/feature this PR addresses: 1 - Create a quality.point and add a repair operation type in the 'picking_type_ids' field 2 - Create a repair picking Current behavior before PR: No QC is created. This is expected because of https://github.com/odoo/enterprise/pull/59509 - only available since 17.3 Desired behavior after PR is merged: Exclude “repair” operation types from the domain of the “picking_type_ids” field to avoid confusing the user. opw-4052819