Thursday, September 3, 2026
87 changes · master
New functionality added to Odoo
Businesses in the Philippines can now apply legally required Senior Citizen and Person With Disability discounts and VAT exemptions directly on quotations and sales orders, not only on invoices. This helps sales teams quote compliant prices earlier, prevents double discounting, and carries the discount details through to the invoice.
Original PR description
In the Philippines, Senior Citizens (SC) and Persons With Disabilities (PWD) are legally entitled to statutory discounts and VAT exemptions on eligible goods and services. The `l10n_ph_invoice`…
In the Philippines, Senior Citizens (SC) and Persons With Disabilities (PWD) are legally entitled to statutory discounts and VAT exemptions on eligible goods and services. The `l10n_ph_invoice` module already handles these on customer invoices and credit notes; this extends the same privileges to quotations and sale orders. This adds a new `l10n_ph_sale` module, enabled like `l10n_ph_invoice` via a separate "Discount Privileges on Sale Orders" toggle in the Philippine Accounting settings (`module_l10n_ph_sale`, defined in `l10n_ph` next to the invoice toggle). It mirrors the invoice implementation: * Sale Order Line: `sale.order.line` inherits the shared `l10n_ph.discount.privilege.line.mixin` and provides the model-specific hooks (`_l10n_ph_get_discount_price_details` recomputes the gross amounts with the tax engine) plus helpers to adjust the price unit and taxes from the privilege's fiscal position. Privilege fields are propagated to the generated invoice lines in `_prepare_invoice_line`, so invoiced lines behave exactly like lines the privilege was applied on. * Application Wizard: `l10n_ph.discount.privilege.wizard` is extended with `order_id` / `sale_order_line_id` so the same preview / scope-filtering / apply / remove-all / single-line-remove flow works on draft and sent quotations and sale orders. * Sale Discounts interplay: privileged lines are excluded from the standard sale Discounts wizard to avoid double discounting. * Views: "Discount Privileges" buttons below the order lines, regular/special discount amount columns, and the line discount becomes readonly while a privilege is applied. * Security: salesmen get read access to privilege definitions and CRUD on the wizard; configuring privilege definitions remains reserved for Accounting. * Tests: coverage for the wizard flows, scopes, fiscal position mappings, discount computations, state guards, access rights, invoice propagation and the sale Discounts interplay. Task-6032201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds the required Vietnamese Sổ Nhật ký chung (S03a-DN) report so businesses can review journal entries chronologically alongside the existing general ledger. The update also improves report consistency and corrects foreign currency amounts in the Vietnamese general ledger.
Original PR description
Circular 200/2014/TT-BTC requires a "Sổ Nhật ký chung" (S03a-DN) next to the general ledger (S03b-DN): the same journal items, but listed entry by entry in chronological order instead of account by…
Circular 200/2014/TT-BTC requires a "Sổ Nhật ký chung" (S03a-DN) next to the general ledger (S03b-DN): the same journal items, but listed entry by entry in chronological order instead of account by account. Add it as a second Vietnamese variant of the general ledger root report, reusing the S03b-DN counterpart matching engine. Grouping by account.move implies a few differences: the query uses the 'strict_range' scope, since a journal reports the movements of the period and carries no opening balance; move_id is a custom groupby, so that the chronological order is kept; lines are labelled with the account they hit, which the move group no longer shows; and the account-centric post-processing of the general ledger is dropped. Also order the rows of _fetch_full_move_rows, which had no ORDER BY. The order in which Postgres returned them decided the order of the split rows produced by the proportional counterpart matching, making both S03a-DN and the existing S03b-DN report non-deterministic. task-6089050
Enhancements to existing features
Companies can now optionally record unpaid breaks in employee attendance, including from the systray and kiosk checkout flow. Breaks are deducted from worked hours, daily totals and overtime, helping payroll and managers get more accurate time records with less manual correction.
Original PR description
Description of the issue/feature this PR addresses: Attendance records only represented check-in and check-out times. Unpaid breaks therefore required manual time corrections and were not…
Description of the issue/feature this PR addresses: Attendance records only represented check-in and check-out times. Unpaid breaks therefore required manual time corrections and were not consistently reflected in worked hours, overtime, the attendance systray or the kiosk flow. Current behavior before PR: - The complete check-in/check-out interval is treated as worked time. - Employees cannot review and correct attendance details from the systray. - Kiosk users cannot record their total break after checking out. Desired behavior after PR is merged: Add an optional company-level break management setting and store the total break duration on each attendance. Validate that breaks apply only to closed attendances, are non-negative and do not exceed the attendance duration. Deduct breaks from worked hours, daily attendance totals and overtime. Recompute overtime when a break changes and expose the break information in the relevant attendance and employee views. Add an attendance review to the systray showing today's sessions, check-in and check-out details, locations, breaks and total worked duration. Allow permitted users to edit attendance details using explicit Save and Discard actions. Pending changes are saved before switching sessions or checking in or out, while validation failures keep the draft available for correction. Update the kiosk checkout flow with a dedicated dialog for recording break minutes on the attendance that was just closed. Preserve manual, PIN and barcode identification and keep server-side validation authoritative if the attendance changes before the break is saved. Add backend and HOOT coverage for break validation, worked-hours and overtime calculations, attendance review editing and synchronization, and kiosk break updates. task-5252996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents the payroll dashboard from crashing when a company has payroll warnings across multiple pay schedules, such as monthly and weekly schedules. It ensures cached dashboard items stay distinct, so users can reliably return to payroll after refreshing the browser.
Original PR description
**Steps to reproduce** - Go to Hong Kong company - Go to payroll - Go back and refresh your browser - Go to payroll **Crash:** OwlError: Got duplicate key in t-foreach: pending_175_2026-08-31 Error:…
**Steps to reproduce**
- Go to Hong Kong company
- Go to payroll
- Go back and refresh your browser
- Go to payroll
**Crash:**
OwlError: Got duplicate key in t-foreach: pending_175_2026-08-31
Error: Got duplicate key in t-foreach: pending_175_2026-08-31
at PayrollDashboardComponent.template_hr_payroll_Dashboard (eval at compile (https://123484110-master-all.runbot135.odoo.com/web/assets/debug/web.assets_web.js:16100:14), <anonymous>:59:49) (/web/static/lib/owl/owl.js:7070)
at RootFiber.render (https://123484110-master-all.runbot135.odoo.com/web/assets/debug/web.assets_web.js:12537:28) (/web/static/lib/owl/owl.js:3507)
at ComponentNode.render (https://123484110-master-all.runbot135.odoo.com/web/assets/debug/web.assets_web.js:12795:15) (/web/static/lib/owl/owl.js:3765)
**Reason:**
04065101644 introduced caching on payroll dashboard. Cached pending warnings were keyed by id + date only, dropping the schedule that distinguishes cards for the same warning across pay schedules (e.g. monthly vs weekly).
Colliding keys crashed the dashboard with a duplicate t-foreach key, notably on l10n_hk which mixes both schedules.
task-6522399Code cleanup and technical improvements
This update simplifies internal setup for website, email, and HTML editing tools by removing unnecessary data-passing layers. It should make the code easier to maintain without changing how users interact with these features.
Original PR description
* html_builder,html_editor,mass_mailing,website Remove `useSubEnv()` calls that were only passing component-local data through the environment layer. Replace with direct instance variable or prop assignments. This simplifies component initialization by eliminating unnecessary environment-based indirection. Values like `localOverlayContainerKey` and `builderRef` are now: - Assigned directly to component instances - Passed as component props where appropriate - Accessed directly from the component in templates
Attendance breaks are now deducted consistently from worked time, overtime, work entries, payroll calculations, and the combined Timesheets/Attendance menu. This helps employees, managers, and payroll teams see accurate totals when checkout breaks are used, while keeping scheduled contract work entries intact.
Original PR description
Attendance breaks reduce worked and overtime hours in hr_attendance, but attendance-based work entries and the combined Attendance/Timesheets systray still treated the complete check-in/check-out interval as worked time. Deduct the break duration when building attendance work-entry intervals, together with refused overtime, and skip intervals fully consumed by those deductions. Keep scheduled work entries for calendar-based contracts while applying breaks to their overtime intervals. Integrate the attendance review into the Timesheets systray with separate Attendance Review and Time Recording tabs. Route checkout through the shared attendance action, preserve the Timesheets discard flow, and display total and expected hours consistently in the footer. Cover reduced and fully consumed attendance intervals, calendar-based contracts, approved overtime and downstream payroll overtime totals. task-5252996
Belgian payroll now limits the daily value paid for political leave using a monthly cap. This helps ensure political leave payments follow the configured payroll limit and remain consistent with Belgian payroll rules.
Original PR description
This commit caps the value of a work day of type political leave (LEAVE1749) based on a monthly cap defined as a salary rule parameter. TaskID: 6486038
This change makes it easier for Odoo to allow selected properties of standard fields to be edited when needed. It supports future customization needs, such as AI-related settings, without broadly changing how fields work for users.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The stock app now opens the specific delivered move lines from a lot's transfers button instead of the broader transfer record. This gives teams clearer traceability for recalls or customer follow-up, and adds a direct option to email the concerned customer.
Original PR description
For better traceability and complete information consistency, instead of showing the whole transfer we show the move lines. The move lines shown, are the final move lines that were delivered including the current selected `lot_id`. This is useful in many cases, for example a product recall; Product recalls need very precise information about the product being recalled. Knowing the final delivered product move line is vital, as one product can be a component in many different products. 'Send Email' action was also added in order to directly send an email to the concerned customer. Task: 6435027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now configure date and datetime fields to show warnings when a selected date is in the past, in addition to the existing future-date warning. This helps teams prevent mistakes on deadlines, end dates, and similar time-sensitive fields, while Studio field options have been reorganized for easier configuration.
Original PR description
Before this change, date and datetime fields only supported a warning for future dates. There was no option to warn users when a past date based on today, which is useful for fields such as deadlines or end dates. After this change, a new warning option is introduced to support past date warnings in addition to the existing future date warning, giving users more flexibility when configuring date fields. Field-specific options in Studio are also reorganized Enterprise PR: https://github.com/odoo/enterprise/pull/125963 Documentation PR: https://github.com/odoo/documentation/pull/19158 Upgrade PR: https://github.com/odoo/upgrade/pull/11147 Task-6366295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now view their event registrations and download tickets directly from the customer portal. Access is limited to the sales order customer or the registered attendee, making ticket access convenient while avoiding weaker email-based matching.
Original PR description
Purpose ======= Give the possibility to users to see their event registration tickets from the customer portal. Specification ============= Users will be able to see a registration and download its ticket if: - the current user is the SO customer OR - the registration partner is the current user The idea of showing registrations where the email matches the current user's was discussed, but then dropped. The criterion is too weak, it could introduce security issues and isn't robust enough given potential email formatting inconsistencies. Task-5384734 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project and timesheet portal pages now show durations and dates in a more readable, consistent format. This makes it easier for customers and employees to understand logged time, remaining work, and related project timelines at a glance.
Original PR description
- Replaced float_time with the duration widget using the narrow format to display durations in a more human-readable way (e.g. 1h 20m). - Updated datetime widget formatting across the affected portal views to use the required medium date and medium date + short time formats for consistent date/time presentation. - Fixed hide_seconds being ignored when a named format (medium/long/full) was passed alongside it in ir.qweb.field.datetime. task-6197942
Landed costs can now be limited to the specific products they apply to instead of being spread across every item in a transfer or manufacturing order. Businesses can predefine target products on landed cost items, reducing manual adjustments, errors, and improving inventory valuation accuracy.
Original PR description
Currently, landed costs are distributed across all products of the selected transfers. In practice, some costs (e.g., customs duties or special handling fees) may apply only to specific products…
Currently, landed costs are distributed across all products of the selected transfers. In practice, some costs (e.g., customs duties or special handling fees) may apply only to specific products only, forcing users to manually adapt the adjustment lines after computation, which is error-prone and time-consuming. - When creating a Landed Cost Product, users can predefine the products it should apply to when the cost is known to always target specific products. - When this landed cost product is added to a cost line, the predefined products are automatically added to Apply On if they are present in the selected transfers/MO, removing the need for manual selection. - Users can still manually add other products from the transfers/MO when the cost should also apply to products that were not predefined. With this change, landed costs can be applied only to relevant products, eliminating manual adjustments, reducing user errors, and improving valuation accuracy and usability. task-5214058
Product catalog filters have been streamlined across sales, purchase, manufacturing, repair, and accounting flows. This reduces duplicate logic behind the scenes, making catalog filtering easier to maintain and more consistent for users working with orders and related documents.
Original PR description
* Move the selected section filter to `account` since it's where the (sub)sections logic is defined * Introduce `catalog_is_in_order` in the `module`, factorizing the logic of multiple fields: * `product_catalog_product_is_in_bom` * `product_catalog_product_is_in_mo` * `is_in_purchase_order` * `product_catalog_product_is_in_repair` * `product_catalog_product_is_in_sale_order` * Drop the compute methods as they are not used nor useful (their only purpose was to disable field storage) * Rely on the orm subquery abilities (`_search`) See also odoo/upgrade#11174
AI-related field settings can now be customized not only for manually added fields, but also for standard fields already provided by Odoo. This gives teams more flexibility when configuring AI behavior across existing business data without needing custom-created fields.
Signature requests now show which signers are missing an email address instead of only displaying a generic warning. This makes it faster for users to complete documents with multiple signers and avoid checking each signer manually.
Original PR description
When a signature request had a signer without an email address, saving it only said that all signers must have a valid email address, so on a document with several signers there was no way to tell which one was incomplete without checking them one by one. The error now names them. task-6515178
Users can now configure date and datetime fields to warn when a selected date is in the past, in addition to the existing future-date warning. This helps teams catch outdated deadlines, end dates, or similar entries earlier, while Studio’s field options are reorganized for easier configuration.
Original PR description
Before this change, date and datetime fields only supported a warning for future dates. There was no option to warn users when a past date based on today, which is useful for fields such as deadlines or end dates. After this change, a new warning option is introduced to support past date warnings in addition to the existing future date warning, giving users more flexibility when configuring date fields. Field-specific options in Studio are also reorganized Community PR: https://github.com/odoo/odoo/pull/279010 Documentation PR: https://github.com/odoo/documentation/pull/19158 Task-6366295
The test suite now checks the latest document in the same order users see in the interface, rather than relying on internal cache order. This reduces confusing test behavior and helps prevent false failures when validating Mexican electronic invoicing for point of sale flows.
Original PR description
Because of missing `sorted()`, we were asserting the last document using the cache order and not the order in which they are in the UI. That brings confusion when reading the code and leads to failing tests if, for some reason, the cache is refreshed.
Belgian payroll now supports the correct 274.13 and 281.13 reports for economic unemployment allocations and related taxes. This ensures these amounts are no longer included in the older 274.10 and 281.10 reports, improving compliance and reporting accuracy.
Original PR description
- previously economic unemployment allocations / taxes were reported in the 274/281.10 - now with the support of 274/281.13 they are reported correctly. - new pdf for 281.13, reporting lines in UI. Task#6003360
Polish VAT EU reporting is now part of the main Polish reports module instead of being maintained as a separate add-on. This simplifies installation and maintenance while keeping the reporting behavior available in one place.
Original PR description
Description of the issue this commit addresses: Recently, the l10n_pl_reports_vat_eu has been added to stable versions for a new behavior. In master, that module can be merged into l10n_pl_reports. --- Desired behavior after this commit is merged: This commit merges the two modules together into l10n_pl_reports. --- task-6368808 upgrade pr: https://github.com/odoo/upgrade/pull/11183
The Sign app now follows the updated Frost visual design used across Odoo, with consistent colors, borders, and dark mode behavior. This makes signing workflows look more polished and aligned with the rest of the backend, including template cards, sidebars, document lists, and PDF viewing.
Original PR description
The webclient redesign (odoo/odoo#282516, odoo/enterprise#127955) did not cover Sign, which kept painting its own colors and borders. The app drifted away from the rest of the backend, as whites and grays that stayed light in dark mode, a stray line across the middle of the Documents list, template cards showing only half of their border, hard divider lines in the editor sidebar, and a PDF viewer still using the previous dark palette. Sign now reuses what the other apps already do. Colors come from the palette instead of being written by hand, so light and dark stay consistent on their own and nearly all the dark-mode overrides could go. task-6518558
Customer portal pages now show dates, times, and work durations in easier-to-read formats. This improves consistency across helpdesk, project, and timesheet-related pages and makes time information quicker for customers to understand.
Original PR description
*_ = helpdesk{,_sale_timesheet}, sale_timesheet_enterprise
- Replaced float_time with the duration widget using the narrow format to display durations in a more human-readable way (e.g. 1h 20m).
- Updated datetime widget formatting across the affected portal views to use the required medium date and medium date + short time formats for consistent date/time presentation.
task-6197942The Belgian payroll module description was updated to direct users to the official documentation. This helps customers and support teams find the right guidance more easily without changing payroll functionality.
Original PR description
Change the module description to refer to the official documentation. Task-6485101
Belgian payroll now uses clearer establishment unit terminology and validates that employee contracts and payslips align with the correct establishment unit location dates. It also reduces manual entry by auto-filling competences when possible and adds easier access to employees linked to an establishment unit.
Original PR description
1. Renamed DMFA work locations into Establishment unit 2. Added checks to make sure employees don't start their contract before the location period of an establishment unit 3. Added a warning on Payroll, blocking payslips if the establishment unit location date isn't correct 4. Added automatic completion for competences: when selecting a working address, the competence is filled automatically. 5. Added a smart button 'Employee' on Establishment unit. 6. Added address_id as required field. 7. Prevent autofill on l10n_be_hr_payroll when there are multiple establishment units for the same company. __ task-6432041
Odoo's web interface framework was updated to a newer version, improving how background component setup is completed when parts of the page are removed. This helps prevent editor callbacks from running for content that is no longer present, making embedded content handling more reliable.
Original PR description
Release notes: https://github.com/odoo/owl/releases/tag/v3.0.0-alpha.48 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285995
Updates the Sri Lanka accounting configuration with a more complete chart of accounts, clearer reporting tags, and depreciation models for fixed assets. This helps companies align with LKFRS for SMEs and keeps financial reports reliable even when account numbers are changed.
Original PR description
The chart of accounts was missing several accounts required by LKFRS for SMEs, and the financial reports classified accounts by code prefix, which breaks as soon as a customer renumbers or adds an account. Renumber and extend the chart of accounts, add the account tags used to identify finance costs, income tax expense and other comprehensive income, and add depreciation models for the fixed asset accounts. task-6497298 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian profit sharing payroll runs now better exclude ineligible employees, including those with short service, specific categories, serious misconduct dismissals, or resignations. Payroll teams also get blocking dashboard warnings for key eligibility issues, and withholding tax is skipped when the employee is marked as exempt.
Original PR description
In this commit, we introduced few improvements for the profit sharing feature. - Profit sharing payruns are excluding CP999, employees with less than 1 year of service, employees that have been fired for serious misconduct, and resigned employees. - 2 blocking payslips warnings (on dashboard) for wrong ONSS employer category and employees with less than 1 year of service. - No withholding tax for profit sharing bonus (low and high) if the employee no_withholding_taxe field is set to true. task-6481237
Belgian HR payroll now includes a dedicated family-section field to record dependents who need specific care. This helps HR teams enter the information needed for professional withholding tax calculations more accurately and reduces manual payroll adjustments.
Original PR description
This commit will add a new field to the employee form to track the number of dependents requiring specific care within the family context. ### Why: For Belgian payroll and tax calculations, the number of dependents who are needing care significantly impacts the calculation of professional withholding tax. Previously, there was no dedicated field in the family section to capture this specific count, requiring manual adjustments during payroll processing. ### What: - Added a new integer field `other_need_care_senior_dependent` to the hr.version model. - Extended the employee form view to include this field under the 'Family' section, specifically within the Belgian localization context. task-6133227
Sri Lanka balance sheet and profit and loss reports now classify accounts using account types and localization tags instead of fixed account code prefixes. This makes the reports more flexible, improves LKFRS for SMEs coverage, and separates other comprehensive income and translation adjustments for clearer reporting.
Original PR description
The balance sheet and profit and loss relied on account code prefixes, which made them inflexible and left several LKFRS for SMEs captions unmapped. Rewrite both reports on the domain engine, classifying accounts by account type and by the tags added in l10n_lk, and report other comprehensive income and cumulative translation adjustments separately. task-6497298
Introduces light user access so employees can use Barcode and Shop Floor workflows without needing broader system access. This helps businesses give operational staff the right permissions to complete inventory and manufacturing tasks while limiting access to other areas.
Original PR description
Light users are only allowed to access shopfloor/Barcode apps, while still being able to perform all actions through them. Task: 6469225
Light users can now perform the same stock and manufacturing actions as regular users, while only seeing direct access to the Shop Floor and Barcode apps. This simplifies access management for operational staff who need warehouse or production capabilities without a full app menu.
Original PR description
Light users can do every action normal users can do, the difference is that they only have direct access 2 apps; shopfloor and barcode. Which means Regular user is now implied by light user. Task: 6469225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Frontdesk visitor records now assign a single host instead of allowing multiple hosts. This simplifies check-in ownership and related SMS notifications, making host responsibilities clearer for reception teams.
Original PR description
This commit changes the `host_ids` field on `frontdesk.visitor` from a many2many field to a many2one field `host_id`.
Refunds for point of sale orders with scheduled deliveries now handle stock operations based on whether the original delivery was completed. This avoids unnecessary negative stock movements and keeps inventory records aligned with the actual delivery status.
Original PR description
Before this commit: - Refund orders of scheduled (with shipping date) orders always generated a new picking with negative quantities, even when the original delivery had not been completed. - This…
Before this commit:
- Refund orders of scheduled (with shipping date) orders always generated a new picking with negative quantities, even when the original delivery had not been completed.
- This could lead to incorrect stock movements and negative quantity computations for undelivered pickings.
After this commit:
- When processing a refund of a scheduled (with shipping date) order, the behavior now depends on the state of the original picking:
- If the picking has already been delivered, a return picking is created with the corresponding negative quantities.
- If the picking has not been delivered, the original picking is updated instead:
- The picking is cancelled for a full refund.
- Refunded product moves are removed from the picking for a partial refund.
- This prevents unnecessary negative stock movements and ensures stock operations remain consistent with the delivery status.
Task-5902424
Forward-Port-Of: odoo/odoo#282576
Forward-Port-Of: odoo/odoo#271506The chat menu now hides general client notifications, such as failures or push notification prompts, when users apply a chat filter like unread conversations. This keeps filtered views focused on the chats users asked to see and reduces unnecessary distractions.
Original PR description
The chat tab shows notifications such as failures or push notification requests. It doesn't make sense to show those when filtering the view (e.g. to unread chats). This commit ensures those are only shown when the "all" filter is active. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attendance managers can now open and manage attendance records without being blocked by overtime rule access errors. The change keeps sensitive HR rule details read-only for non-HR users while allowing attendance workflows to continue smoothly.
Original PR description
Issue ===== The overtime rules searches the model `hr.version` for versions' data. However, an attendance manager does not have access to `hr.version`, hence an access error is raised. Fix ===== - Use `sudo()` on read and search operations on `hr.version`. - Use a dispatcher server action to trigger the ruleset action with the appropriate context to make ruleset data `readonly` for non-HR users. Also see related [PR](https://github.com/odoo/odoo/pull/275676) TaskID-6128198
The configuration views for India EDI and e-way bill settings now point to the correct parent view. This prevents upgrade failures caused by the system looking for settings fields in the wrong place.
Original PR description
The view inherits from the root view `account.res_config_settings_view_form` but modifies the node `name='module_l10n_in_ewaybill'` introduced by a sibling view `l10n_in.res_config_settings_view_form_inherit_l10n_in`. This leads to errors during upgrades: ``` odoo.exceptions.ValidationError: Error while parsing or validating view: Element '<xpath expr="//field[@name='module_l10n_in_ewaybill']">' cannot be located in parent view ``` Note: The inheritance was also wrong in previous versions. Since the error doesn't happen there, the PR targets master directly but can be backported if needed
Odoo now reads database timeout settings in a way that does not require extra database catalog permissions. This prevents avoidable permission errors in restricted hosting environments and helps attachment-related operations continue reliably.
Original PR description
pg_settings requires explicit `SELECT` privileges and may raise an `InsufficientPrivilege` error in restricted environments. Use `current_setting()` instead to read configuration values directly from the backend without requiring catalog privileges.
This update corrects mismatched internal references in the HTML editor so existing features keep working as expected. It restores behaviors such as signature handling, image updates after undo or redo, and table cell selection updates, reducing small editing glitches for users.
Original PR description
Description of the issue this PR addresses: Several plugin declarations had drifted from the code they describe. This PR fixes such issues, see the individual commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes uneven vertical spacing between form field boxes on small screens. Forms will look more consistent and polished for users working from mobile or narrow displays.
Original PR description
The vertical spacing between the outlined field boxes on small screens was defined case by case: `map-get($spacers, 3)` on the property field values and on the outlined headings, while the regular cells relied only on the negative margin of their overlapping label. As a result the gap differed depending on the kind of field. Move the margin to `%-o-field-box` itself, driven by a single `--o-field-box-spacing` variable, so every box (cells, outlined fields and property values) uses the same spacing, and drop the now redundant per-case margins. task-6533314 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update keeps media and action icons consistent in right-to-left languages, avoiding confusing mirrored symbols. It also improves disabled button styling so colors remain correct when some theme values are not explicitly set.
Original PR description
### Prevent the play icon from flipping in RTL Prior to this PR, the play icon was being flipped in RTL, which caused confusion. This PR ensures that the icon is displayed consistently in both RTL…
### Prevent the play icon from flipping in RTL Prior to this PR, the play icon was being flipped in RTL, which caused confusion. This PR ensures that the icon is displayed consistently in both RTL and LTR layouts. ### Make disabled button values optional Prior to this PR, disabled values were mandatory when overriding button variables. This could cause color issues when those variables were not explicitly defined. This PR makes the disabled values optional and falls back to the default values when they are not defined. task-6501706 Requires: - https://github.com/odoo/enterprise/pull/129377 --- | Before | After | |--------|--------| | <img width="187" height="122" alt="Screenshot 2026-08-26 at 15 49 05" src="https://github.com/user-attachments/assets/006830b7-4bd1-43f0-8fc0-f35e9ec66fe5" /> | <img width="212" height="148" alt="image" src="https://github.com/user-attachments/assets/a2c59ec2-e1ce-4a3f-bdc5-37a9fe628126" /> | | <img width="798" height="310" alt="image" src="https://github.com/user-attachments/assets/f0440f18-f1fa-4b46-b43a-e13d816beb26" /> | <img width="806" height="270" alt="image" src="https://github.com/user-attachments/assets/fdcb1364-353f-416c-a297-fb1bcdd316ce" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attendance records now correctly show check-in location details when device and location tracking are enabled. This fixes a display issue in kiosk-mode attendance records so managers can review location information as expected.
Original PR description
Steps: - Enable device & location tracking setting - Create a check in for an attendance in kiosk mode - Open the attendance form - Check in location is not visible Cause: Due to a recent addition of custom CRUD methods to modify access rights for hr_attendance, the attendance view form was inherited and location tracking fields have been hidden from all views indiscriminately because of matching priorities between the new and inherited views Solution: Define priority for the main view in order to take precedence over the new view while maintaining the new view for CRUD methods. Task: 6526280 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian payroll rules were updated so the 3000 deduction is calculated correctly for the second and third quarters of 2026. This helps employers produce accurate payroll and social security reporting for the affected periods.
Original PR description
Forward-Port-Of: odoo/enterprise#126091 Forward-Port-Of: odoo/enterprise#124034
The return creation wizard now checks for existing returns only within the selected company. This prevents users working with multiple companies from being incorrectly blocked by returns that belong to another company.
Original PR description
To reproduce the issue: 1) Create two companies in Belgium: A and B 2) Manually create a return for A before its opening date 3) Switch to company B, and keep A active as well 4) Try creating a return of the same type and at the same date as in 2) ===> The wizard blocks you and displays a warning saying there's already a return at this date. There is, but for another company. We fix that by properly filtering the company when searching for existing returns. Moving the _read_group inside the loop on self is okay here: we'll never compute that field for multiple wizards at once. Forward-Port-Of: odoo/enterprise#130303
The merge details dialog now shows darker badges next to source records, making them easier to read. This improves clarity when users review records before merging and helps reduce mistakes caused by hard-to-see labels.
Original PR description
The badges next to the source record in the merge details dialog were too light to read against the background. Make them darker. task-6512026
Fixed an issue in Odoo Sign where a signer's avatar could disappear after assigning a contact in a template. This keeps the signer sidebar visually clear and helps users confirm they selected the right person.
Original PR description
Version:
- saas-19.5
Steps to reproduce:
- Open a Sign Template and add/select a signer role in the sidebar.
- Add value to `assign_to` field from signer setting dialog.
Issue:
- the avatar next to the signer's name in the sidebar does not render properly.
Cause:
- res.partner's `avatar_128/avatar_1920` are Binary fields. The ORM now returns Binary fields from read() as an object `{ filename, content, size }` instead of a plain base64 string. `updateRoleNameAndAvatar() `still treats the result as a raw base64 string `(partner.avatar_128 || partner.avatar_1920)` and passes it straight into `getImageSrc()`. which expects a base64 string to build the image URL. Since it now gets an object instead, the URL becomes invalid and the image fails to load.
Solution:
- Extract the base64 string from the `content` key of the returned binary value.
task-6529799This fix ensures Sign documents display at the correct size when users switch between multiple documents. It also prevents editing popovers from remaining visible after leaving the template editor, reducing confusion when navigating to another screen.
Original PR description
When there are several documents to be viewed, all viewers are loaded at the same time, but only the current one is visible. Because the other viewers are hidden, their automatic zoom is calculated incorrectly and is never recalculated. As a result, when switching documents, the page has the wrong size. In the template editor, the popover for a sign item belongs to the popover service, not to the document. Because of this, when leaving the page, for example using the breadcrumb, the popover stays open and appears on the next view. task-6530400
The biometric attendance setup screens now make Mantra and eSSL URLs copy-only, preventing users from accidentally opening links that lead to an error page. Related wording and event organization were also clarified, making attendance integration setup and review smoother.
Original PR description
Before this commit, the Mantra and eSSL URLs were clickable, allowing users to copy the links. However, clicking the URL would open it in a new tab, resulting in a Method Not Allowed error. Since these URLs are intended only for copying they should not be opened. In this PR - Updated the URL widget so users can only copy the link and cannot open it. - Updated the related messages for better clarity. Task:6526289
The tax return deadline date label now has stronger contrast, making the due date easier to read in the tax return interface. This helps users quickly identify deadlines and reduces the chance of overlooking important tax dates.
Original PR description
Before this commit: - With the new tax return UI, the tax return deadline date pill has low contrast between the pill's background color & text color, and it became hard to see the actual date shown…
Before this commit: - With the new tax return UI, the tax return deadline date pill has low contrast between the pill's background color & text color, and it became hard to see the actual date shown in the pill. - Behaviour before: <img width="385" height="70" alt="image" src="https://github.com/user-attachments/assets/382d2961-0bd9-4552-a7dd-175b6cfa49e7" /> <img width="344" height="73" alt="image" src="https://github.com/user-attachments/assets/6301929b-0cec-4411-b8e1-4a4a65bc9f9e" /> --- After this commit: - Changed the Bootstrap class for the deadline date pill for the secondary case. Now we are explicitly defining the text color for enhanced contrast with the background color. - Behaviour after: <img width="308" height="73" alt="image" src="https://github.com/user-attachments/assets/50499178-8bba-4917-abd5-026ea287df3e" /> <img width="302" height="74" alt="image" src="https://github.com/user-attachments/assets/59537317-2b7c-4ab5-8828-56f8197ff16f" /> --- Task-6523848
Updates several interface details so attachment previews, switcher controls, barcode kanban tips, and disabled buttons better match the new Frost design. This improves visual consistency and reduces confusing color or spacing issues for users.
Original PR description
*: account_accountant, stock_barcode ### Adapt attachment preview This PR adapts the border of the attachment preview to match the new Frost design. ### Adapt o_switcher colors This PR adapts the…
*: account_accountant, stock_barcode ### Adapt attachment preview This PR adapts the border of the attachment preview to match the new Frost design. ### Adapt o_switcher colors This PR adapts the o_switcher component to: - Ensure consistent border colors - Adjust the color of disabled buttons ### Adapt `o_kanban_tip_filter` This PR reviews the spacing and button styles of `o_kanban_tip_filter` to align with the new Frost design. task-6501706 Requires: - https://github.com/odoo/odoo/pull/284724 --- | Before | After | |--------|--------| | <img width="1920" height="929" alt="image" src="https://github.com/user-attachments/assets/b424769f-77f3-4a2f-a0fe-f78bf757ab33" /> | <img width="1919" height="816" alt="image" src="https://github.com/user-attachments/assets/60e5776a-a846-4fb7-b0f3-b83b7ec00cfd" /> | | <img width="508" height="426" alt="image" src="https://github.com/user-attachments/assets/b53c88c2-5f03-4895-9842-86372396a8e3" /> | <img width="578" height="208" alt="image" src="https://github.com/user-attachments/assets/129fd800-8e99-4355-b283-6f0cad07b574" /> | | <img width="1920" height="1094" alt="image" src="https://github.com/user-attachments/assets/e01b401b-dc1c-4569-920c-03e182776aca" /> | <img width="1920" height="474" alt="image" src="https://github.com/user-attachments/assets/83b0f76c-b0bd-478b-9f55-6019eb8f5acf" /> |
This fix restores an internal connection used by the Mexican e-invoicing website checkout flow. It helps keep the online sales checkout and invoicing process working as expected after a previous change accidentally removed that support.
Original PR description
Lost with 25699301ccde8f4e9ac6333438a7b1d40f9237ab
This fixes a problem that could cause Knowledge pages with foldable sections to crash after a recent technical update. Users can now open and view these embedded sections reliably again.
Original PR description
In this [owl3 adaptation], `ReadonlyFoldableSection` `static props` were replaced using `useProps`, but the `FoldableSection` child class was still using the `static props` form, rendered ineffective. This meant that OWL was not passing the `host` props to `FoldableSection` embedded components, resulting in a crash. [owl3 adaptation]: https://github.com/odoo/enterprise/commit/a8def7a3de4949474741d5c9935c39f3d6cb84cf task-6533835
This update prevents a crash in the Odoo Studio home menu after an underlying web interface change. It keeps Studio users from hitting an error when opening the home menu, with no expected change to normal behavior.
Original PR description
See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a test setup so forum access rules are checked against the right forum configuration. It helps ensure users need the proper reputation level before commenting on posts or replies created by someone else.
Original PR description
**Issue:**
`website_helpdesk_forum` overrides the `ref('website_forum.forum_help')` in its demo data, allowing anyone to comment / post on it.
**Fix:**
Use the helper forum instead and properly requires `KARMA['com_all']` when posting a comment on someone else post/reply.
related: https://github.com/odoo/odoo/commit/ba19ef413e400a65e9f43a6fc6c4bc1586ea8983
runbot-944703
Forward-Port-Of: odoo/odoo#285699
Forward-Port-Of: odoo/odoo#281757This fixes the DIN5008 invoice layout when German invoices are sent by post, ensuring the sender, invoice information, and recipient address appear in the correct positions. Regular DIN5008 invoice layouts are unchanged, while mailed documents now align properly for postal processing.
Original PR description
**Steps to reproduce:** - Install l10n_din5008 and Accounting. - Enable Snailmail from Accounting → Settings. - Create a German customer (Fiscal Country: Germany). - Create and post a customer…
**Steps to reproduce:** - Install l10n_din5008 and Accounting. - Enable Snailmail from Accounting → Settings. - Create a German customer (Fiscal Country: Germany). - Create and post a customer invoice using the DIN5008 report layout. - Select Send by Post. - Enable Developer Mode and navigate to Settings → Technical → Email → Snailmail Letters. - Open the generated letter and send it. **Observed behavior:** The address blocks are incorrectly aligned when the DIN5008 report is rendered for snailmail. The information block and recipient address do not follow the expected vertical positioning. **Cause:** The DIN5008 layout previously applied vertical alignment rules to its table cells. These rules were removed while adapting the layout to the invoice table structure and its customizations, such as the position column and line numbering. While this alignment is no longer required for the regular DIN5008 invoice layout, the snailmail layout relies on it to correctly position the sender/invoice information and recipient address blocks. **Fix:** Add a `snailmail` class to the DIN5008 invoice section when `snailmail_layout` is present in the rendering context. Restore the required vertical alignment rules scoped to this class so they only affect snailmail reports, without changing the regular DIN5008 layout. **References** * **PR:** [#201225 – DIN5008 layout improvements](https://github.com/odoo/odoo/pull/201225) * **Ticket:** [6387869](https://www.odoo.com/odoo/project/49/tasks/6387869) opw-6387869 Forward-Port-Of: odoo/odoo#286056 Forward-Port-Of: odoo/odoo#285891
Unbuild orders for serial- or lot-tracked manufactured products now honor the specific lot or serial number selected by the user. This prevents the system from accidentally unbuilding the oldest available item instead, improving inventory accuracy and trust in manufacturing operations.
Original PR description
Steps to Reproduce: - Create a Serial Number tracked product. - Create a Manufacturing Order (MO) for quantity 5. - Create and assign serial numbers: SN1, SN2, SN3, SN4, SN5. - Mark the MO as Done. - Create an Unbuild Order for quantity 1. - Select SN4 in the lot/serial field. - Mark the Unbuild Order as Done. - Check Product Moves, SN1 gets unbuilt Issue: When creating an Unbuild Order for a tracked product and explicitly selecting a specific serial/lot number to unbuild, the system ignores the user's choice. Instead, it falls back to the default FIFO strategy and automatically unbuilds the oldest available serial/lot number from the source location. Task-6326772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283651 Forward-Port-Of: odoo/odoo#272525
Manufacturing orders for serial-tracked products using make-to-order purchased components no longer show an incorrect consumption warning when quantities are actually correct. This prevents unnecessary user confusion and allows the production flow to complete without misleading alerts.
Original PR description
Steps to reproduce the bug: - Warehouse configured for 2-Step Manufacturing - Component "C1": - Routes: MTO + Buy - Tracking: By Unique Serial Number - Create a Finished product: - Route: Manufacture…
Steps to reproduce the bug:
- Warehouse configured for 2-Step Manufacturing
- Component "C1":
- Routes: MTO + Buy
- Tracking: By Unique Serial Number
- Create a Finished product:
- Route: Manufacture
- Tracking: By Unique Serial Number
- BoM:
- component "C1": 1 unit
- Create and confirm the Manufacturing Order
- Generate/assign the serial number for the finished product immediately, before the related purchase order is even confirmed
- Confirm the Purchase Order
- Receive the component
- Transfer the component to WH/Pre-Production
- Click Produce All
Problem:
A Consumption Warning was displayed stating that the consumed quantity differs from the expected quantity, even though the consumed quantity was exactly equal to the BoM quantity and no manual quantity change was performed. Clicking "Set Quantities & Validate" completed the MO successfully, hiding the inconsistency.
`_get_consumption_issues()` only counts a raw move's quantity as "consumed" when `move.picked` is `True`
[(odoo/addons/mrp/models/mrp_production.py#L1791)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1791).
Generating the finished product's serial number calls `_set_qty_producing()`
[(odoo/addons/mrp/models/mrp_production.py#L1402)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1402).
, which itself only sets `move.picked = True` when `move.quantity` is truthy
[(odoo/addons/mrp/models/mrp_production.py#L1443)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1443).
At that point the MTO component had not been received yet, so `move.quantity` was still 0 and `picked` was never set. Once the component was later received and transferred to Pre-Production, `_action_assign()` correctly reserved the raw move (`quantity` became correct), but nothing ever went back to flip `picked` to `True`, since `_set_quantities()`
[(odoo/addons/mrp/models/mrp_production.py#L2932)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2932).
only calls `_set_qty_producing()` again when `qty_producing` is still falsy, which was no longer the case. `_get_consumption_issues()` therefore still counted the consumed quantity as 0 against the expected BoM quantity.
Solution:
In `pre_button_mark_done()`, for auto productions (single unit being produced), after `_set_quantities()` runs, also mark as `picked` any non-manual-consumption raw move that is not yet `picked` but whose reserved `quantity` already exactly matches its own `product_uom_qty`. This is scoped to auto productions only, since on a multi-unit production a raw move's aggregate `quantity` can equal its `product_uom_qty` by coincidence (reservation for future backorder steps) even though only part of it is meant to be consumed for the current step.
opw-6421531
Forward-Port-Of: odoo/odoo#285405
Forward-Port-Of: odoo/odoo#281258Italian POS refunds now take users to the payment page for the new refund order, not the original order or product screen. This prevents cashier confusion and helps complete refund transactions correctly when using an Italian fiscal printer.
Original PR description
**Issue**: 1. From versions 18.4 to 19.1 inclusive, the system redirects to the product screen; 2. From version 19.2 onward, the redirection targets the payment page of the original order instead of the refund order. **Expected behavior**: The system navigates to the payment page for the refund order. **Steps to reproduce**: - Set up an Italian fiscal printer; - Open a POS session and process an order; - Create a refund for the order. [Ticket link](https://www.odoo.com/odoo/project/49/tasks/6499079) opw-6499079 Forward-Port-Of: odoo/enterprise#130044 Forward-Port-Of: odoo/enterprise#129758
This fix prevents the Polish bank verification module from recalculating all existing payments during installation. It helps large databases install or update the module reliably without running into crashes caused by too much processing at once.
Original PR description
account.payment model computes every record l10n_pl_verification_id at module installation (l10n_pl_bank_verification), causing crash in case of db with a large number of records wrong method name correction: _auto_init instead of init and call super after creating the db column see odoo/odoo#282504 Forward-Port-Of: odoo/odoo#285968
The Irregular Sequence screen in Accounting now opens in the list view as intended, instead of the kanban view introduced by mistake. This restores the expected workflow for users reviewing sequence issues and avoids confusion from an unintended layout change.
Original PR description
In this PR https://github.com/odoo/odoo/pull/243458 the Irregular Sequence default view was mistakenly changed from list to kanban. This commit reverts this, and makes the default view list again. task-6531731
This fix ensures that low-credit IAP errors are kept separate from general user-facing errors. It helps Odoo correctly identify when an action failed because more IAP credits are needed, instead of treating it like a generic request problem.
Original PR description
Even if `raise_user_error` is enabled, these errors should remain so that the caller can distinguish between a request error and a lack of IAP credits. Forward-Port-Of: odoo/odoo#286288
The payslip correction wizard now shows the expected explanation when users correct a paid payslip. This helps payroll users understand whether they are correcting the payslip or only reverting it, reducing confusion during payroll adjustments.
Original PR description
Steps to reproduce:
1. Open a draft payslip and validate it.
2. Mark the payslip as paid.
3. Click on the "Correct" button to open the correction wizard. The description text "Do you want to correct this payslip or revert only?" is missing.
Reason:
The view evaluated `context.get('is_button_action')` instead of the field `is_button_action`. Since the action context passes `default_is_button_action`, `context.get('is_button_action')` evaluated to False.
Solution:
Remove `context.get()` calls from the XML view and rely on the `is_button_action` Boolean field instead.
Task-6511586The website builder no longer shows theme-based background options for tab sections because those choices did not work reliably. This prevents users from selecting a styling option that would not apply as expected, making page editing clearer.
Original PR description
The theme background options (`o_cc` classes) on the `s_tabs` snippet's tabs doesn't work since 18.4 (html_builder refactor). It was not supported either in previous versions. We decided to fix it so it would be useable in master (20.0) but leave stable versions as is, by restraining the available tabs and removing the theme one. task-5951656 Forward-Port-Of: odoo/odoo#277528
Long delivery method names now display cleanly during eCommerce checkout instead of stretching the page layout. This helps shoppers review shipping options without visual breakage or horizontal overflow.
Original PR description
Issue ----------- Long delivery method names containing lists of locations/zones do not wrap properly on the eCommerce checkout page, causing the layout to overflow. Cause of the issue -----------…
Issue ----------- Long delivery method names containing lists of locations/zones do not wrap properly on the eCommerce checkout page, causing the layout to overflow. Cause of the issue ----------- The first column of `[.o_delivery_method_row](https://github.com/odoo/odoo/blob/saas-19.3/addons/website_sale/static/src/scss/website_sale_delivery.scss#L2)` uses `minmax(max-content, 1fr)`. `max-content` prevents the column from shrinking when the delivery method name is too long. Steps to reproduce ----------- 1. Create a Delivery Method with a long list of locations/zones in its name. 2. Go to the eCommerce checkout at the address page. 3. Observe that the delivery method name does not wrap and breaks the layout. Before Fix ----------- The `max-content` minimum prevents the delivery method name from wrapping, causing the layout to overflow. <img width="1781" height="852" alt="image" src="https://github.com/user-attachments/assets/1150a8ef-e2d8-49ab-9553-fe9728258060" /> After Fix ----------- Change `max-content` to `min-content` so the column can shrink and the delivery method name wraps. <img width="1882" height="890" alt="image" src="https://github.com/user-attachments/assets/84cfd5a4-796d-4b9f-bfdb-c18434f8b67f" /> [OPW- 6486780 ](https://www.odoo.com/odoo/project/70/tasks/6486780) [UPG- 4609267 ](https://upgrade.odoo.com/odoo/upgrade.request/4609267) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284714
The Romanian tax return list now shows the specific declaration name "D300" instead of the generic label "Tax". This makes it easier for users to identify and select the correct Romanian tax declaration when generating returns.
Original PR description
Before this commit: When generating a Romanian tax return, one of the return types in the list was labeled "Tax", which was too generic to know which specific tax declaration it referred to. After this commit: The tax return is now renamed to "D300", making it easy to identify this return in the list instead of seeing a generic "Tax" label. task - 6388087 Forward-Port-Of: odoo/enterprise#124583
The expense workflow now uses the correct status name, "approved," in the HR Expenses screens. This avoids confusion for employees and managers reviewing expense reports and keeps the interface aligned with the actual process.
Original PR description
Use the correct state name (approved) @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285950
This update fixes typos and inconsistent wording in the Point of Sale LNA checklist. It improves clarity for users reviewing the checklist without changing any business process or system behavior.
Original PR description
Fixed some typos and inconsistencies on the LNA checklist document Task-[6330795](https://www.odoo.com/odoo/project/1737/tasks/6330795) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286174 Forward-Port-Of: odoo/odoo#281950
UPS shipments could be rejected when a customer's invoicing address did not have its own name. The delivery integration now falls back to a suitable partner name, helping affected shipments proceed without requiring manual address cleanup.
Original PR description
Issue ----- By default, invoicing addresses of existing partners are created without a name. This leads to the deliveries being rejected by UPS. Steps to reproduce ----- - Set Up UPS - Create a Customer - Create an invoicing address with no name - Create a SO for the partner & confirm - UPS delivery - Open the picking and confirm it > UPS rejects the shipment /!\ I could not reproduce in testing environment, so this is based off user steps in their production DB. /!\ Cause ----- The partner being used in `_set_invoice` was changed in #119747 but this use case was missed due to the error not occuring in test mode. ----- Ticket: opw-6485164 Forward-Port-Of: odoo/enterprise#128933
Payroll search filters have been updated after a recent change to how payslip-related names are stored. This restores reliable searching for payroll lines and worked days, while removing a payslip-name filter that no longer worked correctly.
Original PR description
We recently did a refactor of how names are handled for payslips, lines, and worked days (See #128134). They are now non-stored fields, and some filters still use those fields, effectively breaking the search. For the payslip name, we decided not to replace the filter with a complex domain and simply delete it. For the line / worked days name, we now use a domain on the salary rule / work entry type and the custom name, the same way it is computed. Task-6511349
The Helpdesk unread ticket filter now correctly treats tickets as unread when the latest update is an automatic system message, such as one from OdooBot. This helps support teams avoid missing customer tickets created through the website that still need attention.
Original PR description
**Steps to reproduce:** - Install website_helpdesk. - Create a team and enable website form. - Create a ticket through the website. - Apply the Unread filter. **Issue:** system generated message, such as message authored by OdooBot, were not considered when determining whether a ticket was unanswered. **Cause:** the search method only considered the last message when its author matched the ticket's partner. **Fix:** Consider a ticket unanswered when the last message's author matches the ticket's partner, or when the last message is an automatic system generated message. task-5138678 Forward-Port-Of: odoo/enterprise#130100
The website editor’s block search field now shows a pointer cursor when users hover over the clear button in browsers that display it. This small visual cue makes it clearer that the button can be clicked to reset the search.
Original PR description
Steps to reproduce: - Open the website editor. - Open the "Insert a block" dialog. - Enter text in the search bar. - Hover over the clear icon. => The cursor does not indicate that the icon is clickable. Before this commit, the search clear icon kept the default cursor. After this commit, the clear icon uses a pointer cursor to indicate that it is clickable. Note that Firefox does not natively add this clear icon to search inputs, unlike Chrome. This fix only affects browsers that render it. task-6259086 Forward-Port-Of: odoo/odoo#283435
This fix prevents invalid e-invoicing response records from being created when the French PDP service does not return a tracking identifier. It avoids scheduled status update failures, helping invoice and vendor bill e-invoicing processing continue reliably.
Original PR description
Steps to reproduce: - Install `l10n_fr_pdp` and `l10n_be` module - Activate `French e-invoicing` (you need to put your DB in test mode) (i.e: `account_peppol.edi.mode = 'test'` in system parameter)…
Steps to reproduce:
- Install `l10n_fr_pdp` and `l10n_be` module
- Activate `French e-invoicing` (you need to put your DB in test mode)
(i.e: `account_peppol.edi.mode = 'test'` in system parameter) Refer this Documentation https://www.odoo.com/documentation/19.0/applications/finance/fiscal_localizations/france.html?highlight=e%20invoicing#localizations-france-e-invoicing-fac-elec-config
- Create a Invoice and Sent with `E-invoicing`
- Run `PEPPOL: retrieve new documents` Cron
- In Invoice Other Info > `E-Invoicing Status` should be in `Done` state
- Now Vendor Bill is created for that invoice > Cancel that bill with reason > Check `E-Invoicing Status` response for bill(one response will be without UUID)
- Go to schedule actions > `PEPPOL: update message status`
- Run it and get the traceback: `KeyError: 'false'`
Issue:
When sending a lifecycle response to the French PDP, `_pdp_send_response` calls the `/api/pdp/1/send_response` endpoint and expects IAP to return a `message_uuid` for each response.
However, IAP return a response without a message UUID, for example: ` {'messages': [{'message_uuid': False}]}` `_pdp_send_response` currently assumes that every returned message has a valid UUID and creates an `account.peppol.response` with:
```
'peppol_message_uuid': False
'peppol_state': 'processing'
```
This leaves an `account.peppol.response` in `processing` state without a UUID that can be used to track it.
During the next execution of `_cron_peppol_get_message_status`, `_peppol_get_message_status` retrieves this response through `_peppol_get_documents_for_status` and builds `uuid_to_record` using `peppol_message_uuid` as the key. The resulting mapping contains the Python value `False` as a key.
The cron then calls the PDP `1/get_document` endpoint with this invalid UUID. IAP returns it as the string `'false'`, which is passed to `_peppol_process_messages_status`. The French PDP implementation tries to retrieve the corresponding record with: `uuid_to_record[uid]`
Since the mapping contains `False` while `uid` is `'false'`, this raises: `KeyError: 'false'`
This failure prevents the status cron from completing the processing of the messages.
Solution:
Avoid creating the `account.peppol.response` when IAP does not return a `message_uuid`. A response without a UUID cannot be tracked through the PDP status flow, so creating it in `processing` state only leaves an
invalid record that will later cause the status processing to fail.
opw-6453133
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#286147
Forward-Port-Of: odoo/odoo#281691This fixes a problem that could stop the scheduled retrieval of Turkish Nilvera e-Dispatch purchase PDFs. Businesses using this localization can now retrieve these documents reliably without the process failing due to an attachment lookup error.
Original PR description
## Steps to Reproduce: - Install `l10n_tr_nilvera_edispatch` module. - Run "**Nilvera: retrieve e-Dispatch purchase PDFs**" Scheduled Action. ## Error: ``` ValueError: Binary field stored in…
## Steps to Reproduce:
- Install `l10n_tr_nilvera_edispatch` module.
- Run "**Nilvera: retrieve e-Dispatch purchase PDFs**" Scheduled Action.
## Error:
```
ValueError: Binary field stored in attachment, accepts only existence check; skipping domain in condition ('l10n_tr_nilvera_edispatch_xml_file', 'in', OrderedSet([True]))
```
## Cause:
After commit https://github.com/odoo/odoo/commit/3641f23a9b4cd401444ca3371873d8123922f7b1, The condition operators `=` and `!=` are normalized to `in` and `not in` respectively.
As a result:
```
('field', '=', True) becomes ('field', 'in', OrderedSet([True])) and
('field', '=', False) becomes ('field', 'in', OrderedSet([False]))
```
After this normalization, the domain optimizer `_optimize_type_binary_attachment()` is applied - [1].
For attachment-type binary fields, it only allows `in/not in` operators, and a value should be `{False}`.
Therefore, the condition (converted) `('l10n_tr_nilvera_edispatch_xml_file', 'in', [True])` is rejected.
Binary fields with `attachment=True` are not stored as a boolean value. When converting their domain to SQL, `condition_to_sql()` - [2] handles them as an EXISTS check on `ir.attachment` to determine whether an attachment exists.
## Fix:
This commit replaces the `= True` in the condition with `!= False`.
[1] - https://github.com/odoo/odoo/blob/762fd7c0b65e8f8e3eb59eb8a57b1394cb176339/odoo/orm/domains.py#L1782-L1784
[2] - https://github.com/odoo/odoo/blob/762fd7c0b65e8f8e3eb59eb8a57b1394cb176339/odoo/orm/fields_binary.py#L217-L218
sentry-7627832395
Forward-Port-Of: odoo/odoo#284401When a user pastes a new URL over an existing link whose text matches its address, the editor now updates both the link destination and visible text. This prevents confusing cases where a link points to the new address but still displays the old one.
Original PR description
**Current behavior before PR:** Steps to reproduce the issue: - Create a link via typing a valid URL + space. - Copy/Paste a different URL from the browser. - Select the entire link you just created.…
**Current behavior before PR:** Steps to reproduce the issue: - Create a link via typing a valid URL + space. - Copy/Paste a different URL from the browser. - Select the entire link you just created. - Paste the copied URL on top of it. Notice that the label is still the old URL even though the URL actually changed. This happens because after commit [1] When pasting a URL over an active text selection, selected content is converted into a link pointing to the pasted URL. This should not be the case if selected content is a link with same label and URL. **Desired behavior after PR is merged:** If a link is entirely selected and its label is the same as URL then it should replace the existing link label with new URL. [1]: https://github.com/odoo/odoo/commit/d356043a67e1d7291bd1302b1e90a2d9a07718da task-6456004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286081 Forward-Port-Of: odoo/odoo#281700
Belgian payroll now treats removal of a company car from a contract like a car change when prior payslips may already have been declared. This prevents an error and ensures users get the needed confirmation prompt for changes that can affect ATN and CO2 payroll contributions.
Original PR description
Deselecting a car on a contract version raises a singleton error because `version_requires_prompt` is called on an empty `fleet.vehicle` recordset. Removing a company car alters Belgian ATN/CO2 contributions. If past payslips were already declared in a DMFA, removing the car carries the same compliance impact as swapping cars and must trigger the confirmation prompt. task-6524324
Fixed an issue where accrued expense entries were not created for purchase orders using products invoiced based on ordered quantities. This ensures finance teams can recognize expected purchase expenses as soon as the order is confirmed, even before goods are received or invoiced.
Original PR description
Version: -------- - 19.0+ Steps to reproduce: ------------------- - Install `stock`, `purchase`, and `accountant` - Create a storable product with: - Tracking Inventory enabled - Control Policy set…
Version: -------- - 19.0+ Steps to reproduce: ------------------- - Install `stock`, `purchase`, and `accountant` - Create a storable product with: - Tracking Inventory enabled - Control Policy set to **Ordered Quantities** - Create and confirm a Purchase Order with some unit price - Do not receive or invoice the order - From the Purchase Order gear menu, click **Accrued Expense Entry** Issue: ------ The Accrued Expense Entry wizard opens, but no accounting lines are generated. For products invoiced on **Ordered Quantities**, the ordered quantity should already be accrued even though nothing has been received. Cause: ------ This issue was introduced after this changes [commit](https://github.com/odoo-dev/odoo/commit/81f25bc57b8433a65bf33950c64dc7582240a229) Previously, the accrual wizard relied on the stored `qty_to_invoice` field, whose computation already respected the product's Control Policy. For products invoiced on **Ordered Quantities**, `_compute_qty_invoiced()` computes the quantity to invoice from the ordered quantity: https://github.com/odoo/odoo/blob/810a02a577c2811dc5c12f0abf45eebb9cf96d00/addons/purchase/models/purchase_order_line.py#L147-L152 The refactoring replaced this logic with the new `amount_to_invoice_at_date` field, which always computes the invoicable quantity as: `qty_received_at_date - qty_invoiced_at_date` https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/purchase/models/purchase_order_line.py#L282-L285 This formula ignores the product's Control Policy. For products invoiced on Ordered Quantities, before any receipt: `qty_received_at_date` = 0 `qty_invoiced_at_date` = 0 therefore: `amount_to_invoice_at_date` = 0 The Accrued Expense wizard filters out lines whose `amount_to_invoice_at_date` is zero: https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/account/wizard/accrued_orders.py#L168-L178 As a result, the purchase order line is excluded entirely and the wizard produces no accounting entries. The same assumption is also used later in `account.accrued.orders.wizard._compute_move_vals()` when computing tax-included amounts, causing incorrect accrual values for Ordered Quantities products whenever receipts and invoices differ. Fix: ---- Introduce `_get_qty_to_invoice_at_date()`, mirroring the existing purchase_method logic used by _compute_qty_invoiced(). The helper returns: product_qty - qty_invoiced_at_date for Ordered Quantities products; `qty_received_at_date` - `qty_invoiced_at_date` for Received Quantities products. Now products invoiced on `Ordered Quantities` become accruable as soon as the Purchase Order is confirmed; --- opw-6290782 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284507 Forward-Port-Of: odoo/odoo#276435
This fix stops repeated fast clicks from creating duplicate timesheet entries or showing the same new timesheet multiple times in the interface. It improves reliability for users working on slow connections by ensuring each save or suggestion action is handled only once at a time.
Original PR description
Steps to reproduce: 1. Open the ActivityWatch timesheets view. 2. Throttle the network speed to simulate a slow connection. 3. Rapidly click "Add" on an ActivityWatch suggestion. 4. Click 'New', fill in the details, and rapidly click "Create" (or mash Ctrl+Enter). Issue: - Suggestion List: Multiple duplicate timesheets are created in the database. - Creation Form: The newly created timesheet appears multiple times in the UI list on the left side, even though only one might be created in the database. Cause: Both the `onTake` (ActivityWatch list) and `onSave` (Timesheet form) methods are asynchronous. Without a concurrency lock, rapid user interactions trigger these methods multiple times before the initial network request finishes, causing parallel ORM calls and duplicate UI array pushes. task-6462515 Forward-Port-Of: odoo/enterprise#130101 Forward-Port-Of: odoo/enterprise#127806
This fixes an issue where Point of Sale pop-up dialogs no longer closed when users clicked outside them. Restoring this expected behavior makes dialogs easier to dismiss and reduces friction during checkout workflows.
Original PR description
Commit `2abce52ce5f1f3f1b86ee0250f9a3d4544c4da8b` ("[REF] web: migrate t-ref to Owl 3 signals") changed `modalRef` from a classic ref (exposing `.el`) to a signal in dialog.js.
Since then, the DOM element is read by calling the signal (`this.modalRef()`) instead of `this.modalRef.el`.
The POS `Dialog.onClick` patch was still reading `this.modalRef.el`, which is now `undefined`. As a result, `event.target === undefined` was always false, so clicking on the backdrop no longer dismissed the dialog.
Read the element through the signal call so the backdrop click is detected again.
task-6412012
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prBasic point-of-sale receipts for Peruvian companies no longer include additional electronic invoicing details such as the amount in words or QR-related data. This keeps simplified receipts concise while preserving the full information on standard receipts where it is expected.
Original PR description
Step to reproduce - install l10n_pe_edi_pos with demo and switch to PE company - from settings> "Signature Provider" set it to SUNAT - create a pos, enable "Basic Receipt" from settings - open pos…
Step to reproduce - install l10n_pe_edi_pos with demo and switch to PE company - from settings> "Signature Provider" set it to SUNAT - create a pos, enable "Basic Receipt" from settings - open pos and fulfill a order - from feedback screen, print > print basic recipt Observation: - `Amount In Word` is visible in basic receipt, we should not show such info in basic receipt Cause: - commit [1] introduces the template `l10n_pe_edi_pos.pos_order_receipt`, which adds the info block to the receipt using xpath `<xpath expr="//div[contains(@t-if, 'use_self_invoicing')]" position="before">` - this inserts the block before the [target div](https://github.com/odoo/odoo/blob/1ace23afe8a937fc1dc53879f33ca591fd5d25b8/addons/point_of_sale/receipt/pos_order_receipt.xml#L70-L86), which is independent of the `basic_receipt` flag, causing the block to always be visible [1] https://github.com/odoo/enterprise/commit/a0c4f841cde0fcfda0a0c57f865f0eff6b6d6afe Fix: - place the block so it is shown only when `basic_receipt` is false - update the xpath expression to `prices` div ( here `basic_receipt` is false `//div[@name='prices']` with `position="inside"` After fix (for full receipt) <img width="257" height="349" alt="image" src="https://github.com/user-attachments/assets/3932cae1-3ceb-42ad-9ce4-16a9bd4fea7d" /> opw-6383358 Forward-Port-Of: odoo/enterprise#125118
Fixed an issue that could stop Odoo's point-of-sale interface from loading when accessed over a local network IP address instead of a secure or localhost connection. This helps businesses run POS setups more reliably in common in-store network configurations.
Original PR description
Steps to reproduce: 1. Start Odoo with `--http-interface=0.0.0.0` 2. Access the POS interface via IP address (e.g., http://192.168.1.100:8069) 3. The JavaScript bundle fails to load with: "Cannot read properties of undefined (reading 'writeText')" Cause: The `navigator.clipboard` API is only available in secure contexts (HTTPS or localhost). When accessing via IP address over HTTP, the browser denies clipboard access for security reasons, making `navigator.clipboard` undefined. The code directly accessed `navigator.clipboard.writeText` at module load time without checking if the clipboard object exists. Fix: - Use optional chaining when capturing the original writeText reference - Add guard checks in both allowClipboardWrite and restoreClipboardWrite before accessing navigator.clipboard This allows the module to load successfully.
Odoo now avoids showing repeated error dialogs when the browser removes or blocks the storage used for the mail unread badge. The unread badge update is retried safely and ignored if storage remains unavailable, keeping the main interface usable.
Original PR description
Description of the issue/feature this PR addresses: The unread counter feeding the PWA app badge is written to the `odoo-mail-unread-db` IndexedDB database, through a connection opened once, at…
Description of the issue/feature this PR addresses: The unread counter feeding the PWA app badge is written to the `odoo-mail-unread-db` IndexedDB database, through a connection opened once, at module load, and cached for the life of the page by the bundled idb-keyval (3.2.0), which cannot reopen it. When the browser drops the origin's storage (eviction under disk pressure, site data cleared, a privacy extension purging it), that connection is closed for good, and as `updateAppBadge()` discards the promise returned by `idbKeyval.set()`, the rejection reaches the user as a client error dialog. Reported in production on a backend tab left open overnight (Firefox, 19.0): ``` UncaughtPromiseError > InvalidStateError Uncaught Promise > IDBDatabase.transaction: Can't start a transaction on a closed database ``` Reproduced on a demo database below, with `?debug=assets` so that the stack points at the source: lines 23 and 24 of the vendored idb-keyval are the `db.transaction()` call of `_withIDBStore`, on the connection cached at module load. <img width="1600" height="590" alt="error-dialog-debug" src="https://github.com/user-attachments/assets/e2b1aa46-501a-43d4-b4c0-20def1f529ef" /> Current behavior before PR: 1. log into the backend and leave the tab open 2. in the devtools, Application > Storage, tick *only* "IndexedDB" and click "Clear site data", as the browser itself does when it evicts the origin (the session cookie is left untouched, so the tab keeps working) 3. receive a message, or do anything else that changes the unread counter The dialog opens, and opens again on every counter update for the whole life of the tab, since the dead connection is never replaced; the counter is not saved any more either. Two variants of the same code: the write also rejects, without anything being cleared, when the origin runs out of storage quota (`QuotaExceededError`), and when the browser forbids storage for the origin, `indexedDB.open()` throws during module evaluation, so `store_service_patch.js` fails to load entirely. Desired behavior after PR is merged: The store is opened lazily, dropped whenever saving the counter fails, and the write is retried once on a new connection: a single counter update after the connection was closed saves it again. Opening the database is guarded too, for the synchronous throw. When the retry fails as well the error is ignored, the app badge being cosmetic. `mail/static/tests/web/app_badge.test.js` covers the retry, the recovery of a permanently closed connection, and the database that cannot be opened at all. The three tests fail on the current code with the uncaught `IDBDatabase.transaction` error. Introduced in 19.0 by c04c4cb715902fe95618a15e18233cd001bdb304, and identical from saas-19.1 to master, hence this PR against 19.0. The corporate CLA for ERPVibe Limited is submitted in #283477. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283480
This update simplifies internal component setup in Knowledge and Web Studio by removing an unnecessary indirect way of passing local data. It should make the code easier to maintain without changing how users interact with these features.
Original PR description
* knowledge,web_studio Remove `useSubEnv()` calls that were only passing component-local data through the environment layer. Replace with direct instance variable or prop assignments. This simplifies component initialization by eliminating unnecessary environment-based indirection. `localOverlayContainerKey` is now: - Assigned directly to component instances - Accessed directly from the component in templates
This update reorganizes web tour assets into a simpler folder structure and adjusts related references across affected Odoo modules. It should not change user-facing behavior, but it reduces maintenance complexity and helps prevent asset loading or styling issues.
Original PR description
Flatten the unnecessary js/ subfolder into static/src/, alongside views/, widgets/ and scss/. Update imports and manifest asset paths accordingly. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update standardizes internal naming for configuration helpers in the web and resource areas. It reduces developer confusion and prepares the platform for future framework changes, with no expected change to day-to-day user behavior.
Original PR description
Replace deprecated config imports with the correctly named useConfig hook to align with owl3 hook naming conventions. In owl3, hook functions should follow the use* naming pattern. However, props, plugin, and config were introduced without this convention, making it unclear that they are hooks. This creates confusion and inconsistent usage throughout the codebase, with some code using the old config while other code uses the correctly named useConfig. While config is technically deprecated in owl and will eventually be removed, it was retained in Odoo due to widespread usage. This refactoring consolidates all usages to the correctly named useConfig hook, ensuring consistency across the codebase and preparing for the eventual removal of the deprecated config function from owl.
This change updates several Odoo Enterprise web interface components to align with the newer OWL framework version. It is mainly internal maintenance that helps keep views such as cohort, gantt, grid, map, Studio, and the home menu compatible and easier to maintain, with little expected impact on day-to-day users.
Original PR description
- https://github.com/odoo/odoo/pull/286472 See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Web Studio was updated to use the current naming convention for an internal configuration helper. This makes the codebase more consistent and easier to maintain, with no expected change for end users.
Original PR description
Replace deprecated config imports with the correctly named useConfig hook to align with owl3 hook naming conventions. In owl3, hook functions should follow the use* naming pattern. However, props, plugin, and config were introduced without this convention, making it unclear that they are hooks. This creates confusion and inconsistent usage throughout the codebase, with some code using the old config while other code uses the correctly named useConfig. While config is technically deprecated in owl and will eventually be removed, it was retained in Odoo due to widespread usage. This refactoring consolidates all usages to the correctly named useConfig hook, ensuring consistency across the codebase and preparing for the eventual removal of the deprecated config function from owl.
This update adjusts internal test and asset references after a shared tour component was reorganized. It helps keep automated checks and public signing pages working correctly without changing day-to-day user workflows.
Original PR description
web_tour flattened static/src/js/ into static/src/ (odoo repo). Update the asset path and @web_tour/js/... imports accordingly.
This update modernizes how many Odoo interface components define their inputs as part of the ongoing Owl 3 migration. It is an internal cleanup that improves consistency and future maintainability without intended changes to everyday user workflows.
Original PR description
- https://github.com/odoo/enterprise/pull/130310 See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr