Wednesday, April 15, 2026
20 changes · 19.0
Resolved issues and error corrections
Point of Sale users can now access the SInvoice symbol information needed for Viettel electronic invoicing in Vietnam. This prevents access-related interruptions when issuing or processing these invoices from PoS.
Original PR description
Add access right for sinvoice symbol so that PoS user can access to it. Forward-Port-Of: odoo/odoo#259045
This update fixes a test issue in the HTML editor color picker by making the test explicitly choose the solid color tab. It helps ensure the same automated test behavior across Odoo Community and Enterprise, reducing false failures in quality checks.
Original PR description
Purpose of this PR: Color picker opens different tabs by default because inline code uses a custom color `-900`. In community it opens the custom tab, while in enterprise it opens the solid tab. This caused the test to fail in community when selecting a color from the solid tab. runbot-242556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259169
The sample quotation buttons now point to the correct Odoo documentation PDF instead of opening a missing page. This prevents users from seeing a blank 404 error when trying to preview sample sales documents.
Original PR description
Currently, a 404 error is occurring when the user clicks on the Check the sample button. **Steps to produce:** - Install sales module without demo data. - Click on the check a sample. its clean! button. **Issue:** - A 404 error occurs with a blank page. **Cause:** - This issue is occurring because the link to open the sample quotation pdf was changed in the Odoo documentation. **Solution:** - Give a valid link to open the sample quotation pdf. - similar fix already did [here1] & [here2]. [here1]: https://github.com/odoo/odoo/commit/38431f3aef57c5b91644b4c5241f226beb917b12 [here2]: https://github.com/odoo/odoo/commit/610cea89c37454a4ddb68939333b4b363f2f81a2 opw-6099641 opw-6074953 Forward-Port-Of: odoo/odoo#258984 Forward-Port-Of: odoo/odoo#258003
This fix stops website popups from being placed inside sticky page sections that can cause display problems. It helps ensure popups appear correctly for shoppers and site visitors, such as on product listing pages.
Original PR description
If an popup is dropped within an element with the property "position" set to "sticky", there would visual issues with the modal. For example, if the user drop a popup below the filters in the /shop page, the images of the product would appear over the popup content when the popup is opened. Since there shouldn't be cases where "position" is setted to sticky without having the specific class, this commit fixes the issue by adding the selector ".position-sticky" as a forbidden ancestor for popups. task-5411329
Recruitment officers can now view the Trackers page on job positions without needing broader employee management permissions. This fixes an access mismatch and lets recruiting staff manage applicant tracking links with only the appropriate recruitment role.
Original PR description
Steps to reproduce: ---------------------------------------- 1. Install the `hr_recruitment` module 2. Create a new user and configure the following access rights: * Employees: No * Recruitment:…
Steps to reproduce:
----------------------------------------
1. Install the `hr_recruitment` module
2. Create a new user and configure the following access rights:
* Employees: No
* Recruitment: Officer Manage all applicants
3. Create new job position > Set created user in Recruiter
4. Log in with the created user
5. Go to Recruitment > Click on the Configure button of that job position
Observation:
----------------------------------------
The Trackers page is not visible on the job position form for the recruitment officer user.
If the user is additionally granted the Employees → Officer: Manage all employees group, the Trackers page becomes visible. The access to the recruitment Trackers should not depend on the Employee 'Officer: Manage all employees' access right.
Issue:
----------------------------------------
The visibility of the Trackers page depends on the Employees → Officer: Manage all employees group instead of the recruitment officer access rights
Solution:
----------------------------------------
Grant access to the Trackers page using the Recruitment Officer group so recruitment officers can access it without requiring the employee officer privileges
opw-5969416This fix makes an automated check for course review conversations wait for the confirmed empty-message state instead of moving ahead too early. It helps keep website course testing reliable and reduces false results during fast automated runs.
Original PR description
The previous negative assertion could pass prematurely during fast tour execution. Switching to a specific text based assertion ensures the step only proceeds once the empty conversation is explicitly confirmed. Forward-Port-Of: odoo/odoo#258921
The website builder color picker now shows the correct preview when a gradient theme background is applied to the header. This helps users see the expected visual result before applying or adjusting theme colors, reducing confusion during website customization.
Original PR description
### Issue: Color picker preview not showing correctly when a theme with a gradient background is applied to the header. ### Steps to reproduce: 1. Go to the Theme tab and open the color presets…
### Issue: Color picker preview not showing correctly when a theme with a gradient background is applied to the header. ### Steps to reproduce: 1. Go to the Theme tab and open the color presets dropdown. 2. Select any preset and set its background to a gradient. 3. Apply this theme to the header. ### Reason: - The color picker preview relies on `getComputedStyle` of the current editing element to determine what background to show. - For the header, the targeted editing element is `#wrapwrap > header`, but the actual gradient styles are applied to its inner `<nav>` elements (e.g., via `customizeWebsiteColorAction`). - Since the `background-image` property is never applied directly to the header element itself, computing its style does not capture the gradient defined on its inner elements, resulting in an incorrect or missing preview. ### Fix: - Avoid depending strictly on the computed style of the main editing element for generating the preview. - Ensure the preview accurately reflects the applied styles by utilizing CSS variables, even when certain builder actions apply those styles to inner elements rather than the primary targeted element, as demonstrated in the header example with `customizeWebsiteColorAction`. task-[6075788](https://www.odoo.com/odoo/project/974/tasks/6075788) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256566
Product images on the self-order combo selection screen now display without being stretched or distorted. This creates a more consistent and polished ordering experience, especially for products with non-square images.
Original PR description
Before this commit, the product image shown in the header of the combo screen in the self order interface was squished to fit the container, resulting in distortion for non-square images. After this commit, we add the `object-fit: cover` style to match the how the images are displayed elsewhere in self order. Before the change: <img width="595" height="536" alt="image" src="https://github.com/user-attachments/assets/fb90167c-8c28-46c9-9ab5-3ac472299c67" /> After the change: <img width="597" height="538" alt="image" src="https://github.com/user-attachments/assets/44d5c5a6-037b-46e2-8a28-5ef9df4d5e58" /> Product screen for reference (no change): <img width="561" height="143" alt="image" src="https://github.com/user-attachments/assets/4ee20d8c-9cde-4cc8-bcf1-8179f878a517" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257489
Digest reports now count connected users based on all companies they are allowed to access, not just their default company. This makes multi-company KPI reporting more accurate and reduces misleading user activity figures.
Original PR description
**Problem:** Currently, the digest KPI for connected users checks the "company_id" field (as with all other models), but this field corresponds to "Default Company" on res.users, meaning a user can only be considered for one company when computing the digest KPI. This can cause misleading digest KPIs if users work in multiple companies, or mainly in a company that isn't their default company. **Solution:** Instead of always using the "company_id" field, we use the "company_ids" field if present on the model. opw-5404940 Forward-Port-Of: odoo/odoo#257934 Forward-Port-Of: odoo/odoo#247806
The portal's "Back to edit mode" link for invoices now opens the invoice in the Invoicing app instead of sometimes landing in another app such as Website. This makes the navigation more predictable for users editing invoices from the portal.
Original PR description
The "Back to edit mode" link used action_move_out_invoice_type, which isn't bound to any menu, so the backend fell back to whichever app happened to match (e.g. Website when installed) instead of Invoicing. Switch to action_move_out_invoice (the one referenced by the Invoicing menu) so the webclient resolves the correct app automatically. task-5882256 Forward-Port-Of: odoo/odoo#257841
Fixed an issue where published eLearning course cards could incorrectly appear dimmed when their description included a button or similar content. This ensures only unpublished courses are visually marked with the grey overlay, avoiding confusion for website visitors and course managers.
Original PR description
Steps to reproduce: ================= 1. Go to eLearning > Courses and create a published course 2. In the Description tab, add a button with a link and save 3. Go to /slides on the website 4. The…
Steps to reproduce: ================= 1. Go to eLearning > Courses and create a published course 2. In the Description tab, add a button with a link and save 3. Go to /slides on the website 4. The course card appears with a grey overlay (0.5 opacity) => Published course cards with a button in the description show a grey overlay => Only unpublished course cards should have the grey overlay Cause: ====== In [1], the opacity for unpublished courses was moved from `.o_wslides_course_unpublished` to its container using a `:has()` selector. However, the selector `div:has(> .card + .card-body, ...)` was too broad: it matched any container whose `.card` child had a sibling `.card-body`, regardless of whether the course was unpublished. When a course description contains a button (or any block-level element), the browser renders the button outside the `.card` element. This creates the structure `div > .card + .card-body` that the selector matches, applying a 0.5 opacity grey overlay to fully published courses. Solution: ======== The fix restricts the first selector arm to only match when `.o_wslides_course_unpublished` is the sibling, ensuring published courses with buttons in their descriptions are not affected. [1]: https://github.com/odoo/odoo/pull/249969 opw-5900287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales order reports no longer show a misleading zero amount next to the “Down Payments” section header. This keeps printed and portal order documents clearer for customers and avoids confusion when down payments are included.
Original PR description
When creating an order with a down payment, the printed order report incorrectly shows a zero amount on the “Down Payments” line. This line acts as a section header and should not display any amount. opw-5446875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Nested list items now correctly show the default font size in the editor toolbar, even when a parent list item uses a custom size. This avoids misleading formatting information and helps users edit notes and documents more consistently.
Original PR description
Problem: When using nested lists where a parent list item has a custom font size, the child list does not display the default font size in the toolbar. Cause: `getFontSizeDisplayValue` does not treat `.o_default_font_size` as a boundary element. It continues searching up the DOM and may retrieve a font size from a parent element outside the intended default font size scope. Solution: Stop the font-size lookup when reaching `.o_default_font_size`, since this class defines the default font size boundary. Steps to reproduce: - Go to a "To do" note. - Insert a bullet list with sub-items. - Select the top list item and set its font size to 72. - Select a sub-item. - Observe the toolbar does not show the default font size. task-6105581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Uploading an empty or invalid PDF in Accounting now fails safely instead of causing an error page. This improves reliability when users attach documents for accounting workflows.
Original PR description
Issue: - Uploading an empty PDF triggered a stack trace. - The uploaded file content sometimes returned False instead of bytes. - Passing this value to io.BytesIO() raised a TypeError. Fix: - Added a check to ensure the content is valid. Impact: - Prevents crashes when users upload empty or invalid PDF files. TaskID-6004471 Forward-Port-Of: odoo/odoo#252208
This change fixes an internal Manufacturing app test that was failing because it referenced an outdated production order relationship. It helps keep automated quality checks reliable without changing day-to-day user behavior.
Original PR description
Since the introduction of test_basic_flow_with_minimal_access_rigths in e8ce2d842dd95ee1626f346ee0025abb55beb94e, running the test on 19.0 fails with:
AttributeError: 'mrp.production' object has no attribute 'backorder_ids'
The mrp.production model on 19.0 does not expose a backorder_ids field anymore: the equivalent relation is now reached through the production group, via production_group_id.production_ids.
The test was backported from master where the same field is also absent, so the assertion was broken as soon as it was introduced on 19.0.
Use production_group_id.production_ids in the assertion to restore the intended check (original MO + its backorder).
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-prThis update resolves an issue where very small order weights (under 1kg) weren't being correctly converted to grams before being sent to the shipping carrier. Previously, the system treated these as zero, leading to rejected orders. Now, all non-zero lightweight orders are accurately converted, ensuring shipments meet carrier minimum weight requirements.
Original PR description
Before this commit, `sendcloud_convert_weight()` used the source UoM rounding to short-circuit zero values. On databases where the weight UoM is `kg` with a rounding of `1.0`, any weight below 1kg was treated as zero and returned unconverted. For example, 0.23kg stayed 0.23 instead of being converted to 230g, `int()` turned it into 0, and Sendcloud rejected the order as being below the carrier minimum weight. This commit ensures that non-zero lightweight orders are properly converted before Sendcloud weight checks are applied. opw-6014572
This update resolves an issue where the Batch Payment report incorrectly displayed default 'demo' values (Account Holder Name and Memo) when customer information was missing. The fix ensures that these fields are blank in the report, providing accurate and clean payment details for users. This improves the clarity and professionalism of the printed reports.
Original PR description
**Steps to reproduce:**
- Install the `account_batch_payment` module.
- Navigate to Invoicing > Customers > Payments.
- Create a new payment with `Payment Type: Send` and
select a customer without setting an `Account Holder Name`.
- Create a batch payment including this payment.
- From the gear icon, click `Print Batch Payment`.
**Observation:**
In the generated report:
- `Account Holder Name` shows `ABC Holder Name`.
- `Memo` shows `Demo Ref`.
**Root Cause:**
At [1], the default demo values ("ABC Holder Name", "Demo Ref") are rendered
when the fields are empty, instead of being left blank.
**Fix:**
This commit ensures that the `Account Holder Name` and `Memo` are `blank`
in the printed Batch Payment report when their values are not set.
[1]:
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/account_batch_payment/report/account_batch_payment_report_templates.xml#L36-L38
opw-6092595
Forward-Port-Of: odoo/enterprise#113515This update adds a specific line item to the CH balance sheet report to accurately reflect Treasury Shares (account 2980). Previously, this account was handled differently, and this change corrects a previous omission, ensuring accurate equity reporting for Swiss clients. The change improves the report's precision and aligns with accounting standards.
Original PR description
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report. Account 2980 was previously included in the Legal reserves report line via the old formula:…
This commit adds a dedicated report line for account 2980 (Treasury shares) to the CH balance sheet report.
Account 2980 was previously included in the Legal reserves report line via the old formula:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
In recent commit https://github.com/odoo/enterprise/pull/102247/changes/81bcf433e909ce6ec56af484e9dd59a47fc87c98 the formula was narrowed down to :
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
And account 2980 was no longer considered.
Rather than adding it to the Legal reserves formula, a dedicated Treasury shares report line (CH_290_C) has been added under report line CH_290. New line as account 2980 represents a correction of equity (negative item) and is conceptually distinct from legal reserves. The parent line aggregation formula has been updated accordingly:
```py
CH_290_A.balance + CH_290_B.balance + CH_290_C.balance
```
see affected account: https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L108This update corrects a technical issue impacting delivery processing for Colombia. Previously, the system incorrectly formatted zip codes, leading to inaccurate data sent to Envia. Now, the system uses Envia's geocoding service to ensure correct zip code formatting, improving delivery reliability.
Original PR description
For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code. When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`. Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally. opw-6083181
This update resolves an issue where POS users with limited access rights were unable to fully close their Fiskaly VAT resolution sessions, requiring administrator privileges. The fix simplifies the process by removing unnecessary checks for API credentials, ensuring a smoother user experience for POS users working with the Germany + Fiskaly setup. This improves usability and avoids requiring specialized user permissions.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#112618