Thursday, December 7, 2023
4 changes · master
Code cleanup and technical improvements
Messaging and live chat avatars now use Odoo's standard image delivery path in most cases, reducing duplicate code and making behavior more consistent. This cleanup should make avatar handling easier to maintain while preserving the special live chat embed route needed for browser access rules.
Original PR description
This PR cleanup the extra avatar route by moving the access right check in `_find_record_check_access`, allowing to always use the `web/image` route to get avatars. Custom route for im_livechat embed can't be removed for cors reasons. This PR also uniformise the getter avatarUrl for thread and persona model, allowing to delete the `threadservice.avatarUrl` function and `thread.imgUrl` getter. PR enterprise: https://github.com/odoo/enterprise/pull/52116
This update simplifies how Odoo's web framework makes server requests, making the code easier for developers to use and maintain. The change is mostly internal, but it touches many apps and may slightly affect how background requests behave when screens are closed or changed.
This update renames an internal WhatsApp contact image field from imgUrl to avatarUrl to align with related platform changes. It does not introduce new user-facing behavior, but helps keep the codebase consistent and easier to maintain.
Original PR description
See https://github.com/odoo/odoo/pull/142010
This change updates multiple Odoo Enterprise apps to use a newer internal way of communicating with the server. It should not change day-to-day behavior for users, but it helps keep the platform aligned with the latest core architecture and reduces obsolete code.
Original PR description
This PR aims at simplifying the way developpers can do rpcs with our framework. Before this commit, in components, they had to import the hook `useService`, and in the setup do something like…
This PR aims at simplifying the way developpers can do rpcs
with our framework. Before this commit, in components, they had to
import the hook `useService`, and in the setup do something like
`this.rpc = useService("rpc")`, and then use `this.rpc` where they
wanted. In services, they had to explicitely declare the dependency
to the rpc service. In any other functions (like helper functions),
it was a bit painful: the function had to take an env (or the rpc
function directly) in arguments, which wasn't ideal.
This PR makes doing rpcs easier. The rpc service service has
been removed. The `jsonrpc` function has been renamed into `rpc`
(and the file `rpc_service` into `rpc`). One can now simply do
`import { rpc } from "@web/core/network/rpc"` and use `rpc` where
he wants.
Note that this change has a (maybe) not insignificant side-effect.
We no longer have the "protection" on rpc. Before, when a component
used `useService("rpc")`, the returned function was tied to that
component instance. If the component was destroyed when calling the
function, it crashed (s.t. a destroyed component didn't do rpc). If
the component was destroyed during the rpc, the promise was left
pending forever (s.t. subsequent callbacks weren't executed). This
protection was sometimes annoying, and people started to bypass it
by directly calling `env.services.rpc` (i.e. a version which isn't
tied to the component). We believe this protection is not really
necessary. In the future, we may introduce an `alive` function to
wrap rpc calls, and use it at some places where it is indeed
necessary (i.e. move it user-space instead of enforced by the
framework).
Part of task~3621046