Daily updates from Odoo
Navigate
Branch
Friday, August 19, 2022
13 changes
Enhancements to existing features
Restricted fields and sections in back-end views are now handled consistently: users without the right access group will no longer receive those elements in the view at all. This simplifies behavior for developers and supports future performance improvements by making back-end view caching easier and less costly.
Original PR description
This revision is to make uniform the behavior of the `groups` attribute on the Python model fields and on the node in the view architecture. In both cases, remove the node from the view completely.…
This revision is to make uniform the behavior of the `groups` attribute on the Python model fields and on the node in the view architecture. In both cases, remove the node from the view completely. Before this revision, in a back-end view: - In the Python model, if a field has the `groups` attribute set and the user is not part of the groups, the field is removed, completely, from the view. - In the view architecture, if a node has the `groups` attribute set and the user is not part of the groups, the node is made invisible (not completely removed, just made invisible). in a front-end view: - if a node has a "groups" or "t-groups" set and the user is not part of the groups, the node is removed from the view. So it's 2/3 cases removing nodes restricted to a group. and 1/3 case making invisible nodes restricted to a group. It's simpler to have a uniform behavior for the 3 cases, simpler to understandard for developers. In addition, this will help for the goal to cache back-end views. It makes possible to convert views using the `groups_id` field by moving the content of these views directly in the view to which they add content which is suppose to be completely removed when the user has not the according group. By getting rid of the `groups_id` many2many field on `ir.ui.view`, it makes possible to cache the view architecture without requiring to use the groups in the cache key. Currently, if we want to cache the view architecture, it would be required to use the intersection of the user groups with the `groups_id` groups of the view, making it costly to compute the cache key, therefore altering the performance point to cache the view architectures. Related community PR: odoo/odoo#95729
The appointment booking experience has been redesigned across the website with clearer cards, improved progress steps, and more flexible avatar display. Customers can now choose a staff member from visual operator cards or see all available times, making bookings easier and more informative.
Original PR description
RATIONALE Before this commit, the display of the appointment front-end views was simple but lacked a proper design. It implements the new design in all the views, allowing more customization, mainly…
RATIONALE
Before this commit, the display of the appointment front-end views was simple but lacked a proper design.
It implements the new design in all the views, allowing more customization, mainly on the avatar display.
A new view is added to act as an operator selection before the time selection, if some condition is met.
This view display a card view of all available staff users, whereas before the selection was only a name
in a select dropdown. All the views are redesigned and harmonized.
MAIN CHANGES
- NEW OPERATOR SELECT VIEW / FLOW
- The operator cards are made of a large avatar, the name and function of user, as well as a description (website description, which requires website_partner to be now in the website_appointment dependencies).
- SEE ALL AVAILABILITIES: on that view, the customer can pick this option to allow all suggested staff users to be used when computing availabilities. At that point, it is the same as a random assign method, but restricted to suggested staff users (the ones on the appointment_type, but after filtering)
- The view is only active if avatars are activated, at least two users can be selected and if the assign_method is 'chosen'
- Once a user is selected, we reach the calendar time selection view.
- This view is called via a new route /<appointment_type_id>/select, that redirects to /<appointment_type_id> if the condition is not met. Also, the time selection view will redirect to this new route if the condition is met.
- url parameters staff_user_id and see_availabilities manage this flow, and are adequately transmitted through the submissions / actions / links in the appointment process. See commit messages for more details.
- DYNAMIC DESIGN
A new parameter 'AVATARS_DISPLAY' is set on the appointment_types. Views will display user's details / user's avatar according to this value. On creation of 'custom' or 'work_hours' appointment_types, this parameter will be set to True if the linked user has either an image or a function on their partner.
- NEW DESIGN
All views are redesigned and harmonized. See commit messages and Figma design on task for more details. Those views are:
- Appointment Card / List Views
- Calendar time selection
- Details of Appointment (Form)
- Appointment Validation
Some fields are editable in the front-end editor and have now a placeholder. Some (theme-color matching) helper images are also added if no appointment exist, both in front-end / back-end.
- NAVBAR
The views receive clickable chevrons if website is installed. There is also a 'all appointments' link that redirects to all available appointments.
Task-2496629This update makes a few internal improvements to how VoIP registration settings are initialized and maintained. It helps keep the calling registration process clearer and more consistent, with minimal direct impact for users.
Original PR description
In this commit: + Make the expiration interval a field and document it + Set the initial value of `state` in `_created` hook instead of via a compute + Fix single quotes
Saved SEPA direct debit payment tokens now use a shorter, modern masked format such as •••• 1234 instead of long strings of Xs. This improves readability for customers and staff when viewing subscriptions, payment flows, and related communications.
Original PR description
Before this commit, tokens were prefixed with usually 12 X’s. To improve readability, modernity and to shorten the length, this commit changes token prefixes to a standard of •••• 1111. task-2832669 See also: - https://github.com/odoo/odoo/pull/94978 - https://github.com/odoo/upgrade/pull/3738
The employee referral dashboard has been modernized to improve maintainability and keep the experience aligned with Odoo’s current interface framework. This should help ensure a smoother, more consistent dashboard experience for users while making future improvements easier.
This update simplifies how several Odoo Enterprise apps handle internal data replacement behavior. It should make the underlying code easier to maintain without changing day-to-day user workflows.
Original PR description
* = approvals, documents, sign, voip Distinction between "replace" and "insert-and-replace" can be guessed based on the type of the provided data. task-2957295 https://github.com/odoo/odoo/pull/98404
Resolved issues and error corrections
This fixes the text color on bank reconciliation model buttons so labels appear in white as intended. The change improves readability and keeps the accounting interface visually consistent for users.
Original PR description
The text color should be white. task: 2928259
Some preloaded records created from XML were treating HTML content as XML, which could add unwanted headers or wrappers. This update marks those fields correctly so demo and configuration content displays as intended across affected apps.
Original PR description
When a record is created through xml data, its HTML fields should receive a `type="html"` attribute, not a `type="xml"` attribute. When important XML data with XML type instead of HTML type will have 2 differences: - The field value will be prefixed by `<?xml version="1.0"/>` - If the HTML contains multiple root nodes, the value will be wrapped in a `<data/>` tag. See `_fix_multiple_roots()` and the `xml_import` class for more details.
This update adjusts several accounting and Studio screens to work correctly with the newer Bootstrap version used by Odoo. It prevents errors and broken expand/dropdown behavior in reports, follow-up views, asset reports, and Studio-managed views.
Original PR description
in bootstrap 5.x the toggle attribute changed from `data-toggle` to
`data-bs-toggle`, so we have to change `data("toggle")` by
`data("bs-toggle")`
https://getbootstrap.com/docs/4.6/components/collapse/
https://getbootstrap.com/docs/5.1/components/collapse/
Also using `$el[0].dataset.bsToggle` instead of `$el.data("toggle")` is
better since `data()` can be confusing
```js
const a = document.createElement("a");
> <a></a>
a.setAttribute("data-bs-toggle", "dropdown")
> <a data-bs-toggle="dropdown"></a>
a.dataset
> DOMStringMap {toggle: 'dropdown', bsToggle: 'dropdown'}
$(a).data()
> {}
```
https://pad.odoo.com/p/wowl_views
[aju] https://watch.screencastify.com/v/XuuQTkKRFX3lJh1vnvt9 project.task
kanban view > schedule an activity > mark it as done > traceback
https://pastebin.com/i96Krxrb
community: https://github.com/odoo/odoo/pull/98339Code cleanup and technical improvements
The messaging code was updated to use a simpler internal name for a message list item. This does not change how users interact with the product, but it makes the code easier to understand and maintain.
Miscellaneous changes
When an article does not have any title and the user clicks on the text input containing the title of the document, the script will automatically fill the text input with the first h1 of the document. The selector allowing the script to retrieve the first h1 is not correct and can select several titles at once. When it occurs, the script fills the text input with a concatenation of all h1 titles which does not correspond to the desired behavior. With this commit, we will update the selecto
Original PR description
When an article does not have any title and the user clicks on the text input containing the title of the document, the script will automatically fill the text input with the first h1 of the document. The selector allowing the script to retrieve the first h1 is not correct and can select several titles at once. When it occurs, the script fills the text input with a concatenation of all h1 titles which does not correspond to the desired behavior. With this commit, we will update the selector to select the first h1 of the document. We will also slightly refactor the function to make sure that the model is updated before updating the view. task-2957260 Forward-Port-Of: odoo/enterprise#30576
Some Helpdesk Tickets have wrong 'SLA Failed' flag (True), even when all policies are met. To replicate customer issue I followed steps below: 1. We have SLA policy with deadline (assume 5 min after creation of ticket). 2. Our ticket met conditions for SLA (conditions were met before 5 minutes, so "SLA Failed" Flag is false). 3. After SLA deadline (let us say 15 minutes after ticket creation) the Kanban stage of ticket changes. 4. As result, "SLA Failed" flag will be true. As per my
Original PR description
Some Helpdesk Tickets have wrong 'SLA Failed' flag (True), even when all policies are met. To replicate customer issue I followed steps below: 1. We have SLA policy with deadline (assume 5 min after…
Some Helpdesk Tickets have wrong 'SLA Failed' flag (True), even when all policies are met. To replicate customer issue I followed steps below: 1. We have SLA policy with deadline (assume 5 min after creation of ticket). 2. Our ticket met conditions for SLA (conditions were met before 5 minutes, so "SLA Failed" Flag is false). 3. After SLA deadline (let us say 15 minutes after ticket creation) the Kanban stage of ticket changes. 4. As result, "SLA Failed" flag will be true. As per my check, it comes from recalculating function '_compute_sla_reached_late', which checks if deadline is earlier that reached SLA date (ok) or deadline is earlier than now (not ok, as there is no condition to exclude SLA that are already satisfy, i.e. reached date is earlier than deadline). That function depends on deadline, which is recalculated when ticket changes stage. To fix it, condition for SQL was modified. First one remains the same, second has additional AND condition that reached date is NULL. Support ticket id: 2869202 Forward-Port-Of: odoo/enterprise#30235
Forward-Port-Of: odoo/enterprise#30543 Forward-Port-Of: odoo/enterprise#29796
Original PR description
Forward-Port-Of: odoo/enterprise#30543 Forward-Port-Of: odoo/enterprise#29796