Daily updates from Odoo
Friday, May 16, 2025
5 changes
Resolved issues and error corrections
This fixes an unnecessary warning that asked users to create a warehouse when making certain purchase orders, such as dropship purchases, for a company without a warehouse. Users can now proceed without being forced into extra setup that is not needed for that purchasing flow.
Original PR description
Usecase: - Create a new company without warehouse - Create a purchase.order with a dropship type You got a redirect warning asking for a warehouse. But in this case it's not needed and force the user to create a warehouse. (which is not the purpose of commit 6516ab61927a63e3f2d804cf1b5baa43a151ca19) 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 fix prevents new Odoo databases from failing when they are created with certain regional languages, such as Argentinian Spanish. It ensures language settings are applied in the right order so setup completes successfully without duplicate language code errors.
Original PR description
**Steps to reproduce:** 1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR` **Result:** ``` 2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading…
**Steps to reproduce:**
1. Initialize a new database with `odoo -d langdb --stop -i base --load-language=es_AR`
**Result:**
```
2025-01-03 11:41:28,054 54 INFO langdb odoo.modules.loading: loading base/data/res_bank.xml
2025-01-03 11:41:28,057 54 INFO langdb odoo.modules.loading: loading base/data/res.lang.csv
2025-01-03 11:41:28,076 54 INFO langdb odoo.modules.loading: loading base/data/res_lang_data.xml
2025-01-03 11:41:28,091 54 ERROR langdb odoo.sql_db: bad query: b' UPDATE "res_lang"\n
SET "url_code" = "__tmp"."url_code"::VARCHAR, "write_date" = "__tmp"."write_date"::timestamp, "write_uid" = "__tmp"."write_uid"::int4\n
FROM (VALUES (68, \'es\', \'2025-01-03T11:41:26.517428\'::timestamp, 1)) AS "__tmp"("id", "url_code", "write_date", "write_uid")\n
WHERE "res_lang"."id" = "__tmp"."id"\n'
ERROR: duplicate key value violates unique constraint "res_lang_url_code_uniq"
DETAIL: Key (url_code)=(es) already exists.
```
**Explanation:**
When initializing a new database with a specific language, the language is activated on `install_lang`, and since it's the only active language of the "es_*" family, its url_code is set to the short version. [^1]
By the time the url_code switch in `res_lang_data.xml` is executed, the `base.lang_es` language is no longer the one with "es" as url_code. It's actually the recently activated es_AR language.
**Solution:**
We must perform the `url_code` switch before calling `install_lang`
[^1]: https://github.com/odoo/odoo/blob/c042e1ba/odoo/addons/base/models/res_lang.py#L339-L356
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixes how fixed-rate IEPS taxes are reported on Mexican electronic invoices and related payment documents. This helps ensure tax values are sent correctly to the tax authority, reducing validation errors and manual follow-up.
Original PR description
See test in this commit. opw-4744627
Customer follow-up emails now correctly include the overdue invoice attachments again. This ensures customers receive the documents they need to understand and pay outstanding amounts, including when automated follow-ups are run.
Original PR description
### Steps to reproduce:
- Create an invoice with a due date past for long time
- Accounting > Customers, click on the partner of the invoice
- In the page "Accounting" the "Follow-up Status" should be "In need of action"
- Go to the Scheduled Action "Account Report Followup; Execute followup" and Run manually
- Go back to the partner
- The follow-up is send without the invoices
### Cause:
This [commit](https://github.com/odoo/enterprise/pull/84114) moved a part of code to fix a bug but it also changed it: it moved `'attachment_ids' not in options` from the end to the beginning. By doing that the line
`options.get('attachment_ids', self._get_invoices_to_print(options).message_main_attachment_id.ids)`
does not work anyore because `attachment_ids` is always in `options` so `_get_invoices_to_print` is never called.
### Solution:
Use `setdefault` instead of `get`.
opw-4716458This fixes an issue where newly selected Knowledge cover images could be incorrectly linked to an older cover record. As a result, the system cleanup process could delete the active cover image; the change ensures covers remain visible after cleanup.
Original PR description
The overhaul of html editor into knowledge introduced an issue involving the auto-vaccuum. This commit https://github.com/odoo/enterprise/commit/08d84f8b61450a0ebd0d2aadfe8f227bda283edd passes the res_id value of the currently existing knowledge.cover record. However, when we set a new cover image, we will always create a new cover record and the new cover image attachments are linked to the previous cover record. The auto-vaccuum then deletes unused cover images and any attachments linked, which will delete the actual cover image. The web_unsplash/attachment/add does not need to pass in a res_id of the cover image since we always create a new record at the end of the workflow. opw-4629300