Daily updates from Odoo
Wednesday, October 29, 2025
24 changes · 18.0
Enhancements to existing features
Swedish electronic invoices now include required reference fields and checks for national Peppol rules. This helps Swedish suppliers reduce invoice rejections and meet local e-invoicing compliance requirements.
Original PR description
Description ----------- This PR enhances the account_edi_ubl module to fully support Swedish national PEPPOL BIS Billing 3.0 validation rules (SE-R-001 to SE-R-013), which are mandated by SFTI and…
Description ----------- This PR enhances the account_edi_ubl module to fully support Swedish national PEPPOL BIS Billing 3.0 validation rules (SE-R-001 to SE-R-013), which are mandated by SFTI and enforced by Peppol Authorities. These validations are critical to ensure invoice acceptance and compliance for Swedish suppliers. Additionally, it fixes the export of two missing but required BIS3 fields: - RequisitionDocumentReference (mapped from invoice.ref) - OrderReference (mapped from invoice.invoice_origin) It also adds the required "Godkänd för F-skatt" designation for Swedish suppliers using SellerTaxRegistrationID. Technical details ----------------- - Extended `_get_partner_party_tax_scheme_vals_list` to add "Godkänd för F-skatt" to the tax scheme for Swedish suppliers. - Extended `_export_invoice_vals` to export requisition and order references. - Added detailed constraints in `_invoice_constraints_peppol_en16931_ubl` to enforce Swedish VAT number structure, organization number format and length, tax scheme requirements, VAT rates, bank account formatting, PaymentMeansCode logic, and Luhn checksum validation. - Minor refactoring of existing code for better readability and maintainability. Impact ------ These changes ensure that invoices generated for Swedish companies conform to national and Peppol standards, reducing the risk of invoice rejection and facilitating smoother e-invoicing processes. References ---------- - Swedish validation rules documentation: https://sfti.se/download/18.427140af179361c4e462cc34/1620641679827/Beskrivning%20av%20svenska%20valideringsregler%202018-11-12.pdf - PEPPOL BIS Billing 3.0 national rules: https://docs.peppol.eu/poacc/billing/3.0/bis/#national_rules
Odoo now tries to release a VoIP connection as soon as a browser tab is closed and shortens how long unused connections remain active. This helps avoid hitting provider limits on simultaneous phone registrations, reducing disruption for users who open multiple tabs.
Original PR description
Some providers like OnSIP allow for a limited number of registrations per user. This is a problem in Odoo because each tab opened creates a new registration for one hour. This commit mitigates the problems in two ways: - Sends an "unregister" request onbeforeunload to try to invalidate the registration upon closing the tab. - Reduces the TTL of registrations so that they get invalidated quicker in case the unregistration failed. Forward-Port-Of: odoo/enterprise#97963
Resolved issues and error corrections
Repair order users can no longer enter a serial number on a new repair line before that line has been saved. This prevents the serial number from disappearing when the repair order is saved, reducing data entry mistakes and rework.
Original PR description
When creating a repair order, if you add a line and assign a serial number before saving the line, the serial number is removed when saving. Steps to reproduce: - Create a repair order and save it. - Add a repair line with a product tracked by serial number. - Without saving the repair order, add a serial number on the line. - Save the repair order. - You will notice that the serial number is no longer assigned to the repair line. This PR fixes the issue by making the serial number field read-only until the repair line is saved. opw-5156267 Forward-Port-Of: odoo/odoo#232973
A test in the Project Timesheet Holidays module now uses the correct user record when checking time off that includes a public holiday. This helps keep automated validation accurate and reduces the risk of future regressions in timesheet and holiday handling.
Original PR description
In the 'test_timesheet_time_off_including_public_holiday' test case, 'employee' was mistakenly passed to 'with_user'. This commit replaces 'employee' with 'user' for consistency. task-4809916 Forward-Port-Of: odoo/odoo#233366
This fix restores a missing border on selected category items in the search panel. It improves visual clarity so users can more easily see which category is currently active.
Original PR description
This commit introduces a missing border on active category items within the search panel. task-5121027 Requires: - https://github.com/odoo/enterprise/pull/95900 | Before | After | |--------|--------| | <img width="587" height="654" alt="Capture d’écran 2025-10-28 à 10 28 49" src="https://github.com/user-attachments/assets/4c9f9292-9a18-4470-863d-35b34a3fade6" /> | <img width="494" height="645" alt="Capture d’écran 2025-10-28 à 10 28 31" src="https://github.com/user-attachments/assets/d7994472-b7ae-4518-966a-d42def9e35d5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mobile search panel now uses colors that better fit dark mode. This improves readability and visual consistency for users working in dark mode on smaller screens.
Original PR description
This commit adapts colors of search_panel for mobile in dark mode. task-5121027 Requires: - https://github.com/odoo/odoo/pull/233193 | Before | After | |--------|------------| | <img width="904" height="1022" alt="image" src="https://github.com/user-attachments/assets/9d2dd1d9-4d23-4c55-8e2d-2cb978db5f39" /> | <img width="360" height="640" alt="Capture d’écran 2025-10-28 à 10 37 46" src="https://github.com/user-attachments/assets/2b030e05-d0ad-46d9-ae7c-10593de1bb36" /> |
Generating a pricelist report no longer crashes when no pricelists have been configured. Instead, users are shown a clear message asking them to create at least one pricelist first, helping avoid confusion and support requests.
Original PR description
Description of the issue/feature this PR addresses: When generating a pricelist report, Odoo crashes if there are no configured pricelists. Current behavior before PR: The system raises an unhandled error when attempting to generate a report without any pricelist record. Desired behavior after PR is merged: If no pricelist exists, a user-friendly UserError message is shown instructing to configure at least one pricelist before generating the report. This is a backport of PR #233429 (merged in 19.0) to 18.0. Issue : https://github.com/odoo/odoo/issues/233393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an unstable automated test in the manufacturing app where timing differences could cause inconsistent results. It helps keep quality checks reliable without changing business workflows or user-facing behavior.
Original PR description
### Issue: The test `test_mrp_backorder_operations` behaves non-deterministically. It may fail at this assertion:…
### Issue: The test `test_mrp_backorder_operations` behaves non-deterministically. It may fail at this assertion: https://github.com/odoo/odoo/blob/6e37542b53f9c9ec1baf8d58b1eeca376252186f/addons/mrp/tests/test_backorder.py#L986-L989 Because the `duration` of done workorder can vary. ### Cause: The delta time between `button_start()` and `button_finish()` https://github.com/odoo/odoo/blob/6e37542b53f9c9ec1baf8d58b1eeca376252186f/addons/mrp/tests/test_backorder.py#L983-L985 `button_finish()` triggers `Productivity._close()` https://github.com/odoo/odoo/blob/6e37542b53f9c9ec1baf8d58b1eeca376252186f/addons/mrp/models/mrp_workcenter.py#L572-L576 Which sets `Productivity.duration` to 0 if delta time is zero. Consequently, `workorder.duration` also becomes zero. When `bo_2.button_mark_done()` is called, the duration is set to `duration_expected` (240 in this test), which the assertion only can pass in that case. If delta time isn't zero, then duration will also be non-zero. So it will not set to `duration_expected`. As a result the assertion will fail. runbot-233247
This fix prevents an error when regenerating payroll work entries for an employee whose contract no longer has a working schedule set. It helps payroll users complete work entry generation instead of being blocked by a system traceback after attendance-related configuration changes.
Original PR description
A traceback occurs when generating work entries for an employee whose contract has no working schedule set. steps to reproduce the error: - Install ``hr_payroll`` and ``hr_attendance`` module - Create a new Employee A - Go to Payroll > Contracts > Create a new contract > Employee: Employee A Work Entry Source: Attendances > Unset Working Schedule > Status: Running - Uninstall ``hr_attendance`` module - Go to Payroll > Work Entries > Regenerate Work Entries > Select Employee A > Regenerate Work Entries Traceback: ``` AttributeError: 'bool' object has no attribute 'upper' ``` https://github.com/odoo/odoo/blob/99a87be39c734dd2916a51bc5663162dda32a16b/addons/hr_work_entry_contract/models/hr_contract.py#L107 Here, When calendar is False and user tries to generate work entries for an employee. So, It will lead to the above traceback. sentry-6672998106,6808497160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where course slides with a "|" character in their name could cause the browser tab title to show the wrong website name after switching slides. This keeps course navigation labels consistent and avoids confusing learners.
Original PR description
How to reproduce: - Go to a course with a slide containing "|" in its name. (e.g. Basics of Gardening) - Change slide to this special named slide. - Change back to another slide. - The browser title contains the string part after the "|" instead of the website name. This commit now handles slides with name containing the "|" character. Task-5152858 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230489
Fixes incorrect and sometimes negative leave durations for India sandwich leave rules. Leave calculations now handle weekends, public holidays, hourly leave, linked leave requests, and cancellations more reliably, helping payroll and time-off balances stay accurate.
Original PR description
Before this PR, if you created a leave of a type that had sandwich leave enabled on a non-working day, it would show a negative duration. This PR fixes some issues related to sandwich leave cases…
Before this PR, if you created a leave of a type that had sandwich leave enabled on a non-working day, it would show a negative duration. This PR fixes some issues related to sandwich leave cases (where Saturday and Sunday are considered non-working days): - Friday - Monday across weekend - counted (4 days). - Hour-based leave types: weekend bridging increases hours accordingly - Public holiday in the middle (Tue-Thu with Wed PH) - counted (3 days). - Stop/Start exactly on a public holiday(Tue-Wed(Public holiday), or Wed(Public holiday)-Thu) - trimmed to 1 day. - Public holiday only - 0 days. - Two single-day leaves around a Public holiday - When the second leave is created, it bridges via a public holiday (2 days), - The first one remains 1 day if it stands alone - Mixed leave types: - If the linked leave type doesn’t have sandwich enabled, no sandwich rules. - If both leave enable sandwich (with different types) - sandwich rule applies - Refusing/canceling a linked leave must immediately adjust the other side’s duration (e.g., Monday refused - Friday drops from 3 - 1 day) Task-4430044 Co-authored-by: @mepe-odoo
Calendar events created across multiple days in week view now show the correct start and end times on each day segment. This prevents confusing 12pm or midnight times from appearing, making scheduling clearer for users.
Original PR description
When creating an event in week view spanning over multiple days, all parts of the event display 12pm as end date (except the last one) and 00am as the start date (except the first one). This fix allow calendar views to display the correct hour in week view when the event spans multiple days. task-4700158
This fixes a website editor issue where repeated undo and redo actions could duplicate the header Contact Us button or incorrectly restore a badge. The editor now avoids recording temporary internal changes during undo and redo, making page editing more reliable for users.
Original PR description
*=website Steps to Reproduce : 1. Go to `edit` mode. 2. Drop at least four block snippets. 3. Drop a badge in the header next to the _Contact Us_ button. 4. Undo twice → the _Badge_ reappears. 5.…
*=website Steps to Reproduce : 1. Go to `edit` mode. 2. Drop at least four block snippets. 3. Drop a badge in the header next to the _Contact Us_ button. 4. Undo twice → the _Badge_ reappears. 5. Undo twice more → the _Badge_ reappears again. 6. Redo three times → the _Contact Us_ button is duplicated. Issue: The `Contact Us` button in the header was duplicated after multiple undo/redo actions. Moreover, the `Badge` snippet did not behave as expected during undo/redo. Reason: When the uncommitted draft was cleared before undo/redo, the `OdooEditor` observer triggered the `OdooField` observer to roll back and flush mutations. However, this rollback was considered a new mutation by the `OdooEditor` observer. On the next undo, the `OdooField` observer tried to sync with these artificial mutations, causing duplication of buttons and badges. Fix: Deactivate the `OdooEditor` observer during undo/redo operations to prevent recording unnecessary mutations. After discarding the draft, reactivate the `OdooEditor` observer. This avoids redundant syncs and resolves the duplication issue. task-4558376 Forward-Port-Of: odoo/odoo#223579
French electronic invoices sent through Chorus Pro now place the recipient SIRET number in the required field and remove an invalid invoice attribute. This helps businesses avoid Peppol/Chorus Pro invoice rejections and aligns the service label with Chorus Pro terminology.
Original PR description
1. We didn't met one of the specific requirement of the BIS3 invoices to be sent through Chorus Pro. > The SIRET number for the final recipient, behind Chorus Pro should always be sent in the following tag: Invoice/cac:AccountingCustomerParty/PartyLegalEntity/CompanyID 2. One of the attributes of the CompanyID was set to schemeName which is not a valid attribute of the Peppol BIS3 specification. Fixed in 18.0+: https://github.com/odoo/odoo/commit/c3ae4b29c51c7b0cff11aac5f4bf4aab5fad16c9 task-none (possible opw-4972189, but might not be the only problem) Source: <img width="787" height="673" alt="image" src="https://github.com/user-attachments/assets/2a410fa8-572a-4738-aa5d-764e91271880" /> https://www.pagero.com/onboarding/aife/aife-en Forward-Port-Of: odoo/odoo#229014
This fixes Belgian payroll so public holidays during long-term sick leave are no longer incorrectly paid after the 30-day threshold. It helps ensure payslips follow Belgian payroll rules and reduces the risk of overpayment.
Original PR description
Bug: In Belgium, after 30 calendar days of sick leave, all public holidays during the sick leaves are no longer paid. But here they were still being paid. Cause: The method that was checking what to do about public holidays was never seeing public holidays since they were already changed to their corresponding work entries at the work entry generation. Fix: Add the public holidays in the context and change the condition for checking if the current leave is actually from a public holiday or not. Task: 3864585 Forward-Port-Of: odoo/enterprise#95178
Imported invoice lines now avoid linking to unrelated products when the product name is very generic or punctuation-only. This prevents incorrect product assignments during XML invoice imports while keeping existing barcode and internal reference matching unchanged.
Original PR description
The product resolver appended a fuzzy domain ('name', 'ilike', name). With XML imports this can bind unrelated products when the item name is generic or punctuation (e.g., '-' matches any name containing a hyphen, like the demo “[FURN_8999] Three-Seat Sofa”).
This is because fallback uses 'ilike' (substring match), causing false positives.
This commit replaces the fallback with a case-insensitive *exact* match: ('name', '=ilike', name). Barcode and default_code lookups are unchanged; exact case-sensitive ('name', '=', name) remains first.
Steps to reproudce:
Accounting -> Invoices
upload an XML with a product name liek `-`
See the product attched to the invoice line.
Note: When uploading the xml you'll see that the invoice lines have no product_id, just the label, here is the PR for that: https://github.com/odoo/odoo/pull/224921
opw-5046573
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUBL/CII invoice imports now create a basic product when no matching product already exists. This prevents imported invoice lines from being left as label-only entries, making invoices more complete and easier to process.
Original PR description
When importing vendor/customer invoices from UBL/CII, The invoice lines stay product less. the importer tried to resolve a product using the identifiers parsed from the XML (barcode, default_code,…
When importing vendor/customer invoices from UBL/CII, The invoice lines stay product less. the importer tried to resolve a product using the identifiers parsed from the XML (barcode, default_code, name). If nothing matched, it silently left product_id empty and produced a label-only invoice line. even though the XML commonly provides at least an item name `<cac:Item>/<cbc:Name` The root cause is that the import flow assumed a product would be found and did not attempt to create one when the lookup failed. This change makes the behavior deterministic: if no product is found, we create a minimal product.product using the values available from the XML and use it on the invoice line. As a result, imported lines carry a proper product_id instead of falling back to a label-only line, Step to reproduce: Go to accounting > invoices. Upload an XML file with `<cac:Item><cbc:Name` There is no product ID in the line id of the inoice. OPW-5003482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Event descriptions exported to external calendars now keep readable formatting and exclude hidden website content. This prevents attendees from seeing confusing unformatted text or content that was not meant to be visible.
Original PR description
**Steps to reproduce:** - Go to `Events` app - Select any event - Preview it on the website - Options are available to add to external calendars - Click on any of them - Description will be added to the exported calendar event - The description is an unformatted block of text - When using editor widgets with hidden elements, those will also appear in the export. **Issue:** The method `html_to_inner_content` doesn't take the html formatting into account, which leads to the export of the 'hidden' elements. **Fix:** Format the description like it is done for `calendar_event` with `_get_customer_description` and remove non-visible blocks (using `d-none`class) if there are any in the html of the description. opw-4923912 related : https://github.com/odoo/odoo/commit/96a76040f90c6faec6c2332c88af2e42af00663e --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Inactive guests who have not been online in the last 12 hours will no longer receive call notifications. This prevents outdated or disconnected live chat participants from being disturbed and keeps call alerts focused on active users.
Original PR description
With this commit, guests who haven't been online in the last 12 hours will not be notified of a call starting. task-5136330 backport of https://github.com/odoo/odoo/pull/230337
Managers using the attendance approval view will now see attendance records even when they have zero overtime. This ensures they can still review, manually adjust, or approve those entries instead of having them hidden by the filter.
Original PR description
Currently attendances having 0 overtime are hidden by the filter "To approve", which is weird because managers might want to manually edit them, or approve them. task-5189190
This fixes an issue where users could not save changes to an expense category cost when vendor taxes from multiple companies were configured. It helps multi-company setups manage expense categories without being blocked by an incorrect validation error.
Original PR description
Steps to reproduce: - Create 2 companies - Create a tax one each - Create an expense category - Set the 2 taxes as Vendor Taxes - Select only one of the companies - Change the cost of the expense category - Try saving --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing a customer's email address between uppercase and lowercase no longer triggers signature request emails to be sent again. This avoids duplicate messages, reduces confusion for recipients, and keeps signing communication cleaner.
Original PR description
Before this commit, when changing the partner email to uppercase or lowercase, it would resend sign requests emails for each previously sent signed request to that email. After this commit, we don't resend anymore the sign requests emails after a case sensitive email change of a partner. task-4844230
This fixes Italian electronic invoicing checks so ENASARCO taxes no longer incorrectly block invoice sending when used alongside standard withholding taxes. Businesses can submit realistic invoices with VAT, withholding, and ENASARCO while still preventing invalid tax setups during tax editing.
Original PR description
In the Italian localization, we validate that each invoice line has at most one tax per kind (VAT, withholding, pension fund). In Italy, a product cannot have more than one VAT tax. Also, the…
In the Italian localization, we validate that each invoice line has at most one tax per kind (VAT, withholding, pension fund). In Italy, a product cannot have more than one VAT tax. Also, the FatturaPA XML structure only allows global declarations for withholding and pension fund taxes — on the line level, it can only specify if those taxes apply, not which ones. To reflect this, we enforce one tax per kind per line. This validation was broken and recently fixed. However, ENASARCO is a special case: it acts both as a withholding and a pension fund tax. We added the Withholding flag recently (odoo/odoo#226968). In realistic cases (e.g., a line with VAT + withholding 23% RIT AG + ENASARCO), the validation fails and the user gets a blocking error in account.move.send. Since ENASARCO already has dedicated support through the AltriDatiGestionali tag on the line, we allow it to pass the check as if it were only a pension fund, restoring the previous behavior before we added the withholding flag. Some validation added and fields clear up in the tax editing phase, preventing invalid cases. Ticket [link](https://www.odoo.com/odoo/project.task/5154223) opw-5154223
Batch payment users now see a clear, non-blocking warning when SEPA Credit Transfer payments include partners missing required city or country details for structured addresses. This helps users correct partner records before generating XML files that would become invalid under the upcoming SEPA rules from November 2026.
Original PR description
Starting from November 15th, 2026, SEPA Credit Transfer (SCT) payments require both the partner's country and city to be defined when using structured addresses. If missing, the generated XML file will be invalid. This change adds a non-blocking red banner on the batch payment form to warn users and provide a link to review the affected partners. task-5156613 Forward-Port-Of: odoo/enterprise#97598