Tuesday, September 2, 2025
16 changes · saas-18.3
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#92497