Daily updates from Odoo
Navigate
Branch
Friday, August 29, 2025
73 changes
44 changes
New functionality added to Odoo
A new VAT Books report is now available for Spanish accounting, helping businesses review and export VAT-related records more easily. The Spain reporting menu also now includes direct access to VAT Books and Libro Diario, with an added XLSX export option for the journal audit.
Original PR description
In this PR: - Added 'VAT Books' report. - Added 'Libro Diario XLSX' button in Journal Audit view (XLSX export). - Introduced a dedicated submenu for Spain with: - 'Vat Books' report - 'Libro Diario' linking to the Journal Audit. task-4831718
Enhancements to existing features
This update adds automated checks across barcode lookup features to confirm product data is fetched and applied correctly. It helps reduce the risk of issues when creating products through point of sale, inventory barcode scanning, and website flows.
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 Forward-Port-Of: odoo/enterprise#93175 Forward-Port-Of: odoo/enterprise#69120
Projects created from templates can now automatically plan task dates based on the timing used in the original template. This helps teams start new projects with realistic schedules while still allowing the system to adjust dates to avoid conflicts.
Original PR description
This PR allows planning dates when a project is created from a template. The dates of the created tasks are calculated based on the dates of the task in the template project. Tasks will be scheduled based on the elapsed time between the start of the project and the start of the task in the template. Tasks are scheduled using the smart scheduling algorithm, so the time ranges might not be exact to avoid conflicts, etc. If the template doesn't have planned dates, tasks will be simply scheduled from the start of the created project (or today) using the smart scheduling. Task-4700745
This update makes account return and audit screens clearer and more reliable for users. It fixes navigation and display issues, adds better completion notifications, uses more appropriate dates during setup, and helps prevent duplicate return creation.
VoIP call status messages are now more consistent between call records and the softphone history. This makes it easier for users to understand call outcomes across the VoIP interface without seeing mismatched wording.
Original PR description
Aim of this commit is to harmonize call status messages in voip.call and softphone history. Task-4915054
Warehouse operations can now place packages inside other packages, such as boxes on a pallet, and move the whole package structure together. This improves handling of common logistics workflows and keeps a clearer history of what was moved, even if package organization changes later.
Original PR description
Before this change, it wasn't possible to handle multiple levels of packages within Odoo. One simple example of this is having a few boxes put on top of a pallet, which is a *very* common occurence…
Before this change, it wasn't possible to handle multiple levels of packages within Odoo. One simple example of this is having a few boxes put on top of a pallet, which is a *very* common occurence in stock. Changes summary: - Packages inside other packages - Rework of the put in pack, can display a widget if enabled in Operation Type - You can move a package containing other packages, this will move all of them - The handling of a package is *always* done on the move lines directly - Packages now holds several more information regarding their current reservation - A new `stock.package.history` record is added to keep track of what was moved in previous transfers, as package hierarchy may be different between the past and now In other commits: - Rename `stock.quant.package` to `stock.package`, as they're not really related to `stock.quant`. - Remove `stock.package_level`, as we now handle everything on the package / move lines. See odoo/odoo#203987 See odoo/upgrade#7576 Task-4314600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now download TDS and TCS tax reports directly as Excel files instead of manually selecting export fields. The file includes the relevant return-filing information and is grouped by section to make review and filing easier.
Original PR description
Receives many feedback from the users that they currently exports report by manually selecting fields to file TDS & TCS return. The problem is many users are unaware of how to export it with existing fields. With this commit, users can now directly download the Excel file from the TDS/TCS Tax report, which includes all the relevant fields needed for filing TDS/TCS returns. Additionally, the XLSX file is grouped by section to make it easier to read. task-4945885 COM PR: https://github.com/odoo/odoo/pull/220707
VoIP call transcription now handles failed uploads more reliably, so users see the correct status instead of calls getting stuck as pending. Calls can also show a short transcript summary and clearer status banner, with demo examples and broader tests added to improve confidence.
Original PR description
Following up on the quick merge of the voip transcription aa5983efc390dc16cff3ee99a55a8878d6e06939 We are improving its state by modifying: **Controller**: doesn't raise errors anymore, returns http…
Following up on the quick merge of the voip transcription aa5983efc390dc16cff3ee99a55a8878d6e06939 We are improving its state by modifying: **Controller**: doesn't raise errors anymore, returns http err codes, keeping transcription_status persist errors (ref.1) **Tests**: added backend controller tests and cron tests covering happy paths and edge cases. (ref.2) **Summary**: added one_liner_summary filed on the voip call, which is generated after successful transcription; (if it fails we still have transcription) **Banner**: Previously we informed user about the transcription_status with a selection field in a view. Now it is replaced by a status banner at the top of the form view **Demo**: added some demo calls to showcase calls in all transcription_status. (ref.3) (ref.1) Without it: when we have an error in the request to transcribe it will rollback the transaction. Example: Controller is asked to transcribe, it can't because the file is too big, so it sets transcription_status=too_big_to_process **and raises**. This revers the transaction resulting in transcription_status set to pending. BAD (ref.2) To avoid gymnastic of creating second cursor for the sake of testing cron try to commit, we restrict committing so it doesn't happen in the test_mode. Subsystem testing covers those <img width="1139" height="408" alt="image" src="https://github.com/user-attachments/assets/90736892-58ce-4a15-b28d-bb8bf4369888" />
Payroll salary rules are now treated as updateable configuration, making it easier to keep standard payroll logic aligned during upgrades. Businesses that need custom payroll behavior should create or duplicate their own rules so those customizations remain protected during migrations.
Original PR description
Purpose ======= Rules that are supposed to be customized and kept over migrations should be created by hand, or duplicated from existing structures.
Employee records now show the official contract type separately from the payroll salary structure category. This helps HR teams keep legally or officially named contracts visible while still seeing the payroll classification needed for compensation processing.
Original PR description
This change ensures that official contract names remain visible while clearly distinguishing them from the salary structure category. task-5013761
Employee work schedule handling has been simplified by removing start and end date limits from resource attendance records. This reduces configuration complexity and supports cleaner payroll and scheduling processes, including Belgian payroll version handling.
Original PR description
Removed date_from and date_to fields for simplification Task: 4929940
Subscription products now prioritize the currently payable price in the cart, aligning their presentation with rental items. The order summary also shows the subscription period correctly, reducing confusion during checkout.
Original PR description
At the moment the subscription is displaying the price period under the price, which is not consistent with what we do for rental items. The emphasis should be on the current paid price not the subscription period. Additionnaly fixes the subscription period in the order summary. task-4512956
This update improves how decimal numbers are displayed and handled by ensuring float fields can keep a minimum number of digits. It helps maintain consistent precision in accounting, payroll, delivery, point of sale, quality, and electronic invoicing workflows, reducing formatting inconsistencies across documents and integrations.
Original PR description
task-4895014
Partner ledger and related customer follow-up reports now include reconciliation date information, giving finance teams clearer context on payments and outstanding balances. This helps users review customer accounts more accurately and align follow-up actions with the latest reconciliation status.
If website generation fails, the error is now sent back to the website support service. This makes it easier for support teams to see what went wrong and resolve issues faster.
Original PR description
When an error occurs during generation, send the error back through report_ko to be able to see the logs on the WSS. Forward-Port-Of: odoo/enterprise#93176
The partner ledger now supports an additional closing date filter, making it easier to view open items up to a specific date. This helps finance teams produce more precise partner balance and reconciliation reports.
The payroll setup screen for salary rule parameters has been simplified by removing less-used fields from the main form and placing the description where users see it sooner. This makes payroll configuration easier to read and navigate for HR teams.
Original PR description
-Removed value and valid since from form view -Move the description field below the code. -Remove description tab. task-5043887
Payroll configurations for Jordan and Saudi Arabia now include the missing account mappings for salary rules. This helps ensure payroll entries are posted to the correct accounting accounts, reducing manual corrections and improving reporting accuracy.
Original PR description
xx: jo, sa In this commit we add the maping for all the salary rules accounts Taks: 4882398
Spreadsheet list headers are now kept consistent across user languages, so pivots based on lists continue to work when a spreadsheet is opened by colleagues using a different language. Several spreadsheet dashboard files were also reformatted to make future updates cleaner without changing their business content.
Internal VoIP calls made using extension numbers are now matched to the corresponding Odoo user. This helps employees recognize who is calling instead of seeing only an extension number.
Original PR description
**Purpose:** Improve the user experience by identifying internal calls made using extension numbers (voip usernames) by displaying the corresponding user's name. **Specification:** Enhance the get_contact_info method in the voip.call model to resolve internal extensions by matching the call's phone_number with the voip_username field on res.users. **Task**-4997542
Resolved issues and error corrections
Fixed an issue where starting two IoT WebRTC connections almost at the same time could cause the connection to fail. The update prevents duplicate connection attempts while one is already opening and adds test coverage to reduce the risk of this happening again.
Original PR description
If two calls are made to open a WebRTC connection within a short space of time, they will both try to open a new connection causing a failure. This commit fixes the issue by checking to see if a connection is currently opening before continuing. It also adds a unit test for this scenario.
UK tax report submissions to HMRC now include the correct obligation ID. This prevents submissions from failing or being sent with missing reference information, improving reliability for UK tax filing workflows.
Original PR description
Issue: Prior to this commit, when sending a tax report to HMRC, the obligation ID was undefined Fix: sending the appropriate obligation ID opw-4965620 Forward-Port-Of: odoo/enterprise#91735
The Spanish SME balance sheet now avoids counting certain current financial investment accounts twice. This ensures reported investment amounts match the underlying accounting entries, improving confidence in financial statements.
Original PR description
**Issue**: * Amounts were exactly doubled in 'Current financial investments' (line 12500) in the Spanish Balance Sheet - SMEs report as account codes 551 and 5525 were incorrectly included in…
**Issue**: * Amounts were exactly doubled in 'Current financial investments' (line 12500) in the Spanish Balance Sheet - SMEs report as account codes 551 and 5525 were incorrectly included in balance_pymes_line_12500_sub_balances formula **Root Cause**: * Account codes 551 and 5525 were included in BOTH: 1. Line 12500 sub_balances (unfiltered account_codes expression) 2. Line 12500 sub_debits (domain expression with sum_if_pos filter) * This double-counting within the same line caused financial investment amounts to appear twice in the balance sheet **How to Reproduce**: 1. Create Spanish company with 'es_pymes' chart of accounts 2. Post journal entries to accounts 551 or 5525 (current financial investments) 3. Generate 'Balance Sheet - SMEs (ES)' report 4. Observe amounts in line 'V. Current financial investments' are exactly doubled compared to account balances 5. Click on the doubled amount - shows underlying transactions sum to half the amount **Fix**: * Removed account codes 551 and 5525 from balance_pymes_line_12500_sub_balances * These accounts are properly handled by the sub_debits expression * Each account is now counted only once within the line opw-4983300 Forward-Port-Of: odoo/enterprise#93052
Quality checks on manufacturing orders can now proceed without users first entering the producing quantity. This removes an obsolete validation that is no longer needed because invalid manufacturing quality point setups are already prevented elsewhere.
Original PR description
This commit reverts the change from: [PR](https://github.com/odoo/enterprise/commit/51a9b38), which had introduced a `UserError` that occurs when creating a quality point with operation type `Manufacturing` having control per `quantity`. Revert is done since this [PR](https://github.com/odoo/enterprise/pull/67780) now prevents creating quality points with operation type `Manufacturing + control per quantity`, which makes the original bugfix PR unnecessary and has become dead code. After this commit, quality checks on manufacturing orders no longer require setting the producing quantity first. Task ID: [4915067](https://www.odoo.com/odoo/project/966/tasks/4915067)
Spreadsheet list headers are now stored consistently so pivots keep working when users open the same spreadsheet in different languages. This prevents dashboards and custom spreadsheets from breaking for multilingual teams and also standardizes dashboard file formatting for easier maintenance.
Spreadsheet list headers now stay consistent regardless of each user's language settings. This prevents pivots and dashboards based on list columns from breaking when opened by colleagues using a different language.
Original PR description
Current issue: Alice's language is in English and Bob is in French. Alice inserts a list in a spreadsheet, and create a pivot with the dataset being the list. Alice chooses the pivot dimensions based…
Current issue: Alice's language is in English and Bob is in French. Alice inserts a list in a spreadsheet, and create a pivot with the dataset being the list. Alice chooses the pivot dimensions based on the columns headers, which are the translated(!) field display names. Now Bob opens the spreadsheet. => the pivot doesn't work because the dimension are specified using the field names in English, but they cannot be found because they are in French in the spreadsheet. The issue is that `ODOO.LIST.HEADER` returns the translated field string. One solution would be drop `ODOO.LIST.HEADER` completely and just hard-code the string values when the list is inserted. But users use it to add fields after, and then auto-fill it. Also, being easily able to know which cells are list headers is helpful to display "widget" like the sorting widget (task 4543812) Other thing to consider: currently, when users are creating their own spreadsheet/dashboard, there's a mix of languages: what they manually type in cells, in their language (untranslated obviously) and the result of ODOO.LIST.HEADER, which is translated. Task: 4805206
Point of Sale badge printing now loads the needed badge format information again. This restores badge printer functionality for event check-ins and reduces manual work for staff using PoS at events.
Original PR description
Due to an oversight in odoo/enterprise#83021, printing badges using the badge printer from POS was not working. This commit fixes the issue by restoring the `badge_format` field to the list of fields loaded in the POS. Forward-Port-Of: odoo/enterprise#93365
GSTR document summaries now ignore invoices that no longer have a valid sequence number. This prevents report generation errors and ensures only properly numbered invoices are included.
Original PR description
_* = l10n_in_reports_gstr_document_summary Issue: - The GSTR document summary included all invoices that were posted or cancelled with posted_before = True. - If a user manually cleared the invoice sequence (set it to null), such invoices were still picked up. - This caused errors during summary generation since those invoices no longer had valid sequence numbers. Fix: - Adjusted the document summary logic to only include invoices with a valid sequence number. - Ensures that entries without a sequence are ignored, even if they were once posted. Impact: - Prevents errors when generating GSTR document summaries. - Guarantees that only valid, numbered invoices are included in reports. opw-5005048 Forward-Port-Of: odoo/enterprise#93039
This fixes an issue in Barcode receipts where removing scanned serial-number lines could remove the wrong item. Users can now decrement and re-enter serial numbers without false duplicate warnings, reducing receiving errors for tracked products.
Original PR description
Steps to reproduce: - Install Purchase, Stock and Barcode apps - Create a product tracked by serial number - Create a PO of this product and confirm it (demand 3) - Open Barcode application for the PO's receipt - Start entering serial numbers for the 3 products - For each line, use the decrement button and remove all 3 lines - Make sure the last removed line is not the first scanned serial - Re-enter the serial number of the last removed line Issue: The parent line of the 3 sublines has the lot_name fixed on the first scanned serial_number. So when decrementing the last_line, it will always use the virtual_id of the first serial_number scanned, leading to decrementing the wrong serial number. It starts showing that the next scanned number is already used, because it wasn't properly removed in the first place. opw-4646765 Forward-Port-Of: odoo/enterprise#89987 Forward-Port-Of: odoo/enterprise#88130
Portal users receiving published planning shift emails are now sent to the correct planning page instead of the portal dashboard. This helps external or limited-access users view their schedules directly from email without confusion or extra navigation.
Original PR description
### Steps to reproduce: - Install Planning app - Create a portal user and an employee for this user - Create a shift for this user and Publish it - Go to the email that has been sent and click on…
### Steps to reproduce: - Install Planning app - Create a portal user and an employee for this user - Create a shift for this user and Publish it - Go to the email that has been sent and click on View Your planning - Notice you are redirected to the portal dashboard home ### Cause: Since this commit diff we removed the check if the user is having planning group https://github.com/odoo-dev/enterprise/commit/72afe1e14703f0a3eafd0cfaec10c67462db73ce#diff-293bc9f44292d19793981abbafbe2a55642d170bda5e3bf17d7654f7bffcbedaL62-L64 When getting the planning url that will be share in the email we don't check if the user is portal or not so we set the url with /odoo path and if a portal user is accessing a /odoo path it will redirect him to /my https://github.com/odoo/odoo/blob/1acf4b2ce2bdad27e7d32d1227698968148a5935/addons/portal/controllers/web.py#L25-L26 ### Fix: We check if the user is portal we set the url with /planning path which will redirect the portal user to the correct planning view opw-5045746 Forward-Port-Of: odoo/enterprise#93359 Forward-Port-Of: odoo/enterprise#93333
Recurring subscription orders with timesheet-based services are no longer incorrectly treated as free when work has already been delivered. This ensures invoices are generated for delivered service work even when the original order quantity or recurring amount is zero, helping prevent missed revenue.
Original PR description
### Steps to reproduce: - Install Helpdesk, Sale Subscription apps - Create a service recurring product and set its invoicing policy as 'Based on Timesheets' - Create a SO with the created product…
### Steps to reproduce: - Install Helpdesk, Sale Subscription apps - Create a service recurring product and set its invoicing policy as 'Based on Timesheets' - Create a SO with the created product and set the qty to 0 - Create a Helpdesk ticket and link it to the SO - Record some timesheets in this SO - Run the cron for generating recurring invoices - Notice no invoice will be created for the SO and it will be considered as free renewal ### Cause: When trying to create a recurring invoice we check if the invoice that will get generated is free by checking the MRR and the total amount of the SO and if one of them are 0 we will flag this invoice as free so we won't generate it ### Fix: We check if the order lines to be invoiced is invoiced based on delivery and they have delivered quantity already and if so we create the invoice even if the MRR and the total amount is equal 0 opw-4990478 Forward-Port-Of: odoo/enterprise#93245 Forward-Port-Of: odoo/enterprise#93115
Managers can now access VoIP call records for employees across their full reporting line, not just direct reports. This fixes incomplete visibility for teams with multiple management levels and helps managers review relevant call activity more reliably.
Original PR description
This commit fixes the record rules that specifies the users that can read phone calls made through VoIP. Currently, managers can only access call records of their direct subordinates. They should have access also to calls made by employees that are managed by their direct subordinates. This commit fixes that. Task-5033984
The fix ensures that signing request email buttons direct recipients to the website of the company that sent the request, rather than defaulting to another company’s website. This reduces confusion for signers and helps avoid business or legal issues caused by documents appearing under the wrong company.
Original PR description
According to a ticket, when you have 2 companies and send a sign request from the second one, the button in the email received from the signer redirects to the website of the first company. This may cause confusion and may have legal implications. This PR aims to fix the problem by correctly targeting the right website. Task & ticket: 4976533
Fixed an issue where previewing a sales order could fail after switching from a subscription quotation template to a regular one. The preview now only shows subscription-specific information when the order is actually a subscription, preventing an error and keeping the sales workflow uninterrupted.
Original PR description
Steps to reproduce: 1. Go to Sales > Configuration > Settings. 2. Set Subscription Template as default Quotation Template e.g.(Yearly Cleaning) 3. Create a new Sales Order 4. Switch the quotation…
Steps to reproduce: 1. Go to Sales > Configuration > Settings. 2. Set Subscription Template as default Quotation Template e.g.(Yearly Cleaning) 3. Create a new Sales Order 4. Switch the quotation template from a Subscription one to a non-subscription template e.g.(Office Furnitures) 5. Click Preview on the Sales Order. Issue: A traceback is raised: `TypeError: unsupported operand type(s) for +: 'datetime.date' and 'bool'` Cause: In the portal template, the following expression is evaluated without checking if value is falsy or empty: https://github.com/odoo/enterprise/blob/36f419e4604a2adc946f3a6828e69fba7584d2df/sale_subscription/views/sale_subscription_portal_templates.xml#L66 The portal template contained expressions referencing subscription-specific fields (like plan_id.billing_period) without checking whether the sales order was actually a subscription. When the quotation template is non-subscription, these fields may be False, leading to the error. Solution: Guard all subscription-related blocks with condition: `<t t-if="sale_order.is_subscription">` opw-4980869 Forward-Port-Of: odoo/enterprise#92845
Fixed an issue where the Timesheet Leaderboard could crash when the current employee was not shown because their billing rate was very low. Users can now open the widget reliably, even when their own record is filtered out of the billing rate view.
Original PR description
**Issue:** A traceback occurs when clicking the Timesheet Leaderboard widget. **Cause:** The template `timesheet_leaderboard_dialog.xml` assumes that `state.current_employee` is always defined. However, when the current user's employee has a billing rate ≤ 0.5%, they are filtered out from the leaderboard. As a result, `setCurrentEmployeeIndexFromLeaderboard` returns `undefined`, causing the widget to crash. https://github.com/odoo/enterprise/blob/70ed91ba1ebb94cb1919df49a4d95fad26935d03/sale_timesheet_enterprise/static/src/services/timesheet_leaderboard_service.js#L18-L31 **Steps to reproduce:** 1. Set up a company with 4+ employees having billing targets. 2. Ensure the current user's employee has a billing rate ≤ 0.5% (e.g., 0.3 hours logged / 100 hours target). 3. Switch the leaderboard to "Billing Rate" mode. 4. Click the Timesheet Leaderboard widget. opw-4875410 Forward-Port-Of: odoo/enterprise#93339
This fix prevents duplicate records from being created when the stock fleet module is upgraded. It helps keep upgrades reliable and avoids unnecessary duplicate interface entries for inventory delivery operations.
Original PR description
Commit a7f2a2cf9c96 changed the window action to take a specific view xmlid by creating a new `view_ids` entry. As the action is `noupdate=0`, upgrading the module will try to create a new record with the same name. This commit adds the `noupdate` tag around those record to avoid creating new view at update. runbot-230819 Forward-Port-Of: odoo/enterprise#92611
Customers who reorder past sales orders will no longer have appointment-related calendar events added back into their cart. This prevents confusing cart contents and avoids inconsistent behavior when previous appointment orders are reordered.
Original PR description
Steps to reproduce: - Create an appointment that generates a sale order on confirmation. - Confirm the order. - Navigate to `/my/orders` and attempt to reorder the sale order. - Calendar events are added to the cart. Issue: - Calendar events shouldn't be added to the cart - Reordering such lines can lead to inconsistent behavior. Root Cause: - The base `_is_reorder_allowed()` method does not filter out sale order lines that originate from appointments. Solution: - Override `_is_reorder_allowed()` in the `website_sale_appointment` modules. - Filter out lines with `calendar_event_id` set. See also: https://github.com/odoo/odoo/pull/198070 https://github.com/odoo/upgrade/pull/7633 affected version-master task-4472286
The work entry split action in the Gantt view now opens a confirmation form instead of trying to split immediately. This helps HR users review the split details first and prevents incorrect or failed split actions.
Original PR description
This commit fixes how the split button behaves in the Gantt view of the work entry. Instead of calling the ORM function upon clicking the split button, the split button now opens a `FormViewDialog`. The save button in the dialog is modified so that, instead of saving the record data, it calls the `action_split` function that handles the splitting logic. The context is used to open the dialog with a custom form view that has read-only fields, and the form is populated with the existing work entry data, except for the duration, which is set as half of the existing work entry duration. task-5043857
A redundant internal marker was removed from the payroll payslip run screen definition. This does not change how the feature works, but makes the code clearer and easier to maintain.
Original PR description
This directive allows to declare a template, so using it inside a template is useless. It doesn't cause any issue, it simply has no effect. This commit removes it for the sake of clarity.
This fixes how Swiss payroll accounting handles negative payslip lines by reversing the accounts when needed. It helps ensure payroll entries are posted to the correct accounts, reducing accounting corrections and improving reliability for Swiss payroll processing.
Original PR description
…r 2050 Invert accounts for negative payslip line Forward-Port-Of: odoo/enterprise#93142 Forward-Port-Of: odoo/enterprise#93074
GSTR2B reconciliation now skips vendor bills that do not include any taxes. This prevents bills that vendors likely did not file from appearing in the reconciliation process, making Indian GST reporting more accurate.
Original PR description
Before this commit- We included the Vendor bills without taxes for GSTR2B reconciliation After this commit- We exclude the Vendor bills without taxes for GSTR2B Because if no tax is there on the bill it means wasn't filed by the Vendor as well task-5023013 Forward-Port-Of: odoo/enterprise#93373 Forward-Port-Of: odoo/enterprise#92866
The subscription invoicing process now skips subscriptions linked to archived companies. This prevents hidden or inactive company records from continuing to generate recurring invoices unexpectedly.
Original PR description
Currently, when a company which has recurring orders (subscriptions) active is archived, the cron still periodically invoices them as usual but the user is not able to see it because they don't show up in the views. To avoid having to unarchive the comany and check every subscription one by one, this PR aims at making the cron ignore any subscription tied to an archived company, as intended. The only modified cron is the one that creates invoices since the other one of interest (the one that sends reminders) operates only on invoiced orders, which we avoid having with this change. Also added a test to ensure that if the company related to a subscription sale order is archived, the cron won't invoice it. Task: 4947107
The VoIP CRM integration now includes needed user permission details when the web session starts. This avoids extra background calls during startup, helping the interface load more efficiently without changing user-facing features.
Original PR description
Since the VoIP app use some groups at startup[1], it's made sense to adds it inside the session_info bundle to avoid RPCs at webclient startup. [1]: https://github.com/odoo/enterprise/commit/9d3a13e9adae3a6b1c44b70a52b2fd74ef9dcc1a#diff-e8144e1aa7d3b4933985de5693d78e8c392bce8f7150ad186a04b8c87c7cd32aR14-R16 Forward-Port-Of: odoo/enterprise#93419
Code cleanup and technical improvements
The spreadsheet filter editor side panel now uses a shared footer area for save, delete, and cancel actions. This streamlines the interface implementation and should make future updates to these controls more consistent across filter types.
Original PR description
This commit adds a new component called GlobalFilterFooter, which is used to render the footer of the global filter editor side panel. The footer includes buttons for saving, deleting, and canceling changes to the filter. Task: 5042717
29 changes
New functionality added to Odoo
A new Indian localization module adds support for managing port codes used when e-Way Bills involve air or sea transport. This helps businesses create compliant e-Way Bill data for shipments that pass through Indian ports.
Original PR description
Introduced a new module to manage Indian port codes, specifically for transport modes classified as Air or Sea in the e-Way Bill system. see - https://github.com/odoo/upgrade/pull/8170 Task-3638761 Forward-Port-Of: odoo/odoo#221503
Adds a new Poland localization feature to record and display the taxable supply date on invoices. This helps Polish businesses meet local tax reporting requirements more accurately when invoice date and supply date differ.
Original PR description
This new module aims at adding support for taxable supply date in Poland. task-4829233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update adds shared automated checks for point-of-sale localization modules across multiple countries. It helps reduce the risk of country-specific compliance or checkout issues by making these localized POS flows easier to test consistently.
Original PR description
Thi commit add a generic tour that can be run in all pos l10n_modules. In some cases it requires some extra steps, this can be done with hooks. The hooks will execute different steps depending on the country the tour is run in. opw-4606788
The Turkish Nilvera integration now syncs more invoice types, including E-Archive documents and invoices created directly in Nilvera. Users can retrieve statuses and PDFs from one renamed "Sync with Nilvera" action, with documents shown in previews and attached to the invoice chatter.
Original PR description
[IMP] l10n_tr_nilvera_einvoice: refactor API to include E-Invoices & E-Archive Fixed bugs in API calls triggered during fetch requests and added support for fetching the status of E-Archive files. Updated the action button label to "Sync with Nilvera", which now fetches invoice statuses, retrieves PDFs for both E-Archive and E-Invoices, and includes invoices generated directly in Nilvera, enabling support for additional invoice types currently not supported in Odoo. Invoices/Bills are marked as "Successful" once retrieved. Retrieved PDFs are displayed in the preview and automatically attached to the chatter. The original limit of fetching a maximum of 30 records (status and PDFs) is maintained. task-4714467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds shared automated checks for point of sale localization modules across several countries. It helps ensure local fiscal and reporting requirements keep working consistently when point of sale features change.
Original PR description
Thi commit add a generic tour that can be run in all pos l10n_modules. In some cases it requires some extra steps, this can be done with hooks. The hooks will execute different steps depending on the country the tour is run in. opw-4606788
Resolved issues and error corrections
This fix ensures mail records that are already marked for deletion are no longer treated as active records by internal business logic. This reduces the risk of crashes and incorrect data handling during record deletion and recomputation.
Original PR description
Before this commit, business code could leak records that are soft deleted, i.e. the representation of the record is still in the store but conceptually this record is deleted. These soft-deleted…
Before this commit, business code could leak records that are soft deleted, i.e. the representation of the record is still in the store but conceptually this record is deleted. These soft-deleted records are present in the code for a very short time, just enough time to warn business code in the onDelete() hooks. The problem for Model.records and Model.get() to return these records, is that the business code thinks these records are not deleted, which can lead to misuses and crashes. For example: if a computed field returns this soft-deleted record, then the field value has this soft-deleted record. When the record is hard-deleted, this field will be recomputed, but when diffing with its old this will crash because it will still have a trace of the record in the internal code. This commit fixes the issue by removing the record from Model.records when soft-deleted, so that Model.records and Model.get() doesn't return this record. The onDelete() hooks will returned the soft-deleted like before because the deleted records are stored in the data queue of the hooks. This solution also solves another problem: if a record is deleted and there's an immediate side-effect computed field to insert this record, the previous implementation would hard-delete the record at the end which is wrong: the record should be deleted but the insert part should apply, thus the resulting record is a fresh one with same identity but only partial data from the insert. All other field values must be lost from the deletion. The changes in this commit also fixes this issue. Commit also fixes issue for `.exists()` that should be `false` for soft-deleted records. Task-4860196
Opening a Discuss channel now correctly clears its unread status even if that browser missed an earlier notification. This keeps unread indicators consistent across multiple browser sessions and reduces confusion for users managing conversations.
Original PR description
Before this commit, if you opened an unread channel that the server already considered “read,” the channel would remain marked as unread in your browser. This typically happens when one browser instance misses the bus notification that cleared the unread status. Steps to reproduce: 1. Open Discuss as the same user on two browsers (A and B) 2. Send a message to said user 3. Stop bus notifications on browser A 4. Read the message on browser B 5. Re-enable bus notification on browser A 6. Open the channel on browser A -> not being marked as read This happens because the method `_set_last_seen_message` skips sending the notification when the message seen is older than the current `seen_message_id` (previously set by the other browser). This commit fixes the issue by setting the `allow_order` parameter in the rpc call. task-4863058 Forward-Port-Of: odoo/odoo#218623
The Point of Sale tax control button now appears only when relevant settings are enabled, including restaurant takeout or delivery scenarios. The tax selection popup also now uses a clear, accurate title, reducing cashier confusion during checkout.
Original PR description
Before this commit: =================== - When only point_of_sale is installed, the tax control button is visible only if `Flexible Tax` is enabled. But with pos_restaurant installed, the button is always visible, even if Flexible Tax is disabled. - Also, the tax selection dialog had an incorrect title: `Please register the voucher number`. After this commit: ================== - In point of sale, the tax control button will be visible if `Flexible Tax` is enabled, and in restaurant mode, the button will be visible if the `Flexible Tax` or `Takeout/Delivery` is enabled. - The tax selection dialog title has been updated to: `Choose the tax you want to apply`. Task: 4937977
The Saudi localization now shows the “THIS IS NOT A LEGAL DOCUMENT” warning only on customer invoices, credit notes, and debit notes when the required QR code is missing. Vendor bills, vendor adjustments, purchase receipts, and sales receipts no longer display this misleading warning, reducing confusion for accounting users.
Original PR description
Before this commit: - The message "THIS IS NOT A LEGAL DOCUMENT" was also displayed on Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. - The warning should only appear on Customer Invoices, Credit Notes, and Debit Notes when the QR code is missing After this commit: - The warning message is no longer displayed on all Vendor Debit Notes, Vendor Credit Notes, Purchase Receipt and Sales Receipt. Task-5044870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents required true/false values in Turkish Nilvera e-Dispatch documents from being translated. This helps ensure Nilvera receives the exact values it expects, reducing the risk of rejected or incorrect electronic dispatch submissions.
Original PR description
Before this commit, since we hardcoded the value, the value was present in the pot and po file. Except that nilvera want a precise value which is 'false' or 'true' and not something translated. task-5009049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222669
Fixed an issue where public holidays spanning multiple days could appear as only one blocked day in calendar views for employees or companies using flexible working schedules. This makes holiday calendars clearer and consistent with the existing time-off validation that already prevented requests across the full holiday period.
Original PR description
**Issue**: Multi-day public holidays only display as single days in calendar views when using flexible working schedules. A 3-day holiday appears as only 1 day blocked, though time-off requests are still correctly prevented for all 3 days. **Cause:** In `_get_unusual_days()`, the implementation for flexible schedules only captures the start date of each leave interval https://github.com/odoo/odoo/blob/132938929d46c8248a9e3a7e2972174ae38eacfa/addons/resource/models/resource_calendar.py#L683-L685 **Steps to reproduce:** 1. Configure a flexible working schedule for an employee or company 2. Go to Time Off > Public Holidays 3. Create a 3 day public holiday 4. Check Time Off calendar view Only 1 day appears blocked instead of all 3 days opw-4997757
When the same POS order is open on multiple devices, other devices now detect when it has already been finalized. This prevents staff from trying to edit a completed order and redirects them to the appropriate next screen or a new draft order.
Original PR description
Before this commit, if two devices were working on the same order and one of them finalized the order, the other device would not be aware of this change. This was leading to error, since a finalized order is not editable anymore. This commit adds a hook to track the finalized order on the product, payment and split bill screens. When the finalized order is detected, the user is redirected to another screen or a new draft order is created, depending on the screen. taskId: 4788430
This fixes an error that could occur when removing a bank account from a company contact. The change prevents empty duplicate-check results from being treated as real contacts, making contact bank account management more reliable.
Original PR description
To reproduce: ============= - go to the contact form of any company contact - add a new bank account "e.g. with account number 'DE'" (there should now only be one account) - save the contact form -…
To reproduce: ============= - go to the contact form of any company contact - add a new bank account "e.g. with account number 'DE'" (there should now only be one account) - save the contact form - remove the bank account via bin icon Problem: ========= ARRAY_AGG returns [NULL] when no duplicates found in query: https://github.com/odoo/odoo/blob/d7577430f229ed1770bbe2ccfa0d45eabbb394c7/addons/account/models/res_partner_bank.py#L73 This causes browse([None]) to create res_partner(None,) recordset: https://github.com/odoo/odoo/blob/d7577430f229ed1770bbe2ccfa0d45eabbb394c7/addons/account/models/res_partner_bank.py#L88 Which fails when accessing id_ field which will be None: https://github.com/odoo/odoo/blob/d7577430f229ed1770bbe2ccfa0d45eabbb394c7/addons/web/models/models.py#L1173 Solution: ========= Add FILTER clause to ARRAY_AGG to exclude NULL partner_id values, preventing creation of null records in duplicate_bank_partner_ids. opw-4988134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now requires an update path when users configure a server action to update a record. This prevents incomplete action setups that could otherwise lead to errors when the action runs.
Original PR description
[FIX] base: make update_path required for 'Update Record' server actions If a server action was previously created without an `update path`, the resulting error already fixes with this commit [1]. This commit ensures that the `update_path` field is marked as required when the action type is set to `Update Record`. [1]: https://github.com/odoo/odoo/pull/217723/commits/9d0144f97795d71474bf84bdfd7ed7025fd8a9a2
Users can now enter an ampersand character in filter or domain search values without triggering an error. This prevents crashes when applying custom filters and keeps search behavior consistent for everyday use.
Original PR description
Example of steps: - Open any domain selector with an archive checkbox (via custom filter for example) - Try to add char `&` in value input - focus out or try to apply the filter - Traceback ``` UncaughtPromiseError > OwlError Uncaught Promise > The following error occurred in onWillUpdateProps: "Cannot read properties of undefined (reading 'filter')" ``` The problem comes from the fact that we expect to have multiple nodes in our domain if we have an `&` as a value. However, there is a difference between using `&` in a text search for example (type `condition`), and using `&` as an AND between two nodes (type `connector`). The solution is to restrict the condition so that it not only checks that the value is equal to `&`, but also checks that the tree type is indeed a connector and not a condition. opw-5015281 Forward-Port-Of: odoo/odoo#224567
Installing the Manufacturing app on very large databases is now less likely to run out of memory or time out. The change improves how existing stock movement records are prepared during installation, reducing disruption for customers with high data volumes.
Original PR description
Description ----------- On large databases with millions of already existing `stock.move`, the post-install computation of compute stored fields can be time-consuming and memory intensive. This commit extends the pre_init_hook that was done in `mrp` to: - Speed up computation of `stock.move.is_done` - Implement SQL query to initialize `stock.move.manual_consumption`. Reference --------- opw-4980036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability to create and edit client-type menu actions in Studio without hitting a missing default view error. It removes obsolete special handling that conflicted with a broader default view generation fix, improving reliability for users configuring menus.
Original PR description
Steps to reproduce ================== - Install studio,contacts - Go to contacts - Open studio - Click on "Edit menu" - Click on the pencil next to a menu item - Set the action type to ir.actions.client - Type a random string next to it, for example "test123" - Click on "Create and Edit" => No default view could be found Cause of the issue ================== The following commit removes the binary fields from the default view as it caused a traceback https://github.com/odoo/odoo/commit/70d51d2103118287b1ebafdae396c7b86e6b9257 A more general fix has been made in https://github.com/odoo/odoo/commit/e1edcb06ef2619835d07717f00cbf6f04f026366 Since the binary fields are already removed in the super call, the override doesn't find them. Solution ======== There is no need for the override anymore opw-5023188 Forward-Port-Of: odoo/odoo#224634
This fixes a Point of Sale issue where applying a gift card could create an extra gift card line with a zero amount. Sales orders are now clearer for cashiers and customers, reducing confusion during checkout.
Original PR description
When selling some product and applying a giftcard, there could be 2 giftcard lines applied on the order one with a correct amount and the other one with 0 as amount. Steps to reproduce: ------------------- * Create a gift card with 50€ * Open PoS and add a Desk Pad and a Black Drawer > Observation: There are 2 giftcard lines applied on the order Why the fix: ------------ Sometimes the discountable amount could get weird values that are really close to 0 but that was not interpreted as False. To fix this we use `floatIsZero()` instead. Note: ---------- I will introduce a hoot test in 18.3 to cover this weird use case. opw-4866358
This fixes kiosk online payments so paid orders are properly sent onward for preparation instead of only showing a confirmation screen. It also limits kiosk payment choices to the online methods configured for that kiosk and makes single online-payment setups show the QR payment flow correctly.
Original PR description
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are…
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are redirected to the confirmation screen saying that the order is being prepared but the order is not sent to the preparation display, although the order is paid in the backend. Steps to reproduce: ------------------- * Create a payent method using terminal, for easier setup use stripe, you'll only need to setup serial number on the payment method but you do not need to do the whole stripe setup * Create an online payment method (use demo for example) * Change the kiosk settings to use those two payment methods * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ The fix to send the order to the backend is in the other part of this fix. Here we decide to only allow to use the online payment methods that have been set on the config. Previously if two were existing but only one setup you were able to select any of them. We also make a change to the `filterPaymentMethods` method. This method is called when pressing the pay button and is indirectly responsible for the fact that if there's only one payment method then we directly start the payment process. Prior to this fix if we only had a terminal method setup and clicked to pay an order we directly had the screen telling us to follow the instructions on the terminal. However if we only had a online payment method, when clicking on pay, we would directly have the screen prompting us to pay at the register, we could never select the payment method. With the fix, when there's only one payment method and it's online, clicking on pay will show the qr code. opw-5001998 Enterprise: https://github.com/odoo/enterprise/pull/92825
Purchase orders now consistently display both the vendor’s product name and the company’s internal product name across all pages. This prevents confusion when reviewing multi-page purchase orders and keeps product identification consistent.
Original PR description
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the…
#### Issue: Only the vendor name of a product is displayed on a purchase order on all pages except the first one. #### Step to reproduce: - make sure "Variant grid entries" is disabled in the settings. If you can't disable it, you can disable the view `purchase.order.form.inherit.matrix` to trigger the bug. - Create a product - Go to the purchase sheet - Add a vendor - Add the field "Vendor Product Name" and "Vendor Product Code" and fill them - Create a purchase order - Add your product - Add your product a second time (on a second line) - Confirm the PO - Activate debug mode - Go to the view and add a limit to have only 1 POL per page - Return to your PO - Go to the second page #### Current behavior: - Only the vendor name is displayed #### Expected behavior: - The vendor name should appear at the top, while the db name should be displayed under as in the first page. #### Cause of the issue: On the first page, POLs data are fetch through a `web_read` on the PO, while on other pages data are fetch through `web_read` on the POLs of the page. While fetching POL data with a `web_read` the client ask for several informations including: `name` and `product_id.display_name`. If both return the same, the client show only one, else it shows the `display_name` on top and the `name` below. - `name` return the vendor name - `product_id` is fetch with the context `partner_id` which transform the `display_name` from the db_name to the Vendor name Therefore it fetches twice the vendor name and don't have the name from the db. #### Solution: - remove the `partner_id` from the context. #### Consequence: - When adding a product to the PO, the name of the product displayed in the dropdown list will be the name from the db instead of the name of the vendor. PO confirmed that consequence is OK as long as it's still possible to search for product using vendor code, which is still possible. opw-4737337 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Italian POS receipts now exclude negative change payments before sending payment details to the fiscal printer. This prevents affected orders from being rejected by the printer and helps ensure sales remain properly reported to authorities.
Original PR description
Before this commit, specifying the payment method used to give back the change in a POS order would lead to the fiscal printer receiving a negative payment as input, which is not supported, thus leading to the order not being treated by the fiscal printer (so not reported to the government). Only the payments with is_change=true where filtered out. I am now adding a filter to only keep the positive payments in the receipt, as the fiscal printer is computing the change itself. opw-4931671
The signing dialog now consistently opens with the automatic signature option selected, whether or not the user already has a saved signature. This avoids confusion and creates a more predictable signing experience for users.
Original PR description
Ensure the signature dialog consistently defaults to the "auto" option, regardless of whether a user has a pre-set signature or not. task-5012307 Forward-Port-Of: odoo/enterprise#92276
This fix removes country-based restrictions that could prevent certain localization reporting modules from installing automatically. It helps ensure that when a new localization is added, its related reporting features are enabled as expected for existing company setups.
Original PR description
Specifiying countries in the manifest will only auto-install the module if at least one company is in one of the countries. This is not wanted as, if someone already has a company with it's reports module, and we add a new localization. We want that new localization to auto-install it's reports module.
The French VAT reporting flow now uses the correct account when creating reimbursement entries. This helps ensure reimbursement accounting is posted accurately, reducing the risk of manual corrections or reporting inconsistencies.
Original PR description
This commit will change the account used for the reimbursement move. task-4932427
Kiosk orders paid with an online payment method are now correctly sent to the preparation display after payment. This prevents staff from missing paid self-order kiosk orders that customers already see as being prepared.
Original PR description
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are…
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are redirected to the confirmation screen saying that the order is being prepared but the order is not sent to the preparation display, although the order is paid in the backend. Steps to reproduce: ------------------- * Create a payent method using terminal, for easier setup use stripe, you'll only need to setup serial number on the payment method but you do not need to do the whole stripe setup * Create an online payment method (use demo for example) * Change the kiosk settings to use those two payment methods * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ We bring back the code from the previous version which allowed orders to be sent to the preparation display: https://github.com/odoo/enterprise/blob/c4da0b5136f44a1437300844f6a06f44c5d79631/pos_self_order_preparation_display/models/pos_order.py#L12-L19 We also precise the sending condition in order to avoid to recompute the function which is already called in other setup. opw-5001998 Community: https://github.com/odoo/odoo/pull/223689
Code cleanup and technical improvements
This update prepares customer payment follow-up reports for easier customization. Businesses can now tailor which overdue and upcoming payment lines appear in communications without changing the core report flow.
Original PR description
The goal with these hooks is to allow customization of overdue and due lines that are going to be printed on the followup report to be communicated to the customer.
Documentation and clarification updates
This pull request records that GitHub user dimaurosalvatore has signed Odoo's Individual Contributor License Agreement. This is an administrative legal update that helps ensure future contributions from this contributor can be accepted under Odoo's contribution rules.
Original PR description
Description of the issue/feature this PR addresses: Sign the Odoo Individual Contributor License Agreement (CLA) for GitHub user dimaurosalvatore. Current behavior before PR: CLA not signed Desired behavior after PR is merged: CLA signed and recorded in doc/cla/individual/ under dimaurosalvatore.md. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds an individual Contributor License Agreement for a contributor. It supports the project's legal compliance process and does not affect product functionality or users.
This pull request adds a signed Contributor License Agreement record for the contributor tux-lyk. It supports Odoo's legal contribution process and does not change any product functionality or user workflows.
Original PR description
Description of the issue/feature this PR addresses: CLA Signature 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