Daily updates from Odoo
Friday, January 16, 2026
168 changes
15 changes
Enhancements to existing features
This update makes the 'Open Cashbox' button in the Point of Sale (PoS) interface more visible and user-friendly. The change is a small UI adjustment that enhances the overall customer experience. This improves ease of use for cash-based transactions.
Original PR description
Little UI changes on the Open Cashbox button in the PoS. task: 5441682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243224
This update clarifies the labels and settings related to Peppol reception within Odoo Enterprise. It adjusts requirements based on a company's Peppol participation role and prevents unnecessary fields from being required for companies only sending data. This ensures smoother integration with Peppol networks.
Original PR description
In this commit: Clarify Peppol reception mode labels to better reflect actual behavior. Update Settings field requirements based on the Peppol participation role. Prevent document-related fields from being required when the company is configured as sending-only. Task-5438539 Co-authored: [Soham Zadafiya (soza)](soza@odoo.com) Forward-Port-Of: odoo/enterprise#104430
Resolved issues and error corrections
This update resolves an issue where our automated testing for online typing status was unreliable due to how the tests simulated time. The fix ensures the tests accurately reflect real-time typing behavior, preventing intermittent test failures and improving the stability of our system. This primarily impacts the reliability of our internal testing processes.
Original PR description
Backport of odoo/odoo#243138 Before this commit, the following discuss typing HOOT tests were failing non-deterministically: ``` [text composer] other member typing status "is typing" refreshes of…
Backport of odoo/odoo#243138
Before this commit, the following discuss typing HOOT tests were failing non-deterministically:
```
[text composer] other member typing status "is typing" refreshes of assuming no longer typing
other member typing status "is typing" refreshes of assuming no longer typing
```
This happens because these tests advance time for 10 to 60 seconds to assert presence of "Demo is typing..." text. The text relies on 2 asynchonous pieces of code:
1. a bus notification that the server returns `is_typing_dt` when someone explicitly notifies start or stop typing
2. a client-side internal timeout `typingTimeoutId` for long typing of more than 60 seconds (it expects receiving a is_typing: true in the mean time if the member is still actually typing)
The test had no control over these 2 asynchronous pieces of code. This is a problem because HOOT tests show extreme condition where bus notifications come much later than RPC returns, and also simulation of passing of time with `advanceTime()` acts as a jump to the future and consumes all registered timeouts.
The bus notification problem can mistakenly have it consumed way later than a long typing with simulated advanced time of test. This commit fixes the issue by awaiting the notification `notify_typing`.
`advanceTime()` that jumps to future and consumes timeout can mistakenly register and consume timeouts in the wrong order. We can't know for sure when the timeout is consumed so we cannot reliably provide a specific value to `advanceTime()`. This commit fixes it by patching a dedicated function that registers the timeout, so that the test can patch and asynchronously step when the long typing timeout is registered, also ensuring proper awaiting to simulate advance of time in a reliable way.
This commit also fixes an issue with recent PR [1] were `Demo is typing... { count: 0 }` were mistakenly turned into `Demo is typing...`. Diff in PR was big so some mistakes were expected!
Fixes runbot-error-237516
[1]: https://github.com/odoo/odoo/pull/238887This update fixes a scheduling issue in the autovacuum cron job that was causing delays in database maintenance. The change ensures the cron job correctly reports partial progress, allowing for quicker rescheduling and preventing tasks from being delayed for an entire day. The code was also simplified for better readability.
Original PR description
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have…
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have a ir cron action with the following code: time.sleep(MIN_TIME_PER_JOB) self.env['ir.cron']._commit_progress(remaining=1) return The code looks stupid, but we tracked down a bug we had in the autovacuum cron in 18.3, and the minimum code to reproduce the problem is that above line of code. Since there are remaining stuff to do, the cron worker should report a `PARTIALLY_DONE` status, and reschedule to call the cron action asap. But the system currently determine a `FULLY_DONE` status and reschedule the cron action *later* (next day for a cron with an interval of 1 day). It is pretty bad for the autovacuum cron in 18.3 We used the opportunity to rework the `status` computation to one big match-case, for extra readability. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216116
This update resolves an issue preventing non-administrator users from archiving channels. By using `sudo`, users can now archive channels without needing specific permissions, improving channel management flexibility. This change enhances user experience and simplifies channel organization.
Original PR description
**Purpose of this PR:-** Allow users to archive channels using `sudo` so the action is not blocked by missing discuss role access error. task-5478832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor issue within the Point of Sale (POS) testing process. Specifically, it ensures that a key step – verifying the existence of at least one paid order – is completed before the automated tour ends. This prevents potential errors and ensures the tour runs smoothly, providing a more reliable testing experience.
Original PR description
By adding a last step ( that check that there is at least one paid order), we ensure that the RPC is done before closing the tour. error-runbot-id~233511 error-runbot-id~232677 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243815
This update resolves issues with the Knowledge editor, specifically preventing problems when copying and pasting headings and improving the responsiveness of the heading link button. The changes ensure consistent URL redirection and a smoother user experience when editing knowledge articles.
Original PR description
### [FIX] knowledge: prevent heading link id duplication on copy/paste Prior to this commit, copy/pasting a heading would preserve its `data-heading-link-id` resulting in mismatches for URL redirections. After this commit, such ids are always reset to guarantee unicity. ### [FIX] knowledge: throttle mousemove for heading link button Prior to this commit, every `mousemove` event could cause a layout trashing to reposition the heading link button. After this commit, the repositioning is debounced at a more reasonable rate. task-5384684 Forward-Port-Of: odoo/enterprise#104460 Forward-Port-Of: odoo/enterprise#101445
This update fixes an issue where numbers extracted from OCR boxes were incorrectly formatted due to language-specific decimal separator handling. The change simplifies the parsing process by consistently using a standard Javascript `Number` parser, ensuring accurate number representation regardless of the user's language settings. This improves data integrity for financial and reporting processes.
Original PR description
When using a language that doesn't use a dot as decimal separator, the number parsed from the box content was incorrect. For example, if the content of the box was "1234.56", the parsed value would have been "123456". This happened because the float parser available through the registry takes into account the language of the user and its configured thousands/decimal separators. Since the content of the boxes are always formatted as "1234.56", without thousands separator and with a dot as decimal separator, the regular `Number` parser of Javascript can be used to get consistent results. opw-[5427979](https://www.odoo.com/odoo/49/tasks/5427979) Forward-Port-Of: odoo/enterprise#104467
This update corrects a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian currency (BGN). Now, it's correctly linked to the Euro (EUR) to reflect Bulgaria's adoption of the Euro as its official currency on January 1, 2026. This ensures accurate financial reporting and data for users operating in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update fixes a usability issue in the Sign editor where the document dropdown didn't close correctly after selection. The fix adds a click listener to the PDF iframe to manage dropdown interactions, ensuring a smoother user experience. It also includes styling updates for consistency and clarity.
Original PR description
- Fix hover and pointer behavior on update document action - Apply consistent danger styling to delete action - Ensure dropdown closes correctly after interaction (PDF iframe has its own document so outside-click logic did not apply; add a click listener on the iframe document to close open dropdowns. ) task: 5384677 Forward-Port-Of: odoo/enterprise#102447
This update fixes an issue where right-clicking on links within messages was obscured by extra message actions. Now, users will see the standard browser context menu options like 'Open Link' and 'Copy Link' when right-clicking on a link, providing a smoother and more intuitive experience.
Original PR description
Before this commit, when right-clicking on a link in a message body, this was showing the list of message actions in dropdown. This is a problem because right-click on link has features like "Open link" / "Copy link" and so on. They were over-shadowed by the right-click on message for showing of message actions. This commit prevent the showing of message actions in dropdown from right-click in links in message body, so that the browser context menu is open instead in that scenario, showing features like "Open link" and "Copy link".
This update fixes a technical issue that caused tracebacks when a member typed in group chats with multiple users. The fix restricts the display of typing indicators to direct messages (DMs) only, aligning with the expected behavior of group chats. This ensures a smoother user experience for all Odoo users.
Original PR description
Before this commit, when another member of a group chat with more than 2 members was typing it would result in a traceback. Steps to reproduce: 1. Have `hr_homeworking` and/or `hr_holidays` installed 2. Create group chat with 2 other users 3. Open said group chat 4. Have another member start typing -> traceback This happens because since [1] the condition to show the `ImStatus` component became `showImStatus`, which is true in group chats when another member is typing. However since group chats with more than 2 members have no correspondent, this leads to the `ImStatus` component having no `persona` attribute, which in turn causes a crashes in templates without a guard on `persona` access. This commit fixes the issue by making `showImStatus` only true in DMs, since it's not expected for group chats to have a correspondent and hence an IM status should not be shown. [1]: https://github.com/odoo/odoo/pull/234715
This update fixes a bug that prevented read-only accounting users from seeing the 'Customer Statement' button when viewing a customer record. The issue stemmed from a restriction in the system's access controls, which was unintentionally limiting access for read-only users. This change ensures all users with accounting rights can access this important feature.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103715 Forward-Port-Of: odoo/enterprise#102683
This update fixes an issue where invalid warehouse addresses caused continuous geolocation requests to OpenStreetMap. Now, when a location's coordinates cannot be determined, the system sets default coordinates, preventing further attempts and improving location accuracy for warehouse listings. This enhances the user experience and data reliability.
Original PR description
When a warehouse location had no coordinates, a request to geolocate the address was made to OpenStreetMap every time the location selector was open. However, when the address was invalid, the geolocation failed, and no coordinates were set, which caused further geolocation requests being continuously sent. This commit changes the geolocation behavior to set invalid coordinates for the address when the request fails, thus disabling future geolocation attempts for that address. Forward-Port-Of: odoo/odoo#243523
This update resolves a potential error in how accounting calculations handle specific scenarios, particularly when all factors are zero. The change ensures the system correctly distributes remaining amounts, preventing tracebacks and maintaining accurate financial reporting. This improves the stability and reliability of the accounting module.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616
6 changes
Resolved issues and error corrections
This update fixes a display issue where tax names and invoice labels were shown in English for Vietnamese users. By adding the necessary Vietnamese translations to the chart template CSV, users will now see these labels in Vietnamese, improving the user experience for Vietnamese-speaking businesses using Odoo.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242437 Forward-Port-Of: odoo/odoo#236502
This update fixes an issue where the link popover remained open after a snippet was removed from the website. The change ensures the popover closes automatically when a snippet is deleted, improving the user experience and preventing visual clutter. This resolves a minor usability problem.
Original PR description
Description of the issue this PR addresses:
- When removing a snippet, the link popover stayed open because its `pointerdown` handler didn’t trigger, leaving the popover visible even after its selected content element was removed.
- A previous fix used { capture: true } on the document `pointerdown` listener, but this also triggered when interacting with the link type `dropdown` and color picker, closing the popover triggers `applyCallback` and causing nested links to be created.
After this commit:
- Close the link popover from `on_will_remove_handlers` before the target element is removed from the DOM.
- This ensures the popover closes when removing the snippet.
task-5359000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where the 'Other Input' section of the Payroll app incorrectly displayed trailing zeros for negative salary attachment counts. The fix adjusts a widget to properly handle negative values, ensuring accurate reporting of attachment numbers. This improves the clarity and reliability of payroll data.
Original PR description
Steps to Reproduce: - install Payroll app - create an employee and create a salary attachment. - check the negative value for salary attachment - generate a payslip Issue: - In "Other Input" section, salary attachment count displays value with trailing decimal zeros for negative amounts. Reason: - The field is using the widget float_without_trailing_zeros which should remove the extra decimal zeros but it doesn't work when the value is negative. Solution: - Fix the regular expression in the float_without_trailing_zeros widget to handle negative values and properly remove trailing decimal zeros. task-5477466
This update corrects a data inconsistency in Odoo, ensuring Bulgaria's currency is accurately listed as EUR. As Bulgaria transitions to using the Euro on January 1, 2026, this change aligns Odoo's data with the latest official currency information. This ensures accurate reporting and financial processes related to Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update resolves a technical issue causing tracebacks when generating the Follow-up Report in Partner Ledger. It ensures that general accounting entries are automatically set to 'no_followup', streamlining reporting. Importantly, payments from Point of Sale (POS) systems are still included in follow-up reports.
Original PR description
* Fix traceback when opening the follow-up report and customer statement. * General(MISC) entries should be no_followup by default. Except entries coming from pos should not be excluded from follow-ups. Forward-Port-Of: odoo/enterprise#104500 Forward-Port-Of: odoo/enterprise#104433
This update resolves an issue where rapid receipt printing via USB printers occasionally caused errors. The fix ensures only one thread can access the printer at a time, preventing conflicts and guaranteeing reliable printing performance. This improves the overall stability of the receipt printing process.
Original PR description
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS…
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status ERROR ? root: Could not set configuration: [Errno 16] Resource busy ``` This would cause `python-escpos` to be disabled and fallback to just CUPS printing. The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways: - IoT thread with `python-escpos` and CUPS try to access the printer at the same time. - Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time). Both of these scenarios should now prevented: - Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it. - We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time. task-5490942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
9 changes
Resolved issues and error corrections
This update fixes an issue where placeholder hint text in the HTML editor would wrap awkwardly onto multiple lines when the screen was narrow. Now, the text is correctly truncated when space is limited, ensuring a cleaner and more consistent user experience across different screen sizes. This improves readability and visual appeal.
Original PR description
Description of the issue this PR addresses: - The placeholder hint text wraps onto multiple lines when the cell width is reduced. - When there is insufficient horizontal space, the text should be truncated rather than wrapped. task-5480080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243603 Forward-Port-Of: odoo/odoo#243006
This update corrects a technical issue that caused tracebacks when generating the Follow-up Report, specifically related to how customer statements were processed. It now ensures that General entries are automatically set to 'no_followup', with an exception for payments originating from Point of Sale (POS) systems. This improves report stability and accuracy.
Original PR description
* Fix traceback when opening the follow-up report and customer statement. * General(MISC) entries should be no_followup by default. Except entries coming from pos should not be excluded from follow-ups. Forward-Port-Of: odoo/enterprise#104433
This update removes an unnecessary warning related to credit notes from the GSTR report. Previously, the warning interfered with credit note processing, particularly when a credit note was confirmed after an invoice. Now, the warning is automatically cleared when the credit note is fully posted and checked.
Original PR description
This **PR** removes the credit note warning from the GSTR report, as it is not required at the report level. Additionally, when this warning is present on an invoice and the credit note is confirmed, the credit note is set to not checked. The warning will only be cleared once the credit note is posted and checked task-5469000 Forward-Port-Of: odoo/enterprise#104518 Forward-Port-Of: odoo/enterprise#102106
This update corrects a technical issue that was causing error messages when using Razorpay payment processing within the Point of Sale (POS) system. The fix removes a problematic attempt to access sudo functionality, which wasn't applicable to the Razorpay payment request object. This ensures smoother and more reliable payment processing for Indian users.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634 Forward-Port-Of: odoo/odoo#244177
A bug was causing overdue invoices to appear twice in PDF follow-up reports. This update corrects a technical issue within the invoicing process, ensuring invoices are printed only once in these reports. This improves the accuracy and clarity of follow-up reminders for customers.
Original PR description
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this…
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this Partner then in the "Accounting" sheet, - Choose follow-up as manual, - Click on send, - In the wizard select Print and "Join invoices" ### Current behavior: The PDF display the reminder, the invoice, the report and the invoice again. ### Expected behavior: Invoice should appear only once in the follow-up PDF. ### Cause : When manually sending the follow-up, the wizard attaches the invoices to the follow-up. Then in `_get_followup_attachments`, it attaches the report, template attachments and the invoices again. In a manual follow up, it should be possible to choose which invoices are sent. The method `_get_invoices_to_print` ensure this by looking at the options' attachment. Therefore, it's not possible to clear the attachment field before fetching the invoices. opw-5368870 Forward-Port-Of: odoo/enterprise#102516
This update resolves an issue preventing stable IoT Box responses from being correctly read. By adding a check for a 'result' key in the data, the system now reliably processes data from these terminals, ensuring consistent and accurate reporting. This improves the overall stability and functionality of the IoT integration.
Original PR description
We now read data in result key if it exists to ensure readability of stable IoT Box responses. Forward-Port-Of: odoo/enterprise#104360 Forward-Port-Of: odoo/enterprise#104113
This update corrects a data inconsistency in Odoo, reflecting Bulgaria's recent adoption of the Euro as its official currency. Previously, Bulgaria was linked to the Bulgarian Lev (BGN). Now, it's correctly associated with the Euro (EUR), ensuring accurate financial reporting and data processing for transactions in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update ensures that manually set currency rates on customer invoices (especially in German and Hungarian) are correctly applied during the invoice posting process. Previously, the system automatically replaced these rates with standard exchange rates, leading to potential inaccuracies. This fix maintains the user's intended rate, improving invoice accuracy and financial reporting.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update resolves a potential error in the accounting module that could occur when calculating tax adjustments. The change ensures the system handles the scenario where all factors are zero, preventing a traceback and maintaining accurate financial calculations. This improves system stability and reliability.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616
5 changes
Resolved issues and error corrections
This update fixes an issue where sorting of picking records was not functioning correctly due to a technical detail in how Odoo compares related data. The change ensures that picking records are sorted accurately, improving the reliability of inventory management processes. This resolves a potential inconsistency in how the system identifies and orders related records.
Original PR description
Ordering recordset based on relationnal field should always take the relational field's `.id` instead of the field itself. This is due to the BaseModel `__gt__` override comparing if a set is included into another and not if the `id` is bigger that the other `id`. runbot : 237512
This update resolves a technical issue that was causing an error message during Razorpay payment processing within the Point of Sale (POS) system. The fix removes an unnecessary attempt to use 'sudo' on a specific object, ensuring smooth and reliable payment transactions for Indian users.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634 Forward-Port-Of: odoo/odoo#244177
This update ensures that manually set currency rates on customer invoices (especially in German and Hungarian) are correctly applied during the invoice posting process. Previously, the system automatically replaced these rates with standard currency rates, leading to potential inaccuracies. This fix maintains the user's intended rate, improving invoice accuracy and financial reporting.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update corrects a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian currency (BGN). Now, it’s correctly linked to the Euro (EUR) reflecting Bulgaria’s adoption of the Euro as its official currency on January 1, 2026. This ensures accurate financial reporting and data for transactions involving Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update corrects a bug where overdue invoices were printed twice in follow-up PDF reports. The issue stemmed from how the system attached invoices during manual follow-up creation. Now, invoices appear only once in the generated PDF, ensuring accurate reporting and reducing potential confusion for users.
Original PR description
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this…
### Issue: In a manual follow-up printed as PDF, overdue invoices appear twice. ### Step to reproduce: - Create a partner and an overdue invoice for this partner, - Send the invoice, - go to this Partner then in the "Accounting" sheet, - Choose follow-up as manual, - Click on send, - In the wizard select Print and "Join invoices" ### Current behavior: The PDF display the reminder, the invoice, the report and the invoice again. ### Expected behavior: Invoice should appear only once in the follow-up PDF. ### Cause : When manually sending the follow-up, the wizard attaches the invoices to the follow-up. Then in `_get_followup_attachments`, it attaches the report, template attachments and the invoices again. In a manual follow up, it should be possible to choose which invoices are sent. The method `_get_invoices_to_print` ensure this by looking at the options' attachment. Therefore, it's not possible to clear the attachment field before fetching the invoices. opw-5368870 Forward-Port-Of: odoo/enterprise#102516
4 changes
Resolved issues and error corrections
This update fixes a visual inconsistency in the Odoo Enterprise application. Previously, the subtitle color within the 'Recent' tab didn't match the colors applied to other tabs. This change ensures a uniform and professional appearance across all tabs, improving user experience.
Original PR description
Since commit [1], the subtitle color has been changed but not for the "Recent" tab, which creates inconsistencies. This commit ensures that the subtitle color is consistent across all tabs. [1]: https://github.com/odoo/enterprise/commit/568d29af1e1d792642f0dc288d57871fc7781f38 task-5485493 | Before | After | |--------|--------| | <img width="800" height="662" alt="Capture d’écran 2026-01-12 à 11 19 34" src="https://github.com/user-attachments/assets/8beb175a-27c8-4d73-899c-6fc3ab22c0e6" /> | <img width="800" height="657" alt="Capture d’écran 2026-01-12 à 11 19 49" src="https://github.com/user-attachments/assets/e2542822-6b05-4b15-b3e8-a4aa7c1b611c" /> | Forward-Port-Of: odoo/enterprise#104206 Forward-Port-Of: odoo/enterprise#103996
This update ensures that product attributes are correctly displayed on refund orders and receipts. Previously, attributes were lost during the refund process. The fix correctly transfers attribute data from the original order to the new refund order, improving accuracy and reporting.
Original PR description
**Steps to reproduce:** - Make an order with a product that has variants and chose whatever in the popup - Pay for that order, then refund it - The attribute is not shown on the orderline anymore - The attribute is not shown on the receipt either **Why the fix:** When making a refund, we are actually making a new order, so we need to move the data from the old order to the new refund order. During this transit, the *attribute_value_ids* was forgotten on the moving lines, so the attributes were lost. We now give the old attributes to the new line. opw-5393332 Forward-Port-Of: odoo/odoo#243589 Forward-Port-Of: odoo/odoo#240602
This update corrects a potential error in how the system identifies location relationships. Previously, matching location IDs could incorrectly identify unrelated locations as sublocations, leading to test failures. This fix replaces a method that was susceptible to ID alignment issues with a more reliable approach, ensuring accurate location identification and preventing test failures.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update resolves a recurring issue that caused random errors during Odoo's tour process. By removing problematic assertions, the tour is now more reliable and stable, leading to a smoother user experience. This change focuses on internal improvements to the Odoo system.
Original PR description
With this commit, we remove synchrone assertions in steps that can cause random errors in tour. runbot-error-id~237552 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
20 changes
Enhancements to existing features
This update clarifies the labels and settings related to Peppol reception within Odoo Enterprise. It adjusts requirements based on a company's Peppol participation role and prevents unnecessary fields from being required for sending-only companies. This ensures more accurate and streamlined Peppol data handling.
Original PR description
In this commit: Clarify Peppol reception mode labels to better reflect actual behavior. Update Settings field requirements based on the Peppol participation role. Prevent document-related fields from being required when the company is configured as sending-only. Task-5438539 Co-authored: [Soham Zadafiya (soza)](soza@odoo.com)
Resolved issues and error corrections
This update fixes an issue where website location requests repeatedly failed for invalid warehouse addresses. Now, when geolocation fails for an address, it sets default coordinates, preventing endless attempts and improving the user experience. This ensures accurate location data is displayed on the website.
Original PR description
When a warehouse location had no coordinates, a request to geolocate the address was made to OpenStreetMap every time the location selector was open. However, when the address was invalid, the geolocation failed, and no coordinates were set, which caused further geolocation requests being continuously sent. This commit changes the geolocation behavior to set invalid coordinates for the address when the request fails, thus disabling future geolocation attempts for that address.
This update fixes a display issue in the Point of Sale product information popup. Previously, it only showed the first tax applied to a product. Now, it correctly displays all taxes, separated by commas, providing a more accurate and complete view for sales transactions.
Original PR description
Before this commit: --- - The POS product info popup displayed only the first tax from `tax_details`, which meant multiple applied taxes were not visible. - The logic fetched a single tax name instead of all tax applied to the product. After this commit: --- - The POS store sends a full list of tax names instead of a single name. - The popup template displays all tax names, comma-separated. task-5406826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem in the payroll testing process where contract end dates weren't being calculated correctly. The fix ensures contracts automatically end after two years, aligning with standard payroll practices. This improves the reliability of payroll calculations and reporting.
Original PR description
### Cause: Apparently the contract ends automatically after a period if `contract_date_end == False` ### Solution: Set `contract_end_date` to ` Date.today() + relativedelta(years=2)` like in `hr_payroll/tests/common.py` error-237945
This update resolves a technical issue that was preventing the generation of follow-up reports for certain customer records. It now automatically sets ‘no_followup’ for general customer entries, ensuring accurate reporting. This change improves the reliability of customer statement and follow-up report generation.
Original PR description
* Fix traceback when opening the follow-up report and customer statement. * General(MISC) entries should be no_followup by default. Except entries coming from pos should not be excluded from follow-ups. Forward-Port-Of: odoo/enterprise#104500 Forward-Port-Of: odoo/enterprise#104433
This update removes a feature that allowed users to directly open folders from the sync configuration list. This change simplifies the process of selecting and editing configuration rows, leading to a more user-friendly experience. The removal addresses a usability issue that was causing confusion.
Original PR description
Previously, clicking a folder in the sync configuration list redirected the user to the folder view, which made it difficult to select or edit the configuration row. To improve usability, the ability to open folders directly from `documents_account.documents_folder_setting_view_list` has been removed. task-5212503
This update prevents notifications for other recipients from being incorrectly marked as 'bounced' when a single bounce notification is received. The fix addresses a technical issue where an outdated search domain incorrectly matched all notifications linked to a message, leading to inaccurate bounce reporting. This ensures more reliable notification tracking.
Original PR description
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an…
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an incoming mail server with a bounce alias. 2. Create multiple contacts with different email addresses. 3. Send a message that notifies multiple contacts. 4. Process a bounce email related to only one recipient. 5. Observe that notifications for other recipients of the same message are also marked as “bounced”. Root Cause: During bounce processing, `MailThread._routing_handle_bounce` builds a search domain to identify which `mail.notification` records should be updated. The original implementation constructed an `OR` domain that could include empty domain elements (`[]`) when some bounce identification data was missing. In Odoo’s domain logic, an empty domain represents a constant “match all” condition. When such a domain is included in an `OR`, the entire expression can match all notifications linked to the message, rather than only those related to the bounced recipient. Fix: The domain used to select bounced notifications is now built dynamically. Criteria are only added when the corresponding bounce identification data is present. opw-5349170
This update ensures that Odoo accurately flags modules imported with demo data. This improvement will enhance the reliability of industry testing by providing clearer information about which modules were initially populated with demo content. It resolves a previous oversight that impacted testing processes.
Original PR description
Currently even if a imported module was imported with demo data, the 'demo' field is not set to True. Setting this field proprely will allow to have a better handling of demo data in industry tests. Backport of https://github.com/odoo/odoo/pull/243032
This update resolves an issue where a deleted floor would reappear in the floor selector after a refund was processed on a related order. The fix filters out inactive floors, ensuring the floor selector accurately reflects available tables and improving the user experience. This prevents confusion and ensures data consistency.
Original PR description
Task: [#5421683](https://www.odoo.com/odoo/project/1737/tasks/5421683) --- **Steps to reproduce:** * Create a new floor with one table * Create and pay an order on that table * Delete the floor * Refund one line of the order ==> The deleted floor is shown again in the floor selector, without its table. This happens because the deleted floor is loaded when fetching the table of the order in the Ticket Screen. If an order is linked to a table that belonged to a deleted floor, that floor is loaded again and displayed in the floor selector. **Fix:** Filter out inactive floors from the floor selector.
This update resolves an issue where users received an error when attempting to unbuild tracked components in a manufacturing order. The fix ensures that component serial numbers are not reused, preventing validation errors and ensuring accurate inventory tracking. This improves the reliability of the manufacturing process.
Original PR description
Steps to reproduce the bug: - Create a storable product P1 - Tracking: Serial Number - BoM: Component: 1 unit of C1, tracked by Serial Number - Update the inventory of C1 - 1 unit with SN1 - 1 unit…
Steps to reproduce the bug:
- Create a storable product P1
- Tracking: Serial Number
- BoM: Component: 1 unit of C1, tracked by Serial Number
- Update the inventory of C1
- 1 unit with SN1
- 1 unit with SN2
- Create a Manufacturing Order to produce 2 units of P1
- Confirm and validate the MO using serials SN1-P1 and SN2-P1
- SN1 and SN2 of C1 are consumed
- Unbuild 1 unit of P1 with serial SN1-P1 Result: SN1 of C1 is correctly restored
- Unbuild 1 unit of P1 with serial SN2-P1
- Try to validate the unbuild
Problem:
A user error is raised:
"The serial number SN1 has already been assigned"
This happens because _action_unbuild attempts to reuse the same component serial number (SN1 of C1) without checking whether it has already been consumed by a previous unbuild operation on the same Manufacturing Order.
Solution:
This fix ensures that, when unbuilding tracked products, component serial numbers already used by previous unbuilds of the same MO are excluded from the candidate move lines.
This prevents reassigning the same serial number multiple times and avoids the validation error.
opw-5441256This update resolves an issue where Point of Sale orders with custom sequence prefixes were generating errors due to data type mismatches. The fix ensures that sequence numbers, including custom prefixes, are correctly stored and used, preventing order processing failures. This improves the stability and reliability of the POS system.
Original PR description
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with config number 1 active and make a purchase - A traceback appears saying that we can't convert the sequence to an Integer **Why the fix:** Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number. To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose. This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name. opw-5386575
This update fixes a problem where customers couldn't change product selections in the Point of Sale configurator when multiple attribute combinations were restricted. The issue was previously resolved but reintroduced. The fix removes code that incorrectly disabled options, allowing customers to freely select their desired product combinations.
Original PR description
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. (ex: a1v1 excludes a2v2 and a1v2 excludes a2v1) - Open PoS and try to add the product to the cart. - The configurator popup will appear. Observation: - You will not be able to change the selection because the other combinations are not correct. Cause: - The issue was already fixed [1] but issue was reintroduced in [2] Fix: - Remove the code, which was causing the issue, we shouldn't disable an option and allow customer to change the combiantion [1] https://github.com/odoo/odoo/commit/5864780ed703f61d763e1b49c33da3bbf8ca32f2 [2] https://github.com/odoo/odoo/commit/6e7c663543ba2b219d492795971f42e3e2c1213e opw-5418977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where cash order creation was missing essential information like company and user details. Previously, orders weren't properly linked, leading to potential data discrepancies. This change ensures cash orders are created with accurate context, improving order tracking and reporting within the Point of Sale system.
Original PR description
Before this commit, the order for cash moves was created without setting the session_id, company_id, and user_id fields. opw-5500966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a scheduling issue in the autovacuum cron job that was causing delays in database maintenance. The change ensures the cron job correctly reports partial progress, triggering a faster reschedule. Additionally, the code has been simplified for better readability.
Original PR description
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have…
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have a ir cron action with the following code: time.sleep(MIN_TIME_PER_JOB) self.env['ir.cron']._commit_progress(remaining=1) return The code looks stupid, but we tracked down a bug we had in the autovacuum cron in 18.3, and the minimum code to reproduce the problem is that above line of code. Since there are remaining stuff to do, the cron worker should report a `PARTIALLY_DONE` status, and reschedule to call the cron action asap. But the system currently determine a `FULLY_DONE` status and reschedule the cron action *later* (next day for a cron with an interval of 1 day). It is pretty bad for the autovacuum cron in 18.3 We used the opportunity to rework the `status` computation to one big match-case, for extra readability. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216116
This update fixes a display issue where tax names and invoice labels were shown in English for Vietnamese users. By adding the necessary Vietnamese translation columns to the chart template CSV, the system now correctly displays tax information in Vietnamese, improving the user experience for Vietnamese-speaking businesses.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242437 Forward-Port-Of: odoo/odoo#236502
This update fixes a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian currency (BGN). Now, it’s correctly linked to the Euro (EUR) to reflect Bulgaria’s adoption of the Euro as its official currency on January 1, 2026. This ensures accurate financial reporting and data for businesses operating in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update corrects an issue where payslip names were not being generated accurately for the Swiss (l10n_ch_hr_payroll) version of Odoo. The fix ensures that payslip names are now correctly formatted and displayed, improving the accuracy of payroll reports and data.
Original PR description
Forward-Port-Of: odoo/enterprise#104289
This update ensures that newly created General(MISC) entries in Odoo automatically have 'no followup' enabled. This simplifies reporting and reduces the risk of unnecessary follow-up actions for these types of transactions, improving data clarity and efficiency.
Original PR description
General(MISC) entries should be no_followup by default. task-5489772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where a project was automatically created when ordering 0 units of a prepaid service product within a quotation. The change ensures that projects are only generated when a valid quantity of the service is ordered, streamlining the invoicing process and preventing unnecessary project creation. This resolves an issue reported by users.
Original PR description
--- ## Short functional explanation of the error Let's say we have a prepaid service as a product, generating a project upon order. When we order 0 units of this product as an optional product, a project is still created. ## Reproduction Steps 1. Create a product of type Service. Set Project in the field Create On Order. Set the Invoicing Policy at Prepaid. 2. Create a quotation containing an optional product with 0 units of this service and click on confirm. ### Expected behavior The quotation is confirmed, but no project is created. ### Unexpected behavior A project linked to the product and the quotation is created. ## Origin of the issue When creating projects linked to order lines, we don't check if such projects are linked to optional products. opw-5406118
This update resolves a potential error in the accounting module that could occur when calculating tax distributions. The change ensures the system handles the rare scenario where all factors are zero, preventing a traceback and maintaining accurate calculations. This improves stability and reliability of financial transactions.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616
7 changes
Enhancements to existing features
This update enhances the testing process for invoice payments, specifically when using bank statement lines. A new test helper has been introduced to streamline and standardize these tests, ensuring more reliable payment processing scenarios. This improves the overall accuracy and stability of invoice payments.
Resolved issues and error corrections
This update resolves an issue where posting a tax return variant (like the Generic Tax Report) didn't consistently post its related grouped variant (e.g., Account > Tax). The fix ensures that both variants are properly processed when a closing entry is initiated, improving the reliability of tax reporting.
Original PR description
## Issue: When closing the entry for one tax return variant (e.g., the Generic Tax Report), the grouped variant (e.g., Account > Tax or Tax > Account) remains in draft, even though both variants represent the same content ## Cause: The function `_get_tax_closing_entries_for_closed_period()` searches for closing moves by `report_id` As a result, variants do not find the matching moves and instead generate a new `account.move` When the move is posted, it differs from the one of the other variant, so the existing move is never posted ## Steps to reproduce: - Create an invoice for any product with a 15% Tax (Invoice Date: 01/01/2025) - In Tax Return, select January 2025 - Click Closing Entry > Post - In Tax Return, change Report type to "Group by: Account > Tax" - Click Closing Entry, the move isn't posted opw-4858689
This update resolves an issue where tables inserted into the To-Do editor appeared after the existing text instead of before it. The fix streamlines the table insertion process, ensuring tables are placed correctly at the desired cursor position. This improves the user experience and prevents formatting inconsistencies.
Original PR description
### Steps to Reproduce : - Open To-Do and type some text. - Place the cursor at the start of the block. - Insert a table. (e.g.: /table) - The table appears after the text instead of before it. ### Purpose of this PR: - Table insertion logic was previously duplicated inside TablePlugin, where it tried to manually split text and inline nodes before inserting the table. However, this responsibility is now correctly handled by `DomPlugin.insert()`, which already: - deletes the current selection if needed. - splits text and inline nodes safely. - handles block boundaries and unsplittable elements. - normalizes the DOM after insertion. - places the cursor at a valid position. task-5480759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where a warning about eTIMS configuration was incorrectly displayed on invoices for companies outside of Kenya. The fix ensures that eTIMS validation only applies to Kenyan companies, improving the user experience and preventing unnecessary alerts.
Original PR description
**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558
This update resolves an error that occurred when exporting SAFT reports for Austrian companies without defined contacts. The fix eliminates a redundant check, streamlining the process and preventing a traceback. This ensures SAFT exports function correctly for all Austrian businesses.
Original PR description
[FIX] l10n_at_saft: saft export traceback When no contacts is defined on the company and the user tries to download the SAFT to XML, a traceback is shown Steps to reproduce the traceback: - Install l10n_at_saft module and create an Austrian company with no contacts - Create a few invoices for this company - Open the General Ledger report and export SAFT to XML, the traceback should appear This fw port includes an other modification: the check 'missing_company_contact' was performed twice, one time in the account_saft module, and the second time in l10n_at_saft. So we removed it from the second module This check make sure the company partner has at least 1 child (1 contact) no-task Forward-Port-Of: odoo/enterprise#104144
This update corrects a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian Lev (BGN). Now, with the adoption of the Euro on January 1, 2026, Bulgaria is correctly linked to the Euro (EUR) within Odoo's system. This ensures accurate financial reporting and data for businesses operating in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update addresses several minor issues within the l10n_hr_edi module, primarily focused on improving the reliability and user experience of fiscal document processing and approval workflows. Specifically, it enhances error handling and clarifies settings related to multi-company operations, ensuring smoother and more accurate HR and accounting processes.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This update corrects a display issue in the Follow-up Levels list view. Previously, an activity was always shown even when 'Schedule Activity' was disabled. Now, the activity column only appears when 'Schedule Activity' is enabled, ensuring a cleaner and more accurate view of follow-up levels.
Original PR description
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176
This update fixes a usability issue where the barcode on customer receipts was too narrow, making it difficult for staff to scan. The barcode width has been increased to ensure reliable scanning and streamline the order fulfillment process. This change enhances the overall customer experience.
Original PR description
Step to reproduce; - install pos_loyalty - create a loyalty program of type "next order coupon" with minimum spend of 1$. - open pos and settle a order, see receipt. Issue: - currently bar-code is too narrow, making it difficult for to be scanned Fix: - increase the width of barcode, so it can be easily scanned. <table> <tr> <td> <b>Before</b> </td> <td> <b>After</b> </td> </tr> <tr> <td> <img width="451" height="508" alt="image" src="https://github.com/user-attachments/assets/a0d1e95e-0a9d-4552-977a-0ad9686867b8" /> </td> <td> <img width="456" height="517" alt="image" src="https://github.com/user-attachments/assets/40d04ac4-9ffc-4f81-a063-31b3ea26b4e1" /> </td> </tr> </table> opw-5363916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr