Daily updates from Odoo
Wednesday, November 12, 2025
101 changes
15 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#96746When 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 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
This update corrects how job listings are counted and shown to visitors based on their location, even when they are not logged in. It also fixes an issue where duplicate location results could lead to incorrect counts being displayed, improving the accuracy of job search and redirection behavior.
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. Forward-Port-Of: odoo/odoo#234713
This change prevents an access error that could appear when a purchase order uses an unrestricted analytic account shared across companies. It ensures users only see budget lines they are allowed to access, avoiding interruptions when entering purchase orders.
Original PR description
Steps to reproduce: - Create an analytic account [ACCOUNT] not restricted to any company - Create an analytical distribution model applying [ACCOUNT] to [PRODUCT] not restricted to any company - Create a budget in company [COMP A] using analytic account [ACCOUNT] - Create a budget in company [COMP B] using analytic account [ACCOUNT] - In company [COMP B], create a purchase order, add [PRODUCT] to a line Issue: Access Error is raised Analysis: Because we search with sudo company rules are bypassed and the system assign both budget lines to the order line (budget_line_ids). When we access the field, the system try to access the budget line of the other company, causing the error. As solution we revert https://github.com/odoo-dev/enterprise/commit/4941c1928c9a2bcb38af3cadf023f904c9fd9be0 removing the `sudo` on the search and we explicitly check if the user has read access on the budget analytic model opw-5056712 Forward-Port-Of: odoo/enterprise#98573
This change stops event ticket products from being changed into a rental setup, which could break the online registration and payment flow. It helps ensure attendees can always complete booking and payment for event tickets without errors.
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 Forward-Port-Of: odoo/odoo#234705
This fix restores automatic cost updates on sale order lines after an order has been confirmed, canceled, and then reset to draft. It matters because sales margins and pricing can now reflect the correct purchase cost again, even after order status changes.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a product with a purchase cost; 2. have sale margins enabled; 3. add a the product to a quotation; 4. change pricelist to one with a different currency; 5. note that the line's cost gets updated; 6. change order state to confirmed, then canceled, then back to draft; 7. change pricelist again. Issue ----- The purchase cost no longer update. Cause ----- The `_compute_purchase_price` override in `sale_stock_margin` doesn't pass the line to `super` if it `has_valued_move_ids`. This hook only checks for the existence of linked `move_ids` on the record with no regard for their state. Solution -------- 1. Move the `has_valued_move_ids` hook from `sale` to `sale_stock`. 2. Only return `True` if any of the moves aren't in draft or canceled. opw-5147321 Forward-Port-Of: odoo/odoo#233746
This change prevents the website editor from crashing when a user presses Delete without an active text selection. It improves stability during common editing actions, especially when working with embedded content like videos and snippets.
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 Forward-Port-Of: odoo/odoo#232643
The website now publishes product price information in a way that matches the shop’s tax display setting. This prevents search engines and other consumers of the page markup from seeing a different price than visitors see on the website.
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#235106
Forward-Port-Of: odoo/odoo#22557716 changes
Enhancements to existing features
This change speeds up how Odoo calculates invoice and journal entry amounts, especially when there are many lines to process. It reduces waiting time and memory usage, which makes large accounting operations noticeably faster and more efficient.
Original PR description
Currently performance on `_compute_amount()` is bottlenecked by `__get__()` calls on fields on `line_ids`. We tackle this bottleneck by warming the cache with `fetch()` Benchmark on reconciling 2 account moves with ~70k lines each | |Total Time|Allocated Memory|Queries| |----------|----------|----------------|-------| |Before |43.23s |2GB |993 | |After |18.60s |1GB |693 | opw-5098543 Forward-Port-Of: odoo/odoo#234656
The point of sale now shows clear error messages when the fiscal device is disconnected or when the social security number is missing. It also tells users what to do next, which should reduce confusion and help staff resolve issues faster.
Original PR description
We now display an error when the FDM is disconnected, or when the user needs to fill in the social security number. We also advise what to do in such cases.
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 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 editor now correctly displays overlay borders and snippet options when the site uses a right-to-left language such as Arabic. This prevents the editing tools from appearing misplaced or hidden, improving the experience for teams managing multilingual websites.
Original PR description
__Before this commit__: 1. Set a right-to-left language (e.g. arabic) as default language on the website 2. Open the website editor 3. Select an element of the page => The editor overlay border are…
__Before this commit__: 1. Set a right-to-left language (e.g. arabic) as default language on the website 2. Open the website editor 3. Select an element of the page => The editor overlay border are not in the correct place 4. Open the snippet dialog => The snippets are not visible. __Cause__: Since [this commit][1], `lang` in `session.bundle_params` is (correctly) set to the `request.lang.code`. Consequently, `website.assets_all_wysiwyg_inside` is fetched with the frontend language code in the `searchParams` which shouldn't be the case especially if the website language direction is not the same as the backend one. __Description of the fix:__ The `getBundle` method from outside the iframe is used instead of the frontend one to retrieve the URL of the bundle that matches the language direction of the builder. Backport and adapt the test from [this commit][2]. [1]: https://github.com/odoo/odoo/commit/e10852a45f10c55a833c33a51956e5f [2]: https://github.com/odoo/odoo/commit/7bcd56c07852b77849b05184200c48a task-5246916 opw-5214703 Forward-Port-Of: odoo/odoo#234991 Forward-Port-Of: odoo/odoo#234782
This fix stops event ticket products from being changed into a product setup that breaks online registration and checkout. It ensures tickets keep the right tracking rules, so customers can register for events and complete payment without errors.
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 Forward-Port-Of: odoo/odoo#234705
This change prevents an access error that could occur when creating a purchase order in a company that shares an unrestricted analytic account with another company. It ensures budget information is checked safely so users only see budget lines they are allowed to access, avoiding interruptions during purchasing.
Original PR description
Steps to reproduce: - Create an analytic account [ACCOUNT] not restricted to any company - Create an analytical distribution model applying [ACCOUNT] to [PRODUCT] not restricted to any company - Create a budget in company [COMP A] using analytic account [ACCOUNT] - Create a budget in company [COMP B] using analytic account [ACCOUNT] - In company [COMP B], create a purchase order, add [PRODUCT] to a line Issue: Access Error is raised Analysis: Because we search with sudo company rules are bypassed and the system assign both budget lines to the order line (budget_line_ids). When we access the field, the system try to access the budget line of the other company, causing the error. As solution we revert https://github.com/odoo-dev/enterprise/commit/4941c1928c9a2bcb38af3cadf023f904c9fd9be0 removing the `sudo` on the search and we explicitly check if the user has read access on the budget analytic model opw-5056712 Forward-Port-Of: odoo/enterprise#98573
Sales order lines now correctly refresh their cost after an order has been canceled and set back to draft. This prevents outdated margin and pricing information from sticking around when the pricelist or currency changes.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a product with a purchase cost; 2. have sale margins enabled; 3. add a the product to a quotation; 4. change pricelist to one with a different currency; 5. note that the line's cost gets updated; 6. change order state to confirmed, then canceled, then back to draft; 7. change pricelist again. Issue ----- The purchase cost no longer update. Cause ----- The `_compute_purchase_price` override in `sale_stock_margin` doesn't pass the line to `super` if it `has_valued_move_ids`. This hook only checks for the existence of linked `move_ids` on the record with no regard for their state. Solution -------- 1. Move the `has_valued_move_ids` hook from `sale` to `sale_stock`. 2. Only return `True` if any of the moves aren't in draft or canceled. opw-5147321 Forward-Port-Of: odoo/odoo#233746
3 changes
Resolved issues and error corrections
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 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
This change prevents an access error that could appear when using the same unrestricted analytic account across multiple companies. It ensures purchase orders only check budget information the current user is allowed to read, avoiding interruptions for users working in company-specific budgets.
Original PR description
Steps to reproduce: - Create an analytic account [ACCOUNT] not restricted to any company - Create an analytical distribution model applying [ACCOUNT] to [PRODUCT] not restricted to any company - Create a budget in company [COMP A] using analytic account [ACCOUNT] - Create a budget in company [COMP B] using analytic account [ACCOUNT] - In company [COMP B], create a purchase order, add [PRODUCT] to a line Issue: Access Error is raised Analysis: Because we search with sudo company rules are bypassed and the system assign both budget lines to the order line (budget_line_ids). When we access the field, the system try to access the budget line of the other company, causing the error. As solution we revert https://github.com/odoo-dev/enterprise/commit/4941c1928c9a2bcb38af3cadf023f904c9fd9be0 removing the `sudo` on the search and we explicitly check if the user has read access on the budget analytic model opw-5056712 Forward-Port-Of: odoo/enterprise#98573
9 changes
Enhancements to existing features
The US Profit and Loss reports have been updated to make key sections easier to read and compare. This improves financial report clarity for users reviewing business performance, without changing the underlying accounting data.
Original PR description
Purpose: Improve the layout of the US Profit and Loss reports to enhance visualization of important sections. task-5231683
Applicants can no longer use interview scheduling links once their application is archived, refused, or hired. Future linked interview meetings are archived automatically, preventing outdated bookings while preserving past meeting history.
Original PR description
This PR aims to restrict the applicant from scheduling any further appointments if the application is archived, refused, or contract-signed. Additionally, all previous appointments will be archived from the calendar task - 4715325
UAE payroll calculations now include unpaid leave and out-of-contract days when determining gross salary. This improves payroll accuracy and helps ensure salary figures better reflect employee work and leave circumstances.
Original PR description
- Add a new rule category to include unpaid leave and out-of-contract rules in the gross salary computation. Task: 5079110
Belgian accounting reports now display pre-payment amounts and balances more appropriately based on the return type and status. The inventory analytical review check now focuses on fixed assets rather than receivables, making the review better aligned with its business purpose.
Original PR description
* = account , l10n_be In this commit: --- For Pre-Payment: - Changed the Account return Kanban view logic to ensure `amounts` and `balances` are displayed appropriately depending on the return type and state just for Be Reports. For Inventory Analytical Review: - Update the `Inventory analytical review` check to filter by `Fixed Assets` instead of `Receivables`. task-5065775
SEPA payment users can now choose an instruction priority, with the relevant normal and high options available. If no priority is selected, payments default to normal, helping ensure consistent payment processing behavior.
Original PR description
Before this commit:
SEPA payments did't have an instruction priority option, and no default value
'NORM' was set. Only ISO20022 payments supported priority selection.
After this commit:
Added instruction priority to SEPA payments.
For SEPA, only relevant options ('NORM', 'HIGH') are used for the selection.
Also, 'NORM' is now set as the default priority if nothing is defined.
task-4890052A default attendance ruleset is now provided so employees can have attendance records created without manual setup. It includes standard handling for overtime and non-working days, reducing setup errors and keeping behavior consistent with migration data.
Original PR description
## PR Purpose It's impossible to create an attendance for an employee without a ruleset. To solve this problem, this PR adds a default ruleset with 2 rules: one for overtime, and another one for non working days. Those data are the same as the data added in the upgrade/migrations/hr_attendance/saas~18.5.2.0 post-migrate script. [Task#5082628](https://www.odoo.com/odoo/all-tasks/5082628) [Community#234628](https://github.com/odoo/odoo/pull/234628) [Upgrade#8684](https://github.com/odoo/upgrade/pull/8684) Forward-Port-Of: odoo/enterprise#95421
Resolved issues and error corrections
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
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
29 changes
Enhancements to existing features
The point-of-sale receipt step is being streamlined by removing the separate receipt screen and using the feedback screen instead. This keeps the customer journey simpler while preserving existing features and integrations, so businesses should see the same outcomes with fewer steps.
Original PR description
pos*: l10n_br_edi_pos, l10n_it_pos, whatsapp_pos This commit aims at removing the receipt screen and replacing it with the feedback screen. Of course, the feedback screen needs some adaptations done in this commit to keep every existing feature. task-id: 5149815
The point-of-sale checkout flow has been simplified by replacing the separate receipt screen with the feedback screen. This keeps the same receipt-related features while reducing an extra step for staff and making the end-of-sale experience more consistent across POS setups.
Original PR description
pos*: point_of_sale, pos_restaurant This commit aims at removing the receipt screen and replacing it with the feedback screen. Of course, the feedback screen needs some adaptations done in this commit to keep every existing feature. task-id: 5149815 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update speeds up how tax returns are generated and refreshed, making the related accounting screens and setup wizard respond faster. It also fixes a case where manually created draft returns could be incorrectly removed before being posted.
Original PR description
- batched _compute_company_ids on returns - batched return to unlink in _generate_or_refresh_all_returns - removed redondant call to _generate_or_refresh_all_returns in…
- batched _compute_company_ids on returns - batched return to unlink in _generate_or_refresh_all_returns - removed redondant call to _generate_or_refresh_all_returns in action_save_onboarding_fiscal_year since we want to call it only when a value is changed and that's already handled in the write on the company. - batched _is_available_for on reports - make only one write on the company (and one call to _generate_or_refresh_all_returns) when writing or create the fiscal year wizard. - dont delete return created manually with a date before the date of the account_opening_date and not yet posted. Detected from runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231463 A small workaround is needed on the company when writing the changes from the fiscal year wizard. This is because related fields are writen one by one, which then trigger multiple times _generate_or_refresh_all_returns. To prevent this, we are batching all the write on the company from the fiscal year wizard in one write. The opening_date need to be handled separatly since it's not a related field but still need to be writen on the company, if removed from the vals during the create it's then not possible to save the wizard anymore. Also fixed a bug where the returns manually created before the account_opening_date would be deleted if they were not posted before the next call to _try_create_returns_for_fiscal_year. **Detailed Explanation** We can see the tour being broken when trying to save on the wizard: <img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/9443251c-aee1-4fbe-be2f-27c11bcbb77d" /> So we can do a flamegraph to take a look at what's happening on that database during that time and we can see 2 majors time uses, a call to `_generate_or_refresh_all_returns` triggered by a write on the wizard and a call to `action_save_onboarding_fiscal_year` <img width="1396" height="855" alt="image" src="https://github.com/user-attachments/assets/a9d310da-2787-4806-951d-e50b8c1da2a8" /> The first call to `_generate_or_refresh_all_returns` took about 7.8s, the second one took about 1.1s First, we can see a lot of `_compute_company_ids` calls, this is because we have `precompute=True` on this field due to it being needed in the different access rules. Since all the returns that are created have similar main company, tax unit and return type, we can easily batch them to only call `_get_company_ids` once for all the returns that will be created. Resulting in the following flamegraph: <img width="1422" height="866" alt="image" src="https://github.com/user-attachments/assets/c52c88c7-0263-44fb-a16c-52456673dc92" /> The first call to `_generate_or_refresh_all_returns` took about 0.8s, the second one took about 1.2s Another little change we can do is to remove the call to `_generate_or_refresh_all_returns` during `action_save_onboarding_fiscal_year` and adding the forced_date from the first one to the second one. <img width="1294" height="844" alt="image" src="https://github.com/user-attachments/assets/7ad55d06-ecd4-4957-b514-71fffa6de00c" /> We now end up with one call to `_generate_or_refresh_all_returns` that takes 1.4s BUT, we can still do better. We can see that all we did previously was only do to one thing less. The "real" problem was the many search calls done in `_is_available_for` during the `_init_options_variants`. <img width="1268" height="693" alt="image" src="https://github.com/user-attachments/assets/ebae398d-dfdd-4c1e-99ac-44f25e5875e7" /> After the final change, we are down to 0.9s ! One thing to keep in mind, all those flamegraph were done on a dump of a database from a nightly test, which had many companies created as well as **every** modules installed, which means every return types, reports, ... This means those performance improvements wont be as useful on small databases.
The Swiss QR payment code now uses the updated structured address format for both creditor and debtor information. This change aligns Odoo with the current Swiss QR standard and helps ensure payments continue to be generated correctly.
Original PR description
Change creditor's and debtor's address to a structured format of type S. Old type K is discontinued. Port of odoo/odoo#232083 with additional tests. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
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
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
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
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-5221403A 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 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 change lets employees and other users read work entries even if they are not attendance managers. It removes an access-rights error that could block normal viewing of work entry information, improving day-to-day usability.
Original PR description
When we try to read the work entries, we've got an access rights error if we are not attendance manager. As we are still supposed to read the work entries, we get the attendance interval in sudo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The fiscal year setup wizard now correctly applies changes to the company even when the wizard starts with default values. This reduces the risk of duplicate updates and makes the setup flow more reliable in more scenarios.
Original PR description
When writing value with the wizard, we wrote the value of related field of the company to prevent multiple write from happening. Now, we handle the write too in case the wizard is created with default value instead of created beforehand. It's also now possible to specify the fields that are to be written to handle more cases in overrides. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents Spreadsheet from crashing when freezing or sharing a view that includes a boolean global filter. It ensures Excel exports handle empty filter values safely, improving reliability for users working with shared spreadsheets.
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#235123 Forward-Port-Of: odoo/odoo#232784
This fix ensures the product cost on sales order lines can be updated again after an order has been confirmed, canceled, and reset to draft. It matters because cost and margin calculations will stay accurate when users revisit and adjust a quotation.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a product with a purchase cost; 2. have sale margins enabled; 3. add a the product to a quotation; 4. change pricelist to one with a different currency; 5. note that the line's cost gets updated; 6. change order state to confirmed, then canceled, then back to draft; 7. change pricelist again. Issue ----- The purchase cost no longer update. Cause ----- The `_compute_purchase_price` override in `sale_stock_margin` doesn't pass the line to `super` if it `has_valued_move_ids`. This hook only checks for the existence of linked `move_ids` on the record with no regard for their state. Solution -------- 1. Move the `has_valued_move_ids` hook from `sale` to `sale_stock`. 2. Only return `True` if any of the moves aren't in draft or canceled. opw-5147321 Forward-Port-Of: odoo/odoo#233746
This update fixes an issue that prevented PIN codes from being encoded correctly in the Belgian POS blackbox flow. It also improves error handling so the system reacts more reliably when an operation fails or succeeds after being queued.
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
This change stops event ticket products from being switched into a rental setup that the event website flow cannot handle. It prevents a checkout error during event registration and keeps tickets working correctly for customers.
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 Forward-Port-Of: odoo/odoo#234705
20 changes
New functionality added to Odoo
This update adds the French “Plan Comptable Associatif” as an available chart of accounts in Odoo. It means French nonprofit organizations can now use the standard accounting structure they need for their bookkeeping and financial reporting.
Original PR description
## Description of the issue/feature this PR addresses: Add the French "Plan Comptable Associatif" to the available charts of accounts Reference: https://www.associations.gouv.fr/le-nouveau-plan-comptable-applicable-depuis-le-1er-janvier-2020.html ## Current behavior before PR: ## Desired behavior after PR is merged: French NPOs are allowed to use Odoo for their accounting work. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update refreshes the official Luxembourg payroll rule numbers for 2025. It helps ensure payroll calculations stay aligned with the latest legal requirements and reduces the risk of incorrect withholding amounts.
Original PR description
Update the official numbers of the Luxembourg payroll rules for 2025. This is a backport of PR https://github.com/odoo/enterprise/pull/79805 task-5187202 Forward-Port-Of: odoo/enterprise#98763
The point of sale payment screen now shows a “force done” option even when a payment line is stuck waiting on a terminal response. This helps cashiers continue serving customers instead of getting blocked by an unresponsive payment device.
Original PR description
If a payment line is stuck in a waiting state (e.g. payment terminal not responding to a request), we now display the "force done" button, to avoid blocking the user. Forward-Port-Of: odoo/odoo#235244
Resolved issues and error corrections
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 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 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
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
This change fixes how rounding is applied in several accounting test scenarios, helping ensure totals and reconciliations behave as expected. It also updates outdated comments and test values so they better reflect real cases, reducing the risk of confusion and regressions.
Original PR description
Also fixes the comments that were wrong. Change some values to better test things 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 update fixes an intermittent issue where a Knowledge article could open in the wrong state after reorganizing articles in the sidebar. It makes the editor reliably show the article the user clicked, improving stability during normal editing and reordering workflows.
Original PR description
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously…
Before this commit, the `test_knowledge_main_flow` tour sometimes failed. That tour creates articles, then d&d one of them in the sidepanel to re-organize articles, and then clicks on a previously created article to continue editing it. The tour failed on that step, as the previously created clicked article wasn't properly selected/displayed in the editor. The race condition was that two (non synchronized) calls to the `load` function of the model were done: one after the move because the move could have altered the displayed article (1) and one because we selected another article to open by clicking in the sidebar (2). (1) is done without resId (reload the current article) and (2) is done with the id of the clicked article. Depending on the order these two calls are done, we end up with the clicked article displayed (if (2) is done after (1)), or with the current article still displayed, but reloaded ((1) done after (2)). This commit fixes the race condition by forcing the reload of the current record for (1), instead of blindly reloading the model, which might have changed/been requested something else meanwhile. runbot error~182073
This change ensures product cost on a sales order line can be updated again after an order has been confirmed, canceled, and reset to draft. It fixes a case where the cost could stop refreshing, which helps keep margin calculations accurate when the pricing currency changes.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a product with a purchase cost; 2. have sale margins enabled; 3. add a the product to a quotation; 4. change pricelist to one with a different currency; 5. note that the line's cost gets updated; 6. change order state to confirmed, then canceled, then back to draft; 7. change pricelist again. Issue ----- The purchase cost no longer update. Cause ----- The `_compute_purchase_price` override in `sale_stock_margin` doesn't pass the line to `super` if it `has_valued_move_ids`. This hook only checks for the existence of linked `move_ids` on the record with no regard for their state. Solution -------- 1. Move the `has_valued_move_ids` hook from `sale` to `sale_stock`. 2. Only return `True` if any of the moves aren't in draft or canceled. opw-5147321 Forward-Port-Of: odoo/odoo#233746
Opening Studio from a calendar view now works even when one of the calendar fields is restricted by group settings. This fixes a crash that previously blocked users from editing those calendar views in Studio.
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 Forward-Port-Of: odoo/enterprise#98903
This fix restores the ability to use previously saved payment methods when paying an invoice. It matters because customers who saved their card or payment token during an earlier payment can now select it again instead of having to re-enter payment details.
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 Forward-Port-Of: odoo/odoo#234173
8 changes
Enhancements to existing features
The official payroll figures used for Luxembourg have been updated to match the 2025 rules. This helps ensure employee payroll calculations remain accurate and compliant with the latest official values.
Original PR description
Update the official numbers of the Luxembourg payroll rules for 2025. This is a backport of PR https://github.com/odoo/enterprise/pull/79805 task-5187202
When a payment line gets stuck waiting for a payment terminal response, the POS now shows a “Force Done” option. This helps staff move forward instead of being blocked by an unresponsive terminal.
Original PR description
If a payment line is stuck in a waiting state (e.g. payment terminal not responding to a request), we now display the "force done" button, to avoid blocking the user.
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
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 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