Wednesday, June 17, 2026
15 changes · 19.0
Enhancements to existing features
The demo Flour product in Point of Sale now uses kilograms as its unit of measure. This makes weighing setup clearer and better supports scale certification scenarios for bakery demos.
Original PR description
This small PR sets the "Flour" product's units of measure to kilograms. This helps to configure the weighing of the product, especially for the l10n_eu_iot_scale cert
Analytic distribution checks now reuse previous plan lookup results when the same criteria are used repeatedly. This reduces repeated processing during bulk journal entry validation, helping accounting workflows run more smoothly without changing user-facing behavior.
Original PR description
The method `get_relevant_plans` is called in `_validate_distribution`, which is often called in loops, for instance when validating the analytic distribution of multiple journal entries or of journal entries with multiple lines. That method is doing a lot of work by filtering all the plans and all the applicabilities every time, which can be avoided since the `kwargs` are likely to often be the same ones.
This update ensures Odoo sends the LC116 code with dots, as required by Avalara for their city web services. Currently, Odoo removes these dots, which prevents Avalara's automated sanitization process from working correctly. This change aligns with Avalara's requirements to ensure proper data processing.
Original PR description
Purpose: Avalara requires the LC116 code to be dotted for certain city webservices. Their tool will automatically sanitize the dots for cities that don't support it. Current Behavior: Odoo sanitizes the LC116 code before sending the JSON payload. Expected Behavior: The LC116 code is sent in the JSON payload with the dots. task-6304351
This update enhances navigation between sold assets and related customer invoices. Now, invoices linked to a sold asset are directly accessible from the asset's chatter, and vice versa. This streamlines workflows by providing quick access to relevant invoice information.
Original PR description
This commit improves the navigation from a sold asset to the customer invoice and vice versa. A reference link of the sold asset is added to the chatter of each invoice used in sale. Also, all invoices used in sale are added as reference link to the asset's chatter. task-4413649
Resolved issues and error corrections
This fix moves the logic for choosing the French PDP service connection URL to the company record, making it more reliable over time. It avoids depending on temporary registration records that may be deleted, reducing the risk of failures during PDP setup or use.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270345
Users can now save website pages after removing all content from an editable HTML field, such as a job description or rating section. The system now treats whitespace-only content as empty, avoiding a validation error that blocked saving.
Original PR description
Steps to reproduce: =================== 1. Edit a job page. 2. Delete every `s_rating` block. 3. Save. => Validation Error: Document is empty. Cause: ====== Deleting the last snippet inside an…
Steps to reproduce: =================== 1. Edit a job page. 2. Delete every `s_rating` block. 3. Save. => Validation Error: Document is empty. Cause: ====== Deleting the last snippet inside an editable HTML field (e.g. the last `s_rating` block in the `website_rating` field of a job page) leaves the field's editable container with only whitespace text nodes. On save, it writes that whitespace to the record and then calls `_copy_custom_snippet_translations`, which does `html.fromstring(lang_value)` on the whitespace and raises `lxml.etree.ParserError: Document is empty`, re-raised as `ValidationError`. The user sees a "Validation Error" dialog and can't finish saving. The previous fix for the analogous "Document is empty" symptom on product description editing (commit [1]) added a `cleanupEmptyStructures` `on_removed_handlers` that strips whitespace from `.oe_empty` containers after element removal. That selector covers `oe_structure.oe_empty` containers but not editable HTML field savables (`[data-oe-type="html"]`), which don't carry an `oe_empty` class when they originally had content. As a result, fields like `hr.job.website_rating` still hit the failing parse path. Solution: ========= Extend the cleanup selector to also include `[data-oe-type="html"]` so HTML-field editables are normalized to genuinely empty after the last inner snippet is removed. [1]: https://github.com/odoo/odoo/commit/53d5cc7eed635f64038bf0315f6863011879c529 opw-6244892 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267397
Product images in the self-order flow now keep their proper proportions instead of appearing stretched or distorted. This improves the ordering experience by making menu items clearer and more visually accurate for customers.
Original PR description
In this commit: ------------------- - Applied `object-fit: scale` to ensure product images are fully visible and properly displayed without distortion. task: [6260046](https://www.odoo.com/odoo/project.task/6260046) Forward-Port-Of: odoo/odoo#268521
A repeated account entry was removed from the Danish accounting migration list. This helps keep the localization data clean and avoids unnecessary duplicate processing during migrations.
Original PR description
In the list, 'dk_coa_7630 ', the account has been used in the list twice. Removing the duplication from the list. [Reference](https://github.com/odoo/odoo/blob/19.0/addons/l10n_dk/migrations/1.4/pre-migrate.py#L14) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when users open the email notification popover for chatter messages that do not have a linked contact. It keeps event registration and mass mailing-related notifications usable instead of showing a traceback.
Original PR description
# How to reproduce - Create an Event registration - Add a follower - Click on the enveloppe icon next to the sender's name in the chatter # The problem A traceback appears # Cause of the issue When clicking on the enveloppe, we display the `message_notification_popover` that calls `isFollowerNotification` to filter follower notifications from other ones. This function compares the ids of the followers of the notification to it's res_partner_id : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/static/src/core/common/notification_model.js#L101-L105 But in our case res_partner_id is undefined because it is not a required field and it will not be set in the case of mass_mailing : https://github.com/odoo/odoo/blob/ee12a62407fa1c2dbca00d77dc6d5bd16eac1e43/addons/mail/models/mail_notification.py#L23-L27 opw-6178443 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes automated tests for older live chat views that could fail because of timing issues in real-time updates. The affected views have already been replaced by a dedicated Discuss category, so this reduces false test failures without changing the user experience.
Original PR description
Some tours check that real time updates work for kanban/list views of looking for help live chats. However, there can be a race condition between the time the view is loaded, and the time the bus subscription is made on the server. As a result, there is a small window where updates can be missed. A proper solution would be to wait for the subscription to be made to load the view, but the server doesn't provide any acknowledgement for subscriptions. Since those views have been removed in favor of a dedicated discuss category, the issue is considered minor and not worth fixing. This commit removes the related tests. runbot-234681 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 French FEC export now skips opening balance lines that net to zero, avoiding blank-looking entries with 0.00 debit and credit amounts. This makes the exported statutory accounting file clearer and helps reduce confusion during review or audit preparation.
Original PR description
Steps to reproduce: - Use a French company (l10n_fr_account installed) - Post prior-year entries so that an account/partner nets to zero at the start of the next fiscal year (e.g. a customer invoice fully paid the same year, or a misc entry debiting and crediting the same balance-sheet account), and keep another account/partner with a non-zero opening - Open the FEC export wizard, set Start Date to the first day of the next year - Generate the FEC file and look at the "Balance initiale" (OUVERTURE) lines Issue: One of the exported line in as empty one with `...|0,00|0,00|..`` opw-6083991
This fix ensures recruitment and eCommerce only create accent-insensitive search indexes when the database function fully supports indexing. It prevents installation or upgrade failures on databases where the function exists but was not configured for indexes.
Original PR description
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index. The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is…
PostgreSQL's `unaccent` function must be marked as `IMMUTABLE` before it can be used in a functional index.
The ORM usually handles this when the `unaccent` extension is missing and `odoo-bin` is started with the `--unaccent` flag during database creation.
However, it is also possible to start `odoo-bin` with an existing database where the `unaccent` extension is already installed, but the function was never marked as `IMMUTABLE`.
In that case, `unaccent` can still be used in conditions such as `WHERE` clauses, but it cannot be used in functional indexes.
`has_unaccent()` actually has three possible states:
```py
class FunctionStatus(IntEnum):
MISSING = 0 # function is not present (falsy)
PRESENT = 1 # function is present but not indexable (not immutable)
INDEXABLE = 2 # function is present and indexable (immutable)
```
Therefore, checking only `if has_unaccent()` before creating an index using `unaccent` is not enough. The index should only be created when `has_unaccent()` returns `FunctionStatus.INDEXABLE`.
task-6307060
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#270278This update resolves a technical issue in Odoo's Studio that caused errors when users deleted the last column from a report table. The fix ensures the system handles this scenario gracefully, preventing unexpected tracebacks and improving the user experience. This ensures reports can be edited without interruption.
Original PR description
Problem: When deleting the last column in a table in studio we get a traceback. Cause: `firstCell` will be null if we delete the last cell in the table. Fix: Added a null check on `firstCell` before calling `setCursorEnd`, so the cursor is only repositioned when the table still has remaining cells. Steps to reproduce: - Edit a report with a table. - Remove all columns. - Traceback will occur when deleting the last one. opw-6263696 Forward-Port-Of: odoo/enterprise#119502
This update fixes an issue where quality alerts weren't being created when incoming emails were processed without a company assigned. The fix ensures that a default company is now automatically applied, preventing errors and guaranteeing that all emails trigger the correct quality alert record creation. This improves the reliability of the quality control process.
Original PR description
Steps to reproduce 1. Install quality 2. Create an incoming email server 3. Go to Quality > Configuration > Quality Teams > Team > add alias email 4. Do not fill the company field 5. Send email to this alias 6. Fetch emails from incoming email server Issue: - Record is not created in the quality alert Root cause: - For the Quality alert model, the field `company_id` is required, but while we fetch emails We haven't set the `company_id` on the quality alert team, resulting in trying to insert a null value on the quality alert model. Solution: - Give a default value to company_id. - Raise a validation error on not having a company_id - Update alias default values on changing company_id opw-5917791 Forward-Port-Of: odoo/enterprise#117846 Forward-Port-Of: odoo/enterprise#109947
This update fixes a discrepancy in the start dates of semi-monthly payrolls. Previously, payslips were incorrectly aligned with the end of the first half of the month. Changing the start date to the 16th ensures accurate payroll scheduling for employees on this payment cycle.
Original PR description
Issue: ---------------------------------------- The start date of semi-monthly payslips on second half of the month is the 15 which is also the end date of the first half of the month. Steps to reproduce: ---------------------------------------- - Have an employee with a semi-monthly payroll - When in the first half of the month, create a payslip for this employee - The payslip is from 1st to 15th - Do the same when in the second half of the month - The payslip is from 15th to end of the month Cause: ---------------------------------------- In `_schedule_period_start()` we set the start date to th 15th for semi-monthly payslips. Solution: ---------------------------------------- Set it to the 16th. opw-6281556 Forward-Port-Of: odoo/enterprise#120172