Wednesday, September 6, 2023
6 changes · master
Resolved issues and error corrections
This fixes how product attachments automatically generate related documents, making the process more reliable. It helps ensure product files are handled correctly with less manual correction needed.
Original PR description
Finetuning of #132739 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects internal documentation for mail and discussion models so developer tools identify returned records accurately. It does not change business workflows or user-facing behavior, but helps reduce development errors and improve maintainability.
Original PR description
Before this commit, static methods on discuss models like `.get()` or `.new()` where not properly documented. The superclass `Record` documents `@returns`, but jsdoc failed to deduce these static methods return subclass instances. We tried to find a way to define things once in `Record` and let typedoc deduce things automatically without overriding in each models just for the sake of type. However typedoc still sucks in 2023 despite requests for improvements to support this specific case since 2016, 7 years ago.
The resume form now prevents users from selecting an end date that is earlier than the start date. This keeps employee resume and certification records accurate and avoids confusing or impossible date entries.
Original PR description
before this commit, in resume we are able to put end date less than start date which is not possible in real life. inside form view add daterange widget to start date field so user not able to select end date less than start date. task-3397726
The activity dialog now closes directly after scheduling or creating a meeting instead of briefly reloading its buttons. This removes a visible flicker where the Schedule button could momentarily change to Save, especially on slow networks, making the workflow feel smoother and more reliable.
Original PR description
This commit solves a flicker in the action buttons of the activity dialog: - open project task kanban view - schedule an activity on a record => this open a dialog - in that dialog, notice the Schedule button - click on it - the button is now, for a small amount of time, replaced by a Save button (If the network goes bad, it can be pretty obvious. Reproduced with the network dev tool) - the dialog is closed When creating a meeting, the save button would be added to the buttons for a small amount of time without replacing any other button instead. By adding the close=1 attribute, the form view of the dialog will no longer reload after the create call which prevents the flicker. task-3270301
Sale orders now show only the relevant contact name for invoice and delivery address fields after changing the customer, instead of also displaying the full address. This keeps the form easier to read and avoids unnecessary clutter for sales users.
Original PR description
Since https://github.com/odoo/odoo/pull/122085, on the sale order form (with website_sale installed), changing the "Customer" changes the "Invoice Address" & "Delivery Address". But the latter are displayed with the partner name, but also with the full partner address. This last information makes the form uglier than before and are useless.  The old `display_name` of `res.partner` was stored in the DB and did not depend on the context. Also, onchange calls add the context of the source field (the one being changed). In this case, `'show_address': 1` is added, and then `display_name` of `partner_invoice_id`/`partner_shipping_id` is also read with this context. We cannot easily fix this in saas16-4 because it was not possible to change the read context of a particular field. With the new specification of onchange, we can override the read context on a particular field.
This fixes a small usability issue where, after confirming and closing a confirmation dialog, the page did not return focus to the element the user was using before. Restoring focus correctly improves keyboard navigation and makes the interface more predictable, especially for accessibility.
Original PR description
When a dialog is closed, the focus is meant to be restored to the previous focused element. Before this commit, it did not work for the ConfirmationDialog when the confirm button was clicked. This was because the focus was lost **before** the dialog was closed (because the confirm button is disabled when clicked), and thus the previous focused element was not in the el of the dialog anymore, and thus the focus was not restored. 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