Tuesday, October 21, 2025
46 changes · 19.0
Resolved issues and error corrections
App icons created in Web Studio are now automatically resized before being saved. This prevents oversized images from taking unnecessary space in caches and the database, helping keep requests lighter and performance more consistent.
Original PR description
Before this commit, the IconCreator images were sent as is in their full size. Downstream it was problematic because apps' icons were bigger than necessary, bloating the different caches, the database, and the request. After this commit, icon are resized to a max of 64x64 pixels. Forward-Port-Of: odoo/enterprise#97626 Forward-Port-Of: odoo/enterprise#94480
This update lets Odoo process files before they are uploaded, including resizing image files when needed. This helps keep uploaded Studio icons and similar images from unnecessarily increasing database size.
Original PR description
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#231899 Forward-Port-Of: odoo/odoo#226611
This fixes missing payroll group settings on certain Swiss payroll employee fields. It helps ensure payroll information is shown and managed consistently for the correct employee payroll group, reducing configuration errors.
Original PR description
The payroll group was missing on some payroll fields. Related runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/233445 task-5179821 Forward-Port-Of: odoo/enterprise#97611
Tax return creation now correctly recognizes fiscal years that do not start in January. This prevents incorrect “wrong dates” warnings when users create annual returns aligned with their company’s configured fiscal year.
Original PR description
When the company fiscal year is not the first of the year (Aug 1 → Jul 31), creating a tax return for the fiscal year (2024-08-01 → 2025-07-31) wrongly triggers the wizard’s “wrong dates” warning.…
When the company fiscal year is not the first of the year (Aug 1 → Jul 31), creating a tax return for the fiscal year (2024-08-01 → 2025-07-31) wrongly triggers the wizard’s “wrong dates” warning. The wizard validates the range by slicing it into periods via `_get_period_boundaries()`, which anchors the first period using `_get_start_date_elements()`. If we dont have `deadline_start_date` that anchor falls back to a fixed Jan 1 (calendar year) instead of the company’s fiscal-year start. Consequently, the first computed period becomes 2024-01-01, so the check sees a mismatch and flags the warning even though the user’s dates are perfectly aligned with the fiscal year. The fix is to use the company’s fiscal-year start as the anchor for period slicing instead of silently defaulting to Jan 1. `_get_start_date_elements()` still prefers the explicit `deadline_start_date` (unchanged behavior for calendar-anchored VAT returns), and otherwise derives the day/month from `company.compute_fiscalyear_dates(today)['date_from']`. Steps to reproduce: Accounting: Settings and set Fiscal Year End to July 31 Reporting: tax reports and set it to Year and the year to 2024 Top left there is the Return, click on it and set: - Opening Date: 08/01/2025 - Fiscal Year End: 31 July - VAT Periodicity: Annually Creat a new tax return and chose any type and set: - start date 08/01/2024 - end date 07/31/2025 opw-4990676 Forward-Port-Of: odoo/enterprise#94325
Partial payments made from the invoice payment widget will no longer trigger an automatic write-off just because the remaining amount is within tolerance. Invoices now stay marked as partially paid until the remaining balance is intentionally handled, helping users keep more accurate payment status and control.
Original PR description
Prevents the system from creating a write-off and marking an invoice as 'Fully Paid' when a partial payment (within tolerance) is reconciled from the invoice form. The invoice status will now correctly remain 'Partially Paid', giving the user control over the remaining balance. task-5114658 Forward-Port-Of: odoo/enterprise#95899
Mobile self-order customers now see the correct order after placing a new order, instead of being shown a previous paid order. Receipts downloaded after refreshing the page also keep their payment details, preventing confusing missing payment or negative change lines.
Original PR description
This PR contains 2 small fixes for mobile self order: - **[FIX] pos_self_order: wrong order on confirmation screen** Steps to reproduce: 1. Configure a Self Order POS to use QR menu + ordering 2. In…
This PR contains 2 small fixes for mobile self order:
- **[FIX] pos_self_order: wrong order on confirmation screen**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. In the mobile menu, make an order and confirm
3. The confirmation screen shows order S001, pay at the counter
4. In the POS, pay and validate the order
5. In the mobile menu, make another order and confirm
Expected behaviour:
- The confirmation screen shows order S002, pay at the counter
Actual behaviour:
- The confirmation screen shows order S001, already paid
The cause of this is that `selectedOrderUuid` is cleared whenever the
`getUserDataFromServer` method is called, even if the server doesn't
return an order to replace it with. The self order service then tries
to find the current order and takes the previously paid order instead of
the new order.
To fix this, we simply don't clear `selectedOrderUuid`. It will still be
overwritten if the server does return new order data.
- **[FIX] pos_self_order: incorrect receipt after refresh**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. Make an order in the mobile menu
3. Pay and validate the order in the POS using the 'Card' payment method
4. Go to 'My Orders' in the mobile menu, and download the receipt
5. Observe the correct 'Card' payment line is shown on the receipt
6. Refresh the page
7. Download the receipt again
Expected behaviour:
- The downloaded receipt is the same as the first one, with the 'Card'
payment line.
Actual behaviour:
- The downloaded receipt has no payment lines, so it just shows a
negative 'Change' line at the end.
The cause of this issue is that the payment lines and payment methods
used to render the receipt were not being persisted in the indexed DB.
The fix is simply to add these models to the data service options so
that they also get saved locally.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232314
Forward-Port-Of: odoo/odoo#231910Fixed an issue where saved payment methods were not offered when registering payment on a later invoice for the same user. The payment process now uses the invoice's linked customer rather than the company contact, helping payments be completed without manual workarounds.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#232134 Forward-Port-Of: odoo/odoo#230105
Opening the Helpdesk ticket list when there are no tickets now works correctly instead of crashing. This improves stability for teams starting with an empty ticket queue or after clearing all tickets.
Original PR description
When accessing the Helpdesk ticket list view with zero tickets, the view previously crashed due to improper handling of folded sample data. This commit ensures that sample data folding does not trigger errors when the view is empty, improving overall stability. Steps to reproduce: 1. Navigate to Helpdesk > Teams > Tickets. 2. Ensure there are no tickets. 3. Switch to list view. Task-4971510 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226253
Point of Sale now applies minimum-quantity pricelist rules based on the total quantity of the same lot-tracked product, even when items are split across multiple lots. This ensures customers receive the correct price or discount at checkout and avoids undercharging or overcharging caused by separate lot lines.
Original PR description
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot…
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should). **STEP TO REPRODUCE** 1. install pos 2. create a lot tracked product 3. create a pricelist rule for the product, with a price based on min qty 4. from the pos, order the min qty but split it accross multiple lots 5. price will not takethe rule into account **CAUSE** Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually. **FIX** For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked. **REMARK** Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db. opw-4751920 Forward-Port-Of: odoo/odoo#232276 Forward-Port-Of: odoo/odoo#219110
This update fixes multiple small issues affecting website content, Indian e-Waybill printing, payments, mail cleanup, SMS validation, and IoT certificate handling. It improves day-to-day reliability by preventing printing failures, stale activity records, unnecessary certificate requests, and regressions in website sitemap language behavior.
Original PR description
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
New user signatures now place the user's name in a layout block that avoids unwanted extra spacing. This prevents line breaks in the editor from duplicating paragraph spacing, making default signatures look cleaner for new, demo, and admin users; existing user signatures are not changed automatically.
Original PR description
Prior to this commit, the default signature for users was their name wrapped in a `p`. This is not what we want, because a `HTMLParagraphElement` natively has a margin-bottom, and when a user creates a newline from a paragraph in the HTML Editor, the paragraph is cloned. After this commit: the user name is wrapped in a `div` instead. This does not update existing users signatures. To switch to a `div`, they will have to select the desired lines, and change their type from "Paragraph" to "Normal". Demo and admin users are updated too, because lxml `document_fromstring` would wrap text content in a `p` during record creation. task-5149570
Demo user signatures for Laurie Poiret and Maggie Davidson now use a layout that avoids unwanted extra spacing. This reduces manual cleanup when using or adapting these sample records.
Original PR description
Adapt signatures for Laurie Poiret and Maggie Davidson so that they are wrapped in a `<div>` instead of a `<p>`, because lxml `document_fromstring` would wrap text content in a `p` during record creation. Ideally all user data records should do that for their signature field. This commit only updates the main ones. `p` in a signature is not desired because it has a native margin-bottom, and the user has to change it to a `div` in order not to have it. Making `div` the default container for signatures simplifies that tedious process. task-5149570
This fixes an issue where Swiss payroll pay run generation could fail or be blocked when users worked across multiple companies. It helps payroll teams generate pay runs reliably in multi-company setups without unnecessary access problems.
Original PR description
Forward-Port-Of: odoo/enterprise#97503
This fixes an eLearning display issue where highlighted text in course articles appeared correctly in normal view but disappeared in fullscreen mode. Learners now see the same formatted content in both viewing experiences, improving consistency and readability.
Original PR description
**Steps to reproduce:** - Go to eLearning course on the website - Edit an article - Add the highlighting effect on the text - Save the changes - The text is properly displayed in normal article - Go to the fullscreen version - The highlighting is not present in this version **Issue:** This is an ordering issue caused by the dynamic rendering of fullscreen slides. When in normal mode, the content is initialized and then the `TextHighlight` widget is started. But the rendering of the slides in fullscreen mode is delayed and occurs after the widget is applied. **Fix:** Recreate and restart the widget on `_renderSlide` in the `slides_course_fullscreen_player`` opw-4978798 related: https://github.com/odoo/odoo/commit/f64c9f27f1a9106bc009ad2f696845f2c5c58066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232209 Forward-Port-Of: odoo/odoo#225150
Spacing was improved for event website menu options shown in debug mode, making labels and fields easier to match. This reduces confusion for administrators configuring event pages and event types.
Original PR description
The PR fixes the display of the fields displayed when the debug mode is activated and used to show buttons in the menu of event website pages. Previously, it was difficult to determine what were the labels of the fields. To make it clearer, the spaces between the label-field couples have been increased. Task-4750239 Forward-Port-Of: odoo/odoo#214135
Fixed an issue that could cause an error when refreshing appointment availability for bookings assigned to a staff member. This improves reliability for users managing appointment slots and prevents interruptions during scheduling.
Original PR description
This commit fixes an issue where the refresh with appointment based on staff user was raising a traceback as it also tried to compute the max capacity possible. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5118860 Forward-Port-Of: odoo/enterprise#97634 Forward-Port-Of: odoo/enterprise#95862
A previously disabled automated test for website editor animation options has been re-enabled after its timing issue was resolved. This helps ensure hover-based animation settings remain reliable without changing the user-facing website experience.
Original PR description
In commit 22c4ecff46d34a37549dfa3feda8cfe12cf00407, the test was disabled because it had non-deterministic failures It was failing because the preview (that was made by the hover before the click) took sometimes long enough that `waitForEndOfOperation` was executed before preview finished, so it only waited for the end of the preview, not the end of the commit made by the click. Thus the `waitDomUpdated` that followed did not wait for the update caused by the commit (thus had nothing to wait for). And the assertions failed as the sidebar was not updated yet. In order to wait enough, the helper `waitSidebarUpdated` has been introduced in commit 143c40bdb7eac35126d51ac85fb89e37ecb75f13. In this commit, we just un-skip the test (which was updated to use that helper) task-4367641 Forward-Port-Of: odoo/odoo#226814
Vendor bill XML imports for Ecuador now correctly include discounts when a discount value is present in the file. This prevents understated discounts and helps keep imported supplier bills aligned with the original invoice totals.
Original PR description
In the l10n_ec_edi localization, XML files that include a <descuento> (discount) tag do not apply the discount when imported into Odoo. - Create an invoice with a discount and export the XML. - Re-import the XML as a vendor bill — the discount is missing. This commit fixes the issue by computing and importing the discount percentage from the <descuento> tag. opw-5137439 Forward-Port-Of: odoo/enterprise#96712
This fixes a test setup issue where a website form tour could stall because the editor component was not loaded in the test bundle. The change makes the test helper check that the editor is available before applying its setup, improving reliability of automated validation without changing user-facing behavior.
Original PR description
Steps to reproduce
==================
Run the test test_contactus_form_email_stay_dynamic
The ready "odoo.isTourReady('...')" code was always falsy
Cause of the issue
==================
website_form_editor.js import @html_editor/../tests/tours/helpers/editor
it itself import @html_editor/editor
Since the editor is not part of the bundle when loading the tour, nothing is loaded
Solution
========
As it not that easy to include the editor in the web.assets_tests bundle,
we check if the editor module is present before patching it.
When actually running the tour, it will be present.
runbot-231561
Forward-Port-Of: odoo/odoo#230595This update fixes inconsistencies in employee payroll fields and makes payroll API tests independent from demo data. It helps improve build reliability and reduces the risk of payroll-related validation issues in Australian localization workflows.
Original PR description
- Remove test dependency on demo data - Fix inconsistency on employee fields runbot-231643 runbot-230983
Picking operation reports now show products grouped in the expected location order, such as stock shelves or warehouse areas. This makes printed or viewed operation details easier for warehouse teams to follow and reduces confusion during receipts, deliveries, and other stock movements.
Original PR description
Steps to reproduce: - Create an operation (Receipt, Delivery, etc..) - Add move lines with different locations (WH/Stock, WH/Stock/Shelf 1, etc..) Issue: Products are not sorted based on picking operation's location. Iterations on the picking operations were on the move_line directly. In 18.2, it was changed to iterate on the move itself, but the sorting was disregarded therefore it was added again with some modifications to cope with the new iterations. The change was made on this PR: See https://github.com/odoo/odoo/pull/152280 Task: 4570203 (Unreleated but addressed on this task) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Planning and Timesheet Analysis report now calculates planned and remaining hours using each employee's own working schedule rather than assuming a standard Monday-to-Friday week. This gives managers more reliable capacity and workload figures for employees with part-time or non-standard calendars.
Original PR description
To reproduce: ============= - set the company calendar to 40h/week (Mon to Fri) - create an employee with a 32h/week working schedule (doesn't work on Fri) - on planning app, create a shift for this employee for ex from 01/09 to 15/09 with 2h allocated - go to Planning / Timesheet Analysis report and check report for this employee on september -> planned hours and remaining hours are wrong Problem: ======== when querying the data for the desired period, we divide the allocated hours by the number of weekdays (Mon to Fri) in the period, but we should divide by the number of working days according to the employee's working schedule Solution: ========= we compute the number of working days based on the resource calendar of the employee and use this number to compute the planned hours and remaining hours opw-5008066 Forward-Port-Of: odoo/enterprise#95115
This fixes a Belgian SEPA payment file issue where a required payment reference field could be left empty. The change helps banks process generated payment files correctly and reduces failed or rejected payment batches.
Original PR description
The XML of the spea file in format pain.001.001.03 in l10n_be has a missing EndToEndId tag. - Configure the bank to use the pain.001.001.03 sepa xml format. - Generate a payment using sepa. Create a batch for this payment and validate. - The resulting xml has an empty EndToEndId tag. Commit fa08eac141956141bc12c1d5619bd57f487c36e9 responsible - investigate opw-5150525
This fixes an error that could prevent users from opening Timesheets and Planning Analysis from a project. The change makes the report handle missing currency information safely, improving reliability for teams using timesheet forecasting and sales planning.
Original PR description
### Issue: A traceback occurs when opening Timesheets and Planning Analysis. #### Steps to reproduce: 1. Create a database with `project_timesheet_forecast_sale` installed. 2. Create a project and open the three-dot menu. 3. Click on `Timesheets and Planning Analysis`. ### Cause: The error occurs because `currencyIds` is undefined. This issue was introduced by #224667. ### Solution: Add a safe access check for `currencyIds`. opw-5176269
Canned responses included in the Mail app setup and demo data are now shared with the appropriate user group. This ensures users can see and use the default OdooBot responses as intended.
Original PR description
**Description of the issue this PR addresses:** Modify Canned Response master and demo data **Current behavior before PR:** Before this PR, canned responses created by OdooBot in master and demo data were not shared effectively, so they were not visible to anyone. **Desired behavior after PR is merged:** This PR ensures canned responses created by OdooBot are shared properly, by assigning a user group, ensuring that everyone can see them. task-[5069111](https://www.odoo.com/odoo/project/1519/tasks/5069111) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231976 Forward-Port-Of: odoo/odoo#228006
This fix restores the default cash journal when setting up companies using the Turkey and Jordan accounting localizations. It helps those companies meet local compliance requirements after the journal was previously removed during an accounting interface cleanup.
Original PR description
This commits adds back default cash journal for companies intializing with l10n_tr and l10n_jr. In our efforts to cleaning the UX/UI of accounting (PR #192031 task-4430969) We removed the default cash journal, however, some locatizations, such as l10n_tr and l10n_jo, require them for compliance reasons task-4991218 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#232113 Forward-Port-Of: odoo/odoo#231200
This fix restores missing timing information in IoT driver events so event retrieval works reliably again. It prevents errors that could interrupt real-time device updates and helps keep connected operations running smoothly.
Original PR description
In odoo/odoo#232282, `time` was removed from registered events, leading to `KeyError` when trying to fetch longpolling events. Forward-Port-Of: odoo/odoo#232452
Manual AI-triggered actions now carry the needed record context, so follow-up actions like creating records, scheduling activities, or sending emails actually run. The AI document sorting setup is also easier to use because related tools can be opened directly and new actions are AI-ready by default.
Original PR description
Purpose: -------- Currently, when an AI server action is triggered manually, the child server actions with state != code are not executed. Nothing happens because inside `_run`, the server action is executed on each record obtained by browsing the ids given by the `active_ids` and `active_id` keys in the context, which are not present (it works fine when the action is triggered by an automation because the record info is added in the context in `_process` in base automation). This commits adds the current records info in the context of the ai tools so that these server actions (such as create record, create activity or send mail) are now executed). Task-5107876
Point of Sale settings now show the EPOS printer test button whenever EPOS printing is enabled, even before an IP address has been saved. If no IP address is set, users receive a clear notification prompting them to add it, reducing confusion during printer setup.
Original PR description
Currently it is only visible if the epos ip is set, but if the user 1) Opens the settings 2) Sets the epos ip 3) Doesn't defocus and clicks on "Save" He never gets to see the test button. This PR makes the "test" button for epos printers always visible in the PoS settings if the "epos" setting is activated. If the ip is not set it displays a notification asking to set it
This fixes a flaky automated test by ensuring each breadcrumb navigation step waits for the expected page label before continuing. It helps avoid false test failures caused by timing differences on slower or busier machines, improving confidence in release validation.
Original PR description
Depending on scheduling / machine load, it's possible for the "Back to the sale order" step to run before the "Back to the task" step's effect have completed, and thus trigger on the exact same breadcrumb, leading to *not* returning to the SO and on to not finding the `order_line` field and a failure on the next step. Fix this specific instance of breadcrumb confusion by checking that the breadcrumb label is the one we expect as precondition. https://runbot.odoo.com/odoo/runbot.build.error/231766
Users can now turn debug mode on or off from the command palette while using the Documents app. This ensures the app uses the latest navigation setting instead of an outdated value, so the URL updates correctly.
Original PR description
Issue: In the documents app toggling debug mode through the command palette (ctrl-k) does not work. Manually editing the URL works as expected. Cause: A patch on `router.stateToUrl` for the documents app rebuilds the URL to create clean, shareable links. When doing so, it attempted to preserve the debug status by referencing the global `odoo.debug`. This global object did not reflect client-side state changes. The command palette correctly provides the intended future state to the router. The patch was ignoring this incoming state and using the outdated global value, causing the generated URL to be incorrect. Solution: Modify the patch to use the `state` argument provided to `stateToUrl`, which contains the correct, up-to-date information for the navigation. Task-5095056 Forward-Port-Of: odoo/enterprise#96275
Fixes an issue where changing the shape of a GIF image in the website/editor could trigger an error instead of applying or safely skipping the change. This improves reliability for users editing pages with animated images.
Original PR description
Steps to reproduce: =================== 1- Add an image of type GIF. 2- Try to change its shape. → Traceback occurs. Cause: ====== The `process` image function can return a callback function when GIF…
Steps to reproduce:
===================
1- Add an image of type GIF.
2- Try to change its shape.
→ Traceback occurs.
Cause:
======
The `process` image function can return a callback function when GIF transformation must be skipped:
https://github.com/odoo/odoo/blob/7f95cc6094b914c57b6e36ad072ebb2c9c3b324b/addons/html_editor/static/src/main/media/image_post_process_plugin.js#L78
It can also return an object `{ url, newDataset }`: https://github.com/odoo/odoo/blob/7f95cc6094b914c57b6e36ad072ebb2c9c3b324b/addons/html_editor/static/src/main/media/image_post_process_plugin.js#L224
Only the object case was handled:
https://github.com/odoo/odoo/blob/7f95cc6094b914c57b6e36ad072ebb2c9c3b324b/addons/html_editor/static/src/main/media/image_post_process_plugin.js#L231
As a result, when a function was returned, the image source was set to `null`, because `processed` was a function and didn't have a `url` or `newDataset`, causing a crash here:
https://github.com/odoo/odoo/blob/22c83301337e40699b11621053af627f5bfd505b/addons/html_builder/static/src/plugins/image/image_shape_option_plugin.js#L412
Solution:
=========
Ensure that only the `url` and `dataset` are returned, since the same
function is called elsewhere expecting those values.
opw-5137667
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#231370Fixed an issue in Discuss where inviting someone from a self chat could fail if the related conversation included guest members. This keeps the invitation flow working reliably for users collaborating with guests.
Original PR description
Steps to reproduce: 1. Open Discuss 2. Create a channel/chat with at least one guest member 3. Open self chat 4. Open the `Invite People` 5. Select any user from the invitation list => An error is thrown Cause: To display the `Invite` button text, the code filters thread correspondents by `partner_id`, but guest members have no `partner_id`, resulting in a crash. This PR fixes this issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the mail discussion tools where additional related data could be handled incorrectly unless provided in one specific format. The change makes the system more reliable when loading or displaying mail-related discussion information.
Original PR description
Follow up of https://github.com/odoo/odoo/pull/232266 extra_fields is not necessarily a list, any format supported by _format_fields should be supported.
This fixes an issue where businesses running multiple websites could see pages from the previously visited website after switching to another one. The website now uses the right cache separation so each site shows its own correct content, reducing confusion for visitors and editors.
Original PR description
After this [commit], we had an issue when we had multiple websites and tried to switch from one of them to another, the cached page of the previous one would still be present. task-5152918 [commit]: https://github.com/odoo/odoo/commit/6c8a90ecba45fb99addf1b86fe237fd626fba650
Odoo now blocks account report formulas that accidentally leave an empty account code prefix, which could otherwise include all accounts and duplicate amounts. It also catches invalid aggregation formulas when reports are created or edited, helping businesses avoid misleading financial reports.
Original PR description
Empty account code prefixes in report expressions (e.g., "12 + 13 +") unintentionally include all accounts, which can lead to duplicated amounts. This PR raises a UserError when a newly created or modified expression includes an empty prefix. task-id: 4975559
Users with Belgian reports installed no longer see access errors when the Accountant app is not installed. The affected company fields are now hidden unless users have the right accounting access, preventing disruption in daily use.
Original PR description
This commit fixes the access right problem for `l10n_be_region_id` and `l10n_be_company_type_id` when `accountant` is not installed. When `accountant` is not installed and users have `l10n_be_reports` installed, an access error was raised when these fields were accessed. A group `account.group_account_user` is added to these fields such that they become invisible when when `accountant` is not installed. task-5156687
Point of Sale can now create receipt and payment QR codes directly in the browser instead of relying on the server. This helps stores print receipts with QR codes even when the POS is offline and keeps receipt layouts more reliable.
Original PR description
Import the `qrcode` JS library and render QR codes directly in the browser instead of requesting them from the backend. This allows receipts with QR codes to be generated and printed even when the POS is offline. Problem was that we cannot use `ZXing.BrowserQRCodeSvgWriter();` (which is a library already used in the POS that can generate QR code) because it generates an unpredictable padding, which cause some issues in the receipt layout. task-id: 5060246 task-id: 5060246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228242
Product image lookup scheduling was simplified to avoid duplicate or inefficient background jobs. This makes the process of fetching product images more reliable while keeping overall scheduled task creation efficient across the system.
Original PR description
Remove `_check_image_cron_is_not_already_triggered` because: - It doesn't work in batch mode due to `self.cron_id.id`. - It increases the cost of creating a cron trigger because the reference lookup (`ref`) makes at least one extra query. (We want to keep cron trigger creation efficient since it is used everywhere.) - Because of this constraint, there is an extra commit in `_trigger_fetch_images_cron` that is inefficient and error-prone, serving no purpose. Keep the intended effect of the constraint by removing the existing cron trigger before the new one is created, ensuring the time offset is respected. Forward-Port-Of: odoo/enterprise#97411
Account report formulas now reject newly created or edited entries that leave an account code prefix blank. This prevents reports from accidentally including all accounts and duplicating amounts, improving financial report accuracy.
Original PR description
Empty account code prefixes in report expressions (e.g., "12 + 13 +") unintentionally include all accounts, which can lead to duplicated amounts. This PR raises a UserError when a newly created or modified expression includes an empty prefix. Community and main part of the PR: https://github.com/odoo/odoo/pull/230302 task-id: 4975559
This update prevents reconciliation failures when custom settings change the default type for journal entries. Write-offs created by the reconciliation wizard are now always treated as standard journal entries, avoiding errors about missing partners or incompatible account types.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97130 Forward-Port-Of: odoo/enterprise#97028
Fixed an issue where undoing an auto-reschedule in the manufacturing planning Gantt view could trigger an error. This helps planners safely reverse scheduling changes without interruptions.
Original PR description
When rescheduling workorders in mrp's Planning by Workcenter using Auto-Reschedule mode and then Undo-ing, a bad query error occurs, due to
WHERE "mrp_workcenter"."id" IN ('m', 'r', ...
This comes from web_gantt_reschedule returning something like
{'3': {'date_finished': '2025-10-20 11:43:51',
'date_start': '2025-10-20 09:43:51',
'workcenter_id': 'mrp.workcenter(1,)'}}
Forward-Port-Of: odoo/enterprise#97717UPS shipment requests now send the company and customer VAT information, so commercial invoices generated for international shipments can show the correct tax identifiers. This prevents blank VAT fields on UPS documents and helps businesses meet cross-border invoicing requirements.
Original PR description
**Current behavior:** There is currently no tax information supplied in the UPS shipment request. So, for example, the VAT number section on a commercial invoice generated from a shipment will always be blank. **Steps to reproduce:** - Create a quotation, chose a customer that is not is the same country as your company. - Add a delivery and chose UPS. - Validate the delivery. - Check the invoice generated in the chatter. - The VAT is not in the invoice **Cause of the issue:** The VAT of the company and the VAT of the customer were never given to UPS. **Fix:** The VATs are now added to the UPSRequest class before making the call to the API. As the TaxIdentificationNumber field is depricated, we have to use the new GlobalTaxInformation container, which allows us to specify the tax information about the sender and the shipper. opw-4591744 Forward-Port-Of: odoo/enterprise#82356
Fixes an issue where validating a delivery could miss automatic printing of shipping labels or documents when only one device was connected. The process is simplified so required shipping paperwork is included directly in the validation flow, making warehouse printing more reliable.
Original PR description
The `button_validate` method called clicking "Validate" returns a list of client actions to call. After these clients actions are executed, the page reloads. This reload makes our broadcasted action not to be caught by the client if there is only one connected. Anyway, this flow was overcomplicated and has been simplified overriding the method returning the client actions, adding the "shipping labels" and "shipping documents" to it. Forward-Port-Of: odoo/enterprise#97688 Forward-Port-Of: odoo/enterprise#97462
The web module test for resizable panels was updated to handle a small browser measurement difference introduced in Chrome 140. This keeps automated testing stable without changing how users experience the application.
Original PR description
In Chrome 140, a fix [^0] has been applied regarding the `offsetParent` property with a fixed position element. Due to this fix, a resizable panel's test failed by 1px. As this difference doesn't have a real functional impact, we adapted the test to accept both the pre/post fix values. Note: that it is also related to a clarification [^1] in the CSS spec [^2]. [^0]: https://chromium-review.googlesource.com/c/chromium/src/+/6774502 [^1]: https://github.com/w3c/csswg-drafts/issues/12352 [^2]: https://drafts.csswg.org/cssom-view/#dom-htmlelement-offsetparent Forward-Port-Of: odoo/odoo#232458
Fixed an issue where website pages could remain shifted to the side after hiding a sidebar-style header. This keeps page content properly aligned and avoids a confusing visual layout problem for website editors and visitors.
Original PR description
Steps to reproduce the issue: - In edit mode, change the header template to use the "Sidebar" header (=> since it is a sidebar, the page content is shifted to the right) - Go to the theme tab and toggle the "Show Header" option so the header is removed => Bug: the page content is still shifted as if the sidebar were still present. This happens because the page still has padding-left for the header, although there's no header. task-5131064 Forward-Port-Of: odoo/odoo#231487 Forward-Port-Of: odoo/odoo#229860