Daily updates from Odoo
Friday, November 7, 2025
176 changes
16 changes
Resolved issues and error corrections
The replenishment list now updates the quantity to order whenever the visibility horizon is changed. This keeps the displayed stock planning figures aligned with the expected replenishment needs and avoids confusion for users.
Original PR description
## **Issue Before This PR:** When the `horizon (visibility days)` is updated from the left panel, the `quantity to order` for orderpoints was not automatically recomputed. This caused an…
## **Issue Before This PR:** When the `horizon (visibility days)` is updated from the left panel, the `quantity to order` for orderpoints was not automatically recomputed. This caused an inconsistency between the expected replenishment quantity and the value displayed in the orderpoint list, leading to confusion in stock planning. ## **Steps to Reproduce:** - Install `Inventory (stock)` and `Sales (sale_management)` module, - Add a product with 0 on-hand quantity, - Create a replenishment rule for this product with manual trigger, - Create a sale order with the same product with delivery date 10 days later, - Confirm the sale order, - Open the replenishment menu in Inventory, - Change the horizon (visibility days) to 10, - Observe that qty_to_order is not updated automatically, causing inconsistency. ## **Cause of the Issue:** This bug was introduced in PR #213745, where `qty_to_order_computed` was made `store=True` and `qty_forecast` was removed from its `depends`. As a result, the compute method is not called on relevant changes and the value does not get updated. ## **With This PR:** The `_compute_qty_to_order_computed` is now manually called which updates the value each time the horizon is updated. This ensures that the `qty_to_order` field reflects the correct values and resolves the inconsistency in replenishment quantities. TaskID: [4988468](https://www.odoo.com/odoo/project/966/tasks/4988468)
This change fixes a problem in the editor where selecting table cells from right to left or bottom to top could lose the first selected cell in Firefox. It makes table selection behave 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
When a guest joins a meeting through the welcome page and changes their name, the updated name now appears immediately in the member list. This makes participant lists more accurate and avoids confusion for meeting hosts and attendees.
Original PR description
**Steps to Reproduce:** - Login with Admin, start a meeting, open the member list. - Join the meeting with a guest, using the invite link. - Change the guest name from the welcome page. - Admin member list doesn't show updated guest name. **Current behavior before PR:** Before this PR, the guest appeared as `Guest` in the member list even after updating their name on the welcome page. **Desired behavior after PR is merged:** This PR ensures the guest name is updated and displayed instantly upon joining, providing a smoother and more consistent experience. task-[5062702](https://www.odoo.com/odoo/project/1519/tasks/5062702) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234299
This change prevents an unnecessary validation error during database migration when a tax distribution total is zero. It ensures the system only flags invalid totals when that check is actually meaningful, helping upgrades complete smoothly.
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#234334This change prevents archived reconciliation models from appearing in the list of available matching rules in the Bank journal. It helps users avoid accidentally using inactive models and keeps the reconciliation screen accurate and easier to use.
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 change prevents an error when opening the AI assistant from the email composer if a user's timezone has been removed. If no timezone is set, the system now safely falls back to UTC so users can continue working without interruption.
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 update fixes an issue in website forms where changing a field name could corrupt visibility rules and cause the site editor to crash. It helps keep form settings stable when users rename fields or adjust conditional display rules.
Original PR description
This commit resolve the traceback arise after the refactoring of snippet options. Steps to reproduce this traceback: 1. Drop Form snippet and add text field A 2. add text field B, change visibility condition to depend on A 3. change label text of B to A 4. save snippet 5. instance crashes and cant's do anything in instance after that. This commit aims to: - Correct `previousInputName` to be taken from the first input element’s `name` instead of the container element. - Ensure dependent fields update their `data-visibility-dependency` correctly based on the old input name. - Detect and remove circular visibility dependencies when renaming fields to conflicting names. - Prevent instance crashes caused by corrupted visibility dependency data during label renames.
This update fixes the barcode app so reserved lot and serial numbers only appear in Manufacturing when the relevant display option is enabled. It helps users see only the information they need, reducing confusion and the risk of picking or scanning 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 change prevents an error that could appear when users open payment-related invoice lists from batch payments. The system now applies a specific view option only where it is relevant, avoiding a mismatch between invoice and payment records and keeping the workflow smooth.
Original PR description
Repro: - Create DDM for a client - Create 4+ invoices for him - Pay with SEPA - Go to batch payment set it with SEPA - Add all the invoices and set the date to any date <5 days from today. - A yellow line will appear along with (View All).. / click it - From the view click on any payment. - Exception arises saying made_sequence_gap not found in account.payment Issue: made_sequence_gap belongs to 'account.move' incompatible with 'account.payment' causing the exception. Solution: Here the view_duplicated_moves_tree_js view is intended for account.move elements not for account.payment ones, So I included it only when the resModel is account.move. opw-5149260 Forward-Port-Of: odoo/odoo#233450
The test setup now creates a fresh loyalty program instead of reusing an old one. This prevents previously deactivated reward records from being unintentionally restored during testing, which was causing test failures.
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
This update prevents certain spreadsheet actions from failing when they are run outside the normal calculation flow, such as in version history. It improves stability by avoiding unexpected errors when a currency setting is not available.
Original PR description
Some getters are (too) tied with the evaluation and sometimes take the liberty to throw evaluation-related errors. This can only work if the said getter is called exclusively in the within the…
Some getters are (too) tied with the evaluation and sometimes take the liberty to throw evaluation-related errors. This can only work if the said getter is called exclusively in the within the context of the evaluation (which has a splendid try/catch statement to this effect). Issues start to appear when we start using the said getters outside the evaluation and this is what happens. Since https://github.com/odoo/o-spreadsheet/issues/6083, we call the getter `getPivotCellFromPosition` which in specific cases call `getCompanyCurrencyFormat` and the latter will throw errors when starting and RPC. However, its effect was hidden by the sortcut added in https://github.com/odoo/odoo/pull/151725. The effect could only be seen in a version history action where we did not provide a default currency to the model config. This commit fixes the symptom but not the original cause: having getters that throw and are not handled in the components life-cycle. Such getters should probably disappear in a future refactoring. Task-5187293 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update stops website forms from saving temporary Turnstile loading states, such as the spinner and disabled button styling. It ensures forms stay clean and continue working normally even if the Turnstile module is later removed.
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 corrects how payment amounts are written in words on Philippine checks when there is a decimal part. It removes the trailing “ONLY” in those cases and standardizes the wording so checks follow the expected local format.
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
The search feature now measures text length after accents and similar marks are removed, so it no longer reads past the end of the cleaned-up text. This prevents incorrect search results and reduces the risk of errors for languages that use these marks, such as Thai.
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
Creating a new employee version now copies all relevant version details, so the new record keeps the same information as the original. The Group S duplicate check was also adjusted to validate per employee instead of per version, preventing overly strict errors when multiple versions belong to the same person.
Original PR description
## [FIX] hr*: make sure copy of a version copy all version fields This commit makes sure all the information of a version is completely duplicated when the user creates a new version from an existing version of an employee. ## [FIX] l10n_be_hr_payroll_group_s: move group S unicity constraint per employee Before this commit, the group S unicity constraint were per versions since before it was per contract. Now, since we no longer any contract model and more than version could represent the same contract, that constraint is a bit too restrictive. Moreover, the group S is more stored on the employee, so it would surely make more sense to trigger an error if 2 different employees have the same group S code. This commit moves the group S unicity constraint in hr.employee model to make sure we check per employee instead of per version.
This update fixes how employee version changes are recorded so edits made by users are correctly tracked, even when creating a new version at the same time. It also ensures all version details are copied consistently, preventing missing information or unintended side effects during version creation.
Original PR description
## [FIX] hr: track the fields updated when creating new version Before this commit, when the user alters an employee form view and then create a new version, if a version exists on that employee…
## [FIX] hr: track the fields updated when creating new version Before this commit, when the user alters an employee form view and then create a new version, if a version exists on that employee altered, it will copy the version with the changes made by the user at the same time and so no tracking values on the values changed by the user are created. This commit makes sure the changes made by the user are correctly tracked when a new version is created with some values given in parameter. ## [FIX] hr: add explanation how to change group on version fields in employee model ## [FIX] hr*: make sure copy of a version copy all version fields This commit makes sure all the information of a version is completely duplicated when the user creates a new version from an existing version of an employee. ## [FIX] hr: protect fields copied in create_version to avoid recomputing Before this commit, since now we do a write after the copy of a new version to be able to track the changes made by the user. We cannot guarantee the vals given to the write will trigger a compute method from a field copied. This commit makes sure the version fields copied will never be invalidated and only the fields inside the write (that is, the fields altered by the user) will be altered.
19 changes
Resolved issues and error corrections
This update fixes a problem in the editor where selecting table cells from right to left or bottom to top could lose the first selected cell in Firefox. It makes table selection behave 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
When a guest changes their name on the meeting welcome page, the updated name now appears right away in the attendee list. This makes meeting participation clearer and avoids confusion for hosts and other participants.
Original PR description
**Steps to Reproduce:** - Login with Admin, start a meeting, open the member list. - Join the meeting with a guest, using the invite link. - Change the guest name from the welcome page. - Admin member list doesn't show updated guest name. **Current behavior before PR:** Before this PR, the guest appeared as `Guest` in the member list even after updating their name on the welcome page. **Desired behavior after PR is merged:** This PR ensures the guest name is updated and displayed instantly upon joining, providing a smoother and more consistent experience. task-[5062702](https://www.odoo.com/odoo/project/1519/tasks/5062702) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234299
This change fixes a migration issue where certain tax distributions could incorrectly fail validation and stop the database upgrade. It ensures records with no positive distribution are handled correctly, reducing unexpected errors during upgrades.
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#234334This fix makes lot and serial numbers appear in the barcode app only when the Manufacturing setting to show reserved lots/SNs is enabled, or when they have already been picked or scanned. It reduces visual clutter and helps users avoid picking or scanning the wrong items during manufacturing operations.
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 fix ensures that when users switch between IoT device screens, any previous background request is properly stopped before starting a new one. It prevents requests from piling up and avoids timeouts that could stop IoT actions from 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…
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, causing action calls to timeout. This behaviour was broken when the longpolling was changed to use the `fetch` method instead of jquery. This commit restores the behaviour by using an `AbortController` instance which is aborted when `stopPolling` is called. Before the fix (action times out due to many stuck event calls): <img width="545" height="249" alt="image" src="https://github.com/user-attachments/assets/f18b8a5d-c27c-47a3-ab58-428a78ef5383" /> After the fix (action succeeds): <img width="538" height="228" alt="image" src="https://github.com/user-attachments/assets/30f2863e-9df9-4a6e-b715-135ece4224ed" /> Forward-Port-Of: odoo/enterprise#98985
This update corrects an automated test for restaurant preparation tickets so it matches the current system behavior. It helps ensure the test keeps validating the right result after changes to how empty tickets are handled.
Original PR description
pos_* = post_restaurant_preparation_display Before this PR (https://github.com/odoo/odoo/pull/231733), the checkPreparationTicketData method returned True if the preparation ticket was empty. This is no longer the case, so the test has been updated to work correctly now. Related Community PR: https://github.com/odoo/odoo/pull/231733 Forward-Port-Of: odoo/enterprise#97333
This update fixes the live chat dashboard so its rating percentage only includes sessions that were actually rated. This makes the displayed score more accurate and consistent with the reporting view, helping teams rely on the dashboard for a true picture of customer feedback.
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
When a website form is edited and saved, temporary elements added by Cloudflare Turnstile no longer get stored in the page content. This avoids forms being left with a disabled button or spinner after Turnstile is removed or turned off, keeping the site’s forms working as expected.
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
Quality checks created during receipt validation now keep the same company as the related stock movement. This prevents cross-company errors when users switch companies before confirming a draft receipt.
Original PR description
When creating quality checks per quantity, a multi-company error occurs if the active company differs from the one defined on the control point. Steps to reproduce: - Create a Quality Control Point for Company B and Product Table for the receipt operation with a per-quantity control. - Create a receipt in Company B for this product but leave it in draft. - Switch to Company A and try to confirm → error. Root cause: The company_id was not set when creating the quality check, causing it to default to `env.company` (A) instead of the stock move line’s company (B). opw-86993 Forward-Port-Of: odoo/enterprise#98827 Forward-Port-Of: odoo/enterprise#98655
This change prevents an error that could appear when users open a payment from certain invoice-related views. The system now only applies invoice-specific behavior to invoices, avoiding a mismatch that could break the payment screen.
Original PR description
Repro: - Create DDM for a client - Create 4+ invoices for him - Pay with SEPA - Go to batch payment set it with SEPA - Add all the invoices and set the date to any date <5 days from today. - A yellow line will appear along with (View All).. / click it - From the view click on any payment. - Exception arises saying made_sequence_gap not found in account.payment Issue: made_sequence_gap belongs to 'account.move' incompatible with 'account.payment' causing the exception. Solution: Here the view_duplicated_moves_tree_js view is intended for account.move elements not for account.payment ones, So I included it only when the resModel is account.move. opw-5149260 Forward-Port-Of: odoo/odoo#233450
The color picker interface now updates properly when users select grayscale, transparent grayscale, or theme colors. This makes it easier to fine-tune these colors and keeps the on-screen controls aligned with the selected color.
Original PR description
Before this commit, the colorpicker UI would not update when switching to some colors (grayscale, transparent grayscale, theme colors). It would therefore be difficult to make small changes to those colors. This commit make the colorpicker update correctly. Step to reproduce the bug (example with grayscale colors): - Add a snippet - Change the background color to a custom color (the colorpicker interface was updated to match the color) - Change the background color to a grayscale color (the colorpicker interface was not updated to match the color) task-3806989 Forward-Port-Of: odoo/odoo#179883
Uploading an unsupported file type in the Sign app no longer triggers a traceback when debug mode is enabled. Users now see a clear error message instead, which makes the app more reliable and easier to use during troubleshooting.
Original PR description
Version: - saas-18.3 Steps to reproduce: - Enable debug mode. - Try uploading a non-PDF file in the Sign app. Before: - Uploading a non-PDF file in debug mode caused a traceback error. - The TemplateAlertDialog component tried to use a message prop that wasn’t defined. After: - Replaced the use of the undefined message prop with the correct body prop to display the error message. Impact: - Fixes the traceback error in debug mode. - Shows a clear and user-friendly error message when uploading unsupported file types. task-4828439
This update brings back the Save button and the related logic for trusted point of sale orders. It ensures the POS behaves as expected again for businesses relying on trusted order workflows, avoiding disruptions in daily operations.
Original PR description
The button save and all the logic about trusted orders were removed. This commit puts it back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220309 Forward-Port-Of: odoo/odoo#200567
This update corrects how fuzzy search measures text length after letters with accents or tone marks are simplified. As a result, searches are more reliable for languages that use these marks, reducing the risk of missing results or search errors.
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 search panel background on mobile now adjusts correctly in both light and dark modes. This makes the popover view easier to read and more consistent with the rest of the app.
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 "popover" 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 update adjusts the search panel colors on mobile when dark mode is enabled. It makes the interface easier to read and more consistent with the rest of the dark theme.
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
Checks in the Philippines will now show the amount in words correctly when the payment includes cents. This removes the trailing “ONLY” in those cases and uses the proper lowercase “and” for the decimal part, making printed checks more accurate and compliant.
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
This change fixes an issue that could block confirming or updating a manufacturing order created from the BoM overview. It ensures the right quantity information is passed along, so users can continue working without the process failing.
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-4795105Sales orders that have been delivered are now marked as invoiced even when the full ordered quantity was not shipped, as long as no further stock operations are expected. This reduces confusion and prevents orders from incorrectly appearing as still waiting for invoicing.
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
5 changes
Resolved issues and error corrections
Lot and serial numbers in the barcode app are now shown only when the Manufacturing setting allows reserved lots/SNs, or when they have already been picked or scanned. This makes the interface less cluttered and helps users avoid working with information that should not be visible yet.
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 fix prevents repeated IoT screen actions from leaving old background requests running. As a result, the IoT interface stays responsive and avoids timeouts when users open and close device views repeatedly.
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…
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, causing action calls to timeout. This behaviour was broken when the longpolling was changed to use the `fetch` method instead of jquery. This commit restores the behaviour by using an `AbortController` instance which is aborted when `stopPolling` is called. Before the fix (action times out due to many stuck event calls): <img width="545" height="249" alt="image" src="https://github.com/user-attachments/assets/f18b8a5d-c27c-47a3-ab58-428a78ef5383" /> After the fix (action succeeds): <img width="538" height="228" alt="image" src="https://github.com/user-attachments/assets/30f2863e-9df9-4a6e-b715-135ece4224ed" /> Forward-Port-Of: odoo/enterprise#98985
The mobile search panel now uses colors that are better adapted for dark mode. This makes the interface easier to read and more visually consistent for users who work in dark mode on mobile devices.
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
Quality checks created per quantity now use the correct company from the related stock move line instead of the currently active company. This prevents errors in multi-company setups when confirming receipts or other stock operations.
Original PR description
When creating quality checks per quantity, a multi-company error occurs if the active company differs from the one defined on the control point. Steps to reproduce: - Create a Quality Control Point for Company B and Product Table for the receipt operation with a per-quantity control. - Create a receipt in Company B for this product but leave it in draft. - Switch to Company A and try to confirm → error. Root cause: The company_id was not set when creating the quality check, causing it to default to `env.company` (A) instead of the stock move line’s company (B). opw-86993 Forward-Port-Of: odoo/enterprise#98827 Forward-Port-Of: odoo/enterprise#98655
The wording on Philippine check prints has been corrected for amounts with decimals. When an amount includes centavos, the printed text now uses the proper format and no longer ends with “ONLY”, helping avoid incorrect check wording.
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
15 changes
Resolved issues and error corrections
This fix prevents the AI chat from crashing when a user has no timezone set in their profile. If no timezone is available, the system now uses UTC so users can continue composing emails with AI assistance without interruption.
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
Archived reconciliation models are now hidden from the list of available options when matching bank transactions. This prevents users from accidentally selecting outdated or disabled rules and keeps the reconciliation workflow aligned with active settings.
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 fixes manufacturing barcode screens so lot and serial numbers are only shown when the Manufacturing setting allows it, or when those items have already been picked or scanned. It reduces clutter for operators and lowers the risk of selecting or scanning the wrong component.
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 fixes an issue where connecting an IoT Box could fail while creating its record if the version information was not yet available. The system now checks that the version is present before using it, helping ensure smoother IoT Box setup.
Original PR description
In order to avoid a traceback when creating the IoT Box record after connection, we need to ensure the version is set, before checking whether the first character is a "W". Forward-Port-Of: odoo/enterprise#98871
Philippine check printing now formats amounts with centavos correctly by removing the trailing "ONLY" when decimal amounts are present. The wording for decimal amounts was also adjusted to use lowercase "and", helping printed checks match local formatting expectations.
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
Completed manufacturing orders can no longer be canceled from the list view. Instead, users receive a clear error, preventing the related stock transfer from being canceled by mistake and keeping production records accurate.
Original PR description
Steps to reproduce:
- Enable multi-step routes.
- Go to Warehouse:
- Manufacturing Operations - Enable 3 steps.
- Create a storable product P1.
- Create a MO to produce one unit of P1.
- Validate the MO.
- Go to the MO list view.
- Select the MO.
- Try to cancel it.
Issue:
The MO is not canceled, but the picking from production to stock is canceled instead.
A done MO should not be cancelable, a UserError should be raised.
opw-5216220
Forward-Port-Of: odoo/enterprise#98954
Forward-Port-Of: odoo/enterprise#98758This fixes how Swiss payroll handles overtime as one-time payments in ELM transmissions. It helps ensure overtime-related payroll data is reported correctly, reducing payroll reporting errors and follow-up corrections.
Original PR description
Forward-Port-Of: odoo/enterprise#98730 Forward-Port-Of: odoo/enterprise#98670
Appointments no longer cap resource bookings at a fixed limit of 12. Businesses can now set a global maximum allowed capacity, so higher-capacity resources can be booked correctly on the website and related reservation flows.
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
Fixed an issue where repeated navigation in the IoT device screens could leave old event requests running in the browser. This prevents browser connection limits from being reached, keeping IoT device views responsive during normal use.
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 https://github.com/odoo/enterprise/pull/98985
The mobile search panel now uses colors that fit dark mode better. This improves readability and visual consistency for users working 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
The Planning app now handles missing employee data when opening an avatar popover, such as for archived employees. This prevents an error screen and lets users continue working without interruption.
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#98963 Forward-Port-Of: odoo/enterprise#98230
The employee salary offer button now shows all offers linked to the employee across every contract version, instead of only the currently displayed version. This gives HR users an accurate count and avoids missing offers when reviewing employee salary information.
Original PR description
Fix offers count shown in the smart button to show all offers of the mployee in all version, not just the version being displayed. Task-5082700
When a pay run is created from an employee payslip, its dates now automatically match the payslip's pay period. This prevents incorrect default dates and reduces manual corrections for payroll teams.
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 Forward-Port-Of: odoo/enterprise#98799
Folder selection dialogs now show only the expected list options, without document action icons such as open or rename. This prevents confusing choices and avoids crashes when users select folders outside the main Documents app.
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 Forward-Port-Of: odoo/enterprise#97861
Opening the Timesheets and Planning Analysis view could fail because cost amounts were treated as monetary values without an associated currency. The fix ensures the analysis can load correctly, so project users can access planning and timesheet cost insights 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 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. opw-5176269 Forward-Port-Of: odoo/enterprise#97768
36 changes
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
7 changes
Resolved issues and error corrections
Fixed the wording printed on Philippine checks when the payment amount includes cents. The amount in words now follows the expected local format, which avoids invalid check text and improves payment accuracy.
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
This update corrects how credit note totals are prepared for Taiwan ECPay invoicing. It prevents payment-matched invoices from sending an incorrect amount, which could cause ECPay to reject the request.
Original PR description
When invoice is reconciled and credit note is issued, amount_residual_signed is not zero. By doing sale_amount += self.amount_residual_signed, TotalAmount is not match with the original sale amount and ECPay API returns error. task-5230384 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 color picker now refreshes properly when users choose grayscale, transparent grayscale, or theme colors. This makes it easier to fine-tune background and design colors because the on-screen controls now match the selected color reliably.
Original PR description
Before this commit, the colorpicker UI would not update when switching to some colors (grayscale, transparent grayscale, theme colors). It would therefore be difficult to make small changes to those colors. This commit make the colorpicker update correctly. Step to reproduce the bug (example with grayscale colors): - Add a snippet - Change the background color to a custom color (the colorpicker interface was updated to match the color) - Change the background color to a grayscale color (the colorpicker interface was not updated to match the color) task-3806989 Forward-Port-Of: odoo/odoo#179883
This change fixes a crash that could happen when users opened very large XLSX files and converted them into Odoo spreadsheets. It helps ensure large workbooks can be imported more reliably without interrupting the workflow.
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#98443
This fix stops old IoT event requests from staying open when users switch between device and form views. As a result, the interface no longer hits browser request limits, which prevents actions from timing out and restores normal use of the IoT screen.
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…
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, causing action calls to timeout. This behaviour was broken when the longpolling was changed to use the `fetch` method instead of jquery. This commit restores the behaviour by using an `AbortController` instance which is aborted when `stopPolling` is called. Before the fix (action times out due to many stuck event calls): <img width="545" height="249" alt="image" src="https://github.com/user-attachments/assets/f18b8a5d-c27c-47a3-ab58-428a78ef5383" /> After the fix (action succeeds): <img width="538" height="228" alt="image" src="https://github.com/user-attachments/assets/30f2863e-9df9-4a6e-b715-135ece4224ed" /> Forward-Port-Of: odoo/enterprise#98985
This change reclassifies several Romanian accounting accounts used for customer advances from assets to current liabilities. It ensures down payments on customer invoices are recorded in the proper place, improving accounting accuracy and financial reporting.
Original PR description
Before this PR: - Accounts 419000, 419100, and 419200 were set as Current Assets, even though they represent customer advances (liabilities). After this PR: - These accounts are reclassified as Current Liabilities, allowing them to be properly used as downpayment accounts on customer invoices. Task-5188142
Alert content added in the checkout’s extra information description fields is now inserted correctly inside the editable area. This fixes a bug where the text inside the alert could not be changed, improving the checkout editing experience for website managers.
Original PR description
Problem: When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified. Cause: In…
Problem:
When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified.
Cause:
In
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L784-L789 the logic determines the block using:
`this.closestElement(range.endContainer, 'p, div, ol, ul, cl, h1, h2, h3, h4, h5, h6');` Since the field description template is:
```html
<div class="s_website_form_field_description small form-text text-muted"
contenteditable="true">
text
</div>
```
and the selection occurs within the text (direct child of the editable `div`), the computed `block` becomes the editable area itself. As a result, the cloned alert is inserted *after* the editable area: `block.after($clonedBody[0]);`, making it non-editable.
Solution:
Use the editor’s built-in `insert` command instead of manually inserting clones. This ensures the alert is correctly inserted within the editable region.
Steps to reproduce:
1. Enable "Extra Step During Checkout" in Settings.
2. Open Website → add a product to the cart → proceed to checkout.
3. In the "Extra info" step, open the editor.
4. Select the "Give us your feedback" field.
5. Enable "Field" → "Description".
6. Run the "/alert" command in the description. → The alert content cannot be edited.
opw-5184309
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#2329102 changes
Resolved issues and error corrections
This update fixes two issues in DHL shipment requests: a misspelled customer reference field and the shipping date/time format. As a result, DHL labels and return labels should now be created successfully without validation errors.
Original PR description
Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes…
Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes validation errors when communicating with the DHL API. In addition, the datetime format used for the planned shipping date and time does not conform to the expected format specified by DHL. Steps to reproduce spelling issue: 1. Create a Sales Order with a customer reference and a deliverable product. 2. Validate the SO. 3. Go to the delivery, select DHL as carrier, and confirm. → Error: Validation error #/content/exportDeclaration: extraneous key [recepientReference] is not permitted. Steps to reproduce datetime issue: 1. Create a delivery using the DHL carrier. 2. Confirm the delivery. 3. Return the delivery. 4. Click "Print Return Label". → Error: Bad request #/plannedShippingDateAndTime is not well formatted (expected format: '2010-02-11T17:10:09 GMT+01:00'). Official DHL documentation: https://developer.dhl.com/sites/default/files/2025-11/dpdhl-express-api-3.1.1_swagger.yaml opw-5024363
This update fixes the Italian translations and labels for document types used in electronic invoicing. It helps users see clearer, more accurate names when creating and managing these documents, reducing confusion and the risk of selecting the wrong type.
Original PR description
Simplified and fixed labels and labels translations. Ref: https://help.fattureincloud.it/help/articolo/544-crea-autofattura-elettronica Ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiGeneraliDocumento/TipoDocumento