Thursday, September 10, 2026
39 changes · master
Resolved issues and error corrections
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
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#286460This 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
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
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
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 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
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)
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 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)
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 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
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
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
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
German 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
Spreadsheet 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