Daily updates from Odoo
Tuesday, September 2, 2025
54 changes
16 changes
Resolved issues and error corrections
In Point of Sale, opening All Orders from the customer list no longer clears the currently selected customer. This avoids extra re-selection steps and keeps checkout workflows smoother for sales staff.
Original PR description
Before this commit, opening the All Orders from the partner list would reset the selected partner. As a result, the user had to reselect the partner after returning, which disrupted the workflow. opw-4972314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224828 Forward-Port-Of: odoo/odoo#222507
Website image grid blocks such as Masonry now keep images inside their rounded or bordered containers. This prevents visual overflow and makes edited website layouts look as intended for visitors.
Original PR description
When a border radius and/or width is applied to an image grid item (e.g. in "Masonry"), the image overflows its parent box. This happens because the style was only applied to the column, not the image itself. This commit adds necessary style to the image to take into account the border radius and width of the parent box. Steps to reproduce: 1. In Website Builder, add the "Masonry" snippet. 2. Select a block with an image (i.e. the block with the largest image) and apply a border radius. 3. Notice that the image does not respect the border radius. Related to task-3358501
This fixes a timezone issue when sending order dates for POS online payments. Orders are now formatted in UTC as expected by the backend, helping prevent incorrect order timestamps caused by local timezone conversion.
Original PR description
In 2a5f1ab, we formatted the `order_date` with `toFormat(...)`, however, that transforms the date into local, while the backend expects it to be in UTC. In this commit, we set the date tz back to UTC before formatting it. opw-4942697 Forward-Port-Of: odoo/odoo#225041 Forward-Port-Of: odoo/odoo#224085
This fixes a Point of Sale gift card issue where an order could show a second gift card line with a zero amount. The change helps keep receipts and order totals clearer by treating tiny rounding-like values as zero.
Original PR description
When selling some product and applying a giftcard, there could be 2 giftcard lines applied on the order one with a correct amount and the other one with 0 as amount. Steps to reproduce: ------------------- * Create a gift card with 50€ * Open PoS and add a Desk Pad and a Black Drawer > Observation: There are 2 giftcard lines applied on the order Why the fix: ------------ Sometimes the discountable amount could get weird values that are really close to 0 but that was not interpreted as False. To fix this we use `floatIsZero()` instead. Note: ---------- I will introduce a hoot test in 18.3 to cover this weird use case. opw-4866358 Forward-Port-Of: odoo/odoo#224870 Forward-Port-Of: odoo/odoo#223948
Inventory settings can now be saved even if the Replenish on Order route was previously deleted. This prevents an unexpected error and avoids blocking users from updating configuration settings.
Original PR description
Currently, an error occurs when saving settings if the `Replenish on Order (MTO)` route has been deleted. **Steps to reproduce:** - Install the `stock` and `purchase` modules. - Go to inventory…
Currently, an error occurs when saving settings if the `Replenish on Order (MTO)` route has been deleted.
**Steps to reproduce:**
- Install the `stock` and `purchase` modules.
- Go to inventory settings > enable `Multi-Step Routes` and `Replenish on Order (MTO)`.
- Go to inventory > Configuration > Routes and delete the `Replenish on Order (MTO)` route.
- Open the Settings app and click `Save`.
**Error:**
`AttributeError: 'NoneType' object has no attribute 'sudo'`
**Root Cause:**
After PR [1], at [2], `self.env.ref('stock.route_warehouse0_mto', raise_if_not_found=False)` can return `None` if the MTO route is missing. The code then directly calls `.sudo()` on this `None` value, causing an error.
**Fix:**
This commit moves the `.sudo()` call inside the `if route:` block, ensuring it is only executed when the route exists. This prevents errors when the MTO route is deleted and allows users to save settings without an access error.
[1]:
https://github.com/odoo/odoo/pull/221757
[2]:
https://github.com/odoo/odoo/blob/dfb14be8b83e3c48c1b186b0d7d7a66753381c9e/addons/stock/models/res_config_settings.py#L64
sentry-6839993384Fixes an issue in the website editor where removing a popup or undoing its creation could leave the page unable to scroll. This helps editors continue working normally on longer pages after popup changes.
Original PR description
Following the [html_builder refactoring], commits [1] and [2] removed the functionality that was responsible for toggling the popup's visiblity when we remove it or undo its creation. Steps to see the issue: - Have enough content on the page to be able to scroll it - Start editing and drop the popup - Undo => We can't scroll. The same happens if we just remove the popup. Related to task-4367641 [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddb [1]: https://github.com/odoo/odoo/commit/a3722219038fff [2]: https://github.com/odoo/odoo/commit/06101974532157c521155a7fbb2179aa85b060db
The Send & Print wizard now consistently hides the Download option regardless of the user's language settings. This prevents confusion for non-English users and keeps the accounting workflow aligned with the intended behavior.
Original PR description
Since 7ad7a1d976391e81eaa03be7076cc61f4a6cfcbe we don't show Download option in the Send & Print wizard. However, we were checking the tuple `(value, label)` which works only if language is set to English. With this commit, we only check the technical value opw-4965650 Forward-Port-Of: odoo/odoo#221763
This update adjusts automated checks for the eLearning course publishing flow after changes in the website builder. It helps ensure future updates do not accidentally break course publishing for eLearning managers.
Original PR description
This commit adapt the broken test test_course_publisher_elearning_manager after refactoring of the website builder.
This fixes an issue where users editing menus in Studio could not create or edit a client action because the default form view failed to load. The change removes an outdated customization so Odoo can generate the form normally, improving reliability when configuring menus.
Original PR description
Steps to reproduce ================== - Install studio,contacts - Go to contacts - Open studio - Click on "Edit menu" - Click on the pencil next to a menu item - Set the action type to ir.actions.client - Type a random string next to it, for example "test123" - Click on "Create and Edit" => No default view could be found Cause of the issue ================== The following commit removes the binary fields from the default view as it caused a traceback https://github.com/odoo/odoo/commit/70d51d2103118287b1ebafdae396c7b86e6b9257 A more general fix has been made in https://github.com/odoo/odoo/commit/e1edcb06ef2619835d07717f00cbf6f04f026366 Since the binary fields are already removed in the super call, the override doesn't find them. Solution ======== There is no need for the override anymore opw-5023188 Forward-Port-Of: odoo/odoo#224752 Forward-Port-Of: odoo/odoo#224634
This fix prevents Spain VeriFactu electronic reporting from failing when a company has no tax ID set. Instead of showing an unexpected error, the system now handles the missing value more safely during batch sending checks.
Original PR description
Replaced `['NIF']` with `.get('NIF')` to avoid a `KeyError` when the company does not have a NIF.
When the VAT value is not set on the company and the `_send_as_batch_check` method is executed, the system raises an error from [1].
This PR updates the code to use `.get('NIF')` instead of direct access, making it more robust.
[1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/l10n_es_edi_verifactu/models/verifactu_document.py#L1165
**sentry-6829500308**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224982The email composer now filters templates so users only see templates assigned to them or templates available to everyone. This prevents templates intended for another user from appearing in sales email workflows, reducing confusion and accidental use of the wrong message.
Original PR description
**Steps to reproduce:** 1. Install Sales. 2. Create an email template for the 'sale.order' model and assign it to the admin user under the settings page in the 'User' field. 3. Log in as the demo…
**Steps to reproduce:** 1. Install Sales. 2. Create an email template for the 'sale.order' model and assign it to the admin user under the settings page in the 'User' field. 3. Log in as the demo user. 4. Create a quotation and click the 'Send by Email' button. 5. In the wizard, click the three dots between the attachment and AI logo in the footer. 6. Observe the templates list. **Issue:** - The template created for the admin user appears for the demo user as well. **Cause:** https://github.com/odoo/odoo/blob/07626050bd0104fecd8799b56d30245d00da3f27/addons/mail/static/src/core/web/mail_composer_template_selector.js#L31-L44 - The domain used to fetch templates was incorrectly filtering for templates assigned to any user (instead of filtering for templates assigned to the current user or not assigned at all). **Solution:** - Corrected the domain to include only templates assigned to the current user and not assigned to anyone. opw-4901492 Forward-Port-Of: odoo/odoo#222073 Forward-Port-Of: odoo/odoo#217641
The leave statistics view has been adjusted so information no longer overlaps in the interface. This makes absence and time-off figures easier for HR teams and employees to read and use.
Original PR description
This commit addresses an overlapping styling issue in the leave stats task-4945729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221099
The barcode app now opens the scrap flow correctly for completed manufacturing orders even when there are no by-products. This prevents users from hitting an error screen and keeps warehouse production cleanup tasks moving smoothly.
Original PR description
Issue ----- Trying to scrap a production through the barcode app gives the user a traceback. Steps to reproduce ----- - Have a done MO - Go to barcode and try to scrap it --> Traceback Cause ----- When preparing the context for the scrap window, we try to map the MO's byProducts. When there is no byProduct, we end up trying to apply a mapping on "nothing". ----- Ticket: opw-4792599 Forward-Port-Of: odoo/enterprise#92925 Forward-Port-Of: odoo/enterprise#90623
The employee form warning shown when wages fall below the legal minimum can no longer be edited. This avoids confusion and helps prevent accidental changes while keeping the warning informational.
Original PR description
When an employee’s wage falls below the minimum, the warning displayed on the employee form appeared with editable fields. This was misleading and could allow accidental changes. task-5051879
The Documents app now recognizes older redirect records when someone opens a shared document content link. This preserves access to existing links and avoids broken document downloads or previews after link changes.
Original PR description
We do not currently check for `documents.redirect` records when accessing the `/documents/content/<access_token>` endpoint. This commit fixes this by redirecting if a `document.redirect` with the appropriate `access_token` was created for backwards compatibility. opw-4517698 Forward-Port-Of: odoo/enterprise#92342 Forward-Port-Of: odoo/enterprise#92313
The duplicate transaction search now works even when users leave the Starting Date blank. Instead of showing an error, the system uses today’s date so accounting teams can continue their bank review without interruption.
Original PR description
Currently, an error occurs when attempting to find duplicate transactions in the bank. Steps to Reproduce: - Install the `Accountant` module. - In the `Accounting` Dashboard, click on `Bank`. - In…
Currently, an error occurs when attempting to find duplicate transactions in the bank.
Steps to Reproduce:
- Install the `Accountant` module.
- In the `Accounting` Dashboard, click on `Bank`.
- In Actions, click `Find Duplicate Transactions`.
- Clear the `Starting Date` and click save.
Traceback:
```py
psycopg2.errors.UndefinedFunction: operator does not exist: date >= boolean
LINE 6: AND move.date >= false
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
This error occurs when the system attempts to detect duplicate transactions without a `Starting Date`. During the check, it evaluates the condition `move.date >= date_from`. Since `date_from` is False, the comparison triggers an error.
This commit ensures that if the `Starting Date` is empty when finding duplicate transactions, it uses today’s date as the `Starting Date`.
Reference commit: https://github.com/odoo/enterprise/pull/87000/commits/806ab2d56952e9d0f597cf1ab36ea2f180a84323
Forward-Port-Of: odoo/enterprise#9249716 changes
Resolved issues and error corrections
This fixes an issue where online payment order dates could be sent using the local timezone instead of UTC. Keeping these timestamps in the expected timezone helps prevent incorrect order timing in point-of-sale payment records.
Original PR description
In 2a5f1ab, we formatted the `order_date` with `toFormat(...)`, however, that transforms the date into local, while the backend expects it to be in UTC. In this commit, we set the date tz back to UTC before formatting it. opw-4942697 Forward-Port-Of: odoo/odoo#225041 Forward-Port-Of: odoo/odoo#224085
This fix restores the ability to swipe left on mobile to unpin conversations from the messaging menu. It corrects how unread message information is read, preventing the swipe action from failing and improving mobile usability.
Original PR description
Before this commit, swiping left to unpin threads in the messaging menu was not working. This issue was introduced by [1] (which is a backport of [2]), and it stems from trying to acccess the message_unread_counter on the thread instead of the self channel member. This commit fixes the issue by accessing the property correctly from the self channel member. [1] https://github.com/odoo/odoo/pull/212793 [2] https://github.com/odoo/odoo/pull/212793 task-5058496
Users can now find Indonesian Coretax product codes more easily when editing product templates. Searches work by code, description, or the displayed label, reducing confusion and helping users select the correct tax-related product code faster.
Original PR description
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or…
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or searchview is difficult and not normal. so this uses `_rec_name = "code"` for fixing in searchview, and overrides `_name_search()` to be able to search using field `code` or `description` or like `name_get()` string Current behavior before PR: <img width="821" height="353" alt="Before fixing coretax product code search 1" src="https://github.com/user-attachments/assets/12ca3248-0bea-4ef3-bb04-116d63520517" /> <img width="832" height="432" alt="Before fixing coretax product code search 2" src="https://github.com/user-attachments/assets/ced291b7-c4c6-42e7-a453-7a1f18945637" /> <img width="988" height="568" alt="Before fixing coretax product code search 3" src="https://github.com/user-attachments/assets/bbac4ae1-a31d-49bd-b520-a68a1a945e78" /> Desired behavior after PR is merged: <img width="438" height="314" alt="After fixing coretax product code search 1" src="https://github.com/user-attachments/assets/4469bb5b-0830-49af-af1c-f05b81dcb10c" /> <img width="467" height="331" alt="After fixing coretax product code search 2" src="https://github.com/user-attachments/assets/5528db34-e279-4d2d-98f0-644f7a618ead" /> <img width="991" height="619" alt="After fixing coretax product code search 3" src="https://github.com/user-attachments/assets/fec53a0c-ab29-46c5-b366-46653b51d7e4" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222588 Forward-Port-Of: odoo/odoo#221858
The mailing form now correctly marks the sender email as required before saving. This prevents confusing server errors and gives users a simple, familiar prompt to complete the missing field.
Original PR description
**Steps to reproduce:** - Install `mail_mailing`. - Create a new record and leave the `email_from` field empty. **Observed behavior:** - A validation error is raised due to a bad query. **Expected…
**Steps to reproduce:** - Install `mail_mailing`. - Create a new record and leave the `email_from` field empty. **Observed behavior:** - A validation error is raised due to a bad query. **Expected behavior:** - Since the field is required, the UI should display a simple “Invalid fields” pop-up instead of a server-side validation error. **Cause:** The commit odoo@92c5b0699dffab98f55ed1a54a0236dbc4b5626a removed the `required` attribute from the `email_from` field and replaced it with a constraint. As a result, UI-level validation was lost and only the backend validation error is shown. **Fix:** Re-add the `required` attribute for the `email_from` field in the view so that the standard UI validation is triggered. **Before Fix:** <img width="1366" height="578" alt="email_from_empty" src="https://github.com/user-attachments/assets/23680aad-e9c8-4554-b990-de0784cb4442" /> **After Fix:** <img width="1366" height="620" alt="after_fix_email_from" src="https://github.com/user-attachments/assets/ef34c680-8b17-4773-995d-d953a874e6a0" /> I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Current Stock button on a stock location now opens a list filtered to that specific location instead of showing all products across all locations. This helps warehouse users see the relevant inventory faster and avoids confusion from unrelated stock records.
Original PR description
From this [commit](https://github.com/odoo/odoo/commit/81acb532a45cf7ab2837634e4d347b216c95f07a), clicking the "Current Stock" button on a location form opened the stock quant list without filtering by the selected location, showing all products. After this commit, the context `search_default_location_id` is added so that the stock quant list is properly filtered by the active location. **Before fix** <img width="1919" height="951" alt="2025-09-01_12-15" src="https://github.com/user-attachments/assets/93a6034b-0d07-4668-b67d-a84df2285a48" /> **After fix** <img width="1913" height="862" alt="2025-09-01_12-20" src="https://github.com/user-attachments/assets/03eb5b48-0799-4a73-a826-b3c9971b4a85" /> opw-5033643 upg-3117055 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 point of sale tax control button now appears only when the relevant tax or takeout/delivery settings are enabled, including in restaurant mode. The tax selection popup also has a clearer title, reducing cashier confusion and preventing unnecessary options from showing.
Original PR description
Before this commit: =================== - When only point_of_sale is installed, the tax control button is visible only if `Flexible Tax` is enabled. But with pos_restaurant installed, the button is always visible, even if Flexible Tax is disabled. - Also, the tax selection dialog had an incorrect title: `Please register the voucher number`. After this commit: ================== - In point of sale, the tax control button will be visible if `Flexible Tax` is enabled, and in restaurant mode, the button will be visible if the `Flexible Tax` or `Takeout/Delivery` is enabled. - The tax selection dialog title has been updated to: `Choose the tax you want to apply`. Task: 4937977 Forward-Port-Of: odoo/odoo#224847 Forward-Port-Of: odoo/odoo#218815
Updates the Spanish descriptions for several Argentine IIBB sales perception taxes so they show the full jurisdiction names. This helps accounting users identify the correct taxes more clearly and consistently in Odoo.
Original PR description
**Description of the issue/feature this PR addresses**: It is needed to ensure that the descriptions for the IIBB perceptions are consistent and correctly reflect the complete name of the…
**Description of the issue/feature this PR addresses**: It is needed to ensure that the descriptions for the IIBB perceptions are consistent and correctly reflect the complete name of the jurisdictions they apply to. **Steps to reproduce**: 1) Go to runbot odoo 18 instance, install l10n_ar module, take position on Argentinean company and activate "Spanish (Latin America)" language. 2) Go to "Accounting / Configuration / Accounting / Taxes", filter by "Sales" Tax Type (type_tax_use) and see that Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe don`t have the complete description. It is needed to show the complete description. <img width="1825" height="307" alt="image" src="https://github.com/user-attachments/assets/f664e5ec-a4b5-4a8f-bbab-9ba3d824bd2b" /> **Current behavior before PR**: Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes don`t have the complete description. **Desired behavior after PR is merged**: Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes have the complete description. <img width="1828" height="425" alt="image" src="https://github.com/user-attachments/assets/dc8ee6dd-23c3-40c1-a973-943971e3cb78" /> **Task Adhoc side**: 53028 **Task latam side**: 1356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221742
The Spanish Point of Sale test now uses the current year when checking order names instead of relying on a fixed 2025 value. This prevents date-related test failures and helps keep release validation stable across build environments.
Original PR description
The settle account due tour in l10n_es_pos was failing because the order name was hardcoded to "TSJ/2025/00001". This value includes a date-dependent year and sequence number, which vary based on `context_today`. this will ensure that the tour dynamically generates the order name based on the current year, making it correct for faketime builds build_error-230724 <img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/2b7d0e04-9cd9-45d9-b5f0-32f39f87dd90" />
This fixes an issue where users editing menus in Studio could not create or edit a client action because the system failed to generate a default form. The redundant custom handling was removed so the standard view generation now works as expected.
Original PR description
Steps to reproduce ================== - Install studio,contacts - Go to contacts - Open studio - Click on "Edit menu" - Click on the pencil next to a menu item - Set the action type to ir.actions.client - Type a random string next to it, for example "test123" - Click on "Create and Edit" => No default view could be found Cause of the issue ================== The following commit removes the binary fields from the default view as it caused a traceback https://github.com/odoo/odoo/commit/70d51d2103118287b1ebafdae396c7b86e6b9257 A more general fix has been made in https://github.com/odoo/odoo/commit/e1edcb06ef2619835d07717f00cbf6f04f026366 Since the binary fields are already removed in the super call, the override doesn't find them. Solution ======== There is no need for the override anymore opw-5023188 Forward-Port-Of: odoo/odoo#224752 Forward-Port-Of: odoo/odoo#224634
This update corrects the Spanish Canary Islands tax configuration to use the current field name in Odoo 18. It helps ensure tax data loads properly and avoids setup errors for companies using this localization.
Original PR description
Description of the issue/feature this PR addresses: In version 18 of Canary Islands taxes, the “price_include” field no longer exists. It is now called “price_include_override.” 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#223996
The Send & Print wizard now reliably hides the Download option for users in all languages. This prevents a previously hidden choice from reappearing when Odoo is used outside English, keeping the workflow consistent.
Original PR description
Since 7ad7a1d976391e81eaa03be7076cc61f4a6cfcbe we don't show Download option in the Send & Print wizard. However, we were checking the tuple `(value, label)` which works only if language is set to English. With this commit, we only check the technical value opw-4965650 Forward-Port-Of: odoo/odoo#221763
This fix prevents an error when a Spanish company has no tax ID set and the VeriFactu batch check runs. The system now handles the missing value safely, improving reliability for affected Spanish electronic invoicing workflows.
Original PR description
Replaced `['NIF']` with `.get('NIF')` to avoid a `KeyError` when the company does not have a NIF.
When the VAT value is not set on the company and the `_send_as_batch_check` method is executed, the system raises an error from [1].
This PR updates the code to use `.get('NIF')` instead of direct access, making it more robust.
[1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/l10n_es_edi_verifactu/models/verifactu_document.py#L1165
**sentry-6829500308**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224982The email composer now correctly limits template suggestions to templates available to the current user or shared with everyone. This prevents employees from seeing templates assigned to another user, reducing confusion when sending sales emails.
Original PR description
**Steps to reproduce:** 1. Install Sales. 2. Create an email template for the 'sale.order' model and assign it to the admin user under the settings page in the 'User' field. 3. Log in as the demo…
**Steps to reproduce:** 1. Install Sales. 2. Create an email template for the 'sale.order' model and assign it to the admin user under the settings page in the 'User' field. 3. Log in as the demo user. 4. Create a quotation and click the 'Send by Email' button. 5. In the wizard, click the three dots between the attachment and AI logo in the footer. 6. Observe the templates list. **Issue:** - The template created for the admin user appears for the demo user as well. **Cause:** https://github.com/odoo/odoo/blob/07626050bd0104fecd8799b56d30245d00da3f27/addons/mail/static/src/core/web/mail_composer_template_selector.js#L31-L44 - The domain used to fetch templates was incorrectly filtering for templates assigned to any user (instead of filtering for templates assigned to the current user or not assigned at all). **Solution:** - Corrected the domain to include only templates assigned to the current user and not assigned to anyone. opw-4901492 Forward-Port-Of: odoo/odoo#222073 Forward-Port-Of: odoo/odoo#217641
This fix prevents certain errors from the IoT-connected Belgian blackbox from causing a system traceback after POS data is pushed. It improves reliability for Belgian point-of-sale operations by handling these error responses more safely while a broader error-handling approach is planned.
Original PR description
Before this commit, it could happen that an error returned by the iot when contacting the blackbox was not correctly handled and led to a traceback. This commit solves the issue temporaly before finding a solution to harmonize the error handling in the blackbox. Forward-Port-Of: odoo/enterprise#93468
Users can now scrap completed manufacturing orders from the Barcode app without encountering an error. The fix safely handles cases where a production order has no by-products, preventing an interruption in warehouse operations.
Original PR description
Issue ----- Trying to scrap a production through the barcode app gives the user a traceback. Steps to reproduce ----- - Have a done MO - Go to barcode and try to scrap it --> Traceback Cause ----- When preparing the context for the scrap window, we try to map the MO's byProducts. When there is no byProduct, we end up trying to apply a mapping on "nothing". ----- Ticket: opw-4792599 Forward-Port-Of: odoo/enterprise#92925 Forward-Port-Of: odoo/enterprise#90623
Finding duplicate bank transactions no longer fails when the Starting Date field is left empty. The system now uses today's date automatically, allowing accounting users to complete the action without interruption.
Original PR description
Currently, an error occurs when attempting to find duplicate transactions in the bank. Steps to Reproduce: - Install the `Accountant` module. - In the `Accounting` Dashboard, click on `Bank`. - In…
Currently, an error occurs when attempting to find duplicate transactions in the bank.
Steps to Reproduce:
- Install the `Accountant` module.
- In the `Accounting` Dashboard, click on `Bank`.
- In Actions, click `Find Duplicate Transactions`.
- Clear the `Starting Date` and click save.
Traceback:
```py
psycopg2.errors.UndefinedFunction: operator does not exist: date >= boolean
LINE 6: AND move.date >= false
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
This error occurs when the system attempts to detect duplicate transactions without a `Starting Date`. During the check, it evaluates the condition `move.date >= date_from`. Since `date_from` is False, the comparison triggers an error.
This commit ensures that if the `Starting Date` is empty when finding duplicate transactions, it uses today’s date as the `Starting Date`.
Reference commit: https://github.com/odoo/enterprise/pull/87000/commits/806ab2d56952e9d0f597cf1ab36ea2f180a84323
Forward-Port-Of: odoo/enterprise#9249713 changes
Resolved issues and error corrections
This update fixes automated website shop tests so they match a recent checkout page structure change. It helps keep rental purchase and wishlist checkout flows reliably tested, reducing the risk of unnoticed issues reaching customers.
Original PR description
This aligns the test steps with updated template structure, where the current checkout step is rendered using a added div name="active_step" instead of the older CSS class-based method. See also: - Enterprise PR: https://github.com/odoo/odoo/pull/210879 task:4766612
This fix restores an optimization that avoids starting the IoT communication session until it is actually needed. It helps keep IoT-related point of sale and self-ordering flows efficient and prevents unnecessary background activity introduced by a previous refactor.
Original PR description
* : pos_iot, pos_self_order_iot The refactor introducing the `iot_http` service dropped by mistake the previous lazy_session optimisation [1], this commit reintroduce it. [1]: https://github.com/odoo/enterprise/commit/313bde6feb756c050a20a3459e1e8282d11ffa66 Forward-Port-Of: odoo/enterprise#93600
The Chilean electronic invoicing demo data now includes the required certificate serial number. This prevents setup errors when users test sending demo invoices to the Chilean tax authority, while leaving real production certificates unchanged.
Original PR description
**Issue** When installing l10n_cl_ed, the `subject_serial_number` field is left empty. This causes an error when attempting to send an invoice to the SII. **Steps to Reproduce** 1. Install Accounting and l10n_cl_edi 2. Create and confirm an invoice 3. Click "Send Now to SII" 4. Error: Invalid Operation **Root Cause** The `subject_serial_number` is not set during installation, and this field is required for electronic document generation. **Fix** Restore the behavior from version 17.0 by setting a default `subject_serial_number` if it's missing and the certificate is available. This ensures the demo data is functional and allows users to test the SII integration out-of-the-box. Opw-4961801 Forward-Port-Of: odoo/enterprise#90636
Finding duplicate bank transactions no longer fails when the Starting Date field is left empty. The system now uses today's date by default, helping accounting users complete the duplicate check without interruption.
Original PR description
Currently, an error occurs when attempting to find duplicate transactions in the bank. Steps to Reproduce: - Install the `Accountant` module. - In the `Accounting` Dashboard, click on `Bank`. - In…
Currently, an error occurs when attempting to find duplicate transactions in the bank.
Steps to Reproduce:
- Install the `Accountant` module.
- In the `Accounting` Dashboard, click on `Bank`.
- In Actions, click `Find Duplicate Transactions`.
- Clear the `Starting Date` and click save.
Traceback:
```py
psycopg2.errors.UndefinedFunction: operator does not exist: date >= boolean
LINE 6: AND move.date >= false
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
This error occurs when the system attempts to detect duplicate transactions without a `Starting Date`. During the check, it evaluates the condition `move.date >= date_from`. Since `date_from` is False, the comparison triggers an error.
This commit ensures that if the `Starting Date` is empty when finding duplicate transactions, it uses today’s date as the `Starting Date`.
Reference commit: https://github.com/odoo/enterprise/pull/87000/commits/806ab2d56952e9d0f597cf1ab36ea2f180a84323
Forward-Port-Of: odoo/enterprise#92497A date used in Belgian payroll accounting tests has been fixed so the tests remain reliable when the calendar year changes. This prevents avoidable failures in 2026 and helps keep payroll-related validation stable over time.
Original PR description
Some tests will fail in 2026. This adds a freeze time to prevent this failing. Task: 5034173 Forward-Port-Of: odoo/enterprise#93575 Forward-Port-Of: odoo/enterprise#92983
When duplicating accounting moves related to returns, the copied move is no longer incorrectly tied to the original return. This prevents confusion and reporting mistakes by ensuring duplicated records are treated as separate entries.
Original PR description
Duplicating some return's move also kept the duplicate linked to the return. This is wrong. task-5046319 Forward-Port-Of: odoo/enterprise#93390 Forward-Port-Of: odoo/enterprise#93323
The AI message action buttons now appear in a more logical order, with the copy option placed after sending as a message and logging as a note. This reduces confusion and makes the interface easier to use.
Original PR description
The copy button appears in between the 'Send as Message' and 'Log as Note' buttons. It should appear last (after both buttons). This commit along with the corresponding community commit update the sequence of these buttons to make the copy button appear last. See https://github.com/odoo/odoo/pull/224774
The Documents app now checks for existing redirect records when someone opens a shared document content link. This preserves access for older or migrated links, reducing broken document access for users and customers.
Original PR description
We do not currently check for `documents.redirect` records when accessing the `/documents/content/<access_token>` endpoint. This commit fixes this by redirecting if a `document.redirect` with the appropriate `access_token` was created for backwards compatibility. opw-4517698 Forward-Port-Of: odoo/enterprise#92342 Forward-Port-Of: odoo/enterprise#92313
Payroll users can now change salary rule colors reliably from both Salary Rules and Salary Structures. The fix ensures the chosen styling is applied directly in the salary rule preview and pop-up, making rules easier to identify and review.
Original PR description
Steps to Produce: - open payroll app - Go to Salary Rules or go to Salary Structures and open any salary rule. - try to change color of any rule. issue: - The color does not change in the Salary Rules. - Additionally, styles do not apply in the salary rule pop-up accessed through Salary Structures. Fix: - Instead of changing the color with formrenderer, a custom widget was created to apply styles directly to the field. opw-4716810 task-4774448 Forward-Port-Of: odoo/enterprise#93520 Forward-Port-Of: odoo/enterprise#83514
Spreadsheet pivot configuration now hides field relationships that cannot be stored and therefore cannot be reliably retrieved. This prevents users from selecting options that would create cell errors, and adds test coverage for many-to-many relationships.
Original PR description
Before this commit, it was possible to follow a non-store field relation in the pivot chain feature. It leads to an error in the cell as it's not possible to retrieve the value of a non-stored field. In order to ease the work of the user, we do not display non-store field relation. This commit also adds a missing test for the m2m relation. Task: 5059203
Creating a new salary offer from an employee's shortcut now automatically selects the correct employee again. This prevents manual correction and helps HR teams avoid offers being created without the intended employee attached.
Original PR description
Since this PR: https://github.com/odoo/enterprise/pull/91716, the context when creating a new offer for an employee via his smartbuttons was lacking the default employee_id. This commit fixes the issue by specifying the correct default employee_id.
The barcode app now handles manufacturing orders that have no by-products when opening the scrap window. This prevents a traceback and lets users scrap completed productions reliably.
Original PR description
Issue ----- Trying to scrap a production through the barcode app gives the user a traceback. Steps to reproduce ----- - Have a done MO - Go to barcode and try to scrap it --> Traceback Cause ----- When preparing the context for the scrap window, we try to map the MO's byProducts. When there is no byProduct, we end up trying to apply a mapping on "nothing". ----- Ticket: opw-4792599 Forward-Port-Of: odoo/enterprise#92925 Forward-Port-Of: odoo/enterprise#90623
A timezone is now set in a timesheet test calendar so automated checks use the expected dates and times. This helps keep test results reliable when demo data is included, reducing false failures during development and releases.
Original PR description
The timezone of a working calendar is not properly set in a test class, which causes datetimes to not match the expected values when running tests with demo data. This PR sets a timezone on the working calendar to solve the issue.
9 changes
Resolved issues and error corrections
The organization chart now picks the right employee and manager information when shown from user, employee, or public employee forms. This prevents incorrect chart details from appearing and improves reliability for HR users viewing employee relationships.
Original PR description
This update ensures that the correct employee and parent IDs are fetched depending on whether the widget is displayed in a `res.users`, `hr.employee` or `hr.employee.public` form. The `onWillStart` was removed since `useRecordObserver` is triggered in `onWillStart`, and both used to have the same logic. task-5039701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224456
This fixes an issue where the Settings page could fail when a section header did not have a label configured. Headers can now be displayed without a label, preventing avoidable errors for users and administrators.
Original PR description
Before this commit, an error would occur if a header setting did not contain an attribute string or field. This was because the code tried to infer the label. However, the label should be optional. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225080
Fixed a mobile issue where opening the Employee form and tapping the gear icon could cause the page to crash. This makes the employee screen more reliable for users working from phones or tablets.
Original PR description
Opening the Employee form on mobile and tapping the gear icon could crash because `PresenceActionItems` was undefined. Initialize it and guard the template. task-5055564
This fix makes Indonesian e-Faktur Coretax product codes easier to find when editing product templates. Users can now search by product code or description, reducing confusion and speeding up tax-related product setup.
Original PR description
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or…
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or searchview is difficult and not normal. so this uses `_rec_name = "code"` for fixing in searchview, and overrides `_name_search()` to be able to search using field `code` or `description` or like `name_get()` string Current behavior before PR: <img width="821" height="353" alt="Before fixing coretax product code search 1" src="https://github.com/user-attachments/assets/12ca3248-0bea-4ef3-bb04-116d63520517" /> <img width="832" height="432" alt="Before fixing coretax product code search 2" src="https://github.com/user-attachments/assets/ced291b7-c4c6-42e7-a453-7a1f18945637" /> <img width="988" height="568" alt="Before fixing coretax product code search 3" src="https://github.com/user-attachments/assets/bbac4ae1-a31d-49bd-b520-a68a1a945e78" /> Desired behavior after PR is merged: <img width="438" height="314" alt="After fixing coretax product code search 1" src="https://github.com/user-attachments/assets/4469bb5b-0830-49af-af1c-f05b81dcb10c" /> <img width="467" height="331" alt="After fixing coretax product code search 2" src="https://github.com/user-attachments/assets/5528db34-e279-4d2d-98f0-644f7a618ead" /> <img width="991" height="619" alt="After fixing coretax product code search 3" src="https://github.com/user-attachments/assets/fec53a0c-ab29-46c5-b366-46653b51d7e4" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222588 Forward-Port-Of: odoo/odoo#221858
Refreshing the Thank You page of a live survey session no longer causes an error if a survey question was deleted in another tab. This keeps completed live sessions stable for participants and avoids a disruptive crash in the survey flow.
Original PR description
Currently, an error occurs when refreshing a live session's `Thank You` page after deleting a survey question. **Steps to reproduce:** - Install the `survey` module. - Create a `new survey`, `add a question` and click on `Create Live Session`. - Complete the survey and leave it on the `Thank You` page. - Switch back to the `first tab`, delete the question and `save` the survey. - Return to the `Thank You` tab and `refresh` the page. **Error:** `IndexError: list index out of range` **Root Cause:** At [1], the controller assumes the question exists and tries to access `index [0]`, but when the question has been deleted, the recordset is empty, causing an `error`. [1] https://github.com/odoo/odoo/blob/ffd9c0f96bda1bad1ad2059d9be2fae54b60eace/addons/survey/controllers/survey_session_manage.py#L236 This commit prevents a crash when refreshing a live session if the question was deleted. sentry-6736648824 Forward-Port-Of: odoo/odoo#218312
Saving a view with an unsupported XML tag now shows a proper validation message instead of an unexpected system error. This helps administrators understand the issue and correct the view setup without disruption.
Original PR description
When a user tries to save a view with an invalid tag, an error occurs. **Steps to produce:-** 1. Go to Settings > Technical > User Interface > Views. 2. Click on New. 3. Add the view name. In architecture -> add `<template></template>`. 4. Try to save the changes. **Error:-** `ValueError:Wrong value for ir.ui.view.type: 'template'`. **Root cause:-** - The view type in `ir.ui.view` is automatically inferred from the `root tag` of the XML defined in the `arch` field. - In this case, `<template>` becomes the inferred view type, which is not part of the valid selections for the type field in the model `ir.ui.view`. **Solution:-** - Before calling `super().create(vals_list)`, add a validation check to ensure `values['type']` is in the allowed types. If not, raise a ValidationError. sentry-6561028171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now retry deleting items in related lists after cancelling a confirmation prompt. The delete button is briefly disabled to prevent accidental double-clicks, then automatically becomes available again.
Original PR description
PR [1] aimed at fixing a double-click issue with the delete button in x2many lists. In standard views, it works fine. However, there are customizations (e.g. project sub tasks, product attributes...) that add a confirmation step before actually removing the row. If the user cancelled the deletion, clicking on the delete icon of that row afterwards had no effect at all. This commit fixes the issue by re-enabling the button after 500ms, thus only preventing double clicks. [1] https://github.com/odoo/odoo/pull/173481 opw~5019621 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
Saving the document layout no longer tries to update a company bank account when the displayed account number has not changed. This prevents unnecessary errors for trusted bank accounts while keeping the same visible settings for users.
Original PR description
Description of the issue/feature this PR addresses: The document layout wizard (base.document.layout) attempts to write the partner’s bank account number even if it has not been changed. If the first bank account is marked as trusted, Odoo blocks the write and raises an error. This PR prevents that error by only writing the account number when it has actually changed. Current behavior before PR: - The wizard shows the account_number field. - On saving, _inverse_account_number always writes to the first partner bank account. - Trusted bank accounts trigger an error: “You cannot change the account number or partner of a trusted bank account.” Desired behavior after PR is merged: - The wizard still shows the account_number field. - On saving, _inverse_account_number only writes if the value changed. - Trusted bank accounts that are not modified do not cause an error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where users could not save Documents settings for secondary companies after installing the Sign integration. The hidden Sign folder setting is no longer required, preventing an unnecessary validation error and allowing normal configuration changes.
Original PR description
**Steps to reproduce** - On a fresh DB, have multiple companies - Install documents_sign - With a company other than the main one, go to Settings > Documents > try to change a setting (e.g. Spreadsheets Workspace) - Error: "Invalid fields: Sign Base Folder" **Cause** The `documents_sign_folder_id` is only set on the main company and since it is invisible and required on the view, saving it is impossible. **Change** Since the folder serves no purpose, make it non required in the view. opw-5048447