Daily updates from Odoo
Friday, November 7, 2025
71 changes · 19.0
Enhancements to existing features
A dedicated payslip report has been added for Saudi Arabia payroll. It simplifies the standard printout by removing fields that are not needed and updates the layout to better match local payroll requirements.
Original PR description
- Introduce a dedicated payslip printout tailored for Saudi localization. - Remove unnecessary fields from the default format and adjust the layout to match Saudi payroll requirements. Task: 5126583
This update adds automated testing for self-order flows that send orders to an IoT preparation printer. It helps ensure printing behavior keeps working reliably and reduces the risk of regressions in restaurant and kiosk setups.
Original PR description
This commit adds a tour to check that the self order can send an order on an IoT preparation printer.
This update makes the language import/export command easier to use by showing a helpful hint when a language is not yet installed. It also broadens language matching so users can find the right language using either the standard code or ISO code, reducing confusion around similar language file names.
Original PR description
When exporting/importing a language with the i18n export/import CLI tool we might forget installing the language in the database first. By providing a hint on how to do that, the user can easily copy the command to install it in his database and continue in what he was doing. We see that Python also gives similar hints when you make typos in a method name for example, so it is good to follow that fashion. A change has been added to also allow the search of languages for the command, with the `code`, other then only with `iso_code`.
This update adjusts the sale PDF quote builder tests so they do not depend on the exact names of sales order states. It helps the test suite remain reliable when another module customizes those state labels, reducing false failures without changing customer-facing behavior.
Original PR description
### Description of the issue/feature this PR addresses: This ensures that `sale_pdf_quote_builder` tests pass even if a third party module that renames `sale.order` `state` selections has been installed. ### Current behavior before PR: Tests fail. ### Desired behavior after PR is merged: Tests pass. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232760
The barcode test suite now uses dedicated test data instead of relying on the live default warehouse and company. This makes the tests less sensitive to unrelated configuration changes and reduces flaky failures, while also improving test speed in some cases.
Original PR description
*: stock_barcode_mrp, stock_barcode_mrp_subcontracting, stock_barcode_picking_batch Until now, the default warehouse (WH) was the warehouse used in the `stock_barcode` tests which means all the tests depends of it and are influenced by the changes done in this warehouse (like changes done by the demo data.) A better way to run the tests would be to use a warehouse created for this occasion, and what a chance, that's why this commit does! Incidentally, this commit also fixes [runbot built error 233274](https://runbot.odoo.com/odoo/runbot.build.error/233274) **Community PR:** odoo/odoo#234483
The live chat info panel now lets users assign expertises directly to a conversation. This makes it easier to classify chats, route them to the right people, and quickly find related conversations without leaving the panel.
Original PR description
The live chat info panel shows expertises linked to the chat. However, it's not possible to assign expertises to the chat (only available from the chat bot script). Expertises are useful to quickly identify which kind of help is needed on a chat, or to find conversations about the same topic. This commit allows to add expertises from the channel info panel. task-5190361 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Odoo PWA now displays the number of pending Discuss notifications directly on the app icon. This helps users quickly see if there are unread chats or messages even when the app is closed.
Original PR description
This commit adds a badge counter with global discuss counter on the PWA app icon, which helps a lot in knowing how many chat notifications are pending in the PWA when the Odoo app is not open. Task-5136354 
Resolved issues and error corrections
This change fixes an issue where printed expense reports using the DIN5008 format showed the title twice. It adds the correct report title so the PDF displays cleanly and consistently for users in affected localizations.
Original PR description
Issue: Expense title is duplicated when printing an expense report for localizations using the DIN5008 standard. Steps to reproduce: - Install German localization - Create a new expense report - Print the expense report PDF -> Title is duplicated Cause: DIN5008 reports tries to load a value `din5008_document_title` in their header and fallbacks to report's name With this commit, we add a bridge module to extend the expense sheet report and set the `din5008_document_title` to `Expenses Report`. opw-4314414 Forward-Port-Of: odoo/odoo#234686 Forward-Port-Of: odoo/odoo#212923
Conversation transcript files now render with the correct layout when downloaded. This fixes visible table borders and misaligned content, making the exported document easier to read and more professional-looking.
Original PR description
**Purpose of this PR :** Previously, downloading the conversation transcript file produced rendering issues, such as a misaligned layout and visible table borders. This commit updates the rendering template by applying the `table-borderless` class, required by `web.basic_layout` to suppress table borders. It also replaces flex with inline-block to ensure the chatBubble displays correctly. This issue occurred because the `table-borderless` class was not used and flex was applied when generating the PDF. **Before Image:** <img width="628" height="609" alt="render_bug" src="https://github.com/user-attachments/assets/020bb072-8eed-407a-aa1f-f6bc8efb9086" /> **After Image:** <img width="599" height="600" alt="render_fix" src="https://github.com/user-attachments/assets/d2a1f74d-c2a4-48a1-b3e1-3e344f53af78" /> Task-5012010
This change fixes a crash that could happen when opening the Timesheets and Planning Analysis view from a project. It ensures the analysis can load correctly so users can review planned and actual costs without interruption.
Original PR description
### Issue: A traceback occurs when opening Timesheets and Planning Analysis. #### Steps to reproduce: 1- Create a database with `project_timesheet_forecast_sale` installed. 2- Create a project and…
### Issue:
A traceback occurs when opening Timesheets and Planning Analysis.
#### Steps to reproduce:
1- Create a database with `project_timesheet_forecast_sale` installed.
2- Create a project and open the three-dot menu.
3- Click on `Timesheets and Planning Analysis`.
### Cause:
The error occurs because currency_id field is not defined, as a result:
https://github.com/odoo/odoo/blob/dff0a35413c0bcb106d0ab1086465f9200e25c5d/addons/web/static/src/views/pivot/pivot_renderer.js#L108-L116
currencyIds will cause a traceback as it is undefined.
This is due to `planned_costs` and `effective_costs` fields being float but declared as `widget="monetary"` in the pivot view. Since there is no `currency_field`, the pivot renderer fails to resolve currency_id.
In stable in the pivot view we can remove monetary widget from fields.
In master, we can:
```diff
+ currency_id = fields.Many2one(related="company_id.currency_id", string="Currency", readonly=True)
+ effective_costs = fields.Monetary('Effective Costs', readonly=True)
+ planned_costs = fields.Monetary('Planned Costs', readonly=True)
- effective_costs = fields.Float('Effective Costs', readonly=True)
- planned_costs = fields.Float('Planned Costs', readonly=True)
```
opw-5176269This change prevents an error that could happen when users schedule or update a meeting without having a timezone set in their profile. If no timezone is available, the system now safely uses UTC so the meeting can be saved normally.
Original PR description
Currently, an error occurs when scheduling or updating a meeting for an applicant if the user's timezone is not set.
**Steps to Reproduce:**
1. In the user's profile, remove the TimeZone.
2. Now, install the "**Recruitment**" module.
3. Create an application and schedule a meeting for the applicant.
4. After saving the record, change the start time and try to save the record.
**Error:**
`AttributeError - 'bool' object has no attribute 'upper'`
**Cause:**
At [1], system gets the timezone from the context, but in this case, `'tz'` is `False`. As a result, `user_tz` becomes False, and using `upper()` method on a bool value triggers an error.
**Fix:**
This commit ensures that the 'UTC' timezone is assigned when the context does not include a valid timezone ('tz' is missing or False).
[1] - https://github.com/odoo/odoo/blob/78bd84c7b91f11780f152c29c8f595e3d9ed3d68/addons/calendar/models/mail_activity.py#L23
sentry-6952137101
Forward-Port-Of: odoo/odoo#233727This change fixes an issue in the editor where selecting table cells from right to left or bottom to top in Firefox could lose the first selected cell. It makes backward table selections work consistently, improving the editing experience for users working with tables.
Original PR description
Steps to Reproduce: 1. Create a table in the editor (Firefox). 2. Select table cells backward (right → left or bottom → top). Description of the issue this PR addresses: - The first selected cell does not remain selected in Firefox when extending the selection backward. task-5094832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234579 Forward-Port-Of: odoo/odoo#227694
This fix ensures that invoices marked as "Registered For Export" show the correct payable amount in the exported XML. The amount now reflects the VAT deduction, helping the electronic invoice match the expected tax treatment.
Original PR description
When the invoice's type is "Registered For Export", the total of the invoice which is shown in the cbc:PayableAmount node in XML, has to reflect the VAT deducted amount. This PR fixes the given issue. task-5159638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232586 Forward-Port-Of: odoo/odoo#231221
This update prevents an unnecessary validation error from appearing during database migration when tax distribution values are empty. It helps migrations complete smoothly and avoids interrupting users with a misleading error message.
Original PR description
``` File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 611, in _validate_repartition_lines raise ValidationError(_("Invoice and credit note distribution should have a total…
```
File "/home/odoo/src/odoo/19.0/addons/account/models/account_tax.py", line 611, in _validate_repartition_lines
raise ValidationError(_("Invoice and credit note distribution should have a total factor (+) equals to 100."))
odoo.exceptions.ValidationError: Invoice and credit note distribution should have a total factor (+) equals to 100.
```
- During the database migration, a traceback occurs because the [total_pos_factor](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L558) is being calculated as 0. When this happens, the float_compare [function](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L559) returns -1, which incorrectly satisfies the validation condition and triggers a ValidationError.
- To resolve this, we need to add an additional condition to check whether total_pos_factor is 0, similar to the condition already implemented [here](https://github.com/odoo/odoo/blob/18.0/addons/account/models/account_tax.py#L562) in the code.
tbg-1970
opw-5228357
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#234334Archived bank reconciliation models will no longer be shown in the list of available matching rules. This helps users avoid selecting outdated rules and keeps the reconciliation screen cleaner and more accurate.
Original PR description
Steps to reproduce: ------------------- 1. Install Accounting (with demo data). 2. Go to Accounting > Dashboard and open the "Bank" journal. 3. Click on any unreconciled line and open the dropdown menu. 4. Select “Manage models” and archive one of the reconcile models. 5. Return to the bank journal and open any unreconciled line. Issue: ------- Archived reconcile models are still shown in the available model list. Cause: ------ The [SQL query](https://github.com/odoo/enterprise/blob/6615de3100ac1192039a5f276df278c543f2fabb/account_accountant/models/account_reconcile_model.py#L47-L118 ) does not filter out inactive reconcile models. Solution: ---------- Add a condition to include only active models. opw-5189700 Forward-Port-Of: odoo/enterprise#98372
This update corrects how check amounts are written out in words for Philippine payments when the amount includes cents. It removes the incorrect "ONLY" ending in those cases and standardizes the wording for decimals, helping ensure checks are formatted properly and match local requirements.
Original PR description
In phillipines, if any amount has centovas (decimal amount), the amount in words cannot contain 'ONLY' in the end. Additionally, changed 'And' -> 'and' for decimal amount. **task**-5155953 Forward-Port-Of: odoo/enterprise#98535
Opening the avatar popover for an archived employee no longer triggers an error. The system now correctly reads archived employee data, so users can view these records without interruption.
Original PR description
**Steps to reproduce:** - Open the Planning app. - Archive an employee. - Open the archived employee's avatar popover. **Current behavior before PR:** Opening the popover raised an error because `get_avatar_card_data` returned an empty list for archived records. This occurred since `search_read` ignored inactive records by default. **Desired behavior after PR is merged:** The method now uses `read` instead, ensuring archived records are properly handled without error. enterprise PR: https://github.com/odoo/enterprise/pull/98230 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231184
This update fixes errors and layout issues that could appear when printing invoices using the GCC country-specific report templates, especially when invoice sections are used. It helps ensure the UAE and Saudi Arabia invoice reports continue to display correctly after recent report changes, reducing broken printouts and unwanted formatting changes.
Original PR description
Description of the issue/feature this PR addresses: after the merge https://github.com/odoo/odoo/pull/220167 there were some bugs due to the new section features that were also merged in 19.0 this commits fixes certain tracebacks that occured when sections were used in the invoice pdf report. it also fixes certain formatting issues due to different layouts or due to changes made in the standard report. Current behavior before PR: certain tracebacks/unwanted formatting changes occur when you try to print any report that inherits l10n_gcc_invoice and you have sections in the invoice. Desired behavior after PR is merged: the changes done in the account invoice report are accounted for in the ae & sa reports. task-5069610 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Planning app now safely handles missing employee data when opening an avatar popover. This prevents traceback errors and avoids interruptions when viewing archived employees.
Original PR description
Purpose of this PR: A guard has been added in the override of `get_avatar_card_data` to handle empty results and prevent traceback errors when data is missing. community PR: [odoo/odoo#231184](https://github.com/odoo/odoo/pull/231184) Forward-Port-Of: odoo/enterprise#98230
This fix prevents an error that could appear when opening the AI assistant from the email composer if a user has no timezone set. If timezone information is missing, the system now safely falls back to UTC so the chat opens normally.
Original PR description
Currently, an error occurs when opening the AI chat from the mail composer if the user's timezone has been removed. **Steps to Reproduce:** 1. Install AI and Purchase modules. 2. In the user's profile, remove the 'TimeZone'. 3. Open any purchase order and click on _Send PO_. 4. In the _Compose Email_ form, click on AI icon. **Error:** `AttributeError - 'bool' object has no attribute 'upper'` **Cause:** The issue occurs because `self.env.user.tz` returns False when the user's timezone is not set, causing an error when it tries to use `upper()` method on bool value. **Fix:** This commit fixes the issue by defaulting to the UTC timezone when the user's timezone is not set. **Ref:** https://github.com/odoo/odoo/blob/0f40ea82a1332f0e7168d861ad446b7316ab03de/odoo/addons/base/models/res_partner.py#L225-L228 sentry-6961379038 Forward-Port-Of: odoo/enterprise#98435
This change corrects how Odoo checks whether certain linked fields should be indexed. It now recognizes inherited fields properly, so performance-related indexing guidance is applied to the field that actually needs it. This helps avoid missing important indexing recommendations in models built through inheritance.
Original PR description
Many2one fields that originated from an `inherits` model were not linted for indexing if they were an inverse to a One2many field, because those fields on the inverse model have `store=False`. The Many2one field that needs to be indexed is the one on the delegated model. This commit fixes this by always getting the `base_field` for the inverse field - if it's an inherited field, it will use the source field; if not, it will use the field itself. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234621 Forward-Port-Of: odoo/odoo#234530
The test setup now creates a fresh loyalty program instead of reactivating an existing one. This prevents old reward rules from coming back unexpectedly and makes the tests more reliable.
Original PR description
## Versions 18.3+ ## Issue Tests fail due to free product rewards being reintroduced when a loyalty program is reactivated. ## Cause Reactivating a loyalty program also reactivates its child records, including default rewards. See: https://github.com/odoo/odoo/blob/f03ff6d9b727a22e3b250a5c9cc875b9f1f16263/addons/loyalty/models/loyalty_program.py#L513-L518 ## Fix Create a new loyalty program instead of reactivating an existing one. runbot-232709 Forward-Port-Of: odoo/odoo#228012
The search feature now correctly handles words that lose characters during language normalization, such as accented or tone marks. This prevents search from going past the end of the text and improves reliability for affected users.
Original PR description
The fuzzy search mechanism (specifically the _match utility) calculates the length of the string before normalizing it (e.g., with `unaccent`). However, `unaccent` can remove non-spacing marks (like Thai tone marks or vowels), which changes the length of the string. This mismatch caused the search loop to iterate past the end of the normalized string, leading to incorrect behavior or potential errors. This commit moves the length calculation to after the string has been unaccented, ensuring the loop has the correct bounds. opw-5189276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234616 Forward-Port-Of: odoo/odoo#233249
The barcode app now respects the Manufacturing setting that controls whether reserved lots and serial numbers are shown. This means users only see that information when it is enabled, or when the lot/serial has already been picked or scanned, which helps reduce confusion and picking mistakes.
Original PR description
Issue: ------------------------------------- Lots/serial numbers were always displayed in the barcode module during Manufacturing Order operations, regardless of whether the Show Reserved Lots/SNs…
Issue: ------------------------------------- Lots/serial numbers were always displayed in the barcode module during Manufacturing Order operations, regardless of whether the Show Reserved Lots/SNs option was enabled in the Manufacturing settings. Steps to Produce: ------------------------------------- - In Manufacturing settings, disable the Show Reserved Lots/SNs option. - Create a Manufacturing Order and reserve component lots. - Go to the barcode app - Lots/SNs appear even though the Show Reserved Lots/SNs option is disabled. After this Commit: ------------------------------------- A correct value is now passed to the condition controlling the lot and serial number visibility. Lots/SNs are shown only when Show Reserved Lots/SNs is enabled in Manufacturing settings, or when they have been picked or scanned, helping users focus only on relevant information and reducing the chance of picking or scanning mistakes. Task Id: [3908929](https://www.odoo.com/odoo/project/966/tasks/3908929) Forward-Port-Of: odoo/enterprise#62853
This update prevents temporary loading indicators and disabled states from being permanently saved into website forms while they are edited. It ensures forms keep their normal behavior even if the Cloudflare Turnstile feature is later removed or turned off.
Original PR description
Steps to reproduce: 1. Install the `website_cf_turnstile` module. 2. Enter valid Cloudflare Turnstile credentials in the configuration. 3. Go to the Website Editor. 4. Add or edit a form (e.g.…
Steps to reproduce: 1. Install the `website_cf_turnstile` module. 2. Enter valid Cloudflare Turnstile credentials in the configuration. 3. Go to the Website Editor. 4. Add or edit a form (e.g. contact form) and save the page. 5. Notice that the form’s submit button temporarily shows a spinner and gets a 'disabled' class while Turnstile is initializing. 6. After saving the page, these temporary elements and classes (e.g. .turnstile-spinner and 'disabled') are incorrectly saved into the form’s HTML. 7. If you later remove or uninstall the website_cf_turnstile module, the submit button remains disabled and the spinner icon still appears, even though Turnstile is no longer active. After this commit: Now, when you save a website form in the editor, any temporary classes or elements added by Cloudflare Turnstile are removed. This prevents unwanted changes from being saved to forms. task-4951470 Forward-Port-Of: odoo/odoo#234730 Forward-Port-Of: odoo/odoo#221841
This update prevents the website search bar input from being edited while the page is in edit mode in Firefox. It resolves a browser-specific issue that could cause the search bar to be altered incorrectly, keeping the editing experience consistent across browsers.
Original PR description
Since the [html_builder refactoring], it's possible to type something inside of an input while in the edit mode on Firefox, which is not the expected behavior and which is not the case in other browsers, for example, Chrome. Steps to see the issue: - Open Website and start editing - Drop a searchbar - Click on the input - Type something => It will remove the searchbar and add text to the searchbar button. This happens because of the different behavior on Chrome and Firefox of `pointer-events`. When the input has `pointer-events` set to `none` Chrome blocks any activity on it, including `beforeinput` events, but Firefox doesn't. This commit fixes this problem making the input not `contenteditable`. task-5144517 [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 Forward-Port-Of: odoo/odoo#230764
A background update job was incorrectly replacing employee work phone numbers with the company phone. This fix keeps employee contact details unchanged and avoids unnecessary reprocessing, improving data accuracy and system efficiency.
Original PR description
When executing the ir_cron_data_employee_update_current_version job, employee's work_phone fields would always be overridden by the company phone. We found out that setting the employee phone as the company phone as a default was pretty much never useful. By searching for other computed properties that could be triggered by the cron job, I found out that two computed properties were the exact same as their equivalent in hr_version. I thus removed them. The computed property triggered by the cron would assign current_version_id, even if it was the same. Even in this case will all the computed properties be triggered (even if current_version_id stays the same), so I added a check before to avoid unnecessary recomputations. task-5103739 Forward-Port-Of: odoo/odoo#229010
This update narrows the tooltip cleanup to only the rental information messages, preventing the system from trying to remove the same tooltip twice. As a result, users can edit the website during checkout without encountering an error.
Original PR description
Following commits odoo/odoo@d37d908 and odoo/enterprise@901b8ea, the tooltip cleanup logic disposes elements in `website_sale_renting`, and when the same logic runs again in `payment`, it tries to…
Following commits odoo/odoo@d37d908 and odoo/enterprise@901b8ea, the tooltip cleanup logic disposes elements in `website_sale_renting`, and when the same logic runs again in `payment`, it tries to dispose them a second time, causing a null element error.
Steps to reproduce:
1. Install `website_sale_renting`
2. Install a demo payment method
3. Go to the shop, add any product to the cart, proceed to payment
4. Click the "Edit" button on the website → observe the error
```js
web.assets_frontend_lazy.min.js:3912 TypeError: Cannot read properties of null
(reading 'closest') at Tooltip.dispose (web.assets_frontend_lazy.min.js:2710:70)
at PaymentForm.<anonymous> (web.assets_frontend_…zy.min.js:8282:1450)
at Colibri.destroyInteraction (web.assets_frontend_lazy.min.js:6472:68)
at Colibri.destroy (web.assets_frontend_lazy.min.js:6524:55)
at InteractionService.stopInteractions (web.assets_frontend_lazy.min.js:6584:162)
at InteractionService.stopInteractions (web.assets_frontend_lazy.min.js:6625:907)
at stop (website.assets_insid…rame.min.js:137:290)
at HTMLDocument.<anonymous> (website.assets_insid…rame.min.js:153:450)
at WebsiteBuilderClientAction.onEditPage (web.assets_web.min.js:22215:55)
```
- Restrict tooltip handling to elements with the .o_rental_info_message class to ensure only the intended elements are selected.
- This fix ensures tooltip cleanup is performed safely without re-disposing already disposed elements.When a delivery is finished and no further stock operations are expected, the related sales order will now be marked as invoiced even if not every unit was delivered. This avoids orders staying open incorrectly and gives users a more accurate billing status.
Original PR description
If no other operations are expected on the picking, even if the full quantity wasn't delivered, the order should be marked as invoiced. task-4607401 Fixes #144485 Partial revert of #115871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234412 Forward-Port-Of: odoo/odoo#218322
The Inventory at Date report now works correctly for products using average cost valuation. This prevents an error when viewing stock information for dated inventory reports, so users can review stock and accounting data without interruption.
Original PR description
Steps to reproduce: - Create a product - Set a category using 'avco' valuation - Create a purchase order for that product, with some quantity and unit price - Validate the receipt - Bill the purchase order - Go to Inventory > Reporting > Stock - Use 'Inventory at Date' with today's date Issue: A traceback appears, as the wizard sends a datetime for `at_date` context. However, we compare it later on with `account.move.line.date`, which is a date and will cause a faulty comparison between two different types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a problem where uninstalling certain add-ons could leave the system metadata out of sync with the actual database rules. As a result, modules can now be removed more cleanly without causing follow-up errors or incorrect field settings.
Original PR description
When we uninstall a module, we never reflect impacted models or fields on ir.model or ir.model.fields. That can lead to an inconsistent state after uninstallation: For example, the…
When we uninstall a module, we never reflect impacted models or fields on ir.model or ir.model.fields. That can lead to an inconsistent state after uninstallation:
For example, the 'appointment_account_payment' module that makes `calendar_event_id` not required anymore. After uninstalling it, the ORM will complain that the not-null constraint doesn't exist ("Missing not-null constraint on appointment.answer.input.calendar_event_id"). Also, if we look at the `ir.model.fields` record for `calendar_event_id`, it shows that the field isn't required, but it should be required again (with the correct constraints too).
Add the information of impacted models for the 'to remove' modules, and force the new registry to call `init_models` on them. This will handle constraints and reflection on `ir.model`/`ir.model.fields`. We can then remove the call to `check_tables_exist` (see 3058ca4121048796c38aad78e3e4f5ffde3530f5) since `init_models` will do the job correctly for impacted models.
Also remove a part of the uninstall hook of website because it forces reloading the registry too soon (warning of missing not-null constraint) and the uninstallation manages the case genericly (remove correctly `ir.model.fields` record of `res.config.settings.website_id`)
runbot-error-233770
Forward-Port-Of: odoo/odoo#234742
Forward-Port-Of: odoo/odoo#234364This update corrects how overtime one-time payments are transmitted in Swiss payroll exports. It helps ensure these payments are reported accurately, reducing the risk of payroll discrepancies and manual corrections.
Original PR description
Forward-Port-Of: odoo/enterprise#98730 Forward-Port-Of: odoo/enterprise#98670
Point of Sale popups no longer show an extra OK button when the modal style is used. This makes the interface cleaner and avoids confusing users with duplicate actions.
Original PR description
Before this commit: - An extra `ok` button was displayed in popups that contain the modal class. After this commit: - The extra `ok` button has been removed. task-4919745
This fix ensures employee-related fields can be used in searches and filters even when the user is not an HR user or does not have access to the version record. It removes a restriction that could prevent people from finding the employee data they need.
Original PR description
Before this commit, since now `hr.employee` is inherited by `hr.version` when the other model search employee field, the current user has to access to version or be a hr user to be able to use filters using employee fields. This commit makes sure the employee fields are searchable. runbot-error-233311
When a pay run is created directly from a payslip, its date range now starts from the payslip’s own period instead of the current month. This reduces manual corrections and helps payroll records stay aligned with the payslip being processed.
Original PR description
When creating a pay run directly from the payslip form view, the pay run dates now default to the payslip's period dates instead of the current month. task-5236811
This change reverts a prior update that caused product list page options in the website editor to stop working properly. Restoring the previous behavior ensures these settings remain visible and usable for storefront customization.
Original PR description
This reverts commit 160a2c90a12d683726e7df50d83df10068c55e0b.
This update fixes a crash that could happen when opening Monthly Hours while Extra Hours are enabled. It also ensures the overtime information shown in the list view is accurate, so managers see the correct employee hours without errors or misleading totals.
Original PR description
A stacktrace would be shown when clicking on the "Monthly Hours" smart button, when "Display Extra Hours" is checked in Configuration/Settings This was due to a missing comma in the domain creation. When reviewing the code that was causing the crash, we noticed that the wrong domain was used on the wrong model to fetch overtime data. Also, the function needed logic from hr_holidays (and not just hr_attendance). So I needed to move that to the hr_holidays_attendance. Moreover, the correct values were not displayed in the JS list view (that adds a small summary on top of the list). I had to investigate and fetch the correct info about the selected employee's overtime. task-5106638
Work entries are now correctly updated when an attendance is created, edited, or deleted. This prevents payroll from showing outdated or missing work time, especially when several attendances happen on the same day.
Original PR description
[FIX] hr_work_entry: fix work entries not being regenerated on attendance modification Steps to reproduce: - In Attendance, create, modify or delete an attendance - In Payroll, go to the work entries…
[FIX] hr_work_entry: fix work entries not being regenerated on attendance modification Steps to reproduce: - In Attendance, create, modify or delete an attendance - In Payroll, go to the work entries tab - If creating an attendance, work entries with the previous and current attendance duration will be displayed - If modifying an attendance, changing the duration would not create a new work entry nor modify the existing one(s) - If deleting an attendance, the work entry would be deleted even if there were other attendances on the same day Reason: - For creation, the method creating work entries from attendances had a strict inequality, which caused the check to never trigger. - For modification, nothing was done to regenerate the work entry after editing the duration. - For deletion, the method archived work entries regardless of whether or not there were other attendances in the day. How it was fixed: - For creation, changed the strict inequalities to inequalities to allow the check for work entries to be made - For modification, if the check in or check out dates are changed, triggers the regeneration of linked worked entries - For deletion, the work entry is only deleted when no attendances are left, and then regenerate work entries to match the new total attendance duration Task ID: 5116353
This change prevents Odoo from refreshing stored product data when nothing has actually changed. It reduces wasted processing during product variant creation, which helps keep product operations a bit faster and more efficient.
Original PR description
Description of the issue/feature this PR addresses: Method `product.template._create_variant_ids()` triggers a `write()` on `product.product.product_template_attribute_value_ids` which will, in turn, invalidate the cache. This cache invalidation is unnecessary if the new value is the same as the old value. 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#233677
The mobile search panel now uses colors that better fit dark mode. This makes the interface easier to read and more consistent for users who work in dark mode on smaller screens.
Original PR description
This commit adapts colors of search_panel for mobile in dark mode. | Before | After | |--------|--------| | <img width="904" height="1022" alt="image" src="https://github.com/user-attachments/assets/9136de22-3ce1-40e3-bb79-8f87c8ee2bf8" /> | <img width="372" height="653" alt="Capture d’écran 2025-10-29 à 08 37 39" src="https://github.com/user-attachments/assets/6aff402b-6dc8-46ce-8e2a-d55887374f51" /> | Requires: - https://github.com/odoo/odoo/pull/234361 task-5121027 Forward-Port-Of: odoo/enterprise#98248
This change fixes an error that could appear when users copy an invitation link from the Picture-in-Picture call window. The link now copies normally to the clipboard, improving the experience and avoiding confusing error tracebacks.
Original PR description
**Current behavior before PR:** Attempting to copy the invitation link from the Picture-in-Picture (PIP) window results in a traceback error, indicating that the document is not focused. **Desired behavior after PR is merged:** Copying the invitation link from the PIP (Picture-in-Picture) window no longer triggers a traceback error and successfully copies the link to the user's clipboard. task-[5149370](https://www.odoo.com/odoo/project/1519/tasks/5149370) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Ask AI snippet will no longer automatically grab focus when a page reloads in fullscreen mode. This keeps the page from jumping to the widget unexpectedly, while still preserving the ability to return focus to the input after an AI response.
Original PR description
Scenario: - add "Ask AI" snippet on bottom of a page - reload the page Result: we get autofocused on the "Ask AI" snippet if the snippet is in "Fullscreen" configuration. Fix: avoid the initial focus but keep the code so we re-focus on the input after AI answer. opw-5153332
The mobile search panel now uses the correct background color in both light and dark themes. This improves readability and keeps the bottom sheet view consistent with the rest of the interface.
Original PR description
This commit adjusts the search_panel background color so it adapts correctly to both light and dark modes on mobile. It only affects the "bottom sheet" use case. task-5121027 Requires: - https://github.com/odoo/enterprise/pull/98248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234361
This change updates several website and online store actions to use a standard redirect method when sending visitors to a URL. It helps ensure customers are taken to the right page more reliably after actions like updating a cart, choosing options, or entering address information.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/98492 Forward-Port-Of: odoo/odoo#234384 Forward-Port-Of: odoo/odoo#233842
This update prevents the IoT box installation process from trying to reinstall a package that is already provided by the system on the new image. As a result, setup no longer fails on the latest image, making deployment smoother and more reliable.
Original PR description
When checking out 19.0 from the new IoT box image running Python 3.13, there is an error when running `pip install`: ``` error: subprocess-exited-with-error × Building wheel for cffi (pyproject.toml) did not run successfully. ``` This is due to it trying to install `aiortc` and all its dependencies via `pip` even though it is already installed via `apt`. To fix this, we add a Python version check to the requirement, so that it will only be installed when using an old IoT box image. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When an order status update comes back from Gelato, the customer will now receive the expected email. This fixes a gap where customers were not being notified about the updated order status, improving communication and reducing follow-up issues.
Original PR description
Fix not sending the email to customer, when order status update was received from Gelato. opw-4962878 Forward-Port-Of: odoo/odoo#234017 Forward-Port-Of: odoo/odoo#233587
This change prevents the payment terminal from being listened to again at the wrong time, which could cause the same payment action to be handled more than once. It makes in-store payments more reliable by avoiding duplicate callbacks after a successful response.
Original PR description
Issue is that we were calling `_keepListening` everytime we received a success response from the driver, instead of only on specific cases such as timeout or first message received completely processed. Forward-Port-Of: odoo/enterprise#98901
AI-powered search and view building now understands date-based requests much better, such as filtering by specific periods or grouping results by day, week, month, quarter, or year. This makes it easier for users to get the exact reporting view they want from natural language requests, while also improving accuracy for more detailed date-related queries.
Original PR description
Users can now filter and group records by date using natural language (e.g., "show sales from last quarter grouped by month"). The AI navigation tools now support date filters (dynamic month/year…
Users can now filter and group records by date using natural language (e.g.,
"show sales from last quarter grouped by month"). The AI navigation tools now
support date filters (dynamic month/year patterns with offsets, named quarters,
and custom options) and date groupbys (with intervals) that can interleave with
regular field groupbys to preserve ordering.
- Renamed "Natural Language Search" to "View Builder" throughout codebase
- Enhanced AI tool selection guidance: clarified when to use View Builder
(configure UI) vs Information Retrieval (provide concrete data)
- Added comprehensive date filter system supporting search view declared filters
with dynamic patterns (month±N, year±N), named quarters (first_quarter, etc.),
and custom options
- Added date groupby support with intervals (day/week/month/quarter/year) that
can interleave with regular field groupbys (e.g., ["employee_id",
{"field_name": "date_order", "intervals": ["month"]}])
- Restructured search view XML processing to properly serialize allowed date
filters and date groupbys for AI consumption
- Added validation for date groupbys and date filters in open_menu_*/adjust_search
tools
- Updated JavaScript to handle date filters and date groupbys from AI tool calls
- Updated AI system instructions with detailed documentation about date filtering
and grouping features
Note: Introduced `get_search_view` using `get_views` because `get_view` doesn't
work if we provide a search view id of False.
TASK-ID: 5076645This update restores correct validation for Swedish point-of-sale blackbox orders, which had stopped working after an internal system change. It also fixes receipt reprint tracking and corrects the format of the organisation number so records are validated properly again.
Original PR description
Before this commit, the Swedish blackbox was completely broken in 18.0 because the `push_single_order` function is no longer used. To fix this, the same approach as `pos_blackbox_be` was used, where the `preSyncAllOrders` function was overridden instead. In addition, the old receipt reprinting logic was no longer working, and so it now uses the `nb_print` field to keep track of the number of reprints. Finally, we also forward port a fix from 17.0 (ddbc1fc) to correct the format of the organisation number, which for some reason was not forward ported originally. task-5077448 Forward-Port-Of: odoo/enterprise#98179 Forward-Port-Of: odoo/enterprise#98139
This change fixes an issue where prices in point-of-sale accounting reports were being counted with the wrong sign, which could show incorrect totals for sales and refunds. It also improves screen performance by recalculating prices more efficiently when order lines change, reducing slowdowns on large orders.
Original PR description
Before this commit, the prices in the pos_order_line_accounting model were taking into account the order sign 2 times, leading to incorrect display of prices in accounting reports. This commit fixes the issue by removing the redundant sign application, ensuring that prices are displayed correctly according to the order type --- From a performance standpoint, the `get prices` getter has been removed because it was being called too often. We now calculate prices globally, which requires calculating all order lines at the same time. When refreshing the interface, each line called the getter, which caused slowdowns when many lines were added to the order. Now, the price is recalculated and cached on the order when a line is modified or added.
This fix prevents the chat hub from being hidden behind newly opened chat windows after it has been moved. It also stops the hub from being dragged while chat windows are open, keeping the messaging area usable and easy to access.
Original PR description
Prior to this commit, moving the chat hub could cause newly opened chat windows to appear on top of it, rendering the hub invisible and unusable. This commit fixes the issue by resetting the chat hub's position whenever a chat window opens and disabling its drag functionality while any chat window remains open. task-5227499 Forward-Port-Of: odoo/odoo#234367
This change corrects the accounting entries created when selling products in packaged units. The system now records the full total quantity value instead of only the value of a single unit, so stock valuation and cost of goods sold amounts are accurate.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Cost: $10 - UoM: Unit - Sales tab: - Packaging: Pack of 6 - Category: Goods - Costing Method: AVCO - Inventory Valuation: Perpetual (at…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Cost: $10
- UoM: Unit
- Sales tab:
- Packaging: Pack of 6
- Category: Goods - Costing Method: AVCO - Inventory Valuation: Perpetual (at invoicing) - Expense Account: 500000 Cost of Goods Sold - Stock Account: 110100 Stock Valuation
- Create an invoice:
- Customer: Azure Interior
- Product: P1
- Quantity: 10
- UoM: Pack of 6
- Confirm
Problem:
The journal items created for Stock Valuation and Cost of Goods Sold are computed with an incorrect amount: $100 instead of $600.
Explanation:
In the `_stock_account_prepare_realtime_out_lines_vals` method, the unit price is first computed for a single unit, regardless of the costing method (AVCO, Standard, or FIFO), using the helper method `_get_cogs_value`:
- https://github.com/odoo/odoo/blob/08b62a4bbcc6f9a391b2cc00a621ef4c76100229/addons/stock_account/models/account_move.py#L121
- https://github.com/odoo/odoo/blob/08b62a4bbcc6f9a391b2cc00a621ef4c76100229/addons/stock_account/models/account_move_line.py#L66-L67
In the FIFO case, the computation is based on the stock move value, but still returns the price per single unit:
- https://github.com/odoo/odoo/blob/08b62a4bbcc6f9a391b2cc00a621ef4c76100229/addons/stock_account/models/account_move_line.py#L70-L71
opw-5215191This fix stops action icons such as Open Folder and Rename from appearing in folder pickers and other secondary views. It prevents confusion for users and avoids crashes when those icons are clicked outside the main Documents area.
Original PR description
Action icons (like 'Open Folder', 'Rename', etc.) were incorrectly appearing in list views outside of the main Documents app, for example, when selecting a folder in a settings menu or a popup dialog. This was confusing and caused a crash when an icon was clicked, as the required functionality was not loaded in those contexts. This fix removes the action icons from these secondary views. To keep the fix stable-proof, the template of the widget was modified, in 19.1 we will fix this in cleaner way. The icons are now correctly restricted to the main Documents list view, where they function as intended. Other views (like folder pickers) now behave as standard selection lists without errors. Task-5166843
This change fixes an issue where some screens could crash with a key error when a related record was not available. The system now correctly reports the record as missing instead of failing unexpectedly, which improves stability during normal use and automated processes.
Original PR description
**Issue:** If no of records are [more](https://github.com/odoo/odoo/blob/f40203c0f3954d3c6be7d4234ee102cd903704b6/odoo/orm/fields_relational.py#L63) than the ``PREFETCH_MAX``.So, it just the fetch…
**Issue:**
If no of records are [more](https://github.com/odoo/odoo/blob/f40203c0f3954d3c6be7d4234ee102cd903704b6/odoo/orm/fields_relational.py#L63) than the ``PREFETCH_MAX``.So, it just the fetch the data using ``fetch`` method. If records are less then that then it directly check from ORM and using ``__get__`` method. if record is missing it will raise missing error in that case otherwise records are more in that it directly assume that records are fetch and it directly check from field_cache which leads to key error and here in attachment scenerio code implementation they are expecting to have [missing error](https://github.com/odoo/odoo/blob/f40203c0f3954d3c6be7d4234ee102cd903704b6/odoo/addons/base/models/ir_attachment.py#L588)
**To fix:**
raising missing error
```
Traceback (most recent call last):
File "/tmp/tmpbit0pj9c/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpbit0pj9c/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpbit0pj9c/migrations/base/tests/test_mock_crawl.py", line 430, in mock_act_window
views = get_views(
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 463, in get_views
res = super().get_views(views, options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/models.py", line 10, in get_views
result = super().get_views(views, options=options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_ui_view.py", line 52, in get_views
return super().get_views(views, options)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 2935, in get_views
result['models'][model] = {"fields": self.env[model].fields_get(
File "/home/odoo/src/odoo/19.0/addons/stock/models/product.py", line 512, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_model.py", line 76, in fields_get
return super().fields_get(allfields, attributes=attributes)
File "/home/odoo/src/enterprise/19.0/ai_fields/models/models.py", line 47, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3360, in fields_get
description = field.get_description(self.env, attributes=attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 883, in get_description
value = value(env)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 930, in _description_groupable
model._read_group_groupby(model._table, groupby, query)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_activity_mixin.py", line 259, in _read_group_groupby
return super()._read_group_groupby(alias, groupby_spec, query)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 2064, in _read_group_groupby
coquery = comodel._search(codomain, bypass_access=field.bypass_search_access)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_attachment.py", line 661, in _search
return records._filtered_access('read')[offset:]._as_query(ordered)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4128, in _filtered_access
if self and not self.env.su and (result := self._check_access(operation)):
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_attachment.py", line 544, in _check_access
forbidden_res_model_id = set(self._inaccessible_comodel_records(model_ids, operation))
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_attachment.py", line 586, in _inaccessible_comodel_records
records = records._filtered_access(operation)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4128, in _filtered_access
if self and not self.env.su and (result := self._check_access(operation)):
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4152, in _check_access
if domain and (forbidden := self - self.sudo().filtered_domain(domain)):
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6251, in filtered_domain
predicate = Domain(domain)._as_predicate(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/domains.py", line 1079, in _as_predicate
func = field.filter_function(records, field_expr, positive_operator, value)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_relational.py", line 179, in filter_function
corecords = getter(records)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_relational.py", line 71, in __get__
vals.append(field_cache[record_id])
KeyError: 3
```
upg-3267511
opw-5246118
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe appointment website no longer caps resource booking quantities at a hardcoded value of 12. A new global setting lets administrators define the maximum allowed capacity, so bookings can match the actual resource size.
Original PR description
**Steps to reproduce:** - Install Appointment and Website apps - Create a resource with capacity above 12 - Create an appointment_type on `Resources` - Check `Manage Capacities` - Set its assignment method to `Select Time then auto-assign` - Go to the website and select the new resource - The maximum capacity you can book in the drop-down list is stuck to 12 **Issue:** Arbitrary maximum value (12) seemed to be used in the appointment website and controllers, for the resource capacity which can be booked by someone. **Fix:** Added `resource_max_capacity_allowed` setting to configure the maximum allowed value globally. related: https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc related: https://github.com/odoo/enterprise/commit/db36b59c80b45c6df1da3ac9dc876e79121e5e5e opw-5059177 Forward-Port-Of: odoo/enterprise#98956 Forward-Port-Of: odoo/enterprise#94935
This update prevents an error when Odoo Fin transactions include a field that the import process does not expect. As a result, missing transactions can be fetched more reliably without interrupting the user with a traceback.
Original PR description
… missing transactions The field `end_to_end_uuid` was introduced in `account_iso20022` on the bank statement line model but is absent from the corresponding transient model used by `account_online_synchronization`. When a transaction payload from OdooFin includes this field, processing it raises a traceback because the field does not exist on the transient model. This commit drops the `end_to_end_uuid` key from incoming transactions to avoid the error. task-5223434
The Time Off allocation form no longer shows a past-due warning for allocations that are actually scheduled in the future. This corrects a confusing message so users only see the warning when an allocation really ends in the past.
Original PR description
steps to reproduce:
- Go to Time Off > Allocations
- Create new allocation
- Set `date_from` and `date_to` (future dates)
- Notice the warning 'The allocated days cannot be used, because the allocation is set to finish in the past' appears incorrectly
cause:
- The warning visibility condition used literal string `'today'` instead of proper date comparison, causing incorrect evaluation in view expressions.
fix:
- Replace `'today'` string with `context_today().strftime('%Y-%m-%d')` in the invisible condition.
- This ensures the warning only appears when `date_to` is actually in the past.
task-5009365When a picking is automatically grouped into a new batch, its responsible person now remains assigned correctly. This prevents staff ownership information from being lost during automated warehouse processing.
Original PR description
## Issue When auto-batching a picking create a new batch, the picking's responsible is lost when the picking is added to the batch. ## How to reproduce 1. Enable auto-batch for receipt operation type (by partner for example) 2. Create a new picking and assign a responsible; 3. Confirm the picking -> It's automatically added to a new batch and the picking's responsible is lost. ## Explanation When a picking is added to a batch, the batch's responsible is assigned as the picking responsible which is totally wanted. The issue here is a new batch is created without a responsible and thus, `False` is assigned as the picking's responsible when the picking is added to the batch. ## Fix To fix that, if a batch is created by a single picking, the picking's responsible is the batch responsible. **Enterprise PR:** odoo/enterprise#96657
When a contact has more than one email address, sending a message from the chatter could incorrectly treat the extra address as a new person. This fix makes Odoo match the contact correctly, preventing duplicate contacts from being created and keeping recipient lists accurate.
Original PR description
**Steps to reproduce:** - Go to the `Contacts` app - Create a new contact - Add multiple emails in the email field (e.g. `"test1@example.com,test2@example.com"`) - Click on `Send Message` button in…
**Steps to reproduce:** - Go to the `Contacts` app - Create a new contact - Add multiple emails in the email field (e.g. `"test1@example.com,test2@example.com"`) - Click on `Send Message` button in the chatter - Default recipients are computed for each email - One of them match the contact, the other doesn't but still pass to the badges list - When sending a message, the second mail is considered as a new contact to create **Issue:** Emails coming from an email field with multiple emails are considered separately when added in the chatter recipients. The partner only match the first one which means that the second one creates a duplicate. This seems to be the default behavior when receiving an email from the additional email address of a partner (`If an email is not unique (e.g. multi-email input), only the first found valid email in input is considered.`), but automatically filling the recipients badges in this way seemed unintended. **Fix:** Properly parsed the email field of recipients to match the partner and avoid creating a duplicate when sending a message on a contact page. opw-4929564 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220593
This update fixes the slide highlighting behavior when a presentation is switched to fullscreen. It ensures the highlighting interaction restarts properly so users see the expected visual guidance during fullscreen viewing.
Original PR description
**Issue:** `this.websiteAnimateWidget` is undefined Also the fix wasn't working properly in later versions. This is due to an incorrect conflict resolution in the forward port of the related fix. **Fix:** The fix for websiteAnimateWidget was made obsolete in these versions with: https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba But the original issue of `textHighlightWidget` was still present and not properly caught by the tour. The new fix add the fullscreen slide to the selector of the TextHighlight interaction which is restarted when fullscreen is enabled. related: https://github.com/odoo/odoo/commit/184c6f855f703239864f482ff252beb1293c343d opw-4978798 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234704 Forward-Port-Of: odoo/odoo#234107
This change fixes an issue in POS restaurant where the guest count popup could not be used when sending an order to the preparation display during payment. It ensures staff can still choose the number of guests, and if no number is selected, the system falls back to the table’s maximum guest count.
Original PR description
Steps to preproduce: - Set a preset with Guests amount - Make an order with that preset with a product set on preparation display - Go to payment without ordering - Pay and send order to preparation display - The ui is blocked and it is not possible to select the number of Guests Issue: In this PR: [#216523](https://github.com/odoo/odoo/pull/216523) the ui is blocked when paying and calling sendOrderInPreparationUpdateLastChange, since the selection of the number of guest is made inside that method the uiBlok blocks the popup. Fix: Extract the part of the code responsible for the selection of the number of guest. Additional note: If the user dismisses the popup or selects 0, the default number of guests will be set to the table maximum number of guests, as defined in the specification of task-4497128. opw-5113007
Large Excel files with many sheets could fail when opening them in Documents and converting them into an O-spreadsheet. This fix makes the conversion work reliably for very large files, preventing errors for users handling big spreadsheets.
Original PR description
Steps to reproduce: - upload a large xlsx file (e.g. with >1000 sheets) - open it and convert it to o-spreadsheet => traceback Task: 5222481 Forward-Port-Of: odoo/enterprise#98482 Forward-Port-Of: odoo/enterprise#98443
The employee time off dashboard now correctly shows extra hours coming from attendance records. This fixes a visibility issue that could make the available balance look incomplete, helping managers and employees see the full picture of time off and overtime data.
Original PR description
### Steps to reproduce: - Install Attendance and Time off apps - Create some attendance with extra hours for the employee - Go to the employee's time off dashboard - Notice Extra Hours allocation is not shown ### Cause: When we are getting the allocation data we check for the leave types that require allocation https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/hr_holidays/models/hr_leave_type.py#L473 And then when checking the types that doesn't require allocation we are looping on the res that we got from the super which already excluded those types https://github.com/odoo/odoo/blob/5f6d2afa8c09fe72c01d056ebef01214567a4a99/addons/hr_holidays_attendance/models/hr_leave_type.py#L41-L43 ### Fix: We loop over the self leave types to make sure we are getting all of the employee's leave data whether the type requires allocation or not. opw-5042325 Forward-Port-Of: odoo/odoo#234426 Forward-Port-Of: odoo/odoo#225015
When someone is invited to a meeting, they now receive only the meeting invitation card instead of both that card and an extra channel notification. This makes the experience clearer and reduces redundant alerts for recipients.
Original PR description
Before this PR, when inviting someone to a meeting, they received both a call invitation card and a channel invited notification, which was redundant. This change removes the duplicate notification, keeping only the call invitation card for clarity. <img width="613" height="200" alt="image" src="https://github.com/user-attachments/assets/dd525c84-4ee4-4961-88e5-a17cf3938785" /> part of task- [5227387](https://www.odoo.com/odoo/project/1519/tasks/5227387) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The live chat dashboard now calculates the rating percentage only from sessions that were actually rated. This prevents unrated chats from lowering or skewing the reported score, making the dashboard more reliable for business reviews.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Before this change, the live chat rating percentage in the dashboard included sessions that were not rated, which made the overall rating misleading. While the sessions reporting view allowed filtering on "rating is set", the dashboard did not provide this option. **Current behavior before PR:** --------------------------------- - Unrated sessions are included in the dashboard rating percentage - The percentage is misleading compared to the sessions reporting view **Desired behavior after PR is merged:** ----------------------------------------- - The dashboard rating percentage only considers sessions with a rating - Unrated sessions are excluded, resulting in a more accurate rating display **Task:** 5048700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227474
Project aliases now correctly handle incoming emails even when the recipient is shown with a display name, which is common in email clients. This prevents the task creation flow from failing with an error and helps ensure messages sent to project aliases are processed reliably.
Original PR description
**Steps to reproduce** - Set an alias on a project, e.g. `my-project@my-domain.com` - Send an email to this alias, with the `To` part including a display name (default in most clients). e.g. `To: MyProject <my-project@my-domain.com>` - Issue: the task is not created because of a traceback `ValueError: list.remove(x): x not in list` **Change** The values in the dict returned by `_mail_cc_sanitized_raw_dict` can be more than just an email, so use the keys instead. Note: use `discard` instead of `remove` to avoid error if for some reason a partner has the same mail as the alias. opw-5176607
This update fixes an issue where repeated opening and closing of IoT device screens left old network requests running in the background. By cancelling the previous request when a new one starts, it prevents browser request limits from being reached and keeps the IoT interface working reliably.
Original PR description
Steps to reproduce: 1. Pair an IoT box 2. In the IoT form view, click on any device, then click back to return to the IoT form view. 3. Repeat this step multiple times. If you have devtools open, you can see a `/event` fetch request every time you open the device form. Expected behaviour: - When a new request is made, the previous request is cancelled. Actual behaviour: - The previous requests remain active, and eventually no further requests are possible due to browser limits. This behaviour was broken when the longpolling was changed to use the `fetch` method instead of Odoo's `rpc` method. This commit restores the behaviour by using an `AbortController` instance which is aborted when `stopPolling` is called. Manual Forward Port of Enterprise PR: https://github.com/odoo/enterprise/pull/98985 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234872
Selecting an EasyPost carrier no longer triggers an error during setup. This fixes a mismatch in how the carrier selection is handled, so users can load and choose carrier accounts smoothly.
Original PR description
**Issue** A traceback occurs whenever a carrier is selected in the EasyPost delivery method. **Steps to reproduce** 1. Install the barcode application 2. Go to Settings > Inventory > enable…
**Issue** A traceback occurs whenever a carrier is selected in the EasyPost delivery method. **Steps to reproduce** 1. Install the barcode application 2. Go to Settings > Inventory > enable "Easypost" shipping connector 3. Go to Delivery Methods -> click "New" -> choose "Easypost" as provider 4. Fill in the API keys 5. Click "Load your Easypost carrier accounts" and select a carrier → A traceback occurs **Cause** The error occurs at: https://github.com/odoo/enterprise/blob/39320569a3561f133000ded00800f705d9507ac2/delivery_easypost/static/src/components/carrier_type_selection/carrier_type_selection.js#L15 `ev` is expected to be a JSON object but is received as a string. The component extends `SelectionField`, which has been modified in [this commit](https://github.com/odoo/odoo/commit/0923409082ead5ffdf2c28f3b063fbd91ebce553): https://github.com/odoo/odoo/blob/5be6ef1ae3958a25e680f5fa30824fec57d63efe/addons/web/static/src/views/fields/selection/selection_field.xml#L9 **Solution** Adapt the `onChange` method to handle the argument type change. opw-5170833
This change resolves an error that could block confirming or updating a manufacturing order when it is created from the Bill of Materials overview, especially for products with multi-level BoMs. As a result, users can complete manufacturing actions normally instead of being interrupted by a technical error.
Original PR description
This PR fixes the error that occurs when confirming an MO from the BoM overview for a product with a 2 level BoM.
Bug Reproduction:
1- Create BoM for a Main Product.
2- Create a child BoM for any component in the main Product's BoM and make that component have an MTO route.
3- Navigate to the BoM Overview of the Main Product.
4- Click "Manufacture" to create an MO for the Main Product.
5- Click the save icon in the MO.
6- There are two scenarios to reproduce the error now:
a- Confirm the MO form.
b- Or update the quantity to produce in the MO.
= The confirmation or update of the MO is blocked, it should be allowed.
The Issue:
A dirty context is being passed from the BoM overview. it sets the `default_product_qty` to be set in the MO. However, when creating the moves necessary for the MO, this makes an issue as `product_qty` should never be set in stock moves, we set `product_uom_qty` instead.
Task-4795105
Forward-Port-Of: odoo/odoo#214305Miscellaneous changes
task-5184489 Related: https://github.com/odoo/odoo/pull/233275 Forward-Port-Of: odoo/enterprise#98949 Forward-Port-Of: odoo/enterprise#98193
Original PR description
task-5184489 Related: https://github.com/odoo/odoo/pull/233275 Forward-Port-Of: odoo/enterprise#98949 Forward-Port-Of: odoo/enterprise#98193
task-5184489 Related: https://github.com/odoo/enterprise/pull/98193 Forward-Port-Of: odoo/odoo#234625 Forward-Port-Of: odoo/odoo#233275
Original PR description
task-5184489 Related: https://github.com/odoo/enterprise/pull/98193 Forward-Port-Of: odoo/odoo#234625 Forward-Port-Of: odoo/odoo#233275