Friday, January 9, 2026
15 changes · 18.0
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.