Monday, September 21, 2026
7 changes · 18.0
Resolved issues and error corrections
This fixes an internal HR leave test that could fail in certain future years because it depended on the current date. The change makes the test use a fixed date, improving reliability of quality checks without changing user-facing leave behavior.
Original PR description
test_no_carried_over_leaves_for_flexible_resource derives its target date from date.today(), so the window it inspects, [12/30 of next year, the 12/31 carryover date], starts on a different weekday every year. Since odoo/odoo@1e4f78a7e318a2a5195f9d94d22c094f2aabfb09, the flexible hours algorithm anchors the weekly budget on the Monday of the week containing the start of the requested range and charges hours_per_day for every day of that week preceding it. On the 40h/week, 8h/day flexible calendar of the test the 40 hours are therefore already consumed when the range starts on a Saturday: no work interval is generated and closest_allocation_duration is 0 where the test expects 2. A Sunday start gives 1. 12/30 falls on a weekend for the tests run in 2027 and 2028. Freeze the test at 2024-01-01, like the other tests of this file, so the window always falls mid-week. runbot-944214
Peppol activation now checks that the required contact email is in a valid format before proceeding. This prevents users from entering unusable email addresses and helps avoid registration or communication issues.
Original PR description
Currently, while activating peppol, we have email as a required field, but we don't validate the email format so user can enter any string for email which is invalid. This commit adds a validation for the email format by using regex for email defined in `odoo.tools`. task-6158448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Peppol activation flow now uses corrected English text. This improves the professionalism and clarity of the setup experience for English-speaking users.
Original PR description
There were some minor English mistakes on the Peppol activation wizard that might make Odoo look cheap and untrustworthy to English-speaking audiences. This commit fixes these english mistakes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents French e-invoicing test checks from failing when an optional French PDP component is not installed. It keeps automated validation aligned with the installed configuration, reducing false failures in development and release pipelines.
Original PR description
### Issue: Tests in `TestCIIFR` fail when run without `l10n_fr_pdp` installed The expected XML files contain `PMT`, `PMD` and `AAB` notes that are only generated when `l10n_fr_pdp` is installed ### Cause: The note generation for FR e-invoicing lives in `l10n_fr_pdp` When it is not installed, the notes are absent from the generated XML but still present in the expected test files When `l10n_fr_pdp` is not installed, the expected tree is stripped of `PMT`, `PMD` and `AAB` notes before comparison ### Steps to reproduce: - Install `l10n_fr_account` without `l10n_fr_pdp` - Run `TestCIIFR` from `l10n_account_edi_ubl_cii_tests/tests/test_xml_cii_fr.py` Before the fix, the affected tests fail on the `cbc:Note` comparison runbot-945999
The Guatemala electronic invoicing setup now applies fiscal positions in a consistent order. This prevents occasional incorrect tax selection on invoices and makes related invoice processing and tests more reliable.
Original PR description
Test TestGtFlow.test_gt_edi_basic_invoice nondeterministically fails, but the reported error has always the same values. Turns out the code is picking the wrong fiscal position to apply taxes on the prices of the invoice. `res.partner._get_fiscal_position()` searches auto_apply fiscal positions without explicit order, so it relies on the model's default order-by sequence. `account.fiscal.position-gt.csv` carries two records into the database without sequence number, so the order they are returned in is nondeterministic. The resultset is afterwards stable sorted (no tie-breaker between equal sequence numbers) and filtered, so the wrong/unexpected tax can be applied randomly. Explicit sequence numbers are added to account.fiscal.position-gt.csv so the fiscal positions are always returned in-order (domestic first). This approach matches the convention of the other fiscal-position CSVs. runbot-945738
Fiscal positions with the same priority will now be evaluated in a stable order. This prevents inconsistent tax or accounting rule selection after data imports where sequence values are duplicated.
Original PR description
The algorithm to find the right fiscal position works on top of deterministically ordered fiscal position records. This invariant is not enforced by the functional code. Importing data without explicit sequence number results in multiple records ending up with the same value in this column. Sorting by column 'sequence' is not good enough to have repetitive results in this case. The fiscal position algorithm can return a different record due to database implementation details. Adding field "id" to the default ordering ensures the order of fiscal position records remains deterministic. This is because insertion order is preserved and locked into order-preserving id-values when importing data. runbot-945738
This fix improves logging when the French PDP integration receives an unsupported lifecycle status. Instead of showing an empty value, the system now records the actual status code, making investigations and support easier.
Original PR description
Currently we just log `None` in case we receive a lifecycle with an unsupported (on community side) status. After this commit we log the status code at least. task-None before fix <img width="711" height="120" alt="image" src="https://github.com/user-attachments/assets/1f939cf4-17b7-49cb-8b31-5cc594fdeadd" /> after fix <img width="700" height="116" alt="image" src="https://github.com/user-attachments/assets/1b8b3853-f2da-4426-9c49-1d135d1c7824" /> Forward-Port-Of: odoo/odoo#286429