Friday, January 9, 2026
18 changes · 18.0
Enhancements to existing features
This update allows system administrators to customize the main Odoo home menu with a message. Administrators can set a configurable message through the database, such as a maintenance notification, ensuring timely communication to users. This improves internal communication and operational alerts.
Original PR description
Display a message on home menu based on an ir.config_parameter that can be added directly in the database by the system administrator.
The ir.config_parameter is sysadmin.message and should be a json loadable. The format shoud be something like this:
{
"type": "warning",
"replace": false,
"warning_type": "user",
"message": "`<span>A maintenance operation is planned on your server on <strong>2026-01-15</strong> between 14h and 15h</span>`"
}
Forward-Port-Of: odoo/enterprise#102433
Forward-Port-Of: odoo/enterprise#102239This update simplifies the process for unregistering PEPPOL accounts by allowing a default 'unregister to sender' option. Previously, users had to unlink accounts directly, which is now streamlined for better efficiency and ease of use. This change improves the overall PEPPOL integration experience.
Original PR description
Allow unregistering to sender instead of unlinking directly. task-5395262 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update strengthens Odoo's PDF/A compliance to the latest 3A standard, ensuring compatibility with critical document formats. Previously, inconsistencies in PDF libraries caused validation failures. This change includes fixes to decoding issues and adds necessary metadata for full compliance, improving document processing reliability.
Original PR description
This commit upgrades our PDF/A compliance from 3B to 3A, and fixes a few issues previously undetected due to the different PyPDF libraries we're currently supporting that made the previous PDF fails…
This commit upgrades our PDF/A compliance from 3B to 3A, and fixes a few issues previously undetected due to the different PyPDF libraries we're currently supporting that made the previous PDF fails even the 3B validation. Improvement 1: PDFA validators were previously detecting our file as 3B. Hence we update the metadata content `conformance` to `A`. Issue 2: When using `._pypdf` library, we failed the 6.1.2-2 and 6.8-1 rule even though we have implemented them on the previous version. It seems that this is caused by the `if SUBMOD...` check only ensuring it's not equal to `_pypdf2_2` (which makes it trigger for the new `_pypdf`). Hence, we reclarify the comments and fix the IF check. Issue 3: After implementing issue 2, it seems that a traceback occurs every time we're using `._pypdf` and calling the pdf write method. This is because the added characters on the header can't be decoded with `UTF-8`. Hence we change it to other greater-than-127-bytes characters that can still be decoded with `UTF-8`. (The actual character used here doesn't matter). Improvement 4: To be compliant with the new 3A rules (additional rules not there in 3B when we first implemented them), we add a minimal mark info dictionary and document structure on the PDF catalog object (`_root_object`). task-None Forward-Port-Of: odoo/odoo#234960
Resolved issues and error corrections
This update ensures that all MOA (Minimum Operating Amount) values within the French accounting module are positive integers. The changes involved rounding and adding a check to prevent negative values and removing unnecessary calculations. This corrects a potential issue impacting financial reporting accuracy.
Original PR description
All MOA fields should be positive integer. task-5380637 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239587
This update resolves an issue where Turkish invoice documents were defaulting to the wrong journal type, potentially leading to accounting errors. The default journal type has been corrected to 'purchase' to ensure accurate record-keeping and prevent misuse. This change improves the reliability of invoice processing within the Odoo system.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id
This update prevents Odoo from automatically converting the character 'B)' into the 😎 emoji. Previously, this unintended conversion could alter user input and cause confusion. This fix ensures consistent and accurate user input within the application.
Original PR description
Before this PR, typing `B)` was automatically converted into a 😎 emoji, which could unintentionally alter user input. This PR disables that conversion. task-[5221032](https://www.odoo.com/odoo/project/1519/tasks/5221032) Forward-Port-Of: odoo/odoo#242831
This update fixes a potential issue in the HTML editor's testing process. Previously, test actions could be executed multiple times due to overlapping selection updates. This change ensures that test actions are performed correctly and reliably, preventing duplicate selections and improving test accuracy.
Original PR description
The `simulateArrowKeyPress` method used in hoot tests performs both an actual `press` and modifies the selection. However, in some cases, the `press` already updates the selection because of our own listeners, which leads to a selection similar to performing the action twice. This commit avoids this by making sure the default `press` did not get prevented by our own custom listeners before modifying the selection. task-5438683
This update ensures that employee leave dates are automatically recalculated when their working schedule (calendar) changes. Previously, changes to an employee's calendar didn't update their leave entitlements, leading to potential inaccuracies. This fix maintains accurate leave balances by dynamically reflecting schedule adjustments.
Original PR description
purpose: Accepted leaves should be recomputed upon working schedule change. - made the `resource_calendar_id` change on the leave when it's changed on the corresponding employee/contract, then forced recomputation of its dates from the new resource calendar task-id: 5424312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241284
This update corrects a technical issue where the `TaxBase` element was missing from FAIA XML reports generated for Luxembourg companies with multiple product taxes. This ensures compliance with Luxembourg tax reporting requirements and prevents potential errors when submitting reports to tax authorities. The fix was triggered by a specific test case.
Original PR description
### Issue: The `TaxBase` element was missing in the generated FAIA XML, although it is required when a product line has multiple taxes ### Steps to reproduce: - Use a l10n_lu company - Create an invoice with a product line that has two taxes - Download the General Ledger → FAIA XML report - Observe that `TaxBase` is not included before the TaxBaseDescription element ### Specs & reference: FAIA v2.01 (full) XSD files: https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip opw-5360519 Forward-Port-Of: odoo/enterprise#101178
This update corrects a bug where the portal system incorrectly marked a page as viewed every time a link was sent via chatter (message or log note). Now, the system verifies if the view originated from a web browser, ensuring accurate tracking of customer portal activity. This improves data reliability for customer insights.
Original PR description
When a link to the portal is sent from the chatter via message or log note, the preview of the link triggers that the page was viewed by customer. As a solution, now we will check if it was viewed from browser with request.is_frontend opw-5237785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual issue where long product names in the combo configurator popup caused misalignment of product cards. The change ensures all product cards remain consistently aligned and sized, regardless of product name length, improving the user experience and visual consistency of the configurator.
Original PR description
Before this commit: ================= Product cards with long names caused a slight vertical misalignment in the combo configurator popup, resulting in inconsistent card sizes within the grid. After this commit: ================== Ensure all product cards remain uniformly aligned and maintain consistent dimensions in the combo configurator popup, even when product names are long. Task:5447320
This update resolves an issue where certain bank statement lines were unnecessarily granted elevated permissions (sudo). Removing these permissions improves security and reduces potential risks associated with access to sensitive financial data. This change ensures that only authorized users can access and manipulate bank statement information.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242771
This update corrects an issue where manually changed invoice currency rates were lost when the invoice date wasn't specified. Previously, Odoo automatically set the invoice date to today, triggering unnecessary recalculations and data loss. Now, the system only recomputes rates and lines if the user manually adjusts the rate, ensuring accurate currency calculations.
Original PR description
in case the user would enter manually a different rate than the default one, but does not fill the invoice date; odoo was setting today as the invoice date, which was changing the rate and recomputing all the lines... Effectively losing everything the user just encoded. So now, we only recompute the rate and the lines if the user didn't change it. Fix: https://github.com/odoo/odoo/pull/226124/changes/1b48d141d7260a262075555c4ab9cedc691d3551 Issue with Fix: Invoices posted on dates different from their creation date do not update their currency rates, even though they should. Comparing `invoice_currency_rate` to the expected rate at creation is a better guess. task-5477481 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where accepting UrbanPiper online orders in multiple POS locations resulted in multiple preparation tickets being printed. The fix ensures that a preparation ticket is only printed once, regardless of how many POS sessions are open, improving order efficiency and reducing printing costs.
Original PR description
When a POS session is open in multiple tabs/locations, accepting an UrbanPiper online order triggers multiple preparation ticket prints. Steps to reproduce: - Configure POS with UrbanPiper and a preparation printer. - Open the same POS session in multiple tabs/locations. - Receive an online food delivery order via UrbanPiper. - Accept the order in the POS terminal (TicketScreen). (Note: Order may also be auto-accepted by UrbanPiper.) Issue: - The same order printed multiple preparation tickets due to multiple active session instances. Fix: - Ensure preparation ticket prints only once when accepting (or auto-accepting) UrbanPiper orders. - Remove local order records when rejecting an online order. Task-5353283
This update removes a previous permission that allowed inventory users to change locations within the stock module. This change was deemed too risky and outside the scope of an inventory user's responsibilities. Testing confirms this change doesn't impact core functionality.
Original PR description
During the development of the task of the PR https://github.com/odoo/odoo/pull/149149, this permission was added as a possible way to fix some found problems, but that's not the way to fix them, as allowing inventory users to modify locations is something very dangerous and out of scope of what an inventory user should do. Reverting the permission, and doing manual tests with an inventory user for doing a "update quantity" or a "inventory adjustment", there's no problem, so maybe that permission was needed in a past codebase. @Tecnativa
This update resolves a technical issue in the Ecuadorian Point of Sale (POS) localization that caused a traceback when changing the selected customer. The fix ensures a customer is always selected, either a specific customer or 'Consumidor Final', improving stability and accuracy of transactions.
Original PR description
Step to reproduce: - install `l10n_ec_edi_pos` - open pos - ensure "Consumidor Final" is selected as partner - open partner list and deselect the partner Observation: - we get a traceback Cause: - we try to set a partner, without proper checks - Also, in the Ecuadorian localization there should always be a customer selected Fix: - rewrote `selectPartner` function to allow following things for EC localization 1. ensure a customer is always selected, a specific one or "consumidor final" 2. when refunding with "consumidor final" customer, changing partner is allowed opw-5350570
This update removes an unnecessary restriction that prevented users from inserting records into lists grouped by many2many fields. The change clarifies the process and ensures users can consistently add records from these grouped lists, improving usability. This resolves a previous limitation without impacting core functionality.
Original PR description
When we introduced the record-specific insertion from a list, we added a limitation on lists grouped by many2many fields but this limitation makes no sense, it only blocks the users without any clear reason. Task: 5267035
This update resolves a problem where the demo data for the Mexican payroll modules incorrectly set the company and partner names during installation. This prevented proper CFDI stamping of invoices and payment complements in demo databases, ensuring demo data is reliable for testing and demonstration.
Original PR description
The demo data of the Mexican payroll modules was overriding the company and partner name during installation, which can break the CFDI stamping flow for invoices and payment complements in demo databases.