Daily updates from Odoo
Monday, July 6, 2026
169 changes
25 changes
Enhancements to existing features
This update simplifies the process for responding to PDP requests by moving the response button from a prominent display to the cog wheel menu. Previously, users could achieve the same result by cancelling or posting an invoice/bill, so this change reduces clutter and improves usability. This is an important improvement to the user experience.
Original PR description
No real need to show a big button for sending a response in PDP as cancelling and posting an invoice/bill would do the same, so we move it to the cog wheel menu task-6274220 Forward-Port-Of: odoo/odoo#268846
This update refines how employees' favorite projects are automatically selected on timesheets. Previously, a project was selected with fewer than 3 linked timesheets. Now, a project is only selected if at least 3 of the employee's 5 most recent timesheets are associated with it, ensuring more accurate and relevant project associations.
Original PR description
A favorite project is now selected only when at least 3 of the employee's 5 most recent timesheets are linked to it. task-6290859 Forward-Port-Of: odoo/odoo#273259
Resolved issues and error corrections
This update resolves an issue where the 'Apply To' option in pricelist rules wasn't consistently saving the selected category. The fix ensures that when a category is chosen for a pricelist rule, it's correctly saved and reapplies when the rule is reopened, improving data accuracy for rental pricing.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install Rental(sale_renting) module and activate Pricelist. 2. Go to Rental > Products > Pricelists. 3. Open an existing pricelist or…
Steps to reproduce:
------------------------------------
1. Install Rental(sale_renting) module and activate Pricelist.
2. Go to Rental > Products > Pricelists.
3. Open an existing pricelist or create a new one.
4. Add a pricelist rule and set:
- Apply To: Category
- Configure the rule (e.g. select a category).
5. Save and close the rule, then save the pricelist.
6. Reopen the pricelist rule.
Observation:
------------------------------------
The "Apply To" option is no longer set to Category. Instead, it default value to Product, and the selected category is not saving correctly.
Issue:
------------------------------------
After [This Commit](https://github.com/odoo/odoo/commit/d2648b1d983927b5df7260a16d6d1d33c213ddeb), 'display_applied_on' is used to control the visibility of uom_id but is not defined in the list view. As a result, field parsing marks it as readonly, so its updated value is not saved.
This causes the "Apply To" option to fall back to its default value ('Product') when the pricelist rule is reopened.
Solution:
------------------------------------
Include the display_applied_on field in the pricelist item list view so the selected "Apply To" option is preserved when saving the pricelist.
opw-6346422
Forward-Port-Of: odoo/odoo#273596This update resolves a bug in the Odoo IoT setup process for the l10n_eg module. A recent change simplified the token storage, but without updating the validation logic, it caused errors. The fix now correctly handles both token and hash submissions, ensuring a smooth and reliable setup experience.
Original PR description
In odoo/odoo#255121, the l10n_eg token flow was simplified to store the token automatically in the IoT config when running the installer, instead of showing a popup requiring the user to save the token manually. However, this broke the flow because previously, a *hash* of the token was being stored in the IoT config, but now the actual token is stored in the config (which allows it to be sent to the DB). The token validation logic was not updated accordingly, so it would try to use the token itself as a hash which would result in an `UnknownHashError`. To fix this, we first check if the provided token matches the stored token exactly. If it doesn't, we assume it is a hash and continue with the old flow as before. Logging statements are added in every failure case to ease debugging in the future. opw-6049363 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273474 Forward-Port-Of: odoo/odoo#273033
This update resolves a rare issue where the Glory cash machine was occasionally sending incorrect data to Odoo, leading to errors. The fix ensures that the machine's messages are properly formatted, preventing these errors and maintaining reliable transaction processing. This improves the stability of the Glory Cash integration.
Original PR description
Rarely, the Glory machine can send a websocket message containing 2 root XML elements, which causes the `parseXML` function to fail. This commit fixes the issue wrapping the message in a root element, and then returning the children. opw-6292925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272040
This update fixes an unexpected accrual calculation that occurred when carryover allowances were applied. Previously, an extra accrual happened on the carryover date, leading to confusing accrual amounts. This change ensures accruals only occur at the standard periods (start/end of month, or level transitions) as intended.
Original PR description
## Issue Currently, an extra accrual happens on carryover date, but it shouldn't. Indeed, accrual only happened at the start - end of a period, or on level transition. ## Reproducing steps Let's take an accrual plan with a level that adds 2 days/month on the 15th of the month. The carryover takes place at the beginning of the year. So we will have this: - 2025-11-01 -> creation of the allowance, 0 days available - 2025-11-15 -> 1 day (only 15 days are counted, so only half of the days are added) - 2025-12-15 -> 3 days (1 full month elapsed) - 2026-01-01 -> 4 days (as the carryover triggers an accrual) -> this event causes confusion as the accrual seems to “come out of nowhere” - 2026-01-15 -> 5 days - 2026-02-15 -> 7 days task-5432188 Forward-Port-Of: odoo/odoo#272349 Forward-Port-Of: odoo/odoo#245201
This update fixes an issue where clicking links within reply messages didn't open them in a new browser tab. Now, links from parent messages will automatically open in a new tab, providing a smoother and more convenient user experience when navigating between conversations.
Original PR description
Before this commit, clicking on a link in a parent message was not opening it in a new tab. Now, the target and rel attributes of the parent message are passed to the inline body opening the link in a new tab if it was the case in the parent. task-6326242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273603
This update corrects a display issue on the shop page where the order of product attribute values wasn't consistently maintained. The fix ensures that the order of attribute values, as defined by the user, is correctly displayed when browsing products. This improves the user experience and prevents confusion regarding product options.
Original PR description
In saas-19.3, the shop controller was refactored to fetch attribute values using `ProductAttributeValue._read_group()` with `aggregates=["id:recordset"]`. This aggregate internally uses `ARRAY_AGG(id ORDER BY id)`, which orders values strictly by database ID, ignoring the `sequence` field defined in `product.attribute.value._order = 'attribute_id, sequence, id'`. Steps to reproduce: 1. Go to ecommerce attributes. 2. Add an attribute value to any attribute. 3. Make sure the attribute is used by a product. 4. Rearrange the order of the attribute value. 5. Go to the shop page, and try to access the attribute value by clicking on the proper attribute. 6. We see that the order isn't maintained. Fix by calling `.sorted()` on each value recordset after the aggregate, so the user-defined sequence is respected before storing into `pavs_per_attribute`. opw-6325814 Forward-Port-Of: odoo/odoo#273802
This update enhances the logging page by limiting the displayed log data to the last 10,000 lines, preventing performance issues with large logs. It also adds automatic scrolling and removes unnecessary log requests, improving the user experience and overall stability of the logging feature.
Original PR description
This commit makes the following pages to the log viewing page: - Only the last 10000 lines of logs are shown. This stops the page from freezing/performing badly when the logfile is very large. - When the view is at the bottom of the page, new logs are automatically scrolled into view. Otherwise the view stays still so the user can inspect the logs without them scrolling away. - The ANSI color codes are now stripped from the logs as they were just displayed as garbage characters. - The requests to fetch logs are now removed from the output, as otherwise you would be spammed with requests that only happen as a result of the logging page being open. task-6330996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273343
This update clarifies the roles and permissions associated with the 'User' and 'Administrator' groups within the Project module. The changes improve the clarity of how users manage tasks and projects, ensuring accurate understanding of access rights.
Original PR description
This commit improves the grammar of the Project user group description. ### **For User:** **Before -** `User can user the your employees' schedule` **After -** `User: Can manage tasks in projects shared with them.` ### **For Admin:** **Before -** `Administrator can manage the employees' schedule` **After -** `Administrator: Can manage projects and stages, with access to reporting and configuration.` **opw-6340390** Forward-Port-Of: odoo/odoo#273061
This update ensures WIoT instances are immediately accessible during upgrades to newer Odoo versions. The change sets the HTTP interface to `0.0.0.0`, preventing a default configuration change in Odoo 19.1 that would block access. This streamlines the upgrade process for WIoT.
Original PR description
WIoT are built in v19, but progressively upgrading to 19.1,2,3,... We need to set the `http_insterface` param to `0.0.0.0` so they are ready when upgrading, as `http_interface` changes to localhost by default in 19.1. Forward-Port-Of: odoo/odoo#271857
A recent test for adding products to invoices was failing due to an outdated element search within the Odoo system. This update corrects the test to correctly identify a key element, ensuring the invoice product catalog tour functions as intended. This resolves a minor technical issue impacting test reliability.
Original PR description
The tour preciously looked for a `o_field_product_label_section_and_note_cell` element to verify product was added. In the configuration used, the element did not exist, despite the line with the product being present. This caused the tour test to fail. This PR makes it look for a `o_account_label_text_cell` instead to successfully detect the line. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a minor issue where the mailing domain dropdown remained visible when a target model wasn't selected. The fix ensures the recipient count is correctly set, preventing errors and improving the user experience. While a mailing requires a target model, this update ensures proper functionality.
Original PR description
On a mailing, when attempting to remove the target model, `_compute_recipients_count` will attempt to recompute the recipient count. As the new target domain is empty, recipient count will not be set. This will cause an traceback, as the compute method was unsuccessful in assigning a recipient count. (This is a minor issue, as a mailing cannot be saved without a target model anyways; however, this causes the mailing domain dropdown to remain visible when it should be hidden.) Steps to reproduce: - Create a new mailing - Blank out the target model field (recipients) Fix: `_compute_recipients_count` assigns recipient count to False (empty column).
This update resolves a bug that prevented users from correctly selecting section templates within Sales Orders. The fix corrects a data entry error that was causing a validation issue when creating sales orders with section templates. This ensures the sales order creation process functions smoothly.
Original PR description
## Steps to Reproduce: 1. Install the sale_margin module. 2. Sales > Configuration > Templates. 3. Create a template with type 'Section', and add a section line. 4. Create a Sales Order, click Add…
## Steps to Reproduce: 1. Install the sale_margin module. 2. Sales > Configuration > Templates. 3. Create a template with type 'Section', and add a section line. 4. Create a Sales Order, click Add Section, and select the created template. ## Error: `ValueError: Expected singleton: res.currency()` ## Cause: The `_prepare_order_line_values()` method mistakenly stores the converted purchase price in the `currency_id` field instead of `purchase_price`. When these values are used to create a sales order line, leaving currency_id unset. - [1] As a result, the onchange later fails when it expects a valid currency. - [2] ## Fix: Pass the correct field value of `purchase_price` instead of `currency_id`. [1]: https://github.com/odoo/odoo/blob/f2f656371f81683ee3fe558932df53a2d0c5d374/addons/sale_management/models/sale_order_template.py#L346-L350 [2]: https://github.com/odoo/odoo/blob/f2f656371f81683ee3fe558932df53a2d0c5d374/addons/sale_margin/models/sale_order_line.py#L76 opw-6347869
This update resolves an issue where the extra price for product variants was incorrectly displayed when a pricelist used a fixed pricing model. The fix ensures that the extra price badge is hidden in the product configurator and website views when the pricelist's calculation method is fixed, aligning with expected behavior.
Original PR description
Issue: --- If pricelist.compute_price is fixed, extra price of variant is not taken into calculation, but it's shown in extra price badge. Steps to reproduce: --- 1- Create a product template with two variants. 2- Apply extra price for each attribute values. 3- Apply a pricing with a fixed price for the product on a pricelist. 4- Create a SO and apply the pricelist. Add the product to SOL. 5- Open product configurator on SOL. - As you see, the extra price is shown but it's not effective. 6- Open the product in website with the pricelist. - Here also the extra price is shown but it's not effective. Cause: --- This is caused because there is no mechanism to hide extra price having pricelist.compute_price == fixed. Fix: --- We need to fix the issue both in sale and website_sale separately by having a flag to ensure extra price badge is hidden if compute_price is fixed. opw-6276208 Forward-Port-Of: odoo/odoo#272541 Forward-Port-Of: odoo/odoo#270140
This update fixes an issue where the restaurant floor plan selector would overlap other parts of the interface when multiple floor plans were available. Adding horizontal scrolling ensures the floor plan is always visible and accessible, providing a better user experience for restaurant staff.
Original PR description
In this commit: ---------------- - Added horizontal scrolling for the floor selector when multiple floor plans are available, preventing it from overlapping other components. Task: 6356983 Forward-Port-Of: odoo/odoo#274092 Forward-Port-Of: odoo/odoo#273637
This update fixes a technical issue related to printer test setup by moving mocking to the client-side. Additionally, the printer setup tours have been streamlined for easier testing and a more intuitive user experience, particularly when using demo data.
Original PR description
We moved printer requests mocking client-side in tests to avoid creating fake controllers. We also improved the tour to search the actual printer name in the printer selection wizard, and made the zebra tour start directly from the product instead of searching it (simplifies search when tests are run with demo data).
This update fixes an issue where switching settings apps on mobile devices didn't correctly update the browser's URL. Now, refreshing the page will reliably take the user back to the settings app they were previously using, ensuring a smoother user experience.
Original PR description
Before this commit, when switching applications in the settings view on mobile, the URL fragment was not correctly updated to reflect the active application. Because of this, if the page was reloaded, the user would be redirected back to the first application in the settings instead of the one they were currently viewing. This commit ensures the URL fragment is properly updated upon selection, preserving the user's current context if the page is refreshed. task-id 6333778
This update resolves a technical issue that was preventing tests for our Point of Sale and POS Stock modules from running correctly. The change ensures that test code doesn't accidentally alter the system's core data, allowing the tests to pass and maintain the stability of these important features.
Original PR description
Avoid polluting the Odoo model registry and failing `test_lint_override_signature` by using `patch.object` instead of manual assignment. This ensures the injected method is properly torn down after the test block, keeping the registry clean and bypassing static analysis failure as the patched method is only used for tests. Note: this commit is a follow-up of odoo/odoo@163225c3f9c0f51c40c9b1ae6ec00ba1c8f16017 runbot-939298 Forward-Port-Of: odoo/odoo#274318
This update corrects a technical issue where a key field related to product removal strategies was incorrectly loaded in the Point of Sale module. Now, this field is correctly loaded within the pos_stock module, ensuring accurate stock management and reporting for point-of-sale transactions. This improves the overall reliability of the POS system.
Original PR description
Before this commit: ==== - removal_strategy_id field was loaded in point_of_sale instead of pos_stock Following this commit: ==== - Field is now been loaded in pos_stock Error-941369 Forward-Port-Of: odoo/odoo#274297
This update standardizes the technical names used for website types within the Odoo platform. Previously, inconsistent capitalization (camelCase) was used, which has now been corrected to snake_case. This ensures greater clarity and consistency across the codebase, improving maintainability.
Original PR description
Avoid using camelCase for website type technical names and use snake_case consistently for technical identifiers. task-[6284263](https://www.odoo.com/odoo/project/974/tasks/6284263) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268829
This update ensures GIF functionality in Odoo continues to work by switching from the soon-to-be-terminated Tenor GIF API to the Klipy GIF API. This change is necessary to avoid disruptions to GIF sharing within the system. Users should be aware that updating the API key is required for GIF functionality to remain operational.
Original PR description
Tenor API will be terminated on June 30, 2026: https://developers.google.com/tenor/guides/quickstart This commit makes the Tenor API key input settings use a Klipy GIF API key instead of a Tenor GIF API key. To keep GIF working after this commit, the API key must necessarily be changed to a Klipy GIF API key, as the old Tenor API key would be considered as an invalid Klipy API key. Task-5491965 Upgrade: https://github.com/odoo/upgrade/pull/10516 Forward-Port-Of: odoo/odoo#273182 Forward-Port-Of: odoo/odoo#250113
A recent update caused internal server errors when blog comments were enabled. This fix removes a leftover reference to a field, resolving the issue and ensuring blog pages function correctly with comments active. This improves the overall stability of the blog feature.
Original PR description
**Description of the problem** Traceback on blog pages when comments are active. **How to reproduce** (Starting from a fresh database with `website` and `website_blog` installed with demo data) 1. Open edit mode on a blog post 2. Activate comments 3. PROBLEM: Internal Server Error **Origin of the problem** Commit [1] removed the `website_message_ids` field, but a single occurrency was left behind in the codebase, causing a traceback on the first attempt to open the blog page. **FIX** This commit removes the reference to the field `website_message_ids`. [1]: https://github.com/odoo/odoo/pull/261003 task-6364928
A bug in the public tour process caused it to repeatedly run and fail due to delayed uploads. This fix correctly scopes the tour's uploads to the composer, ensuring it waits for its own attachments to be processed. This resolves a recurring test failure and improves the tour's reliability.
Original PR description
discuss_channel_public_tour uploads two files and waits for their attachment cards before clicking Send. The card selectors were not scoped to the composer, and message attachments render the exact…
discuss_channel_public_tour uploads two files and waits for their attachment cards before clicking Send. The card selectors were not scoped to the composer, and message attachments render the exact same card. The tour runs twice per test: on the second run, the message posted by the first run already displays identical text.txt and image.png cards, so the waits matched immediately and the tour never waited for its own uploads (build logs show the steps passing before the upload requests even reached the server). Send was then clicked during the upload window. The trigger can catch the button enabled from a render preceding the upload registration, while processMessage checks the live model, still finds an attachment uploading, and silently drops the message. The persistent "cheese" message step then timed out. Scope the selectors to the composer so the tour genuinely waits for its own uploads; this also makes the guest access token check read the composer image instead of the first run's message image. https://runbot.odoo.com/odoo/error/941300
This update resolves a bug that prevented the generation and sending of French PDP reports. The issue stemmed from incorrectly formatting the report data before sending, which caused a system crash. This fix ensures reports are now processed correctly and reliably.
Original PR description
Before this commit, it was impossible to send a `l10n.fr.pdp.reports.flow` as we included a raw file in the payload without decoding it. This causes the JSONification to crash. 1. Install l10n_fr_pdp 2. Create a record of `l10n.fr.pdp.reports.flow` 3. Try to send it 4. See crash opw-6330820 **19.3+** Forward-Port-Of: odoo/odoo#272513
9 changes
Resolved issues and error corrections
This update corrects a technical issue where the removal strategy field wasn't correctly loaded within the pos_stock module. Now, this field is properly loaded, ensuring more accurate stock management within point-of-sale transactions. This improves the reliability of sales data.
Original PR description
Before this commit: ==== - removal_strategy_id field was loaded in point_of_sale instead of pos_stock Following this commit: ==== - Field is now been loaded in pos_stock Error-941369
This update fixes an issue where clicking links within reply messages didn't open them in a new browser tab. Now, links from parent messages will automatically open in a new tab, providing a smoother and more convenient user experience when navigating between conversations. This improves usability and efficiency.
Original PR description
Before this commit, clicking on a link in a parent message was not opening it in a new tab. Now, the target and rel attributes of the parent message are passed to the inline body opening the link in a new tab if it was the case in the parent. task-6326242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273603
This update resolves a test failure related to how methods were being overridden in the Point of Sale and POS Stock modules. By using a specific testing technique, the system now correctly cleans up after tests, preventing errors and ensuring the stability of the core Odoo system. This improves test reliability and reduces the risk of future issues.
Original PR description
Avoid polluting the Odoo model registry and failing `test_lint_override_signature` by using `patch.object` instead of manual assignment. This ensures the injected method is properly torn down after the test block, keeping the registry clean and bypassing static analysis failure as the patched method is only used for tests. Note: this commit is a follow-up of odoo/odoo@163225c3f9c0f51c40c9b1ae6ec00ba1c8f16017 runbot-939298
This update fixes an issue where the year on timesheet kanban cards was split across two lines, making it visually less clear. The fix ensures the year is always displayed on a single line, improving readability and the overall user experience. This change addresses a minor aesthetic concern.
Original PR description
Steps to reproduce:
-
1. Open the Timesheets app and display "All Timesheets" in kanban view.
2. Use a record whose project, task, or description is long enough to take up most of the card's width.
3. Look at the date shown on the left side of the kanban card.
Issue:
-
The year is split over two lines (e.g. "202" / "6") instead of staying on a single line.
Cause:
-
On the kanban card, the date is rendered in a small left-hand column split into two lines ("MMM d" and "yyyy"). That column has no `flex-shrink-0`, so when the description and the hours/avatar footer compete for space, the flex layout shrinks the date column until the year no longer fits and wraps.
Fix:
-
Add `flex-shrink-0` to the date column so it keeps its natural width.
task-6330852This update clarifies the descriptions for both User and Administrator groups within the Project module. The changes refine the language to more accurately reflect their respective access and capabilities, ensuring better understanding and usability.
Original PR description
This commit improves the grammar of the Project user group description. ### **For User:** **Before -** `User can user the your employees' schedule` **After -** `User: Can manage tasks in projects shared with them.` ### **For Admin:** **Before -** `Administrator can manage the employees' schedule` **After -** `Administrator: Can manage projects and stages, with access to reporting and configuration.` **opw-6340390** Forward-Port-Of: odoo/odoo#273061
This update ensures WIoT installations are immediately accessible during upgrades to newer Odoo versions. The change sets the HTTP interface to '0.0.0.0', preventing a default change to 'localhost' that could interrupt the upgrade process. This simplifies the upgrade path for WIoT deployments.
Original PR description
WIoT are built in v19, but progressively upgrading to 19.1,2,3,... We need to set the `http_insterface` param to `0.0.0.0` so they are ready when upgrading, as `http_interface` changes to localhost by default in 19.1. Forward-Port-Of: odoo/odoo#271857
This update ensures that non-global rules behave correctly when a group association is removed. Previously, rules without groups could unexpectedly trigger, leading to potential inaccuracies. This fix corrects a technical issue to guarantee rules only apply when a group is actively defined.
Original PR description
A non-global rule is expected to have at least one group. However, it is technically possible to remove a rule's last group without making the rule global. This may happen for instance, when the group relation is removed in plain SQL. In that case, the rule should not apply at all.
This update resolves a discrepancy in the testing process for the pos_qfpay module. A necessary step to ensure correct payment terminal functionality was missing in the tests, which has now been added. This ensures the payment processing system operates as intended.
Original PR description
In odoo/odoo#270240 we removed the automated "send" call on payment terminals, but the test for pos_qfpay wasn't updated in the fw port. This commit fixes by adding a call to "send" in the test.
This update optimizes how Odoo forms respond to changes. Previously, opening a form triggered onchange methods multiple times for each field that changed, leading to slower performance. This fix reduces redundant calls within a single update, resulting in a faster and more responsive user experience.
Original PR description
When an onchange method depends on several fields that all change at once (for example two fields that both have a default value), opening the form triggers that method once per field, even though a single call would suffice. This adds a per-pass set of already-applied onchange methods so that, within the same batch of changed fields, each method is invoked only once. Note this does not guarantee a method is called exactly once overall: it may still run again in later onchange passes; we only remove the redundant calls within a single pass. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273843 Forward-Port-Of: odoo/odoo#251813
6 changes
Resolved issues and error corrections
This update resolves a rare issue where the Glory cash machine occasionally sent incorrect data to Odoo, leading to errors. The fix ensures that all incoming data is properly formatted, preventing the system from crashing when receiving multi-element XML messages. This improves the reliability of the Glory cash integration.
Original PR description
Rarely, the Glory machine can send a websocket message containing 2 root XML elements, which causes the `parseXML` function to fail. This commit fixes the issue wrapping the message in a root element, and then returning the children. opw-6292925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272040
This update fixes a problem where receipts sometimes printed blank or were cut prematurely. A small delay was added after sending the receipt image to allow the printer to fully process the data. The update also modernizes the printer software for better compatibility and future tracking.
Original PR description
Previously, printing a receipt could sometimes result in blank paper being dispensed or the paper being cut prematurely. This occurred because the sequence of line feeds and cut commands was dispatched immediately after sending the image payload, before the printer hardware had sufficient time to process and spool the bitmap. To resolve this, a 200ms delay is introduced after the bitmap is sent. Additionally, the arbitrary `printAndLineFeed` calls are replaced with a precise `printAndFeedPaper` and explicit `partialCut` command. This ensures the hardware has fully rendered the receipt before advancing the paper and engaging the blade. Finally, the internal imin SDK (`lib/imin-printer/imin-printer.js`) is updated to handle websocket connection timeouts gracefully and to expose new hardware APIs for future tracking. owp-6242801 Forward-Port-Of: odoo/odoo#270765
This update clarifies the descriptions for both User and Administrator groups within the Project module. The changes improve the clarity of their respective roles and responsibilities, specifically outlining task management capabilities for Users and project/stage management with reporting access for Admins.
Original PR description
This commit improves the grammar of the Project user group description. ### **For User:** **Before -** `User can user the your employees' schedule` **After -** `User: Can manage tasks in projects shared with them.` ### **For Admin:** **Before -** `Administrator can manage the employees' schedule` **After -** `Administrator: Can manage projects and stages, with access to reporting and configuration.` **opw-6340390** Forward-Port-Of: odoo/odoo#273061
This update ensures WIoT instances are properly configured for seamless upgrades to newer Odoo versions. Specifically, the `http_interface` setting has been adjusted to `0.0.0.0`, allowing WIoT to be accessible during the upgrade process. This prevents potential connectivity issues and simplifies the upgrade path.
Original PR description
WIoT are built in v19, but progressively upgrading to 19.1,2,3,... We need to set the `http_insterface` param to `0.0.0.0` so they are ready when upgrading, as `http_interface` changes to localhost by default in 19.1. Forward-Port-Of: odoo/odoo#271857
This update optimizes how Odoo forms respond to changes. Previously, opening a form triggered onchange methods repeatedly for each field that was updated. This fix reduces unnecessary calls, making forms load and update faster and more efficiently. It's a small change that improves the overall user experience.
Original PR description
When an onchange method depends on several fields that all change at once (for example two fields that both have a default value), opening the form triggers that method once per field, even though a single call would suffice. This adds a per-pass set of already-applied onchange methods so that, within the same batch of changed fields, each method is invoked only once. Note this does not guarantee a method is called exactly once overall: it may still run again in later onchange passes; we only remove the redundant calls within a single pass. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273843 Forward-Port-Of: odoo/odoo#251813
This update fixes a bug where email bounces from mailing campaigns weren't accurately recorded for contacts. Now, the system correctly updates bounce counts when emails fail to deliver, providing a more reliable view of mailing campaign performance. This ensures accurate reporting and helps optimize future campaigns.
Original PR description
Previously, when a mailing campaign sent out an email to a mailing.contact, and that email bounced, the bounce would not increment the contact's bounce count. This commit makes it so that the bounce count is correctly updated when a mailing campaign sends an email that bounces. task-4893615 Forward-Port-Of: odoo/odoo#226362
14 changes
New functionality added to Odoo
This update adds PayU as a new payment option for our customers. This expands payment choices and supports a growing market. Details are available in the PayU documentation linked in the pull request.
Original PR description
Add new payment provider PayU. See README.md for more details. task-6219530 Forward-Port-Of: odoo/odoo#267962
Resolved issues and error corrections
This update corrects a technical issue that prevented proper logging functionality in Odoo's SaaS version, specifically impacting versions 19.0 and later. The fix ensures that necessary data is captured during the forwardport process, maintaining accurate logging records.
Original PR description
During the forwardport, it was missed that get_log_metadata needs an argument starting from 19.0. Forward-Port-Of: odoo/odoo#273694
This update resolves a rare issue where the Glory cash machine occasionally sent a complex websocket message, leading to errors in Odoo's processing. The fix ensures the message is correctly formatted, preventing the error and maintaining reliable transaction processing with the Glory machine.
Original PR description
Rarely, the Glory machine can send a websocket message containing 2 root XML elements, which causes the `parseXML` function to fail. This commit fixes the issue wrapping the message in a root element, and then returning the children. opw-6292925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#272040
This update fixes an issue where the number of expenses linked to a sales order was inconsistent, leading to confusion for users. Now, all expenses associated with a sales order are accurately counted, ensuring the smart button displays the correct number of expenses and provides a reliable list when clicked. This improves the user experience and data accuracy.
Original PR description
**Before this commit** Only expenses that generated a sale order line on an SO would be counted in that SO's count of expenses, introducing confusing behavior with the smart button on the SO form view that would take the user to a list of all expenses that have anything to do with the current SO. **After this commit** We return to the behavior that was present in Odoo 18.1 where all expenses that are associated with a SO show up in that SO's "expense_count", making the number in the smart button consistent with the number of expenses that will be fetched when clicking on it. opw-6309575 Forward-Port-Of: odoo/odoo#272287
This update resolves an issue where creating multiple applications with the same applicant information would trigger an error within the Talent Pools feature. The fix restricts the duplication of talent records, ensuring data integrity and preventing application errors. This improves the user experience when managing recruitment applications.
Original PR description
When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback. Steps to reproduce the error: - Install…
When multiple talent records share the same information, opening the Talent Pools smart button from a matching application will trigger a traceback. Steps to reproduce the error: - Install ``hr_recruitment`` module with demo data - Go to Recruitment > Applications > Talent Pools > Create a new pool - Go to Recruitment > Applications > All Applications > Create a new application with valid email > Click Add to Pool > Select the Talent Pool > Add to Pool - Duplicate the created talent record - Create another application with the same email > save > click Talent Pools Traceback: ```py ValueError: Expected singleton: hr.applicant(2, 1) ``` https://github.com/odoo/odoo/blob/d4e76a5663223a2a2c6e50d1701fabbdcaf32405/addons/hr_recruitment/models/hr_applicant.py#L857-L859 Here, the talent is searched using matching applicant information. When a matching talent has been duplicated, the search returns multiple records. Assigning a multi-records to the many2one field ``pool_applicant_id`` then raises a singleton error. Solution: Restrict the duplication of talent. sentry-7556261128 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273301 Forward-Port-Of: odoo/odoo#270827
This update fixes an error that occurred when clearing the date field in the WIP Accounting Entry wizard. Previously, the wizard would crash. Now, users can temporarily empty the date field without causing an error, ensuring a smoother workflow for managing manufacturing orders.
Original PR description
Issue Before This PR: When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the…
Issue Before This PR: When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard. Steps to Reproduce: - Open the list view of Manufacturing Orders. - Open the Post WIP Accounting Entry wizard by either: - Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry - Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu. - Clear the Date field. - Observe that an error is raised. Cause of the Issue: The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error. With This PR: The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input. Issue reference: https://github.com/odoo/odoo/issues/246547 Forward-Port-Of: odoo/odoo#273002
This update clarifies the roles and responsibilities associated with the 'User' and 'Administrator' groups within the Project module. The changes improve the clarity of how users manage tasks and projects, ensuring better understanding of their access and capabilities.
Original PR description
This commit improves the grammar of the Project user group description. ### **For User:** **Before -** `User can user the your employees' schedule` **After -** `User: Can manage tasks in projects shared with them.` ### **For Admin:** **Before -** `Administrator can manage the employees' schedule` **After -** `Administrator: Can manage projects and stages, with access to reporting and configuration.` **opw-6340390** Forward-Port-Of: odoo/odoo#273061
This update ensures WIoT instances are immediately accessible during upgrades to the latest Odoo versions. The change sets the HTTP interface to '0.0.0.0', preventing a default configuration change that would otherwise block access. This streamlines the upgrade process for WIoT deployments.
Original PR description
WIoT are built in v19, but progressively upgrading to 19.1,2,3,... We need to set the `http_insterface` param to `0.0.0.0` so they are ready when upgrading, as `http_interface` changes to localhost by default in 19.1. Forward-Port-Of: odoo/odoo#271857
This update optimizes how Odoo forms respond to changes. Previously, opening a form triggered onchange methods repeatedly for each field that was updated. This change reduces unnecessary calls, resulting in faster form loading and a smoother user experience. It's a small but important improvement for overall system performance.
Original PR description
When an onchange method depends on several fields that all change at once (for example two fields that both have a default value), opening the form triggers that method once per field, even though a single call would suffice. This adds a per-pass set of already-applied onchange methods so that, within the same batch of changed fields, each method is invoked only once. Note this does not guarantee a method is called exactly once overall: it may still run again in later onchange passes; we only remove the redundant calls within a single pass. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273843 Forward-Port-Of: odoo/odoo#251813
This update resolves an issue where archived employee order data remained visible in the POS system. The fix ensures that orders processed by an archived employee are no longer displayed when searching for 'Paid' orders. This improves data accuracy and prevents confusion for users.
Original PR description
Steps to reproduce on runbot:
- Enable "Log in with Employees"
- Connect to the POS with an employee
- Process an order
- Go to the backend
- Archive the employee
- Connect to the POS with another employee
- Go to the "Order" tab and search for "Paid" orders
Error:
Odoo Server Error: {archived_employee_id}
[opw-6223243](https://www.odoo.com/odoo/project/49/tasks/6223243)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#273394
Forward-Port-Of: odoo/odoo#266364This update resolves a rare technical problem within Odoo's web interface that could occasionally cause a test to fail. The fix ensures that popovers are properly closed, preventing errors that arise when components are destroyed during the testing process. This improves the stability of the web interface.
Original PR description
Add an extra step to close the popover and prevent the `Component is destroyed` error[1], which can happen during hoots cleanup, similar to the issue we see when some dialogs perform RPCs as they are being destroyed. [1]: https://runbot.odoo.com/runbot/build/115972540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273826 Forward-Port-Of: odoo/odoo#273085
This update fixes a technical error that prevented users from accessing the 'By Employee' report within the Time Off module when specific employee settings were configured. The issue stemmed from a singleton problem, now resolved to ensure the report functions correctly for all users. This ensures accurate reporting on employee time off requests.
Original PR description
A singleton error appears when opening the "By Employee" report under Time Off. Steps to reproduce: 1)Install the l10n_fr_hr_holidays module. 2)Switch to the French company. 3)Open any employee record. 4)Set Working Hours (resource_calendar_id) to empty. 5)Set Hours Per Week. 6)Create a time off request for any past date. 7)Go to Reporting → By Employee. Task:-6043142 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
This update fixes a testing issue within the account_edi_ubl_cii module by using a real, partial XML file for partner bank account retrieval tests. This ensures more accurate and reliable testing of the system's ability to process UBL invoices, leading to greater confidence in the financial data being imported.
Original PR description
Move the partner retrieval bank account number test to the `test_ubl_import_bis3_invoice_be_retrieve_partner.py` file and use a partial XML instead of a generated XML. Forward-Port-Of: odoo/odoo#273575 Forward-Port-Of: odoo/odoo#269995
This update fixes a minor typo in the Odoo email responsive design code. The correction ensures the email layout renders correctly across different devices, improving the user experience for recipients. This change is a routine maintenance task to maintain consistent email quality.
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#274343
6 changes
Resolved issues and error corrections
This update resolves an issue where the live chat system would crash when a chatbot attempted to forward a conversation to an operator, and no operators were configured for that channel. The fix prevents the system from attempting to process an empty operator list, eliminating the error and ensuring smooth chatbot operation.
Original PR description
When a live chat channel has no operators configured and the chatbot script ends with a Forward to operator step, triggering that step causes a traceback. Steps to reproduce the error: - Install…
When a live chat channel has no operators configured and the chatbot script ends with a Forward to operator step, triggering that step causes a traceback. Steps to reproduce the error: - Install ``im_livechat`` module with demo data - Go to Live Chat > Configuration > Chatbots > Create a new chatbot > Add script > Step Type: Question > Set answers > Save > Add script > Step Type: Forward to operator > Only If: Set one of the above answers > Save - Go to Live chat > Channel > Click the configure channel on YourWebsite.com > Remove the operators > Save - Go to the chatbot > test > select the configured answer Traceback: ```py StopIteration ``` https://github.com/odoo/odoo/blob/8791cdcd89ea3cb56b1fac63b3e2ffbd2956a912/addons/im_livechat/controllers/chatbot.py#L65-L70 When the chatbot script reaches a Forward to operator step while no operator is configured in the live chat channel, no chatbot message is created. As a result, the generator iterates over an empty iterator, and the ``next()`` call raises a ``StopIteration`` exception, causing a traceback during the conversation. sentry-7435424405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261726
This update clarifies the descriptions for both User and Administrator groups within the Project module. The changes improve clarity regarding user access to projects and reporting capabilities, ensuring accurate understanding of permissions.
Original PR description
This commit improves the grammar of the Project user group description. ### **For User:** **Before -** `User can user the your employees' schedule` **After -** `User: Can manage tasks in projects shared with them.` ### **For Admin:** **Before -** `Administrator can manage the employees' schedule` **After -** `Administrator: Can manage projects and stages, with access to reporting and configuration.` **opw-6340390** Forward-Port-Of: odoo/odoo#273061
This update resolves an issue where invoices were displaying an incorrect final amount due due to a misinterpretation of loyalty program discounts. The fix ensures that tax calculations are accurate, particularly when loyalty discounts are applied, preventing a small discrepancy in the invoice total. This improves the reliability of the POS order process.
Original PR description
When computing taxes for the order, we group the base lines based on a grouping key. One of the components of this key is `is_refund`, and reward lines where considered as refund lines, which caused…
When computing taxes for the order, we group the base lines based on a grouping key. One of the components of this key is `is_refund`, and reward lines where considered as refund lines, which caused them to be grouped separately. This caused a discrepency between the tax amount computed in the frontend and the one computed in the backend. Steps to reproduce: ------------------- * Change the rounding method to globally * Create a 21% tax not included in price * Create a product with a price of 76.01 and the tax created above * Create a loyalty program with a 10% discount * Create a POS order with the product above and apply the loyalty program * Validate the order and generate the invoice > Observation: The invoice states that 0.01$ is still due Why the fix: ------------ In `round_tax_details_tax_amounts`, we try to detect any delta with the expeced tax amount. To do that we group the base lines based on a grouping key. The grouping key `is_refund` was incorrectly set to `true` for reward lines, which caused them to not be grouped. The delta was then not detected and tax amounts were not adjusted. We now make sure not to consider reward lines as refund. opw-6052112 Forward-Port-Of: odoo/odoo#273397 Forward-Port-Of: odoo/odoo#271577
This update corrects a visual issue where the background color of the account type selection dropdown remained in light mode when dark mode was enabled. The change ensures the dropdown's background color matches the overall dark mode theme, improving the user experience and visual consistency. This fix was implemented to maintain a polished and professional appearance across all Odoo environments.
Original PR description
Steps to reproduce: - Install `account` module - Enable dark mode - Open `view_account_form` to create a record - On the Accounting page, open type dropdown - The dropdown background remains in light mode This commit applies $dropdown-bg on `o_field_account_type_selection` as in odoo/odoo@0cd148eb389078c896aaa719af5733d05377fd1c Forward-Port-Of: odoo/odoo#274098 Forward-Port-Of: odoo/odoo#271352
This update fixes an issue where template tasks were incorrectly counted in task views and notebooks. The change ensures that task counts accurately reflect only real subtasks, improving the clarity and usability of project management within the Odoo system. This ensures accurate reporting and task management.
Original PR description
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab,…
Steps to Reproduce --- - Create a normal parent task with one normal sub-task and one template sub-task. - Open the parent task form view and observe the Sub-tasks stat button count and notebook tab, check the subtask view as well. - Create a template parent task with one normal sub-task and one template sub-task, then repeat the same checks. Issue --- - Task templates are handled like regular subtasks in the subtask count, notebook, and subtask view, without taking the parent task type into account. Current Behaviour --- - For a normal parent task, both the normal sub-task and the template sub-task are counted and shown in the opened subtask view and notebook. - For a template parent task, the same filtering is applied, even though template subtasks should remain accessible in that context. Expected Behaviour --- - For a normal parent task, only real sub-tasks should be counted and shown in the subtask view and notebook, and on the project kanban card. - For a template parent task, template subtasks should remain available in the subtask view and notebook according to the parent template context. - In the project kanban card, tasks must not be counted when their parent task is a template, even if the child task itself is not a template. Fix --- - Apply template-aware filtering to subtask counting,project kanban task count and subtask view behavior, depending on whether the parent task is a normal task or a template task. task-5966684
This update corrects a previous error that triggered a user error message when generating invoices for Co-Contractant tax situations. The fix ensures that a note is only added to the invoice when the Co-Contractant tax amount is zero, aligning with standard fiscal practices. This improves invoice accuracy and user experience.
Original PR description
We were raising a UserError because we were putting the note even if the tax amount was different from 0. But in fact, it can be normal to have 0% cocontractant tax and normal rate at the same time on an invoice, which would have the fiscal position Co-Contractant. So remove these UserError, but only apply the note when the tax amount is 0 opw-6302806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274117 Forward-Port-Of: odoo/odoo#268899
5 changes
New functionality added to Odoo
This pull request introduces a new module for cleaning services within Odoo. It lays the groundwork for managing cleaning service offerings, scheduling, and potentially integrating with cleaning providers. This addition expands Odoo's capabilities to cater to businesses requiring cleaning services management.
Original PR description
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
Resolved issues and error corrections
This update corrects a visual inconsistency in the website's accordion controls. A previous change caused the accordion's color to appear differently when expanded versus collapsed. This fix ensures a consistent and correct color display for all accordion states, improving the overall user experience.
Original PR description
In commit[1] we restyled the accordion snippets, removing the background-image to use oi-icons instead. However due to selector specificty, the rule was taking priority. This :not is actually wrong since we want the color to apply as well when the accordion is collapsed (else you have 2 different colors between the collapsed uncollapsed state) task-6361379 [1]: f26a1535b96c728e4360d94c0c06de138a6b1b3f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous error that displayed an invoice note even when the tax amount was not zero. The change allows for proper handling of invoices with varying tax rates, reflecting the Co-Contractant's fiscal position. This ensures accurate invoice generation and avoids unnecessary error messages.
Original PR description
We were raising a UserError because we were putting the note even if the tax amount was different from 0. But in fact, it can be normal to have 0% cocontractant tax and normal rate at the same time on an invoice, which would have the fiscal position Co-Contractant. So remove these UserError, but only apply the note when the tax amount is 0 opw-6302806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268899
This update resolves an issue where tests related to account_edi_ubl_cii were failing due to an outdated VAT number. Replacing the invalid VAT with a valid one ensures consistent test results across different environments, improving the reliability of our system.
Original PR description
The previous Belgian VAT is rejected by newer versions of `python-stdnum`. Replace it with a valid VAT so the test behaves consistently across environments.
This update resolves a test failure related to certificate generation. The Odoo system relies on a specific version of the cryptography library, and an older version caused issues with X25519 keys. By skipping the X25519 issuer test when the library is outdated, the system continues to function correctly without disrupting certificate creation.
Original PR description
CertificateBuilder.public_key() rejects X25519 keys before cryptography 36.0.0, and Odoo pins 3.4.8 for python < 3.12, so test_is_issued_by errored on runbot. Skip the X25519 case when the lib can't build it. https://cryptography.io/en/latest/changelog/#v36-0-0 Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/941306 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
4 changes
Resolved issues and error corrections
This update corrects a bug in the Odoo journal entry preview. Previously, if a currency wasn't specified, the preview incorrectly displayed the debit amount in both columns. This change ensures the preview accurately reflects the credit and debit values, improving the reliability of financial reporting.
Original PR description
In _move_dict_to_preview_vals(), when no currency is provided, the credit column falls back to the line's debit value, so any caller omitting currency_id would show the debit amount in both columns of the journal entry preview. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects formatting issues with numbers in various languages, including Indian languages and Burmese, ensuring correct decimal separators and grouping symbols. It addresses inconsistencies in number formatting to improve the user experience for international customers and users.
This update resolves an issue where Nilvera invoices occasionally got stuck in an 'Unknown' status. The fix ensures Odoo continuously polls Nilvera for the latest invoice status, preventing delays in reporting and reconciliation. This improves the reliability of e-invoice processing with Nilvera.
Original PR description
## Short fix summary:
Nilvera reports `Unknown` as a normal, transient `StatusCode` value (their own e-Archive API docs
list the enum as `unknown`/`waiting`/`succeed`/`error`) right after a document is sent, before their
daily batch resolves the final status. But `_cron_nilvera_get_invoice_status`'s search domain only
matches `l10n_tr_nilvera_send_status in ('waiting', 'sent')`, so once an invoice lands on `unknown` it
is never polled again — even after Nilvera later resolves the real status on their side. This adds
`unknown` to that domain so these invoices keep getting polled until Nilvera reports a final status.
task-6328589
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a formatting issue with numbers displayed in Portuguese (pt_PT) and Hindi (hi_IN) languages within Odoo. It ensures numbers are grouped correctly according to international standards – three digits for Western countries and two digits after the first three for India – improving readability and accuracy. This change ensures consistent and appropriate number formatting for our users in these regions.
Original PR description
Currently the number grouping for Portuguese and Hindi is missing. Number grouping is used to separate long numbers in logical groups to make then easier to read. In Western countries, the grouping is usually done in groups of three digits (e.g. `1,000,000` instead of `1000000`), while in India, the grouping is done in groups of two digits after the first three digits (e.g. `10,00,000` instead of `1000000`). Source: https://www.unicode.org/cldr/charts/48/by_type/numbers.number_formatting_patterns.html#24a93b3d14ba17b2 All languages will be revised in a follow-up `master` PR. [task-6320391](https://www.odoo.com/odoo/project.task/6320391)