Thursday, September 10, 2026
79 changes · master
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
Users 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