Daily updates from Odoo
Wednesday, August 5, 2026
41 changes · master
New functionality added to Odoo
Adds a new Romania-specific D390 EC Sales report so businesses can prepare the required monthly declaration for intra-EU transactions in the ANAF XML format. It also improves report audit drill-downs so users see only relevant tax-tagged entries when reviewing EC Sales report totals.
Original PR description
This commit introduces a new module, 'Romania - EC Sales D390 Report'. For the support of Declarația 390 report as an EC List report for Romania in stable versions. Romanian localization has…
This commit introduces a new module, 'Romania - EC Sales D390 Report'.
For the support of Declarația 390 report as an EC List report for Romania in
stable versions.
Romanian localization has different requirements for the
EC Sales List report. So the generic EC Sales List does not work in the case of
Romania.
LEGAL REQUIREMENTS:
- Romanian tax authority accepts the Declarația 390 (Form 390) report for
cross-border transactions within the European Union.
- This declaration is filed on a monthly basis.
- The declaration must be submitted electronically to ANAF by the 25th of the
month following the month in which the transactions occurred. For example,
the declaration for transactions made in July must be filed by August 25th.
- The declaration must include all the intra-community transactions. These
transactions include:
1. Intra-Community acquisition of Goods
2. Intra-Community acquisition of Services
3. Intra-Community triangular trades
4. Intra-Community supplies of Goods
5. Intra-Community supplies of Services
REQUIRED FORMAT:
- Declarația 390 must be submitted electronically in a specific XML format.
The structure of this XML file is defined by ANAF.
- To facilitate compliance, ANAF provides a free software application called
'DUKIntegrator'. This tool allows businesses to:
1. Validate the generated XML file against the official schema to ensure it is
correctly formatted.
2. Generate the final PDF file with the XML attachment, which is the official
format for submission.
TECHNICAL DETAILS:
- Implemented the tax returns for the D390 EC Sales List report filing.
- Implemented XML export file generator, which creates the whole D390 XML report
with the required schema format.
- The D390 report needs to have the declarant's details in the report, the
attributes like 'nume_declar(Middle Name)', 'prenume_declar(First Name)',
'functie_declar(Job Position)' and 'adresa(Fiscal Domicile Address)'.
For collecting these details, we've created a wizard that will be on the
return validation action. Along with these details, we ask the user if the
current return is the corrected/rectified one, with the 'corrective_declaration'
field in this wizard. This wizard will then store these details in the
respective return. And in the XML export file generator, we are retrieving
these details from the return to show in the report.
REFERENCES:
- Drive link for official XML report schema, report structure, 'DUKIntegrator'
software and XML report attribute explanation in English: (
https://drive.google.com/drive/folders/1uzROZAM5Vuiv0HlBXw-vU28x5a9sVOpb)
- Official ANAF sources for D390 report: (
https://static.anaf.ro/static/10/Anaf/Declaratii_R/390.html)
- Official ANAF website for Electronic Declaration: (
https://www.anaf.ro/anaf/internet/ANAF/servicii_online/declaratii_electronice)
Forward-Port-Of: odoo/enterprise#109921Enhancements to existing features
SEPA direct debit batch validation has been optimized for large payment batches. This reduces processing time and avoids timeouts when validating thousands of payments, improving reliability for finance teams.
Original PR description
- Replace the `id:recordset` aggregation in `_get_expiry_date_per_mandate()` with `date:max` to compute the latest payment date directly in SQL. - Render `email_from` for all payments in batch and cache the computed authors by sender email to avoid repeated partner lookups during SDD pre-notification. This reduces ORM/cache overhead when validating large SEPA batches containing thousands of payments. Measured on a production-sized database: | metric | before | after | factor | |--------|-------:|------:|-------:| | `_get_expiry_date_per_mandate` (500 payments) | 564 ms | 111 ms | ~5x | | `_send_after_validation` notification (500 payments) | 92.9 s | 55.7 s | ~1.7x | | `_get_expiry_date_per_mandate` (1000 payments) | 890 ms | 178 ms | ~5x | | `_send_after_validation` notification (1000 payments) | timed out (>159 s) | 108.9 s | completed | OPW-6377340 Forward-Port-Of: odoo/enterprise#126429 Forward-Port-Of: odoo/enterprise#125439
Employees can now be associated with more than one company car, improving support for benefits and payroll scenarios where multiple vehicles are provided. This helps Belgian payroll and salary contract processes calculate and display company car benefits more accurately.
Original PR description
WIP to allow multiple company cars per employee
Archived tax returns now hide the actions that would validate, submit, or fetch e-invoices for them. This prevents users from accidentally continuing work on returns that have been closed or archived, reducing the risk of incorrect tax processing.
Original PR description
Hide validate and Submit button on tax returns when the return is archived, and hide the 'Fetch E-Invoice' button on the return check in case of GSTR-2B report when the return is archived. Previously, an archived return could still be validated and processed further. Since validation is the entry point for all subsequent actions on a return, blocking it at this stage prevents any further processing of archived returns. Related Pr: PR community - https://github.com/odoo/odoo/pull/270669 task-6303338
The Timesheet Assistant now supports keyboard navigation for reviewing and selecting suggested timesheet entries. This improves accessibility and helps users work faster without relying only on a mouse.
Original PR description
Implement full keyboard controls for managing timesheet suggestions to improve accessibility and user efficiency. This adds support for the following interactions: - ArrowUp / ArrowDown to navigate focus through rows - Space to select/deselect the focused item (and set the selection anchor) - Shift + Arrows to select continuous ranges of suggestions task: 6267620 Forward-Port-Of: odoo/enterprise#126143 Forward-Port-Of: odoo/enterprise#120437
Payroll warning messages now open directly in a detailed view when there is only one warning and no custom action is defined. This reduces extra clicks for users, while still showing a list when multiple warnings need review.
Original PR description
When the warning doesn't have a specific action implementation and it returns a single warning record, we display it in a form view instead of the list view. List view will be displayed only in multiple warning records. task-6425861
Appointment kanban cards now open the calendar view focused on today, making navigation more predictable. The separate upcoming meetings button now correctly opens the next scheduled meeting, while confirmation-related actions only load meetings that need confirmation.
Original PR description
Before, a click on an appointment kanban card lead to the gantt view of calendar.event, using the first next event as the initial_date of the gantt view. It was also the case when using the dedicated 'upcoming meetings' button on the card, which was pretty much a fake button. Now, use today as the default, next upcoming meeting when using 'upcoming meetings', using a new dedicated action, and only request meetings when using 'to confirm', as before. The tour is updated accordingly as well. Task-6344764
This draft improves the reliability of Knowledge article comments by adding tests for creating comments, handling large selections, deleting commented text, undo/redo behavior, keyboard navigation, and invalid comment placement. It helps ensure comment markers behave consistently before the feature is finalized, though the work is still described as needing cleanup.
Original PR description
This commit creates a test environment for article comments; it mounts a limited version of the Knowledge form view and mocks the necessary services and routes to allow for comment creation. It still needs to be heavily cleaned up, as many artifacts of earlier versions still linger, or have yet to be used. Many tests have also yet to be written; and the current version keeps them all in the same file. task-4235306
This update adds richer demo data for Belgian payroll testing, including employees, contracts, work schedules, attendance records, and a vehicle. It helps teams manually test payroll scenarios that better reflect real customer situations, and employee search now also works with external codes.
Original PR description
Add demo data records to match more realistic real world scenarios of employees, contracts, resource calendars and attendances. task-6364398
A new assistant rule was added for Timesheet Grid to help track runbot testing and the related branch. This improves internal testing visibility with minimal direct impact on end users.
Original PR description
Add an assistant rule to track runbot testing and which branch. --- task-6410639
Payroll warnings can now automatically apply only to records for the relevant country when company information is available. This reduces irrelevant warnings across multi-country payroll setups and helps teams focus on the alerts that apply to their local rules.
Original PR description
* = l10n_{be, ch, hk, in, sa}_hr_payroll
With this commit, by default when a warning will be defined on a specific country, if this warning is defined with a warning_domain and if the model linked to this warning have company field a sub domain to restrict this warning to model's record defined in this country will be automatically added.
task-6425987Tax return cards have been redesigned to be narrower and less tall, making long lists easier to review. This helps users scan return statuses and actions more quickly, using a layout aligned with other Odoo card views.
Original PR description
Returns are worked through as a list, but the cards were too wide and tall to scan. Reviewed the design following payroll's narrower kanban cards design. task-6088472
The data cleaning merge details popup has been redesigned to make it easier to understand how duplicate records will be combined. Improved views, field display, hover behavior, and keyboard focus help users review merges more confidently before confirming them.
Original PR description
Before this PR, the merge details popup needed a redesign, now the different views showcase the merge better to the user. | Before | Before | After | |--------|--------|--------| | First section |…
Before this PR, the merge details popup needed a redesign, now the different views showcase the merge better to the user. | Before | Before | After | |--------|--------|--------| | First section | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 44" src="https://github.com/user-attachments/assets/81faaad4-f950-4031-bd1c-66b46c1e61c3" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 07 59" src="https://github.com/user-attachments/assets/46895709-3575-4bae-864e-f33a96a7737b" /> | | Second section | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 47" src="https://github.com/user-attachments/assets/1fd3381c-d93c-4a2e-892b-134633279677" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 08 05" src="https://github.com/user-attachments/assets/0400e9f4-00ee-4d8b-9d77-a1566b1242f5" /> | | Third section | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 52" src="https://github.com/user-attachments/assets/dce3590c-4f16-473a-abd7-611f781f70f3" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 08 13" src="https://github.com/user-attachments/assets/a8315904-0067-4794-b48d-6b357445d1c7" /> | | Record hover | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 11 02" src="https://github.com/user-attachments/assets/1fa8fa2e-e9e0-45a6-a8c0-6dd4a8e6fa9b" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 08 17" src="https://github.com/user-attachments/assets/78434801-f34e-4e8f-87d9-bc9841a1628a" /> | | Field display | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 52" src="https://github.com/user-attachments/assets/d410867c-3013-4b90-99a2-b26bbab22e86" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 12 02" src="https://github.com/user-attachments/assets/38b1e359-02b5-4586-990e-f11805390ddd" /> | | Tab focus (accessibility) | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 10 44" src="https://github.com/user-attachments/assets/162b0a57-5138-45f7-b595-76337a5793dc" /> | <img width="1023" height="985" alt="Screenshot 2026-06-26 at 11 09 18" src="https://github.com/user-attachments/assets/3b79e21a-ab1c-47a8-874a-0f9f157938f3" /> | task-6196149
HR users can now confirm, reset, or mark multiple appraisals as done in one action. This reduces repetitive work and helps teams process appraisal workflows faster when managing many records.
Original PR description
Before this: HR users had to perform appraisal actions one by one, such as Confirm, Reset and Mark as Done. This was slow and repetitive when managing many appraisals. After this commit: Added bulk server actions to Confirm, Reset, and Mark as Done for multiple appraisals at once, making the appraisal process faster and easier for HR users. Task-6368348
The Sign app now only retrieves the single role record it needs instead of loading every role and all related details. This reduces unnecessary data fetching and should improve performance when opening sign template actions, especially in databases with many roles.
Original PR description
This `search_read` is done - without `domain` which means it fetches the entire table - without `fields` which means it fetches all fields And the business code only actually needs the id of the very first record which is returned. See `SignTemplateIframe`'s constuctor: `this.props.signRoles[0].id;` AFAICS, that's the only place where it's used. This will be better refactored in master. Forward-Port-Of: odoo/enterprise#126835
Resolved issues and error corrections
Automatic bank transaction matching now ignores archived bank accounts when identifying the related customer or vendor. This prevents old or inactive bank details from assigning transactions to the wrong partner, improving reconciliation accuracy.
Original PR description
Steps to reproduce: - Have a partner with a bank account, then archive the res.partner.bank record (keep the partner active). - Import or create a bank transaction (e.g. via bank sync) whose account number matches that archived bank account, and whose label/payment_ref would otherwise match a reconciliation model for a different partner. - Let the transaction go through automatic partner retrieval. => The archived bank account's partner is assigned, even though a normal manual entry (which skips the account-number match) would have used the label instead. Cause of the issue: `AccountBankStatementLine._retrieve_partner()` matches statement lines to partners in batch using raw SQL joining `res_partner_bank`. The query's WHERE clause filters out archived partners (`AND partner.active`) but never filters `res_partner_bank.active`. opw-6340479 Forward-Port-Of: odoo/enterprise#124748 Forward-Port-Of: odoo/enterprise#124537
This fixes an issue in Studio approval requests where a reference field could be created without a valid related model. Ensuring the reference always points to a defined record type helps prevent approval setup errors and improves reliability for users configuring workflows.
Original PR description
studio.approval.request Many2oneReference must have a valid model field.
The Helpdesk unanswered filter no longer treats automatic acknowledgement emails as customer replies needing attention. This keeps support queues cleaner by showing only tickets that genuinely require a response from the team.
Original PR description
Steps to reproduce: --------- - install website_helpdesk - set an email address on the company partner if it is empty ( it is empty in a database without demo data). - generate a ticket from the website. - apply the Unanswered filter. Issue: ------ system generated acknowledgement message is considered an unanswered customer reply. Fix: -------- system generated acknowledgement messages are now considered answered. task-5138678 Forward-Port-Of: odoo/enterprise#125977
This fixes an issue that blocked companies using Avalara Brazil from confirming several customer invoices at once. Users can now validate multiple affected invoices in one action without the process failing.
Original PR description
**_Steps to reproduce:_** * Install `l10n_br_avatax` and configure Avalara Brazil. * Create at least two customer invoices. * Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara…
**_Steps to reproduce:_** * Install `l10n_br_avatax` and configure Avalara Brazil. * Create at least two customer invoices. * Ensure the fiscal position is set to **Automatic Tax Mapping (Avalara Brazil)**. * Select the invoices and click **Action → Confirm Entries**. **_Observed behavior:_** * A traceback is raised with `ValueError: Expected singleton: account.move(...)` and the invoices cannot be validated. **_Cause:_** * During tax extraction, `_extract_tax_values_from_l10n_br_avatax_detail` accesses `self.invoice_filter_type_domain` while `self` may contain multiple `account.move` records. * Accessing `invoice_filter_type_domain` on a multi-recordset raises an `Expected singleton` error, preventing the validation of multiple invoices. **_Fix:_** * Build the returned tax values by iterating over each invoice in the recordset and using the corresponding `invoice_filter_type_domain`. * This ensures `_extract_tax_values_from_l10n_br_avatax_detail` correctly handles multiple invoices during validation without raising a singleton error. opw-6334761 Forward-Port-Of: odoo/enterprise#126437 Forward-Port-Of: odoo/enterprise#124993
The aged payable and receivable drill-down now filters out bills and invoices that were already fully settled for the selected report date. This gives finance teams a cleaner and more accurate view of outstanding balances, especially when reviewing historical aging reports.
Original PR description
Steps to Reproduce: 1. Create a vendor/customer with multiple bills/invoices. 2. Fully pay one or more, leaving at least one still open for the same partner. 3. Open Accounting > Reporting > Partner…
Steps to Reproduce:
1. Create a vendor/customer with multiple bills/invoices.
2. Fully pay one or more, leaving at least one still open for the same partner.
3. Open Accounting > Reporting > Partner Reports > Aged Payable/Receivable.
4. Set to any date and click into an aging bucket for that partner.
Issue:
The drill-down list shows fully settled bills (residual = 0.00) alongside genuinely outstanding ones. Only surfaces when the partner has at least one open balance — if everything is paid, there is no bucket to click into.
Root Cause:
aged_partner_balance_audit builds the drill-down domain filtering only by reconcile flag, journal type, and date range — never checking residual. Additionally it completely overwrites the XML action domain (account.action_amounts_to_settle) which already had ('amount_residual', '!=', 0), losing that protection entirely.
Fix:
Added ('residual_at_date', '!=', 0) to the domain in aged_partner_balance_audit and set recon_limit in the action context so residual_at_date computes as of the report's 'as of' date rather than today's value:
action['context'] = {
'recon_limit': options['date']['date_to'],
}
Without recon_limit, residual_at_date falls back to amount_residual (today's value) which incorrectly excludes bills that were genuinely open on the report date but paid after it.
Result:
The drill-down now correctly shows only genuinely outstanding items regardless of whether the report is run as of today or a historical date.
opw 6333699
Forward-Port-Of: odoo/enterprise#126021This fix prevents an error that could occur when appraisal survey settings were missing or empty. It helps ensure appraisal survey functionality continues working reliably during setup or upgrade scenarios.
Original PR description
Avoid a TypeError in _compute_allowed_survey_types when allowed_survey_types is False by falling back to an empty list before unpacking and appending the appraisal survey type.
```py
File "/home/odoo/src/enterprise/saas-19.3/hr_appraisal_survey/models/survey_survey.py", line 33, in _compute_allowed_survey_types
survey.allowed_survey_types = [*survey.allowed_survey_types, 'appraisal']
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: Value after * must be an iterable, not bool
```
Ref: https://github.com/odoo/odoo/pull/268125
Bug introduced in: https://github.com/odoo/enterprise/commit/896f54532338b07265722cb4a4161131d408f58c
upg-[4458975](https://upgrade.odoo.com/odoo/request/4458975?debug=1)
Forward-Port-Of: odoo/enterprise#124417Peruvian electronic invoices now format address details according to SUNAT's current UBL 2.1 requirements. This helps prevent validation issues for invoices involving districts and urban subdivisions, supporting smoother legal invoice submission in Peru.
Original PR description
Update electronic invoicing address nodes to align with current SUNAT requirements. This transitions the geographic data formatting from the legacy UBL 2.0 schema to the standard UBL 2.1 specification, ensuring proper structural validation for districts and urban subdivisions. Documentation used: https://cpe.sunat.gob.pe/sites/default/files/inline-files/guia+xml+factura+version+2-1+1+0+(2)_0+(2).pdf opw-6282314 Forward-Port-Of: odoo/enterprise#126380 Forward-Port-Of: odoo/enterprise#121390
The Time Off Gantt view now only shows time off types that are currently available for selection. This prevents managers from accidentally choosing outdated or disabled leave types when planning time off.
Original PR description
Steps to reproduce: - In Time Off, create a leave with any selectable time off type - Modify this time off type so that it is not selectable anymore - Go to "Management" -> "Time Off" and select the gantt view - When clicking on a day, the now non selectable time off type still shows in the list of available time off types Reason: When fetching time off types to display, the code did not check if the time off type was selectable, leading to this issue. How it was fixed: Added a condition when fetching time off types to only get those that are selectable. Task ID: 6314831
Planning filters for employees and materials now apply the open-shift rule only to shifts without an assigned resource. This prevents assigned shifts from being incorrectly included or excluded, helping teams view the right planning data.
Original PR description
Before this commit, the domain wrongly assumes that we always search on shifts having no role or a role containing resources of types 'user' or 'material' (1). Additionally to the basic domain which searches on the shifts having resources of types 'user' or 'material' (2). After this commit, we add a condition on domain (1) to only apply it for open shifts (shifts having no resource_id). no-task Forward-Port-Of: odoo/enterprise#126616 Forward-Port-Of: odoo/enterprise#126247
Users can now duplicate several maintenance requests at the same time without the system showing an error. This makes bulk work in the maintenance app smoother and avoids interruptions for teams managing equipment requests.
Original PR description
Currently, when a user attempts to duplicate multiple maintenance requests simultaneously, the system throws a ValueError (Expected singleton). This PR fixes that. ### How to reproduce the issue: - Install `mrp_maintenance` module; - Open maintenance request list view; - Select multiple records and try to duplicate them using the Action button; - It will throw a traceback stating a singleton error. ### Expected behavior after PR is merged: Now multiple maintenance requests will be copied without raising any errors. Forward-Port-Of: odoo/enterprise#124255
The cart now prevents customers from increasing rental product quantities beyond what is available for the selected dates. Availability is also rechecked when rental dates are changed, reducing overbooking risk for planned services.
Original PR description
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning…
From the cart, it is possible to increase the amount ordered of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. Add as much product "test" to the cart as possible (the quantity is limited) 7. Open the cart 8. You can increase the amount of the product regardless of its availability Issue: We don't check the renting availabilities to limit the maximum quantity of the product Solution: Check that the new quantity of the product is available in `_verify_updated_quantity` for the specified dates. We also need to check the availability of the product when we modify the rental dates opw-6274035 Forward-Port-Of: odoo/enterprise#126497 Forward-Port-Of: odoo/enterprise#123056
This fix prevents sale orders linked to point-of-sale planning from receiving duplicate lines when an order syncs multiple times. Sale order lines are now created only once when the POS order is paid, reducing billing and order accuracy issues.
Original PR description
Before this commit, the creation of sale order lines was in sync_from_ui and was executed every time we would enter the method. Since this method is called everytime we sync the order with the backend, it would create duplicated lines on the sale order. The logic is now moved to action_pos_order_paid, which is only called once when the order is paid. Forward-Port-Of: odoo/enterprise#124813
Preparation tickets in Point of Sale now load the required styling again after a receipt printing refactor caused some formatting to disappear. The update also restores missing receipt information, improves receipt display, and ensures customer notes are printed correctly.
Original PR description
..., pos_restaurant, pos_self_order, pos_urban_piper --- During the refactor of the receipt printing system, some CSS classes were no longer loaded with preparation tickets. As a result, preparation tickets lost part of their original styling. To restore the expected rendering, ensure all required classes are properly loaded while keeping the loading minimal. Additionally, some receipt data were missing after the refactor and some UI elements could be improved. This commit restores the missing data and improves the overall UI. It also fixes an issue where customer notes were not printed on the receipt. Templates checked: * point_of_sale.pos_order_change_receipt * point_of_sale.pos_order_change_receipt_line --- Task: https://www.odoo.com/odoo/project/1737/tasks/6133403 Refacto: https://github.com/odoo/odoo/pull/244395 Forward-Port-Of: odoo/enterprise#124898 Forward-Port-Of: odoo/enterprise#118782
A small issue in the accounting journal report was fixed by cleaning up unused date information in the report line actions. This helps keep the report interface consistent and reduces the chance of confusing or incorrect behavior for users.
Original PR description
Forward-Port-Of: odoo/enterprise#126603 Forward-Port-Of: odoo/enterprise#125266
The manufacturing planning tests were adjusted to match the corrected handling of demand for the current day. This helps ensure replenishment suggestions include same-day activity scheduled later in the day, reducing the risk of misleading planning checks.
Original PR description
Updated the forecast suggestion test expectations after monthly demand was updated to count the full current day, so same-day orderpoint replenishment moves scheduled later in the day are also included Community PR: odoo/odoo#262435 TaskID-5490137 Forward-Port-Of: odoo/enterprise#126732 Forward-Port-Of: odoo/enterprise#115944
Updated the Italian Balance Sheet report labels to use the correct Italian wording. This helps Italian-speaking accounting users read and interpret the report more accurately without changing the report's calculations or workflow.
Original PR description
### Steps to reproduce the issue: 1. Download Accounting and l10n_it 2. Install and switch to italian language 3. Go to Balance Sheets and select Balance Sheet (IT) 4. Some words are not correct [Here]( https://docs.google.com/spreadsheets/d/1-w83oAHTxDRIi-W_VSJiscNclw-yijzQUHOgMnTq7jE/edit?gid=0#gid=0) the wrong fields with their correct translations. opw-6424609 Forward-Port-Of: odoo/enterprise#126253
Users opening a bank statement line from an in-app notification will now see the related conversation and activity panel. This ensures tagged users can view the comment context immediately, reducing confusion during bank reconciliation work.
Original PR description
Problem: When navigating to a bank statement line through a notification, the chatter doesn't appear. Steps to reproduce: 1. Set in app notifications for one of the users 2. Open Accounting > Bank > To Reconcile 3. Select any bank statement line 4. Tag the user from step 1 in a comment 5. Log in as that user 6. Check notifications and click the new notification 7. Notice how the chatter does not appear on the bank statement line after navigating there Cause: The chatter was not enabled on the bank statement line form view. opw-6410186 Forward-Port-Of: odoo/enterprise#125777
Cancelled Mexican electronic invoices can now be reprinted with their required fiscal information, including QR codes, digital stamps, and fiscal folio details. This ensures legally relevant cancelled invoices remain complete and usable for audit or compliance purposes.
Original PR description
### Issue before this commit: When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR…
### Issue before this commit: When an invoice's CFDI cancellation request is confirmed (state moves from sent to cancel), reprinting the invoice PDF no longer displays the fiscal information (QR code, digital stamps, fiscal folio/UUID, etc.), even though the signed CFDI attachment is still present on the invoice. ### Steps to reproduce the issue: 1. Download Accounting and l10n_mx 2. Create an invoice and send it to CFDI 3. Select 'Request for cancel' 4. Wait and click retry button in the CFDI tab until the invoice is marked as cancelled 5. Print the invoice again 6. See PDF does not show fiscal information (QR, fiscal folio, etc.) ### Cause of the issue: https://github.com/odoo/enterprise/blob/f6c94d4ca3ef4211a5ab00bf0b39f6a7675c8f79/l10n_mx_edi/models/account_move.py#L904-L909 Once the CFDI is cancelled, the computed field switches to 'cancel', so the condition fails and the method falls back to the generic account.report_invoice_document template, which has no knowledge of CFDI fiscal fields. ### Reason to introduce the fix: A cancelled CFDI invoice is still a legally relevant fiscal document in Mexico and must be reprintable with its fiscal data intact (to prove it was issued and later cancelled). The fix extends the condition to also cover the 'cancel' state, ensuring the CFDI-specific report template is used whenever a valid attachment exists, regardless of whether the CFDI is currently signed or cancelled. opw-6393656 Forward-Port-Of: odoo/enterprise#126750 Forward-Port-Of: odoo/enterprise#126466
Date and datetime fields are now hidden from the pivot setup popup once all available time groupings have already been added. This prevents users from accidentally creating duplicate entries and keeps drag-and-drop behavior predictable in spreadsheets.
Original PR description
Current behavior before PR: - Date and datetime fields remained visible even when all their granularities were already added to the pivot. - Users could add the same field with the same granularity multiple times, creating duplicate IDs and causing unexpected drag and drop behavior. Desired behavior after PR is merged: - Hide date and datetime fields from the popup once all available granularities have already been added to the pivot. - This prevents duplicate field IDs and keeps the popup behavior consistent with spreadsheet pivots during drag-and-drop. Task: [6295794](https://www.odoo.com/odoo/project/2328/tasks/6295794) Forward-Port-Of: odoo/enterprise#126830 Forward-Port-Of: odoo/enterprise#123280
Dropdown fields in account reports now show the text cursor aligned to the right instead of appearing in the middle. This improves the visual polish and usability of report filters without changing any business logic or report data.
Original PR description
Dropdown inputs inside of an account report show the cursor in the center of the input field. The cursor has been changed to be right-aligned. task-6247454 Forward-Port-Of: odoo/enterprise#120728
Code cleanup and technical improvements
This update modernizes part of the Documents app so it remains compatible with the next version of the underlying interface framework. It preserves existing behavior for document selection and topbar actions, reducing the risk of stale or incorrect action buttons for users.
Original PR description
Replaced `useLayoutEffect` (from `@web/owl2/utils`) with `onMounted` + `onPatched` because `useLayoutEffect` is deprecated in OWL3. `useLayoutEffect`'s shim is literally `onMounted + onPatched` with…
Replaced `useLayoutEffect` (from `@web/owl2/utils`) with `onMounted` + `onPatched` because `useLayoutEffect` is deprecated in OWL3. `useLayoutEffect`'s shim is literally `onMounted + onPatched` with a deps-diff guard; a native reactive `useEffect` does NOT work here — it runs outside OWL's patch lifecycle and stops re-running once the first selection settles, leaving topbar actions stale. A manual diff of `[this.props.targetRecords, this.ui.isSmall]` inside `onPatched` reproduces the post-patch, gated recompute the original shim performed. The useLayoutEffect refactored in this PR had test coverage — below are some tests that failed when the effect was commented out, and are now passing: - @documents/kanban_view/Check actions with preview - @documents/kanban_view/Download button availability - @documents/list_view/only show common available actions see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2593680/build/114734104 `useEffect` from `@odoo/owl` is NOT an equivalent replacement — despite both `this.props.targetRecords` and `this.ui.isSmall` being reactive signals, the effect stops firing after the first selection settles. Only patch-tied lifecycle hooks sustain the subscription.
The Documents module was updated to use a newer internal approach that aligns with the next version of Odoo's interface framework. This reduces maintenance risk and adds test coverage to help ensure document selection actions continue working correctly.
Original PR description
Replaced `useLayoutEffect` with `computed()` signals because `useLayoutEffect` is deprecated in OWL3. Both `recordsToDelete` and `recordsToArchive` are pure derived values from `this.selection`. Using `computed()` removes the effect entirely, making the reactive dependency explicit with no layout-effect overhead. When commenting out the useLayoutEffect there was no error, the code we refactored had NO TEST coverage. A test was written to ensure our fix was correct, and it was tested against the previous useLayoutEffect: - Passed with previous useLayoutEffect. - Failed with previous useLayoutEffect commented. - Passed with our OWL3 replacement.
Manufacturing work orders and VoIP calling screens were updated to use Odoo's newer overlay framework. This is an internal modernization that helps keep these interfaces compatible with the latest platform changes, with no expected functional change for users.
Original PR description
`overylayService` has been converted to an OWL3 Plugin, so existing useService("overlay") call sites need to be rewritten.
This commit is the result of the owl3-migration script.The Documents app’s drag-and-drop area was updated to use the current supported framework approach, reducing future maintenance risk. A new automated test was added to confirm the drop zone still reacts correctly while scrolling and dragging files.
Original PR description
Replaced the `useLayoutEffect` in `DocumentsDropZone` that registered dragover, dragleave, and scroll listeners on `props.parentRoot()` and tracked `scrollTop` for overlay positioning. Used…
Replaced the `useLayoutEffect` in `DocumentsDropZone` that registered dragover, dragleave, and scroll listeners on `props.parentRoot()` and tracked `scrollTop` for overlay positioning. Used `useListener` from `@odoo/owl` and a class-level `signal(0)` for the scroll offset. `useLayoutEffect` is deprecated in OWL3. `useListener` is the idiomatic OWL3 API for external listeners: it accepts the ref getter directly as its target, subscribes to it reactively, and handles add/remove lifecycle automatically — no manual cleanup or `onMounted`/`onUnmounted` pairing required. The `proxy` state property for `topOffset` was replaced with a `signal(0)` so the template reads `this.topOffset()` with fine-grained reactivity. When commenting out the useLayoutEffect there was no error, the code we refactored had NO TEST coverage. A test was written to ensure our fix was correct, and it was tested against the previous useLayoutEffect: - Passed with previous useLayoutEffect. - Failed with previous useLayoutEffect commented. - Passed with our OWL3 replacement.
Point of Sale orders now receive their required references before the order is created. This helps prevent initialization issues in localized invoicing, payment settlement, and connected POS flows, making order processing more reliable.
Original PR description
Before this commit: ==== - In the createNewOrder method, the pos.order was created first, and the references were set afterward using getNextOrderRefs. After this commit: ==== - References are now set before creating the pos.order instance, ensuring proper initialization. task-4677391 Community PR - https://github.com/odoo/odoo/pull/205859
The Luxembourg reporting test data has been moved into separate XML files, making the test suite easier to navigate and maintain. This is an internal cleanup that does not change product behavior for users.
Original PR description
Each expected FAIA content is around 700 lines long. It is cumbersome to navigate the file. This commit moves the expected FAIA content to their own files. This has the added bonus of adding xml syntax highlighting to the file if one uses VSCode or a similar program.