Daily updates from Odoo
Tuesday, June 23, 2026
45 changes · saas-19.3
Resolved issues and error corrections
This update resolves a critical issue where VoIP registration would fail due to a delayed response when a user left a session open and inactive. The fix ensures a new registration attempt is made when the initial request times out, preventing error dialogs and restoring VoIP functionality. It improves the reliability of the VoIP service for users.
Original PR description
Leaving a session open and idle (page open, no activity at all) eventually pops an error dialog: UncaughtPromiseError > RequestPendingError REGISTER request already in progress, waiting for final…
Leaving a session open and idle (page open, no activity at all) eventually pops an error dialog:
UncaughtPromiseError > RequestPendingError
REGISTER request already in progress, waiting for final response
at Registerer.register (sip.js)
at Registerer.register (registerer.js)
at UserAgent.attemptReconnection (user_agent_service.js)
When the WebSocket transport drops while a REGISTER is in flight (which happens on an idle tab: SIP.js sends a periodic re-REGISTER before the registration expires, and the socket may be closed by an idle timeout or by the machine going to sleep in the meantime), the final response never comes back. SIP.js only clears its internal `waiting` flag from the REGISTER response callbacks (onAccept/onReject/onRedirect); it is never reset on transport loss or request timeout. The Registerer is then stuck `waiting` forever, and every subsequent register() rejects with a RequestPendingError.
On top of that, our wrapper's register() did not return the SIP.js promise, and attemptReconnection() called it without awaiting, so the rejection escaped the surrounding try/catch and surfaced as an unhandled promise rejection. Worse, the WebSocket error was resolved right after, so the user appeared reconnected while VoIP registration was actually dead until the page was reloaded.
This commit makes register() recreate the underlying SIP.js Registerer when it is stuck `waiting` (a clean instance starts with waiting=false), and return the promise so callers can await it. attemptReconnection() now awaits it, so any rejection goes through the existing retry/back-off logic instead of bubbling up as an uncaught error.
The recreation is intentionally conditional: disposing a healthy registerer would send an unregister (REGISTER expires=0) racing with the fresh register (expires=600) and could leave us unregistered, so we only recreate when a request is actually stuck.
Forward-Port-Of: odoo/enterprise#120487
Forward-Port-Of: odoo/enterprise#119701This update resolves an issue where the FEC export wizard was generating empty lines with zero balances for certain accounts. The fix ensures accurate reporting of opening balances, particularly when prior-year entries result in zero balances, improving the reliability of financial data exports for French companies using the l10n_fr_account module.
Original PR description
Steps to reproduce: - Use a French company (l10n_fr_account installed) - Post prior-year entries so that an account/partner nets to zero at the start of the next fiscal year (e.g. a customer invoice fully paid the same year, or a misc entry debiting and crediting the same balance-sheet account), and keep another account/partner with a non-zero opening - Open the FEC export wizard, set Start Date to the first day of the next year - Generate the FEC file and look at the "Balance initiale" (OUVERTURE) lines Issue: One of the exported line in as empty one with `...|0,00|0,00|..`` opw-6083991 Forward-Port-Of: odoo/odoo#270658 Forward-Port-Of: odoo/odoo#268510
This update resolves an issue where the payment authorization process would fail if a required address field was left blank. The fix ensures that empty address fields are now handled gracefully by setting them to empty strings, preventing errors and improving data accuracy. This enhances the reliability of payment transactions.
Original PR description
Fix bug introduced by commit https://github.com/odoo/odoo/pull/267592/changes/c4556637e8eeef07ce6e3cc3b3b4cf28fa10e468 that caused an error if an address field was not set, due to trying to cut a False field. Now, unset fields are set to empty strings. Forward-Port-Of: odoo/odoo#270295
This update ensures that prettified links in portal chatter messages remain functional after a page refresh. Previously, a refresh would break these links. The fix involves sending the correct thread name to ensure the links are properly formatted and displayed to users.
Original PR description
Before this commit, a message link posted on a portal chatter would lose it's prettified link (introduced in [1]) upon page refresh. This happens because `prepareMessageBody` needs the thread's `displayName` to create the prettified message link, which is not sent on portal chatter init. This commit fixes the issue by sending the thread's `display_name`. [1] https://github.com/odoo/odoo/pull/221069 task-6204819 Forward-Port-Of: odoo/odoo#270032 Forward-Port-Of: odoo/odoo#263488
This update fixes an issue where the spreadsheet filter dropdown remained open even when the filter value hadn't changed. The fix ensures the dropdown automatically closes after a filter selection, providing a more consistent and user-friendly experience. This improves the overall usability of the spreadsheet dashboard.
Original PR description
Current behavior before PR: - In b4d5d1f, added early return when filter value is unchanged. - However, the dropdown was not closed in this case, leaving it open after clicking the filter button, resulting in inconsistent and unexpected UX. Desired behavior after PR is merged: - Ensure the dropdown is closed even when the filter value remains unchanged, restoring consistent and expected behavior. Task: [6304213](https://www.odoo.com/odoo/project/2328/tasks/6304213) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271298 Forward-Port-Of: odoo/odoo#270225
This update resolves a technical issue related to how Odoo handles direct debit mandates for SEPA accounts. The change adds a constraint to ensure the correct bank account is linked to the mandate, improving the reliability of direct debit payments. This ensures accurate and secure processing of payments.
Original PR description
Forward-Port-Of: odoo/enterprise#121236 Forward-Port-Of: odoo/enterprise#120901
This update resolves an issue where manually adding serial-tracked by-products to manufacturing orders caused errors when closing production. The fix ensures that all move lines, including those with manually assigned serial numbers, are correctly processed within the shopfloor workflow, preventing user error messages.
Original PR description
**Issue** Adding a serial-tracked by-product manually on a Manufacturing Order whose BOM does not define it, can lead to inconsistencies when assigning serial numbers in the shopfloor application.…
**Issue** Adding a serial-tracked by-product manually on a Manufacturing Order whose BOM does not define it, can lead to inconsistencies when assigning serial numbers in the shopfloor application. **Steps to reproduce** - Activate by-product in the settings - Create a product with an empty BOM (final product) - Create another product tracked by serial number (by-product) - Create and confirm a MO for the final product with 1 unit of the by-product - Go to Miscellaneaous -> operation Type -> shopfloor - Activate the option "Pre fill lot/serial numbers in shop floor" - Return to the MO and open the shopfloor view - Click on the '+' button next to the by-product and assign a serial number - Try to close the production -> A user error is raised stating that the by-product requires a serial number. **Cause** When the by-product is added manually on the MO, a stock move is created with an initial move line that does not contain any serial number. Later, when assigning a serial number from the shopfloor view: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L121-L122 a new move line containing the serial number is created: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L116-L119 However, the original empty move line is not removed (the issue): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/mrp_workorder/models/stock_move.py#L124-L125 Because `self.picking_type_prefill_shop_floor_lots` is True, but `self.byproduct_id` is an empty recordset since: https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1304-L1311 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/mrp/models/mrp_production.py#L1279 Indeed, `byproduct_id` is only populated from BOM-defined by-products. As a result, while confirming the production, there is 2 sml and among them, the original one without SN, which triggers the error: https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L590 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L634-L635 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L658-L659 https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/addons/stock/models/stock_move_line.py#L661-L669 opw-6223158 Forward-Port-Of: odoo/enterprise#120493 Forward-Port-Of: odoo/enterprise#118792
This update adjusts the accounting classification for a specific inventory account (502040) within the Philippine localization module (l10n_ph). The account type has been changed from 'Expenses' to 'Current Assets' to align with updated accounting standards and reporting requirements. This ensures accurate financial reporting.
Original PR description
Update the account type of 502040 Inventory/Stock Variation account from ` Expenses` to `Current Assets`. task-6299228
This update corrects a technical issue related to barcode scanning tests within the Point of Sale and POS Stock modules. The test steps for a specific EAN-13 barcode pattern have been moved to the `pos_stock` module where the relevant rules are defined. This ensures more accurate and reliable barcode scanning functionality.
Original PR description
In this commit:
=
- The test steps covering the EAN-13 barcode pattern `21.....{NNDDD}` have been moved from `point_of_sale` to `pos_stock` because the rule for this barcode pattern is defined in `stock`.
runbot-error-242912This update resolves an issue where a key test partner wasn't consistently loaded during demo data setup. By renaming the test partner to 'A Partner Full', the system now guarantees it's included, ensuring consistent and reliable testing of the Point of Sale (POS) functionality. This improves the accuracy of test results and reduces potential issues during development.
Original PR description
Issue:
=
* The test partner name ("Partner Full") was not guaranteed to be loaded with demo data because only the first 100 partners are loaded, and the record could fall outside that limit.
Fix:
=
* Rename the test partner from "Partner Full" to "A Partner Full" to ensure it is included with demo data too.
runbot-error- 243063, 939228This update fixes an issue where preparation times weren't correctly calculated when order stages changed and ensured the preparation time report only displayed data for the active company. This improves the accuracy of order processing times and reporting, leading to better business insights.
Original PR description
Issues: - Preparation time for order lines was not computed when the preparation order stage changed. - Preparation time report aggregated orders across all companies instead of showing records for the active company only. Fixes: - Ensure preparation time is properly recomputed when the order stage changes. - Add company domain filtering to the preparation time report. Task-6250974 Forward-Port-Of: odoo/enterprise#118738
This update significantly speeds up appointment scheduling, particularly when managing multiple resources like tables in a restaurant. The change optimizes how the system checks resource availability, resulting in faster loading times and quicker auto-assignment processes. This improves the overall user experience and efficiency.
Original PR description
In the current code, for each slot, and for each "available" resource, we check if the resource is available on the slot, based on availability values. Then, we check the remaining capacity of that…
In the current code, for each slot, and for each "available" resource, we check if the resource is available on the slot, based on availability values. Then, we check the remaining capacity of that resource. Also, linked resources information is added when computing the original resource remaining capacity. If many linked resources exist, this will be done several times and is not useful. This commit makes that loop disappear. We now check all resources at once in terms of availability, and linked resources that could be selected (in the appointment resources, in the slot resources (if any restricted resource)) at the same time. Then, the total capacity is the sum of the resource remaining capacity and the ones of available linked resources. Therefore, _slot_availability_is_resource_available is renamed to _slot_available_resources, as it now takes more than one resource and returns all resources among 'resources' that are valid on the slot, based on the availability_values, slot restrictions and booking lines. A noticeable difference is mainly seen when using many resources (and linked resources). For instance, a restaurant with a lot of small tables will have their slot availability check much shorter. BENCHMARK, LOCAL (time only, as number of requests does not change) Only appointment installed For a restaurant with - 10 tables of 2 - 5 tables of 2 linked, 2 times - 10 tables of 4 - 2 table of 2 - time then auto assign On loading /appointment/id: ~ 3.1s -> ~ 1.6s On selecting any number of people (1 to 10): [2s, 2.5s] -> [0.6s, 0.8s] Task-4144524 Forward-Port-Of: odoo/enterprise#121212 Forward-Port-Of: odoo/enterprise#107711
This update resolves a confusing warning message that appeared during bill editing, related to vendor history. The fix prevents temporary data inconsistencies from triggering these warnings, creating a smoother and more intuitive editing process for users. The warning is now only calculated when the bill is saved, ensuring a better user experience.
Original PR description
Abnormal bill warnings are based on vendor history read from the saved move in the db, while a bill is being edited the form uses a temporary record; after changing the vendor, that temporary value differs from the vendor still stored on the saved move. This makes the warning use the old vendor's history while showing the new vendor's name. Only compute these warnings for saved records, while editing hide them and let them be recomputed once the bill is saved. task-6263829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270515
This update corrects a technical issue within the spreadsheet module that was preventing data hover functionality from working correctly. The fix resolves a previous bug that masked the problem, ensuring accurate and reliable data visualization for users. This improves the overall user experience when working with charts and data in the spreadsheet.
Original PR description
### [FIX] spreadsheet: fix arguments of `onDataSetHover` The arguments of `onDataSetHover` were wrong. It was not apparent because there was another bug that caused the function to never be called. Task: [6233312](https://www.odoo.com/web#id=6233312&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where event titles were sometimes saved as "(no title)" when users quickly saved events using the alt+c keyboard shortcut. The fix ensures that all event titles are correctly saved, regardless of how the event was created, improving the user experience and data accuracy.
Original PR description
When creating an event using the quick create form from the calendar view if the user saves the record while the title is still being edited (using alt+c) the record will be saved with the default title: "(no title)" The code currently relies on the record data being up to date by the time onRecordSave is reached. However in the case of a text field, it is only saved when blurred. While there is a mechanism to blur the field when saving using a hotkey, it is completely asynchronous from the save logic of the form. To ensure all fields have comitted their data at save time, the framework has a mechanism to "request changes" which notifies all fields to update the record with their latest value and waits for them to do so. We can simply reuse this mechanism to ensure the data is up to date at recordSave time already, as we don't expect fields to have any changes after it. task-6321702
This update fixes an access error that prevented users from viewing employee type information within the payroll module. The change ensures users with the correct payroll group permissions have full access, resolving a potential disruption to payroll processes. This was identified during upgrades to version 19.3.
Original PR description
The field `employee_type_id` in models `hr.version` and `hr.employee` is used by the `hr` module. The group is overriden in `hr_payroll`, but the model can still be accessed by users without the required group `hr_payroll.group_hr_payroll_user`, triggering an `AccessError`.
To reproduce:
- On 19.3, install `hr_payroll`.
- Remove any Payroll access from the current user.
- Go to Employees > Configuration > Employee > Employee Types.
```
File "/home/odoo/src/odoo/saas-19.3/odoo/orm/models.py", line 2732, in check_field_access
raise AccessError(error_msg)
odoo.exceptions.AccessError: You do not have enough rights to access the field "employee_type_id" on Employee Contract (hr.version). Please contact your system administrator.
Operation: read
User: 6
Groups: allowed for groups 'Payroll / Assistant'
```
Found during upgrades to 19.3This update resolves an issue where the table of contents would obscure headings when the status bar was sticky. The fix dynamically adjusts the table of contents' position to avoid overlapping sticky elements, ensuring headings are always visible and easily accessible. This enhances the user experience when navigating long documents.
Original PR description
Since [1] when the `o_form_statusbar` status bar was made `sticky` the table of content scrolls to a given heading without taking it into account. Because of this, when scrolling upwards the heading ends up behind the status bar. This commit fixes this by finding top-aligned sticky elements within the closest scrollable element impacted by the table of content. Steps to reproduce: - Go to a To do note - Define some headings - Have sufficient content so that reaching a heading requires scrolling - Define a table of content with `/toc` - Click on a heading => The heading ended up behind the status bar. [1]: https://github.com/odoo/odoo/commit/a3c63413825cf3492a10ade77a2c571c4eeb33a6 task-6302762 Forward-Port-Of: odoo/odoo#270043
This update fixes an issue where Odoo was incorrectly selecting unavailable couriers from Shiprocket. The change now filters out 'blocked' couriers, ensuring only serviceable options are considered for rate calculations and shipment selection. Additionally, the system is more robust to handle potential errors in Shiprocket's data, preventing shipment delays.
Original PR description
Shiprocket provides an odablock flag in the courier serviceability response. Couriers with odablock=True are not serviceable for the requested route and should not be considered for rate calculation or selection. Before this change, Odoo selected the first courier returned by Shiprocket regardless of its ODA status. As a result, unavailable couriers could be proposed to users and selected for shipments. The fix filters out ODA-blocked couriers before evaluating available services, ensuring that only serviceable couriers are considered. Additionally, freight charge parsing is hardened to gracefully handle non-numeric values returned by Shiprocket, preventing errors during AWB assignment and price computation. FYI: Shiprocket uses odablock=False for serviceable routes and odablock=True for routes that are blocked for a given courier. opw-6288768,6152279 Forward-Port-Of: odoo/enterprise#120374
This update fixes an issue where the number of comments displayed on course slides wasn't accurately reflecting the actual number of comments. The change adjusts how comments are calculated to account for recent updates to the platform's messaging system. This ensures a more accurate and reliable view of course discussions.
Original PR description
Steps to reproduce: - Open a slide of a course in non fullscreen mode (website). - Go to the comments tab and add a comment in the chatter. - The comments count does not change in the tab. - The same thing happens when a comment is deleted. - Another way to see the incorrect counter is to add a note in the slide form view (backend). Before this change, `website_slides` used `website_message_ids` to calculate the comments. Since #138233 the old portal chatter has been replaced with the mail chatter and the way messages are displayed on the portal has changed. For example notes are no longer considered portal messages and also deleted messages should not be displayed or counted as such. This change ensures that comments calculations are based on a domain that considers those changes meaning that comments will be synced with the actual number of available comments. Forward-Port-Of: odoo/odoo#271247 Forward-Port-Of: odoo/odoo#260376
This update fixes a problem where self-order receipts lacked important company information like the logo, address, and contact details. Now, all relevant company and PoS settings are included on self-order receipts, improving customer experience and providing consistent branding.
Original PR description
Before this commit: ---------------- - Order receipts generated from self-orders were missing several company and PoS configuration details, such as the company logo, receipt address, phone number, email, and website. After this commit: ---------------- - Order receipts generated from self-orders now include all relevant company and PoS configuration details. Task-6271261 Forward-Port-Of: odoo/odoo#268789
This update resolves an issue where text entered into SelectMenu fields (like Campaign or Source) would intermittently disappear. The fix ensures the input field accurately reflects user typing, even after autocomplete suggestions are refreshed. This improves the user experience when searching within these fields.
Original PR description
Step to reproduce: 1. Install `website_link` 2. Open Website > Site > Link Tracker 3. Type in text into any pre-defined field (Campaign, Medium, Source) 4. Observe that the input is not showing all…
Step to reproduce: 1. Install `website_link` 2. Open Website > Site > Link Tracker 3. Type in text into any pre-defined field (Campaign, Medium, Source) 4. Observe that the input is not showing all the typed characters Issue: - It's randomly removing characters, for example, type "1234567890" and observe Cause: - SelectMenu updates its internal searchValue only inside the debounced onInput handler `debouncedOnInput`. When an autocomplete callback reloads choices before that debounce fires, the component rerenders with a stale searchValue and writes that outdated value back into the controlled input, overwriting newer characters already typed by the user. Solution: - Update searchValue immediately on every raw input event and keep only the search callback debounced. - Also reset searchValue to null when a required single-select is blurred while empty, so the input falls back to the selected choice label instead of staying visually cleared. opw-6000540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267974 Forward-Port-Of: odoo/odoo#255819
This update corrects a technical issue within the Odoo’s Danish accounting module (l10n_dk) where an account was listed twice. Removing this duplication ensures accurate financial reporting and data integrity. This change improves the reliability of financial transactions for Danish businesses using Odoo.
Original PR description
In the list 'dk_coa_7630 ', the account has been used in the list twice. Removing the duplication from the list. [Reference](https://github.com/odoo/odoo/blob/17.0/addons/l10n_dk/migrations/1.4/end-migrate.py#L14) 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#270865 Forward-Port-Of: odoo/odoo#270573
This update resolves an issue where sign templates with auto-filled fields would incorrectly display placeholders instead of the actual values, or fail to generate documents. The fix ensures falsy values from auto-fields are properly preserved during the signing process, preventing errors and guaranteeing accurate document generation.
Original PR description
Version: - 19.0 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the linked field value is empty or False. - Send the…
Version: - 19.0 Steps to reproduce: - Create a sign template with a readonly sign item linked to an auto field. - Use a reference record where the linked field value is empty or False. - Send the document for signing. - Complete the signing flow. Issue: - Readonly sign items linked to auto-filled values could not properly handle falsy values. Empty values could trigger the error "Some required items are not filled" and completed sign requests displayed the sign item placeholder instead of the actual auto-filled value. - completed document generation could fail when rendering falsy values for textarea sign items. Cause: - Falsy auto-filled values were ignored during constant item population and replaced by the sign item placeholder. Additionally, readonly constant items were included in required field validation and completed sign requests continued to display placeholders when the stored value was empty. - document rendering assumed sign item values were always strings for textarea sign items but when auto field is empty it value can be False. Fix: - Preserve falsy values when populating readonly constant items, exclude constant items from signer validation, and hide placeholders for empty auto-filled constant items when displaying completed sign requests. - Normalize falsy values to prevent crashes and allow completed documents to be generated correctly. Forward-Port-Of: odoo/enterprise#121255 Forward-Port-Of: odoo/enterprise#121009
This update fixes issues where mass email campaigns were failing due to incorrect server selections. Specifically, personal email servers were being inadvertently used, causing campaigns to get stuck in the queue. The changes ensure that personal servers are excluded from mass mailing selections, improving campaign delivery reliability.
Original PR description
A personal outgoing mail server is an `ir.mail_server` that belongs to one user. The system only lets that user send through it. Mass mailings do not always respect this, which can cause a few…
A personal outgoing mail server is an `ir.mail_server` that belongs to one user. The system only lets that user send through it. Mass mailings do not always respect this, which can cause a few problems: 1. Admins cannot duplicate a personal server. The copy keeps the same owner, and the rule that says one user can own only one server stops the save. 2. In *Email Marketing > Settings*, the "Dedicated Server" picker offers every server, even personal ones. If an admin picks a personal one, all campaigns get stuck. The cron job runs as Odoobot, the personal server rejects it, and the mailing stays in the queue. 3. When no dedicated server is set, the fallback selection can still land on a personal server (for example because its `from_filter` matches the sender). The cron sends through it and gets rejected. One commit per problem: 1. **mail**: duplicating a personal server now produces a copy with no owner. 2. **mass_mailing**: the picker in the settings hides personal servers. Setting an owner on a server that is already used for mass mailing now raises a clear error that names the campaign blocking the change. 3. **mass_mailing**: personal servers are skipped when the fallback selection runs, so only shared servers are considered. opw-6086077 Forward-Port-Of: odoo/odoo#271115 Forward-Port-Of: odoo/odoo#261537
This fix resolves an issue where extra prices were incorrectly added to POS orders when using 'always' attributes for products. The change ensures that extra prices are now set on the combo creation page for 'always' attributes, aligning with the intended product variant behavior and preventing double-counting.
Original PR description
## Steps to reproduce - Create an attribute A, of type always, with 2 values, one should have an extra price - Create an attribute B, of type never, with 2 values - Create a product that has both…
## Steps to reproduce - Create an attribute A, of type always, with 2 values, one should have an extra price - Create an attribute B, of type never, with 2 values - Create a product that has both those attributes - Create a combo with that product with both values for A - Go to the PoS and order that combo with the value that has an extra price for A - The extra price is added ## Why the fix: For variants of type always, a product is created, meaning we can chose which products of this variants to have in our combo. As we can chose this, it means that we can and should chose the extra price on the combo creation page, not on the attribute page. It does not make sense to take the attribute extra price into account, as we do not take the unit price of combo items into account, so this extra price should be set on the combo page and we should ignore the attribute's extra price if the type is "always". The variants are then considered as different products, as they should in this case. If the type of the attribute is never, we can't chose which one gets an extra price on the combo page, so we should still take the attribute's extra price in this situation, as we have no other way to set it. We need to have both an always and a never attribute in order to reproduce this bug because if we only have "always" values, the configuration of the combo item is bypassed and is undefined, so **attribute_value_ids** will be undefined in this code and we won't get any value for the extra price in this code: https://github.com/odoo/odoo/blob/c09e8b2fc24ee75495fc947924e29cf5c601506f/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L44-L49 We now ignore the attribute's extra price if it's type is always, otherwise, it the behavior stays the same. opw-6262431 Forward-Port-Of: odoo/odoo#270894 Forward-Port-Of: odoo/odoo#268567
This update resolves an issue where recurring plans would disappear when updating a subscription product's quantity. The fix ensures that the selected plan is correctly recomputed and displayed after changes, improving the user experience for subscription management. It addresses a conflict arising from checks related to one-time purchase options.
Original PR description
# Introduction note This PR fixes two bugs introduced by the same commit : https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa The original commit fixed multiple issues…
# Introduction note This PR fixes two bugs introduced by the same commit : https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa The original commit fixed multiple issues regarding the display of recurring plans when the One-time purchase option was enabled, but it also introduced new ones. Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this variable only indicates that the One-time purchase option is available to the user, not that it is actually selected. So the fixes of the original commit works when first loading the page, but fails when the content of the page is updated. # Shared steps - Activate Subscriptions & eCommerce modules - Create a subscription product, enable 'Accept One-Time' and publish it on the website # Bug 1 ## How to reproduce - Add atleast two recurring plans to the product - Go to the product page on the website - Select one of the recurring plans - Increase the quantity of the product ## The problem The recurring plan selection is removed ## Cause The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are recomputed and rerendered : https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40 When that is the case, that condition blocks the proper display of the selected recurring plan. ## Proposed Solution When loading the recurring plan selection, what defines wich plan is selected is the `subscription_default_pricing_plan_id` variable, which is based on the `plan_id` value given in the request to the server : https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222 We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is enabled, then the server does not give back any `subscription_default_pricing_plan_id` opw-6131532 # Bug 2 ## How to reproduce - Add an attribute with values A & B for the product - Define atleast two recurring plans for the variant with attribute B - Publish the product - Go to the product page - Select the variant with attribute B ## The problem The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected. ## Cause The pricings are correcly sent to the front-end but they are not added to selection because of the check on `allow_one_time_sale` : https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50 opw-6132160 Forward-Port-Of: odoo/enterprise#120873 Forward-Port-Of: odoo/enterprise#115446
This update fixes a bug that prevented website options using composite actions from functioning correctly. Specifically, when a composite action with a 'getValue' was used, it wouldn't properly bind, leading to errors. A new test has been added to ensure correct action binding, improving website configuration stability.
Original PR description
In 18.4 the composite action isn't used extensively, so the problem was unnoticed. However, if you use it with an action that has a `getValue` set, you may get issues, since the action will not be bound. Possible way to reproduce the issue: - Create an option that uses the `composite` action - Set `customizeWebsiteVariable` as a first action in the `actionParam` - Click on an element that has that option => You'll get an error. Note, that testing just this would be useless, so I added a test that tests that the action uses the first `getValue`. Without this fix the test would crash since in `getValue` `this` is unbound. Forward-Port-Of: odoo/odoo#269873
This update resolves an issue where appointment invitations were sometimes sent even when appointments were in a 'requested' or 'cancelled' status. The change ensures invitations are only generated for appointments marked as 'booked', improving the user experience and preventing unnecessary notifications. This was addressed based on a related issue in the Enterprise version.
Original PR description
This PR adapts the code to fix the invitations at the appointments' update. See the enterprise PR to get more information about the issues. Enterprise PR: https://github.com/odoo/enterprise/pull/114304 Task-6139036 Forward-Port-Of: odoo/odoo#271116 Forward-Port-Of: odoo/odoo#260073
This update corrects errors in how appointment invitations are sent, ensuring they're only triggered for 'booked' or 'requested' appointments. Previously, invitations were sent regardless of appointment status, leading to unnecessary emails and incorrect notifications. This ensures accurate and timely appointment confirmations for users.
Original PR description
This PR fix three issues related to the sending of the appointment invitations. Each one has its own commit: - Commit 1 sends invitations only if the event either "booked" or "request". Previously they were sent even if the appointment was cancelled. - Commit 2 prevents the sending of regular invitations and always sends appointment invitation to new attendees of existing booked appointments. - Commit 3 sent appointment invitations if the status of an existing event is set "request". It also add the status change in the log as it would have been if it was done at the creation. Community PR: https://github.com/odoo/odoo/pull/260073 Task-6139036 Forward-Port-Of: odoo/enterprise#121213 Forward-Port-Of: odoo/enterprise#114304
A recent update caused the Point of Sale system to incorrectly add the 'S' variant when scanning a barcode for the 'M' variant of a product with dynamic attributes. This fix ensures that the correct variant is added based on the scanned barcode, improving the accuracy of sales transactions. The change corrects a logic error in how the system handles product variants with dynamic attributes.
Original PR description
Steps to reproduce ------------------ 1. Create a product with two attributes: - Size with values S and M (Variants Creation: "Instantly") - a second attribute with a single value (Variants Creation: "Dynamically") 2. Set a different barcode on the S and the M variant. 3. Open PoS, scan the barcode of M. -> The S variant is added instead. Why the issue ------------- In 390b48a1ba24, when a product has a single-value attribute set to "dynamic", we look for the first variant that has this value and use it instead of the preselected variant. This is wrong when several variants share this value: in our case both S and M have it, so scanning M is overridden by the first variant, S. The fix ------- We now keep the preselected variant if it already has this value, and only look for or create one otherwise. opw-6272739 Forward-Port-Of: odoo/odoo#268590
This update corrects a bug where reordering rules were incorrectly creating purchase orders linked to sales orders. Now, reordering rules will always generate new, separate purchase orders, ensuring accurate inventory management and preventing duplicate purchase orders. This improves order fulfillment efficiency.
Original PR description
Steps to reproduce the bug: - Go to contact: - azure interior: - Group RFQ: On Order - Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor - Confirm a sale…
Steps to reproduce the bug:
- Go to contact:
- azure interior: - Group RFQ: On Order
- Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor
- Confirm a sale order with P1 (MTO+Buy):
- a purchase order PO1 is created, linked to the sale order via reference_ids
- Create a reordering rule for P2 and trigger it
Problem:
The reordering rule procurement for P2 was merged into PO1 (the sale order's purchase order) instead of creating a new separate PO.
In _make_po_get_domain (purchase_stock/models/stock_rule.py), when group_rfq == 'default' (On Order), the domain only adds a reference_ids filter when the procurement carries reference_ids. When the procurement comes from a reordering rule (no sale order, no reference_ids), no filter was added, so the search matched any draft PO from that vendor, including PO1, which has reference_ids pointing to the sale order.
Solution:
When group_rfq == 'default' and the procurement has no reference_ids, add ('reference_ids', '=', False) to the domain so the search only matches POs that are also not linked to any sale order.
opw-6167835
Forward-Port-Of: odoo/odoo#270735This update resolves a bug where overtime was incorrectly generated when using timing rules with employer tolerances. The fix ensures that attendance limits are properly considered during overtime calculations, preventing unnecessary overtime charges. This improves accuracy and reduces potential payroll discrepancies.
Original PR description
**Version:** - 19.0 **Steps to reproduce:** - Create a rule of Timing type. - Add a tolerance for the employer. - Set the ruleset on the employee. - Add an attendance of less than the tolerance. **Issue:** - When using a Timing type rule with employer tolerance, overtime is still created even if the attendance is below the tolerance limit. **Cause:** - The timing rule calculation was missing the tolerance check that exists in the quantity rule calculation. **Fix:** - Added the missing tolerance check in the timing rule calculation. - Removed employee tolerance from view for timing rules. **Task-6064081** Forward-Port-Of: odoo/odoo#257079
This update ensures that the chatter within Odoo accurately reflects the employee who made changes to tracked orders. Previously, the system incorrectly attributed changes to the original order cashier. This fix uses the current session employee to provide accurate tracking, improving order management and reporting.
Original PR description
**Steps to reproduce:** - Enable "Track orders edits" in the settings - Enable "Log in with Employees" - Go to the Restaurant, log in with employee A - Go to a table, order 3 Sushis - Go back to the…
**Steps to reproduce:** - Enable "Track orders edits" in the settings - Enable "Log in with Employees" - Go to the Restaurant, log in with employee A - Go to a table, order 3 Sushis - Go back to the floor plan and change to employee B - Go back to the table and change the qty of 3 Sushis to 2 Sushis - Go to the order in the backend and check the chatter - It will indicate that employee A did the change, but it was employee B **Why the fix:** We always used the cashier set on the order to determine who should be put in the chatter, regardless of who is actually connected at that point. We now use the session's current employee to write who did the change in the chatter. We do not change the order's employee, because it will be done once the order has been paid. In the case where we are not logged in but pos_hr is installed, the employee_id might be the id of a res.user, and browsing it might return the wrong value. To avoid this, we check if the value exists as a hr.employee before assigning the name. The way we return the value has been changed because the linter wasn't happy about it. opw-6213504 Forward-Port-Of: odoo/odoo#270768 Forward-Port-Of: odoo/odoo#265582
This update clarifies the budget report by replacing generic labels like 'Budget 2026 x' with more specific names that include the associated analytic accounts. This makes budget lines easier to understand and differentiate, improving reporting accuracy and user experience.
Original PR description
Budget report grouping by budget line displayed the budget name for every line, which made different lines indistinguishable and produced labels like "Budget 2026 x", "Budget 2026 x (2)", etc. Compute a more specific display name for budget lines by appending the analytic accounts concerned by the line to the budget name. Also expose Budget Line as a first-class group-by in the Budget Report search view and apply it by default when opening the report. task-6293065 Forward-Port-Of: odoo/enterprise#121204
This update removes a restriction on phone number formatting during event registration. This simplifies the user experience and allows for more flexible input when signing up for events within the Point of Sale system. The change was made to address a minor technical issue and improve usability.
Original PR description
Following this commit: ===== - '+' constraint from number validation is removed while user register for any new event. task-6194962
This pull request updates the core spreadsheet component with several improvements and bug fixes. It addresses issues related to chart rendering, viewport behavior, and formula parsing, ensuring a more stable and reliable spreadsheet experience for users. These changes were made to enhance performance and address reported user issues.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/da121002d2 [REL] 19.3.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/da121002d2 [REL] 19.3.8 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/9c9ea4006a [FIX] viewport: fix viewport jump with frozen pane [Task: 6292764](https://www.odoo.com/odoo/2328/tasks/6292764) https://github.com/odoo/o-spreadsheet/commit/8c5b03b36e [FIX] composer_tokenizer: fix argument separator in formulas [Task: 6303210](https://www.odoo.com/odoo/2328/tasks/6303210) https://github.com/odoo/o-spreadsheet/commit/4a9480b602 [IMP] node: add script to run the model in node [Task: 6088515](https://www.odoo.com/odoo/2328/tasks/6088515) https://github.com/odoo/o-spreadsheet/commit/b9dd4f4ae4 [FIX] package.json: Update Node.js and npm engine requirements [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5856475544 [FIX] carousel: custom color don't use carousels [Task: 6263128](https://www.odoo.com/odoo/2328/tasks/6263128) https://github.com/odoo/o-spreadsheet/commit/396acb35d2 [FIX] charts: pie chart shows empty chart for text entries [Task: 6275525](https://www.odoo.com/odoo/2328/tasks/6275525) https://github.com/odoo/o-spreadsheet/commit/ed39af1898 [FIX] charts: pass `onDataSetHover` to chart config [Task: 6233312](https://www.odoo.com/odoo/2328/tasks/6233312) https://github.com/odoo/o-spreadsheet/commit/3baf99b853 [FIX] table: correctly insert table on static pivots [Task: 6204984](https://www.odoo.com/odoo/2328/tasks/6204984) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update corrects a previous issue where the invoice status cron job only processed invoices for the main company within an Odoo instance. Now, it correctly fetches and updates the status of invoices across all companies within the system. This ensures accurate invoice tracking and reporting.
Original PR description
The invoice status cron was only fetching the main company's invoices. Fetch all companies' invoice statuses. Reference: https://github.com/odoo/odoo/pull/267144#discussion_r3441968099 no-task Forward-Port-Of: odoo/odoo#271227
This update resolves a crash that occurred when users tried to view Instagram videos within Odoo. The fix now displays the video link instead of attempting to render the video as an image, ensuring a stable preview experience. This improves usability and prevents disruptions for users accessing Instagram content.
Original PR description
Purpose ======= When we have a real on Instagram, we try to show the video as an image. When clicking on the broken image, the previewer crash. To fix that issue, we know show the link of the video in the message. Task-5491124 Forward-Port-Of: odoo/enterprise#121176 Forward-Port-Of: odoo/enterprise#113487
This update fixes an issue where bank verification timestamps were incorrectly interpreted, leading to display errors for users in Poland. The change converts timestamps from the local Polish timezone to UTC, ensuring accurate display and preventing incorrect time conversions.
Original PR description
The gov API returns a 'requestDateTime' in str format in PL timezone. This commit converts it back to UTC timezone for a better display in payment form. fields.Datetime assume the value is in UTC time and so when a field of this type is displayed, it's converted to the user timezone. This cause issue with the PL API call because the API will send us 9:25 PL TZ but if we store it directly, it will be interpreted by the ORM as 9:25 UTC and displayed to the user that's in UTC+2 as 11:25 task-6314380 Forward-Port-Of: odoo/odoo#270839
This update fixes an issue where scanning an unknown barcode in the POS system didn't automatically open the product creation form. The fix removes a redundant check for API keys, ensuring the form opens correctly regardless of whether a key is configured. Users can now seamlessly create products by scanning barcodes.
Original PR description
When scanning an unknown barcode in POS, the product creation form was never opened because `barcode_lookup()` was called with no barcode as an implicit API key check. Commit 0c8019a4aa7 ([FIX] product_barcodelookup: avoid crash on invalid image URLs) standardized `barcode_lookup_request()` to always
return a `requests.Response` object, removing the `{'authenticated': True}` dict it previously returned for HTTP 404 responses. As a result the JS check `response?.authenticated` was always falsy and the form never opened.
Fix: remove the API key check entirely. `allowProductCreation()` already gates on the user having product create rights, which is the only condition that matters. If a Barcode Lookup API key is configured the `_onchange_barcode` on the form will auto-fill product data; if not, the user can fill it in manually. Either way the form is always usable.
opw-6295221
Forward-Port-Of: odoo/enterprise#120256This update resolves a problem where users were incorrectly denied access to WhatsApp templates within the Event management system. The fix prevents users from creating new WhatsApp templates, which was causing the 'User does not have access' error. This ensures proper WhatsApp template functionality for events.
Original PR description
Issue: 1) User goes to Event.event Form -> communication tab -> add line 2) Select whatsapp -> type something -> create and edit -> create new template with any model event.registration -> save ( all the way including the event form) 3) reload page -> whatsapp event.mail displays "User does not have access to this record". Fix: add "'no_create_edit': True" to the associated field in the xml to block creation of new mail.templates opw-6037488 Forward-Port-Of: odoo/odoo#268641 Forward-Port-Of: odoo/odoo#259683
This update fixes an issue where the avatar in the Discuss section was displaying outdated information for archived employees. The fix prioritizes the correct employee data based on active status and user links, ensuring accurate details are shown. This improves the user experience when accessing employee information.
Original PR description
*: hr_holidays,test_discuss_full **Steps to reproduce,** Create an employee linked to a user Archive the employee and remove the link to the user Create another employee for the same user Go to…
*: hr_holidays,test_discuss_full **Steps to reproduce,** Create an employee linked to a user Archive the employee and remove the link to the user Create another employee for the same user Go to Discuss > 'General' channel Open the member list and click on the user's avatar **Before this commit,** Clicking on the avatar opened a popover showing outdated information from the archived employee record instead of the new one. **Cause,** By default, the server sends employee data ordered by name. Since both records have the same name, the order is non-deterministic. The client then attempts to match the employee's company to the current user's company, falling back to the first record in the list if no match is found. **Fix,** Filter out archived records first (treating them as non-existent). Then, sort the remaining employee records to prioritize those that match the current user's active company. In case records share the same company, prioritize employees with a related user. Fall back to descending order of creation for identical results. **After this commit,** Clicking on the avatar shows the correct employee details in the popover. task-6175765 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270546 Forward-Port-Of: odoo/odoo#252170
This update fixes an issue where the partner associated with an invoice was incorrectly overridden by the purchase order during UBL XML imports. Now, the purchase order is the definitive source for the bill's partner, ensuring accurate record-keeping and improved data consistency. This resolves a potential discrepancy in billing information.
Original PR description
Fix a bug where the partner of a bill is overriden by the PO matching The chosen logic here is to say that in the context of a purchase, the purchase order is the single source of truth to set the partner on a bill Steps to reproduce: - Create a partner with is_company = True - Create a contact type 'invoice' for this partner - Create a purchase order for the first partner - Import an XML (UBL) that matches this PO - You can see in the import logs that the partner was correctly found first, and then the PO matching override it to set the contact as the partner task-6289358 Forward-Port-Of: odoo/odoo#271133 Forward-Port-Of: odoo/odoo#269223
This update enhances the Helpdesk system by adding tests to ensure automatic reminder emails are sent correctly before tickets close. It also corrects a calculation error in the reminder timer, preventing delays and ensuring timely notifications for support staff. This improves the overall efficiency of ticket resolution.
Original PR description
- add tests for the auto reminder email before auto-closing tickets - fix issue with the reminder timer calculation --- task-5438678 Forward-Port-Of: odoo/enterprise#120540
This update corrects a bug in the SaaS version of Odoo (19.3) where sales orders without products (note lines) would prevent the 'deliver' button from appearing. The change ensures that all sales order lines, regardless of product association, can be delivered correctly. This resolves an issue that arose after a previous update.
Original PR description
In saas-19.2, note lines on SO's are no longer have a calculated
"manual" qty_delivered_method value. In the previous code, these would
prevent the deliver button showing on SO's (when stock was not
installed). These would also cause issues with the deliver action.
On Runbot (no apps installed):
1. Install Sales
2. Create SO with a product
3. Confirm SO
4. See deliver button dissapear
This change will correct a previous change so that sale order lines without a product will remain with a manual delivered method
opw-6280551
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#270440