Thursday, August 28, 2025
7 changes · 17.0
Resolved issues and error corrections
This fix prevents required Nilvera e-Dispatch values from being translated in Turkish localization. It ensures the system sends the exact expected 'true' or 'false' values, reducing the risk of rejected or incorrect electronic dispatch documents.
Original PR description
Before this commit, since we hardcoded the value, the value was present in the pot and po file. Except that nilvera want a precise value which is 'false' or 'true' and not something translated. task-5009049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes Indonesian Coretax product codes easier to find when selecting them on product records. Users can now search by code or description, reducing confusion and speeding up product tax 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#221858
Users can now enter an ampersand character in filter values without causing the search or domain selector to crash. This fixes a frustrating error when applying custom filters and keeps legitimate text searches separate from internal filter logic.
Original PR description
Example of steps: - Open any domain selector with an archive checkbox (via custom filter for example) - Try to add char `&` in value input - focus out or try to apply the filter - Traceback ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillUpdateProps: "Cannot read properties of undefined (reading 'filter')" ``` The problem comes from the fact that we expect to have multiple nodes in our domain if we have an `&` as a value. However, there is a difference between using `&` in a text search for example (type `condition`), and using `&` as an AND between two nodes (type `connector`). The solution is to restrict the condition so that it not only checks that the value is equal to `&`, but also checks that the tree type is indeed a connector and not a condition. opw-5015281
This fix prevents errors when website SEO suggestions fail to load or when a page has no description. It helps keep SEO preview tools stable for users editing website pages.
Original PR description
Ensure the Google suggest fallback always returns a JSON list, even on IOError, instead of raising a serialization traceback. JS (SEOPreview): guard against undefined/empty descriptions with optional chaining and default empty string to avoid runtime errors. opw-4963552
Kit products now follow quantity-on-hand filters based on their actual computed availability from component stock. This prevents kits from appearing in product lists when they do not meet the selected stock quantity criteria, improving inventory search accuracy.
Original PR description
#### Issue: - When filtering products on "Quantity on hand", kits may appear when they shouldn't #### Step to reproduce: - with MRP - create a new product - create a BoM for this product as kit - make sure you have product of the BoM on hand - go to product - add filters: - "Quantity on hand" > 1 - "Quantity on hand" < *less_than_you_have* #### Current behavior: - kit appears #### Expected behavior: - kit doesn't show #### Cause: - kit were filtered has having both 0 quantity (as unstored product) and their quantity (computed from stock of BoM products). Therefore they were compliant with both filter. #### Solution: - remove kits from products compliant with the filter if they don't comply with the filter with their computed quantity opw-4967763 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Mexican electronic invoices from failing when an extremely early invoice date is used. It removes an unnecessary date conversion so the posting time is stored correctly, improving reliability for edge-case invoice data.
Original PR description
If we create an invoice with `invoice_date = date.min`, `fields.Datetime.to_string(move._l10n_mx_edi_get_min_of_now_and_document_date())` is `'1-02-01 23:59:00'` which cannot be parsed when assigning to the `l10n_mx_edi_post_time` field which is of type `fields.Datetime`. It turns out we don't need the `fields.Datetime.to_string` since `_l10n_mx_edi_get_min_of_now_and_document_date` already removes the timezone information from the datetime it returns. So we remove it. runbot-231184 Forward-Port-Of: odoo/enterprise#93174
The signing dialog now consistently opens with the automatic signature option selected, whether or not the user already has a saved signature. This reduces confusion and keeps the signing experience predictable for users.
Original PR description
Ensure the signature dialog consistently defaults to the "auto" option, regardless of whether a user has a pre-set signature or not. task-5012307