Odoo Changelog — 2026-03-24

Tuesday, March 24, 2026

5 changes · 17.0

Bug Fixes(5)

Resolved issues and error corrections

[FIX] l10n_es_reports: set default procuration date in Modelo 390 BOE export

Enterprise17.0l10n_es_reportsMedium

This update resolves an issue where the AEAT tax report file was being rejected due to an incorrect date format. The fix ensures the file includes a default numeric date ('00000000') when a legal person's procuration date is not specified, meeting AEAT's requirements and allowing successful file uploads.

Original PR description

**Steps to reproduce:**
- Install the `l10n_es_reports` module and switch to the `ES company`.
- Go to Invoices and create an invoice with taxes, then confirm it.
- Navigate to Accounting > Reporting > Tax Report.
- From the smart button, select `Report: Tax Report (Mod 390) (ES)` and 
  choose the year as `This Financial Year`.
- Download the `BOE` file using the dropdown and fill the wizard fields 
  (e.g., Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345).
- Upload the generated .txt file to the AEAT portal. (AEAT credentials are required)

**Observation:**
AEAT rejects the file with:
`Caracteres no válidos '4. Representante - Personas Jurídicas - Represent. 1 - Fecha Poder (DDMMAAAA)'`

**Root cause:**
At [1], when `judicial_person_procuration_date` is `false`, an empty string is 
written to the BOE file, resulting in blank spaces in the exported file. This 
does not comply with AEAT’s required numeric format and causes the file 
to be rejected.

**Fix:**
This commit ensures the file contains '00000000' when 
`judicial_person_procuration_date` is false, complying 
with AEAT numeric format requirements.

[1]:
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/l10n_es_reports/models/aeat_tax_reports.py#L1696

opw-5995290

#reporting#es#tax#aeat

[PERF] account_edi_ubl_cii: Batch queries for Peppol cron

PR #244550

Core17.0account_edi_ubl_ciiMedium

This update resolves a performance issue where processing large Peppol invoices caused delays and potential cron job failures. By batching invoice processing, the system now handles high volumes of invoices much more efficiently, reducing processing times significantly. This improves the reliability of Peppol document creation.

Original PR description

### Description:

Retrieving Peppol documents with high line counts could cause the background cron to timeout and eventually be disabled after multiple failures. This bottleneck occurred because the system processed each invoice line through individual calls.

To resolve this, the code has been refactored to batch the creates and updates. This change significantly reduces I/O overhead and ensures that large invoices no longer block the cron from creating new documents.

### Benchmark:

| N° of lines | Before  | After  |
|-------------|---------|--------|
|        4633 | Timeout |  3 min |

### Reference:
opw-5462267

#Peppol#EDI#Invoice Processing#Performance

[FIX] tools: add support for /Kids attachments in PDFs

PR #252523

Core17.0baseMedium

This update resolves an issue where PDFs with multiple XML attachments (organized in a specific PDF format) weren't being correctly extracted. The fix ensures that all XML attachments embedded within these PDFs are now processed, preventing empty bills and improving data accuracy. This enhancement impacts how attachments are handled in accounting documents.

Original PR description

Steps to reproduce:
- From the accounting dashboard, upload a PDF containing intermediate
  /Kids nodes representing separate xml attachments

Issue:
No xml will be extracted, as result the bill will be empty.
However, in the chatter pdf preview, the js pdf toolkit correctly
show the xml attachemnts.

Analysis:
The PDF spec defines two ways to organize embedded files under /EmbeddedFiles
in the document's name dictionary:
- /Names: a flat array of pairs located directly under /EmbeddedFiles
- /Kids: an array of child nodes, each of which carries its own /Names array.
The extractor currently only handled the /Names case, not detecting
embedded attachments in case of PDF using a /Kids tree.
This change add lookup for both structures.

opw-5929274

#pdf#attachments#accounting

[FIX] website, *: prevent 404 on records access with website rule

PR #213143

Core17.0websiteMedium

This update prevents 404 errors when accessing website content without logging in. The issue stemmed from how website access rules were evaluated, leading to incorrect access denials. The fix ensures proper website context is available during rule evaluation, allowing authorized access to public records.

Original PR description

\* = test_website_modules

### Issue:
When accessing a record from the website without logging in, a `404`
error occurs if a public record rule filters records by website related
domain, for example `[('website_id', '=', website.id)]`.

### Steps to reproduce:
- Install the 'website_blog' module and create at least one website.
- Enable debug mode.
- Go to Settings > Technical > Database Structure > Models.
- Open the `blog.post` model.
- Go to the 'Record Rules' tab.
- For the record 'Blog Post: public: published only', change the domain
  from `[('website_published', '=', True)]` to
  `[('website_id', '=', website.id)]`.
- Go to Website > Configuration > Blogs.
- Open a blog (e.g., Travel).
- Select 'My Website' in its 'Website' field.
- Open 'My Website' without logging in.
- Click on the 'Blog' menu and the blog listing will appear correctly.
- Try opening a blog post and a `404` error occurs.

### Reason:
<pre>
┌─────────────────────────────────────────────────────────┐
│                    Request Lifecycle                    │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  User Request (not logged in)                           │
│       ↓                                                 │
│  ┌──────────────────────────────────────┐               │
│  │ 1. _pre_dispatch                     │               │
│  │    ↓                                 │               │
│  │    check_access_rule                 │               │
│  │    ↓                                 │               │
│  │    _eval_context (compute domain)    │               │
│  │    ↓                                 │               │
│  │    get_request_website()             │               │
│  │    ↓                                 │               │
│  │    request.website = None            │  ← Issue      │
│  │    ↓                                 │               │
│  │    Domain evaluation FAILS           │               │
│  │    ↓                                 │               │
│  │    Access DENIED → 404 Error         │               │
│  └──────────────────────────────────────┘               │
│       ↓                                                 │
│  ┌──────────────────────────────────────┐               │
│  │ 2. _frontend_pre_dispatch            │               │
│  │    (NEVER REACHED)                   │               │
│  │    ↓                                 │               │
│  │    request.website initialized ✓     │  ← Too Late   │
│  └──────────────────────────────────────┘               │
│                                                         │
└─────────────────────────────────────────────────────────┘
</pre>
Because `request.website` is initialized later in
`_frontend_pre_dispatch`, access rules evaluated earlier in
`_pre_dispatch` cannot rely on website context. As a result, record
rules depending on `website_id` are evaluated before `request.website`
is available, incorrectly denying access to public records.

### Fix:
Avoid totally relying on `get_request_website` during access rule
evaluation. Use the `request.is_frontend` attribute as a fallback, which
is set earlier, to detect frontend requests and ensure correct access
handling.

task-[4758311](https://www.odoo.com/odoo/project/974/tasks/4758311)

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#website#access#404

[FIX] point_of_sale: fix QR-code cache issue

PR #251139

Core17.0point_of_saleMedium

This update resolves a problem where QR codes on point-of-sale receipts were sometimes incorrect, pointing to the wrong invoice. The issue stemmed from how the system cached QR code images, leading to duplicate keys. The fix ensures unique QR codes are generated for each order, improving receipt accuracy and customer experience.

Original PR description

**Step to reproduce:**
- install "l10n_es_edi_verifactu_pos"
- setup "ePOS printer" for a pos
- open pos and settle a order below 400$
- notice we get l10n_es_edi_verifactu_qr_code in our receipt
- click on "Print receipt"
- repeat above steps for one more order

**Observation:**
- when we print the second order receipt, the QR still points to 1 order invoice

**Issue:**
- [getCacheKey](https://github.com/odoo/odoo/blob/0cee3350df09b06af77c879f0eba74bf6a8dd2c9/addons/point_of_sale/static/src/app/utils/html-to-image.js#L351C10-L355
) was trimming query strings when generating cache keys. URLs like:
`  http://localhost:9000/report/barcode/?barcode_type=QR&value=... `
were reduced to:
`  http://localhost:9000/report/barcode/`

- As a result, different QR code requests shared the same cache key. Subsequent requests reused the previously cached image instead of fetching a new one, producing incorrect QR codes for different orders.

**Solution:**
Add an `includeQueryParams` flag to `resourceToDataURL` so the full URL, including query parameters, is used as the cache key when needed. This ensures unique QR code URLs are cached and fetched correctly.

opw-5455807


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#pos#qr code#receipt

**Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the `ES company`. - Go to Invoices and create an invoice with taxes, then confirm it. - Navigate to Accounting > Reporting > Tax Report. - From the smart button, select `Report: Tax Report (Mod 390) (ES)` and choose the year as `This Financial Year`. - Download the `BOE` file using the dropdown and fill the wizard fields (e.g., Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345). - Upload the generated .txt file to the AEAT portal. (AEAT credentials are required) **Observation:** AEAT rejects the file with: `Caracteres no válidos '4. Representante - Personas Jurídicas - Represent. 1 - Fecha Poder (DDMMAAAA)'` **Root cause:** At [1], when `judicial_person_procuration_date` is `false`, an empty string is written to the BOE file, resulting in blank spaces in the exported file. This does not comply with AEAT’s required numeric format and causes the file to be rejected. **Fix:** This commit ensures the file contains '00000000' when `judicial_person_procuration_date` is false, complying with AEAT numeric format requirements. [1]: https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/l10n_es_reports/models/aeat_tax_reports.py#L1696 opw-5995290

### Description: Retrieving Peppol documents with high line counts could cause the background cron to timeout and eventually be disabled after multiple failures. This bottleneck occurred because the system processed each invoice line through individual calls. To resolve this, the code has been refactored to batch the creates and updates. This change significantly reduces I/O overhead and ensures that large invoices no longer block the cron from creating new documents. ### Benchmark: | N° of lines | Before | After | |-------------|---------|--------| | 4633 | Timeout | 3 min | ### Reference: opw-5462267

Steps to reproduce: - From the accounting dashboard, upload a PDF containing intermediate /Kids nodes representing separate xml attachments Issue: No xml will be extracted, as result the bill will be empty. However, in the chatter pdf preview, the js pdf toolkit correctly show the xml attachemnts. Analysis: The PDF spec defines two ways to organize embedded files under /EmbeddedFiles in the document's name dictionary: - /Names: a flat array of pairs located directly under /EmbeddedFiles - /Kids: an array of child nodes, each of which carries its own /Names array. The extractor currently only handled the /Names case, not detecting embedded attachments in case of PDF using a /Kids tree. This change add lookup for both structures. opw-5929274

\* = test_website_modules ### Issue: When accessing a record from the website without logging in, a `404` error occurs if a public record rule filters records by website related domain, for example `[('website_id', '=', website.id)]`. ### Steps to reproduce: - Install the 'website_blog' module and create at least one website. - Enable debug mode. - Go to Settings > Technical > Database Structure > Models. - Open the `blog.post` model. - Go to the 'Record Rules' tab. - For the record 'Blog Post: public: published only', change the domain from `[('website_published', '=', True)]` to `[('website_id', '=', website.id)]`. - Go to Website > Configuration > Blogs. - Open a blog (e.g., Travel). - Select 'My Website' in its 'Website' field. - Open 'My Website' without logging in. - Click on the 'Blog' menu and the blog listing will appear correctly. - Try opening a blog post and a `404` error occurs. ### Reason: <pre> ┌─────────────────────────────────────────────────────────┐ │ Request Lifecycle │ ├─────────────────────────────────────────────────────────┤ │ │ │ User Request (not logged in) │ │ ↓ │ │ ┌──────────────────────────────────────┐ │ │ │ 1. _pre_dispatch │ │ │ │ ↓ │ │ │ │ check_access_rule │ │ │ │ ↓ │ │ │ │ _eval_context (compute domain) │ │ │ │ ↓ │ │ │ │ get_request_website() │ │ │ │ ↓ │ │ │ │ request.website = None │ ← Issue │ │ │ ↓ │ │ │ │ Domain evaluation FAILS │ │ │ │ ↓ │ │ │ │ Access DENIED → 404 Error │ │ │ └──────────────────────────────────────┘ │ │ ↓ │ │ ┌──────────────────────────────────────┐ │ │ │ 2. _frontend_pre_dispatch │ │ │ │ (NEVER REACHED) │ │ │ │ ↓ │ │ │ │ request.website initialized ✓ │ ← Too Late │ │ └──────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────┘ </pre> Because `request.website` is initialized later in `_frontend_pre_dispatch`, access rules evaluated earlier in `_pre_dispatch` cannot rely on website context. As a result, record rules depending on `website_id` are evaluated before `request.website` is available, incorrectly denying access to public records. ### Fix: Avoid totally relying on `get_request_website` during access rule evaluation. Use the `request.is_frontend` attribute as a fallback, which is set earlier, to detect frontend requests and ensure correct access handling. task-[4758311](https://www.odoo.com/odoo/project/974/tasks/4758311) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**Step to reproduce:** - install "l10n_es_edi_verifactu_pos" - setup "ePOS printer" for a pos - open pos and settle a order below 400$ - notice we get l10n_es_edi_verifactu_qr_code in our receipt - click on "Print receipt" - repeat above steps for one more order **Observation:** - when we print the second order receipt, the QR still points to 1 order invoice **Issue:** - [getCacheKey](https://github.com/odoo/odoo/blob/0cee3350df09b06af77c879f0eba74bf6a8dd2c9/addons/point_of_sale/static/src/app/utils/html-to-image.js#L351C10-L355 ) was trimming query strings when generating cache keys. URLs like: ` http://localhost:9000/report/barcode/?barcode_type=QR&value=... ` were reduced to: ` http://localhost:9000/report/barcode/` - As a result, different QR code requests shared the same cache key. Subsequent requests reused the previously cached image instead of fetching a new one, producing incorrect QR codes for different orders. **Solution:** Add an `includeQueryParams` flag to `resourceToDataURL` so the full URL, including query parameters, is used as the cache key when needed. This ensures unique QR code URLs are cached and fetched correctly. opw-5455807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr