Tuesday, July 15, 2025
23 changes · saas-18.4
Enhancements to existing features
The IoT Box now sends device information to the database earlier in the connection process. This helps speed up setup and reconnection by making device details available before the system checks for code updates.
Original PR description
We increase connection speed by sending devices information to the database before checking out the code on the IoT Box. This PR is a forward port of a part of odoo/odoo#213386.
Point of Sale order lines now show the unit of measure, such as kg, next to each quantity on the customer display. This supports EU weighing scale certification requirements and helps customers better understand weighted product purchases.
Original PR description
This commit adds the the unit e.g. 'kg' to each orderline next to the quantity. The reason for this change was to satisfy the requirements of the LNE to allow Odoo to be certified for weighing scales in the EU. task-4869128 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216059 Forward-Port-Of: odoo/odoo#214335
The Point of Sale now checks whether a connected scale still matches its expected certification checksum. If the checksum changes, users are alerted that the POS is no longer certified, helping businesses catch compliance issues before using the scale in sales.
Original PR description
Before this commit, we had the capability to view the current scale checksum by visiting `/scale_checksum`, but no way to automatically flag to the user if it had changed. After this commit, we keep track of the expected checksum and compare it to the current checksum. If they differ, the POS is no longer certified and we show an error to the user. task-4873162 Forward-Port-Of: odoo/enterprise#88622 Forward-Port-Of: odoo/enterprise#87726
Resolved issues and error corrections
The website/page editor now remembers and shows custom colors that are already used, making it easier for users to keep designs consistent. It also correctly recognizes SVG illustrations so related color options remain available when selecting them.
Original PR description
Since the introduction of `html_builder`, the colorpicker does not give access to already used custom colors. This commit obtains all used colors by default for builder colorpickers. task-4367641
This fix keeps the website login page stable while it is being edited, including in Chrome when saved passwords trigger unexpected browser events. It also prevents users from accidentally leaving the login page or submitting the login form while the editor is open, reducing interruptions and errors during website updates.
Original PR description
Description of the issue/feature this PR addresses: - Fix traceback when the user click with the mouse on the login page - Prevent changing page by clicking on one of the buttons of the login form while the Editor is open - Prevent clicking "Login" while being in the Editor app, fixing a traceback Desired behavior after PR is merged: - The login page should not crash when the user click with the mouse - The user shouldn't be able to leave the login page while he is editing the login page - The user shouldn't be able to click login while being in the Editor app --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale receipts now show the required Belgian blackbox validity and refund information more clearly. Duplicate date and address details were removed because they are already included elsewhere on the receipt, helping keep receipts accurate and easier to read.
Original PR description
Since this revmap of the POS receipt (https://github.com/odoo/odoo/pull/201105), we have to make some changes on the receipt when using `pos_blackbox_be`: - Display if the ticket is valid or not (Pro Format) & increase its size. - Display if the order was a refund or not. - No need to display the `blackbox_date` since we now have the `date_order` inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml``. - No need to display the `order.company.street` since the whole adress is now displayed inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.xml`. task-id: 4848882 enterprise PR: https://github.com/odoo/enterprise/pull/87759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214394
This fix ensures website editing handles every mega menu on a page, including separate desktop and mobile menu versions. It prevents menu editing behavior from targeting only the first menu, making sites with multiple mega menus easier and more reliable to manage.
Original PR description
During the refactoring in [1], the `MegaMenuDropdownEdit` interaction was added in order to manage the mega menus behavior in edit mode. However, the code was made by considering that only one mega…
During the refactoring in [1], the `MegaMenuDropdownEdit` interaction was added in order to manage the mega menus behavior in edit mode. However, the code was made by considering that only one mega menu would be present in the navbar, which is not the case. Indeed, we can add as many mega menus as needed in the menu editor. Moreover, even with only one mega menu on the page, there are still two toggles, since there is the mobile navbar equivalent. This commit therefore fixes the code to consider all mega menus and not just the first one. This commit also improves the code activating the mega menu options when opening it. Indeed, it was simulating a click on the mega menu, relying on the fact that the `builderOptions` plugin will listen to it, but this solution is hackish. Instead, when clicking on a mega menu toggle, there is now an explicit call to that plugin shared functions: - `updateContainers` when showing it, and - `deactivateContainers` when hiding it. [1]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
This fixes a problem where the link editor popover could open and instantly close when users added a link from the full composer, such as while logging a note in CRM. Users can now select text and add links reliably without the editing tool disappearing.
Original PR description
Issue: currently, the linkpopover get closed as soon as it is open, due to fact that autofocus hooks do not work as expected when working inside full composer we have faces same issue previously, fixed by odoo/odoo@99a01a66e3bda18a7655581ddc5c768ed92c14d1 but issue arises again after odoo/odoo@deaeecc54a10519656338546c18eb091ac84ff4e overrides the the original component and relies on `useAutofocus` again. Step to reproduce: - open crm - open a record and click on "Log note" -> full composer - enter some text - select it and try to add link form toolba observation: The LinkPopover opens and closes immediately Fix: - we manually focus on the input instead of using autofocus opw-4874775 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217029
Invoice summaries now show “Reversed on” when an invoice is reconciled through a credit note instead of implying it was paid. This prevents users from mistaking reversals or credit notes for actual bank or cash payments.
Original PR description
Before this PR: -------------------------------------------------- In the invoice summary, the label `Paid on ...` was always shown whenever the invoice was reconciled, regardless of whether the reconciliation was made through an actual payment (bank/cash) or through a credit note or journal entry. This led to misleading information: - Credit note reconciliation (partial or full) showed `Paid on ...` - Even though no real payment occurred - Full reversals correctly showed status 'Reversed', but the label still said `Paid on ...` After this PR: -------------------------------------------------- - The label is now shown as `Reversed on ...` when the reconciliation is done with credit note. - This avoids confusion and better reflects the actual accounting status of the invoice This change ensures users are not misled by incorrect payment indications when only a reversal or credit note is involved. task-4920349 Forward-Port-Of: odoo/odoo#217477
Fixes an issue in the website/page builder where clicking inside a newly added block too quickly would be ignored. The click is now replayed once the editor is ready, so users can select and edit new content without waiting while still preserving safe undo behavior.
Original PR description
Steps to reproduce: 1. Add a block into your page 2. Click immediately inside => The block is not selected, you have to wait the end of the invisible loading element to be able to click. This was not the case in 18.3. While this commit does not remove the delay, it catches clicks made while the iframe is blocked and redispatches them once it is freed. This delay is needed to avoid rogue steps and conflicts in the history: accepting the click immediately creates a snapshot of the selection, which could appear in the middle of the mutations done by dropping the snippet. If you then make some change and want to undo it, it would be impossible to revert to a stable state. [task-4367641](https://www.odoo.com/web#id=4367641&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form)
Replacing images, videos, or icons in the website editor now consistently activates the relevant editing options, whether users double-click or use the replace action. Icon replacements also keep their correct format, reducing unexpected layout or styling changes while editing pages.
Original PR description
When replacing a media by double-clicking on it, the new media options were not activated. When using the "replaceMedia" option, they were activated but the way it was done was not correct. Another…
When replacing a media by double-clicking on it, the new media options were not activated. When using the "replaceMedia" option, they were activated but the way it was done was not correct. Another issue also happens when replacing icons: if they were replaced by double-clicking, the tag name was preserved (so an `<i>` stayed an `<i>` and a `<span>` stayed as a `<span>`), but with the "replaceMedia" option, the tag was always becoming a `<span>` (because we were replacing the node with the media dialog result manually). This commit fixes that by uniformizing the "replace a media" flow. More precisely, the `replaceMedia` shared function was added in the `media_website` plugin and it is used by both the double-click handler and the "replaceMedia" option. It simply uses the `openMediaDialog` shared function, where everything is correctly managed (so the icons now keep their tag). In order to activate the replaced media options, a new resource `on_replaced_media_handlers` is now dispatched in `openMediaDialog`. The resource then simply asks to update the containers target with the replaced media. Another still unused `on_added_media_handlers` resource is also dispatched when a new media is added. It was simply done to have the access point/hook (as it was needed before the refactoring). This commit also takes the opportunity to clean the `media_website` plugin code, by factorizing redundant code, removing unused variables, formatting lines and adding some doc. For the reference, the commit adding the "Double-click to edit" tooltip was commit [1] and the refactoring is in commit [2]. [1]: ce533be3f71e08c06fbe0c1fdbbe9fe7f0545dc8 [2]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
Fixes an error that could occur when users adjusted reordering quantities for manufactured products after changing a related manufacturing order date. This helps keep replenishment workflows stable and avoids interruptions for inventory planners.
Original PR description
**Steps to reproduce:** - Install MRP module - Create a new product tracked by quantity and set its route to manufacture - Create a new BoM and set the Manuf. Lead Time to 2 days - Create a new…
**Steps to reproduce:**
- Install MRP module
- Create a new product tracked by quantity and set its route to manufacture
- Create a new BoM and set the Manuf. Lead Time to 2 days
- Create a new reordering rule, set the minimum quantity to 2 and click on order
- Navigate to the newly created manufacturing order and set the scheduled date to the next day
- Try increasing the minimum quantity on the reordering rule
- `KeyError` is triggered
**Issue:**
When computing `unwanted_replenish` field, the `_quantity_in_progress` function builds a dictionary (`res`) created using the IDs of current 'stock.warehouse.orderpoint' records as keys.
During `onchange()` process the keys can be set as temporary IDs (`NewID` class). But, when evaluating domains, `orderpoint.id` is returned as the real ID (`orderpoint._origin.id`), which make the index lookup fails when checking value of existing model:
```
self.id => NewId origin=6
res => {<NewId origin=6> : 0.0}
orderpoint.id => 6
res[orderpoint.id] => KeyError
```
This mismatch occurs due to the implicit conversion when using `NewId` inside domain filters with `.ids`. In which case they return the elements which matched the `_origin` id (for previous existing records). Domains will return the matching records with real IDs, but the dictionary still expects `NewId` as key.
**Fix:**
Ensure safe lookup by explicitly checking whether the dictionary has either the real ID or the `NewId` wrapper.
opw-4729116
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#209505Fixes an error that occurred when creating an employee from a recruitment applicant who already had skills recorded. This helps HR teams complete the hiring workflow without interruptions after a contract is signed.
Original PR description
…plicant
Step to reproduce:
------------------
1- Go on Recruitment > All Applications
2- Create an applicant with some skills
3- Click on contract signed in the statusbar
4- Click on create Employee button
You will have a traceback
Reason:
-------
The applicant's employee is not created yet and some employee_skills are already given.
Solution:
---------
Transform vals['employee_id'] into vals.get('employee_id', False)
task-4931239
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-prThe Point of Sale product screen now adjusts the number of products per row on mobile devices instead of forcing three items per row. This prevents product lists from overflowing and makes browsing products smoother for mobile users.
Original PR description
- This commit fixes the issue of vertical scrolling on mobile devices, now we responsively display the correct number of product lists by line, instead of forcing the display of 3 per lines. - Also add a test to ensure that the product list does not overflow on mobile devices. task-id: 4922341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218764
This change prevents users or configuration changes from removing or narrowing important activity types that automated business flows rely on, such as calls, meetings, approvals, leave actions, fleet contracts, banking synchronization, tax closing, and payroll deferrals. It also makes activity creation more resilient when activity types are missing or assigned to the wrong model, reducing crashes and broken workflows across apps.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/odoo#218705
Forward-Port-Of: odoo/odoo#156731Point of Sale users on multiple devices will now see the expected alert when a register is being closed from another device. This helps staff avoid confusion and keeps shared POS sessions synchronized during closing.
Original PR description
Previously, the “closing session” notification was not correctly handled in the frontend. Steps to reproduce: - Open a POS session on two devices - On Device 1: Close the Register. - On Device 2: Nothing happens. A dialog titled “Closing session” should appear, but it does not. After this commit, the notification includes the correct parameters, allowing the frontend to handle the “closing session” event properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218391
Restores a missing receipt registration flow for Belgian POS blackbox setups. This ensures kiosk transactions send the required blackbox response back to the server, preventing receipt handling issues in those flows.
Original PR description
- In this commit (f5cea73183c0a25039b44e8a16341095431de029), the `registerReceiptWeb` action was removed from the `pos_blackbox_be` module. This action was useful to call `registerReceipt` and then call `send_blackbox_response`. - This commit restores the `registerReceiptWeb` action in the `BlackBoxDriver`, ensuring that when calling it, we send the blackbox response to the server (which is used for Kiosk flows). task-id: 4901299
This fixes how the Belgian POS blackbox reads status information from serial-connected fiscal devices. It helps prevent incorrect responses from blocking or disrupting point-of-sale fiscal operations.
Original PR description
As serial drivers use a different way of providing status, we need to check for the right value in the blackbox response. Community PR: odoo/odoo#218203
Belgian POS receipts now show required certification information more clearly, including whether a ticket is valid and whether the sale is a refund. Duplicate date and address details were removed because they are already shown elsewhere on the receipt, keeping receipts compliant and easier to read.
Original PR description
Since this revmap of the POS receipt (https://github.com/odoo/odoo/pull/201105), we have to make some changes on the receipt when using `pos_blackbox_be`: - Display if the ticket is valid or not (Pro Format) & increase its size. - Display if the order was a refund or not. - No need to display the `blackbox_date` since we now have the `date_order` inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml``. - No need to display the `order.company.street` since the whole adress is now displayed inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.xml`. task-id: 4848882 community PR: https://github.com/odoo/odoo/pull/214394 Forward-Port-Of: odoo/enterprise#87759
When assets are migrated into Odoo with depreciation already recorded in a previous system, Odoo now includes that imported amount in depreciation totals and reports. This gives businesses accurate asset values and depreciation schedules after migration, avoiding understated cumulative depreciation.
Original PR description
Working:- - When migrating from any other accounting software to Odoo,in `Depreciated Amount(already_depreciated_amount_import)` field we put asset's depreciated amount till then(before migration).…
Working:- - When migrating from any other accounting software to Odoo,in `Depreciated Amount(already_depreciated_amount_import)` field we put asset's depreciated amount till then(before migration). This depreciation is recorded in each account when starting in Odoo(the original balances) and in Odoo creating Journal Entries are skipped for this imported depreciated amount. Example:- - Consider Asset with Original Value: \$10,000.00, Acquisition Date: 01/01/2020, Method: Straight Line, Duration: 10 Years, Computation: No Prorata. - Now according to our computation this asset will depreciate \$1000.00 for the years 2020 to 2029 each, and Journal Entries would be created on 31st December each year. - Now someone migrating from other software to Odoo in the year 2025 will put Depreciated Amount: \$5,000.00 . - Now Odoo will create Journal Entries for only years 2025 to 2029 and skip creating Journal Entries for the years 2020 to 2024 as these entries are created in previous accounting package and are recorded in original balances while migrating. Before this commit:- - In Depreciation Board, Cumulative Depreciation starts from \$1,000.00 for the year 2025 and goes till \$5,000.00 for the year 2029, ignoring imported depreciated amount. - Depreciation Schedule report displays constant \$5,000.00 as depreciated value for the years 2020 to 2024. After this commit:- - In Depreciation Board, imported depreciated amount is added in Cumulative Depreciation, so it starts from \$6,000.00 for the year 2025 and goes till \$10,000.00 for the year 2029. - In Depreciation Schedule Report, `_simulate_imported_depreciation` method will modify report values to simulated imported depreciation amount and skipped Journal Entries. task-4864528 Forward-Port-Of: odoo/enterprise#90214 Forward-Port-Of: odoo/enterprise#88127
This fix ensures that Peruvian point-of-sale refunds for invoiced orders show the required reason dialog before continuing. It prevents staff from being sent to the wrong screen and helps keep the refund flow compliant and consistent.
Original PR description
Steps to reproduce - install `l10n_pe_edi_pos` module - open a pos session - create a order, when checking out, tick `invoice` checkbox - pay and complete the order - go to order menu (present in…
Steps to reproduce - install `l10n_pe_edi_pos` module - open a pos session - create a order, when checking out, tick `invoice` checkbox - pay and complete the order - go to order menu (present in navbar) - select the previously completed order, apply for refund Observation: you are navigated to Order screen Expectation: A dialog for reason should be open first Issue - after this commit odoo/odoo@3a09ea7 and odoo/enterprise@e3e84bb account_move field is used instead of `invoiced` state of order. But the `account_move` field is always undefined. This is due to fact that when pos_order is fulfilled from `syncAllOrders` function, a call to `missingRecursive` is made, as `account.move` model is never loaded, it is unable to link it to appropriate model and results to undefined Fix - use `order.raw.account_move` instead of `order.account_move` Note: `account.move` is loaded from saas-18.3 by https://github.com/odoo/odoo/pull/201528 opw-4744785 Forward-Port-Of: odoo/enterprise#87283
This update prevents users from deleting or changing key activity types that several business workflows rely on, such as calls, approvals, tax closing, bank synchronization, payroll deferrals, and document uploads. It also makes related processes more resilient when activity types are missing, reducing crashes and workflow interruptions across apps.
Original PR description
Master data protection ====================== In general, be defensive with activity types: avoid crash when activity type has been removed, try to gracefully recover from non existing data, protect…
Master data protection
======================
In general, be defensive with activity types: avoid crash when activity
type has been removed, try to gracefully recover from non existing
data, protect types linked to business code that should not be unlinked
or changed from model.
Introduce a generic way to mark some activity types as master data
* model is fixed and should not be modified, because it is linked
to specific flows e.g. todo should be generic;
* data should not be unlinked, because it is used in automated flows
like plans, business code, ... and cannot easily be replaced;
Mail: make "Call", "Meeting" and "Todo" activity types master data users
cannot remove as they are required in various flows: fleet, plans,
voip, ... Also force their model to be False (aka be cross model).
Mail: make "Warning" and "Upload document" activity types in addition
to "Call" and "Todo", always cross model. As they are used in various
apps it should not be specific to a model.
Hr holidays: prevent from modifying leave activity types, as they are
used in business flows and in automated code.
Fleet: prevent from modifying contract activity type (same reason).
Account Online Synchornization: make "Bank Synchronization" master
data as business behavior dependso on it. Also fix model used for
the type.
Account reports: make "Tax Closing" master data as business flow
depends on it.
Approvals: make "Approval" master data as business flow depends on it
and it is not easy to remove it in their usage.
Hr Payroll: make "Leaves to defer" master data as business flow
depends on it.
Voip: make "Call" activity type master data users cannot remove as it
is required in various flows of VOIP. Also force its model to be False
as it is used in various models and should not suddenly be limited to
a given model. Done in community, as activity is defined in 'mail'.
Studio: make "Approval" master data as approval flow depends on it.
Calendar: fix activities creation
=========================
Current event creation tries to create activities. However code coming
from https://github.com/odoo/odoo/pull/72043 seems quite broken: it tries to find if the
target model accepts activities, but does not by browsing the wrong
model with wrong ids ... which globally turns off activity creation.
This fix rewrites a bit code creating activities when creating an event so
that
* check activity support on the right model;
* it uses the right model on activity type: otherwise you may end up with
models that do not match between record and activity type;
* remove useless (or wrong) code trying to browse 'model ids' on a given
model;
* we now correctly check for activity inheritance using 'is_mail_activity'
field on IrModel;
Task-3777606
Forward-Port-Of: odoo/enterprise#90117
Forward-Port-Of: odoo/enterprise#58164Rental combo products now correctly show available rental dates when stock restrictions apply. This prevents customers from seeing every date as unavailable, reducing blocked online rental sales and customer confusion.
Original PR description
Issue: - Create a rental product (with a rental pricing), - Make it storable and don't allow out-of-stock orders, - Now make it a combo product, - Add a rental combo choice (to be able to save it), - Go to the product's page on eCommerce, - Issue: all dates are unavailable. Cause: The date range picker only relies on `allow_out_of_stock_order` to know whether to compute rental availabilities (but not on `is_storable`). Fix: Also rely on `is_storable` to know whether to compute rental availabilities. opw-4846084 Forward-Port-Of: odoo/enterprise#90116 Forward-Port-Of: odoo/enterprise#90084