Wednesday, October 22, 2025
22 changes · 19.0
Enhancements to existing features
This update adjusts image shape controls in the HTML builder, making it easier to manage how images appear on web pages. It helps editors create more polished page layouts with a small usability improvement.
This update restores automated checks for the OCR manual correction experience, helping ensure users can reliably review and adjust extracted document data. It also covers newer capabilities such as selecting text areas and filling repeated line items, reducing the risk of regressions in future updates.
Original PR description
Commit 935b25f has refactored and improved the boxes interface of the OCR, but, due to the lack of time (19.0 freeze), the tests were removed as they needed to be rewritten. This commit re-introduce the tests in a more generic fashion by moving them directly into the mixin instead of inside the `account_invoice_extract` module and it also covers the new features: - Availability on all fields. - Rectangular selection. - Smart line creation/filling for x2many fields. Related to task-[5055731](https://www.odoo.com/odoo/project/2068/tasks/5055731)
The Mexican localization demo company has been changed from Kemper School to a SAT-approved demo company that supports payroll stamping. This keeps demo invoicing and payroll scenarios usable in Odoo 19 without adding extra demo company records.
Original PR description
The SAT has a list of ‘demo’ companies to enable invoicing demo operations through Electronic Data Interchange (EDI). Currently, in Odoo, the default demo company is Kemper School. However, with the release of payroll stamping in version 19, this company is no longer useful, as it cannot stamp payroll. So, instead of adding another company, we modified the Kemper School data to change it to another company that can stamp payroll and all other existing documents. The demo company data was changed. Task-id: 5083590
Resolved issues and error corrections
Shopee delivery orders that are delivered but still awaiting buyer confirmation are no longer incorrectly marked as errors. This prevents unnecessary error states and helps teams track delivery progress more accurately in Odoo.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896 Forward-Port-Of: odoo/enterprise#97613
Documentation and clarification updates
This pull request adds Harold Campo's signed Contributor License Agreement record to the project documentation. It supports legal compliance for accepting contributions and has no effect on Odoo product features or users.
Original PR description
Add CLA for Harold Campo 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
This fix strengthens spreadsheet dashboard validation so carousel items are checked for the correct models and fields. It helps prevent dashboards from relying on unavailable data, reducing configuration errors and broken dependencies.
Original PR description
The json validation didn't check the fields and models of carousel figures. Obviously, it already lead to wrong dependencies: in the Product and Sales dashboard, a domain uses the field `product_tmpl_id.recurring_invoice` which defined in another module which is not a dependency. Task-5138412 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
This fixes duplicate screenshots and screen recordings when automated tests fail, reducing unnecessary files and avoiding related crashes. It also saves recording frames directly as readable PNG images, making failure evidence more reliable if a test run stops unexpectedly.
Original PR description
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok`…
Because both `_handle_console` and `_handle_exception` take a screenshot and save the screencast before setting the test to failure, both operations are duplicated when `_wait_code_ok` unconditionally does the same on test failure. Do a bit of rejiggering to fix things up: - in `_wait_code_ok`, only take a screenshot for general errors, under the assumption that the log/exception code already took a screenshot for other cases (with a possibly better timing) - only save the screencast in `_wait_code_ok`, saving the screencast later should be no issue, we just might get a few more frames Also fix a screencast issue revealed by this double saving: in case where the screencast was not saved fast enough by the first trigger, `_wait_code_ok` would try to save it again and blow up as the screencast info would be half destroyed already. And finally remove the saving of screencast frames to base64 files, save them as PNG directly: writing out the files costs orders of magnitude more than base64 decoding, so we can decode upfront and avoid a bunch of faffing about, and that way if the entire thing crashes before we can `save` the screencast we do get all the frames as readable PNGs. Forward-Port-Of: odoo/odoo#232472
This fix prevents module updates from failing when users have edited or duplicated default UTM tracking names such as LinkedIn. Marking the default tracking records as not updated preserves user changes and avoids uniqueness conflicts during upgrades.
Original PR description
Steps to reproduce: 1) Install utm module. 2) In link tracker edit utm named LinkedIn or any and add another with same name. 3) update the module. We get an error that utm_medium or utm_source should be unique. create goes through `_get_unique_names` method so its only a problem when updating the record. 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 Forward-Port-Of: odoo/odoo#202567
The collaboration status tooltip in spreadsheets now appears in the user's selected language. This improves clarity for multilingual teams and provides a more consistent localized experience.
Original PR description
Tooltip in collaborative status component was not translated. Task: 5164097
This fixes problems that could make Odoo's internal profiler crash, hang briefly, or produce unusable results when stopping after a set number of entries. The change improves reliability for performance diagnostics, helping teams investigate issues without profiler-related interruptions.
Original PR description
Issue: - Python throws cannot join current thread when using the entry count with memory and traces async profilers. Cause: - The profiler has two ways to exit. One is through the context which calls…
Issue: - Python throws cannot join current thread when using the entry count with memory and traces async profilers. Cause: - The profiler has two ways to exit. One is through the context which calls the end() through the parent thread. Another is reaching the entry_count limit or whatever limit used. The exit this way was called through the child thread of the collector. This caused a deadlock as the thread was waiting for itself, which caused python to through out an error "cannot join current thread". Solution: - The solution for this issue is to set an event from the child thread, have the parent spawn another thread that waits for that event so it doesnt block the main thread, and then joins when the even is set. Issue: - Another issue was that the periodic profilers were waiting the full amount of the sleep before ending. Cause: - This was caused because the join waits until the function of the thread is done. Which means it would wait until the sleep is done either way. Solution: - This was also circumvented with the same way by using an event wait. The event wait is broken as soon as the event is set, but it waits a default amount of time before releasing the wait. Issue: - Another issue is that when using the entry_count, the memory profiler was throwing a non serializiable object. Cause: - This is because when accessing the entry_count, which was accessing the entries attribute. This attribute to calculate was triggering the post processing function as well. The post processing function is called once per collector and then it does not enter the function. If the object was not post processed correctly, the collector would have entries that have tracemalloc object. This object is not serializable. Solution: - A simple counter was used instead of the entry_count to check. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Contacts in the Dominican Republic can now use valid 11-digit Cédula tax identification numbers without being rejected. This prevents incorrect validation errors when saving customer or partner VAT details.
Original PR description
**Issue** When inputting a VAT number with a length different from 9 digits, the check fails, even if the number is a valid Dominican RNC. **Steps to Reproduce** 1. Install Dominican localization and the VAT check module (base_vat), along with Contacts. 2. Go to Contacts, create a new contact for the Dominican Republic. 3. Insert "152-0000706-8" as the VAT. **Root Cause** The `check_vat_do` method only validated 9-digit RNC numbers via `stdnum.do.rnc.validate()`. 11-digit Cédula numbers are not supported. **Fix** - Updated `check_vat_do` to: * Validate 9-digit RNC numbers using `stdnum.do.rnc.validate()`. * Validate 11-digit Cédula numbers using `stdnum.luhn.validate()`. Opw-5004221 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228077 Forward-Port-Of: odoo/odoo#224507
This fix prevents certain batch payment tests from running when the required accounting app is not installed. It helps keep automated checks reliable without affecting day-to-day users.
Original PR description
We have tests for payment wihtout journal entries. But these payments can only be generated if accountant in installed. It makes these tests fail if the module is not installed. To avoid making a bridge module only to test these, we add a class that will be skipped if the module is not installed. runbot-232728
Customers receiving Gelato shipping notifications will now get a working tracking link when their order ships in a single parcel. This prevents broken links in delivery emails and helps customers follow their shipment without contacting support.
Original PR description
After receiving the shipping webhook from Gelato, we send a shipping notification with the tracking information to the customer. This commit fix the tracking url for single parcel, which was pointing to an inexistant url. opw-4637331 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232520 Forward-Port-Of: odoo/odoo#232071
This fixes an issue where settling an invoice in Point of Sale could fail if full commercial partner details were not loaded. The system now uses the already available partner ID, making invoice settlement more reliable without changing the user workflow.
Original PR description
Before this commit, it was possible that commercial_partner_id was not loaded, which caused an error when settling an invoice. This commit fixes the issue by avoiding the need to load the full partner record. Since only the partner ID is required to load the account move, it is now read directly from the raw data, which already includes the ID. opw-5112883 Forward-Port-Of: odoo/enterprise#96828
Odoo now shows a clear validation message when a user enters a check number that is too large for a bank journal. This prevents confusing technical errors and helps accounting users correct the value immediately.
Original PR description
**Issue** When trying to set a very large value as *Next Check Number* in a Bank Journal, Odoo raises a low-level `RPC_ERROR` caused by a PostgreSQL `integer out of range` error. This results in a technical traceback instead of a clear message to the user. **Steps to Reproduce** 1. Go to *Accounting > Configuration > Journals* 2. Open the Bank Journal 3. Go to the *Outgoing Payments* tab 4. Enable *Manual Numbering* 5. Set *Next Check Number* to `2147483648` **Root Cause** The field `ir.sequence.number_next` is stored as an integer in the ORM. Any value greater than `2,147,483,647` (max signed 32-bit integer) causes PostgreSQL to raise an overflow error when saving. Since the error occurs deep in the ORM write call, the user only sees a generic RPC error without explanation. Opw-5042096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225103
This fix prevents the editor's page monitoring service from repeatedly reconnecting when a user lacks permission to access a related document. It avoids unnecessary log noise and makes the system behave more reliably by not subscribing users to channels they cannot access.
Original PR description
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img…
Description of the issue/feature this PR addresses: When an exception is raised on the access check, the OutdatedPageWatcherService runs into a reconnect loop, resulting in lots of log entries. <img width="1190" height="435" alt="image" src="https://github.com/user-attachments/assets/8634e254-344f-4f4f-a46e-c0b3674de303" /> Each reconnect attempt causes a log entry: ``` 2025-08-22 11:30:17,770 4 INFO db18_test_access odoo.addons.base.models.ir_rule: Access Denied by record rules for operation: write on record ids: [25], uid: 6, model: crm.lead 2025-08-22 11:30:17,779 4 WARNING db18_test_access odoo.http: Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Marc Demo (id=6) doesn't have 'write' access to: - Lead/Opportunity, Modern Open Space (crm.lead: 25) Blame the following rules: - Personal Leads If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. ``` Current behavior before PR: Reconnect loop. Desired behavior after PR is merged: Do not add channels without sufficient rights. Related to: https://www.odoo.com/de_DE/my/tasks/5026412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231599 Forward-Port-Of: odoo/odoo#223890
Odoo now correctly uses the icon specified in a module's manifest before falling back to the standard default icon. This ensures modules display their intended branding or visual identifier wherever module icons are shown.
Original PR description
Description of the issue/feature this PR addresses: The `get_module_icon` function is used in multiple places allowing to default to the standard icon if none is found. First, if the module already has a checked icon as a cached property, just return it. Afterwards, read the raw value from the manifest as the icon to check, we were checking only the default location so the cached value effectively ignored what was defined in the manifest. Current behavior before PR: 'icon' attribute is ignored in the manifest. Desired behavior after PR is merged: Check the icon defined in the manifest before defaulting to the default icon location. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Performance tests for the online shop page were updated so they no longer fail because of expected differences in demo data or installed apps. This helps teams keep monitoring page speed reliably while reducing false alarms in automated testing.
Original PR description
https://runbot.odoo.com/odoo/runbot.build.error/233319 FAIL: TestWebsiteAllPerformancePostInstall.test_perf_sql_queries_shop FAIL: TestWebsiteAllPerformance.test_perf_sql_queries_shop AssertionError: 65 not less than or equal to 37
This fixes a visual inconsistency where some website badges appeared larger than intended after a prior styling change. Badges now keep the expected size, preserving a consistent look across website pages.
Original PR description
| saas-18.4 and above | This PR | |--------|--------| | <img width="439" height="400" alt="image" src="https://github.com/user-attachments/assets/00db2fab-69db-410b-8ed2-f8063e033ce5" /> | <img…
| saas-18.4 and above | This PR | |--------|--------| | <img width="439" height="400" alt="image" src="https://github.com/user-attachments/assets/00db2fab-69db-410b-8ed2-f8063e033ce5" /> | <img width="437" height="392" alt="image" src="https://github.com/user-attachments/assets/b6896545-34b5-4816-a35f-5c2605d4153b" /> | Prior to Commit[^1], the front-end badges using `.badge.o_tag` were receiving a `12px` font size, which came from a rule defined in portal. This looked fine, although odd, since a style from portal was affecting the entire front end. After Commit[^1], this rule no longer exists, meaning that `.o_tag` now falls back to `0.875rem` (14px by default), while standard badges use a default font size of `0.75em` (12px by default) Since using `.badge.o_tag` never allowed overriding the `font-size` value, we fixed the issue by assigning the `--badge-font-size` CSS variable directly to the badge definition, ensuring the correct visual result. task-4900376 [^1]: https://github.com/odoo/odoo/commit/8f8a370a84d136f3d2316eb1a55c7168b7ae6ccf#diff-23677f06a9aaf2e3395e957cfb9580ce6fcc9aba2635b560fe8f15fa27707313L29 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230530
The API documentation now generates JavaScript examples that send request data in the correct format. This prevents users from encountering failed requests when copying examples from the documentation.
Original PR description
**Current behavior before PR:** Before this commit, the example generated for JS was incorrect and returned a 400 Bad Request error. This was due to the fact that we must use `JSON.stringify` on the body before making the request. **Desired behavior after PR is merged:** JS example works --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The ESG dashboard graphs now use colors that display correctly in both light and dark mode, making the data easier to read for users. On mobile, the initiative card layout was also adjusted to leave more room for key action buttons.
Original PR description
Before this commit, the color chosen for the graphs in the ESG dashboard does not take into account the dark/light mode and so they does not have the right color when the user is in dark mode. This commit makes sure the graphs are well rendered in dark mode. task-5138512
Customers viewing product pages can now click a product image once to zoom in and click again to zoom back out. This makes image browsing smoother and avoids shoppers getting stuck in a zoomed-in view.
Original PR description
Step to reproduce: 1. Install 'website_sale' 2. Create a product with an image 3. Open its page on the website via smart button 4. Click on the product image **Issue:** - After zooming in on the image with mouse click, there is no option to zoom out with mouse click. **Solution:** - Implement a toggle mechanism: - First click on the image zooms in - Second click zooms out opw-5104526