Daily updates from Odoo
Monday, November 24, 2025
49 changes
5 changes
Enhancements to existing features
This update brings back the ability to mark specific invoice lines as "No Follow-Up," so they will not trigger payment reminders. It also improves follow-up reports and customer statements so excluded items are handled consistently in views, exports, and reminder emails, while overdue status is not changed when only excluded items remain.
Original PR description
During the rework of the follow-up report, we removed the "No Follow-Up" field from journal items, making it impossible to exclude individual journal items from triggering a follow-up. In this commit…
During the rework of the follow-up report, we removed the "No Follow-Up" field from journal items, making it impossible to exclude individual journal items from triggering a follow-up. In this commit we do the following: - Re-introduce a field for that, since it is a common requirement to be able to exclude individual items from the follow-up reports. The field is stored on the journal item, but can also be toggled from the journal entry. In case of multiple installments on the invoice, toggling the field on one installment will toggle it for all installments. - Adapt the Follow-Up Report and Customer Statement variants of the Partner Ledger to add a toggle for the "No Follow-Up" field on each report line, that toggles the field on the corresponding journal item(s). - Prevent the follow-up status on the partner to change when all of the overdue journal items are marked as "No Follow-Up". - Make sure users can toggle the "No Follow-Up" setting on the invoice level when opening the "Overdue Invoices" view from the partner's "Accounting" tab. - Make sure all receivable/payable lines without a due date (either from a manual miscellaneous entry or a PoS entry) are put under the "Due" section in the Follow-Up Report instead of the "Overdue" section. Since there is no due date, they can't be overdue. - Make sure the PDF and XLSX exports of the Follow-Up Report don't include the "No Follow-Up" lines, and the customer follow up email only includes the amount of the other lines. Backport of https://github.com/odoo/enterprise/commit/74b9d2ef17e4f9a217db8432d886de2eca4baef9 and https://github.com/odoo/odoo/commit/2789a0fbfa358c5c164e44380c2a4a10e5679615 Task: 5138378 Upgrade PR → https://github.com/odoo/upgrade/pull/8864 Forward-Port-Of: odoo/enterprise#99743 Forward-Port-Of: odoo/enterprise#96627
The customer subscription portal no longer relies on a fixed list of billing periods. It now reads the available billing options directly from the system, so custom periods like daily billing can be displayed without causing errors.
Original PR description
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the…
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance. However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value. - Screenshot Order with plan Daily: <img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" /> - Screenshot when trying to get in order on the website: <img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" /> Proposed Solution -------- This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list. The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection). This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance. - <img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" /> Forward-Port-Of: odoo/enterprise#100084 Forward-Port-Of: odoo/enterprise#99207
This update lets Point of Sale and self-ordering connect to local devices like Epson printers and the black box over regular HTTP in modern Chrome browsers. As a result, businesses no longer need to install certificates just to keep these local connections working.
Original PR description
*: pos_self_order, pos_epson_printer Feature: https://chromestatus.com/feature/5152728072060928 Since Chrome 142, a new feature called “Local Network Access” has been added, allowing local IPs to be contacted via HTTP without mixed content errors. This means that certificates are no longer required to contact Epson printers or the black box. Forward-Port-Of: odoo/odoo#236916 Forward-Port-Of: odoo/odoo#235702
This update improves how GSTR-2B processing handles certain errors and avoids retrying records that are already in an invalid state. As a result, background jobs run more reliably and waste less time on records that cannot be processed successfully.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100150 Forward-Port-Of: odoo/enterprise#99378
This update makes website builder tests use the same real content and processing as the live editor, instead of relying on copied snippets. It reduces the risk of test mismatches and helps ensure future changes are validated against the actual website experience.
4 changes
Enhancements to existing features
This change improves how Odoo records screencasts by switching to a lossless H.265 format and removing a setting that was making files much larger without improving quality. The result is more reliable recordings for comparing test runs, while also reducing storage use compared with the previous output.
Original PR description
- `-g 0` turns out to significantly increases file size without increasing quality (apparently it makes every frame an i-frame) - lossless video seems useful for comparing different runs, and while it *is* costly it's pretty reasonable for screencasting (5~6 times the size of a normal output, but a third the size of current outputs) - "lossless h264" (per ffmpeg) does not seem to actually be lossless - lossless av1 does work (and is slightly smaller than h265), but the libsvtav1 shipped by ubuntu does not support it, and libaom is *extremely* slow, so that might be something to revisit in a few years Testing on the main flow tour (desktop), - the current setting generates a 40MB file - removing `-g 0` generates a 2.6MB file, quality seems about the same - h264 pseudo-lossless yields a 9.4MB file - h265 lossless is 16.9MB - av1 (libsvtav1) is 2.5MB - av1 lossless (libaom) is 13.2MB
This update improves how GSTR-2B issues are classified and handled, so one previously unrecognized error is now treated as a warning instead of causing confusion. It also stops background jobs from reprocessing records that are already in an error state, reducing unnecessary work and making the process more reliable.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100150 Forward-Port-Of: odoo/enterprise#99378
This change makes the system much faster when finding delivery records linked to lots/serial numbers. It reduces database work and avoids repeated processing, which means better performance and shorter wait times for large inventories.
Original PR description
### Description: This refactoring replaces the recursive calculation in `_find_delivery_ids_by_lot` with an iterative process. This change significantly reduces the amount of database queries by prefetching and batching all required lines in a single pass, and it also eliminates the overhead caused by repeated recursive function calls. ### Benchmark: | Total Lots | Before | After | |------------|--------|--------| | 69 | 1 sec | 106 ms | | 1152 | 1 min | 5 sec | ### Reference: opw-5096599 Forward-Port-Of: odoo/odoo#236541 Forward-Port-Of: odoo/odoo#233478
Saudi invoices can now be backdated more reliably by letting the invoice issue date be set manually before confirmation. This helps keep Odoo’s invoice dates aligned with ZATCA VAT calculations, reducing the risk of invoices landing in the wrong tax period and improving the accuracy of printed invoices.
Original PR description
Previously, l10n_sa_confirmation_datetime was automatically set when invoices were confirmed, causing issues when users needed to backdate invoices. This created mismatches between Odoo's invoice date recognition and ZATCA's VAT liability calculation, forcing invoices into wrong tax return periods. Changes: - Expose l10n_sa_confirmation_datetime as "Issue Date" in form view - Allow manual setting of l10n_sa_confirmation_datetime before invoice confirmation - Preserve original Issue Date for rejected Phase 2 invoices (400 errors) - Hide Invoice Date field but sync it with Issue Date - Update PDF to display Issue Date instead of Invoice Date - Remove footer date from PDF - Extend future date validation to include Issue Date task-5009969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236865 Forward-Port-Of: odoo/odoo#229517
2 changes
Enhancements to existing features
This update improves how GSTR-2B issues are handled by recognizing an additional return code and classifying it as a warning instead of leaving it unhandled. It also stops background processing from retrying records that are already in an error state, which reduces unnecessary processing and helps keep the workflow cleaner.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100070 Forward-Port-Of: odoo/enterprise#99378
This change updates how messages are sent to IoT Boxes so each device gets its own message instead of sharing one message across multiple devices. This helps maintain compatibility with stable IoT Box versions and reduces the risk of report delivery issues.
Original PR description
In order to ensure ws compatibility with stable IoT Boxes versions, we now split websocket messages to send one per IoT identifier, instead of one targeting multiple ones. related: odoo/odoo#234175 Forward-Port-Of: odoo/enterprise#100205 Forward-Port-Of: odoo/enterprise#100127
15 changes
Enhancements to existing features
Signing templates now organize their field definitions in a dedicated extension point, making future adaptations easier to maintain. This mainly helps teams and partners customize signing workflows with less risk when applying updates.
Original PR description
Introduced a dedicated _getTemplateFields() method to make easier to override or extend the fields in patches. Forward-Port-Of: odoo/enterprise#100096 Forward-Port-Of: odoo/enterprise#95722
The spreadsheet version history panel now uses tile colors with better contrast in dark mode. This makes previous versions easier to read and reduces visual strain for users working with dark mode enabled.
Original PR description
Change the color of the tiles of the version history to have a better contrast in dark mode. Task: [5265478](https://www.odoo.com/web#id=5265478&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Sent email records now keep the exact address used when contacting a recipient. This prevents past notification details from changing if the recipient's partner email is updated later, improving auditability and clarity.
Original PR description
Purpose ======= When we send an email to a partner, we don't store the email used. So if we change the email of the partner, then the email shown in the mail notification won't be accurate anymore. Now, we store that email in `mail_email_address`. Task-5215602
Toolbar buttons in Web Studio now display their matching keyboard shortcuts in their tooltips. This helps users discover faster ways to work and makes common editing actions easier to learn.
Original PR description
This PR updates toolbar button tooltips to display their corresponding keyboard shortcuts. Community PR: https://github.com/odoo/odoo/pull/233741 task-5160025
Field service products no longer carry a separate worksheet template setting when task templates can already provide the worksheet. This reduces duplicate configuration and helps ensure generated tasks consistently use the worksheet defined on the selected task template.
Original PR description
…om product Before this commit, since the adding of a task template in the product settings when the service product will generate a task in a project selected a project with worksheet feature. The user can set a worksheet template and a task template in that product form view. The task template can actually have a worksheet template set to give it to the task that will be generated once a sale order contains that product and is confirmed. And thus, the worksheet_template_id field in the product form view is a bit redundant with the task template. This commit removes the worksheet_template_id field from the product model to let the task template doing the job. task-5213862
Users can now start an AI chat directly while viewing an attachment, with the selected file automatically included as context. This makes it easier to ask questions about documents without manually adding or moving files, while keeping those temporary context files out of the permanent message attachments.
Original PR description
## Summary - Introduced a new AI composer `file_viewer_ai_button` to allow launching AI chat directly from the file viewer. - The selected file is sent as a context attachment along with the message to the LLM. - Context attachments are linked to the message temporarily for AI processing but not stored in `message.attachment_ids`. task-id-5125822
Shop floor users can now adjust the production quantity or split a manufacturing order directly from the Shopfloor interface. This helps teams react faster to changes in demand without leaving their operational workflow.
Original PR description
Add a new menu in Shopfloor to allow changing product_qty and splitting MOs. Task: 5153835
Internal users can now write and edit messages with a richer HTML editor in chatter, Discuss, and live chat. This improves day-to-day communication by making formatting and suggestions more consistent across messaging areas.
Original PR description
This commit enables the html composer for internal users.
This allows internal users to use the html composer to write/edit
messages in the chatter, discuss, and livechat.
1. Uses wysiwyg for internal composer;
2. Adds composer plugin to bind the handlers so that we don't need to
redo it for textarea composer;
3. Adds suggestion plugin to replace the navigable suggestion list;
4. Uses the suggestion plugin in full composer;
task-4454078
https://github.com/odoo/odoo/pull/199806The message composer is being updated to support a richer writing experience, making it easier for users to format and prepare messages. Related tests were adjusted across Documents, Mail, and Helpdesk Live Chat to ensure the improved composer works reliably in key communication flows.
Original PR description
task-2593397
VOIP calls now keep their duration as a stored value, making it easier to filter, group, and total call activity in reports. The call end time is calculated from the start time and duration, helping keep call records consistent and reducing duplicate stored data.
Original PR description
Persist call duration to enable filtering, grouping, and aggregation, and compute end_date on the fly from start_date + duration instead of storing it explicitly. Add a regression test ensuring the stored duration and computed end date stay in sync. upgrade: https://github.com/odoo/upgrade/pull/8891 task-5187543
The return workflow has been streamlined by removing the separate “Validate” step before submission. This reduces extra clicks and makes tax and payroll return processing faster while keeping related submission and locking flows aligned across affected localizations.
Original PR description
task-5155703
Manufacturing orders that require a lot or serial number can now complete without users manually entering one first. This reduces interruptions on the shop floor and ensures related print actions include the newly generated lot or serial information.
Original PR description
Marking a manufacturing order as done without a provided/generated lot/serial number raises with the message "You need to supply a Lot/Serial number for product ...". We want this information to be populated automatically. The automatic report printing actions had to be reworked to include these generated lots/serials, as well as the mrp.batch.produce which previously did not handle them. task: 4595752 See odoo/odoo#209659
Quality checks for repair orders are now generated when the order is confirmed, rather than at initial creation. This avoids unnecessary checks for repairs that are never processed and keeps product or lot-related checks aligned with confirmed work.
Original PR description
- Generate quality checks when a repair order is confirmed rather than when it is created. This ensures that quality checks are only created for repair orders that are actually being processed. - Product and lot updates quality checks only after confirmation. Task [5227065](https://www.odoo.com/odoo/project/966/tasks/5227065) Forward-Port-Of: odoo/enterprise#98815
GSTR-2B processing now recognizes an additional recoverable warning condition and avoids reprocessing return periods already marked with blocking errors. This reduces unnecessary automated retries and helps keep India GST reporting workflows focused on records that can still be processed.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100281 Forward-Port-Of: odoo/enterprise#99378
Signature blocks are now registered in a shared editor category so they can work reliably across different editing experiences. This ensures signatures remain available in Mass Mailing and simple editors, reducing disruption when preparing communications.
Original PR description
### Description of the issue/feature this PR addresses: - The Signature Plugin was defined in the sign module by extending the html_editor plugin under the basic_block category. - The mass_mailing builder removed config.plugins, preventing the Signature Plugin from working. ### Desired behavior after PR is merged: - The category is now defined in html_editor and renamed to modules so other modules can also use it. - Mass Mailing: - Signature Plugin is registered in `mass_mailing-plugins` for mass_mailing. - For simple editor, Signature Plugin is registered in `basic-editor-plugins`. **community: https://github.com/odoo/odoo/pull/190616** task-4224624 Forward-Port-Of: odoo/enterprise#75612
11 changes
Enhancements to existing features
This update corrects how values are calculated in the Coretax e-Faktur XML so they are based on tax group rules instead of invoice type in certain cases. It also adds a safeguard to prevent invalid tax combinations when downloading the XML, helping avoid incorrect reports and making the setup more reliable.
Original PR description
Update Coretax XML file to compute the values for nodes in the correct way. Currently the computation is based on the invoice type for some of the nodes + STLG is based on wrong tax group. This leads to wrong computation of values + inflexibility. - Update the VAT calculation inside the E-faktur XML based on tax group - Add new tax group and modify existing tax - Add restriction when downloading E-faktur Coretax XML Task [#4948267](https://www.odoo.com/odoo/project.task/4948267) Forward-Port-Of: odoo/odoo#236821 Forward-Port-Of: odoo/odoo#233347
When a mass email is also logged in the chatter, its attachments are now linked directly to the related record. This makes them easier for users to find later in the record’s attachments list, improving day-to-day visibility and follow-up.
Original PR description
In [1] the argument to link attachments to messages was that it would automatically clean up the attachments when the message is deleted (typically right after sending). As it originally was kept forever, as we wanted to guarantee that it still exists by the time the email is sent. However in modern ODOO mass emails can, and often are, logged in the chatter. In that case it is relevant to link the attachments to the record directly so that users can see the attachments in the attachments menu of the chatter. [1]: https://github.com/odoo/odoo/commit/cf214ed7244207f1fd5d377ab69d85a6441ff665 task-4829625
The customer portal now reads subscription billing periods dynamically instead of relying on a fixed list. This prevents errors for subscriptions that use custom periods, such as daily billing, and makes future customizations work without extra code changes.
Original PR description
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the…
Problem -------- In v18.0, the day billing period was removed from the sale.subscription.plan model. For our use case, we require daily subscriptions, so we added this value back to the billing_period_unit selection field via inheritance. However, this customization causes an error (a KeyError) when accessing the customer portal at /my/subscriptions/<int:order_id>. This is because the controller logic relies on a hardcoded list of periods and does not account for the new custom "day" value. - Screenshot Order with plan Daily: <img width="1246" height="483" alt="image" src="https://github.com/user-attachments/assets/5dc5ca0d-a2f2-434d-8183-15a0424d9f34" /> - Screenshot when trying to get in order on the website: <img width="1250" height="776" alt="image" src="https://github.com/user-attachments/assets/5b10504e-71e2-4c13-8611-39e8a41e05d1" /> Proposed Solution -------- This PR improves the subscription portal by dynamically retrieving billing periods instead of using a hardcoded list. The portal now reads the available options directly from the billing_period_unit field's selection (i.e., self.env['sale.subscription.plan']._fields['billing_period_unit'].selection). This improves maintainability, as future changes to the field's selection will be automatically reflected without requiring code modifications. This makes the portal robust and automatically compatible with any custom periods added via inheritance. - <img width="1331" height="752" alt="image" src="https://github.com/user-attachments/assets/4f7be6c3-d96b-4525-8e23-6e1323adabde" /> Forward-Port-Of: odoo/enterprise#100084 Forward-Port-Of: odoo/enterprise#99207
This change adds triangular tax handling to Finnish tax reports so they can be used correctly in the EC Sales List report. It improves the accuracy of VAT-related reporting for businesses operating in Finland and across EU sales scenarios.
Original PR description
The aim of this commit is adding the triangular taxes into the tax report to use it in EC Sales List report. task-5126664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236427 Forward-Port-Of: odoo/odoo#229269
This change reduces noise in system logs by stopping the full contents of WebRTC messages from being recorded at the info level. Instead, only the message type and device are logged, which helps keep logs readable and avoids filling them with large receipt data. It also adds timing information for actions, making it easier to monitor performance.
Original PR description
Before this commit, the WebRTC client was logging every message it received in full at the 'info' level. This was causing logs to be flooded with base64 receipt data. We now only log the message type and device. We also now log the action execution time similarly to the websocket client. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes the test runner behave more gracefully when no tests are found, logging a message instead of raising an error. It also improves visibility in headless runs by showing the results of all top-level test suites at the end of execution, making debugging easier.
Original PR description
[FIX] web: Hoot - remove error if no tests This commit replaces the error thrown if there is no test found by a log. --- [IMP] web: Hoot - log root suites at end of run This commit makes the unit test runner log all root suites results after each test run, only in headless mode. Forward-Port-Of: odoo/odoo#236647
The TDS entry form now asks for the TDS Section before the Base Amount. This makes the input flow clearer and prevents the amount from changing after users have already entered it.
Original PR description
Before this commit: - In the TDS Entry wizard the Base Amount field appeared before the TDS Section field, causing users to enter a manual amount that later changed once the TDS Section is selected, since base amount is computed based on it. After this commit: - The TDS Section field is now placed before the Base Amount field to ensure a predictable input flow. task-5312252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change improves how GSTR-2B processing handles certain return-period errors and prevents background jobs from retrying records that are already in an invalid error state. As a result, the system avoids unnecessary processing and reduces noise from known issues.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100150 Forward-Port-Of: odoo/enterprise#99378
We updated how the signature block is registered so it can be used reliably in the Email Builder and Mass Mailing tools. This fixes an issue where the signature option could stop appearing after recent editor changes, helping users keep their content consistent across templates.
Original PR description
### Description of the issue/feature this PR addresses: - The Signature Plugin was defined in the sign module by extending the html_editor plugin under the basic_block category. - The mass_mailing builder removed config.plugins, preventing the Signature Plugin from working. ### Desired behavior after PR is merged: - The category is now defined in html_editor and renamed to modules so other modules can also use it. - Mass Mailing: - Signature Plugin is registered in `mass_mailing-plugins` for mass_mailing. - For simple editor, Signature Plugin is registered in `basic-editor-plugins`. **community: https://github.com/odoo/odoo/pull/190616** task-4224624
This update makes Spanish POS receipts use a consistent, consecutive number when they are not turned into invoices. It helps avoid gaps or resets in the displayed ticket number, so the receipt numbering better matches official requirements and is more reliable across devices.
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
This update adds a Reprocess action so AI source indexes can be refreshed when linked web pages, documents, or knowledge articles change. It also avoids duplicate processing of the same content, which helps keep results accurate while reducing unnecessary system work.
Original PR description
## Summary - Add 'Reprocess' button to enable recomputation of source indexes when URL content, document's documents, or knowledge articles are updated. - When triggered, the system checks for content changes and updates the index for all sources sharing the same attachment across agents. Prevents redundant reprocessing by tracking already processed attachment checksums within each batch operation. task-id-5153627
9 changes
Enhancements to existing features
This change speeds up how product details are loaded during sales product configuration by fetching related data in batches instead of one by one. It reduces waiting time significantly, especially when products have many attributes and values, making the experience smoother for users.
Original PR description
Performing read operations on attributes and values in batch yields a significant performance improvement and is standard practice. Tested with 60 attributes and 8000 values: went from 2.7s to 0.8s (-70%) No task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Importing journal items will now accept lines linked to inactive accounts instead of failing with an unnecessary error. This makes data imports smoother when historical or temporarily disabled accounts are still referenced in the source file.
Original PR description
When importing journal items, if an item targets an inactive account, the import is causing an excessive error. We shall ignore the active/inactive flag in such a case. task-5350113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update changes how Odoo sends messages to IoT Boxes so each device gets its own message instead of a combined one. It helps ensure delivery and reporting features continue to work reliably with stable IoT Box versions.
Original PR description
In order to ensure ws compatibility with stable IoT Boxes versions, we now split websocket messages to send one per IoT identifier, instead of one targeting multiple ones. related: odoo/odoo#234175 Forward-Port-Of: odoo/enterprise#100127
The system now logs only the message type and device for printer websocket events, instead of recording the full message payload. This reduces log noise and helps avoid oversized logs caused by large print data, making troubleshooting easier for support teams.
Original PR description
Before this commit, we logged the full websocket messages received at 'debug' level, and the action device at 'info' level. Logging the whole message causes the logs to be flooded with large base64 print data. After this commit, log the message type and device both at 'info' level. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now includes an additional application information field when sending payment requests to Adyen. This helps ensure the external platform details are transmitted correctly, improving compatibility and reliability of payment processing.
Original PR description
Add applicationInfo to the payload sent to Adyen, ensuring that externalPlatform is correctly transmitted. A test was added to verify that applicationInfo is present in the payload and that the payment request succeeds as expected. task-5157863 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233075
This change lets users import journal items that reference inactive accounts without the import failing. It prevents unnecessary errors and makes data imports more reliable when older or archived accounts are involved.
Original PR description
When importing journal items, if an item targets an inactive account, the import is causing an excessive error. We shall ignore the active/inactive flag in such a case. task-5350113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now uses the newer invoice generation logic by default for more BIS3-based electronic invoice formats. This reduces the risk of inconsistencies across country-specific formats and helps keep maintenance simpler and more reliable.
Original PR description
Since commit 52e984037 we have enabled the new helpers by default for generating BIS3 UBLs. But we didn't enable them in the UBL formats that depend on BIS3 (NLCIUS, XRechnung, Chorus Pro etc). That was to first fix any issues in BIS3 in case the new helpers had broken something. Since the new helpers seem to be working fine for BIS3, we are now making them the default for all the formats that depend on BIS3 as well. We also add comments in the old helper methods to indicate that they are no longer used by default for BIS3 and its extensions. task-none
Colombian e-invoices now handle the plastic bags tax correctly, generating the required XML structure for DIAN. This helps prevent validation errors and allows invoices that include this tax to be submitted successfully.
Original PR description
Before PR: -The plastic bags tax (INC Bolsas) was not handled by a specific flow. -This resulted in incorrect XML generation for Colombian e-invoices, leading to validation errors from the DIAN. After PR: -Dedicated logic flow has been added to correctly handle the INC Bolsas tax. -Generated XML now correctly reports this tax in a separate `TaxTotal` block. -It populates the `BaseUnitMeasure` and `PerUnitAmount` fields with the fixed tax rate per bag. Impact: -Colombian e-invoices that include plastic bags tax are now generated correctly. -Ensures compliance with DIAN's specific requirements for this nominal tax. -Prevents validation errors and allows for successful submission of invoices containing this tax. task-5086926
Financial reports now run much faster by reusing precomputed balance data instead of recalculating the same information many times. This reduces wait times significantly for large reports while keeping the results unchanged.
Original PR description
### Issue Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually…
### Issue
Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually filtered by account_id fields).
### Analysis
Each report line formula independently aggregates balances from account_move_line, even when their domains only differ on account_id-related fields such as account_id.account_type or account_id.non_trade.
This leads to redundant scanning and aggregation of the same dataset multiple times within a single report execution.
### Solution
Introduce a lightweight in-memory caching layer for aggregated balances by account_id, stored in self.env.cr.cache.
For each (options, date_scope) pair:
The report engine now computes once the mapping
{account_id: {'amt': total_balance, 'count_aml_lines': count}}.
This mapping is stored in the cursor cache and reused across all formulas whose domains filter exclusively on account_id fields.
A small domain transformation step allows AML domains based on account_id.* fields to be evaluated directly against the cached account aggregates.
This approach avoids redundant SQL aggregation, remains fully read-only (no database writes), and is safe for execution on read replicas.
### Benchmarks
Profiling get_report_information_readonly on different reports. Database has ~11.6 million account_move_lines, 305 account_accounts, and 16 account_types
| Report Name | Before | After | % Speed Up |
| --- |---|---|---|
| Balance Sheet | 35s | 6.2s | ~550% |
| Profit and Loss | 7.2 | 2.1 | ~300% |
| Cash Flow Statement | 1.5s | 0.4s | ~300% |
| Executive Summary | 24s | 6.3 | ~400% |
### References
opw-51307253 changes
Enhancements to existing features
This change makes Google Places autocomplete more flexible when searching for customer information. Businesses can now adjust the search type to better find locations or establishments, which should reduce cases where no result is returned for valid queries.
Original PR description
Description of the issue/feature this PR addresses: We use the google search autocomplete for completing our clients informations in the application Contact, but for some reasons almost all the times the autocomplete was not working, it was not able to find an address (the same query worked on google search engine). Current behavior before PR: On trying to search the business of a client by name, most of the time no result found. Desired behavior after PR is merged: I would be able to change the base behaviour of the google search api with a custom module by changing the parameter of the method, by changing the types from "address" to "geocode|establishment". This change will change nothing for thoses who don't need this improvement, because the old comportement was kept as a default parameter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds an index to the sales order team field, which helps Odoo find matching sales orders more quickly when users filter by sales team. It improves performance on large databases and reduces delays when opening or searching sales orders.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update replaces the specific name 'Uruware' with a generic 'UCFE Provider' in the Odoo settings for Uruguayan localization. This ensures customers contact Odoo support for assistance and maintains a consistent, clear configuration. The core functionality remains unchanged.
Original PR description
Before: -In the Settings > Uruguay Localization section, electronic invoicing provider was shown as "Uruware". -This could lead customers to contact Uruware directly instead of Odoo support. After: -Replaced all mentions of `Uruware` with generic name, `UCFE Provider`. -Updated labels and descriptions in both testing and production sections. -The overall configuration and functionality remain unchanged. Impact: -Removes direct provider references from the interface. -Ensures customers contact Odoo support for any assistance. -Keeps the configuration clear and consistent for Uruguayan users. task-5244539