Thursday, September 10, 2026
178 changes · master
New functionality added to Odoo
Belgian companies can now generate SAF-T reports directly in Odoo. This supports local accounting compliance needs by making the required audit file export available for Belgium.
Original PR description
SAF-T reports can now be generated for Belgium. task-5129628 Forward-Port-Of: odoo/enterprise#107270
Financial reports can now include fields where users choose from predefined options instead of typing free text. This helps standardize report inputs and reduce data-entry mistakes, with related editing support added for report administrators.
Original PR description
### [IMP] account_reports: Add support for selection figure type in reports This commit adds support for selection type values in report cells that enables user to select a value from a list of…
### [IMP] account_reports: Add support for selection figure type in reports
This commit adds support for selection type values in report cells that enables user to select a value from a list of available values
This values can be defined in the report XML by defining a dict as `selection={'key1': 'value1', 'key2: 'value2'}` and setting the report `figure_type` as `string`.
### [CLN] account_reports: order imports in account_report.py
### [IMP] account_reports: manage selection options in report expressions
Following the related community commit, we add the UI to allow users to edit the selection options for report expressions. We use a small hack to show the translation button for the selection options field, while still allowing users to edit the HTML/XML in the original language only. This is done to avoid users editing the HTML/XML in translations, which could break the report expressions.
We also modify the code extracting the selection options to extract them from the HTML/XML string.
### [IMP] l10n_fr_reports: add sample selection options
THIS COMMIT SHOULD BE DELETED BEFORE MERGING. IT'S ONLY FOR TESTING PURPOSES.Belgian payroll now supports the withholding tax reduction for eligible extra hours, including different deduction rates and annual hour limits. This helps employers calculate overtime-related payroll tax reductions more accurately and stay aligned with Belgian rules.
Original PR description
**Description** This PR implements the Belgian withholding tax reduction for extra hours/overtime (code: P.P.DEDEH) in l10n_be_hr_payroll, where it introduces support for deduction rates (66.81% and…
**Description** This PR implements the Belgian withholding tax reduction for extra hours/overtime (code: P.P.DEDEH) in l10n_be_hr_payroll, where it introduces support for deduction rates (66.81% and 57.75%), annual hour capping (360h standard / 450h Horeca and cash register), **Implementation** . Added the P.P.DEDEH salary rule linked to Belgian CP200 and applicable structures. . A work entry type qualifies for the extra hours reduction if it is flagged as an extra hours entry (is_extra_hours = True) and satisfies the minimum surcharge requirement of at least 20%. Qualification is determined either directly on the work entry type—when its base rate is 120% or higher (amount_rate >= 1.20)—or through its associated category hierarchy. In cases where the base rate itself is lower (e.g., 100%), the system evaluates both assigned categories and optional categories for any child category marked with premium pay (is_premium_pay = True). If the combined sum of the base rate and the child category's premium percentage reaches or exceeds 120%, the work entry line successfully qualifies for the reduction. . To calculate the reduction amount, the system first determines the employee's basic hourly wage rate by dividing their contract wage by the total worked hours in the payslip period. It then evaluates the eligible extra hours against an annual cumulative cap, set to 360 hours or 450 hours if the company uses a registered cash register, by subtracting any extra hours already claimed on prior validated or paid payslips within the same calendar year. For the remaining eligible hours, the system determines the effective rate by adding the work entry type's base rate and any applicable child category premium rates. Surcharges between 20% and 50% receive a 66.81% deduction rate, while surcharges of 50% or higher receive a 57.75% deduction rate. Finally, the total deduction is computed by multiplying the capped extra hours by the basic hourly rate and the applicable deduction percentage. **Example** > Scenario: An employee with a monthly wage of 2,650.00 € works 15.2 extra hours (2 days) in January 2026 under a 200% overtime rate (+100% premium $\ge 50\%$) > . Total Monthly Worked Hours: $167.2 > . Basic Hourly Rate: 2,650.00 / 167.2 = 15.84928$ > . Extra Hours Base Amount: $15.2 *15.84928 €/h = 240.91€ > . Applicable Rate: 57.75 > . Computed Reduction Amount: $240.91 * 57.75 = -139.13€ task-5431919
Odoo now supports Canadian Pre-Authorized Debit as a Stripe payment option. This lets eligible Canadian customers pay through a locally supported debit method, expanding payment choice for businesses using Stripe.
Original PR description
Add support for the Canadian Pre-Authorized Debit payment method in the Stripe provider. task-6276419
This pull request adds a new set of internal guidance documents that make Odoo’s development, review, web, and security expectations easier to find and apply. By documenting rules that were previously informal, it helps new contributors and automation tools produce more consistent, safer code.
Original PR description
Before this commit, the JS conventions of the framework only existed in review comments and in the heads of the people enforcing them. Nothing in the repository stated them, so a new developer, or a coding agent, had no way to find them.
Turkish companies can now store both official buying and selling exchange rates and choose which one applies to invoices, bills, and payments. This helps apply the correct rate per transaction while keeping existing records on the previous selling-rate behavior.
Original PR description
## Description of the issue/feature this PR addresses: Odoo's TCMB integration applies a single selling exchange rate everywhere, but Turkish customers need to apply either the buying or the selling…
## Description of the issue/feature this PR addresses: Odoo's TCMB integration applies a single selling exchange rate everywhere, but Turkish customers need to apply either the buying or the selling rate depending on the transaction - a single rate doesn't fit every case. This lets a TR company fetch both rates and explicitly select which one - Buying or Selling - applies to a given invoice, bill, or payment. ## Current behavior before PR: Only a single (selling) exchange rate is fetched and applied to all invoices, bills, and payments, regardless of the direction of the transaction. ## Desired behavior after PR is merged: `l10n_tr_currency_live_rate` fetches and stores TCMB's buying rate alongside the existing selling rate, and adds a Selling/Buying toggle on invoices, bills, payments, and the Register Payment wizard. The toggle defaults from the document's sale/purchase type or the payment's direction, with a per-partner override that is learned from the first document posted for that partner. Buying rates and the relabelled columns are shown only for companies whose currency provider publishes both rates, so nothing changes for other companies. A `pre_init_hook` backfills existing records to the Selling rate, preserving prior behavior. task-5017817 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Uruguayan point-of-sale orders can now generate the correct electronic tax document directly from the POS. Business customers with a RUT receive electronic invoices, while other customers receive electronic tickets, reducing manual invoicing work and keeping checkout uninterrupted if submission fails.
Original PR description
UY POS sales had no CFE of their own: `l10n_uy_pos` forced every order to be invoiced, so an e-Ticket only ever came out by accident. This module issues the correct type of document based on the customer. E-Invoice 111/112 for RUT partners, and e-Ticket 101/102 built and sent from the `pos.order`. Removes `l10n_uy_pos`: odoo/odoo#281845 task-4221895
Dashboards now open in a visual kanban-style gallery with thumbnails, making it easier for users to browse, create, and open dashboards. This replaces the older landing-page flow and simplifies dashboard creation by letting users start from the dashboard app or convert an existing spreadsheet.
Original PR description
Add kanban view for dashboards Task: [3848129](https://www.odoo.com/web#id=3848129&menu_id=4720&cids=1&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds support for QRMP taxpayers to prepare monthly IFF filings for the first two months of a quarter, with only eligible invoice sections included. The change helps businesses stay compliant with India GST rules by enforcing the ₹50 lakh taxable value cap and carrying excluded or missed invoices into the quarterly GSTR-1 filing.
Original PR description
QRMP taxpayers file GSTR-1 data monthly for the first two months of a quarter via the IFF (Invoice Furnishing Facility), limited to B2B and CDNR invoices and capped at a cumulative taxable value of…
QRMP taxpayers file GSTR-1 data monthly for the first two months of a quarter via the IFF (Invoice Furnishing Facility), limited to B2B and CDNR invoices and capped at a cumulative taxable value of ₹50 lakh. For the third month, a regular quarterly GSTR-1 is filed with all sections, including any B2B/CDNR invoices missed or excluded from the IFF filings of month 1 and month 2. This introduces a new IFF return type and report. - The report reuses the existing GSTR-1 checks and JSON builder, but restricts sections to B2B, CDNR (regular and RCM), SEZ with/without payment, and deemed export - i.e. GSTR-1 Table 4A, 4B, 4C, 6C, 9B. - A new check enforces the ₹50 lakh cumulative taxable value limit on invoices pending for the IFF month. - The `missing_einvoice` check (l10n_in_edi_gstr) is skipped for IFF, as e-invoice completeness is only enforced at quarterly filing. - A new boolean field on account.move tracks whether an invoice is excluded from IFF filing. Excluding an invoice from the check's invoice list defers it to the quarterly GSTR-1 instead of the current IFF month; it remains editable until claimed by a return. task-id 6314238
Odoo spreadsheets can now display hierarchical Odoo data using sunburst and treemap chart formats. This gives business users clearer visual ways to explore grouped data, spot proportions, and understand nested relationships directly in spreadsheets.
Original PR description
This commit adds the odoo_sunburst chart type, which allows to visualize hierarchical odoo data in a sunburst format. Task: [4953941](https://www.odoo.com/odoo/2328/tasks/4953941) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
The employee form has been reorganized to make key payroll information easier to find and manage. Notes now stay attached to the employee overall rather than individual employee versions, and working time calculations better reflect reference calendars.
Original PR description
[IMP] hr: employee form UI This PR adds and adapts employee UI functionalities. - Notes are now relative to the employee and not on the single versions - the notebook page Payroll has been moved at its start task-5961555 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Website header link style options now display correctly across vertical layouts such as mobile, hamburger, and sidebar menus. This keeps navigation design consistent and improves the appearance of menu items when background colors are used.
Original PR description
In this 19.0 commit[1] we reintroduced the link style option on every headers while it was previously disabled on mobile, sidebar and hamburger. However since these templates where not styled to support the link style option, the result was not optimal. This commit adapts the current vertical navigation header to support the link styles options. Fixes the color on accordion items with a background color to match what we do in our dropdown items in non-vertical headers. Step to reproduce: - Choose a vertical header (hamburger, sidebar, or mobile viewport) - Change the link style to any value - Design is not adapted to fit vertical header style. task-5900600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Features or functions removed from Odoo
The old Uruguayan POS module has been removed because it forced every point-of-sale order to be invoiced the same way. It is replaced by a newer module that chooses the correct electronic document based on the customer’s identification type, reducing unnecessary invoicing and aligning with local requirements.
Original PR description
The module's only content was a blanket setToInvoice(true) patch that forced every Uruguayan POS order to be invoiced. This is replaced by the new enterprise module l10n_uy_edi_pos, which decides invoicing per partner identification type: an e-Invoice (via account.move) for RUT partners, and a direct e-Ticket on the pos.order otherwise. The module holds no models, data or xmlids, so there is nothing to carry over: the upgrade script simply uninstalls it, and enterprise databases pick up l10n_uy_edi_pos on their own since it is auto_install on l10n_uy_edi and point_of_sale. That script is a separate PR in the upgrade repository. task-4221895
Code cleanup and technical improvements
The upgrade tooling now updates older signing-related code to match Odoo's newer interface structure. This helps migrations stay compatible and reduces manual cleanup during upgrades.
Original PR description
`signInfoService` has been converted to an OWL3 Plugin, so existing useService("signInfo") call sites need to be rewritten.Documentation and clarification updates
This update records that contributor Victor Hachard has signed Odoo's Contributor License Agreement. It supports legal compliance for accepting current and future contributions from this person.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Signing against 17.0 so the signature is forward-ported to all newer versions, as advised in #139403. Forward-Port-Of: odoo/odoo#287349 Forward-Port-Of: odoo/odoo#287231
Miscellaneous changes
Pulling latest translations from Weblate, since the sync failed to merge them.
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.
Pulling latest translations from Weblate, since the sync failed to merge them.
Channel invitation search now focuses on internal users instead of including large numbers of portal customers. This improves performance for the common case of inviting coworkers, while external participants can still join through invite links.
Original PR description
The exclusion of portal users from the channel invite search was dropped in [1], letting the search match millions of portal users instead of the couple thousand internal ones. This was done to let support agents invite a customer to a videoconf when a ticket needs quick back-and-forth, but that is a corner case compared to the common case of inviting colleagues. Slowing down the common case for everyone to serve a corner case isn't worth it, and external people can still be reached through the invite link. [1]: https://github.com/odoo/odoo/pull/250988 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
Poll start and end notifications will now show a fallback message instead of appearing blank. This makes poll activity easier for users to understand when they receive notifications.
Original PR description
Before this commit, the notification of a start/end poll message was empty. We already have a fallback for empty body and attachments, we can do the same for polls. 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
Saudi e-invoices with an uncertain submission status are now resent exactly as originally signed instead of being recreated. This prevents duplicate or conflicting invoice versions in the official ZATCA chain and keeps retry actions focused on the latest submission attempt.
Original PR description
ZATCA Phase 2 E-invoicing requires each invoice to carry an Invoice Counter Value (ICV) and a Previous Invoice Hash (PIH), forming a cryptographic chain of documents per device (journal). When ZATCA…
ZATCA Phase 2 E-invoicing requires each invoice to carry an Invoice Counter Value (ICV) and a Previous Invoice Hash (PIH), forming a cryptographic chain of documents per device (journal). When ZATCA fails to respond to a submission (timeout or other exception), the document is marked unknown since its actual outcome on ZATCA's side can't be confirmed. Retrying such a document previously regenerated the XML from scratch, producing a new UUID and signature. If ZATCA had in fact processed the original submission, this risked creating a second, divergent version of the same invoice within the chain. This commit stores the signed XML at the moment a document goes unknown and reuses that exact file on every subsequent retry, rather than regenerating it: - A document that returns unknown saves its submitted, signed XML as an attachment - Retrying an unknown document resends that same attachment unchanged, so retries are idempotent and cannot fork the chain - Documents previously stuck in unknown state without a stored attachment are backfilled via a migration, bringing existing data in line with the new behavior - The now-unused chain-blocking mechanism and its supporting field are removed, since a document's own stored attachment is sufficient to guarantee a safe, consistent retry - Only the latest log per document is now actionable (Retry/Process); previously every historical log could show these buttons, letting users retry outdated attempts instead of the current one. Related PR: https://github.com/odoo/upgrade/pull/10887 taskID-5359557
Sales margin tracking will now be installed automatically with the standard sales management flow, instead of requiring users to turn it on in settings. This simplifies setup and makes margin information consistently available for sales teams.
Original PR description
Margins were gated behind a settings toggle even though sale_margin only depends on sale_management, which every quotation flow already requires. Mark sale_margin auto_install so it always installs alongside sale_management, and dropping the "Margins" setting. task-6255022 Related pr: Documentation PR:https://github.com/odoo/documentation/pull/20022 Upgrade PR:https://github.com/odoo/upgrade/pull/11293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website builders get a broader set of decorative shapes, including blurry, line, geometric, grid, and travel map styles. The update also adds ready-made text-and-chart sections to help create richer pages for the new Eclipse theme more quickly.
Original PR description
This PR introduces: - 4 blurry shapes (to be used in new `theme_eclipse`) - 8 lines shapes inside a new section - 5 geometric shapes inside a new section - 2 grid shapes - 2 travel shapes (topographic maps) This PR also introduces `s_text_chart` and `s_chart_text` snippets to be used in new `theme_eclipse`. D-T: https://github.com/odoo/design-themes/pull/1249 task-6482496 | Examples | |--------| | <img width="100%" height="auto" alt="Home-My-Website-09-02-2026_11_15_AM" src="https://github.com/user-attachments/assets/4feab930-0953-4906-91f1-957dfb59da00" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The employee form no longer includes the chat button, and the related code has been removed from the HR module because it is no longer used there. This keeps HR screens cleaner and reduces unused code, while any remaining use is expected to live in the module that still needs it.
Original PR description
The hr_employee_chat widget (component + template + styling) is no longer used in hr since the previous commit removed its only usage on the employee form. It is now only used in sale_timesheet_enterprise (edit_billable_time_target_views.xml), so move it there instead of keeping dead code in hr. task-id 6563733
The timesheet timer now uses the last task or ticket a user viewed instead of relying on recent timesheet defaults, making it more likely to start with relevant context. Users can also copy project and task details from an existing timesheet into the timer, then immediately fill in the description, reducing repetitive entry.
Original PR description
_* = helpdesk_timesheet **- Remove the default project/task values based on the user's most recent timesheets.** - Prefill the timer with the last task visited by the user, even if they are no longer working on it. - store the last visited task/ticket in local storage from the status widget to use it for timer prefill. **- Copy timesheet:** - Add a copy button below the duration of existing timesheets. - Display the copy icon in muted text and turn it green on hover. - Always display the copy button in the mobile view. - Clicking the copy icon sets the corresponding project and task in the timer. - Automatically focus the description field after copying the timesheet. task-6487738
Updates Panama localization reference data to prepare for future electronic invoicing and legal reporting needs. This helps businesses operating in Panama align their accounting setup with upcoming compliance requirements.
Original PR description
Purpose: Update the data in l10n_pa for future implementations of electronic invoicing and legal reporting in Panama. task-6382219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Employee and payroll forms have been adjusted so wage details, notes, working hours, joint committees, and worked-code lists appear in a clearer and more consistent way. This should reduce confusion for payroll teams managing Belgian employee records and payslip-related information.
Original PR description
This PR adds and adapts base and Belgian payroll UI functionalities. As for base payroll: - Depending on the selected wage_type (monthly or hourly) the wage and hourly_wage appear accordingly - Notes are now relative to the employee and not on the single versions As for L10N_BE payroll: - Reference Working Hours is now depending on the resource.calendar and not on a hr.version - Formatted how Joint Committees are displayed in dropdown menus - Formatted Worked Code list view task-5136311
Custom fields added to Planning worksheets with Odoo Studio now show correctly in customer previews and Field Service PDF reports. The update also respects hidden-field rules and preserves side-by-side layouts, so reports better match the worksheet configured by the business.
Original PR description
Previously, - Custom fields added to a worksheet page in Planning (via Odoo Studio) were failing to display in both the **Customer Preview** and the **Field Service PDF report** From now, - Dynamic Field Extraction: Now we actively **scans** the worksheet page for any additional fields added by Studio. - Visibility Evaluation: Now we properly evaluates invisible conditions before adding fields, ensuring hidden elements remain hidden on the report. - Layout Support: Fields are now appended to formatted_properties using a `studio_columns` type. This adds full support for column views if a user arranges fields side-by-side in Studio, the report will faithfully recreate that multi-column layout. - Other Module Compatibility: These changes are seamlessly integrated, leaving the core worksheet functionality and rendering completely **unchanged** for other modules and standard users. Task - 6455812
Businesses can now manage one asset under multiple depreciation rules at the same time, such as statutory and internal book accounting. This improves reporting accuracy and reduces duplicate asset records when different ledgers require different depreciation treatment.
Original PR description
* = account_reports,l10n_{in_asset,ph_reports_asset,ro_saft} This commit enables a single asset to carry multiple depreciation configurations (variants), each targeting a different ledger. This…
* = account_reports,l10n_{in_asset,ph_reports_asset,ro_saft}
This commit enables a single asset to carry multiple depreciation
configurations (variants), each targeting a different ledger. This allows
the same asset to be depreciated under multiple accounting regimes (e.g.,
statutory vs. book) simultaneously.
Changes:
- Introduces `account.asset.variant` model: moves most depreciation
lifecycle logic (board computation, disposal, sale, modification)
from `account.asset` onto variants. A single asset owns multiple
variants, each with its own model, journal, accounts, and state.
- Renames `account.move.asset_id` to `asset_variant_id`: all depreciation
moves now link to a variant instead of an asset directly. Downstream
integrations (fleet, l10n_*, reports) are updated accordingly.
- Adds ledger account fields to `account.depreciation.model`
(`ledger_depreciation_account_id`, `ledger_expense_account_id`,
`ledger_recovery_account_id`) so a depreciation model used for a
ledger variant carries its own account mapping.
- Adds `ledger_depreciation_model_ids` on `account.account` so default
ledger depreciation models can be configured per account, enabling
automatic multi-variant asset creation from bills.
- Adds UI: asset variant list view, depreciation ledger list/form
views, ledger-specific sections on the depreciation model form,
conditional button visibility based on variant state, and a wizard
(`depreciation.ledger.wizard`) to attach a ledger-based depreciation
model to an existing asset.
- Adapts the account asset report SQL to operate at variant level:
restructures CTEs to group values by variant, avoids double-counting
asset cost values across variants, and adjusts disposal/recovery
logic for the multi-variant scenario.
- Updates `l10n_ro_saft` SA-FT asset queries and `l10n_in_asset`
computation overrides to work with `account.asset.variant`.
- Adapts existing tests and adds test file (`test_asset_ledger.py`)
covering ledger variant creation, board generation, disposal, and
report output.
task-5961309Users can now undo shifts scheduled from the planning side panel, making it easier to return to the previous schedule when shifts are split or placed across multiple dates. The planning dialog behavior is also shared more consistently between Planning and Sales Planning, improving reliability when several shifts are scheduled at once.
Original PR description
As some shifts could be split and scheduled at different dates when using the side panel drag & drop feature (happens if there are some unavailabilities in the working schedule or other planned…
As some shifts could be split and scheduled at different dates when using the side panel drag & drop feature (happens if there are some unavailabilities in the working schedule or other planned shifts at that time); In some situations, it can be tedious for the user to undo the scheduling and return to the initial state. To do that, the user would need to manually unschedule the shifts that were planned, set back the allocated hours, etc To prevent this, we introduce an "Undo" notification button that appears after scheduling a shift (i.e., event) from the side panel, allowing you to easily return to the initial state (as we do in most planning actions, like rescheduling or splitting a shift in two). We also moved the logic of the "Plan" dialog that shows up when clicking on an empty cell from sale_planning to the planning module. Thus, we adapted the undo logic to work in batch to handle multiple shifts being scheduled at once. Follow-up of this PR: https://github.com/odoo/enterprise/pull/112009 task-6303828
Belgian payroll now handles mobility budget settlements, Pillar 2 and Pillar 3 payments, year-end balances, and termination calculations more accurately. The update also adds warnings to help payroll teams spot inconsistent payments, invalid budget limits, or company car conflicts before declarations and payslips are finalized.
Original PR description
Rework the mobility budget logic according to Partena requirements. * Settle the remaining mobility budget in December or on the employee's final monthly payslip instead of in the anniversary month.…
Rework the mobility budget logic according to Partena requirements. * Settle the remaining mobility budget in December or on the employee's final monthly payslip instead of in the anniversary month. * Support Pillar 2 payments through payslip inputs even when the Expenses module is not installed. * Add dedicated salary rules for mobility budget amounts already paid, remaining balances, and Pillar 3 payments, including payments related to the previous year. * Include the mobility budget amount in termination fee computations. * Compute the yearly mobility budget as a prorated amount based on all employee versions within the calendar year, where required for payroll calculations and the 281.10 declaration. * Adapt the DMFA mobility budget declaration to report the applicable yearly mobility budget for Pillar 3 payments, including payments related to the previous year. * Add warnings when Pillar 2 or Pillar 3 payments are inconsistent with the remaining mobility budget. * Add warnings when the mobility budget falls outside the configured boundaries or exceeds 20% of the yearly wage. * Add a dashboard warning for employees with a mobility budget and a company car emitting CO₂. * Move the computation of the default mobility budget amount from l10n_be_hr_contract_salary to l10n_be_hr_payroll, so that the mobility budget amount is available without requiring the salary configurator module to be installed. Related upgrade PR:https://github.com/odoo/upgrade/pull/11241 Task: 6263962
Positive correction payslips now defer intellectual property payment increases and their withholding tax to the next monthly payroll. This keeps all intellectual property payments for a month grouped into a single 273.S declaration, reducing reporting inconsistencies and administrative follow-up.
Original PR description
Defer the intellectual-property increase introduced by a correction payslip (the amount and its movable withholding tax) to the next monthly payrun, so that all IP paid in a given month falls into a single 273.S declaration. task-6499510
Belgian payroll now calculates certain withholding tax exemptions directly on payslips, including exemptions for eligible R&D employees. This improves accuracy when exemptions depend on totals across multiple payslips and supports required Belgian reporting.
Original PR description
Some withholding tax exemptions depend on the result of other payslips tax exemptions. Tax exemptions need to be implemented as payslip rules. In order to have the result of other payslip's rules, we need to setup up "rounds of computation". For example: payslip1, payslip2 and payslip3 need to be computed with rules 1, 2 and 3 for each payslip. Rule 3 needs the result of rule 1 and 2 for all payslips. - rule 1: round_of_computation = not_defined -> default = 0 - rule 2: round_of_computation = 0 - rule 3: round_of_computation = 1 Computation will happen in the following order 1) payslip1: rule 1 and rule 2 2) payslip2: rule 1 and rule 2 3) payslip3: rule 1 and rule 2 4) payslip1: rule 3 5) payslip2: rule 3 6) payslip3: rule 3 The final goal of this task is to introduce the computation of withholding tax for R&D employees (bachelor, master and doctor/civil_engineers). task-6201363
Gantt users can now select whole rows or columns directly from their headers when creating multiple items. This makes bulk planning faster and more intuitive, with keyboard shortcuts to extend or adjust selections.
Original PR description
Before this commit, users were unable to select entire rows or columns by clicking on the Gantt chart headers. Selection was only possible by dragging or clicking individual cells inside the grid. We now introduce header-based multi-selection when multi-create mode is enabled: - Clicking a column or row header selects all cells across that column or row. - Shift+click allows extending the range of selected rows or columns from the last selected header anchor. - Ctrl+click allows toggling individual headers, as well as unfolding and selecting folded columns. task-6456200
Financial report expressions can now define selectable options with translatable labels. This lays the groundwork for more flexible reporting choices while ensuring option text can be properly localized for different users.
Original PR description
In order to allow report expressions to have selection options, we add a new field to the ``account.report.expression`` model that will store the selection options as an HTML string, using the following format:
```xml
<select>
<option value="option1">Option 1</option>
<option value="option2">Option 2</option>
<option value="option3">Option 3</option>
</select>
```
We use this format to cleanly extract the option labels for translation using ``html_translate``.
Further handling of these options is done in the related enterprise commit.
[task-6159824](https://www.odoo.com/odoo/project.task/6159824)This update improves responsiveness when using Mail-related dropdown menus in the Odoo navigation bar. It removes a slow page-style check that could cause visible lag, making menu interactions much smoother for users.
Original PR description
This :has() was itself a regression: c9466bb8f8d6 ("unify discuss menus") deleted messaging_menu_patch.scss, which had this exact rule scoped instead as ".o_web_client.o-mail-discuss-systray-menu-open .o_main_navbar" behind a plain media query - the class already toggled by useDiscussSystray()'s body-class effect for a sibling case
Step to reproduce:
1. On runbot, open "Planning" app
2. Go to "Kanban view" (https://<instance>/odoo/employees-planning?view_type=kanban&debug=assets)
3. Open the navbar menu, open a dropdown and "quick" hover the menus "Schedule" > "Maps" > "Planning" > "Reporting" > "Configuration" => You can see the "lag"
On my laptop a come from ~2098ms to ~26.44ms (-98.7%)
task-6465302
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe employee form no longer includes the chat button, and the related code has been moved out of HR because it is only needed by timesheet billing workflows. This keeps the HR module simpler while preserving the functionality where it is still used.
Original PR description
The hr_employee_chat widget (component + template + styling) is no longer used in hr since the previous commit removed its only usage on the employee form. It is now only used in sale_timesheet_enterprise (edit_billable_time_target_views.xml), so move it there instead of keeping dead code in hr. task-id 6563733
Manufacturing administrators can now reset canceled manufacturing orders to draft or move completed ones back into progress, making it easier to correct or continue production records. Canceled orders now consistently cancel all related work orders, and serial or lot numbers are reused when an order is restarted to avoid cluttering inventory records.
Original PR description
This PR allows Manufacturing Admin user to `Reset to Draft` an MO if it's canceled or `Set to In Progress` if validated. This PR also changes the behavior of canceling an MO to cancel all workorders regardless of their state. In case of producing a product tracked by serial number or lot: if the MO already generated/assigned lot_ids, then Mo is validated/canceled, then reset, then confirmed/produced again, it uses the same old lot_ids which keeps the inventory from being crowded with unused serial numbers. Related PR: https://github.com/odoo/enterprise/pull/124863 Task-6348605
Spreadsheet and accounting spreadsheet formulas now handle evaluation errors in the calculation step instead of behind-the-scenes data lookups. This should make user-facing spreadsheet errors clearer and more consistent without changing day-to-day workflows.
Original PR description
Before this commit The evaluation error was thrown in the getters of the plugin. It should be thrown in the compute of the function instead. Task: 6306250 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
Odoo’s shared icon resources are now centralized so multiple apps can reuse the same icon data and search behavior. The icon font generation process is also stored in the codebase, making icons easier to maintain and reducing duplicated frontend mappings.
Original PR description
[IMP] web, html_editor, mail: move icon metadata in `web` --- __Before commit__ All the icon logic is in `web` except for `ms_icons.py`, which contains icon codepoints and search terms. It was…
[IMP] web, html_editor, mail: move icon metadata in `web` --- __Before commit__ All the icon logic is in `web` except for `ms_icons.py`, which contains icon codepoints and search terms. It was originally put in `html_editor` because it was mainly used by the Media Dialog. However, `web_studio` also has an icon selector, `ai_website` uses it inside a model and reimplements a search method, and the codepoints are used by `mail`. __After commit__ - `ms_icons.py` is moved to the root of `web` since it can be used by controllers and models across the entire codebase. - A search method is added to it so `ai_website` doesn't have to write its own. [IMP] web, html_editor, mail: use ligature for `odoo_ui_icons` --- __Before this commit__ `odoo_ui_icons` was generated on fontello.com without ligatures. This meant that a CSS file had to map every icon name to a custom Unicode character. __After this commit__ The Fontello config is stored in the repository. Based on this config, `generate_icons.py` generates a WOFF2 font that contains icon ligatures and a WOFF1 font, which is only used in the backend and includes both ligatures and codepoints. We can therefore remove the frontend CSS mapping, centralize all icon metadata in `icons.py`, and simplify the code exclusive to Odoo UI icons.
This update improves how Odoo records inventory costs, cost of goods sold, and accruals for purchases and sales. It gives finance teams more accurate stock valuation and a clearer view of goods invoiced but not yet delivered or received.
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
Quotation templates now include a Catalog button so users can browse products and add quantities directly, instead of adding items one by one through a field. This makes building reusable sales templates quicker and more consistent with the sales order experience, with related catalog performance improvements when prices are not shown.
Original PR description
Before this commit, adding a product to a quotation template line required creating a line and picking the product from a many2one field, one product at a time. With this commit, a "Catalog" button is added next to "Add a product" in the template lines list, reusing the same product catalog kanban view already available on sale orders. Products can be browsed and added, with their quantity set directly from the catalog. task-6326792
GSTR-1 filing error messages now show the specific HSN codes responsible for failures, along with related error codes and messages. This helps users identify and correct filing issues directly from the chatter without checking separate status files, while also avoiding unhelpful empty error entries.
Original PR description
When GSTR-1 filing fails due to HSN-related errors, the error logs posted in the chatter now include the HSN codes that caused the errors, along with the corresponding error codes and error messages. Previously, the chatter only displayed the error codes and error messages, to identify the HSN codes responsible for the failure, users had to review the generated status.json file separately. By including the HSN codes responsible for errors directly in the chatter, users can quickly identify the source of the issue and resolve it more efficiently. earlier if error code and error message both were missing system still printed False-False now it will be skipped. Also made some improvements in invoices fetching and generating clickable link. task-6214114
Manufacturing orders can now be cancelled without being blocked by related work order quality checks, even when those work orders are in different states. This supports smoother recovery workflows, including future options to reset manufacturing orders back to draft or in progress.
Original PR description
This PR basically allows the deletion of checks on workorders when the MO is canceled regardless of the state of the workorders. This PR is a small part of a feature allowing the user to reset an MO to draft/in progress. Related PR: https://github.com/odoo/odoo/pull/277276 Task-6348605
HR managers in Belgian payroll now receive an activity when an employee has been on sick leave for eight weeks or more. This helps ensure timely contact with occupational medicine services to assess work capacity and support compliance with extended sick leave follow-up processes.
Original PR description
In order to inform the payroll officers to contact the occupational medicine facility to check for the sick employees capacity to their work efficiently in case of an extended sick leave, a new activity will be assigned to the employee HR manager in case any of the employees has a sick leave that has been ongoing for 8 or more weeks. Task: 6126847
Belgian payroll now stores cafeteria plan salary sacrifice and employee net contribution amounts for use in payroll. This prepares payroll processing for cafeteria plan benefits, including deductions that can reduce employer yearly cost when employees cover more of the benefit cost.
Original PR description
This PR is a first step into the cafeteria plan implementation. It creates some properties on the version: - net_contribution: which is an amount taken from the net to cover exceeding benefits costs.…
This PR is a first step into the cafeteria plan implementation. It creates some properties on the version: - net_contribution: which is an amount taken from the net to cover exceeding benefits costs. - salary sacrifice: which represents the amount that the employee willingly sacrifices from his.her gross. Both are used in the payroll process. Salary sacrifice is used because ONSS is due on that. Net contribution is a simple deduction from the net total. Those values are just stored but not computed. They're supposed to be filled after the salary config flow is complete. Updating the salary sacrifice does not trigger any recomputation. The net contribution though has an impact on the yearly_cost : if more of the benefit cost is covered by the employee, it means that the employer cost is lowered. Updating the net contribution has an impact on the yearly_cost, just as updating benefits on the employee's form has an impact on the yearly_cost (in that case, an increase). task-6313710
Spreadsheet survey formulas now handle user-facing errors at the calculation step rather than while retrieving data. This makes error messages appear in the right context and improves reliability without changing the visible survey spreadsheet features.
Original PR description
EvaluationError should be thrown in the compute of the functions instead of the getters. Task: 6306250
Products and lot information selected through the Add Products catalog are now also reflected on the related Equipment page. This helps field service teams keep equipment records aligned with the products used during service work.
Original PR description
Make the lots added in the `Add Products` catalog be added to the `Equipment` page --- task-6397373
The spreadsheet side panels have been visually refreshed to look more polished, consistent, and aligned with Odoo's design style. This improves the user experience when configuring or reviewing spreadsheet options without changing the underlying business workflows.
Original PR description
Go through all the side panels and update their style to be prettier and more modern (and more odoo like). Task: [4080127](https://www.odoo.com/web#id=4080127&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Cash on Delivery and Pay on Site orders now remain marked as unpaid until money is actually collected, while still confirming the order and showing customers a successful checkout. Delivery staff are prompted to collect the due amount during delivery, and Point of Sale can later settle these orders correctly even after goods have been delivered.
Original PR description
*: account_payment_custom, payment(_custom), pos_sale(_delivery,_stock), pos_stock, sale, website_sale_collect Since 9d01784fa998, "Cash on Delivery" and "Pay on Site" transactions were marked as…
*: account_payment_custom, payment(_custom), pos_sale(_delivery,_stock), pos_stock, sale, website_sale_collect Since 9d01784fa998, "Cash on Delivery" and "Pay on Site" transactions were marked as done as soon as the order was placed, so the order appeared fully paid: it could no longer be settled in the Point of Sale, and 1c9c1a1213ef had to patch the remaining balance to ignore those transactions. This keeps such transactions pending instead, the money genuinely hasn't been received yet, and drops that workaround. The order is still confirmed and the customer still sees a success message at checkout, but the payment stays outstanding until it is really collected: - The invoice is no longer issued at checkout, so the customer isn't invoiced for money they haven't paid; it is created when the payment comes in. - Validating a delivery for such an order pops a dialog stating the amount the delivery person has to collect, and for which orders, before the transfer goes through. - The order keeps a remaining balance, so it can be loaded and settled in the Point of Sale, including after the goods have already been delivered, which previously loaded an empty order. - Settling it in the Point of Sale takes the payment there and closes the promise of a payment on delivery. - "Pay on Delivery" is only offered for the full remaining balance: it can't be used to promise a partial payment. task-5166559
The calendar side panel now lets users search and select attendees with clear attendee tags instead of managing a checkbox list. Users can also show or hide their own calendar separately, and selected filters are reused as default attendees when creating new events.
Original PR description
Purpose ======= Improve the calendar side panel attendees filtering. Specification ============= Changing the regular attendee filters display consisting of checkboxes into an attendee records selector with a search input and attendee tags. Each attendee tag matching the color of the related attendee calendar events. As those are filters, they'll be reset after each reload. Also adding a "My calendar" filters so that users can choose between showing/hiding their events. When creating a calendar event, the selected attendee filters will be used as default attendees for the event. The current user will also be added in the default attendees if the "My calendar" filter is checked. Task-5946597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Calendar views can now place extra fields before or after the popover section without triggering a validation error. This gives implementers more flexibility when configuring calendars and helps avoid unnecessary setup failures.
Original PR description
Before this PR, the validator of the calendar view does not allow a field after the popover element inside the calendar tag; a validator error occurs.
This PR makes sure the fields can be added after popover in case, we add a field like this:
```xml
<calendar>
...
<popover>...</popover>
<field name="name"/>
</calendar>
task-5999286The export data dialog is easier to use, with a cleaner layout, better field selection behavior, and editable export templates. Users can now export translated field values by language, making multilingual data exports easier to reuse and re-import.
Original PR description
This PR applies several changes to revamp the export data dialog. First commit modernizes the layout and behavior of the export dialog: Layout: - Replace the "I want to update data (import-compatible…
This PR applies several changes to revamp the export data dialog. First commit modernizes the layout and behavior of the export dialog: Layout: - Replace the "I want to update data (import-compatible export)" checkbox with a more compact "Updatable fields only" switch, placed next to the "Available fields" title it actually filters. - Replace the export format radio buttons with a select displayed below the available fields, freeing vertical space in the right panel, and name the formats "Excel Workbook (.xlsx)" and "Plain Text (.csv)" instead of bare extensions. - Add a search icon inside the search input, hidden as soon as the user starts typing. - Use caret icons and the standard emphasis hover color in the fields tree instead of the brand color overlay, and drop the special styling of expanded items. Behavior: - Toggling "Updatable fields only" now only refreshes the available fields and keeps the export list untouched, instead of resetting it to the default/template list. - Hide the "add" icon of fields already selected instead of rendering it in a disabled state. - Ignore the trash icon in the draggable hook so removing a field cannot accidentally start a drag sequence, and give it a pointer cursor. Second commit adds translation support to export: since https://github.com/odoo/odoo/pull/224997, the import supports translated fields through the `field@lang` header convention (e.g. `name@fr_FR`). The commit adds the counterpart on the export side. Server: - `_export_rows()` now accepts field paths suffixed with `@` and a language code and exports the translation of the field in that language, mirroring the import convention (including nested paths such as `line_ids/name@fr_FR`). - `/web/export/get_fields` and `ir.exports._get_fields_info()` expose a `translate` flag so the client knows which fields are translatable. Export dialog: - Add a "Languages" input at the bottom of the "Fields to export" column, only shown when more than one language is installed. The selected languages are displayed as removable tags next to an inline autocomplete listing the remaining installed languages. - On export, each translatable field of the export list is replaced by one column per selected language, using the `field@code` syntax. An import-compatible export can thus be re-imported with its translations directly. - Languages export preferences can also be saved and loaded into/from export templates. Layout: - Rework the two-pane layout into a 2-column CSS grid so each horizontal pair (titles, search/template, field lists, format/languages) shares a row and stays vertically aligned with equal heights - in particular the Format select and the Languages input. Third commit improves export template creation/edition UX. Templates can now be renamed and have their fields/order/languages changed in-place, instead of only supporting a separate "New template" option. Changing the export list, field order or languages while a template is selected but not being edited detaches from it, keeping the current selection as an unsaved working set instead of forcing edition mode, so a new template can be built on top of an existing one without altering it. ir.exports.line gains a sequence field so the field order of a template is preserved across saves. task-6090205
This update brings Odoo's spreadsheet component up to its latest version, improving reliability in printing, charts, search and replace, clipboard handling, and dashboard spreadsheet behavior. Business users should see fewer errors and more consistent spreadsheet outputs, especially when printing dashboards or working with charts and copied data.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2b1e397c1c [REL] 19.5.0-alpha.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/2b1e397c1c [REL] 19.5.0-alpha.19 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/b85fb02778 [FIX] search and replace: manage invalid range [Task: 6483222](https://www.odoo.com/odoo/2328/tasks/6483222) https://github.com/odoo/o-spreadsheet/commit/b786cb49ed [MOV] clipboard: move clipboard store to correct folder [Task: 6389205](https://www.odoo.com/odoo/2328/tasks/6389205) https://github.com/odoo/o-spreadsheet/commit/873b9b4a20 [REF] clipboard: transform the clipboard into a store [Task: 6389205](https://www.odoo.com/odoo/2328/tasks/6389205) https://github.com/odoo/o-spreadsheet/commit/e4f76b9720 [FIX] carousel: cannot add non-existing chart to carousel [Task: 6455790](https://www.odoo.com/odoo/2328/tasks/6455790) https://github.com/odoo/o-spreadsheet/commit/1fbd77fa5d [FIX] calendar chart: wrong groupBy choice filtering [Task: 5358625](https://www.odoo.com/odoo/2328/tasks/5358625) https://github.com/odoo/o-spreadsheet/commit/56dd9da741 [REF] print: use an iframe to print the spreadsheet [Task: 6466136](https://www.odoo.com/odoo/2328/tasks/6466136) https://github.com/odoo/o-spreadsheet/commit/fe65c382c5 [IMP] draw_grid: explicitly reset transform [Task: 6466136](https://www.odoo.com/odoo/2328/tasks/6466136) https://github.com/odoo/o-spreadsheet/commit/f6cc865beb [FIX] grid: hide AddRowFooter when the mainViewport is too small [Task: 6103620](https://www.odoo.com/odoo/2328/tasks/6103620) https://github.com/odoo/o-spreadsheet/commit/3418890d8e [FIX] print: always print in light mode [Task: 6432165](https://www.odoo.com/odoo/2328/tasks/6432165) https://github.com/odoo/o-spreadsheet/commit/e3f0d8100c [FIX] charts: some charts cannot be aggregated [Task: 6501177](https://www.odoo.com/odoo/2328/tasks/6501177) https://github.com/odoo/o-spreadsheet/commit/d0227ba203 [FIX] print: handle hidden headers [Task: 6332587](https://www.odoo.com/odoo/2328/tasks/6332587) https://github.com/odoo/o-spreadsheet/commit/59860bf2de [FIX] xlsx: fix geo chart xlsx export [Task: 4632983](https://www.odoo.com/odoo/2328/tasks/4632983) https://github.com/odoo/o-spreadsheet/commit/929d44602d [FIX] composer speech_bubble: move after rendering [Task: 6484405](https://www.odoo.com/odoo/2328/tasks/6484405) https://github.com/odoo/o-spreadsheet/commit/fb3300f036 [IMP] package: update owl to alpha 49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/2c7276afad [IMP] *: set button border radius to 4px [Task: 5086089](https://www.odoo.com/odoo/2328/tasks/5086089) https://github.com/odoo/o-spreadsheet/commit/1de94c295d [IMP] formatLargeNumber: throw Error instead of EvaluationError [Task: 6306250](https://www.odoo.com/odoo/2328/tasks/6306250) https://github.com/odoo/o-spreadsheet/commit/1bcd848606 [FIX] hover_overlay: avoid useless render [Task: 6526551](https://www.odoo.com/odoo/2328/tasks/6526551) https://github.com/odoo/o-spreadsheet/commit/a177d96fd5 [FIX] carousel: increase bottom padding [Task: 6481993](https://www.odoo.com/odoo/2328/tasks/6481993) https://github.com/odoo/o-spreadsheet/commit/4b77d5f79f [FIX] ComposerHighlight: Highlight the correct sheet with `#` [Task: 6527596](https://www.odoo.com/odoo/2328/tasks/6527596) https://github.com/odoo/o-spreadsheet/commit/88fdc912e8 [FIX] clipboard: typo on copy/paste on a merge [Task: 6515850](https://www.odoo.com/odoo/2328/tasks/6515850) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Snail mail letters can now report delivery status updates back into the related invoice chatter. This helps users see when a posted letter has delivery problems, reducing uncertainty and making follow-up easier.
Original PR description
Before this commit - sometimes letter got lost and undeliverable for some reason but there was no way to get the status update on that After this commit - added webhook that notify the user in invoice chatter with the status of letter IAP: https://github.com/odoo/iap-apps/pull/1148 task-4942960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Italian e-invoices now use the customer or vendor payment method to select the correct SdI payment code automatically, reducing manual work and inconsistent invoice data. Italian invoice PDFs also show more of the legally relevant FatturaPA information, including payment method, fiscal code, and reference document details.
Original PR description
**PURPOSE** - The Italian invoice PDF should contain the relevant information available in the FatturaPA XML, such as the payment method, fiscal code, and reference document. - The SdI payment method…
**PURPOSE** - The Italian invoice PDF should contain the relevant information available in the FatturaPA XML, such as the payment method, fiscal code, and reference document. - The SdI payment method should also be derived from the customer's configured payment method instead of being manually selected or overridden during payment registration. **SPECIFICATION** - Map Odoo payment methods to their corresponding SdI payment codes. - Automatically set the SdI payment method on new customer invoices based on the customer's configured payment method. - Remove the payment-registration logic that overrides the SdI payment method based on matched or linked payments. - Use the payment method already set on the vendor bill when opening the payment registration wizard. - Improve the Italian invoice PDF to display the missing information, including payment method, fiscal code, and reference document. Task [link](https://www.odoo.com/odoo/project.task/6107170) task-6107170
The website builder can now track and wait for editing actions to finish, which helps AI-driven website editing behave more reliably. Loading feedback has also been improved so users see a continuous indication while multiple builder actions are being processed.
Original PR description
[IMP] html_builder: applyAction returns promise `BuilderActionsPlugin.applyAction` is used to execute builder actions in the builder mutex. After this commit, this method returns the promise associated with the new action pushed in the mutex. This way, if needed, the caller can keep track of the action and await for its execution. This is used in `ai_website` to make the agent await for the execution of builder actions. task-6487866 --- [IMP] html_builder: make Operation handle multiple block requests This commit refactors the `Operation` mechanism such that it can handle multiple block requests. Also `OperationPlugin` now exposes the method `addLoadingElement`. This allows to show a continous loading animation while actions are being pushed in the operation mutex. This is the case in `ai_website` (see linked Enterprise PR). task-6487866
The spreadsheet refresh action now updates Odoo-based formulas as well as charts, pivots, and lists. This helps users see current values across spreadsheets after one refresh, reducing stale financial or business data.
Original PR description
When using the `Refresh all data` menu item, every odoo function should be refreshed, not only the chart/pivot/list data sources. Task: [4823668](https://www.odoo.com/web#id=4823668&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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
Planning shift information is now presented more consistently across calendar, map, Gantt, and Kanban views, making it easier for users to recognize and act on shifts. Field service flows are also clearer, with simpler action labels, better handling when starting open shifts, and corrected menu behavior after uninstalling the field service feature.
Original PR description
## [FIX] web_map: allow to define field/popover in any order in map view Before this commit, it was not possible to add field below the popover element in the map view definition. It was also not…
## [FIX] web_map: allow to define field/popover in any order in map view
Before this commit, it was not possible to add field below the popover
element in the map view definition. It was also not possible to define a
field without string attribute. However, if the string attribute is not
given, the string is found thanks to the fields_get, so the string
attribute can be optional.
This commit improves the rng file for the map view to accept to add
field after the popover to be able to add a field with such xpath:
```xml
<xpath expr="//map" position="inside">
<field name="x_coucou"/>
</xpath>
```
this commit also makes string attrbitue optional for field inside the
map view definition.
## [FIX] planning: wrong order for planning manager
## [IMP] planning{_field_service}: harmonize card popover in calendar/gantt/map
This commit adds the card view in calendar/gantt/map to be able to have
the same card view in popover of those views but also in the kanban
view. This commit also refactors a bit the code to avoid having to
duplicate the code in all those views.
## [IMP] planning_field_service: rename view itinerary and sign in buttons
This commit renames `View Itinerary` into `Navigate` to reduce the size
of the button and also renames `Sign In` button into `Start` to facilitate
the understanding of the purpose of that button.
## [FIX] planning_field_service: correctly restore the menu items in planning
Before this commit, when the field service feature is uninstalled, the
menuitems in planning are not reset as they should be in planning module
and so those menuitems are no longer linked to the planning app.
This commit adds an uninstall_hook to reset the menuitems to their
expected state when only planning is installed.
## [IMP] planning_field_service: improve sign in on open shift
Before this commit, when the user signs in on an open shift, the shift
state is changed to in progress but the shift remains unassigned.
This commit assigns the current user who signs in the open shift to make
sure a resource is assigned to continue the process.
task-5999286Appointment test coverage was updated to reflect recent changes in how calendar partner filters are handled. This helps ensure appointment scheduling continues to work reliably as related calendar behavior evolves.
Original PR description
Update the existing appointment tests to use the "calendar.filters" model so that the recent changes done in to the calendar partner filters (cf COM PR) are correctly reflected. Task-5946597
Spreadsheet printing has been made more reliable by isolating print output from the surrounding page layout, reducing the chance of blank or incorrect pages. The spreadsheet clipboard behavior was also aligned with recent platform updates, helping related chart, sales, and comment tests continue to work correctly.
Original PR description
See https://github.com/odoo/odoo/pull/287546
The AI website builder can now receive direct feedback from browser-based editing tools, so it knows when requested changes succeed or fail. The builder interface stays locked during an AI response to avoid flickering and conflicting edits, and a crash during page redesigns with menu changes has been fixed.
Original PR description
[IMP] ai_website: use aiClientToolsRegistry PR [1] introduced a more convenient way to call client tools, which does not rely anymore on the bus and allow the AI agent to receive a response from the…
[IMP] ai_website: use aiClientToolsRegistry PR [1] introduced a more convenient way to call client tools, which does not rely anymore on the bus and allow the AI agent to receive a response from the tool executing in the user browser. This commit implements this new method for the tools defined in `aiWebsiteBuilderPlugin`. [1]: https://github.com/odoo/enterprise/pull/122477 task-6487866 --- [IMP] ai_website: make agent aware of failed edits Before this commit, the AI agent was not aware of failures generated in `aiWebsiteBuilder.applyActions()`. This meant that the agent was giving a positive feedback to the user edit requests, even if they failed. After this commit, `applyActions()` reports per action what the editor dropped. task-6487866 --- [IMP] ai_website, *: lock the builder UI for the whole AI turn *: ai_html_builder Before this commit, `Thread.post` in `ai_website` ran the post promise inside the builder mutex. The lock was therefore held by `post` for the whole AI turn. After this commit, the loading screen shows the loading effect and blocks the page for the whole turn, this way there won't be any flickering. task-6487866
The spreadsheet refresh action now also updates survey-related formulas, so users see current survey results when refreshing all data. This makes reports more reliable and avoids manually fixing or reopening spreadsheets to get updated survey information.
Original PR description
When using the `Refresh all data` menu item, every odoo function should be refreshed, not only the chart/pivot/list data sources. This commit maek sure the ODOO_SURVEY function is updated. Task: [4823668](https://www.odoo.com/web#id=4823668&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Spreadsheet pivot tables can now have styles defined directly on the pivot, so users no longer need to create separate dynamic tables just to format them. This makes pivot reports easier to format consistently and supports richer styling for headers, totals, and measures.
Original PR description
### [IMP] spreadsheet: implement pivot table styles With this commit, we don't need to manually create a dynamic table to a pivot to have a style applied. Instead we can add a style in the pivot definition, and dynamic tables will automatically be created on the dynamic pivot formulas. Those new pivot styles are better than traditional tables styles because: - they are directly linked to the pivot, taking into account the number of headers, the presence of totals, etc. - they are automatically added on `=PIVOT()` formulas, without the need to create a dynamic table first. - they are more powerful than the old table styles, they can have a style for the sub-headers, the measure headers, etc. Task: [4552232](https://www.odoo.com/odoo/2328/tasks/4552232) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mobile spreadsheet dashboards now show charts and scorecards with more consistent sizing, making them easier to read on phones and tablets. The update also enables carousel-style data views to appear correctly in the mobile dashboard, improving access to spreadsheet insights on smaller screens.
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
Spreadsheet pivot tables now include an option to display row headers in a tabular layout, with each row level shown in its own column. This makes complex pivot reports easier to read, compare, and export for business analysis.
Original PR description
### [IMP] spreadsheet: add pivot tabular form This commit adds a new setting for pivot: whether to use tabular form. In tabular form, each level of row header is displayed in a separate column. Task: [4794334](https://www.odoo.com/web#id=4794334&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Charts in spreadsheets now use updated layout helpers so titles and padding appear more consistent across chart types. This creates a cleaner, more uniform visual experience when users view bar, line, and pie charts.
Original PR description
Adapt the odoo charts to use the new helpers for chart layout. Task: [4316044](https://www.odoo.com/web#id=4316044&action=333&active_id=2328&model=project.task&view_type=form&cids=1&menu_id=4720) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The spreadsheet app interface now adapts to dark mode, giving users a more comfortable viewing option in low-light environments. This also simplifies how the interface is styled, making future visual updates easier to maintain.
Original PR description
This commits implements dark mode for the user interface in o-spreadsheet. We can drop the drak mode-specific stylesheets and use CSS variables using light-dark() instead. Task: [5082659](https://www.odoo.com/web#id=5082659&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet pivot tables now visually indent row groupings based on their hierarchy level. This makes grouped pivot data easier to scan and understand, especially when reports contain multiple nested row categories.
Original PR description
Makde adpatation to the code: now the different groupBys of the rows of the pivots are indented depending on the level of the groupBy. Task: [3965246](https://www.odoo.com/odoo/2328/tasks/3965246) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet users can now duplicate charts directly from the carousel panel menu. This saves time when reusing chart layouts and keeps the related Odoo menu link information intact in the copied chart.
Original PR description
The o-spreadsheet adds a button in the cog wheel of the carousel panel to duplicate charts in the carousel. With this commit, the odoo menu id is also duplicated when duplicating a carousel chart. Task: [5081788](https://www.odoo.com/odoo/2328/tasks/5081788) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product images now include a new stored classification that prepares Odoo for clearer control over primary and secondary product images in future upgrades. This also fixes product duplication so copied products no longer receive duplicate main images or keep image links to the original product's attribute values.
Original PR description
This field will be used in subsequent PRs to: - Keep a product's primary and secondary images unchanged when upgrading to version 20.0. - Allow users to select the primary and secondary images manually, instead of relying on some obscure computation. We're doing the extra work in a separate PR because the new `type` field should be added in the same version as https://github.com/odoo/odoo/pull/242995, and we won't have the time to implement everything before the next version freeze. This PR also fixes issues related to duplicating products with images. Previously: - The main image would be duplicated in the extra images. - Extra images with attribute values would keep pointing to the attribute values of the original product, instead of the duplicate.
The module update process was optimized to reduce repeated lookups and use existing application caching more effectively. This should make system startup and module list refreshes noticeably faster, with reported gains of 30-50%.
Original PR description
30-50% gain by using the ORM directly and caches during loading of all modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Belgian payroll now includes activated joint committee support and related payroll configuration data, helping companies apply the right local payroll rules more consistently. The update also cleans up outdated salary rule references and improves salary configurator test coverage to reduce errors in Belgian payroll flows.
Original PR description
task-6397954
Call activities can now be linked to any relevant contact or record within the same company, not just the exact contact from the call. This makes it easier for teams to record calls against the right opportunity, ticket, project, sale, or subscription when multiple contacts belong to one customer organization.
Original PR description
…ntact *=voip_crm,voip_helpdesk,voip_project,voip_sale,voip_sale_subscription When logging a call activity, the proposed records were limited to those directly related to the call's contact (or its children). They now cover every partner sharing the same `commercial_partner_id`, i.e. the whole company. The Contact field is also unlocked: it used to be readonly when the call had a matched contact, making it impossible to log the activity on another contact of the same company. It now defaults to the call's contact and stays editable within the commercial entity. The helpdesk ticket domain previously matched the call's exact contact only; it now follows the same commercial entity rule as other models. task-6503168
Austrian companies can now see the Fiskaly cash register ID directly in the POS settings. This makes it easier to match each Fiskaly register with the correct POS register, especially for businesses operating multiple registers.
Original PR description
It is difficult to track which Fiskaly register belongs to which POS register for companies which use multiple registers. But we already track the information in the l10n_at_pos module. So this commit will also show the register as a read only field in res_settings for austrian companies (similar to how it's done in l10n_de_cert) Task-[5503862](https://www.odoo.com/odoo/project/1737/tasks/5503862)
Payroll premium pay handling is now made generic so it can be used consistently across all country localizations. This helps businesses apply premium pay categories more uniformly and reduces localization-specific setup or maintenance differences.
Original PR description
Task: 6530690
The calendar side panel filters have been redesigned to make managing visible calendars and attendees clearer and easier. This should help users find, organize, and adjust calendar views faster with a more streamlined filtering experience.
Original PR description
- to do: see if can use Many2manyTagsField instead - Many2ManyTagsFieldColorListPopover? task-5946597
Sales users can now apply the discount wizard to only some lines on a sales order instead of discounting the entire order. This gives teams more flexibility for targeted promotions, corrections, or negotiated discounts without changing unrelated items.
Original PR description
Before this commit, the discount wizard could only discount all the lines of the SO. After this commit it is possible to make the discount on a fraction of them. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Vietnam accounting localization now includes dedicated accounts for recording revenue and costs from selling or liquidating investment property. This supports compliance with Circular 99/2025/TT-BTC and enables related financial reports to separate these gains or losses from regular revenue and cost accounts.
Original PR description
Circular 99/2025/TT-BTC adds a dedicated Profit & Loss line for gains/losses on the sale and liquidation of investment property, computed from dedicated sub-accounts rather than the main revenue and cost-of-goods-sold accounts. Add the two accounts to the chart of accounts: - 5117 Revenue from sale and liquidation of investment property - 6327 Cost of sale and liquidation of investment property See the paired l10n_vn_reports commit for the report changes that consume these accounts. Task-6518304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Vietnamese Balance Sheet and Profit & Loss reports are updated to match Circular 99/2025/TT-BTC effective from FY2026. The changes rename the balance sheet, add the required investment property gain/loss line, adjust line numbering and calculations, and hide a comparison option that does not work correctly for these reports.
Original PR description
Circular 99/2025/TT-BTC (effective FY2026) replaces Circular 200/2014/TT-BTC. It renames the Balance Sheet to "Báo cáo tình hình tài chính" (Statement of Financial Position); the report's account…
Circular 99/2025/TT-BTC (effective FY2026) replaces Circular 200/2014/TT-BTC. It renames the Balance Sheet to "Báo cáo tình hình tài chính" (Statement of Financial Position); the report's account mapping is otherwise unchanged, so only the Vietnamese title needs updating. The Profit & Loss statement (Mẫu B02-DN) gains a new mandatory line, "Lãi/lỗ của hoạt động bán, thanh lý bất động sản đầu tư" (mã số 21), computed from the new 5117/6327 sub-accounts (see the paired l10n_vn commit). Financial income, financial expenses and the interest memo line shift to mã số 22/23/24 accordingly, the "Net profit from operating activities" formula is updated to include the new line, and all following line numbers/labels are renumbered to match the printed form. Also, per revised guidance: - Revenue and cost of goods sold now exclude the new investment property sub-accounts (5117/6327), so those amounts aren't double-counted between the main lines and the new gain/loss line. - Other income is now computed from the "income_other" account type instead of a hardcoded account code, matching how the chart of accounts already classifies it. - The "Percentage of" comparison option is hidden on both reports: it silently no-ops as soon as a report declares more than one column (both reports have a Code column alongside Balance), and there's no per-report way to make it work without a core account_reports change. Task-6518304 See: https://github.com/odoo/odoo/pull/287549
Point of Sale employee access levels have been renamed to clearer business roles: Restrictive, Cashier, Manager, with a new Supervised role added. POS actions are now limited according to each employee's assigned role, helping businesses better control what staff can do at checkout.
Original PR description
**= point_of_sale, pos_discount, pos_loyalty, pos_sale, pos_self_order Following this commit: ==== - Minimal Employee has been renamed to Restrictive. - Basic Employee has been renamed to Cashier. - Advanced Employee has been renamed to Manager. - Introduced the Supervised Employee role. - Restricted POS features based on the employee's assigned role. task-6317141 Ent PR : https://github.com/odoo/enterprise/pull/122275 Upgrade PR : https://github.com/odoo/upgrade/pull/10629
Point of Sale features in appointments, planning, due settlement, and delivery integrations now respect each employee's assigned role. This helps businesses limit sensitive actions to the right staff and keep daily operations aligned with internal responsibilities.
Original PR description
**= appointment, planning, settle_due, urban_piper Following this commit: ==== - Restricted POS features based on the employee's assigned role. task-6317141 Community PR : https://github.com/odoo/odoo/pull/273084 Upgrade PR : https://github.com/odoo/upgrade/pull/10629
This improves how Mexican CFDI invoices are imported, making product, partner, tax, and amount matching more accurate. Businesses should see fewer failed imports and clearer explanations when an invoice cannot be accepted, reducing manual correction work.
Original PR description
Previous this changes, the CFDI import had some limitations: - Missing description when importing Conceptos with a product that didn't exist in database and also the lookup didn't consider when a…
Previous this changes, the CFDI import had some limitations:
- Missing description when importing Conceptos with a product that didn't exist in database
and also the lookup didn't consider when a product reference is from the vendor
- Not a strong validation when importing CFDI (a different RFC, wrong journal, etc.)
- Missing information to be imported due to recent changes
- Wrong criteria to search for a partner when is a foreign Invoice or to public
- No support for local taxes
- Failed to match amounts when taxes are hidden or doesn't match database tax configuration.
- Repetitive error messages or not a complete description on what failed mainly on tax import
and when a document is not valid
After this commit, now:
- The lookup of products considers the vendor information and if no product is found,
the description of the Concepto is used instead
- Improved the validation when a CFDI is not valid and a message explaining why
- Added missing information
- Improved partner search to not search by a generic RFC but for the Registration number
- Added support for local taxes. This will be created as new invoice lines with a generic tax.
- Tax amounts are fixed by forcing the tax lines to have the values of the CFDI. For the untaxed
amounts, a rounding line will be created
Also the structure of the import workflow is changed to use the new helpers for edi import
task-4399021Users creating a job offer from the website now get a clear warning if the job would belong to a company they do not currently have active. This prevents a confusing access error after saving and helps users correct their company selection before continuing.
Original PR description
- With Mitchell admin only select "My belgian company" - Go to website on My Website (My Company website- - New -> Job Offer - Modify -> Save - Access right crash **Current Behavior** It created a record regardless of the user active company. If that company wasn't among the user's currently active companies, the immediate read-back (redirect into edit mode) hit the multi-company record rule and threw a generic Access Error. **Now:** Check the mismatch upfront and show a clear, actionable message instead of letting the record get created and fail on read. task-6563673
This fixes an error that could appear when Odoo sends emails after completing database setup or module installation in translated environments such as French. Emails now use the active environment for translations, preventing unnecessary log errors and improving reliability of automated email delivery.
Original PR description
Currently an exception is generated when the `send_after_commit` tries to send the email as below step: - Create a database without demo data and language `fr_FR` - Install the `appointment` module -…
Currently an exception is generated when the `send_after_commit` tries to send the email as below step: - Create a database without demo data and language `fr_FR` - Install the `appointment` module - Set up outgoing email server - Error appears in the log when loading the demo data Error: `TypeError:'NoneType' object is not subscriptable` This issue occurs after the recent refactoring changes in [1]. The method `send_after_commit` (see[2]) sends the email with a new cursor after committing to the current cursor, and here when `_send()` tries to send the mail, it uses the `_()` method for translation, which accesses `self.env` (self refers to the old closed cursor). However, at this point, the cursor is already closed. As a result, when the code at [3] is reached from `ormcache`, it raises the above error because `model.env.transaction.ormcaches__` is `None` (code ref [4]). This commit fixes the above issue by using `self.env._()` for translation instead of `_()` while sending the mail to ensure the translation accesses the current environment cursor instead of the closed one. [1]: https://github.com/odoo/odoo/commit/13c3adf3a8b5ba6325190d6b9aea45fb8a6a8b2f [2]: https://github.com/odoo/odoo/blob/86d750e777d1adc09f53016a255c7b1158fd309c/addons/mail/models/mail_mail.py#L708-L713 [3]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/cache.py#L111 [4]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/environments.py#L1012 Sentry-7608119520 Forward-Port-Of: odoo/odoo#287438
Point of Sale now avoids adding variant price adjustments twice when a product variant is selected through barcode search or related flows. This prevents customers from being overcharged for configurable products with dynamic variant pricing.
Original PR description
Steps to reproduce: - Create an attribute "Size" with values M and L, variants creation mode "Dynamically", and an extra price of 10 on L - Create a product at 30 using that attribute, and give the L…
Steps to reproduce:
- Create an attribute "Size" with values M and L, variants creation mode "Dynamically", and an extra price of 10 on L
- Create a product at 30 using that attribute, and give the L variant a barcode
- In the PoS, type that barcode in the search bar and click the card
Issue:
The line is added at 50 instead of 40. Scanning the barcode with a barcode reader was fixed by c1ae3261e895, but resolving the variant from the search bar still charges the extra price twice.
Cause:
The lst_price of a variant already contains the extra price of every attribute value that creates a variant ('always' and 'dynamic'); only 'no_variant' extras are missing from it and have to be carried by the order line as price_extra. This is what ProductConfiguratorPopup does, hence the correct price when the configurator opens.
Both openConfigurator(), when the resolved variant leaves a single value per attribute line and no popup is needed, and handleConfigurableProduct(), when configure is false, filter those values with create_variant !== 'always', so a 'dynamic' extra is added on top of a lst_price that already includes it. The same fix was made in 18.0 by d4fabfa08d1c but was lost when pos_store.js was refactored in saas-18.1.
Fix:
Filter on create_variant === 'no_variant' in both places, like the configurator popup. This supersedes the !opts.code condition of c1ae3261e895: product_template_variant_value_ids never holds 'no_variant' values, so the extra is now ignored however the line was added - scan, barcode search, sale order import or optional product.
opw-6531114
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#286460The demo payroll setup for Belgium now enables the joint committees used by the sample data. This ensures related salary rules and records are active, making demos and tests behave as expected.
Original PR description
JC 200, 302, and 999 are used in demo data. They should be enabled to activate the salary rules and other related records. task-6563586
This fix makes an automated spreadsheet reporting test more reliable when the server responds slowly. It reduces false failures by allowing more time for the spreadsheet to open and ensuring each step waits for the correct screen before continuing.
Original PR description
Before the tour was undeterministic because if the server was slow, it would fail by: 1: timeout was too short when opening the spreadsheet 2: some steps ran faster than the view could handle and ran on the previous view instead of the new view to be loaded.
This update prevents employees from requesting time off on days outside an active contract, such as before hiring, after leaving, or between contracts. It also allows payslips with warnings to be printed again, while moving an employee chat component to the module where it is actually used.
Original PR description
[[FIX] hr_holidays_gantt: grey out days outside the employee's contract](https://github.com/odoo/enterprise/commit/63288c5f70a80ea82c5894688bdb38d4d9afd1a1) The Time Off gantt only greyed a employee…
[[FIX] hr_holidays_gantt: grey out days outside the employee's contract](https://github.com/odoo/enterprise/commit/63288c5f70a80ea82c5894688bdb38d4d9afd1a1) The Time Off gantt only greyed a employee ordinary calendar days off, never the days a window shows that no version covers at all: before the employee was hired, after they left, or in a gap between two contracts. Those days rendered as plain available cells, letting time off be requested outside any contract. [[MOV] sale_timesheet_enterprise: move employee chat widget from hr](https://github.com/odoo/enterprise/commit/c56a47aa3e2693d58f2e37356da547332caf012f) The hr_employee_chat widget is now only used here (edit_billable_time_target_views.xml), so bring it into this module instead of leaving dead code behind in hr. [[IMP] hr_payroll, l10n_in_hr_payroll: don't block payslip printing on warnings](https://github.com/odoo/enterprise/commit/0ddce9b40c204d2f31539eff17681ee12e2c02f2) Steps to reproduce: - Go to an employee - Put it as anomaly - Go to the payslip - Unable to print it action_print_payslip refused to print any payslip carrying a danger-level warning (error_count) The check was added to work around a report crash for employees without a running contract (comparing a date to a False contract start raised a TypeError). That crash is already fixed directly in the payslip template's own guard, so blocking print entirely is no longer needed to avoid it. task-6563733
The salary configurator now validates only the field a user edits instead of rechecking the full form and scrolling the page. The job offer template and salary simulation display were also polished, making offers clearer and more comfortable to review.
Original PR description
[[FIX] hr_contract_salary: stop re-validating whole form on single field edit](https://github.com/odoo/enterprise/commit/2a80d668299185f3269071016b86d985967bb656) **Steps to reproduce:** - Go of the salary configurator of a job offer - Click on Review - Some fields are not filled and will be marked as invalid - Fill one of the invalid fields and click on Review again **Current Behavior:** Each time an invalid field is filled, the whole form is re-validated and the page scrolled **Expected behavior:** Only the field that was edited should be re-validated, and the page should not scroll. [[IMP] hr_contract_salary: update offer template and immprove salary background](https://github.com/odoo/enterprise/commit/acf7f4e94c3e204f61e18cb33f823c991f286c3e) This commit improves the offer template and change the grey background of salary simulation to white. task-6563673
Mexican electronic invoice PDFs now include local taxes in the totals and show the export type value. This helps ensure the PDF matches the official CFDI document and avoids confusing or incorrect totals for invoices using local taxes.
Original PR description
In odoo/enterprise#98816 the MX invoice pdf was modified to be an exact representation of the generated CFDI document (MX EDI doc). Some info was not considered during the implementation: local taxes…
In odoo/enterprise#98816 the MX invoice pdf was modified to be an exact representation of the generated CFDI document (MX EDI doc). Some info was not considered during the implementation: local taxes and export type value. This causes the pdf total amounts to not match when generating the PDF when using local taxes. How to reproduce (using demo data for easy testing): - Install l10n_mx_edi with demo data and select `INNOVACION Y DESARROLLO...` demo company - Go to Accounting > Configuration > Taxes - Copy tax 16% (VAT(16%)) and under `Advanced Options` tab change SAT tax type (l10n_mx_tax_type) to Local - Go to Accounting > Customer > Invoices and use one of the draft invoices to INMOBILIARIA CVA. - Add the new tax under the existing line. - Post invoice and send to show Send wizard. Disable the email option and enable CFDI one if not set and generate CFDI. - Generated PDF will not have the local taxes on their totals and also exportacion value is not there This commit adds the local taxes at the tax totals table and export type value. task-6477478 Forward-Port-Of: odoo/enterprise#128145
Completing a field service shift now correctly refreshes the allocated hours shown in planning. This helps teams keep schedules, workload tracking, and related timesheet or sales information aligned after work is marked done.
Original PR description
This reverts commit b642ea4d5d2c0b4bd83c70103f7e8dfa6ef736dd. opw-6542896 Forward-Port-Of: odoo/enterprise#130890 Forward-Port-Of: odoo/enterprise#130832
Odoo now avoids blocking record creation when a calculated field is prepared in advance but hidden from the current user by group permissions. This prevents unexpected access errors, such as when saving sales orders in setups that restrict margin-related fields, while preserving normal permission rules.
Original PR description
**Description of the issue/feature this PR addresses:** If a field is `computed`, `precomputed`, and has `groups` defined, an `AccessError` is raised when a user who does not have the required group…
**Description of the issue/feature this PR addresses:** If a field is `computed`, `precomputed`, and has `groups` defined, an `AccessError` is raised when a user who does not have the required group creates a record because the field is precomputed. After this commit https://github.com/odoo/odoo/pull/201565/changes/48521a311a6dc857c3808db70ed359c7866aa125, Odoo checks field access in `__get__`, so an `AccessError` is now raised. If the field is not precomputed, everything works fine. Therefore, this commit prevents the error by using `sudo()` to recompute the value. I have attached a module to demonstrate the issue. **Steps to reproduce the issue:** 1. Install the attached module. [sale_margin_security_test.zip](https://github.com/user-attachments/files/31967357/sale_margin_security_test.zip) 2. Create a sales order and add a product. 3. Try to save the sales order. The AccessError is raised. https://github.com/user-attachments/assets/54c7e4e2-005f-4ced-bb62-22d0e00049d9 For more context, this module is a simple example extracted from the OCA `sale_margin_security` module, which inherits from a mixin and adds groups to the fields: https://github.com/OCA/margin-analysis/pull/285 You can see the error in this PR: https://github.com/OCA/margin-analysis/actions/runs/34254749207/job/102157600233?pr=285#step:8:126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287257
This fixes an internal website test so it consistently uses mocked image search services instead of trying to contact external providers. It helps keep automated testing stable and prevents false failures during development and release checks.
Original PR description
test_02_image_upload_progress_unsplash monkeypatches HTML_Editor.media_library_search and Web_Unsplash.fetch_unsplash_images to avoid calling third-party APIs during the tour. But the routing map is cached (the "routing" ormcache) with the controller endpoints baked in: when it was already built with the original methods, the patches above are ignored. The original media_library_search then runs and performs a real HTTP request, which is blocked by the test suite, failing the tour with "Couldn't reach API endpoint". Invalidate the "routing" ormcache after patching so the requests are routed to the patched methods. Same change as done in https://github.com/odoo/odoo/pull/271536. https://runbot.odoo.com/odoo/error/939945 Forward-Port-Of: odoo/odoo#287586
Timesheets now handle short activity events after inactivity more accurately, preventing them from being incorrectly counted as inactive time. This improves the reliability of recorded work time for employees and managers.
Original PR description
Before this Commit, if an AFK event was followed by small events, those small events would be packed into the AFK event. This caused the recorded time worked to be inaccurate. After this Commit, when an AFK event is followed by small events, they are either packed together to form a bigger non‑AFK event or ignored if they can't be packed. task-[6486145](https://www.odoo.com/odoo/project/4105/tasks/6486145) Forward-Port-Of: odoo/enterprise#130877 Forward-Port-Of: odoo/enterprise#128710
Fixes overly bright borders and low-contrast elements in Discuss when using dark theme. Livechat disconnect banners and poll styling are also adjusted so messages remain easier to read and the interface looks consistent across themes.
Original PR description
Before this commit, Discuss borders in dark theme were very light. This happens because Discuss used border-secondary as this provided the consistent look between white and dark theme, which the…
Before this commit, Discuss borders in dark theme were very light. This happens because Discuss used border-secondary as this provided the consistent look between white and dark theme, which the default border didn't: the default border was too distracting in dark theme, making the UI look bloated. With frost, the default border now look consistent between white and dark themes. A recent PR changed border-secondary to be much more visible in dark theme [1], which goes against the intended look in Discuss. This commit fixes the issue by removing most border-secondary in Discuss UI, relying on default border that gives the intended look. The recent PR [1] also impacted: - the livechat "disconnect" banner bg color, which made it barely readable in dark theme. This is fixed in this commit by using `.alert` like the unread message banner. - the poll secondary color, in both white and dark theme. This commit reduce the opacity so this made secondary compared to o-action and primary colors as intended. [1]: https://github.com/odoo/enterprise/pull/129792
Icon buttons for email, phone, URL, bank tags, and related-record fields now use the same visual style. This makes forms look more consistent and removes an unwanted light border on mobile in dark mode.
Original PR description
The email, url, phone and many2one internal link buttons each hand-rolled their own `btn-*` combination, so the same button looked different from one field to the next. They now share `btn btn-light btn-sm`. The M3 mobile pill drops the border `btn-light` brings along, which showed as a light rim in dark mode. task-6528417 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Documents app layout has been adjusted to better match the latest Odoo design, with cleaner cards, panels, dialogs, and sharing views. The changes improve usability across desktop and mobile, including clearer side-panel information, consistent folder styling, fixed navigation issues, and restored scrolling on small screens.
Original PR description
- Side panel with chatter becomes a self-contained box, sized to its content, aligned with the kanban cards - Fix kanban card radius, double borders, padding. - Recents didn't have the same styling than other folders - Fix control panel action padding - Move dialog: match search panel styling, fix crash on fold button keypress - Panel and its toggle hidden below lg - Share view, viewers are aligned with the owner - Solved a bug due to the removal of the negative margin (rendering the chatter in the no content) - Reviewed contrast of the fields in the documents_details_panel to match the new bg + added tooltips - Fix scroll in mobile task-6509487
This fix ensures barcode picking batches can reliably find their default source location, even when that information was not already loaded. It helps avoid errors or interruptions during warehouse barcode operations.
Original PR description
Previous commit 62c570a4 [1] from odoo/enterprise#117220 introduces a new getter on BarcodePickingBatchModel: `operationSourceLocation`. The issue comes from `default_location_src_id` which is not guaranteed to be in cache. [^1] 62c570a47cc1884cb31c4e1288b86dfab37daadf Forward-Port-Of: odoo/enterprise#130823
Spreadsheet test sessions now avoid cell animations that could freeze in debug mode and show incorrect cell values. This makes internal test results more reliable without changing normal user spreadsheet behavior.
Original PR description
If you try to open a spreadsheet in debug mode in the Hoot tests, you will often end up with cells with wrong displayed data. That's because cell animations don't work in hoot (it patches `requestAnimationFrame`), so we end up with cell animations stuck in the first frame of the animation. We can simply disable the cell animations in the Hoot tests, as animations are not relevant to the tests. Task: [4909027](https://www.odoo.com/odoo/2328/tasks/4909027) Forward-Port-Of: odoo/odoo#216620
The search filter dropdown is now shown based on whether the user is on a touch device rather than the screen size. This fixes a confusing tablet experience where users could not clearly access filters from the search bar.
Original PR description
Right now we're disabling the drop down caret on screens smaller than md, and clicking on the search bar will not show the filter menu on touch devices. This leaves tablets (md screens) in a weird state where there's no drop down button, but clicking the search bar also doesn't show the filters. You can only see the filters by clicking on the very right end of the search bar (where the caret is supposed to be), with no indication that is possible. You can see the task for a video of the issue. In the commit I change the disabling of the drop down button based on input type, instead of screen size. So it will always show on touch, and always be hidden when using a keyboard and mouse. Task-[6560917](https://www.odoo.com/odoo/project/1737/tasks/6560917) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where extra action menus appeared inside pop-up selection dialogs after a visual change made an older hiding rule stop working. Users will no longer see confusing or irrelevant menu options in those dialogs, making the interface cleaner and more consistent.
Original PR description
The cog menu is displayed in the dialogs that keep a control panel: the SelectCreateDialog and act_window actions in target="new" showing a list or a kanban view. Form views in a dialog are spared,…
The cog menu is displayed in the dialogs that keep a control panel: the SelectCreateDialog and act_window actions in target="new" showing a list or a kanban view. Form views in a dialog are spared, as they drop their control panel altogether. It used to be hidden by a CSS rule matching the settings icon of the toggler. a243283b393a restyled that toggler and swapped its icon for `more_vert`, which silently voided the rule for the CogMenu (the ActionMenus, still using the settings icon, stayed hidden). Hide the menus where they are rendered rather than from a stylesheet, so that this no longer depends on the icon of the toggler, and drop the CSS rule, which has nothing left to hide: outside of a dialog, the only other element carrying the `modal` class is the FileViewer, and it renders no action menus (the Documents preview, which does, sets `modal` to false). Steps to reproduce: - open any form view with a many2one field, e.g. Sales > Orders > New - click the Customer field and pick "Search More..." - the dialog shows the cog menu on the left of its control panel 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 payroll dashboard button for opening pay runs now shows the correct payroll runs instead of an empty window. This helps payroll users quickly access the relevant pay run records from the dashboard without extra searching or confusion.
Original PR description
-Previously, upon clicking "Open Pay Run" button in payroll dashboard, it redirects to an empty window. -The domain for the records has been adjusted to show the correct payruns.
Installing the India Payroll module could fail because demo data still referenced a removed health insurance amount field. This update removes that outdated demo data value so the module can be installed successfully.
Original PR description
Steps to reproduce: - try to install l10n_in_hr_payroll Reason: - in this PR total_amount was removed https://github.com/odoo/upgrade/pull/11155 - total_amount field was not removed from the the health insureance record in indian localization Fix: - Remove total_amount from the demo data. task-6563549
Calendar reminder notifications now show line breaks properly instead of displaying raw HTML text. Related tests were updated so reminder notification checks handle the expected message formats more reliably.
Original PR description
This PR fixes 2 bus related to calendar alarm notification messages. The first bug prevented the message to be correctly displayed. The message displayed the <br/> hmtl tag instead of creating new lines. The second bug is related to tests. Some test related to notification messages couldn't handle the various format of messages.
This update prevents employees from requesting time off on days outside their contract period, reducing scheduling errors. It also allows payslips with warnings to be printed again while keeping report safeguards in place, and moves an internal employee chat component to the module where it is used.
Original PR description
[[FIX] hr_holidays_gantt: grey out days outside the employee's contract](https://github.com/odoo/enterprise/commit/63288c5f70a80ea82c5894688bdb38d4d9afd1a1) The Time Off gantt only greyed a employee…
[[FIX] hr_holidays_gantt: grey out days outside the employee's contract](https://github.com/odoo/enterprise/commit/63288c5f70a80ea82c5894688bdb38d4d9afd1a1) The Time Off gantt only greyed a employee ordinary calendar days off, never the days a window shows that no version covers at all: before the employee was hired, after they left, or in a gap between two contracts. Those days rendered as plain available cells, letting time off be requested outside any contract. [[MOV] sale_timesheet_enterprise: move employee chat widget from hr](https://github.com/odoo/enterprise/commit/c56a47aa3e2693d58f2e37356da547332caf012f) The hr_employee_chat widget is now only used here (edit_billable_time_target_views.xml), so bring it into this module instead of leaving dead code behind in hr. [[IMP] hr_payroll, l10n_in_hr_payroll: don't block payslip printing on warnings](https://github.com/odoo/enterprise/commit/0ddce9b40c204d2f31539eff17681ee12e2c02f2) Steps to reproduce: - Go to an employee - Put it as anomaly - Go to the payslip - Unable to print it action_print_payslip refused to print any payslip carrying a danger-level warning (error_count) The check was added to work around a report crash for employees without a running contract (comparing a date to a False contract start raised a TypeError). That crash is already fixed directly in the payslip template's own guard, so blocking print entirely is no longer needed to avoid it. l10n_in_hr_payroll's payslip templates had the same unguarded comparison this commit fix it task-6563733
Fixes payslip worked day lines so hourly time off, such as a 2-hour absence, is no longer counted as a full day. It also prevents duplicate or excessive lines when multiple time types occur on the same day, improving payroll accuracy.
Original PR description
When creating a time off type based on hours, and setting a time off of 2 hours for example, in the worked day lines of the payslip, these 2 hours would turn into a full day. Moreover, when more than 2 time types were set for the same day, too many lines would show, making the computation wrong. __ task-6450001
The HTML editor module no longer declares an unnecessary dependency on website routing code. This keeps the module setup cleaner and avoids pulling in unrelated functionality when the editor is installed.
Original PR description
The dependency is wrong. The function `_get_translation_frontend_modules_name` is simply dead code. Issue introduced in #287134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The editor color picker now displays borders and focus indicators that fit the dark mode interface. This makes choosing and editing colors clearer for users working in dark mode, while preserving the HTML builder’s existing background styling.
Original PR description
[FIX] html_builder, html_editor: adapt color picker to dark mode Steps to reproduce: - Enable dark mode in the backend. - Open a color picker from the editor toolbar. - Check the swatch borders and the focused custom color controls. Before this commit, the color picker relied on fixed light toolbar colors. Its borders and focus rings did not match the dark popover. After this commit, the color picker uses the popover and body colors, while the HTML builder keeps its own background color. task-6259086
Kanban views that include progress bars no longer flicker when opened or refreshed. This improves the visual experience for users working in apps such as Project without changing functionality.
Original PR description
The progressbar in the kanban views (eg. Project) previously relied on a min-height computation. Frost moved the `fs-4` from the `o_column_title` to the `o_kanban_header` which breaks the computation. This creates a visible flicker when the view load, to reproduce just go in a project and click the kanban view button multiple times. task-6558904 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the expected spacing between grouped buttons in the Community edition after a recent design update removed it. It keeps the interface visually consistent and easier to use, while allowing the Enterprise edition to apply its own styling separately.
Original PR description
After frost reskin, `btn-group` spacing has disappeared. We still need it for community design so we restore it here and override it in enterprise. ENT: https://github.com/odoo/enterprise/pull/130287 task-6519485 | Before | After | |--------|--------| | <img width="309" height="49" alt="Screenshot 2026-09-04 at 09 16 14" src="https://github.com/user-attachments/assets/5f5f5151-30a7-4d7b-97f0-dd1fa5ac3b6c" /> | <img width="313" height="47" alt="Screenshot 2026-09-04 at 09 16 50" src="https://github.com/user-attachments/assets/8a8bd76d-3068-4039-8144-54276a1ab0d9" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Mobile views no longer show each total line inside its own outlined field box in subtotal sections. This keeps invoices, quotations, purchase orders, expenses, PoS orders, and related totals easier to read on small screens while preserving needed spacing for multi-line total blocks.
Original PR description
On small screens, the M3 style wraps every cell of an inner group in an outlined box with a floating label. Applied to the subtotal footers (invoice, quotation, purchase order, PoS order, ...), this framed each amount individually, which is noisy: those groups are already visually delimited by the footer itself and read as a totals block, not as a list of editable fields. Exclude `.oe_subtotal_footer` groups from the field box and floating label rules, so their amounts and labels stay plain on mobile. The box also carried the vertical rhythm (the inner group row gap is 0 below md), so add the spacing back in the few views whose footer stacks several rows. task-6522832 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 time off summary now counts only leave taken in the selected year instead of including leave from other years. This prevents inflated totals and gives managers and employees an accurate yearly view of absences.
Original PR description
**Steps to reproduce:** - Create a sick time off for employee A in 2025 - Create a sick time off for employee B in 2026 **Current** Summary 2026 show all years summary -> 2 day **Expected** Summary 2026 should only show the current year time summary -> 1 day task-6445187
This fix ensures kitchen or preparation tickets from self-order and point-of-sale orders are sent through the correct printing route. It helps restaurants avoid missed or misrouted orders by using OBOX for mobile self-ordering and local printing for kiosks and in-store point of sale.
Original PR description
Ensures that preparation tickets are printed from the correct channel. - Mobile Self Order => via OBOX - Kiosk Self Order => via local IP - Point of Sale => via local IP Behavor of the self-ordering…
Ensures that preparation tickets are printed from the correct channel. - Mobile Self Order => via OBOX - Kiosk Self Order => via local IP - Point of Sale => via local IP Behavor of the self-ordering preparation process depending on the payment status and the configuration of the PoS. Self Order mobile (always printed via OBOX): - EACH PAID: If an order is created and paid, it should create a prep order directly from the Self Order (via OBOX or preparation display) - EACH UNPAID: If an order is created and unpaid, it should also create a prep order directly from the Self Order if there is NO available payment method (via OBOX or preparation display) - MEAL PAID: If an order is created and paid, it should create a prep order directly from the Self Order (via OBOX or preparation display) - MEAL UNPAID: If an order is created and unpaid, it should also create a prep order directly from the Self Order (via OBOX or pdis) Self Order kiosk: - EACH PAID: If an order is created and paid, it should create a prep order directly from the Self Order (local IP or preparation display) - EACH UNPAID: If an order is created and unpaid, it should create a prep order directly only if there is NO available payment method (via local IP or preparation display)
This update adjusts internal tests so they work correctly with recent changes to the test runner in debug mode. It helps keep development and quality checks reliable for the Mail and Spreadsheet areas without changing customer-facing behavior.
Original PR description
Since commit f83282086a412b6560b20186230cfd8daf56e4f9, the hoot `__debug__` helper returns a function that returns the hoot runner rather than the runner itself. Some tests weren't adapted. Task: [6560305](https://www.odoo.com/web#id=6560305&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#287440
Creating a new job position no longer shows the same creation message twice in the chatter log. This keeps recruitment activity history cleaner and avoids confusion for users reviewing job position updates.
Original PR description
When creating a new job position, "Job Position created" was rendered twice in the chatter log. This occurred because the mail subtype definition specified a redundant `description` field with the exact same text as the subtype's name, causing the chatter logic to display both. Removing the explicit `description` field ensures the message is only displayed once upon job creation. Task: 6486002 Forward-Port-Of: odoo/odoo#285018
Payslips now correctly reflect partial-hour time off, so a short absence such as 2 hours is no longer counted as a full day. The fix also prevents duplicate or excessive worked-day lines when several time types occur on the same day, improving payroll accuracy.
Original PR description
When creating a time off type based on hours, and setting a time off of 2 hours for example, in the worked day lines of the payslip, these 2 hours would turn into a full day. Moreover, when more than 2 time types were set for the same day, too many lines would show, making the computation wrong. __ task-6450001
This change removes an earlier workaround for return deadline date color contrast because a separate update already fixed the underlying issue. It helps keep the accounting reports interface consistent and avoids conflicting visual changes.
Original PR description
This reverts commit d2b55b42c0ffb5515faee4b77486bd4da6c93d58. Reason: the fix conflicted with this other commit https://github.com/odoo/enterprise/commit/64b1482a12605aa460324df904df2c8816fdc616 which solved the root caused of the contrast issue.
The AI website feature now uses the updated shared icon search system after icon information was moved in the platform. This keeps icon selection working correctly and avoids unnecessary searching once a match is found.
Original PR description
[FIX] ai_website: adapt to the moved icon index --- The icon metadata moved to `web/icons.py`, next to the fonts it describes, and its index is now private behind a `search_icons()` generator: `_find_icon_by_keywords` no longer has to reach into an html_editor controller for `MS_ICONS_INDEX`, nor restate what makes an icon match. It also stops scanning the whole set once it has its first hit. + Community PR: odoo/odoo#286248
Button groups in dark mode now show visible separation between secondary buttons instead of appearing merged together. This improves visual clarity and keeps the interface more consistent between light and dark modes.
Original PR description
After the frost reskin, btn-groups in dark mode appeared united, since we were using a background color that is the same as the border color. This commit makes the secondary buttons in dark mode use the same design as in light mode, which fixes the border issue in btn-groups while making the interface more consistent in both color modes. COM: https://github.com/odoo/odoo/pull/286452 task-6519485 | Before | After | |--------|--------| | <img width="353" height="53" alt="Screenshot 2026-09-04 at 09 17 34" src="https://github.com/user-attachments/assets/5529404c-c6dc-4ebb-bee6-2ff418cd9510" /> | <img width="345" height="52" alt="Screenshot 2026-09-04 at 09 17 04" src="https://github.com/user-attachments/assets/8fb1c2d7-e399-4fce-ab34-79fc886547e0" /> |
This fix ensures kitchen preparation tickets from self-ordering are sent through the correct printing route depending on how the order was placed. Mobile self-orders use OBOX, while kiosk and point-of-sale orders use the local printer connection, helping avoid missed or misrouted preparation tickets.
Original PR description
Ensures that preparation tickets are printed from the correct channel. - Mobile Self Order => via OBOX - Kiosk Self Order => via local IP - Point of Sale => via local IP Behavor of the self-ordering…
Ensures that preparation tickets are printed from the correct channel. - Mobile Self Order => via OBOX - Kiosk Self Order => via local IP - Point of Sale => via local IP Behavor of the self-ordering preparation process depending on the payment status and the configuration of the PoS. Self Order mobile (always printed via OBOX): - EACH PAID: If an order is created and paid, it should create a prep order directly from the Self Order (via OBOX or preparation display) - EACH UNPAID: If an order is created and unpaid, it should also create a prep order directly from the Self Order if there is NO available payment method (via OBOX or preparation display) - MEAL PAID: If an order is created and paid, it should create a prep order directly from the Self Order (via OBOX or preparation display) - MEAL UNPAID: If an order is created and unpaid, it should also create a prep order directly from the Self Order (via OBOX or pdis) Self Order kiosk: - EACH PAID: If an order is created and paid, it should create a prep order directly from the Self Order (local IP or preparation display) - EACH UNPAID: If an order is created and unpaid, it should create a prep order directly only if there is NO available payment method (via local IP or preparation display)
The time off summary now counts absences only for the relevant year instead of combining records from multiple years. This prevents inflated totals and helps payroll or HR teams review yearly leave balances accurately.
Original PR description
Steps to reproduce: - Create a sick time off for employee A in 2025 - Create a sick time off for employee B in 2026 - In the view form of the time off created, summary 2026 shows 2 days Current Summary 2026 show all years summary -> 2 days Expected Summary 2026 should only show the current year time summary -> 1 day task-6445187
The spreadsheet pivot menu now shows the global filter option only when it applies to pivot header cells. This prevents users from seeing an irrelevant action on regular pivot formula cells, reducing confusion when working with spreadsheet reports.
Original PR description
The context menu (and clickable cell) `use_global_filter` should take the value of the underlying pivot formula, and apply it to the matching global filters. This works, but was supposed to work only for `ODOO.PIVOT.HEADER` formulas, and not simple `ODOO.PIVOT` formulas. This commit fixes the visibility of the `use_global_filter` option in the context menu, so that it is only visible for `ODOO.PIVOT.HEADER`. Also removed/changed tests that were testing that the menu was visible for positional `ODOO.PIVOT` formulas. Task: [3714696](https://www.odoo.com/web#id=3714696&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes a settings issue where creating a new order-related email template without the right default type could later break payment processing after checkout. New templates created from website sales settings now use the proper business document type, helping orders, invoices, and ratings emails work reliably.
Original PR description
Currently, an error occurs when the scheduled action `Payment: Post-process transactions` attempts to post-process a payment after performing the following steps: - Install `website_sale` with demo…
Currently, an error occurs when the scheduled action `Payment: Post-process transactions` attempts to post-process a payment after performing the following steps: - Install `website_sale` with demo data - Enable payment provider `Demo` for testing - Go to Settings and search for `Order Confirmation` - Under Email, enter a template name that does not exist (e.g., `Test`) - Click `Create "Test"` and save the settings - Go to the website shop, place an order, and complete the payment Error: `KeyError: False` Error when user selects `model_id(Applies_to)` as `journal_entry` in the above `Test` template: ``` odoo.exceptions.MissingError: Record does not exist or has been deleted. (Record: account.move(1,), User: 1) ``` The issue occurs because clicks `Create "Test"` creates a `mail.template` record without setting the required `model_id` field. As a result, `render_model` remains empty, causing an error when `self.env[self.render_model]` is accessed (see code [1] and [2]). This commit fixes the above issue by setting `default_model` to `sale.order` in the context, ensuring the correct model is set when a user creates an `Order Confirmation` email template. The same change is also applied to the invoice and rating email templates to ensure the appropriate model is provided when creating each template. [1]: https://github.com/odoo/odoo/blob/bb94f13b38f0bf1ce8886f4630ad42caf6c56325/addons/mail/models/mail_render_mixin.py#L739 [2]: https://github.com/odoo/odoo/blob/bb94f13b38f0bf1ce8886f4630ad42caf6c56325/addons/mail/models/mail_template.py#L125-L128 Sentry-7634490774,7635560002
The website header blur effect was adjusted so it no longer disrupts mobile menus on some browsers. Visitors keep the same visual blur experience while mobile navigation opens without shrinking or altering the page layout.
Original PR description
The header blur feature introduced in commit [1] applied backdrop-filter directly on header nav elements. On mobile, the offcanvas menu is a fixed-position descendant of the navbar. Some mobile browsers treat a filtered ancestor as a containing or painting context for fixed descendants, which can make the offcanvas affect the page width or shrink the page layout when the menu opens. The navbar blur now lives on a pseudo-element layer instead of the nav itself, while the mobile offcanvas keeps its own blur. This preserves the visual effect without making the navbar a filtered ancestor of the offcanvas. [1]: https://github.com/odoo/odoo/commit/4eb9d96d68a33bed721692ec81de4a00425e83e3
Payroll administrators can now use payroll warning actions to configure company and contract-related settings without needing full database administrator rights. This removes access errors during routine payroll setup tasks such as payslip layout customization and contract benefit management.
Original PR description
Issue: A payroll admin without DB administrator role gets access errors upon attempting to configure their company/contracts via the payroll warning buttons. Fix: `sudo` operations and flows which intersect with a Payroll Admin's routine tasks (customizing the payslip layout which required downstream access to `ir.ui.view`, similar issue in managing contract benefits, etc.). Now the Payroll Admin can thrive! task-id: 6348187
POS preparation screens now show decimal quantities rounded according to the configured Product Unit precision. This prevents confusing numbers like 5.070000000000001 from appearing on preparation displays and printed tickets, making order quantities clearer for staff.
Original PR description
Steps to reproduce: - Open a POS session and create an order with decimal quantities (e.g. 1.25). - Send the order to preparation. - Reopen the order in POS, increase the quantity (e.g. to 6.32), and send again. - In the preparation display (orderlines and category summary), floating-point arithmetic artifacts appear (e.g. 5.070000000000001x or 0.30000000000000004). Cause: Floating-point subtraction and accumulation (such as `quantity - cancelled` or sum of product quantities in categories) precision inaccuracies. In addition, quantities were displayed without taking into account the configured "Product Unit" decimal precision. task-id: 6531109
Spanish accounting reports now use the saved invoice and tax regime details on each posted invoice, so user choices are preserved and official exports are more accurate. Amazon sales and real estate reporting were updated to match the latest Spanish localization data model, reducing errors after the underlying field change.
Original PR description
l10n_es dropped the l10n_es_is_simplified boolean in favour of storing l10n_es_invoice_type (F1/F2/R1-R5, encoding "simplified" through its own selection values) and l10n_es_regime_code directly on…
l10n_es dropped the l10n_es_is_simplified boolean in favour of storing l10n_es_invoice_type (F1/F2/R1-R5, encoding "simplified" through its own selection values) and l10n_es_regime_code directly on account.move, both editable by the user and frozen once the move is posted. These three enterprise modules still read the removed field, or duplicated logic that the move itself now already computes and stores. l10n_es_reports: `_l10n_es_libros_get_operation_code` and `_l10n_es_libros_get_invoice_type` used to re-derive the AEAT operation code and invoice type from the move's taxes/is_simplified flag on every report run, ignoring any manual override a user made after posting. Read `l10n_es_regime_code`/`l10n_es_invoice_type` straight off the move instead. This changes two report tests: the OSS/DUA fixtures now carry their own l10n_es_regime_code (as real OSS taxes do via l10n_eu_oss.EU_FIELD_MAP), and the purchase-refund libros export now reports 'R4' instead of the previously hardcoded 'R1', matching what the move's own compute freezes. Add a regression test asserting a manually-picked regime code survives action_post(). l10n_es_sale_amazon: port the amazon-order override from `_compute_l10n_es_is_simplified` (removed) to `_compute_l10n_es_invoice_type`, forcing 'F2'/'R5' the same way it used to force the boolean to True. l10n_es_real_estates: rename `cadastral_reference` (the '1'-'4' BOE location selection) to `real_estate_location`, freeing the old field name for a genuine Char cadastral reference. Mod. 347 generation is updated to read the location from its new field name. task-6175455
Asset values now ignore tax lines when calculating purchase amounts, preventing non-deductible taxes from being counted twice. Users also get clearer guidance in the asset form and selection screens, reducing mistakes when linking vendor bill lines.
Original PR description
- Exclude tax lines from `related_purchase_value` computation to prevent double-counting non-deductible taxes when manually linked in the Bills tab. - Display a muted tax-excluded purchase value label next to the Asset Value on the form view to provide clarity when non-deductible taxes are present. - Update the XML domain on `original_move_line_ids` to hide tax lines from the selection wizard, preventing users from selecting them. - Add a unit test to ensure `original_value` correctly ignores explicitly linked non-deductible tax lines. Task-6518421
The Indian e-invoicing check now opens a list only when missing e-invoices are actually found, and that list is limited to the specific affected invoices. This prevents users from seeing unrelated or misleading invoice results during compliance checks.
Original PR description
The `missing_einvoice` check passed custom `views` but no explicit `domain`, so its action ignored the `moves` recordset and instead opened all matching `account.move` records — an unfiltered list when no invoices were missing, and every eligible invoice (not just the flagged ones) otherwise.
Guard the action to only build when `moves` is non-empty, and pass `domain=[('id', 'in', moves.ids)]` so it's always scoped to the invoices actually found.
task-6544790
Forward-Port-Of: odoo/enterprise#130483The web code editor now correctly allows protected attributes in self-closing QWeb tags to be overwritten or deleted when appropriate. This prevents unnecessary editing restrictions and makes template editing behave consistently for users.
Original PR description
Currently, when we get readonly attributes to prevent overwriting or deletion, we only ignore them if the selection that is being modified is contained between `<>` tags. To rectify this behavior, we also include the `<\>` self closing tags so that they may also be overwritten/deleted. opw-6325841 Forward-Port-Of: odoo/odoo#287393
The Turkish e-Ledger export now fills line numbers automatically and keeps them continuous across monthly filings within the fiscal period. Entries are exported from oldest to newest, helping businesses meet GIB expectations and avoid manual corrections after export.
Original PR description
Before: the `LineNumber` column of the e-Ledger CSV was always empty, left to be filled after the export. Since the ledger is filed monthly, whatever filled it restarted at 1 every month, while GİB expects the numbering to start once, at the beginning of the fiscal period, and to run unbroken until its end. Now: the column is written by the export. An export starting after the first day of the fiscal period is offset by the number of rows that period already counts, so February continues where January stopped, and a full-year export numbers the same rows identically. The lines are also read in ascending date order. They were sorted by the default order of `account.move.line`, the most recent first, so the first row of the file was the last entry of the period and could not be numbered 1. This reverses `EntryNumberCounter` as well, which now counts from the oldest entry. task-6424730 Forward-Port-Of: odoo/enterprise#130923 Forward-Port-Of: odoo/enterprise#127518
Odoo now recognizes five new response codes introduced by Chile's tax authority for supplier electronic documents. This prevents affected documents from getting stuck and restores the expected acceptance and claim workflow.
Original PR description
**Before this PR:** After the implementation of Resolution 161 of November 13th 2025, SII responses included keys not supported by the current l10n_cl_edi implementation. This resulted in supplier DTEs not being processed as they were before the change, because the five new keys were not found in Odoo's current `l10n_cl_claim` field, causing that the documents with these responses, were kept in a loop not solved. **After this PR:** The five new values from the resolution, along with their translations, were added to the selector field, fixing the process flow. **SII Reference:** https://www.sii.cl/normativa_legislacion/resoluciones/2025/reso161.pdf (see Event Code, page 5) Forward-Port-Of: odoo/enterprise#121833
The Timesheet Assistant now avoids using partners that do not have an email address when generating sample data. This prevents a crash and lets users continue creating sample timesheet data reliably.
Original PR description
Forward-Port-Of: odoo/enterprise#131002
Codaclean payroll document labels and related settings have been renamed from SODA to CODB to match the correct file type. This reduces confusion for Belgian payroll users and keeps Codaclean terminology distinct from Codabox SODA files.
Original PR description
CODB files are the payroll documents that are used for codaclean, they are the equivalent for SODA files from codabox. This pr should rename the files, functions, etc for codaclean so that it is CODB instead of SODA. task-6543478
Property definition fields no longer show an empty input box on mobile when there is no value to display. This removes a confusing visual artifact and makes the form layout clearer for users on smaller screens.
Original PR description
- Definition widgets already omit PropertyValue, but the leftover value wrapper was still drawn as an input box on mobile. Remove that wrapper and apply the mobile field-box layout only when a value node exists. task-6542816
Checkout now works correctly when a promotion adds a free reward product to the cart, even if zero-priced products are normally blocked. This prevents eligible customers from being sent back to the cart unnecessarily and keeps promotional offers usable online.
Original PR description
As of commit b8e790b2, a cart containing a product priced at 0 while the website forbids the sale of zero-priced products is no longer payable: the customer is redirected back to the cart with a warning. Reward lines were caught by that new rule. A promotion offering a free gift whose product has no sale price adds a reward line priced at 0 to the cart, so the whole cart became unpayable even though nothing was wrong with it. This commit excludes reward lines from the zero-priced rule, the same way delivery lines already are. opw-6526396 Forward-Port-Of: odoo/odoo#287232 Forward-Port-Of: odoo/odoo#286464
This change makes an internal web-related test run consistently instead of failing unpredictably. It helps keep automated quality checks stable, reducing false alarms during development without changing customer-facing behavior.
Original PR description
[runbot-947020](https://runbot.odoo.com/odoo/runbot.build.error/947020) 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#287463
This fix makes Odoo's PDF tools expose a shared PDF page component consistently across supported PDF library versions. It helps prevent automated test failures caused by differences between installed PDF libraries, improving reliability for maintenance and upgrades.
Original PR description
Prior to this commit, `PageObject` was not re-exported by `odoo.tools.pdf`, forcing tests to patch internal module paths like `PyPDF2._page.PageObject`. This resulted in test failures depending on the installed PDF library version: - `pypdf` (>= 3.0.0): `PyPDF2` submodules no longer exist. - `PyPDF2` 1.x: `PageObject` resides in `PyPDF2.pdf` rather than `PyPDF2._page`. To resolve this, this commit re-exports `PageObject` through `odoo.tools.pdf` across all backend wrappers. runbot-946795 Forward-Port-Of: odoo/odoo#287298 Forward-Port-Of: odoo/odoo#285978
The AI agent's “snappy and creative” response style now uses a lighter reasoning setting, making it more distinct from the standard style. This helps align AI behavior with the selected response tone and avoids unnecessary processing for shorter, more creative replies.
Original PR description
Prior to this commit, the response style `snappy_and_creative` configuration for agent has been using the same reasoning level as the `standard` response style. With the response style instructions being dropped in prior commit, we now lower the reasoning from `standard` to `minimal` (`none`) so that it reflects better its category, and so that we have a proper distinction between different response style. Forward-Port-Of: odoo/enterprise#129804
This fix ensures the company's designated project folder cannot be archived by mistake. It protects an important Documents and Projects configuration from being disabled, helping teams avoid disruptions when managing project files.
Original PR description
The company's project folder is supposed to be [impossible](https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/documents_project/models/documents_document.py#L44) to archive, by using the `_unlink_except_company_folders` logic. However, the method that adds the company field to the list of fields to check was missing, so it was still possible to archive a folder set as projects folder. Forward-Port-Of: odoo/enterprise#120605
Point of Sale receipts generated by the backend now use the configured printer paper width and resolution, preventing scaling issues and cut-off content. Receipt layouts were also adjusted for narrow printers so key information such as QR codes and company details remains readable.
Original PR description
..., l10n_tw_edi_ecpay_pos, pos_self_order, pos_iot_six --- Backend receipts were always generated using the same dimensions, regardless of the paper size configured on the receipt printer. This could produce incorrectly scaled receipts or content that did not fit the available width. Mirror the frontend printer-specific widths and font sizes when rendering the receipt on the backend. Generate the downloaded receipt as a PDF using the printer's printable width and resolution so its physical size is preserved. Also adapt receipt sections for narrow printers to prevent the QR code and company information from overlapping. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6171565
Backend-generated receipts now use the configured printer paper width and resolution, helping printed or downloaded receipts keep the correct physical size. Narrow printer layouts were also adjusted so QR codes and company details no longer overlap.
Original PR description
..., l10n_tw_edi_ecpay_pos, pos_self_order, pos_iot_six --- Backend receipts were always generated using the same dimensions, regardless of the paper size configured on the receipt printer. This could produce incorrectly scaled receipts or content that did not fit the available width. Mirror the frontend printer-specific widths and font sizes when rendering the receipt on the backend. Generate the downloaded receipt as a PDF using the printer's printable width and resolution so its physical size is preserved. Also adapt receipt sections for narrow printers to prevent the QR code and company information from overlapping. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6171565
This fix prevents an error when a milestone is added to a Time Off accrual plan that was originally created without milestones. Employees and HR users can now create related time off requests without the system blocking the save due to missing accrual tracking data.
Original PR description
## Steps to Reproduce: - Install the Time Off module. - Create an Accrual Plan without any milestones. - Create an Accrual Allocation using the newly created accrual plan. - Approve the allocation. -…
## Steps to Reproduce: - Install the Time Off module. - Create an Accrual Plan without any milestones. - Create an Accrual Allocation using the newly created accrual plan. - Approve the allocation. - Add a milestone to the accrual plan. - Create a new Time Off request after the allocation start date. - Save the record. ## Error: `TypeError - '>' not supported between instances of 'datetime.date' and 'bool'` ## Cause: `lastcall` is initialized by method `_add_lastcalls()`, which is only called at create and write. When an accrual allocation is created with an accrual plan that has no milestones, `_add_lastcalls()` returns early because `level_ids` is empty, leaving `lastcall` set to `False`. - [1] If a milestone is added later, `lastcall` is compared with `first_level_start_date`, resulting in a comparison between boolean and datetime, which raises an error. ## Fix: When `lastcall` is not set, default it to `first_level_start_date`. [1] - https://github.com/odoo/odoo/blob/27036bea232572ba692fbb95387911eb453266bf/addons/hr_holidays/models/hr_leave_allocation.py#L703-L706 sentry-7615375197 Forward-Port-Of: odoo/odoo#287331 Forward-Port-Of: odoo/odoo#280674
This fixes an internal event portal test that could fail when subscription demo data was installed. The test now assigns the correct salesperson when creating a sales order, preventing unintended access-right conflicts and improving reliability.
Original PR description
Purpose ======= Fix the event "test_portal_access" test where the sales order creation would raise an access error when 'sale_subscription' is installed. Specification ============= The demo data in 'sale_subscription' assigned 'Mitchell Admin' as sales person for 'partner_portal'. As the 'user_id' field wasn't specified when creating the sales order in the test, the '_compute_user_id' method would assign the 'partner_portal' sales person, aka mitchell admin, as 'user_id'. This assignation made the 'sale_order_personal_rule' security rule fail as the user 'user_sales_salesman' isn't the partner 'user_id' anymore and doesn't have the right to create a sales order for that partner. => Fixing that by making sure the 'user_id' of the sales order is correctly set to 'user_sales_salesman' on creation to prevent the compute from messing up the rights. Task-6560355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Point of Sale settings from adding a manager's employee record from the wrong company when saving a PoS configuration in a multi-company setup. It helps keep employee access lists accurate for each company and avoids cross-company data being linked by mistake.
Original PR description
Steps to reproduce: - multi-company database, PoS Manager user with an employee in each company - current company set to company A - open the settings of a PoS configuration belonging to company B…
Steps to reproduce: - multi-company database, PoS Manager user with an employee in each company - current company set to company A - open the settings of a PoS configuration belonging to company B and save Issue: The advanced_employee_ids of company B's PoS now also contains the manager's employee of company A, an employee from another company. Cause: res.config.settings.create() appends the PoS managers' employees with `_get_group_pos_manager().user_ids.employee_id`. res.users.employee_id is computed for the current company (self.env.company), not for the company of the pos.config being edited, so the employees of the active company are linked instead of the PoS company's. pos.config.write() already resolves them with `with_company(config.company_id)` since fccccf6cabe5, but the settings path was left unscoped. Fix: Resolve employee_id with `with_company(config.company_id)` in the settings create, as done in pos.config.write(). Single-company databases are unaffected. opw-6544518 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287182
Odoo now checks purchase and outgoing receipts for duplicates in the same way it already checks vendor bills and customer invoices. This helps prevent accidental duplicate accounting documents, reducing cleanup work and the risk of incorrect records.
Original PR description
Right now a duplicate is detected if it's a bill, but is not when you switch it to a receipt. This fix makes sure that both bills and purchase receipts duplicates are detected and are checked against each other. The same change is done for invoices and outgoing receipts. task-6115836 Forward-Port-Of: odoo/odoo#287261 Forward-Port-Of: odoo/odoo#279455
This fixes an issue where Belgian payroll employment bonuses could be calculated incorrectly when corrections were made. The change helps ensure more accurate payslips and payroll results for affected employees.
Original PR description
In case of correction, the employment bonus was wrongly computed. This commit fixes the issues with a more generic approach. Forward-Port-Of: odoo/enterprise#130711 Forward-Port-Of: odoo/enterprise#130158
Colombian point-of-sale receipts now include the DIAN tax authority information required for proper receipt display. This fixes missing compliance-related details on customer receipts generated from the POS.
Original PR description
Receipts are now generated in POS using the `generateReceiptData` function. This commit extends this function and adds all the data necessary to properly show the receipt in Colombian POS. opw-6414901 Forward-Port-Of: odoo/enterprise#130677 Forward-Port-Of: odoo/enterprise#112881
Payroll users can now open the eco vouchers wizard from any payroll batch that includes eco vouchers. The wizard now only shows employees who have eco voucher payslips in that specific batch, reducing confusion and preventing incorrect employee selection.
Original PR description
Allow to open the eco vouchers wizard from any payrun that contains eco vouchers. Also, this commit limits the wizard to the employees that have a payslip with eco vouchers in that specific batch. Forward-Port-Of: odoo/enterprise#130712 Forward-Port-Of: odoo/enterprise#130450
Delivery addresses can now keep their own Global Location Numbers instead of having one address overwrite another. This prevents incorrect location identifiers when a customer has multiple delivery locations.
Original PR description
**PROBLEM** EAN_GLN partner identifier is synced (because partner identifiers are synced by default). Meaning you can only have one GLN on a contact and delivery address sub-contact. However, it's common to have multiple delivery location for a contact, which should each have their Global Location Number. **STEP TO REPRODUCE** 1. Install account_edi_ubl_cii. 2. Create a contact. 3. On this contact, create a first delivery address contact with a GLN. 4. Create a 2nd delivery address contact with a different GLN. 5. Notice that: - On the contact, there is a new field appearing EAN/GLN with the 2nd GLN. - The GLN on the 1st delivery address contact has been replaced by the 2nd GLN. expected behavior: - 1st delivery address GLN should not be replaced. opw-6462252 Forward-Port-Of: odoo/odoo#283004
On mobile devices, opening a full-screen image preview now hides the editor toolbar and dismisses the keyboard. This keeps the preview controls accessible, making image viewing and editing smoother for users.
Original PR description
When displaying the full screen image preview lightbox on mobile, the toolbar remains displayed. Because of this, the toolbar of the lightbox cannot be accessed. This commit hides the toolbar when a lightbox is displayed. task-6370220 Forward-Port-Of: odoo/odoo#287268 Forward-Port-Of: odoo/odoo#274949
Sold-out event tickets are now correctly reported as unavailable instead of being treated as if more tickets could still be ordered. This prevents future checkout or registration flows from showing incorrect purchase limits for fully booked ticket or time-slot combinations.
Original PR description
### Steps to reproduce: event = env['event.event'].create({ 'name': 'Repro Event', 'date_begin': '2026-09-01 08:00:00', 'date_end': '2026-09-01 18:00:00', }) ticket =…
### Steps to reproduce:
event = env['event.event'].create({
'name': 'Repro Event',
'date_begin': '2026-09-01 08:00:00',
'date_end': '2026-09-01 18:00:00',
})
ticket = env['event.event.ticket'].create({
'event_id': event.id,
'name': 'VIP',
'seats_limited': True,
'seats_max': 1,
})
env['event.registration'].create({
'event_id': event.id,
'event_ticket_id': ticket.id,
'name': 'Attendee 1',
'state': 'open',
})
ticket.seats_available -> 0
ticket.is_sold_out -> True
result = ticket._get_current_limit_per_order(event=event) print(result) # {ticket.id: 30} -- expected {ticket.id: 0}
### Issue and Expected
`_get_current_limit_per_order()` used `if not seats_available:` to detect the "no limit" case returned by `_get_seats_availability()`. That check is truthy for both `None` (genuinely no limit) and the integer `0` (fully booked), so a sold-out ticket/slot combination was incorrectly treated as unlimited and returned `limit_max_per_order or EVENT_MAX_TICKETS` (e.g. 30) instead of `0`.
### Fix
`_get_seats_availability()` explicitly documents `None` as the "no limit" sentinel, with `0` meaning "constrained, zero seats left". Use `seats_available is None` to preserve that distinction instead of a falsy check.
No functional regression was found in the current website_event flow: sold-out slots/tickets are filtered or re-derived independently before reaching this value in every existing UI path. This fixes the underlying contract of the method itself, so future or additional callers don't inherit the wrong value.
https://github.com/odoo/odoo/issues/284098
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#284100German Intrastat dispatch reports now use the required region code 99 when goods originate outside Germany. The update also improves German exports by handling local number formatting correctly and rounding net mass consistently, reducing reporting errors and compliance risk.
Original PR description
### Issue: In Germany, the intrastat report requires region code `99` for dispatch moves where the product origin country is not DE Per the official specification (section 5.8 — Region of origin):…
### Issue: In Germany, the intrastat report requires region code `99` for dispatch moves where the product origin country is not DE Per the official specification (section 5.8 — Region of origin): "As for goods with foreign origin, code '99' should be entered" https://erhebungsportal.estatistik.de/Erhebungsportal/api/assets/files?downloadId=0c5422f111104705b021b41616ad1ecc But `99` was not being used in those cases ### Cause: `99` was already the default fallback when no `region_code` is set but `_fill_missing_values` had no condition to override the region code for dispatch moves with a non-DE origin country ### Notes: While fixing this, two additional issues were found when exporting with the German locale (`de_DE`): - `weight` and `supplementary_units` are formatted with a comma as decimal separator by the German locale, causing `float()` to raise a `ValueError` — fixed by normalizing to dot before conversion, as done in other localizations - The dispatch/arrival check was comparing against the translated label (e.g. `'Versand'`) instead of a stable identifier A new `intrastat_type_code` field with static values `arrival` and `dispatch` is added based on the existing `id` values from `default_type`, avoiding locale-dependent comparisons This improvement could be extended to other localizations - Net mass is now rounded to full kilograms per item (see §5.14 of the specification linked above) A weight rounding down to 0 kg is reported as `0` instead of being silently dropped (QWeb `t-out` omits the element when the value is `None`) Totals are computed as the sum of already-rounded per-item values to stay internally consistent ### Steps to reproduce: - Install `sale_management`, `l10n_de_account` and `accountant` - Switch to the DE company - In Settings, configure the Intrastat values: -- Default invoice transaction code: 11 -- Default refund transaction code: 21 -- Intrastat region: 07 - Create 3 products with a commodity code set and country of origin: one DE, one empty, one other country - Create and confirm a Sale Order for all products with a European partner, deliver all, create and send the invoice - Open the Intrastat report (Accounting > Reporting > Taxes & Fiscal > Intrastat) - Set the month to the current month Before the fix, all regions show 07 Expected: non-DE origin products should show 99 opw-6455585 Forward-Port-Of: odoo/enterprise#128747
This fix ensures the restaurant table opens only after the German POS certification update has finished. It prevents staff from being blocked or seeing delayed table access when orders are synchronized with Fiskaly.
Original PR description
In this commit: ------------------ - The API call is triggered when an order is updated in Fiskaly. - Previously, the request could be awaited while opening a table, blocking the table from opening before the product screen was ready. - Now, the request is awaited before allowing the table click, ensuring the table opens only after the request is completed. Task: 6522079 Forward-Port-Of: odoo/enterprise#130896 Forward-Port-Of: odoo/enterprise#130132
This fixes a test issue in the mail testing module where large user ID numbers could be displayed differently than expected. The change helps prevent false test failures when running the full test suite, improving reliability without affecting end users.
Original PR description
When calling message_post() with custom tracking_values, the new_value field is rendered verbatim by the QWeb template into the message body. Automatic tracking (mail_track_mixin) already formats integers via formatLang before setting new_value, but the test was passing a raw integer (self.env.uid), causing a mismatch with the formatted value expected by assertTrackingValueInBody. This only manifests when uid >= 1000.
Step to reproduce:
- Create a db with test_mail installed
- run `psql <db_name> -c "SELECT setval('res_users_id_seq', 1234, true);"` (to forcefully increment the sequence)
- launch the test_track_multi_models test
The test will fail due to this sequence increment when the test suite in ran fully (without splits like on runbot).
Forward-Port-Of: odoo/odoo#286256Spreadsheet exports now wait until required map data has finished loading before generating the file. This prevents exports from missing geo chart information and improves reliability for spreadsheet dashboards that use maps.
Original PR description
We need to wait for the geo json to be loaded before trying to export the spreadsheet data. Task: [4632983](https://www.odoo.com/web#id=4632983&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Argentinian electronic export invoices now use the correct recipient identification code in their QR validation data. This prevents ARCA from showing the wrong ID type and allows customers to verify export invoices as valid legal documents on the official ARCA page.
Original PR description
Before this change we were sending id type code 0 and this generate two problems * ARCA verification page it was wrongly taking "CI Policia Federal" as the identification type of the receptor * We were not able to validate the expo invoice, we get always an error With this change the expo invoice can be checked as a real legal document in the ARCA page https://servicioscf.afip.gob.ar/publico/comprobantes/cae.aspx Forward-Port-Of: odoo/enterprise#126704
Spreadsheet and dashboard printing now uses a dedicated print view, reducing issues such as unexpected blank pages. This makes printed spreadsheets more consistent and less likely to be affected by unrelated page layout changes.
Original PR description
### [REF] spreadsheet(_dashboard): print using an iframe Printint a spreadsheet was a bit broken, empty pages would show up in the result. Now we print a spreadsheet using an iframe, which means that we have full control on what's printed and can remove all of the css used to hide elements when printing. It is a huge impovement bacause now a change in the css/layout somewhere in the page will not break the print anymore. Task: [6466136](https://www.odoo.com/web#id=6466136&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet printing has been changed to use a dedicated print area, preventing unwanted blank pages from appearing. This makes printed spreadsheets more consistent and reduces the chance that unrelated page layout changes will break printing in the future.
Original PR description
Printint a spreadsheet was a bit broken, empty pages would show up in the result. Now we print a spreadsheet using an iframe, which means that we have full control on what's printed and can remove all of the css used to hide elements when printing. It is a huge impovement bacause now a change in the css/layout somewhere in the page will not break the print anymore. Task: [6466136](https://www.odoo.com/web#id=6466136&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Mentions in Facebook and LinkedIn social posts are now matched more reliably and linked to the correct profiles. This prevents malformed or duplicated mention text after publishing, improving the accuracy of social content shown in Odoo.
Original PR description
This commit fixes an issue with the mention regexes for social_facebook as they weren't properly replaced by the initial mechanism. The initial mechanism was introduced by [1]. Now, we check every possible mention and if it is indeed a known mention, then we replace it by the correct link to their profile. [1]: https://github.com/odoo/enterprise/commit/4dacc5fce72687680080f75feef875fbfb3dbd15 task-6026857 Forward-Port-Of: odoo/enterprise#130095
The Sign app's internal signing information service was reorganized into a newer plugin structure while keeping the old service available for compatibility. This should not change day-to-day signing behavior, but it helps maintain the feature and prepare it for the newer interface framework.
Original PR description
We rewrite the signInfo service as a plugin.
For legacy purposes, we keep the signInfo service (as a service).
`signInfoService` has been converted to an OWL3 Plugin, so existing
useService("signInfo") call sites need to be rewritten.This update modernizes internal user interface components across several Odoo apps by replacing an older component configuration pattern. It helps keep the platform compatible with the latest frontend framework standards and improves validation behind the scenes, with no expected change to day-to-day user workflows.
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 modernizes internal interface code across accounting, delivery, and related business apps to align with the latest framework standards. It improves long-term maintainability and validation without changing day-to-day user workflows.
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 modernizes internal screen components used across Documents and related business apps so they align with the latest Odoo interface framework. It improves maintainability and validation behind the scenes without changing day-to-day workflows for users.
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 reorganizes where inventory valuation and accrual account settings are managed, making accounting configuration more consistent across purchasing, sales, stock, manufacturing, and point of sale flows. It also improves performance for some Chilean electronic invoicing valuation calculations by avoiding repeated account lookups.
The grid view components were internally updated to use the newer validation approach required by the platform. This helps keep timesheet and grid-related screens maintainable and ready for future framework updates without changing user-facing 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 change relocates existing spreadsheet-related tests into the spreadsheet module. It does not change user-facing functionality, but it helps keep quality checks closer to the area they validate, making future maintenance more reliable.
Original PR description
Task: [4074487](https://www.odoo.com/web#id=4074487&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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 spreadsheet library was reorganized so it loads in a way that better supports Odoo's testing tools. This reduces the risk of test data mixing between editions and helps keep spreadsheet features more reliable over time.
Original PR description
Change the o_spreadsheet library from an IIFE to an ESModule. This is done because hoot doesn't support IIFE (the library is only loaded once, and the registries are filled with enterprise data in community tests). Task: [3995327](https://www.odoo.com/odoo/2328/tasks/3995327?cids=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spanish electronic invoicing now uses one shared invoice type and VAT regime setup across SII, TicketBAI, Veri*Factu and related POS flows. This makes values visible and correctable before posting, then preserves them after posting so reported invoices do not change unexpectedly if tax settings are later updated.
Original PR description
Before this, SII, TicketBAI and Veri*Factu each re-derived a move's "TipoFactura" (F1/F2/R1-R5) and "ClaveRegimenEspecialOTrascendencia" at send time, from `l10n_es_is_simplified` (a boolean guessed…
Before this, SII, TicketBAI and Veri*Factu each re-derived a move's "TipoFactura" (F1/F2/R1-R5) and "ClaveRegimenEspecialOTrascendencia" at send time, from `l10n_es_is_simplified` (a boolean guessed from partner/amount) and ad hoc, slightly different tax-based rules per EDI. Credit notes needed a manual reason anyway, so each EDI kept its own private field for it (`l10n_es_sii_refund_reason`, `l10n_es_tbai_refund_reason`, `l10n_es_edi_verifactu_refund_reason` + `l10n_es_edi_verifactu_clave_regimen`). None of this was visible or correctable from the invoice before sending, and an already-declared move's values could silently drift if its tax configuration changed afterwards, since they were never actually stored. Both values now live directly on `account.move` as real fields: `l10n_es_invoice_type` (replacing `l10n_es_is_simplified`, since a boolean can't express F2 vs R5 vs a refund reason) and `l10n_es_regime_code`/`l10n_es_regime_code_additional`. They're computed once from the move's taxes and the company's special V regime, editable before posting to correct the odd case the com gets wrong, and frozen once posted so a declared invoice keeps what was sent regardless of later changes elsewhere. `account.tax` gets a matching `l10n_es_regime_code`, filled fro tax's own chart-template data instead of re-derived from its ty amount at report time. `l10n_es_applicability` (the tax's AEAT Impuesto: VAT/IPSI/IGIC) moves from `l10n_es_edi_verifactu` to alongside it, since it's a property of the tax itself, not of one EDI's document format, and `l10n_es`'s own regime-code catalog already keyed off it. This also fixes a silent gap: `l10n_eu_oss`'s EU_FIELD_ already stamped this field on the OSS taxes it generates, but t only existed when Veri*Factu happened to be installed, so OSS t a plain Spanish company silently lost their applicability. SII/TicketBAI/Veri*Factu no longer maintain their own refund-re field or re-derivation logic: they read `l10n_es_invoice_type`/ `l10n_es_regime_code` straight off the move, and only extend th catalog (`_l10n_es_regime_code_labels`/`_l10n_es_regime_available_codes` on `account.tax`/`res.company`) with the codes their own format each gated behind its own boolean so the EDI's can be installed together in any order without one silently exposing another's c The same `l10n_es_invoice_type` field is reused on `pos.order` TicketBAI/Veri*Factu POS integrations, replacing their own sepa refund-reason fields there too. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies how Odoo handles the visual layering of form stat buttons and related focus styling. It removes unnecessary styling logic, making the interface code easier to maintain without changing the user experience.
Original PR description
The custom property used to stack the states of a stat button had no effect on the cascade: the three states have the same specificity and are already declared in the order of their priority, so the value they set is resolved exactly like a plain z-index would be. Plus in this case, it doesn't improve the performance. The inset focus ring of the "More" dropdown duplicated the value of $focus-ring-box-shadow, with a comment asking for both to be kept in sync. It is now defined next to it, as $focus-ring-inset-box-shadow, so that the ring follows $focus-ring-width, $focus-ring-blur and $focus-ring-color on its own. task-6528444 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 change updates internal accounting and related interface components to use the newer Owl component property handling. It helps keep the system compatible with upcoming framework changes while improving validation behind the scenes, with no expected change to day-to-day user workflows.
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 streamlines how command palette options are supplied across several Odoo apps. It is an internal cleanup that should make the code easier to maintain without changing the user experience.
Original PR description
* mail,spreadsheet,test_translation_mode,web,web_tour This commit removes the `env` param of the provide function of command providers. The env still can be retrieved with `useEnv()`.
This update streamlines how command palette actions access application context across Account Reports, AI, AI App, and Knowledge. It is an internal cleanup that should not change day-to-day user behavior, but helps keep the code easier to maintain.
Original PR description
* account_reports,ai,ai_app,knowledge This commit removes the `env` param of the provide function of command providers. The env still can be retrieved with `useEnv()`.
This update removes redundant test helper code and old commented-out test content from the accounting accountant module. It does not change product behavior, but makes the test suite easier to maintain and reduces clutter for future development.
Original PR description
This commit cleans up the test suite within the `account_accountant` module by removing redundant methods and old commented code. no-task Forward-Port-Of: odoo/enterprise#130857 Forward-Port-Of: odoo/enterprise#130644
This update refreshes several HR-related app screens to use the newer interface framework standards. It is an internal maintenance change that improves validation and long-term reliability without changing employee-facing workflows.
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
The spreadsheet component now handles clipboard data through a centralized store, improving the internal structure of copy and paste behavior. This is mainly a technical cleanup that should make future spreadsheet maintenance and updates more reliable, with tests adjusted accordingly.
Original PR description
### [REF] spreadsheet: transform the clipboard into a store The `o-spreadsheet` commit tranformet the clipboard into a store. Some test needed to be adapted. Task: [6389205](https://www.odoo.com/web#id=6389205&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet-related automated tests were updated to align with an internal clipboard handling change. This keeps spreadsheet editing, charts, filters, pivots, comments, and sales spreadsheet behavior reliably covered without changing the user-facing workflow.
Original PR description
### [REF] spreadsheet_edition: transform the clipboard into a store The `o-spreadsheet` commit tranformet the clipboard into a store. Some test needed to be adapted. Task: [6389205](https://www.odoo.com/web#id=6389205&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
ERPly S.R.L. has signed Odoo's Corporate Contributor License Agreement. This clears the legal approval requirement for their contribution so related work can continue through the normal review and merge process.
Original PR description
ERPly S.R.L. (Santo Domingo, Dominican Republic) signs the Corporate Contributor License Agreement v1.0. This unblocks the `legal/cla` check on #286565, where every other CI check already passes. Signed by Rob Cruz (rob.cruz@erply.do, @rob-erply), acting on behalf of ERPly S.R.L. Forward-Port-Of: odoo/odoo#286665
Original PR description
Pulling latest translations from Weblate, since the sync failed to merge them.