Odoo Changelog — 2026-03-14

Saturday, March 14, 2026

3 changes · master

Improvements(3)

Enhancements to existing features

[IMP] mail: remove redundant member actions from card popover

Coremasterhr_holidaysmail

The member action menu has been removed from avatar popovers because the same actions are now easier to access directly from the members panel. This reduces duplicate controls and makes managing channel members more consistent and discoverable.

Original PR description

When channel owner / admins was introduced, the member actions were defined in the specific avatar card popover from the members panel. This was not intuitive to find these actions: - only this…

When channel owner / admins was introduced, the member actions were defined in the specific avatar card popover from the members panel.

This was not intuitive to find these actions:
- only this avatar card had this feature, not the other cards
- the feature was hard to find, as we had to click to open avatar, be aware that there's a new "..." button to click and show the member actions.

This made much more sense as a button "..." shown on hover when mouse-hovering the member item in the members panel, which was added shortly after [1].

To follow stable policy, the "..." buttons in card popover have been kept, but in `master` they should be removed as the actions from member item in members panel makes more sense.

[1]: https://github.com/odoo/odoo/pull/244806

Before / After
<img width="571" height="322" alt="Screenshot 2026-03-13 at 17 22 04" src="https://github.com/user-attachments/assets/b455b423-788a-4326-9b70-08cedf58355f" />
<img width="564" height="314" alt="Screenshot 2026-03-13 at 17 21 42" src="https://github.com/user-attachments/assets/5b9294f9-cdc1-4482-92ba-813cdf8193e0" />

#mail#members#user experience

[IMP] base_geolocalise: extract api discovery

PR #253160

Coremasterbase_geolocalize

The geolocation component now separates how it retrieves the API key from the rest of the address lookup process. This makes the setup easier to maintain and adapt without changing user-facing geolocation behavior.

Original PR description

Move the api key retrieval to another method.

Forward-Port-Of: odoo/odoo#252618
Forward-Port-Of: odoo/odoo#243496

#geolocation#maintenance#api-key

[IMP] tests: ChromeBrowser cleanup sequence

PR #253532

Coremastertests

This change improves how automated browser tests clean up temporary files and related resources when setup fails. It helps keep development and testing environments cleaner and more reliable, reducing leftover files that can accumulate after failed test runs.

Original PR description

Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the
`atexit.callback(browser.stop)`: the temporary directory for the user data dir is created as soon as the browser is instantiated, but the cleanup is only recorded after a successful `navigate_to`, so if that (or a previous step e.g. authentication) fails then the tempdir is never cleaned up.

Rather than just move the call up the body and re-introduce conditionals to `stop` to handle more partial initializations though, use the magic of ~~buying two of them~~ `ExitStack` to record cleanup requirements dynamically as the `ChromeBrowser` initialises.

This initially used a bunch of `ExitStack.callback` calls with ad-hoc cleanup, but turns out most of these cases are better as CMs:

- replace `mkdtemp` / `rmtree` by `TemporaryDirectory`, which Just Works as a CM
- add context-manager methods to the screencaster classes (also remove `stop` which is redundant with `__exit__`) so they Just Work as CMs
- convert `_chrome_start` and `_open_websocket` to `@contextmanager`... for obvious reasons

This makes the relation between setup and cleanup clearer, as well as more self-contained in case we want to move stuff to a submodule eventually. It also ensures cleanups run in the correct order, and avoids having to deal with partial initializations.

Keep `ChromeBrowser.stop` because it seems unnecessary to edit those out for now, but have it just `close` the exitstack (which runs all the registered cleanups).

NOTE: it might make sense for `browser_js` to just use `ChromeBrowser.cleanup` instead of having its own exitstack, not entirely sure... Alternatively it might make sense for ChromeBrowser to *take* a CM as parameter... and / or for ChromeBrowser to *be* a CM?

Forward-Port-Of: odoo/odoo#253035

When channel owner / admins was introduced, the member actions were defined in the specific avatar card popover from the members panel. This was not intuitive to find these actions: - only this avatar card had this feature, not the other cards - the feature was hard to find, as we had to click to open avatar, be aware that there's a new "..." button to click and show the member actions. This made much more sense as a button "..." shown on hover when mouse-hovering the member item in the members panel, which was added shortly after [1]. To follow stable policy, the "..." buttons in card popover have been kept, but in `master` they should be removed as the actions from member item in members panel makes more sense. [1]: https://github.com/odoo/odoo/pull/244806 Before / After <img width="571" height="322" alt="Screenshot 2026-03-13 at 17 22 04" src="https://github.com/user-attachments/assets/b455b423-788a-4326-9b70-08cedf58355f" /> <img width="564" height="314" alt="Screenshot 2026-03-13 at 17 21 42" src="https://github.com/user-attachments/assets/5b9294f9-cdc1-4482-92ba-813cdf8193e0" />

Trying to find out why I kept having a bunch of leftover `tmpsomethingsomethign_chrome_odoo` leftovers I realised #203412 had a bit of an error in the location of the `atexit.callback(browser.stop)`: the temporary directory for the user data dir is created as soon as the browser is instantiated, but the cleanup is only recorded after a successful `navigate_to`, so if that (or a previous step e.g. authentication) fails then the tempdir is never cleaned up. Rather than just move the call up the body and re-introduce conditionals to `stop` to handle more partial initializations though, use the magic of ~~buying two of them~~ `ExitStack` to record cleanup requirements dynamically as the `ChromeBrowser` initialises. This initially used a bunch of `ExitStack.callback` calls with ad-hoc cleanup, but turns out most of these cases are better as CMs: - replace `mkdtemp` / `rmtree` by `TemporaryDirectory`, which Just Works as a CM - add context-manager methods to the screencaster classes (also remove `stop` which is redundant with `__exit__`) so they Just Work as CMs - convert `_chrome_start` and `_open_websocket` to `@contextmanager`... for obvious reasons This makes the relation between setup and cleanup clearer, as well as more self-contained in case we want to move stuff to a submodule eventually. It also ensures cleanups run in the correct order, and avoids having to deal with partial initializations. Keep `ChromeBrowser.stop` because it seems unnecessary to edit those out for now, but have it just `close` the exitstack (which runs all the registered cleanups). NOTE: it might make sense for `browser_js` to just use `ChromeBrowser.cleanup` instead of having its own exitstack, not entirely sure... Alternatively it might make sense for ChromeBrowser to *take* a CM as parameter... and / or for ChromeBrowser to *be* a CM? Forward-Port-Of: odoo/odoo#253035