Monday, July 6, 2026
41 changes · saas-19.4
Enhancements to existing features
This update simplifies the process for responding to PDP requests by moving the response button from a prominent display to the cog wheel menu. Previously, users could achieve the same result by cancelling or posting an invoice/bill, so this change reduces clutter and improves usability. This is an important improvement to the user experience.
Original PR description
No real need to show a big button for sending a response in PDP as cancelling and posting an invoice/bill would do the same, so we move it to the cog wheel menu task-6274220 Forward-Port-Of: odoo/odoo#268846
This update refines how employees' favorite projects are automatically selected on timesheets. Previously, a project was selected with fewer than 3 linked timesheets. Now, a project is only selected if at least 3 of the employee's 5 most recent timesheets are associated with it, ensuring more accurate and relevant project associations.
Original PR description
A favorite project is now selected only when at least 3 of the employee's 5 most recent timesheets are linked to it. task-6290859 Forward-Port-Of: odoo/odoo#273259
Resolved issues and error corrections
Users can now preview canceled subscription orders without encountering an error. Canceled subscriptions are shown using the standard sales order preview instead of the subscription-specific portal view, preventing failed previews and improving reliability.
Original PR description
Currently, an error occurs when a user previews a canceled subscription order. **Steps to Reproduce:** - Install `sale_subscription` module. - Go to `Subscriptions` and create a `subscription order`…
Currently, an error occurs when a user previews a canceled subscription order.
**Steps to Reproduce:**
- Install `sale_subscription` module.
- Go to `Subscriptions` and create a `subscription order` with:
- a `subscription product`,
- a `recurring plan`,
- an `Until` (end date) value.
- `Cancel` the subscription order.
- Click `Preview`.
`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`
When previewing a subscription order, the portal view is rendered. During rendering, the
subscription portal template is used, which computes tax values and requires calculating the
next invoice date based on the recurring plan's billing period. However, for canceled
subscription orders, next_invoice_date is False because it is only set when the order is in
the sale state. As a result, an error is raised [2].
This commit ensures that only subscription orders in the sale state use the subscription
portal template. Canceled subscription orders use the default sale order preview, similar
to orders in the draft and sent states. This is appropriate because canceled subscriptions
are not correctly displayed in the subscription portal, and they should not attempt to
render the subscription-specific portal view.
[1]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/controllers/portal.py#L686-L687
[2]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/models/sale_order.py#L2172-L2175
sentry-7579114635
Forward-Port-Of: odoo/enterprise#122287Sick leave taken without a certificate now correctly grants loss-on-commission compensation when it applies. This helps Belgian payroll calculations reflect the employee's entitlement more accurately and avoids underpayment in relevant cases.
Original PR description
Sick time off without certificate should grant loss on commissions if relevant Forward-Port-Of: odoo/enterprise#122807
Commission plans now prevent adding a salesperson whose start date falls after the plan's end date. This helps keep commission eligibility periods consistent and avoids invalid sales compensation records.
Original PR description
Version: 18.0 Steps to reproduce: - open sale commission plans and create a new plan with an effective period - go to the salesperson tab and add a salesperson - set the salesperson from date after the plan end date issue: salesperson period start date was accepted even if it was set after the plan end date fix: added validation to raise an error when the salesperson start date falls outside the plan effective period task id: 6241188 Forward-Port-Of: odoo/enterprise#118289
The recruitment reports app now declares the reporting component it needs to show cohort views. This prevents installation failures in specific automated installation scenarios, helping deployments complete smoothly.
Original PR description
installing hr_recruitment_reports with the --ski-auto-install flag causes an error. The error happens because it does not explicitly depend on web_cohort while displaying a cohort view. task-6352888 runbot_error-237854 Forward-Port-Of: odoo/enterprise#122432
Fixed an issue where the Ask AI button could fail when more than one default prompt was set up for the same AI agent and interface. The system now chooses the most relevant prompt automatically, keeping AI assistance available without requiring users to clean up duplicate configurations.
Original PR description
## Problem When multiple Default Prompts are configured for the same AI Agent and interface key, clicking the "Ask AI" button raises a ValueError. ## Cause The `_get_composer_from_key_and_model`…
## Problem When multiple Default Prompts are configured for the same AI Agent and interface key, clicking the "Ask AI" button raises a ValueError. ## Cause The `_get_composer_from_key_and_model` method searches for composers matching an interface_key and model, but doesn't limit the results. When multiple Default Prompts exist for the same agent, the search returns multiple records, causing a singleton error when accessing `ai_agent_id`. ## Steps to Reproduce [[Video](https://drive.google.com/file/d/1yMAmX4RuevS0vH07qex2V0fMAiLrtJBg/view?usp=sharing)] 1. Go to AI > Configuration > Default Prompts 2. Create a new Default Prompt with Odoo Agent 3. Click the Ask AI button in the top-right corner 4. Error: ValueError: Expected singleton: ai.agent(2, 1) ## Fix Replace the two-step search with a single search using an `OR` domain: - Search both model-specific and generic Default Prompts in one query. - Order the results with `focused_model_id desc` so model-specific prompts are preferred over generic ones. - Return only one record using `limit=1`. This preserves the previous behavior while preventing singleton errors. --- opw-6323764 Forward-Port-Of: odoo/enterprise#121609
The AI icon now appears correctly on thinking notes in the chatter. This makes AI-generated activity easier for users to recognize and keeps the interface consistent after the recent migration.
Original PR description
This PR fixes an issue where the AI icon would not be shown on the thinking note of the chatter. The OWL3 migration added 'this.' prefixes to all template component references. This left 'isAiAgentChat' and 'props.channel' as bare context lookups (`ctx['isAiAgentChat']`, `ctx['props']`), both of which are undefined in the new rendering context. The fix adds 'this' in the xml to go through ctx['this'] to fetch each values correctly. task: 6346446
This update fixes an access issue affecting test employee types in payroll. It helps ensure payroll checks and warnings work correctly for authorized users, reducing friction during payroll validation.
Original PR description
task-6348716 Forward-Port-Of: odoo/enterprise#122264
This update prevents an error when users enter a negative forecast demand in Manufacturing Planning. Negative remaining quantities are now applied to the first forecast as intended, keeping planning workflows from being interrupted.
Original PR description
Steps to reproduce: - Fresh DB - Add a negative number to the forecast demand in the last period Cause: A variable was used without declaration Fix: According to odoo/enterprise#56128, it was intended that any remaining negative quantity to add should be added to the first forecast. Forward-Port-Of: odoo/enterprise#122520 Forward-Port-Of: odoo/enterprise#122261
The Executive Summary report now counts both the start and end dates when calculating period length. This fixes Average Debtor Days values that were slightly understated for date ranges such as a full month.
Original PR description
`_report_custom_engine_executive_summary_ndays` returned `date_to - date_from`, which is the gap between the two dates, not the count of days they span. For example April 2026-04-01 to 2026-04-30 will returned 29 instead of 30, making Average Debtor Days incorrect. Add +1 so the day count is inclusive of both endpoints, matching the rest of the report's date handling. opw-6215362 Forward-Port-Of: odoo/enterprise#121151 Forward-Port-Of: odoo/enterprise#118953
This change fixes inconsistent automated test results for the VoIP tab by ensuring the required mail-related setup is always included. It helps keep validation runs stable and reduces the risk of false failures during release checks.
Original PR description
Depending on the runbot build test order/configuration "tab" tests introduced at [1] passed or not. This was because mail utils rely on mail models definition which are not explicitly defined in this test file. They are now defined through setupVoipTests to be consistent with other VoIP test files. [1]: https://github.com/odoo/enterprise/commit/37b89ba41dd7891a09592f24ecf30df5596f254c runbot-941401
This update fixes internal Sign app tests that could fail when demo data or previous manual activity existed in the database. It makes test checks more precise so development and quality assurance work can run more reliably without affecting customer-facing behavior.
Original PR description
Version: 19.0 `test_sign_request_notification`, `test_gc_removes_orphan_roles_and_dummy_items` ,`test_sign_tour` and `test_sign_tour_without_sign` fail locally when you run them on a db with demo…
Version: 19.0
`test_sign_request_notification`, `test_gc_removes_orphan_roles_and_dummy_items` ,`test_sign_tour` and `test_sign_tour_without_sign` fail locally when you run them on a db with demo data installed, after doing some manual testing/ operations on it.
- `test_sign_request_notification` builds `completion_mail_to_user` by searching `mail.mail` for any email addressed to the admin's address. If admin had received any other email before this test ran, it got counted too, so the assertion on `len(completion_mail_to_user)` became wrong. We now also filter by subject matching `sign_request.reference`, so it only counts the email this test's own sign request actually generated.
- `test_gc_removes_orphan_roles_and_dummy_items` relies on the helper `_get_signer_and_item_gc_context` to count dummy sign items (page < 0). That helper searched `sign.item` with no domain at all, so any dummy item left behind by a different template got added to `non_active_item_ids` and broke the `len(non_active_item_ids) == 4` check. We now scope that search to `template_id = sign_template.id`, so it only counts items belonging to the template created in the test.
- `sign_tour` had a step targeting `.o-autocomplete--dropdown-item:contains('Administrator')` in the signer autocomplete. After installing demo data the admin user is named `Mitchell Admin`, so the tour failed on databases using that name. Both contain 'Admin', so the trigger now matches on that instead.
taskid- 6329037
Forward-Port-Of: odoo/enterprise#121878Fixes an issue where some multi-day shift templates on round-the-clock schedules showed one extra minute of planned time. This keeps allocated hours aligned with the intended shift duration, improving the accuracy of planning reports.
Original PR description
**Problem:** On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift…
**Problem:** On a round-the-clock (0h-24h) working schedule, shifts created from a shift template that spans more than one day get one extra minute added to their allocated time: an 8-hour shift shows 08:01. **Steps to reproduce:** 1. Create a working schedule with a 00:00 -> 24:00 attendance for every day (24h/day, "Full Day"). 2. Assign an employee to that schedule. 3. Create a multi-day-span shift template (e.g. 16:00 -> 00:00, 2 days). 4. Plan a shift for that employee using the template. 5. Observe the Allocated Time shows one minute more than expected (08:01). **Current behavior:** Allocated Time is one minute too long (e.g. 08:01 instead of 08:00), which throws off the customer's planning reports. **Expected behavior:** Allocated Time matches the template duration exactly (08:00). **Cause of the issue:** In `_calculate_start_end_dates`, the end of a multi-day-span shift is computed with `resource.calendar_id.plan_days(...)`. On a 0h-24h calendar each day ends at `time.max` (23:59:59.999999), so `plan_days` returns an end datetime carrying those stale seconds. The following `end.replace(hour=..., minute=...)` overwrites only the hour and minute, leaving `second=59, microsecond=999999`. The slot is therefore ~1 minute longer than intended, and `allocated_hours` rounds that up to 08:01. **Fix:** Resetting seconds and microseconds when rebuilding the end datetime keeps the slot aligned to the template's whole-minute boundary, regardless of how the underlying calendar represents the end of day. The hour/minute already come from the template, so the leftover sub-minute precision from `plan_days` is never meaningful and is what produces the drift. opw-6265238 Forward-Port-Of: odoo/enterprise#122157 Forward-Port-Of: odoo/enterprise#120219
The document selection dialog no longer shows document management actions when users select files to attach or link. This keeps the dialog focused on choosing documents and avoids showing irrelevant controls in that workflow.
Original PR description
When selecting documents for attachment/link, control panel actions were displayed upon selection. The document selection dialog uses the secondary documents view introduced in: https://github.com/odoo/enterprise/pull/89030/changes/f93c159c106d1dde70910ec590f8739e549b19cf Several document management actions were already hidden through the `documents_view_secondary` context, but `DocumentsAction` was still displayed upon selection. Hide `DocumentsAction` in the secondary view. Task-6236888 Forward-Port-Of: odoo/enterprise#122536 Forward-Port-Of: odoo/enterprise#119219
This update fixes an issue that prevented users from temporarily clearing the date field in the WIP Accounting Entry wizard. The fix ensures the wizard functions correctly when editing the date, improving user experience and preventing errors during data entry. This change enhances the reliability of the manufacturing order accounting process.
Original PR description
Issue Before This PR: When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the…
Issue Before This PR: When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard. Steps to Reproduce: - Open the list view of Manufacturing Orders. - Open the Post WIP Accounting Entry wizard by either: - Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry - Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu. - Clear the Date field. - Observe that an error is raised. Cause of the Issue: The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error. With This PR: The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input. Issue reference: https://github.com/odoo/odoo/issues/246547 Forward-Port-Of: odoo/odoo#273002
This update fixes an issue where replacing website icons removed their styling classes (like rounded or shadow). The fix ensures that icons in the website builder retain their original visual styles, providing a more consistent and predictable design experience. This improves the usability of the website builder for creating visually appealing pages.
Original PR description
Issue: Replacing an icon removes style classes applied to the original icon, such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`. This issue was introduced by [commit], which stopped…
Issue: Replacing an icon removes style classes applied to the original icon, such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`. This issue was introduced by [commit], which stopped preserving image-specific classes when replacing an image with an icon. This behavior is appropriate in the backend editor, where icons do not support these styling options. However, the same logic also affected the website builder, where icons support the same styling options as images. As a result, these classes were unnecessarily removed when replacing an icon. Steps to reproduce: 1. Add an icon with style classes such as `rounded`, `rounded-circle`, `shadow`, or `img-thumbnail`. 2. Replace the icon. 3. Notice that the style classes are removed from the new icon. Fix: Preserve these style classes when replacing icons in the website builder, allowing the newly selected icon to retain the existing visual styling. [commit]: https://github.com/odoo/odoo/commit/8638dbc21a7a3ebb3c9cc195d2249b4eb5c264ab task-[6200832](https://www.odoo.com/odoo/project/974/tasks/6200832) Forward-Port-Of: odoo/odoo#273598 Forward-Port-Of: odoo/odoo#265496
This update resolves an issue where users were unable to add event reminders to their calendars (iCal/Outlook) due to an error in the generated ICS file. The fix involved correcting how date/time information was formatted within the ICS file, ensuring compatibility with the underlying software. This prevents a potential disruption for users receiving reminder emails.
Original PR description
Steps to reproduce =================== 1. Open the Events page on the website. 2. Open the OpenWood Collection Online Reveal event. 3. Go to Talks. 4. Favorite a talk to receive the talk reminder email. 5. Try to add the event to an iCal/Outlook calendar from the email. => Internal Server Error With commit [1], while switching from pytz to zoneinfo, we mistakenly set the `created` value in the ICS file to `datetime.timezone.utc`, which is not supported by `vobject`. This commit now uses ZoneInfo instead. [1] https://github.com/odoo/odoo/commit/6fdb36716aac5d2b084fb0faa94ccb2f3ee7f99c Task-6288817 Forward-Port-Of: odoo/odoo#272159
This update resolves an issue where the 'Apply To' option in pricelist rules wasn't consistently saving the selected category. The fix ensures that when a category is chosen for a pricelist rule, it's correctly saved and reapplies when the rule is reopened, improving data accuracy for rental pricing.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install Rental(sale_renting) module and activate Pricelist. 2. Go to Rental > Products > Pricelists. 3. Open an existing pricelist or…
Steps to reproduce:
------------------------------------
1. Install Rental(sale_renting) module and activate Pricelist.
2. Go to Rental > Products > Pricelists.
3. Open an existing pricelist or create a new one.
4. Add a pricelist rule and set:
- Apply To: Category
- Configure the rule (e.g. select a category).
5. Save and close the rule, then save the pricelist.
6. Reopen the pricelist rule.
Observation:
------------------------------------
The "Apply To" option is no longer set to Category. Instead, it default value to Product, and the selected category is not saving correctly.
Issue:
------------------------------------
After [This Commit](https://github.com/odoo/odoo/commit/d2648b1d983927b5df7260a16d6d1d33c213ddeb), 'display_applied_on' is used to control the visibility of uom_id but is not defined in the list view. As a result, field parsing marks it as readonly, so its updated value is not saved.
This causes the "Apply To" option to fall back to its default value ('Product') when the pricelist rule is reopened.
Solution:
------------------------------------
Include the display_applied_on field in the pricelist item list view so the selected "Apply To" option is preserved when saving the pricelist.
opw-6346422
Forward-Port-Of: odoo/odoo#273596This update resolves a bug in the Odoo IoT setup process for the l10n_eg module. A recent change simplified the token storage, but without updating the validation logic, it caused errors. The fix now correctly handles both token and hash submissions, ensuring a smooth and reliable setup experience.
Original PR description
In odoo/odoo#255121, the l10n_eg token flow was simplified to store the token automatically in the IoT config when running the installer, instead of showing a popup requiring the user to save the token manually. However, this broke the flow because previously, a *hash* of the token was being stored in the IoT config, but now the actual token is stored in the config (which allows it to be sent to the DB). The token validation logic was not updated accordingly, so it would try to use the token itself as a hash which would result in an `UnknownHashError`. To fix this, we first check if the provided token matches the stored token exactly. If it doesn't, we assume it is a hash and continue with the old flow as before. Logging statements are added in every failure case to ease debugging in the future. opw-6049363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273474 Forward-Port-Of: odoo/odoo#273033
This update resolves a rare issue where the Glory cash machine was occasionally sending incorrect data to Odoo, leading to errors. The fix ensures that the machine's messages are properly formatted, preventing these errors and maintaining reliable transaction processing. This improves the stability of the Glory Cash integration.
Original PR description
Rarely, the Glory machine can send a websocket message containing 2 root XML elements, which causes the `parseXML` function to fail. This commit fixes the issue wrapping the message in a root element, and then returning the children. opw-6292925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272040
This update fixes an unexpected accrual calculation that occurred when carryover allowances were applied. Previously, an extra accrual happened on the carryover date, leading to confusing accrual amounts. This change ensures accruals only occur at the standard periods (start/end of month, or level transitions) as intended.
Original PR description
## Issue Currently, an extra accrual happens on carryover date, but it shouldn't. Indeed, accrual only happened at the start - end of a period, or on level transition. ## Reproducing steps Let's take an accrual plan with a level that adds 2 days/month on the 15th of the month. The carryover takes place at the beginning of the year. So we will have this: - 2025-11-01 -> creation of the allowance, 0 days available - 2025-11-15 -> 1 day (only 15 days are counted, so only half of the days are added) - 2025-12-15 -> 3 days (1 full month elapsed) - 2026-01-01 -> 4 days (as the carryover triggers an accrual) -> this event causes confusion as the accrual seems to “come out of nowhere” - 2026-01-15 -> 5 days - 2026-02-15 -> 7 days task-5432188 Forward-Port-Of: odoo/odoo#272349 Forward-Port-Of: odoo/odoo#245201
This update fixes an issue where clicking links within reply messages didn't open them in a new browser tab. Now, links from parent messages will automatically open in a new tab, providing a smoother and more convenient user experience when navigating between conversations.
Original PR description
Before this commit, clicking on a link in a parent message was not opening it in a new tab. Now, the target and rel attributes of the parent message are passed to the inline body opening the link in a new tab if it was the case in the parent. task-6326242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273603
This update corrects a display issue on the shop page where the order of product attribute values wasn't consistently maintained. The fix ensures that the order of attribute values, as defined by the user, is correctly displayed when browsing products. This improves the user experience and prevents confusion regarding product options.
Original PR description
In saas-19.3, the shop controller was refactored to fetch attribute values using `ProductAttributeValue._read_group()` with `aggregates=["id:recordset"]`. This aggregate internally uses `ARRAY_AGG(id ORDER BY id)`, which orders values strictly by database ID, ignoring the `sequence` field defined in `product.attribute.value._order = 'attribute_id, sequence, id'`. Steps to reproduce: 1. Go to ecommerce attributes. 2. Add an attribute value to any attribute. 3. Make sure the attribute is used by a product. 4. Rearrange the order of the attribute value. 5. Go to the shop page, and try to access the attribute value by clicking on the proper attribute. 6. We see that the order isn't maintained. Fix by calling `.sorted()` on each value recordset after the aggregate, so the user-defined sequence is respected before storing into `pavs_per_attribute`. opw-6325814 Forward-Port-Of: odoo/odoo#273802
This update enhances the logging page by limiting the displayed log data to the last 10,000 lines, preventing performance issues with large logs. It also adds automatic scrolling and removes unnecessary log requests, improving the user experience and overall stability of the logging feature.
Original PR description
This commit makes the following pages to the log viewing page: - Only the last 10000 lines of logs are shown. This stops the page from freezing/performing badly when the logfile is very large. - When the view is at the bottom of the page, new logs are automatically scrolled into view. Otherwise the view stays still so the user can inspect the logs without them scrolling away. - The ANSI color codes are now stripped from the logs as they were just displayed as garbage characters. - The requests to fetch logs are now removed from the output, as otherwise you would be spammed with requests that only happen as a result of the logging page being open. task-6330996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273343
This update clarifies the roles and permissions associated with the 'User' and 'Administrator' groups within the Project module. The changes improve the clarity of how users manage tasks and projects, ensuring accurate understanding of access rights.
Original PR description
This commit improves the grammar of the Project user group description. ### **For User:** **Before -** `User can user the your employees' schedule` **After -** `User: Can manage tasks in projects shared with them.` ### **For Admin:** **Before -** `Administrator can manage the employees' schedule` **After -** `Administrator: Can manage projects and stages, with access to reporting and configuration.` **opw-6340390** Forward-Port-Of: odoo/odoo#273061
This update ensures WIoT instances are immediately accessible during upgrades to newer Odoo versions. The change sets the HTTP interface to `0.0.0.0`, preventing a default configuration change in Odoo 19.1 that would block access. This streamlines the upgrade process for WIoT.
Original PR description
WIoT are built in v19, but progressively upgrading to 19.1,2,3,... We need to set the `http_insterface` param to `0.0.0.0` so they are ready when upgrading, as `http_interface` changes to localhost by default in 19.1. Forward-Port-Of: odoo/odoo#271857
A recent test for adding products to invoices was failing due to an outdated element search within the Odoo system. This update corrects the test to correctly identify a key element, ensuring the invoice product catalog tour functions as intended. This resolves a minor technical issue impacting test reliability.
Original PR description
The tour preciously looked for a `o_field_product_label_section_and_note_cell` element to verify product was added. In the configuration used, the element did not exist, despite the line with the product being present. This caused the tour test to fail. This PR makes it look for a `o_account_label_text_cell` instead to successfully detect the line. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a minor issue where the mailing domain dropdown remained visible when a target model wasn't selected. The fix ensures the recipient count is correctly set, preventing errors and improving the user experience. While a mailing requires a target model, this update ensures proper functionality.
Original PR description
On a mailing, when attempting to remove the target model, `_compute_recipients_count` will attempt to recompute the recipient count. As the new target domain is empty, recipient count will not be set. This will cause an traceback, as the compute method was unsuccessful in assigning a recipient count. (This is a minor issue, as a mailing cannot be saved without a target model anyways; however, this causes the mailing domain dropdown to remain visible when it should be hidden.) Steps to reproduce: - Create a new mailing - Blank out the target model field (recipients) Fix: `_compute_recipients_count` assigns recipient count to False (empty column).
This update resolves a bug that prevented users from correctly selecting section templates within Sales Orders. The fix corrects a data entry error that was causing a validation issue when creating sales orders with section templates. This ensures the sales order creation process functions smoothly.
Original PR description
## Steps to Reproduce: 1. Install the sale_margin module. 2. Sales > Configuration > Templates. 3. Create a template with type 'Section', and add a section line. 4. Create a Sales Order, click Add…
## Steps to Reproduce: 1. Install the sale_margin module. 2. Sales > Configuration > Templates. 3. Create a template with type 'Section', and add a section line. 4. Create a Sales Order, click Add Section, and select the created template. ## Error: `ValueError: Expected singleton: res.currency()` ## Cause: The `_prepare_order_line_values()` method mistakenly stores the converted purchase price in the `currency_id` field instead of `purchase_price`. When these values are used to create a sales order line, leaving currency_id unset. - [1] As a result, the onchange later fails when it expects a valid currency. - [2] ## Fix: Pass the correct field value of `purchase_price` instead of `currency_id`. [1]: https://github.com/odoo/odoo/blob/f2f656371f81683ee3fe558932df53a2d0c5d374/addons/sale_management/models/sale_order_template.py#L346-L350 [2]: https://github.com/odoo/odoo/blob/f2f656371f81683ee3fe558932df53a2d0c5d374/addons/sale_margin/models/sale_order_line.py#L76 opw-6347869
This update resolves an issue where the extra price for product variants was incorrectly displayed when a pricelist used a fixed pricing model. The fix ensures that the extra price badge is hidden in the product configurator and website views when the pricelist's calculation method is fixed, aligning with expected behavior.
Original PR description
Issue: --- If pricelist.compute_price is fixed, extra price of variant is not taken into calculation, but it's shown in extra price badge. Steps to reproduce: --- 1- Create a product template with two variants. 2- Apply extra price for each attribute values. 3- Apply a pricing with a fixed price for the product on a pricelist. 4- Create a SO and apply the pricelist. Add the product to SOL. 5- Open product configurator on SOL. - As you see, the extra price is shown but it's not effective. 6- Open the product in website with the pricelist. - Here also the extra price is shown but it's not effective. Cause: --- This is caused because there is no mechanism to hide extra price having pricelist.compute_price == fixed. Fix: --- We need to fix the issue both in sale and website_sale separately by having a flag to ensure extra price badge is hidden if compute_price is fixed. opw-6276208 Forward-Port-Of: odoo/odoo#272541 Forward-Port-Of: odoo/odoo#270140
This update fixes an issue where the restaurant floor plan selector would overlap other parts of the interface when multiple floor plans were available. Adding horizontal scrolling ensures the floor plan is always visible and accessible, providing a better user experience for restaurant staff.
Original PR description
In this commit: ---------------- - Added horizontal scrolling for the floor selector when multiple floor plans are available, preventing it from overlapping other components. Task: 6356983 Forward-Port-Of: odoo/odoo#274092 Forward-Port-Of: odoo/odoo#273637
This update fixes a technical issue related to printer test setup by moving mocking to the client-side. Additionally, the printer setup tours have been streamlined for easier testing and a more intuitive user experience, particularly when using demo data.
Original PR description
We moved printer requests mocking client-side in tests to avoid creating fake controllers. We also improved the tour to search the actual printer name in the printer selection wizard, and made the zebra tour start directly from the product instead of searching it (simplifies search when tests are run with demo data).
This update fixes an issue where switching settings apps on mobile devices didn't correctly update the browser's URL. Now, refreshing the page will reliably take the user back to the settings app they were previously using, ensuring a smoother user experience.
Original PR description
Before this commit, when switching applications in the settings view on mobile, the URL fragment was not correctly updated to reflect the active application. Because of this, if the page was reloaded, the user would be redirected back to the first application in the settings instead of the one they were currently viewing. This commit ensures the URL fragment is properly updated upon selection, preserving the user's current context if the page is refreshed. task-id 6333778
This update resolves a technical issue that was preventing tests for our Point of Sale and POS Stock modules from running correctly. The change ensures that test code doesn't accidentally alter the system's core data, allowing the tests to pass and maintain the stability of these important features.
Original PR description
Avoid polluting the Odoo model registry and failing `test_lint_override_signature` by using `patch.object` instead of manual assignment. This ensures the injected method is properly torn down after the test block, keeping the registry clean and bypassing static analysis failure as the patched method is only used for tests. Note: this commit is a follow-up of odoo/odoo@163225c3f9c0f51c40c9b1ae6ec00ba1c8f16017 runbot-939298 Forward-Port-Of: odoo/odoo#274318
This update corrects a technical issue where a key field related to product removal strategies was incorrectly loaded in the Point of Sale module. Now, this field is correctly loaded within the pos_stock module, ensuring accurate stock management and reporting for point-of-sale transactions. This improves the overall reliability of the POS system.
Original PR description
Before this commit: ==== - removal_strategy_id field was loaded in point_of_sale instead of pos_stock Following this commit: ==== - Field is now been loaded in pos_stock Error-941369 Forward-Port-Of: odoo/odoo#274297
This update standardizes the technical names used for website types within the Odoo platform. Previously, inconsistent capitalization (camelCase) was used, which has now been corrected to snake_case. This ensures greater clarity and consistency across the codebase, improving maintainability.
Original PR description
Avoid using camelCase for website type technical names and use snake_case consistently for technical identifiers. task-[6284263](https://www.odoo.com/odoo/project/974/tasks/6284263) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268829
This update ensures GIF functionality in Odoo continues to work by switching from the soon-to-be-terminated Tenor GIF API to the Klipy GIF API. This change is necessary to avoid disruptions to GIF sharing within the system. Users should be aware that updating the API key is required for GIF functionality to remain operational.
Original PR description
Tenor API will be terminated on June 30, 2026: https://developers.google.com/tenor/guides/quickstart This commit makes the Tenor API key input settings use a Klipy GIF API key instead of a Tenor GIF API key. To keep GIF working after this commit, the API key must necessarily be changed to a Klipy GIF API key, as the old Tenor API key would be considered as an invalid Klipy API key. Task-5491965 Upgrade: https://github.com/odoo/upgrade/pull/10516 Forward-Port-Of: odoo/odoo#273182 Forward-Port-Of: odoo/odoo#250113
A recent update caused internal server errors when blog comments were enabled. This fix removes a leftover reference to a field, resolving the issue and ensuring blog pages function correctly with comments active. This improves the overall stability of the blog feature.
Original PR description
**Description of the problem** Traceback on blog pages when comments are active. **How to reproduce** (Starting from a fresh database with `website` and `website_blog` installed with demo data) 1. Open edit mode on a blog post 2. Activate comments 3. PROBLEM: Internal Server Error **Origin of the problem** Commit [1] removed the `website_message_ids` field, but a single occurrency was left behind in the codebase, causing a traceback on the first attempt to open the blog page. **FIX** This commit removes the reference to the field `website_message_ids`. [1]: https://github.com/odoo/odoo/pull/261003 task-6364928
A bug in the public tour process caused it to repeatedly run and fail due to delayed uploads. This fix correctly scopes the tour's uploads to the composer, ensuring it waits for its own attachments to be processed. This resolves a recurring test failure and improves the tour's reliability.
Original PR description
discuss_channel_public_tour uploads two files and waits for their attachment cards before clicking Send. The card selectors were not scoped to the composer, and message attachments render the exact…
discuss_channel_public_tour uploads two files and waits for their attachment cards before clicking Send. The card selectors were not scoped to the composer, and message attachments render the exact same card. The tour runs twice per test: on the second run, the message posted by the first run already displays identical text.txt and image.png cards, so the waits matched immediately and the tour never waited for its own uploads (build logs show the steps passing before the upload requests even reached the server). Send was then clicked during the upload window. The trigger can catch the button enabled from a render preceding the upload registration, while processMessage checks the live model, still finds an attachment uploading, and silently drops the message. The persistent "cheese" message step then timed out. Scope the selectors to the composer so the tour genuinely waits for its own uploads; this also makes the guest access token check read the composer image instead of the first run's message image. https://runbot.odoo.com/odoo/error/941300
This update resolves a bug that prevented the generation and sending of French PDP reports. The issue stemmed from incorrectly formatting the report data before sending, which caused a system crash. This fix ensures reports are now processed correctly and reliably.
Original PR description
Before this commit, it was impossible to send a `l10n.fr.pdp.reports.flow` as we included a raw file in the payload without decoding it. This causes the JSONification to crash. 1. Install l10n_fr_pdp 2. Create a record of `l10n.fr.pdp.reports.flow` 3. Try to send it 4. See crash opw-6330820 **19.3+** Forward-Port-Of: odoo/odoo#272513