Daily updates from Odoo
Navigate
Branch
Tuesday, August 19, 2025
71 changes
40 changes
New functionality added to Odoo
The Point of Sale delivery integration now supports Wolt as an additional food delivery provider. This gives restaurants using Odoo more choice in connecting their delivery operations to external platforms.
Original PR description
Following this commit: - Integrated Wolt as delivery provider in pos_urban_piper. task-4882282 Forward-Port-Of: odoo/enterprise#88222
The Adam Equipment scale driver is now available as a separate module and must be enabled explicitly in Point of Sale settings. This prevents unrelated serial devices from being mistakenly detected as scales, reducing setup confusion for customers using IoT boxes and FDM devices.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/221326 Upgrade PR: https://github.com/odoo/upgrade/pull/8142 Before this commit, the Adam Equipment serial scale driver was included by default on the IoT box. However, this causes issues as there is no way to detect the presence of one of these scales automatically. This caused any unidentified serial device to be registered as an Adam scale, leading to much confusion with customers, especially regarding setting up an FDM. After this commit, the Adam driver is moved into its own module, and a checkbox added to the PoS settings to enable it. This way, only customers who actually need the driver will get it, and everyone else can benefit from not having it wrongly detect devices. task-4954021
Adds a new integration that lets restaurants and other appointment-based businesses offer bookings through Google Maps Reserve. Odoo can share availability, receive new or changed bookings via the IAP service, and keep Google updated when schedules change.
Original PR description
The new appointment_google_reserve module allows to make your restaurant (or other booking based service) available to book via Google Maps Reserve. See: https://www.google.com/maps/reserve…
The new appointment_google_reserve module allows to make your restaurant (or other booking based service) available to book via Google Maps Reserve. See: https://www.google.com/maps/reserve https://developers.google.com/actions-center/verticals/reservations/e2e/overview The integration works alongside with the IAP server, that plays the middleman between the client server and the Google servers. It is split in three main concepts: 1. The Feed files uploads See: https://developers.google.com/actions-center/verticals/reservations/e2e/integration-steps/export-feeds The Google Reserve Service is based on data coming from "feed files", which are manually uploaded once per day via a HTTP call to the IAP servers. IAP servers will take care of the Merchant and Service feed files based on the merchants that registered for this service. The merchant/service registration happens via a HTTP call to the IAP server when an appointment.type is configured accordingly. This is simply done on the appointment.type form by specifying the "merchant" (which is a physical address and some contact details). The same merchant could be re-used between several appointment.types, for example if a hotel allows booking rooms (1 appointment.type) and massages (with a second appointment.type): the merchant is the hotal (same physical location) and the services are both appointment.types. The availabilities for all these services are uploaded to the IAP server with a HTTP call when the IAP server requests them. (See IAP commit message / documentation for more details). 2. The Booking Server See: https://developers.google.com/actions-center/verticals/reservations/e2e/integration-steps/implement-booking-server Once a end-user books something from Google Maps Reserve, they (Google) will hit a certain endpoint on the IAP server with the booking details. IAP then needs to relay this information to the merchant (client)'s, acting as a proxy. The information is then stored accordingly, for example as a new calendar.event record on the related appointment.type. The same principle is applied to other necessary concepts; modify bookings, cancel bookings, ... 3. Real-time API updates See: https://developers.google.com/actions-center/verticals/reservations/e2e/integration-steps/real-time-api-updates This is in a way the same thing as the booking server, but the other way around. Whenever something happens that modifies availabilities for an appointment, including: - Creating a booking directly in the backend - Creating calendar leaves for the appointment resources - Modifying opening hours - ... We need to update the availabilities on Google's side. In that case, the communication is thus initiated by the client server, that contacts IAP. IAP acts as a proxy again by relaying this information to Google. =============================================================================== Limitations: - Only works for auto-assign mode appointment types - Payment and sales related flow are not implemented. Task-3083812 Forward-Port-Of: odoo/enterprise#92457 Forward-Port-Of: odoo/enterprise#82234
Enhancements to existing features
Danish companies can now prepare and send VAT report information from Odoo to the Danish tax authority's online services. The flow also helps retrieve required filing dates, provides a link for official approval on skat.dk, and fetches receipts and payment details after approval.
Original PR description
The Danish government has set up a system enabling users of accounting software to send their tax reports to the government directly from the accounting software. To do this, there are 3 different…
The Danish government has set up a system enabling users of accounting software to send their tax reports to the government directly from the accounting software. To do this, there are 3 different web services: - VirksomhedKalenderHent: This web service returns the dates on which the legal entity must submit its VAT returns. These dates are required to submit VAT returns. - ModtagMomsangivelseForeloebig: This web service submits a draft VAT return to skat.dk with all the fields to be filled in. The web service returns a deep link to skat.dk, where the legal entity can access and approve the submitted VAT declaration. - MomsangivelseKvitteringHent: This web service provides a receipt for the VAT return, given that the legal entity has approved it. This service also includes information on how to pay any outstanding balance. These three web services use SOAP and encryption to function. What we decided to do was to take the SOAP envelopes of the requests and create them by hand and send them to the government portals. task: 3326971 Iap: https://github.com/odoo/iap-apps/pull/1090 Forward-Port-Of: odoo/enterprise#92402 Forward-Port-Of: odoo/enterprise#72094
Belgian Annual Accounts exports from the General Ledger now generate XML files instead of TXT files. This makes the exported data better structured and aligned with official requirements, improving usability for downstream reporting and processing.
Original PR description
The previous Annual Accounts export in the General Ledger generated a TXT file with a fixed column order, which did not meet the structural or formatting requirements for downstream usage. This commit replaces the TXT export with an XML export conforming to the official format, including fields such as account code, debit, credit, multilingual descriptions, and metadata. task-5005345 Forward-Port-Of: odoo/enterprise#92454 Forward-Port-Of: odoo/enterprise#92071
Users enabling UrbanPiper in Point of Sale now see a clearer message when the related module is not yet installed. This helps them understand that configuration will become available after saving, reducing confusion during setup.
Original PR description
In this commit: --------------- - Improved user guidance when UrbanPiper module is not installed by showing a clearer message indicating that they will be able to configure the feature once they save. task: 4939021
Mexican localization now includes additional 16% withholding tax options with specific split distributions, along with the related accounts and fiscal positions. This helps businesses apply the correct tax treatment more easily and improves rounding accuracy for existing 10.67% taxes.
Original PR description
Add few 16% taxes with special distribution (1/3 - 2/3 and 1/4 - 3/4). Also add few accounts and a new fiscal position for each new tax. Also adjust the rounding precision of 10.67% taxes. Linked:https://github.com/odoo/odoo/pull/206406 task-4571928 Forward-Port-Of: odoo/enterprise#92347 Forward-Port-Of: odoo/enterprise#83582
Point of Sale IoT printing now uses the updated shared printer component and handles IoT report closing more reliably. This helps keep printing-related workflows aligned with platform changes and reduces the risk of incorrect behavior after reports are processed.
Original PR description
In this commit =============== - Updated BasePrinter import to use the new base_printer module. - Improved iotReportActionHandler to return a flag indicating whether to close the IoT handler or not. Task-4655597 Related community PR:https://github.com/odoo/odoo/pull/207886
Audit balance progress now focuses on accounts that have an audit status, giving users a more accurate view of completion. The update also improves audit return setup screens, search options, and visibility of audit state across localized balance sheets, reducing confusion and preventing an error when creating certain returns.
Original PR description
* On Audit, balances progress bar counts only accounts with states different than none. * When Audit type on return type form, hide non-related fields. * Fix traceback when creating a return for new actionable checks. * In check template search view, add Title to be searchable * Show Audit State on localized balance sheet accounts * task-4991558
The HR interface now uses “employee record” instead of “version” across payroll, salary, and related workflows. This makes labels and menus clearer for users managing employee information, improving day-to-day usability without changing core business processes.
Original PR description
In this PR, we renamed the version into employee record for a better UX. Related task: 4921404.
The Turkish Profit and Loss report now includes 700-series accounts, which are used during the accounting period before being closed into 600-series accounts. This makes the report more useful for local businesses and accountants by supporting more up-to-date financial visibility during the period.
Original PR description
The current Profit and Loss report has some limitations that inhibit its proper adoption as it does not enable the user to use the report in real-time since it excludes the 700 accounts (accounts used within a period until their closing to 600 accounts.) Therefore, this limits the usefulness of the report for local businesses and accountants. In this task, we included the 700 accounts in the report to enable real-time reporting for our users task-4809142
HR teams can now edit employee leave requests even after they reach the approval stage, provided the leave has not already been included in a payslip. This gives administrators more flexibility to correct or update leave records before payroll processing locks them down.
Original PR description
- Allowing HR people to always edit the leave, as long as it's not included in a payslip. task-4866887
IoT administrators can now configure remote debugging directly from the IoT app instead of relying on more manual setup steps. This makes support and troubleshooting easier when devices need remote assistance.
Original PR description
To ease remote debug configuration, we add the possibility to configure remote debug from the IoT app, using the websocket. Community PR: odoo/odoo#216318 Task: 4865987
Signer roles can now have a default contact assigned, so that person is automatically filled in when creating a signature request. Users can still change the signer manually, reducing repetitive entry while keeping flexibility.
Original PR description
In this commit, - added a new field on the Signer Role to link a default Partner. - On the Sign Item Role form, user can now select a default partner. - This partner will be automatically pre-filled as the signer in the sign request wizard. - The default can still be changed manually if needed. task-4812381
This update lets teams use a Google Gemini access token from the local environment when testing AI features. It simplifies development and local server setup without changing the normal user experience.
Original PR description
Makes it easier to test gemini llms during development or when running the server locally.
Subscriptions now return to active status when their invoice is paid, including payments made by bank transfer or other manual methods. This prevents paid customers from remaining incorrectly marked as churned, while still respecting the allowed automatic closing period.
Original PR description
Before: - A subscription is reopened only when a customer pays through the portal. - Manual payments do not reopen the subscription. - invoice is paid but subscription remains churned. After: - Subscriptions now reopen when invoice paid through bank transfer. - Additionally, reopening is the subscription will only reopen if the next_invoice_date is within the allowed automatic closing limit (next_invoice_date >= today - automatic closing limit). Impact: - Paid invoices now always bring the subscription back to active status task-4277444 Forward-Port-Of: odoo/enterprise#92367 Forward-Port-Of: odoo/enterprise#73136
Studio app creation now handles suggested options more predictably. Pipeline stages no longer add custom sorting automatically, while custom sorting clearly controls whether sorting fields appear, making new app setup easier to understand.
Original PR description
This commit refines the behavior of suggested features during app creation in Studio to ensure better consistency and clarity: - Enabling the Pipeline stages option no longer automatically adds the sequence field. - The Custom sorting option now solely determines whether the sequence field is added to list and kanban views. - In list views, the priority and sequence fields are no longer mutually exclusive; both can coexist. However, when both are present, priority takes precedence for sorting (as in kanban). task-4909220
The Dutch Tax Report layout has been improved to make amounts easier to understand. It now uses fewer lines and separates taxable base amounts from tax amounts more clearly, helping users review and submit tax information with less confusion.
Original PR description
The Dutch Tax Report Can be Improved - less lines by adding a distinct tax col - clear distinction between base amount and tax amount ----- This is fixing the XBRL report after this PR: https://github.com/odoo/odoo/pull/222442 task-5000683
Helpdesk teams can now create and track replacement deliveries directly from a customer support ticket. This improves visibility for agents and customers by logging replacement activity and notifying ticket followers when delivery status changes.
Original PR description
- Create a `replacements` option in the helpdesk team settings - Create a `Replace` action button in the helpdesk ticket form - assign default values of the new replacement order - create a `Replacements` stat button in the helpdesk ticket form - allow the creation of the new replacement form the stat button with the right defaults - Set visibility rules for the stat button - log replacement creation in the ticket chatter- log ticket reference in the picking chatter - add a `delivery status` notification subtype to tickets - make notifications to the followers on the delivery stage update - make `Replacements` active for `VIP Support` helpdesk team in demo data task-4781271
The VoIP SMS interface now uses the more familiar phrase "text message" instead of "SMS". This makes labels and actions clearer for English-speaking users and reduces confusion in day-to-day communication workflows.
Original PR description
According to feedback, "SMS" is not a really common word in English. "Text message" is more frequent. Part of task-4938144
The VoIP CRM lead button now shows a label that better matches the user's situation. It indicates whether the user can create a new lead or view existing leads, reducing confusion during call handling.
Original PR description
Previously, the lead button always displayed 'Lead' as its title, regardless of context. With this change, the button title now adapts based on opportunity count — showing 'Create Lead' or 'View Leads' appropriately. Task-4938144
Forum-related pages now point users to the current profile page address instead of an old forum-specific address. This helps prevent broken links and keeps navigation consistent after the route change.
Original PR description
Update /forum/user/<int:user_id> to /profile/user/<int:user_id> as we have removed that route (see odoo/odoo#217984). Task-4921396
Resolved issues and error corrections
Manual tax calculations now also keep the original taxable base amounts, not just the tax amounts. This helps external tax integrations such as AvaTax and Brazil AvaTax produce more complete and reliable accounting data, reducing discrepancies in invoices and tax reporting.
Original PR description
…unts Forward-Port-Of: odoo/enterprise#92478
A payroll-related test was moved to the correct accounting test area so payroll can be tested independently. This helps prevent test failures when only the Belgian payroll app is checked, improving release reliability without changing user features.
Original PR description
Previously a test created on l10n_be_hr_payroll depended on account module, which broke single app tests. This commit moves the test from l10n_be_hr_payroll to test_l10n_be_hr_payroll_account [Old PR](https://github.com/odoo/enterprise/pull/89149) Task: 4942293 Forward-Port-Of: odoo/enterprise#90144
Egyptian payroll now applies the exempt amount before calculating income tax. This helps prevent employees from being charged too much tax and improves payroll accuracy.
Original PR description
Issue: - The income tax calculation in Egyptian payroll did not properly account for the exempt amount. - This could result in over-calculating tax for employees by not applying the exemption. Fix: - Updated the 'Taxable Amount' salary rule to correctly apply the exempt amount before tax is calculated. Task-4815156 Forward-Port-Of: odoo/enterprise#86395
Payroll users can now filter employees by name when creating a new pay run. This fixes a broken search filter, making it easier to find the right employees and reducing manual effort during payroll preparation.
Original PR description
Originally, when creating a new payrun, if you filter by employee name, the filter doesn't work. The filter logic has been adjusted to search for the correct field. Forward-Port-Of: odoo/enterprise#89877
Swiss payroll-specific employee fields are now only shown for Swiss companies. This avoids confusion in multi-company setups where users work with companies from other countries.
Original PR description
When using odoo in multi company with Swiss installed, we can see the fields from any other company. They should be hidden if the country is not Swiss. Task: 4788657 Forward-Port-Of: odoo/enterprise#89893
The Belgian payroll salary configurator now calculates the laptop benefit in kind consistently with other benefits such as internet and mobile phone. This helps ensure employee salary offers and payroll-related values show the correct laptop benefit amount.
Original PR description
The benefit in kind laptop salary rule was not adapted for the salary configurator. This commit fixes the issue by always returning the correct laptop value if the salary rule is used in a salary configurator, like it is already the case for the internet and mobile benefits. task-4971722 Forward-Port-Of: odoo/enterprise#92520 Forward-Port-Of: odoo/enterprise#91201
This fix ensures payments made through the customer portal for subscriptions are properly connected to the invoice that is created afterward. Business users can now see the related payment from the invoice, improving payment tracking and reducing confusion during subscription billing follow-up.
Original PR description
### Steps to reproduce: - Activate a payment method - Create a subscription and preview it in portal view - Pay this order through the order's portal view - Navigate to the invoice got generated -…
### Steps to reproduce: - Activate a payment method - Create a subscription and preview it in portal view - Pay this order through the order's portal view - Navigate to the invoice got generated - Notice there is not 'Payments' smart button ### Cause: Since https://github.com/odoo/enterprise/pull/77432/commits/02f72f94b7c996fa19c6bfc70a704d27aa677245 we stopped creating the invoice before the payment and the transaction in the controller and we let _post_process do this invoice creation. So the invoice actually gets created after the payment not before and when preparing the payment values the invoice_ids will be False https://github.com/odoo/odoo/blob/6c88e6ffd2c906b72b31d3c34ad3d6da5efba204/addons/account_payment/models/payment_transaction.py#L155-L170 Then we create the invoice for the transaction and we don't propagate it to the payment. https://github.com/odoo/enterprise/blob/20fd574367757c06f30c344056e8b8d91ba8244c/sale_subscription/models/payment_transaction.py#L72-L84 ### Fix: Link the payment to the invoice after creating the invoice and link it to the transaction. opw-4867631 Forward-Port-Of: odoo/enterprise#91690
Employee approval contacts are now recalculated based on the employee's current manager. This helps keep timesheet approval responsibilities accurate when reporting lines change.
Original PR description
To update the approvers information for employee according to his manager, the logic of computing each field has been modified.
Adding a column to a customized report table now uses a layout element that does not add unwanted spacing. This prevents table alignment issues and helps edited reports keep a cleaner, more consistent appearance.
Original PR description
Before this commit when adding a column into a modified qweb table (q-table node) we inserte a `p` as the cell's first child. This was problematic as a margin was always present, messing with the whole table alignment. After this commit, we put a simple DIV. task-5005441 Forward-Port-Of: odoo/enterprise#92085
Tickets created from Timesheets now automatically use the helpdesk team linked to the selected project. This prevents new support tickets from being assigned to the wrong team and limits team choices to those configured for timesheets.
Original PR description
Steps to Reproduce: - 1. Go to Timesheets > My Timesheets, start the timer, and select the project linked to the helpdesk team. 2. In the timer header, quick-create a new ticket via the "Ticket" field dropdown 3. Observe that the default helpdesk team on the new ticket is incorrect. Issue: - - When creating a ticket from the Timesheets module (e.g., via timer header or views), the system selects an incorrect default helpdesk team, leading to misassigned tickets. Cause: - - The core default logic for team_id prioritizes user membership or the first team without considering the selected project's linked helpdesk team. Fix: - - Override `_default_team_id` to set the correct Helpdesk Team based on the selected project. - A domain has been added to the team selection field within the timesheet views to only show teams that have the timesheet feature enabled. task-4885679 Forward-Port-Of: odoo/enterprise#92227 Forward-Port-Of: odoo/enterprise#89503
This fix prevents errors during fast payment when the order is not yet available on the payment screen, especially with automatic receipt printing and refunds. Businesses using affected POS localizations and payment integrations should see smoother checkout flows with fewer interrupted transactions.
Original PR description
*: l10n_cl_edi_pos, l10n_ke_edi_oscu_pos Before this commit: ---------- - TB appears when the order is not available on the payment screen, while fast payment is running on the product screen with automatic receipt printing, and getting refund lines. - Shifted logic before validation from the payment screen to the POS store. After this commit: ----------- - Fast payment is working seamlessly with automatic receipt printing. Related: - https://github.com/odoo/odoo/pull/216523 task-4874273
Expense reports created from uploaded receipts can once again have their names filled in automatically by OCR. This prevents users from being left with generic “Untitled Expense” labels and improves test coverage to avoid the issue returning.
Original PR description
The combination of the following recent changes prevented the OCR from filling the name of the expense: - New expenses are named "Untitled Expense {date}" by default instead of the name of the…
The combination of the following recent changes prevented the OCR from filling the name of the expense:
- New expenses are named "Untitled Expense {date}" by default instead of the name of the attachment (see commit odoo/odoo@ca1f644).
- The OCR doesn't override the name if it's not set to the default value (see commit 5c813dc).
The first commit didn't update the default expense name that was used in the OCR code, it was still computed from the attachment name.
After the second commit, the OCR couldn't fill in the name of the expense anymore, since it was expecting the name to be the attachment name, but it was "Untitled Expense {date}" instead.
This is fixed by checking that the expense name contains "Untitled Expense" (and taking translation into consideration).
This commit also improves the tests in multiple ways:
- For the `test_auto_send_for_digitization` test, it now mimicks an upload of the document to force the creation of the expense with the default name, this should prevent this from happening again.
- It now uses an actual PDF document instead of "fake" attachments.
- Minor clean up.
task-[4684825](https://www.odoo.com/odoo/project/967/tasks/4684825)
Forward-Port-Of: odoo/enterprise#92324This fixes an issue where partially processing lot-tracked receipts in the barcode app could incorrectly increase the expected quantity when users returned to the receipt later. The change keeps backorder and grouped barcode lines aligned so inventory demand remains accurate.
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back…
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back to the picking register the 9 remaining units - Exit the picking and comeback #### > The demand of the receipt has been updated from 10 to 19. ### Cause of the issue: Exiting the picking will launch a call of the `post_barcode_process` in order to keep track of the changes you made without changing the initial demand: https://github.com/odoo/enterprise/blob/c26c21cec14a234021bb13bbc2684334bc64b70b/stock_barcode/models/stock_move.py#L50-L53 THe first time you enter the picking you have a single move with a quantity of 10. The first time you exit, since you have set a qty_done of 1 (and hence have updated the quantity of the associated move to 1), the `split_uncompleted_moves` will then create a move for a quantity of 9 in order to keep 10 units assigned. The second time you enter the picking both moves are grouped in a single line since the product is tracked by lot, however, when you update the qty_done of that grouped line you will actually only update the quantity of the first move line and its related move. Since the `_truncate_overreserved_moves` was not designed to handle these grouped lines, it does not notice that the combined reservation overcomes the actual demand. opw-4731803 Forward-Port-Of: odoo/enterprise#91381 Forward-Port-Of: odoo/enterprise#89967
Odoo now avoids showing an incorrect activity note that a payment was removed from a batch when it actually remains there. This keeps payment batch records clearer and helps users trust the history shown during batch validation.
Original PR description
When validating a batch that includes payments in process (e.g., without journal entries), Odoo incorrectly logs that the payment was removed from the batch, even though it remains. This commit fixes the chatter message by not possessing the write method of the account_payment if batch_payment_id not in vals. task-5011672 Forward-Port-Of: odoo/enterprise#92197
The VoIP softphone now shows the correct place to configure the PBX server when setup is incomplete or incorrect. This helps users resolve connection issues faster by pointing them to the right settings area.
Original PR description
Previously, the error message shown to fix setting in general setting. After this commit, the error message shows the correct location of the PBX server. task-5022401
Non-recurring products sold through upsell sales orders are now included in the Sales Analysis Report. This helps businesses see complete delivered quantities and revenue for one-time products, improving reporting accuracy.
Original PR description
Problem: The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate…
Problem:
The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate reporting.
Purpose:
To ensure that non-recurring products added through upsell Sales Orders are correctly included in the Sales Analysis Report (report_all_channels_sales_action). This fix updates the report's domain filter to include upsell orders when the product is not recurring, resolving the issue of missing sales data for such products.
Steps to reproduce the bug:
1. Create a Sales Order (SO):
Add two products to the order:
- One recurring product (e.g., a subscription-based product with a recurring billing policy).
- One non-recurring (standard) product.
2. Confirm the SO
3. Generate an Invoice for the confirmed SO.
4. Validate the Invoice and deliver the non-recurring product (process the delivery order fully).
5. Create an Upsell Sales Order:
- From the original SO, create a new upsell SO.
- Add the same non-recurring product again.
6. Navigate to the Non-Recurring Product Page:
- Open the Product form for the non-recurring item.
- Click on the "Sold" smart button (shows delivered/sold quantities in the past 365 days).
- This opens the Sales Analysis Report (report_all_channels_sales_action) filtered by this product.
Issue:
The upsell Sales Order is not included in the Sales Analysis Report for the non-recurring product. As a result, the delivered quantity or revenue from upsell SOs is missing from the report for non-recurring products.
opw-4940977
Forward-Port-Of: odoo/enterprise#92559Fixes an issue where running the same WhatsApp marketing automation test more than once could cause an error. This helps users validate campaigns repeatedly without interruptions before launching them.
Original PR description
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration *…
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration * Marketing Automation > New > Start From Scratch > Add a new activity * Select Activity Type as Whatsapp Message and a Whatsapp Template * Launch a Test > Pick a contact > Launch > Run (Do this step twice) **Error:** `ValueError: Expected singleton: marketing.trace(6, 4, 3, 2, 1)` **Cause:** This error occurs because the variable `trace` contains multiple records, but the `process_event` method is being called on the entire recordset. Since `process_event` uses `self.ensure_one()`, it expects exactly one record, and therefore raises an error at [1] when multiple records are passed. **Solution:** * Handle trace records one by one using a loop. [1]: https://github.com/odoo/enterprise/blob/624b18bdb5dff0df4756c4e1d37a696631e57a05/marketing_automation_whatsapp/models/marketing_trace.py#L20 **Sentry-6772553612** Forward-Port-Of: odoo/enterprise#91207
WhatsApp template previews now avoid treating underscores inside URLs or similar text as italic formatting. This prevents portal links and access tokens from being displayed incorrectly, while still allowing intended italic formatting when underscores are separated by spaces.
Original PR description
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current…
Steps to reproduce: 1. Go to a WhatsApp template, for e.g. Sale Order. 2. Update the sample value for the Portal Link variable to include an underscore. 3. Click on Preview Issue: Due to the current regex, we will apply italic to any underscore we find which is not ideal, mostly when we work with URLs that can contain underscores like "acces_token" which we will try to apply italic to it too. Solution: Following the most common logic for italic formatting, we will only apply italic formatting when the underscore is surrounded by whitespace. This is the same way it already behaves in Whatsapp. If we write it like_this_for example, it will not apply italic formatting, but if we write it like this _this_ it will apply italic formatting. So this for example: **"If we write it like_this_for example"** Will be like - before the fix: **"If we write it like<i>this</i>for example"** Will be like - after the fix: **"If we write it like_this_for example"** opw-4720017 Forward-Port-Of: odoo/enterprise#91217
31 changes
Security fixes and vulnerability patches
Copied links from public or portal chatter now open the correct page instead of an unauthorized access page. The change improves customer and visitor access to shared discussion links while preventing token exposure for documents they cannot read.
Original PR description
Before this commit, links produced by the "Copy Link" action on portal or public chatters would redirect to an unathorized page. This happens because the route used in the link would check access rights to the message, which public and portal users usually don't have. This commit fixes the issue by overriding the link route in modules with public chatter such that it would redirect to the page containing the chatter. This commit also removes the possibility to copy links of messages inside portal documents for which a user has no read access to avoid leaking the access token. task-4551910
Enhancements to existing features
This update adds automated checks to make sure barcode lookup correctly retrieves product information and supports product creation across point of sale, stock barcode, and website flows. It helps reduce the risk of errors when teams use barcode-based product setup in day-to-day operations.
Original PR description
*: pos_barcodelookup, stock_barcode_barcodelookup, website_product_barcodelookup In this commit: ------------------- - Added tests for barcodelookup to check whether the data fetched and set properly. - Added tests in respective modules to check the flow and creation of the products using barcodelookup. task - 3920661
Resolved issues and error corrections
This fix ensures Odoo consistently waits for file uploads to finish before users can send messages or manage attachments. It prevents confusing behavior such as attachments being deleted too quickly or messages failing when sent with the Enter key while an upload is still in progress.
Original PR description
\* = im_livechat, website_slides Not waiting for the uploading state to be resolved can lead to unexpected behavior, such as deleting the attachment immediately when clicking on the delete button rather than showing the confirm dialog. This might also prevent the composer from being sent if the attachment is still uploading. This is checked when checking the enabled state of the send button when clicking on it, but it is not checked when pressing enter directly. Some tests also checked uploading was finished but didn't target the correct attachment. https://runbot.odoo.com/odoo/error/230901 https://github.com/odoo/enterprise/pull/92620
This fix restores the review summary information shown in portal rating areas, so customers and visitors can see rating feedback as expected. It also updates related portal and website modules plus tests to prevent the issue from returning.
Original PR description
*: portal_rating, rating, test_mail_full task-4853416
Inter-company customer invoices now correctly display lot and serial numbers for delivered products. This helps businesses keep accurate traceability records when selling between companies in the same Odoo environment.
Original PR description
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2…
### Steps to reproduce: - In the settings enable: "show serial numbers/lot on invoice" - Create a product tracked by SN and put SN001 in stock - With company 1, create and confirm an SO for company 2 (`partner_id`) - Validate the delivery (using SN001) - Create and confirm the invoice associated to the SO. - Print the delivery #### > The lots and serial numbers are not displayed but they would be for any other customer type. ### Cause of the issue: Since 17.2 (commit 08536d687880ca6d9ad5c37b639c0ad4c2599d74), the `location_dest_id` of a delivery for a inter-company partner is set to the `Inter-company transit` location: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/stock/data/stock_data.xml#L54-L60 However, the lots are only displayed on the invoice if the usage of either the location or destination of the move line is `customer`: https://github.com/odoo/odoo/blob/23e63f4394c72939286e00d54ffd5da98d034d24/addons/sale_stock/models/stock.py#L60-L64 which fails for the `Inter-company transit` which is a transit location. opw-4962700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how Odoo tracks changes to an electronic invoice identifier after a previous field rename. It has minimal day-to-day impact, but helps avoid issues for customers who customize screens or workflows to use this field.
Original PR description
In previous PR [1], we renamed field `ubl_xml_id` to `ubl_cii_xml_id`, but failed the compute dependencies. It has next to no impact since this field it not in views, but could lead to problems if people add it through Studio. [1]: https://github.com/odoo/odoo/pull/115627/files#diff-5f7f5f6e9c54527b31f7579db7ef63b5b910794e462cd3346e32387900c13efdR12 task-none Forward-Port-Of: odoo/odoo#223259
This update corrects invalid formatting in delivery reports that could cause problems when editing or generating reports. It helps ensure delivery documents display reliably and avoids issues in the report editor.
Original PR description
because of odoo/odoo#169512, there was some illegal html generated in the delivery report. Indeed a <div> in a <p> is not supported. This created issues in the reportEditor, and possibly elsewhere 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
Combo products now keep the correct pricelist discount from product page through checkout. This prevents customers from seeing misleading original prices or a crossed-out zero price, improving pricing clarity in online purchases.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a combo product; 2. create a pricelist that gives a 10% discount on the product; 3. go to product's website page; 4. observe the displayed discount; 5. add product to cart; 6. go to checkout. Issue ----- The discount has disappeared, instead it displays the original price next to a stricken-through "$ 0.00" Cause ----- The `_compute_discount` method does not get the correct `pricelist_item_id` for the combo items. Additionally, on checkout, it shows the `price_unit` of the combo line in the strike-through, which is always 0. Solution -------- When computing the discount of a combo item, retrieve the discount of its linked line, which has the correct value. Additionally, when displaying a combo product in eCommerce, use `_get_display_price_ignore_combo` instead of the `price_unit`. opw-4968848
This fixes an intermittent issue in point-of-sale loyalty testing by ensuring the customer appears consistently at the top of the selection list. The change helps keep automated checks stable so loyalty features can be validated more reliably before release.
Original PR description
This commit make sure that the partner is always at the top of the list runbot-230704
Purchase orders now recalculate the company total when the order currency is changed. This prevents outdated totals from being shown after currency changes, improving accuracy for purchasing and reporting.
Original PR description
**Steps to reproduce:** 1. Create a Purchase Order (PO) with a non-company currency (e.g., EUR if the main currency is USD). 2. Add at least one order line so the "Amount Total" is greater than zero. 3. Change the currency of the PO to a different one and save the record. **Expected behavior:** The `Company Total` field is recomputed using the new currency's exchange rate. **Actual behavior:** The `Company Total` remains unchanged, still showing the value in the original currency. **Fix:** Add `currency_id` to the `@api.depends` decorator of the `_amount_all` compute method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updating a parent or child contact no longer raises an unnecessary error when one VAT number is blank and the other is empty. This prevents avoidable disruption while still protecting accounting consistency for existing journal items.
Original PR description
An error exists if we update the parent partner and the the VAT number does not match with the child partner to prenvent inconsistencies between journal item created before the change. This error is also triggered when one partner vat is '' and the other is False. This commit aims to fix that. opw-4915851
Fixes an issue where completed manufacturing orders could not be unbuilt if their components were later changed to require lot or serial tracking. This lets businesses reverse eligible production orders without unnecessary blocking errors while preserving normal tracking rules for components that were tracked originally.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes a regression when using the _Unbuild_ feature on a previously completed `mrp.production` whose components did not originally…
**Description of the issue/feature this PR addresses:** This PR fixes a regression when using the _Unbuild_ feature on a previously completed `mrp.production` whose components did not originally require tracking (no lot/serial), but have been updated later to require it. When unbuilding such a product, `stock.move.line._action_done` currently raises a UserError requiring a lot/serial number, because the component moves created by `mrp.unbuild`: - do not have a picking_type_id, - are not inventory moves, - are not scrap moves, - and lack lot/serial information. However, in this context, the lot requirement is misleading, as the original `mrp.production` did not generate tracked components. It is valid to restore untracked components even if they are now tracked. **Current behavior before PR:** - Create an `mrp.production` for a product with untracked components. - Complete the production. - Later, enable lot tracking on one or more of the original components. - Attempt to unbuild the production. - ❌ Error is raised: “You need to supply a Lot/Serial Number for product…” **Desired behavior after PR is merged:** - The unbuild operation proceeds without error. - The untracked components are restored correctly. - Behavior remains unchanged for tracked components that did require lot info during the original MO. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217282
Dutch Peppol invoice XML files now use the correct identifier scheme when the company ID is a 20-character OIN number. This helps ensure NLCIUS e-invoices are accepted and interpreted correctly by recipients and Peppol systems.
Original PR description
## Short functional explanation of the error For Dutch companies, when downloading the NLCIUS file of an invoice, the schemeID of the companyID in the XML isn't correct. ## Reproduction Steps 1. Make…
## Short functional explanation of the error For Dutch companies, when downloading the NLCIUS file of an invoice, the schemeID of the companyID in the XML isn't correct. ## Reproduction Steps 1. Make sure you use a dutch company: in apps, download the 'l10n_nl' and 'account_edi_ubl_cii' modules. Then, click on your company and select the NL Company. 2. Go to settings and type Peppol. Under Customer Invoices, check the Peppo format. Then, setup a Peppol Endpoint. Hit save. 3. Go to the Accounting app and click on the customers tab, then invoices. Click on new. 4. Select a customer. Make sure that the customer is from the Netherlands, has an email address, and in the accounting tab, an account number. Still in the accounting tab, under Electronic Invoicing, set the format at NLCIUS, set a Peppol e-address and a Peppol Endpoint that is 20 characters long. 5. Add a product, click confirm then Send & Print. Make sure that NLCIUS is well checked and click again Send & Print. 6. In the bottom right corner of the page, just under the Amount Due, there's a paper clip icon. Click on it and you'll see the XML. Download it. ### Expected behavior As the CompanyID is 20 characters long, the schemeID next to the CompanyID should have the value of 0190. ### Unexpected behavior If you scroll a bit, you'll see that the SchemeID next to the CompanyID has a number of 0106. ## Origin of the issue In the code, the SchemeID will have a value of 0190 if the CompanyID is 9 characters long. __ opw-4943262 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219424
The website events list now uses the visitor’s local day when applying the “Today” filter, instead of relying on UTC. This ensures events are shown on the correct date for users in different time zones, avoiding missed or incorrectly listed events.
Original PR description
The filters use today in UTC to fetch events in db. The commit fixes this by located today first and then converts it in UTC. related odoo/odoo@bfd55de7c846a0d523e4de4b17020341d8fcfd23 task-4796181
The Australian localization now treats the GST Only on Imports tax as fully included for customs calculations again. This restores the intended tax setup so import-related accounting reports and transactions calculate GST correctly.
Original PR description
It was price_include before and got removed with the changes from https://github.com/odoo/odoo/commit/be308e106ce9699f99efe133976c40519d6128f9 Re-add them 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 fix prevents vendor bills or invoices marked as blocked from being automatically unblocked during reconciliation or related accounting updates. It helps preserve payment controls and avoids accidentally allowing payments that were intentionally put on hold.
Original PR description
Problem: When the `payment_state` field on `account.move` is automatically computed, the logic will prioritize whether the move has been posted over whether it has been blocked. The effect is that if…
Problem: When the `payment_state` field on `account.move` is automatically computed, the logic will prioritize whether the move has been posted over whether it has been blocked. The effect is that if an invoice has been marked as blocked, it might be automatically unblocked during reconciliation. Solution: The `_compute_payment_state` method will now prioritize a move's `payment_state` being blocked over whether it has been posted. This prevents a blocked move from being unblocked unexpectedly. Steps to Replicate (Runbot 18) - Create a product - Track inventory - Cost > 0 - Control policy = On ordered quantities - Product category is valuated in real-time (Inventory Valuation - Automated) (requires 'Stock Accounting Automatic' group) 1. Create a PO for the product 2. Create a bill, validate it 3. Block the bill using the contextual action 4. Receive the product If you navigate back to the Vendor Bill, you will see that it has been unblocked. opw-4981799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Saudi Arabia point-of-sale receipts now encode the local KSA time in their QR codes instead of UTC. This ensures scanned e-invoice details match the printed receipt and follow ZATCA expectations.
Original PR description
**Problem:** If you have an SA company, and try to scan the QR code generated on the receipt, the time will be the UTC time instead of the KSA time, as we are in SA. **Steps to reproduce:** - Change your company to SA and install l10n_sa_pos - Make a purchase with a customer from SA - Scan the QR code from the receipt using an app such as E-invoice QR reader - The invoice date will be the UTC time, or 3 hours less than it should **Why the fix:** Before this fix, the time was always displayed as UTC. It could have been correct if it also displayed a 'Z' in the end, to indicate that it is not local KSA time. We now directly change it using the KSA time, to respect the ZATCA guidelines. The time is now the same on the printed invoice and in the app when scanning the QR code. opw-4769521
Slovenian domestic customers without a VAT number are now assigned the correct domestic fiscal position instead of being treated as EU customers. This prevents domestic sales revenue from being posted to the wrong accounts, improving accounting accuracy for Slovenian businesses.
Original PR description
Before this PR: - Domestic customers without VAT were incorrectly mapped to EU fiscal position, causing domestic revenue accounts (760000) to be mapped to EU accounts (761000). After this PR: - Added new domestic fiscal position for non-VAT customers to ensure proper account mapping for domestic transactions. Task-4918960 Forward-Port-Of: odoo/odoo#217311
## Versions 18.0+ ## Issue The icon's class is changed from `fa fa-bell` to `fa fa-bell me-2` when rendering making the translation unable to find the spot ## Steps to reproduce - Ensure at least 2 languages (with at least one different from English) are set for the website; - Go to a published product without variants (e.g. "Office Chair"): - Ensure the "Track Inventory" checkbox is checked under "General Information" tab; - Set its stock quantity to 0 or less; - Under the "S
Original PR description
## Versions
18.0+
## Issue
The icon's class is changed from `fa fa-bell` to `fa fa-bell me-2` when rendering making the translation unable to find the spot
## Steps to reproduce
- Ensure at least 2 languages (with at least one different from English) are set for the website;
- Go to a published product without variants (e.g. "Office Chair"):
- Ensure the "Track Inventory" checkbox is checked under "General Information" tab;
- Set its stock quantity to 0 or less;
- Under the "Sales" tab, ensure the "Out-of-Stock" checkbox ("Continue Selling") is unchecked;
- Click the "Go to website" smart button;
- Change the website's language for the non-English one;
- As out of stock, as to get notified when the product is back in stock:
- Submit the email address.
opw-4955314Event reminder emails now follow the language selected by the website visitor during registration. This keeps reminder messages consistent with confirmation emails and avoids sending English reminders to attendees using another installed language.
Original PR description
How to reproduce this bug: 1- Create a db with only one language installed e.g. fr_FR and event app installed 2- Create an event and publish it on the website 3- Register for the event using public user 4- The confirmation email is in fr_FR but the reminders are in English This is caused because partner_id.lang is empty as a public user. The correct way to fetch the visitor lang is by `visitor_id.lang.id`. opw-4794184
This fix makes tests consistently verify that files show an uploading state when they are added in messaging, knowledge, helpdesk, spreadsheet comments, and WhatsApp-related areas. It helps prevent regressions where users might not get clear feedback while attachments are being uploaded.
Original PR description
\* = knowledge, test_mail_enterprise, test_spreadsheet_edition, website_helpdesk_knowledge, whatsapp Enterprise counter-part. https://runbot.odoo.com/odoo/error/230901 https://github.com/odoo/odoo/pull/223367
A scheduled billing process could stop too early when the first batch included subscriptions that were not ready to invoice, potentially delaying invoices for other eligible subscriptions. This fix applies the batch limit after checking which subscriptions can actually be invoiced, helping ensure renewal invoices are generated on time.
Original PR description
Change was introduced here https://github.com/odoo/enterprise/pull/82340 that caused the cron trigger to not be activated if any of the 31 in the batch of subscriptions found was not to invoice. This is problematic because there could be other subscriptions that meet the domain requirements and the to invoice requirements that are not being seen because the limit is on the search before we check invoiceability. Added a limit to _get_subscriptions_to_invoice instead of on the search in order to take into account both filters for next cron triggers. opw-4850884
Fixes product searches by Kenya KRA item code so users no longer hit errors or blank results when using the product search filter. This helps Kenyan companies find products more reliably in sales workflows.
Original PR description
This commit odoo/enterprise@c17ebfc7cdf2b218945280e6e3bd09f2b9ee8adc added a [searchview](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu/views/product_views.xml#L74-L84) for `l10n_ke_item_code` but it never worked. as `l10n_ke_item_code` in `product.template` is non-stored field, we generally get error in console about it. fast forward to newer version e.g. saas-18.3, searching on non-stored fields raises traceback on frontend. Step to reproduce: - install L10N_ke and sale_management - switch to kenya company - go to product in sales app - type something in search bar and select 'kra item code' from autocomplete Observation: - nothing happens on frontend - on backend we receive a error `ERROR odoo.osv.expression: Non-stored field product.template.l10n_ke_item_code cannot be searched.` Fix: - we introduce a search method for l10n_ke_item_code field opw-4985176 Forward-Port-Of: odoo/enterprise#91526
Odoo Studio now handles cases where a button points to a deleted server action without crashing. This keeps users able to reopen and edit forms in Studio even after the related action has been removed.
Original PR description
The error is triggered when a user configures a button to execute a serveraction, deletes the associated server action, and then attempts to edit the button. This causes a failure at the line `self.env.ref(str_action)` due to the missing external ID. **Steps to reproduce:** * Install `crm` and `web_studio` * crm > Form View> Studio > `Add a button`> Run a server Action > Enrich * Settings > Technical > Actions > Server Actions > `Enrich` > Delete it * crm > Form View > Studio `ValueError: External ID not found in the system: crm_iap_enrich.action_enrich_mail` **Solution:** * Return `False` when the referenced server action cannot be found or has been removed. **Sentry-6608495874**
Fixes an issue where running a WhatsApp marketing automation test more than once could cause an error and stop the test. The automation now handles each tracking record separately, improving reliability for users validating WhatsApp campaigns.
Original PR description
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration *…
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration * Marketing Automation > New > Start From Scratch > Add a new activity * Select Activity Type as Whatsapp Message and a Whatsapp Template * Launch a Test > Pick a contact > Launch > Run (Do this step twice) **Error:** `ValueError: Expected singleton: marketing.trace(6, 4, 3, 2, 1)` **Cause:** This error occurs because the variable `trace` contains multiple records, but the `process_event` method is being called on the entire recordset. Since `process_event` uses `self.ensure_one()`, it expects exactly one record, and therefore raises an error at [1] when multiple records are passed. **Solution:** * Handle trace records one by one using a loop. [1]: https://github.com/odoo/enterprise/blob/624b18bdb5dff0df4756c4e1d37a696631e57a05/marketing_automation_whatsapp/models/marketing_trace.py#L20 **Sentry-6772553612**
The Point of Sale system now checks connected device status less frequently, moving from every 5 seconds to every 60 seconds. This reduces unnecessary background work and can help stores with large product databases avoid slowdowns during PoS use.
Original PR description
We currently check the status of the connected devices every 5s. This is used in only a short selection of the devices and the delay is unnecessarily short. For databases with a lot of products this can unnecesarily slow down their PoS This PR increases the loop until 60s opw-5006302
This fix prevents financial report spreadsheet exports from failing when an account code looks like an extremely large number, such as "1E1000". Users can now export Trial Balance and related accounting reports reliably even when account identifiers contain these values.
Original PR description
_set_xlsx_cell_sizes tries to convert each cell into a float if it's possible. If the cell contains "inf", "1e1000" (or any value such that float(value) = float("inf")), then there is an OverflowError which is not catch by the try/except.
To reproduce, set an account code as "1E1000", make this account appearing in the trial balance (by creating a move) and export it as XLSX.
opw-4981385Non-recurring products sold through upsell orders are now included in the Sales Analysis Report. This gives teams a more complete view of delivered quantities and revenue, improving sales reporting accuracy.
Original PR description
Problem: The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate…
Problem:
The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate reporting.
Purpose:
To ensure that non-recurring products added through upsell Sales Orders are correctly included in the Sales Analysis Report (report_all_channels_sales_action). This fix updates the report's domain filter to include upsell orders when the product is not recurring, resolving the issue of missing sales data for such products.
Steps to reproduce the bug:
1. Create a Sales Order (SO):
Add two products to the order:
- One recurring product (e.g., a subscription-based product with a recurring billing policy).
- One non-recurring (standard) product.
2. Confirm the SO
3. Generate an Invoice for the confirmed SO.
4. Validate the Invoice and deliver the non-recurring product (process the delivery order fully).
5. Create an Upsell Sales Order:
- From the original SO, create a new upsell SO.
- Add the same non-recurring product again.
6. Navigate to the Non-Recurring Product Page:
- Open the Product form for the non-recurring item.
- Click on the "Sold" smart button (shows delivered/sold quantities in the past 365 days).
- This opens the Sales Analysis Report (report_all_channels_sales_action) filtered by this product.
Issue:
The upsell Sales Order is not included in the Sales Analysis Report for the non-recurring product. As a result, the delivered quantity or revenue from upsell SOs is missing from the report for non-recurring products.
opw-4940977This update fixes how the Indian GST reports determine the month and year for a return period. It helps ensure GST reporting periods are computed consistently, reducing the risk of incorrect report timing or filing data.
Original PR description
Backport of commit: https://github.com/odoo/enterprise/commit/eda621c07393ad8e897503c852a9b00480affc52 Forward-Port-Of: odoo/enterprise#92499
Opening the Journal Audit report no longer fails if the related Journal Report has had all of its lines removed. The system now safely stops processing when there are no lines, preventing an error and improving reliability for accounting users.
Original PR description
Currently, error occurs when user try to open Journal Audit with no lines. Steps to replicate: - Install `accountant`. - Navigate to `Accountant > Configuration > Accounting reports`, search for `Journal Report` and open it. - Under the Lines tab, delete all the records and save. - Open the `Journal Audit` report, and the error will appear. Error: `IndexError: list index out of range` Cause: - An error occurred because the user deleted all the lines from the report, and the code tried to access the first element [1] of those lines (`lines[0]`) which caused the error. Solution: - Added a check if lines are present, if not then returned from the function. [1]: https://github.com/odoo/enterprise/blob/5670a73ef63d313f6c3df2b1ceeec7f7d6cd6a1b/account_reports/models/account_journal_report.py#L167 sentry-6795898305
Documentation and clarification updates
The Adhoc corporate contributor license agreement record was updated to add new members. This keeps Odoo's contribution permissions and legal records current, with no impact on product functionality.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr