Friday, December 12, 2025
10 changes · master
Enhancements to existing features
This change stops Odoo from writing routine informational log entries whenever an access error is created and later handled. It makes logs cleaner and more useful for investigations, while still recording details when an access error is not handled.
Original PR description
There is no need to log an INFO every time we create an AccessError. The exception will be raised and the caller is responsible of either letting it propage or catching and handling it: by replacing the exception, logging, etc. Current behavior before PR: If you make an access error and catch it, you will see it in the logs. It is an INFO and there is no stacktrace, so it gives no information when accessing a related model from somewhere else. Desired behavior after PR is merged: Stop logging these messages. They will be logged in the exception is not caught. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This commit adds Spanish translations so error messages when sending an invoice get translated correctly and are not a combination of english and spanish task: 4625404
Original PR description
This commit adds Spanish translations so error messages when sending an invoice get translated correctly and are not a combination of english and spanish task: 4625404
The Discuss app now uses subtler border styling so dark theme screens feel less visually busy. This improves readability and visual comfort while keeping the light theme appearance nearly unchanged.
Original PR description
The border in discuss app in dark theme was too distracting with its too light color. This happens because border-secondary has still a strong presence in dark theme, when in white theme this is…
The border in discuss app in dark theme was too distracting with its too light color. This happens because border-secondary has still a strong presence in dark theme, when in white theme this is reduced appropriately. This commit improves by using `border-dark o-border-opacity-15` instead of `border-secondary`, which makes it almost visually unchanged in white theme but in dark theme this reduces border visible to a similar ratio than the white theme counterpart. Before / After (dark theme) <img width="1275" height="870" alt="dark-before" src="https://github.com/user-attachments/assets/70f49fcb-28c9-4e6c-9991-87458edce5bb" /> <img width="1275" height="870" alt="dark-after" src="https://github.com/user-attachments/assets/5dc43d74-9a27-411e-91ee-c6d21d843062" /> Before / After (white theme) <img width="1275" height="870" alt="white-before" src="https://github.com/user-attachments/assets/884aba63-6e99-4bd0-b6d3-682c5adf1004" /> <img width="1275" height="870" alt="white-after" src="https://github.com/user-attachments/assets/30fc5e04-473a-423a-8bd0-96887142ab07" />
The live chat channel views no longer offer grouping by agents who requested or provided help, because those groups only contained one channel and added clutter. This makes the channel view cleaner while keeping the useful agent reporting options available elsewhere.
Original PR description
The `livechat_agent_{requesting,providing}_help_history` field is used in discuss channel views and agent reporting views to quickly find out who requested/provided help on a channel.
However, it is also used as a group by filter in the channel views which makes no sense as it will always produce groups of one channel (history is only linked to a single channel).
This commit removes those two group by filters as they are redundant with the ones in the agent reporting anyway.
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-prInventory users can now filter Putaway Rules to show archived records. This makes it easier to review inactive rules without extra manual searching, improving day-to-day warehouse configuration management.
Original PR description
Task: 4735351 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
Website editors can now change the layout of the Kickoff content block directly in the website builder. This makes the block more consistent with other website sections and gives teams better control over column-based page designs.
Original PR description
This PR adds the missing layout option for the s_kickoff snippet. It upgrades legacy containers for consistency and enables proper use of column layouts and related controls within the website builder. task-5319760
Improves internal testing feedback by making decorator-related override errors easier to understand. This helps developers identify the exact cause of lint test failures faster, reducing investigation time without changing business functionality.
Original PR description
[IMP] test_lint: improved message during testing (add decorator override)
Before this commit, the error message appeared like this:
```
TypeError: Invalid override in product.template of load, attribute '_api_model' does not match.
Original definition in odoo.orm.models:
def load(self, fields, data)
Incompatible override definition in product:
def load(self, fields, data)
```
After:
```
TypeError: Invalid override in product.template of load, decorators does not match.
Original definition in odoo.orm.models:
@api.model
def load(self, fields, data)
Incompatible override definition in product:
def load(self, fields, data)
```
Forward-Port-Of: odoo/odoo#239655This change reduces repeated processing during website test setup by reusing already prepared snippet data. It helps the test suite run faster without changing customer-facing website behavior.
Original PR description
__Behavior before commit:__ `getWebsiteSnippets` is called *at least* twice per website Hoot test. - [When opening the sidebar][1] - [When `render_public_asset` is called][2] Although the orm result is cached using `websiteSnippetsPromise`, it still calls `removeImageSrc` everytime. But inside `removeImageSrc`, this line takes around 50 ms to execute: ```js new DOMParser().parseFromString(xmlString, "text/html") ``` Therefore wasting at least 100 ms per test. __Fix:__ Make the promise encompass the result of `removeImageSrc` so that it is called only once at the beginning of the test suite. [1]: https://github.com/odoo/odoo/blob/2dc9529af127ed4b2d451059b6ab9c83778c7814/addons/website/static/tests/builder/website_helpers.js#L281 [2]: https://github.com/odoo/odoo/blob/2dc9529af127ed4b2d451059b6ab9c83778c7814/addons/website/static/tests/builder/website_helpers.js#L51 task-5269391 Forward-Port-Of: odoo/odoo#239591
The point-of-sale loyalty system now stops checking reward products once it finds a valid free product option. This reduces unnecessary processing and helps keep checkout performance smooth when loyalty programs include multiple reward products.
Original PR description
Before this commit, the computation of potential free product quantities looped through all reward products even after finding a valid one. This led to unnecessary calculations and performance degradation, especially when multiple reward products were involved. opw-5268991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239442
This update enhances the website generator's efficiency by proactively verifying URLs before sending requests to the scraper. This prevents unnecessary requests to invalid or blocked URLs, improving performance and reducing potential errors. The check is now performed on the IAP server for security and efficiency.
Original PR description
This PR adds the client side verification of an url for the request we make to generate a website using the website scraper. **The goal is to filter all the unwanted requests (invalid urls, banned urls) before launching the scraper process.** The check is done on the IAP server, and retrieved on the DB. The reason is that we don't want to send a request directly from the db [as this was already discussed](https://github.com/odoo/enterprise/pull/92724). Since the IAP server is also the one that will eventually do the scraping request, it also makes more sense that it is the one to check (to avoid the case where odooDB has access to an URL and IAP server does not). Previous PR was in master, but since we only change js component, we can modify 19.0 directly. Link : [Master PR](https://github.com/odoo/enterprise/pull/99433) Forward-Port-Of: odoo/enterprise#100967