Daily updates from Odoo
Wednesday, November 12, 2025
135 changes
14 changes
Resolved issues and error corrections
This fixes an access issue that prevented some Recruitment administrators from sending referral campaigns when they did not have Employee access. The change ensures the right users can complete this common recruitment action smoothly.
Original PR description
STEP TO REPRODUCE:
------------------
1- Give to Marc Demo the right : Recruitment / Administrator (be sure he doesn't have any right on Employees)
2- Log as Marc Demo
3- Go to Recruitment
4- Click on the three dots in kanban card
5- Click on Referral Campaign
6- Click on Send
You will have an access error
This user (with these groups) should be able to send a referral campaign
task-5082344
Forward-Port-Of: odoo/enterprise#98773
Forward-Port-Of: odoo/enterprise#96746The upload button in accounting dashboards could be accidentally dragged out of place. This update locks the button in position so the interface stays stable and easier to use.
Original PR description
Issue: - In the dashboard, the upload button (purchase journal and others) could be dragged. - This caused unintended movement of the upload UI element. Fix: - Added `draggable=false` to the upload button element. - Ensures the button remains fixed and cannot be dragged around. TaskID-5114617 Forward-Port-Of: odoo/odoo#235086 Forward-Port-Of: odoo/odoo#229013
Updated a purchase-related test so it accepts the error type now returned by PostgreSQL 18. This keeps automated test runs stable after a database behavior change, without affecting customer-facing purchase features.
Original PR description
Apparently in pg18 a standard-compliance fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted…
Apparently in pg18 a standard-compliance
fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted `FOREIGN_KEY_VIOLATION`. One such case is specifically being tested for by `test_purchase_order_line_without_uom`, leading to this test failing systematically when running pg18:
psycopg2.errors.RestrictViolation: update or delete on table "uom_uom" violates RESTRICT setting of foreign key constraint "purchase_order_line_product_uom_id_fkey" on table "purchase_order_line"
DETAIL: Key (id)=(29) is referenced from table "purchase_order_line".
Update the test to use the more generic `IntegrityError` as it's probably more than sufficient for our purposes. Technically we could pass a tuple of `(ForeignKeyViolation, RestrictViolation)` but it doesn't really seem necessary. And it would require fixing the `_raisesContext` override as currently it is very much *not* compatible with that.
Forward-Port-Of: odoo/odoo#235119A test in the HR module was trying to access employee fields that are not always available on an employee record, which caused a build failure. The test now checks whether each field can actually be accessed before using it, preventing this crash and keeping automated builds stable.
Original PR description
This test had a bug: `self.env['hr.employee']._fields.keys()` may contain fields that do not exist in an `hr.employee` record. Now, employee fields that cannot be accessed are filtered out using `hasattr()`. To avoid further crashes. Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/233942 Bug has been introduced by task-5103739 task-5254322 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes flaky website builder tests related to editing images. It ensures the required image assets load before the tests continue, so results are consistent and failures no longer happen randomly.
Original PR description
The goal of this commit is to fix the indeterminate tests related to image editing in the website builder. Problem: ===== Some tests related to image editing on the website fail in an indeterminate…
The goal of this commit is to fix the indeterminate tests related to image editing in the website builder. Problem: ===== Some tests related to image editing on the website fail in an indeterminate manner. This test failure is related to the sidebar's async. When selecting an image, the Image options need to fetch certain data (the original image, etc.). The “html_editor.assets_image_cropper” bundle is also loaded. This loading time can exceed 200 ms, causing the test to fail unpredictably. Solution: ====== 1.Preload the “html_editor.assets_image_cropper” bundle and store it in the cache. 2. Use `waitSidebarUpdated` when selecting an image. `waitSidebarUpdated`` will wait until all the data is loaded and the sidebar is updated. This solution is not optimal, but it will make all the tests deterministic. The best solution: ========= We should mock or preload all the data needed for the tests. This change requires adapting the current production code to make it easily patchable to mock, for example, “.text()” on a response to an image fetch. Error: https://runbot.odoo.com/odoo/error/232956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a pivot table with date-based columns is inserted into a spreadsheet, it now keeps the same sort order as in the web view. This fixes cases where the spreadsheet version could appear unsorted because date values were not being translated into the expected display format.
Original PR description
If on the web pivot view we create a pivot with a date/dateTime field in the columns, and sort on one of these columns, the resulting pivot when inserted in a spreadsheet isn't sorted. This was because we didn't normalize the date values in the pivot `sortedColumn`, and we had UTC timestamps `2023-01-01 00:00:00` instead of normalized values `01/2023`. Task: [3575465](https://www.odoo.com/web#id=3575465&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#96508
This update prevents spreadsheet crashes when freezing or sharing sheets that use boolean global filters. It makes exporting to Excel more reliable by correctly handling empty filter values.
Original PR description
The method `getFilterDisplayValue` would not handled `undefined` values for boolean global filters, causing crashes when exporting to Excel. Task: [5188932](https://www.odoo.com/web#id=5188932&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#232784
This change fixes Swiss ISO20022 payment files so they no longer mix incompatible XML formats and get rejected by some banks. The previous behavior is now only enabled when explicitly requested, which helps companies keep file generation compatible with their bank’s requirements.
Original PR description
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after…
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt. The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix. ticket-4535542 ======================= [FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard. Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file. ticket-4535542 Forward-Port-Of: odoo/enterprise#99005 Forward-Port-Of: odoo/enterprise#98918
Live chat visitors on mobile devices will no longer have the chat input automatically zoom in when they tap it. This keeps the send button visible and makes it easier to type and send messages without having to zoom back out manually.
Original PR description
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would…
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would force users to pinch-to-unzoom, making the UX quite poor. This problem happens because mobile devices have an auto-zoom feature that is triggered when font-size is below 16px. The discuss UI is designed with 14px font size (web client font size), and since 14px < 16px, it zooms on input focus to about 115%. This commit fixes the issue by using a font-size of 16px specifically for livechat visitor on mobile devices, so that this doesn't auto-zoom. Note that this problem doesn't happen on the web client even though this uses a font-size of 14px because it specifically disable the autozoom feature: https://github.com/odoo/odoo/blob/17.0/addons/web/views/webclient_templates.xml#L250 This solution is not practical for livechat, for which it has to work on any external website. opw-5229076 Before <img width="199" height="431" alt="after" src="https://github.com/user-attachments/assets/cc2f8e04-bde7-4eeb-84d5-b2efa2763490" /> After <img width="199" height="431" alt="before" src="https://github.com/user-attachments/assets/6c6679fc-9c16-40e7-ab6f-21540d20d59d" /> Forward-Port-Of: odoo/odoo#235182 Forward-Port-Of: odoo/odoo#234967
The website builder’s selection dropdown now correctly displays all available options when users change an existing choice. This fixes a bug where only four options were shown, helping users make updates without confusion or extra steps.
Original PR description
With the initial [website builder refactor], only 4 options appeared in the `many2x` dropdown when user try to re-select. This commit fixes the issue so the dropdown now fetches all required options through passing domain in rpc call instead of filtering after rpc call this makes sure we only fetch required data by avoiding already selected ids. Steps to Reproduce: 1. Open the website builder. 2. Drop any snippet onto the page. 3. Set the visibility option to conditionally. 4. In the UTM medium dropdown, select any social media option. 5. Try changing the selection again. 6. Only 4 options are shown. Expected: Dropdown should always display 5 options. [website builder refactor]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
This change makes input fields inside image captions use a transparent background instead of a dark gray one. It improves the visual consistency of captions and makes the editor look cleaner for users.
Original PR description
### Purpose of this PR: - Set the default background of inputs inside `<figcaption>` to transparent. This prevents them from appearing dark gray (rgb(59,59,59)) in caption. task-5122745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents a table placed inside another table from growing beyond the space available in its parent cell when resized. As a result, nested tables stay usable and editable instead of becoming partially hidden or inaccessible.
Original PR description
**Current behavior before PR:** - When a table was created inside another table, resizing the inner table could cause it to overflow its parent cell, making it uneditable. **Desired behavior after PR is merged:** - The inner table no longer overflows its parent cell when resized, ensuring it remains editable. task-5216916 Forward-Port-Of: odoo/odoo#233554
This change fixes an issue in the mobile editor where using a formatting button like bold could incorrectly switch the toolbar to the image tools. The toolbar now stays in the correct mode and clearly highlights the selected formatting option, making editing on mobile more reliable.
Original PR description
**Current behavior before PR:** In mobile view, when applying the bold format using the toolbar button, the normal toolbar is incorrectly replaced by image toolbar. This occurs because `getFilteredTargetedNodes` returns an empty array, and as a result, the `isApplied` method evaluates to true since Array.every on an empty array returns true. **Desired behavior after PR:** This PR ensures that the toolbar remains in its normal state when a format is applied via the toolbar button. The corresponding format button (e.g., bold) is correctly highlighted. task-5123317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234467 Forward-Port-Of: odoo/odoo#229454
This fix brings back the save button and the related trusted-order behavior in Point of Sale. It restores the intended workflow so trusted terminals can continue handling orders correctly, preventing missing functionality for affected users.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229335 Forward-Port-Of: odoo/odoo#200567
15 changes
Resolved issues and error corrections
Users will now see inbox messages directly in the top messaging menu, including notifications like signature requests that were previously hidden there. This makes important messages easier to find and reduces confusion when a notification badge was shown but the message itself was not visible.
Original PR description
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of…
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of the signature request, as the counter badge is updated. - When clicking on the badge, no new message is shown. **Issue:** Inbox messages are not considered in the `MessagingMenu` when they are not linked to any record. It's the case when a signature request is sent and while the notification counter is updated, the message can't be seen in the top bar menu, it's only visible in the `Discuss` app > Inbox which is quite confusing for the users. In previous versions the behavior was different as the signature request was either considered as an activity or no notification was sent. Also if the inbox message is linked to a record, it only appears in the `all` filter of the menu. **Fix:** Added the inbox explicitly to the top `MessagingMenu` to be able to read the corresponding messages. We could also link the signature to its record when sending the message instead of `self.env['sign.request']._message_send_mail()` but it might cause access rights issues. Also ensured that a category `others` was used for such messages, and prevented an error caused by clicking on the conversation when the `Discuss` app was opened. Unfortunatly doing this will show duplicates in the notifications of the menu for messages which are in the inbox but which have a record set. (e.g. when such message appears, it will have one line in the inbox and one for the record itself) So we need to filter out the messages which have a thread from their record in the views to avoid it. related: https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda opw-4969005 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228740
This update corrects how date and work-time intervals are combined so the system always normalizes them before merging. It prevents inconsistent results and errors in planning-related operations, improving reliability when different interval types are used together.
Original PR description
## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`.…
## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165 The comment indicates that normalization should be enforced; however, there is no corresponding reference to it within the `_boundaries` method. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53 That normalization just happens in the `__init__`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132 ## Example For example, in Planning module, we perform operations between `Intervals` and `WorkIntervals`. The `WorkIntervals` class behaves differently from `Intervals`: while `Intervals` uses disjoint closed intervals, `WorkIntervals` uses disjoint semi-closed intervals. ## Side effects During these operations, the `_merge` method was not normalizing the `_items`, which caused inconsistencies and errors (when we are merging two unormalized intervals `([0, 10], [10, 20])` with an empty `others`). ## The fix This commit ensures that the `other` parameter is normalized before processing the `_merge` operation. The fix ensures that normalized intervals are always produced after `_merge`, even when unnormalized intervals are provided as input. ## Real case That issue has been found in that ticket: 5184291 Forward-Port-Of: odoo/odoo#234352
Livechat on mobile devices now keeps the message input at a size that prevents the browser from zooming in when it is tapped. This keeps the send button visible and makes it easier for visitors to chat without having to pinch back out.
Original PR description
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would…
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would force users to pinch-to-unzoom, making the UX quite poor. This problem happens because mobile devices have an auto-zoom feature that is triggered when font-size is below 16px. The discuss UI is designed with 14px font size (web client font size), and since 14px < 16px, it zooms on input focus to about 115%. This commit fixes the issue by using a font-size of 16px specifically for livechat visitor on mobile devices, so that this doesn't auto-zoom. Note that this problem doesn't happen on the web client even though this uses a font-size of 14px because it specifically disable the autozoom feature: https://github.com/odoo/odoo/blob/17.0/addons/web/views/webclient_templates.xml#L250 This solution is not practical for livechat, for which it has to work on any external website. opw-5229076 Before <img width="199" height="431" alt="after" src="https://github.com/user-attachments/assets/cc2f8e04-bde7-4eeb-84d5-b2efa2763490" /> After <img width="199" height="431" alt="before" src="https://github.com/user-attachments/assets/6c6679fc-9c16-40e7-ab6f-21540d20d59d" /> Forward-Port-Of: odoo/odoo#235150 Forward-Port-Of: odoo/odoo#234967
When a pivot table with date or date-time columns was inserted into a spreadsheet, its sort order could be lost. This fix keeps the original date-based sorting so spreadsheet pivots display in the expected order.
Original PR description
If on the web pivot view we create a pivot with a date/dateTime field in the columns, and sort on one of these columns, the resulting pivot when inserted in a spreadsheet isn't sorted. This was because we didn't normalize the date values in the pivot `sortedColumn`, and we had UTC timestamps `2023-01-01 00:00:00` instead of normalized values `01/2023`. Task: [3575465](https://www.odoo.com/web#id=3575465&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#96508
This change fixes an issue where installing the Argentina withholding demo data created duplicate tax records. As a result, users will now see a clean, single set of taxes instead of repeated entries with copy labels.
Original PR description
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo…
**Description of the issue/feature this PR addresses**: This pr is to avoid duplicated taxes when the demo data is installed. **Steps to reproduce**: 1. Install l10n_ar_withholding module with demo data. 2. Take position in "(AR) Responsable Inscripto" company. 3. Check the taxes created on "Invoicing > Configuration > Accounting > Taxes". 4. Delete the filter "Sale or Purchase". 5. Add custom filter: Argentina Withholding Payment Tax type (l10n_ar_withholding_payment_type) is in ["supplier", "customer"]. 6. You will see that there are duplicated taxes (duplicated names) with suffix (Copy). **Current behavior before PR**: Duplicated taxes are created when demo data is installed. <img width="1597" height="795" alt="image" src="https://github.com/user-attachments/assets/51b65037-bb89-4ec7-8adf-21636b68e405" /> **Desired behavior after PR is merged**: No duplicated taxes are created when demo data is installed. _Task latam side_: 1360. _Task Adhoc side_: 57627. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226992
This update adjusts an automated purchase test so it works correctly with PostgreSQL 18. It prevents the test suite from failing due to a database error code change, helping maintain reliable validation in ongoing development and releases.
Original PR description
Apparently in pg18 a standard-compliance fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted…
Apparently in pg18 a standard-compliance
fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted `FOREIGN_KEY_VIOLATION`. One such case is specifically being tested for by `test_purchase_order_line_without_uom`, leading to this test failing systematically when running pg18:
psycopg2.errors.RestrictViolation: update or delete on table "uom_uom" violates RESTRICT setting of foreign key constraint "purchase_order_line_product_uom_id_fkey" on table "purchase_order_line"
DETAIL: Key (id)=(29) is referenced from table "purchase_order_line".
Update the test to use the more generic `IntegrityError` as it's probably more than sufficient for our purposes. Technically we could pass a tuple of `(ForeignKeyViolation, RestrictViolation)` but it doesn't really seem necessary. And it would require fixing the `_raisesContext` override as currently it is very much *not* compatible with that.
Forward-Port-Of: odoo/odoo#235119The dashboard upload button can no longer be moved by dragging it. This keeps the interface stable and avoids accidental changes to the button’s position while users work.
Original PR description
Issue: - In the dashboard, the upload button (purchase journal and others) could be dragged. - This caused unintended movement of the upload UI element. Fix: - Added `draggable=false` to the upload button element. - Ensures the button remains fixed and cannot be dragged around. TaskID-5114617 Forward-Port-Of: odoo/odoo#235086 Forward-Port-Of: odoo/odoo#229013
This update fixes Swiss ISO 20022 payment files so banks receive the expected XML structure again. The change only forces SEPA-specific nodes when an explicit configuration is enabled, which helps avoid bank rejections caused by mixed or unsupported file formats.
Original PR description
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after…
[REV] account_iso20022: Wrong XML generated for Switzerland This reverts commit https://github.com/odoo/enterprise/commit/a0e981171808d4e475249431424955ab2223f5da. This commit was introduced after this fix https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611. Though that original fix was correct, it had some unwanted side-effects: due to the payment method being forced on some payments in order to use SEPA, the sepa_pain_version field was used to generate the corresponding XML nodes, most of the time keeping its default value of pain.001.001.09. For Swiss banks supporting pain.001.001.09 (which becomes mandatory in November 2026), it was not a problem, and everything worked fine. This was the case of the customer for whom the fix was made (ticket 4535542). For the ones still not supporting it, and expecting pain.001.001.03, the bank refused the file, since the it contained unsupported nodes, like BICFI, or a subnode to ReqdExctnDt. The commit we revert here tried to patch the symptoms without really understanding the cause of the issue, by not forcing the payment method everywhere. It breaks again the case of the original ticket (because ScvLvl is not passed to "SEPA" on EUR payments), and essentially makes no sense. We revert it in favor of a better fix. ticket-4535542 ======================= [FIX] account_iso20022: Swiss variant: introduce config parameter to force SEPA nodes in the file https://github.com/odoo/enterprise/commit/c160b2ead711797ca7362649971038cc245c5611 made it so we now force SEPA payments into Swiss ISO20022 files when they're made in EUR to an IBAN account. Though all in all correct, this fix forgot to consider the fact that the SEPA nodes would be generated using the sepa_pain_version field, with defaults to pain.001.001.09 version of the ISO standard. As it is today, the Swiss file is still generated using pain.001.001.03 in Odoo (some task will change that soon, since the support for that old version will be dropped in November 2026). Having such pain.001.001.09 nodes in the file causes it to be rejected by a lot of Swiss banks, because they don't support that version yet, or simply because of the file mixing both versions of the standard. Since no one had asked us to enforce SEPA nodes within the file before recently, we make the choice to keep the fix behavior only when a config parameter is explicitly set to enable it. In all other cases, the former behavior is restored. We also now display the PAIN version field in the journal's form view when this config parameter is set, to give more control on the format of the generated file. ticket-4535542 Forward-Port-Of: odoo/enterprise#99005 Forward-Port-Of: odoo/enterprise#98918
This update fixes two issues on the careers page. Visitors who are not logged in will now be redirected to the correct country more reliably, and job opening counts will display correctly even when grouped by different office or location fields.
Original PR description
This commit fixes 2 bugs: When you are not logged in and geolocalized, we don't redirect the visitor to the right country because the visitor cannot read hr.job, so the count will always be 0. Now we use sudo to have the count whether you are logged in or not. Another bug is in compute_filter_selection_counters: in case you provide a key_getter that is not the same as the grouping_field, when we count, we only keep the last count in case of duplicates. Eg, if you group by address_id and count the address_id.country_id, you will get the count of hr.job open in the last office you iterate over.
This update prevents the website editor from crashing when someone presses Delete without an active text selection. It improves stability during normal editing so users can remove content without triggering an error message.
Original PR description
If the selection of the document is not set and the user presses the delete key, the delete handler of the list plugin throws an error. Steps to reproduce (in 19.0, where the issue was discovered): - Open website builder - Drop the video inner snippet in the header - Double-click & drag from the video to just outside the video - Click once on the video - Press "delete" - Bug: Traceback task-5186954
The website now uses the same tax display rules in its structured data as it does on the page itself. This keeps the price shown to search engines consistent with the price customers see, especially when the website is configured to show taxes included.
Original PR description
## Version
18.2+
SEO Schema refactoring from task-3866937
## Issue
The markup always contains the price without taxes, no matter the website settings for pricing display (with or without taxes).
## Steps to reproduce
- Go to Website settings:
- Choose "Taxes Included" for "Display Product Prices".
- Got to the shop and select any product on which taxes apply (e.g. Customizable Desk):
- Open console and execute `JSON.parse(document.querySelectorAll('[type="application/ld+json"]')[1].innerHTML)[0]['hasVariant'][0]['offers']['price']`;
- The found price and the displayed price (visible on the page) are different
## Fix
Allow tax inclusion based on parameter to mimic template's behavior on variants too depending on the website.
https://github.com/odoo/odoo/blob/52a6d88a188d5456262428847aed229f117da8ed/addons/website_sale/models/product_template.py#L377-L430
opw-4923780
Forward-Port-Of: odoo/odoo#225577This fix prevents a table placed inside another table from growing beyond its parent cell when resized. As a result, nested tables remain visible and editable, avoiding a frustrating editing issue for users.
Original PR description
**Current behavior before PR:** - When a table was created inside another table, resizing the inner table could cause it to overflow its parent cell, making it uneditable. **Desired behavior after PR is merged:** - The inner table no longer overflows its parent cell when resized, ensuring it remains editable. task-5216916 Forward-Port-Of: odoo/odoo#233554
The website SEO optimization dialog now waits for the page preview to finish loading before opening. This prevents occasional crashes when users open the dialog immediately after reloading a page on a slow connection.
Original PR description
Steps to reproduce: - Open Website app and enter edit mode on any page. - Reload the page with a slow connection. - Immediately open "Optimize SEO" from the navbar menu. Before this commit, the dialog accessed the preview document while the iframe was reloading, so reading location.origin raised a TypeError. After this commit, the dialog waits for the iframe to finish loading or returns immediately when it is already complete, preventing crashes. task-5104033 Forward-Port-Of: odoo/odoo#230820
This change resolves an error that could occur in Odoo Studio during automated testing. It helps ensure Studio behaves reliably and avoids interruptions in validation workflows.
Original PR description
Forward-Port-Of: odoo/enterprise#98881
This fix prevents the point of sale from raising an error when a pro forma request finishes after the related order has already been deleted. It checks that the order still exists before using it, which avoids interruptions for users and keeps the flow stable.
Original PR description
Before this commit, when trying to send a pro forma for an order that had been deleted while the pro forma call was in the queue, a JS error would occur because the callback of the call would try to access the order which was no longer existing in the frontend. This is now fixed by checking that the order is still present before accessing it in the callback.
5 changes
Resolved issues and error corrections
This change fixes a failing test in the app creation experience used by Studio. It helps keep the product stable by preventing an error in automated validation, reducing the risk of regressions reaching users.
This fix makes it possible to drag and drop documents on touch devices, where the previous browser behavior could lose the data needed to complete the drop. It improves the experience for mobile users by restoring a feature that was failing in some browsers.
Original PR description
For now, touch devices do not work with native drag and drop in browsers. When a datatransfer is set on a dragstart event, it is lost before reaching the drop event, but only when using a touch device. Unfortunately, I still haven't found any sources that clearly explain whether this is a known bug or a limitation. The fact that on mobile (really mobile, not devtools, you need a touch device) drag fails on Chrome but succeeds on Firefox. To fix this issue, this commit manages datatransfers in an external variable, without using the method in the Event. I keep the original behavior as default, I just add a fallback to my global datatransfer variable. opw-5139435 Forward-Port-Of: odoo/enterprise#97091
This update corrects a test in the barcode batch workflow so it runs reliably on newer Python versions. It prevents false test failures caused by changes in how record ordering is handled, helping maintain stable quality checks.
Original PR description
*: stock_barcode_picking_batch Steps to reproduce ================== Use python > 3.10 Run the test test_pack_batch_in_multiple_packages It fails on assertRecordValues, the records are not in the same order Cause of the issue ================== Recordsets ordering is not stable across python versions. It is implemented as `return set(self._ids) < set(other._ids)` https://github.com/odoo/odoo/blob/8a026b875a9b70f12689cdbd71d7e54b987d0612/odoo/models.py#L6636 Since this is a subset check, it always returns false when called with different ids Solution ======== Compare using the id directly opw-231140 Forward-Port-Of: odoo/enterprise#99118
This change simplifies a styling rule used in spreadsheet side panels. It keeps the same visual result while making the code easier to maintain and reducing the risk of future styling issues.
Original PR description
Because of a really strong rule in o_spreadsheet lib that forced the box-sizing property pretty much everywhere, we came up with a super dense rule to counteract it inside odoo and specifically inside the side panels. This commits aims to simplify it at best with the common denominator of those rules. Task-4878174 Forward-Port-Of: odoo/enterprise#98876
This change fixes how subscription quantities are updated when an invoice is only partially credited. After the fix, the remaining invoiced quantity stays accurate instead of dropping to zero, which helps keep subscription billing records correct.
Original PR description
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is…
**Issue** When creating a partial credit note (i.e., for a quantity less than originally invoiced) for a subscription invoice, the `qty_invoiced` on the corresponding subscription order line is incorrectly set to zero, instead of reflecting the remaining quantity. **Steps to Reproduce** 1. Create a subscription with a quantity of 50. 2. Confirm the subscription and generate an invoice. 3. Create a credit note (reversal) for the invoice. 4. Change the credited quantity to 30. 5. Post the credit note. 6. The subscription order line shows qty_invoiced = 0 instead of the expected 20. **Root Cause** The method `_get_max_invoiced_date()` is used to determine the latest invoiced period for a subscription. In its original implementation, it removes refunded periods from the list of invoice dates regardless of whether the refund is partial or full. This causes the system to consider the period as not invoiced at all, which leads to incorrect recomputation of `qty_invoiced` **Fix** Adjust `_get_max_invoiced_date()` to track the net invoiced quantity per period. A period is only removed from the list of invoice dates if it has been fully refunded (i.e., net quantity is zero). This ensures that partially refunded periods are still considered invoiced, and the `qty_invoiced` is correctly updated to reflect the remaining quantity Opw-4908760 Forward-Port-Of: odoo/enterprise#91344
9 changes
Resolved issues and error corrections
The Knowledge app’s automated history checks were updated after changes to the editor history window. This keeps quality checks reliable and helps prevent future issues in Knowledge history features.
Original PR description
Due to a revamp of the html_editor history dialog, some tests were failing. This commit fixes the knowledge history tour. requires: https://github.com/odoo/odoo/pull/231349 task-5135850
This update fixes how the Appointment website snippet includes its supporting page assets, aligning it with the newer platform method. This helps ensure the appointment booking section continues to display and behave reliably after recent framework changes.
Original PR description
See https://github.com/odoo/odoo/pull/104836 task-2963840 Forward-Port-Of: odoo/enterprise#99195 Forward-Port-Of: odoo/enterprise#35153
This fixes a problem that prevented PIN code encoding from working after queue processing was added to the Belgian POS blackbox. The update also improves how related success and error responses are handled, helping reduce checkout disruption for affected installations.
Original PR description
Since the introduction of the queue mechanism in blackbox, the PIN encoding was not working. This was due to the fact that the blackbox driver trying to access some non-existing data. This is now solved and improved to better handle the error and subsequent error or success. Forward-Port-Of: odoo/enterprise#99029
The payslip CFDI PDF now places employee-related information in the correct employee section instead of showing it under employer details. This helps prevent confusion in payroll documents and improves the accuracy of generated reports.
Original PR description
Some info related to the employee is shown in the employer section. Task: 5224191 Forward-Port-Of: odoo/enterprise#98534
Odoo now ignores an unsupported transaction reference field when fetching missing bank transactions from OdooFin. This prevents users from hitting an error during online bank synchronization and helps the process complete reliably.
Original PR description
… missing transactions The field `end_to_end_uuid` was introduced in `account_iso20022` on the bank statement line model but is absent from the corresponding transient model used by `account_online_synchronization`. When a transaction payload from OdooFin includes this field, processing it raises a traceback because the field does not exist on the transient model. This commit drops the `end_to_end_uuid` key from incoming transactions to avoid the error. task-5223434 Forward-Port-Of: odoo/enterprise#98786
The Ask AI website live chat widget no longer automatically takes focus when a page loads in fullscreen mode. This prevents visitors from being unexpectedly pulled to the widget while still allowing the input to refocus after an AI response.
Original PR description
Scenario: - add "Ask AI" snippet on bottom of a page - reload the page Result: we get autofocused on the "Ask AI" snippet if the snippet is in "Fullscreen" configuration. Fix: avoid the initial focus but keep the code so we re-focus on the input after AI answer. opw-5153332 Forward-Port-Of: odoo/enterprise#97260
This update aligns barcode packing behavior with related community changes so package nesting continues to work as expected. It also adjusts delivery test coverage to reflect the updated order of package move lines, reducing the risk of repeated updates to the wrong line.
Original PR description
Some adaptations based on the community side: - Adapt the compute of `outermost_result_package_id` so nothing changes functionality-wise in barcode. - Adapt a test as the priority of move lines from 'Put in Pack' have changed. Task-5116567 Forward-Port-Of: odoo/enterprise#95648
Pivot tables inserted from the web view into spreadsheets now preserve sorting when the sorted column is a date or date-time field. This prevents reports from appearing out of order and helps users rely on spreadsheet pivots for accurate analysis.
Original PR description
If on the web pivot view we create a pivot with a date/dateTime field in the columns, and sort on one of these columns, the resulting pivot when inserted in a spreadsheet isn't sorted. This was because we didn't normalize the date values in the pivot `sortedColumn`, and we had UTC timestamps `2023-01-01 00:00:00` instead of normalized values `01/2023`. Task: [3575465](https://www.odoo.com/web#id=3575465&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#99203 Forward-Port-Of: odoo/enterprise#96508
Payroll users can now cancel a duplicate payslip even when it shares work entries with another payslip. This prevents unnecessary blocking while ensuring shared work entries are not incorrectly reset unless they belong only to the cancelled payslip.
Original PR description
previous behavior: - Cancelling duplicate payslips wasn't possible because they had the same work entries linked current behavior: - Allows to cancel a duplicate payslip without affecting the linked work entries - Work entries are only set to draft when they are linked to one payslip that is being cancelled - added `test_duplicate_payslips_cancellation` task-id: 5075882 Forward-Port-Of: odoo/enterprise#99181 Forward-Port-Of: odoo/enterprise#94236
30 changes
Resolved issues and error corrections
The follow-up report now correctly ignores invoice lines marked as "No Follow-Up" when calculating a partner’s balance. This prevents partners from being incorrectly shown as needing no action when they still have overdue items that should be chased.
Original PR description
### Issue: Have a partner with an overdue invoice and a credit note with an amount greater than the invoice but excluded from follow-ups. This partner will have a follow-up status of…
### Issue: Have a partner with an overdue invoice and a credit note with an amount greater than the invoice but excluded from follow-ups. This partner will have a follow-up status of `no_action_needed` where it should be `in_need_of_action`. ### Steps to reproduce: - Create an overdue invoice for a new partner - Create a credit note for this partner with an amount greater than the invoice - Accounting > Reporting > Partner Ledger - Change the report to 'Follow-up Report' - Unfold the new partner and tick 'No Follow-Up' for the credit note line - Go to the partner form view, under the 'Accounting' page - The status is 'No action needed' ### Cause: The query responsible for the computation of the follow-up status does not consider the `no_followup` option to compute the balance of the partner. So the partner has a negative balance and the line `WHEN partner.balance <= 0 THEN 'no_action_needed'` gives the partner the status `no_action_needed`. ### Solution: Only consider lines with `no_followup = False` in the computation of the partner balance. Now when a partner only has lines with `no_followup = True` the query will not return anything, so the test method `assertPartnerFollowup()` needed to be adapted. opw-5170038
This update adjusts an automated purchase test so it works correctly with PostgreSQL 18. It prevents the test suite from failing due to a database error type change, keeping development and validation runs stable.
Original PR description
Apparently in pg18 a standard-compliance fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted…
Apparently in pg18 a standard-compliance
fix (postgres/postgres@086c84b23d99c2ad268f97508cd840efc1fdfd79) has led to `RESTRICT_VIOLATION` being emitted in cases which formerly emitted `FOREIGN_KEY_VIOLATION`. One such case is specifically being tested for by `test_purchase_order_line_without_uom`, leading to this test failing systematically when running pg18:
psycopg2.errors.RestrictViolation: update or delete on table "uom_uom" violates RESTRICT setting of foreign key constraint "purchase_order_line_product_uom_id_fkey" on table "purchase_order_line"
DETAIL: Key (id)=(29) is referenced from table "purchase_order_line".
Update the test to use the more generic `IntegrityError` as it's probably more than sufficient for our purposes. Technically we could pass a tuple of `(ForeignKeyViolation, RestrictViolation)` but it doesn't really seem necessary. And it would require fixing the `_raisesContext` override as currently it is very much *not* compatible with that.
Forward-Port-Of: odoo/odoo#235119The dashboard upload button could accidentally be dragged out of place, which made the interface behave unpredictably. This update keeps the button fixed in position so it stays where users expect it to be.
Original PR description
Issue: - In the dashboard, the upload button (purchase journal and others) could be dragged. - This caused unintended movement of the upload UI element. Fix: - Added `draggable=false` to the upload button element. - Ensures the button remains fixed and cannot be dragged around. TaskID-5114617 Forward-Port-Of: odoo/odoo#235086 Forward-Port-Of: odoo/odoo#229013
A bug that caused a server error when switching on eCommerce Categories in the website mega menu has been fixed. The editor now correctly finds the mega menu content even when the first element is not the expected one, preventing the traceback and making the customization work reliably.
Original PR description
A traceback would occur when clicking the "eCommerce Categories" toggle in the mega menu's style options. Steps to reproduce: 1. Go to the Website editor. 2. Add a mega menu to the page header. 3. Edit and Click on the mega menu's 4. In the sidebar, click the "eCommerce Categories" toggle. -> Traceback. Cause: When loading it was trying to find a specific class name (starting with `s_mega_menu_`) to identify the snippet. It was hardcoded to only look at the `firstElementChild` of the snippet's container. This assumption was too rigid. If the first element was a `<p>` tag or another element without the required class, the code would fail to find it. This resulted in an `undefined` value being sent to the server, causing the traceback. Solution: Use `querySelector` to search for any element with a class name containing `s_mega_menu_`. opw-5245777 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a guest joins a meeting and changes their name on the welcome page, the updated name now appears immediately in the participant list. This improves clarity for meeting hosts and helps everyone identify guests more easily.
Original PR description
**Steps to Reproduce:** - Login with Admin, start a meeting, open the member list. - Join the meeting with a guest, using the invite link. - Change the guest name from the welcome page. - Admin member list doesn't show updated guest name. **Current behavior before PR:** Before this PR, the guest appeared as `Guest` in the member list even after updating their name on the welcome page. **Desired behavior after PR is merged:** This PR ensures the guest name is updated and displayed instantly upon joining, providing a smoother and more consistent experience. task-[5062702](https://www.odoo.com/odoo/project/1519/tasks/5062702) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234299
This fix restores the ability to tap an order line to select it in the product screen when the IoT scale certification module is installed. It ensures the long-press configurator feature works without blocking normal line selection, improving usability at the point of sale.
Original PR description
Task: [5163235](https://www.odoo.com/odoo/project/1737/tasks/5163235) --- In the product screen, pressing an orderline was supposed to select this line and a long press was supposed to open the Configurator popup. However, since the feature of the long press, if we install the module `l10n_eu_iot_scale_cert`, pressing an orderline does not select it anymore. This was due to the fact that a `t-ref` was added in the orderline template and that in the `l10n_eu_iot_scale_cert` module, we were overriding this template completely. Forward-Port-Of: odoo/enterprise#98886 Forward-Port-Of: odoo/enterprise#96980
Selecting the same date filter again no longer triggers extra updates or chart redraws. This also fixes an issue in Custom Range where clicking inside the date fields could accidentally reapply the filter.
Original PR description
## Description - Re-clicking the current date filter (relative/month/quarter/year/range) triggered redundant RPCs and chart re-animations. In Custom Range, clicks inside inputs also bubbled to the dropdown item, causing unwanted updates. ##### This PR: - Stop event bubbling inside Custom Range inputs to avoid spurious updates. - In GlobalFiltersCoreViewPlugin.allowDispatch(), return NoChanges when the incoming value equals the current filter value (currentFilterValue). Task: [5187275](https://www.odoo.com/odoo/project/2328/tasks/5187275) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change lets users cancel a duplicate payroll slip even when it shares work entries with another slip. It prevents unrelated work entries from being reset, reducing disruption and making payroll corrections safer and easier.
Original PR description
previous behavior: - Cancelling duplicate payslips wasn't possible because they had the same work entries linked current behavior: - Allows to cancel a duplicate payslip without affecting the linked work entries - Work entries are only set to draft when they are linked to one payslip that is being cancelled - added `test_duplicate_payslips_cancellation` task-id: 5075882 Forward-Port-Of: odoo/enterprise#94236
This update fixes a warning caused by newer Python versions in the IoT webRTC client. It helps keep the system cleaner and more compatible without changing how users work.
Original PR description
In Python 3.12 the `asyncio.get_event_loop()` function was deprecated, and now logs a warning when it is used. To fix this we replace it with `asyncio.new_event_loop()`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Scanning a self-invoicing QR code now sends users directly to the ticket validation screen, instead of opening a page with incomplete information. If the customer is already registered, it can go straight to the invoice, reducing friction and avoiding failed or confusing follow-up steps.
Original PR description
Before: QR scan(self invoicing) redirected to /pos/ticket with pre-filled data but missing ticket code. After: Now directly redirects to the validation screen or invoice if customer is already registered. taskID-4777138
The pivot field selector popover now keeps a normal light appearance in dark mode instead of switching to a dark theme. This makes the spreadsheet experience more consistent, since dark mode is not yet supported in the spreadsheet editor.
Original PR description
Spreadsheet does not support dark mode yet, but the pivot field selector popover was dark-themed in dark mode. Task: [5163919](https://www.odoo.com/web#id=5163919&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update restores menu mode in self-ordering so customers can browse and order as expected. It prevents disruptions in the ordering experience and helps ensure orders can be placed smoothly on mobile and kiosk flows.
Original PR description
Menu mode was broken in self ordering. This commit fix it. Forward-Port-Of: odoo/odoo#234460 Forward-Port-Of: odoo/odoo#232503
This change prevents an error when users paste a Vimeo link into the Knowledge app’s media dialog. It makes the video link handling more robust so the dialog works normally even when the link does not include extra time information.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Knowledge app 2. Open any document and use `/media` to open the media dialog 3. Go to the Videos tab in the dialog 4. In another browser…
Steps to reproduce:
-------------------------
1. Install the Knowledge app
2. Open any document and use `/media` to open the media dialog
3. Go to the Videos tab in the dialog
4. In another browser tab, open the Vimeo website
5. Copy any Vimeo video link and paste it into the dialog
Observation:
-------------------------
When pasting a Vimeo link, a traceback occurs:
```
TypeError: Cannot read properties of undefined (reading 'match')
at EmbeddedVideoSelector.parseTimeToSeconds
```
Issue:
-------------------------
In the following function,
https://github.com/odoo/odoo/blob/b5ed2d5a3e4ac9379ed15549dd9c8e08547181bb/addons/html_editor/static/src/main/media/media_dialog/video_selector.js#L350-L353 This happens because the code splits the Vimeo URL using `#t`. If the URL does not contain `#t`, the result is undefined, which is then passed to the `parseTimeToSeconds` function.
Solution:
-------------------------
Added optional chain operator in `parseTimeToSeconds` for safe validation of
`value` before calling `.match()`
opw-5221403When users remove formatting from text inside lists, any applied text color is now also removed correctly. This makes the editor behave as expected and helps keep pasted or edited content visually consistent.
Original PR description
### Steps to reproduce: - Open the Todo and create a new list. - Type some text and press `Ctrl + A` to select all. - Apply a text color class using the color picker. - Remove formatting from the selected content. ### Description of the issue/feature this PR addresses: - When color was applied through classes inside list items and removeFormat was triggered, color classes were not removed. ### Desired behavior after PR is merged: - All text color styles and classes are removed when using `removeFormat`. task-5166472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the cursor behavior when adding an image caption so it stays in the expected place instead of jumping unexpectedly. It also makes the image description popover place the cursor directly in the description field, making image editing smoother and more reliable for users.
Original PR description
### Description of the issue/feature this PR addresses: - Commit [1](https://github.com/odoo/odoo/commit/9a3abd5f9e5658b72b8a5d2fa0384bdbb580873f) changed `selectionchange` listener to `addGlobalDomListener`. As result, calling this.captionInput.el.focus() in caption.js triggered `selectionchange` event. Since `<figure>` is contenteditable="false", the `fixSelectionOnEditableRootGeneric` method moved the selection to sibling `<div>`, causing the cursor to jump unexpectedly. ### Desired behavior after PR is merged: - The selection is explicitly set at the end of the `<figure>` when adding caption, preventing the cursor from moving to a sibling editable `<div>`. - When the image description popover opens, the cursor automatically focuses on the description input field by default. task-5122745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the helper logic behind the Documents sharing panel so the "Access through link" option no longer depends on the internal access setting by mistake. It helps ensure the sharing choices shown to users are accurate and behave as expected when setting up shared links.
Original PR description
This commit fix the helpers for the 'Access through link' option where a condition was mistakenly depending on internal access option. Task-5222910
This update fixes a display issue in the accounting reports control panel on mobile devices. It helps the page fit properly on smaller screens, improving readability and making it easier to use reports on the go.
Original PR description
Before this PR, the control panel had an overflow in mobile view. task-4768525 backport of https://github.com/odoo/enterprise/pull/84742
A layout issue in the Discuss app could cause the page to overflow horizontally when opening or closing the call sidebar during a call. This update adjusts the call layout so the main view resizes correctly, keeping the interface stable and preventing visual overlap.
Original PR description
Before this commit, when in a discuss call in the Discuss app with sidebar not compact and a right panel open, click on Discuss sidebar would overflow horizontally the UI. This happens because the rearrange of tiles of the discuss call grid would be triggered from sidebar toggle state change, but the rearrange of tiles was mistakenly coded to preserve the height of main tile. This is a problem with discuss call sidebar because while the overall height of call view should stay unchanged, the main card must have its height reduced to compensate with discuss call sidebar when shown. This commit fixes the issue by resetting temporarily the height of call card tile in `arrangeTiles()`, so that it takes into account when it has to adapt its height. Before  After 
This change corrects a field reference in stock accounting so the system uses the company currency instead of an invalid currency field. It prevents errors caused by the wrong field being used and helps stock valuation work as expected.
Original PR description
commit 9c63ac283b89807c23a8a1934eef8074a312c36d Introduced a bug since it uses the field `currency_id` instead of the correct field `company_currency_id` 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 change prevents a table placed inside another table from expanding beyond its parent cell when resized. It keeps the table within bounds so users can continue editing it normally.
Original PR description
**Current behavior before PR:** - When a table was created inside another table, resizing the inner table could cause it to overflow its parent cell, making it uneditable. **Desired behavior after PR is merged:** - The inner table no longer overflows its parent cell when resized, ensuring it remains editable. task-5216916 Forward-Port-Of: odoo/odoo#233554
This change fixes an error that could happen when users tried to edit certain website pages, such as appointments pages. It improves the editing experience by preventing the editor from crashing on text elements, so pages can be opened and edited normally.
Original PR description
To reproduce: ============= - with website appointments installed go to appointments page - try to edit the page -> error Problem: ======== when entering edit mode, we call `selection_blocker_predicates` on editable nodes which will call `node.hasAttribute` internally. However, some nodes are text nodes and thus do not have this method, leading to an error. Solution: ========= `isBlock` method checks several things on the node, including if it's a text node. so swapping the order of the conditions will fix the problem. opw-5239754 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Uploading an invalid or encrypted PDF in Sign no longer causes an error screen. The system now checks the file first and safely rejects unreadable documents, improving reliability for users working with signed documents and templates.
Original PR description
Currently, an error occurs when trying to upload an encrypted/invalid document in the Sign Documents. **Steps to reproduce:** 1. Install **Sign** module. 2. Try to upload the encrypted PDF in Sign Document or templates. **Sample files:** https://drive.google.com/drive/folders/1MkiFRgJOlv2zc6ZW3SJYnMwHZYy9CFtX?usp=drive_link **Errors:** ``` DependencyError - PyCryptodome is required for AES algorithm UnicodeDecodeError - 'utf-8' codec can't decode byte 0xa4 in position 0: invalid start byte ``` **Cause:** The `flatten_pdf` function calls `PdfFileReader`, which raises an error if the file is encrypted or cannot be read/decrypted properly. Also, adding AES encrypted document in already uploaded valid document will triggers the same error. **Fix:** This commit prevents a traceback when uploading invalid or encrypted PDF files by validating the PDF data beforehand. sentry-6913657420
This fix ensures the customer document fields appear or disappear correctly when an invoice is moved between journals that do or do not use documents. It prevents users from seeing the wrong fields after changing the journal, which helps avoid confusion and saving errors.
Original PR description
**Steps to reproduce:** 1. Install `l10n_ar` localization. 2. Create two sales journals with the `Use documents` option enabled and disabled. 3. Create an invoice and add a customer and change the…
**Steps to reproduce:**
1. Install `l10n_ar` localization.
2. Create two sales journals with the `Use documents` option enabled and disabled.
3. Create an invoice and add a customer and change the journal to with `use documents` and save the record
4. Now change the jornal to without `use documents` and try to save it
**Observed behavior:**
The `Document Type` and `Document Number` fields fail to show or hide properly when switching between journals with different `Use documents` configurations.
**Cause:**
The `_compute_l10n_latam_use_documents` method lacked the `@api.depends` decorator with appropriate dependencies. As a result, when the journal is changed on an invoice, the
`l10n_latam_use_documents` field was not recomputed, leading to incorrect visibility of related fields.
**Fix:**
Add the missing `@api.depends('journal_id.l10n_latam_use_documents', 'move_type')` decorator to ensure the field recomputes whenever the journal or its `Use documents` setting changes.
opw-5220202This fix ensures that journals excluded from a Multi-Ledger remain excluded even after they are archived. As a result, financial reports such as Profit and Loss will no longer include entries from journals that were meant to be left out.
Original PR description
A journal is still excluded from the ledger even if it is archived. To reproduce: * create a new journal * create a journal entry impacting the P&L in that journal * create a Multi-Ledger (journal group) excluding this journal * archive the journal * open the P&L The journal entry is impacting the report, because the journal is not excluded. task-5251383
This update fixes how tax return reports are handled when a country has more than one report type. It prevents duplicate or incorrect return content by ensuring each closing entry uses only the relevant tax data, and it adjusts some reports so they no longer generate an unnecessary closing entry.
Original PR description
It's possible for different tax reports to exist in the same country, each with its own return type. However, this is an issue when they aren't configured to generate closing entries with distinct contents, since each of them will then repeat the content of the other. To fix this, when it's legitimate to make multiple closing entries, we make sure the closing entry only considers the tax move lines linked to the report's tax tags. If multiple reports must generate the same closing entry (typically because one of them is a simplified version of the other), we disable the generation of the return for one of them. Some reports also didn't need to generate a closing entry and were switched to a 'review_submit' state. task-5123564 Forward-Port-Of: odoo/enterprise#98973 Forward-Port-Of: odoo/enterprise#98158
Pivots inserted into spreadsheets now keep the same date-based sorting as in the web pivot view. This fixes an issue where date and date-time columns could lose their order because their values were not normalized correctly.
Original PR description
If on the web pivot view we create a pivot with a date/dateTime field in the columns, and sort on one of these columns, the resulting pivot when inserted in a spreadsheet isn't sorted. This was because we didn't normalize the date values in the pivot `sortedColumn`, and we had UTC timestamps `2023-01-01 00:00:00` instead of normalized values `01/2023`. Task: [3575465](https://www.odoo.com/web#id=3575465&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#99203 Forward-Port-Of: odoo/enterprise#96508
Follow-up reminder emails now keep the invoice attachment when invoices are set to be included. This fixes an issue where the system was accidentally hiding those attachments, so customers receive the full reminder message with the invoice included.
Original PR description
### Issue: The invoices supposed to be sent with follow-ups when the option `join_invoices` is tick are not sent. ### Steps to reproduce: - Install "account_followup" - Create a new partner - Create…
### Issue: The invoices supposed to be sent with follow-ups when the option `join_invoices` is tick are not sent. ### Steps to reproduce: - Install "account_followup" - Create a new partner - Create an invoice for this partner with a due date in the past, confirm and send - Go on the partner form view, under the "Accounting" it should be in the state "In need of action" - Click "Send", the wizard pops up with the invoice attachment - Click "Send", the message does have the invoice attachment, only the report ### Cause: The attachment in linked to the wizard in database but when doing a read, the domain is appended with `'res_field', '=', False` by these lines: https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/odoo/addons/base/models/ir_attachment.py#L598-L603 But the invoices attachments have res_field set to `invoice_pdf_report_file` so they are filtered out. The purpose of adding the new leaf to the domain is to filter out attachments that we are not searching for specifically. As they are linked to a specific field (`res_field`), if we don't search on this field, we are not supposed to see them. With the `followup_manual_reminder` wizard, we are linking attachments having a `res_field` to `account_move.invoice_pdf_report_file` to a new field: `followup_manual_reminder.attachment_ids`. So `'res_field', '=', False` should not be added. ### Solution: The problematic fields are all `Many2Many` fields to `ir.attachment` and since [this commit](https://github.com/odoo/enterprise/commit/fd4fcb1bd8764dbde1c8b3295623dd020c882a60) these fields have `bypass_search_access=True`. So the fix consist of not adding the domain `'res_field', '=', False` when `bypass_access` is True. opw-5164456
Live chat on mobile devices now keeps the message field at a readable size without triggering the browser’s automatic zoom. This prevents the send button from being hidden and makes it easier for visitors to type and send messages smoothly.
Original PR description
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would…
Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%. This zoom would hide send button at the very end of composer input, and would force users to pinch-to-unzoom, making the UX quite poor. This problem happens because mobile devices have an auto-zoom feature that is triggered when font-size is below 16px. The discuss UI is designed with 14px font size (web client font size), and since 14px < 16px, it zooms on input focus to about 115%. This commit fixes the issue by using a font-size of 16px specifically for livechat visitor on mobile devices, so that this doesn't auto-zoom. Note that this problem doesn't happen on the web client even though this uses a font-size of 14px because it specifically disable the autozoom feature: https://github.com/odoo/odoo/blob/17.0/addons/web/views/webclient_templates.xml#L250 This solution is not practical for livechat, for which it has to work on any external website. opw-5229076 Before <img width="199" height="431" alt="after" src="https://github.com/user-attachments/assets/cc2f8e04-bde7-4eeb-84d5-b2efa2763490" /> After <img width="199" height="431" alt="before" src="https://github.com/user-attachments/assets/6c6679fc-9c16-40e7-ab6f-21540d20d59d" /> Forward-Port-Of: odoo/odoo#235182 Forward-Port-Of: odoo/odoo#234967
The website editor could crash when users tried to edit the appointment booking page. This update prevents the error by handling non-page elements safely, so editing the page works normally again.
Original PR description
**Steps to reproduce:** - Install website_appointment_sale with demo data - Start booking an appointment and stop at the `Date & Time` selection page - Open the `website editor` and click the `edit`…
**Steps to reproduce:**
- Install website_appointment_sale with demo data
- Start booking an appointment and stop at the `Date & Time` selection page
- Open the `website editor` and click the `edit` option
- A traceback occurs
**Issue:**
- A traceback occurs when trying to edit the page,
Error:
`TypeError: blocker.hasAttribute is not a function
at selection_blocker_predicates`
**Cause:**
- The `selection_blocker_predicates` function assumed every `blocker` was an Element
and called `blocker.hasAttribute(...)`. When a non-element node (text, comment, or object)
was encountered, the call raised a 'TypeError'.
<img width="778" height="177" alt="image" src="https://github.com/user-attachments/assets/7ef14d01-56e0-45b7-a39e-3e9fb6a4c6ce" />
> nodeType = 3 then it’s a `text node`
https://github.com/odoo/odoo/blob/700fac2532d2de6abc6f87e30a5b056dcfc109d1/addons/html_editor/static/src/main/selection_placeholder_plugin.js#L39-L45
**Solution:**
- Make the function defensive by checking that `blocker` is an instance of `Element`
- before accessing DOM methods. Non-element nodes are now safely check.
---
opw : 5241222
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix makes sure POS invoice lines are properly included in the HSN validation used for the GSTR-1 report. As a result, items missing an HSN code are more reliably flagged, while older POS lines that lack unit details stay out of the check.
Original PR description
Previously, POS move lines from the original POS entries were not considered during the HSN validation in the GSTR-1 report. As a result, lines without an HSN code were incorrectly skipped from the warning check. This commit updates the domain logic to ensure that: - POS move lines with a Unit of Measure (UoM) but without an HSN code are now included in the check. - Older POS lines without a UoM remain excluded from validation. opw-5252620
17 changes
Resolved issues and error corrections
This change cleans up an overly complex style rule used in spreadsheet side panels. It makes the code easier to maintain and reduces the risk of future styling issues without changing the user experience.
Original PR description
Because of a really strong rule in o_spreadsheet lib that forced the box-sizing property pretty much everywhere, we came up with a super dense rule to counteract it inside odoo and specifically inside the side panels. This commits aims to simplify it at best with the common denominator of those rules. Task-4878174
This change corrects how spreadsheet inputs are displayed when they are missing or invalid, so the warning state is always visible. It also prevents dark mode styling from breaking the spreadsheet’s default layout, improving consistency for users.
Original PR description
Following the style revamp of the o-spreadsheet lib, we introduced a class o-input (differs from odoo o_input) in order to avoid collision with the odoo classes which tend to be altered in dark mode which spreadsheet does not support. However, we still relied on the default behaviour of odoo classes to mark specific inputs as invalid or missing. This commit ensures that missing/invalid are always marked as such while make preventing the dark mode to break the default layout. Task-4878174 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 change prevents event tickets from being switched into a rental-style setup that the website event registration flow cannot handle. It avoids a payment-time error and keeps event ticket setup consistent so customers can register without issues.
Original PR description
Steps ----- 1. Have `sale_renting` but not `sale_stock_renting` installed; 2. create an event with a ticket; 3. make the ticket's product rentable; 4. change ticket's product type to Goods; 5. publish the event to website; 6. register for the event via website; 7. go to payment. Issue ----- > AttributeError: 'bool' object has no attribute 'tzinfo' Cause ----- By making it a rental product, it creates a rental order, but as registering for an event via website doesn't have any way to add rental dates, rental lines cannot be processed & rendered as expected. Solution -------- Prevent users from changing the `service_tracking` away from `'event'` by adding an `api.constrains` to `product.product` on `service_tracking` and `event_ticket_ids`. opw-5207045
This update fixes issues in spreadsheet data sources and filters so broken connections now return the correct error instead of failing silently. It also removes a confusing clear button when a filter is invalid, making the interface clearer and more consistent.
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
This change prevents spreadsheet filter screens from crashing when a datasource or filter is broken after a migration or model change. It also makes cleanup easier by showing delete options more consistently, helping users repair spreadsheets and keep working without errors.
This fix prevents mega menu links from showing when their content is not available to the current visitor. It avoids empty dropdowns and unnecessary navigation items on both desktop and mobile, making the website cleaner and less confusing for users.
Original PR description
Before this commit, when setting the mega menu content visibility, the navbar link would still appear even if the user does not have access to the mega menu content. This commit hides the navbar link for the mega menu in the mobile and desktop view when the user does not have access to the mega menu content, in order to prevent unnecessary elements in the navbar. Steps to reproduce the bug: - Add a mega menu element in the navbar - Open the mega menu - Set the mega menu content visibility to conditional (logged in) - Open the website while logged out (The mega menu link is here but the content is not displayed. However, the dropdown is still opened but it is empty.) task-3992066
This update corrects a styling issue in the live chat visitor view on mobile devices. It prevents the message input from auto-zooming unexpectedly, making the chat experience smoother and easier to use on phones.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/234967 Style rule was not applied due to missing `&` in SCSS, which this commit fixes. Forward-Port-Of: odoo/odoo#235216
This fix prevents a table embedded inside another table from expanding beyond the boundaries of its parent cell when resized. As a result, the content remains editable and users can continue working without layout issues.
Original PR description
**Current behavior before PR:** - When a table was created inside another table, resizing the inner table could cause it to overflow its parent cell, making it uneditable. **Desired behavior after PR is merged:** - The inner table no longer overflows its parent cell when resized, ensuring it remains editable. task-5216916 Forward-Port-Of: odoo/odoo#233554
This update fixes a warning generated by some calendar view components when they were missing expected properties. It helps keep the system quieter and avoids potential issues in automated checks without changing how the calendar works for users.
Original PR description
Some Components used by the calendar view did not have props set, which triggered warnings on the runbot. This has been corrected in saas-17.2 with odoo/odoo@dd583fd670e0ee03b04711780bad2429b18a0788 In the meantime, to avoid warnings, we just set props = ["*"] to avoid breaking the component's API related PR for which the runbot warns: https://github.com/odoo/enterprise/pull/98903 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#234563
This change fixes an error that could happen when Odoo checks which message was last seen by everyone in a conversation. It makes the check more reliable by using the member record directly, preventing crashes when some related user details are missing.
Original PR description
The `lastMessageSeenByAllId` compute function sometimes crashes when the persona linked to a member is unknown. This occurs because the compute function compares the member's persona to determine if it belongs to the current user. However, members are not always sent along with their persona. The compute function should instead compare the member directly to the current user's member. This fixes the issue and makes more sense. 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 change fixes a test that could fail when running on Python 3.11 and later because record ordering was not being handled consistently. It helps keep the barcode batch module reliable across supported Python versions, preventing false test failures during development and deployment.
Original PR description
*: stock_barcode_picking_batch Steps to reproduce ================== Use python > 3.10 Run the test test_pack_batch_in_multiple_packages It fails on assertRecordValues, the records are not in the same order Cause of the issue ================== Recordsets ordering is not stable across python versions. It is implemented as `return set(self._ids) < set(other._ids)` https://github.com/odoo/odoo/blob/8a026b875a9b70f12689cdbd71d7e54b987d0612/odoo/models.py#L6636 Since this is a subset check, it always returns false when called with different ids Solution ======== Compare using the id directly opw-231140 Forward-Port-Of: odoo/enterprise#99118
The fleet tax report logic and its test were moved out of the Community build and into the Enterprise module where the needed vehicle data exists. This fixes a build failure in Community and keeps the fleet-specific reporting working where it is supported.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462
A fleet-specific tax reporting test and its supporting query were moved into the Enterprise version where the needed vehicle data is available. This prevents community builds from failing while preserving the intended fleet tax reporting behavior for Enterprise users.
Original PR description
Community build was failing with: ``` FAIL: TestAccountFleet.test_tax_report_with_vehicle_split_repartition Traceback (most recent call last): File '/data/build/odoo/addons/account_fleet/tests/test_account_fleet.py', line 99, in test_tax_report_with_vehicle_split_repartition self.assertEqual(len(tax_details), 2) AssertionError: 0 != 2 ``` The test and SQL join logic relied on `vehicle_id` propagation that only exists in the enterprise addon `account_accountant_fleet`. Since the community edition cannot populate `vehicle_id` on tax lines, the query always returned zero rows, causing the failure. To fix this, the fleet-specific tax report query and test have been moved to the enterprise module, where the vehicle-aware tax reporting functionality actually resides. This keeps community builds green while retaining the intended behavior in enterprise. runbot error:233462
This update prevents Serbian VAT numbers from being stored with the country prefix twice in generated XML files. It helps ensure partner tax information is exported in the correct format and avoids issues with downstream processing.
Original PR description
By setting for a Serbian partner a VAT with the prefix RS, they will have a duplication of the country code in the XML Ticket [link](https://www.odoo.com/odoo/project.task/5126028) opw-5126028
This update fixes several issues in Uruguay vendor bill synchronization and XML imports. It now processes all bills found in an uploaded XML, improves document identification for manually imported and automatically synced bills, and stores the XML attachment for easier tracking and troubleshooting.
Original PR description
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was…
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was processed. Now all the CFEs are processed. 3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 4) Create xml attachment in the edi document if it is created by drag and drop xml file. 5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 6) Cron is run by batches (size=10). 7) Add tests. The suffixes -manual and -notification are used to differentiate between EDI documents generated manually and those generated automatically. This is useful to determine whether the document was created by a user or by an automated process, also helps users identify its origin more easily and also it is useful for debugging and tracking purposes. Task Adhoc side: 43467 Task latam side: 1355
Signed documents now remain visible to both the person who requested the signature and the person who signed it. This fixes an issue where the requester could not find the completed document in Documents, improving access and document tracking.
Original PR description
To reproduce: ============= - as a User U with Admin rights on Documents (not Sys Admin) - create a folder at the root of the company - create a Sign Request template using this folder as signed document folder - send the Sign Request to another user O and sign it with that user O - go to Documents app with user U and check the folder where the signed document should be - the signed document is not there Problem: ======== when creating signed documents, the access rights for the requester are not set, causing the requester to not see the signed document Solution: ========= give `view` access right on signed documents to both the requester and the signer if they don't already have `edit` access right on it or ownership opw-[5087233](https://www.odoo.com/web#id=5087233&view_type=form&model=project.task)
This update makes the POS correctly show an error when the Belgian blackbox or IoT box is disconnected. It also informs staff when an order could not be sent to the preparation display, helping avoid hidden ordering issues and confusion during service.
Original PR description
Steps to reproduce: 1. Configure POS with Belgian blackbox and preparation display 2. Clock in as normal and start an order 3. At this point, disconnect the Blackbox or the IoT box 4. Try to order some more items Expected behaviour: - An error message is received, informing the user of the blackbox error AND telling them the order has not been sent to the preparation display. Actual behaviour: - In the case the IoT is connected but the blackbox is not - The POS is stuck with a loading spinner forever - A prepration order is printed but not sent to the prepration display - In the case the IoT box is disconnected - An IoT box network error dialog shows, but it does not mention the blackbox or preparation display - A prepration order is printed but not sent to the prepration display The cause of this is that we were previously ignoring the result of the blackbox action. The fix is just to save the result and handle it appropriately. task-5253038
10 changes
Resolved issues and error corrections
This update fixes an error that could appear when opening the Accounts Coverage Report for Spanish balance sheet reports. It ensures the report data is loaded and interpreted correctly, so users can view the report without a traceback.
Original PR description
Step to reproduce: - for Spain localization, in developer mode: - Go to Balance sheet - Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES) - Click on the parameters button…
Step to reproduce:
- for Spain localization, in developer mode:
- Go to Balance sheet
- Select either report 'Balance sheet - SMEs (ES) or Complete Balance Sheet (ES)
- Click on the parameters button
- Click on the "Accounts Coverage Report"
Observation:
- we receive a traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "%(balance_sheet_11700_account)d"
LINE 1: ...ccount_tag" WHERE ("account_account_tag"."id" IN ('%(balance...
```
Cause:
- few records used a wrong format style for values of `domain_formula`
- These faulty domains were not [evaluated](https://github.com/odoo/odoo/blob/2070e30c540a066fb80851527e5e54e97fb23c4b/addons/account/models/account_report.py#L450-L453), but inserted into database as is.
- when browsing account.tag record using these domain, record ids were expected,
instead we got its string representation , causing traceback
https://github.com/odoo/enterprise/blob/8fa6fb27d2a79ee299361b281dc82182feee5860/account_reports/models/account_report.py#L5679-L5680
Fix:
- we fix the data file, which is properly evaluated and stored in database.
- Manifest's data file order is changed, so that account tags is loaded first.
opw-5224114This update fixes an issue where the background image of the website “text cover” snippet could disappear on mobile or when the page is zoomed in. It keeps the cover visible so pages look consistent across screen sizes.
Original PR description
Steps to reproduce: =================== - Go to website and add a "text cover" snippet - Zoom in on the page or switch to mobile view -> The cover's background image disappears Cause: ====== A Bootstrap rule applied `d-md-block` to the cover image container on screens (specifically when width >= 768px, which can be removed by zooming). https://github.com/odoo/odoo/blob/b093786714e9e8567cf75abf78ac3d954a3d89b2/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L8624 So `d-none` will be applied once d-md-block is removed. Solution: ========= Remove the `d-none` rule from this element to ensure the background image remains visible. A workaround is included for non-updated views until master. opw-5219747 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes a test in the barcode batch workflow so it runs reliably on Python 3.11 and later. It improves compatibility across Python versions and prevents false test failures during validation.
Original PR description
*: stock_barcode_picking_batch Steps to reproduce ================== Use python > 3.10 Run the test test_pack_batch_in_multiple_packages It fails on assertRecordValues, the records are not in the same order Cause of the issue ================== Recordsets ordering is not stable across python versions. It is implemented as `return set(self._ids) < set(other._ids)` https://github.com/odoo/odoo/blob/8a026b875a9b70f12689cdbd71d7e54b987d0612/odoo/models.py#L6636 Since this is a subset check, it always returns false when called with different ids Solution ======== Compare using the id directly opw-231140
This update corrects how Odoo identifies serial ports on Raspberry Pi 5 devices. It prevents the built-in port from being shown as an available external device, reducing confusion and avoiding incorrect device selection.
Original PR description
The serial interface previously included a filter to not include the built-in serial port on the Pi 5, however this filter is now broken in Raspberry Pi OS Trixie. To ensure the filter works in all versions, we now explicitly look for the device `/dev/ttyAMA10` and ignore it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening Studio on a calendar view now works even when the view includes fields with access groups. This prevents the calendar editor from crashing and makes customization more reliable for users.
Original PR description
Have a calendar view that has a field A. the field A has a group on it, defined either in python or in the XML. Before this commit, opening studio in the calendar view crashed, because calendar did not support yet those fields that are marked with studio_no_fetch in their attributes. After this commit, there is no crash
This change prevents warning messages from appearing in Odoo’s calendar views during automated checks. It does this by giving the affected calendar components a generic set of accepted properties, which keeps their behavior stable while avoiding unnecessary noise.
Original PR description
Some Components used by the calendar view did not have props set, which triggered warnings on the runbot. This has been corrected in saas-17.2 with odoo/odoo@dd583fd670e0ee03b04711780bad2429b18a0788 In the meantime, to avoid warnings, we just set props = ["*"] to avoid breaking the component's API related PR for which the runbot warns: https://github.com/odoo/enterprise/pull/98903 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 change makes the Swiss payroll transmission tests independent from accounting setup, so they can run more reliably in different environments. It also adjusts payslip validation so a payroll structure can be validated even when some accounting configuration is missing, reducing unnecessary test failures.
This update ensures the Kanban view returns to a normal record limit after a grouping is removed and the view is restored. It prevents the web client from loading too many records at once, which could slow down the page or cause it to crash.
Original PR description
Steps to reproduce ================== - Add a group by in the kanban product view - Switch to the list view - Remove the group by - Switch back to the kanban view -> No limit is applied, and the webclient can crash if too many records are returned. Cause of the issue ================== The groupsLimit is set as MAX_SAFE_INTEGER in the kanban view https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/views/kanban/kanban_controller.js#L168 Which is then reused as the limit https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/model/relational_model/relational_model.js#L368 Solution ======== There is already a code path to reset the limit when switching from grouped to ungrouped, but is wasn't called on the first load (when this.root isn't set yet) opw-5167769
This change fixes an issue where some BACS batch payments could be exported with the wrong amount due to rounding errors. It ensures the payment amount is written correctly in the batch file, preventing underpayment or mismatches during bank processing.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413
This fix restores the ability to choose previously saved payment details when registering a payment for a customer invoice. It matters because businesses can again reuse stored payment methods for the right customer, avoiding failed payment setup and extra manual work.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a sales order for a company partner; 2. create & copy a payment link; 3. open payment link in new session; 4. using demo provider, make the payment & save payment details; 5. add an invoice address to the company partner; 6. create an invoice for the company partner using the invoice address; 7. confirm invoice; 8. click "Register Payment"; 9. select "Demo" as payment provider. Issue ----- The saved payment token cannot be selected. Cause ----- Before commit 75f4008, the company partner was used to search for tokens in the payment register wizard. After the commit, the the invoice partner is used, making it impossible to select previously accessible payment tokens. Solution -------- Search payment tokens linked to either partner. opw-5193718