…ern pypdf backend

`export_article_to_pdf` calls `writer.setPageMode("/UseOutlines")` on the `PdfFileWriter` instance to make the outline/bookmarks panel visible by default when the generated PDF is opened. the old PyPDF2

`odoo.tools.pdf` picks its backend dynamically it first tries to import PyPDF2==2.12.1  and only falls back to the modern `pypdf` library if PyPDF2 is not importable, which is the case on Python 3.13 per requirements.txt, or on any worker where PyPDF2 failed to install.

The PyPDF2-based writer still exposes `setPageMode`, so the bug was never seen on backends using it. The modern pypdf-based writer replaced that method with a `page_mode` property (getter/setter) and never kept a camelCase alias for it

As a result, any request hitting this code got a beautiful HTTP 500
    `AttributeError: 'BrandedFileWriter' object has no attribute 'setPageMode'`

`setPageMode` is not called anywhere else so
this fixes the call site directly instead of adding a new alias to the shared _pypdf.py

opw-6382905

When creating an employee declaration without selecting an employee, a traceback occurs.

Steps to reproduce the error:
- Install ``l10n_be_hr_payroll`` module with demo data
- Switch to Belgian company
- Go to Payroll > Reporting > Individual Accounts > Create a new Individual Account >
  Click on Eligible Employees > Create a new employee declaration without employee > Save

Traceback:
```py
ValueError: Expected singleton: hr.employee()
```

https://github.com/odoo/enterprise/blob/000544c3d5b93e194264e15bb73d9599525106e3/hr_payroll/models/hr_payroll_employee_declaration.py#L71
The ``_compute_version_id()`` method calls ``_get_version()``.
When ``employee_id`` is empty, ``_get_version()`` is invoked on an empty ``hr.employee`` record,
and its ``ensure_one()`` call raises the above traceback at [1].

[1]: https://github.com/odoo/odoo/blob/3c358ae2badad69b125695a97b4a14e8ab77fccd/addons/hr/models/hr_employee.py#L745-L750

sentry-7625826444

Forward-Port-Of: odoo/enterprise#125175

When submitting payroll data to the ATO from an STP record without any payslips or employees, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_au_hr_payroll_account`` module
- Switch to ``My australian Company``
- Go to Payroll > Configuration > Settings > In Australian Localization, Set BMS ID > Set STP Responsible and his date of birth
- Go to Payroll > Reporting > Single Touch Payroll > Create a new record > Set Payment Date > Submit to ATO > Sign & Submit to ATO

Traceback:
```py
IndexError: tuple index out of range
```

https://github.com/odoo/enterprise/blob/b0e48baaf99bdc4faefd2ffdd3bd5637fb548593/l10n_au_hr_payroll_account/models/l10n_au_stp.py#L228-L233
The traceback occurs because ``_get_fiscal_year_start()`` assumes that the
STP record always contains at least one payslip or one employee.
When these recordsets are empty,
indexing the first element raises an IndexError.

Solution:
This commit validates that the required payslips or employees are present
before the submission and raises a validation error instead of a traceback.

Forward-Port-Of: odoo/enterprise#127733
Forward-Port-Of: odoo/enterprise#124096

Steps to reproduce:
---
- Install `website_sale_collect` without demo data.
- Create and publish a product.
- Add the product to the cart and proceed to checkout.
- Complete the main address.
- Select a `Pick Up in Store` delivery method and click checkout.

Issue:
---
The checkout redirects back to the address form instead of continuing to the payment step.

Root cause:
---
During checkout, `shop/checkout`[1] calls `_check_cart_and_addresses()`, which eventually invokes `_check_addresses()`[2]. That method then calls `_check_delivery_address()`[3] to verify that all mandatory delivery address fields are present.

When db is initialized without demo data, the pickup location address may not contain all mandatory fields (such as ZIP code). As a result, the validation fails and the checkout incorrectly redirects the customer back to the address form, even though the delivery address is a pickup location that should not be edited by the customer.

Solution:
---
Override `_can_be_edited_by_current_customer()` to treat the selected pickup location as a non-editable address. Since the pickup location belongs to the store, it does not make sense to ask the customer to edit or complete its address. This prevents the checkout flow from requesting address completion and allows the customer to proceed directly to the payment step.

[1]https://github.com/odoo/odoo/blob/815de3f1a43bccdb5714436da2060f7a45aa385e/addons/website_sale/controllers/main.py#L1141-L1142
[2]https://github.com/odoo/odoo/blob/815de3f1a43bccdb5714436da2060f7a45aa385e/addons/website_sale/controllers/main.py#L1894-L1895
[3]https://github.com/odoo/odoo/blob/815de3f1a43bccdb5714436da2060f7a45aa385e/addons/website_sale/controllers/main.py#L1945

opw-6394166

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce:
- give a user the Point of Sale / User group only, without any accounting access right
- open a session, sell a product to a customer and ask for an invoice

Issue:
The invoice is created and posted, but it is never reconciled with its payment: it stays fully due even though the journals and the accounts are correctly configured.

Cause:
_reconcile_invoice_payments gathers the lines to reconcile with the rights of the caller and elevates only the final reconcile() call. The payment moves it reads are linked to the order through account.move.pos_payment_ids, while rule_invoice_pos_user restricts a POS user to the moves matching [('pos_order_ids', '!=', False)], so those moves are not readable by a salesperson. Since saas-19.3, base_user_account_move_line_rule adds [('move_id', 'access', 'read')] on account.move.line, which propagates that restriction to the lines: payment_moves.pos_payment_ids.account_move_id.line_ids silently returns an empty recordset. reconcile() then gets the invoice receivable line alone and has nothing to match it with.

_create_payment_moves does return a sudo recordset, but _generate_pos_order_invoice accumulates it into self.env['account.move'] and the union of two recordsets keeps the env of its left operand, so the payment moves reach the helper back in the salesperson's env.

opw-6439389

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, the Chat action of the meeting view could keep its unread dot instead of showing "1" after "Mark as Unread":

    FAILED: [14/21] Tour discuss.meeting_view_tour
    Step .o-mail-Meeting [title='Chat']:has(.badge:contains(1)).
    Element (.o-mail-Meeting [title='Chat']:has(.badge:contains(1)))
    has not been found.
    TIMEOUT step failed to complete within 10000 ms.

This happens because a mark as read carries the id of the newest message the client knew when it requested it, and under load it can reach the server after a newer message was posted. The new message separator then moves back before that message, which makes it unread before the user even asks for it. The click on "Mark as Unread" writes the separator the counter is already computed from, so the counter does not change, and the client, which holds the counter it displays while the user reads the thread, never refreshes it.

This commit moves the new message separator forward only, so reading messages never makes another one unread.

https://runbot.odoo.com/odoo/error/945958

Forward-Port-Of: odoo/odoo#281988

Steps to reproduce:
1. Install CRM
2. Activate the Arabic language with English
3. Create a lead with a new email, a new company name, and the Arabic language
4. Save and try to send a message from the chatter

Issue:
- After the message is sent, the language of Lead is changed to EN from Arabic
- Contacts created with the English language

Cause:
- When we send a message from the chatter of a Lead that has an email_from, a partner_name, and the Arabic language, this forces the creation of a new contact First child contact is created with arabic language, but `parent_name` is present in the creation dictionary, so this triggers `_create_parent_from_name` that builds a dictionary to create the parent company, but it does not pass the language. As a result, the parent company is created with the English language. then `_create_parent_from_name` links the child to this new parent and this linking triggers the `_compute_lang` on the child and overwrites the child's language with the parent's language At last, Lead's own computed field `_compute_lang_id` triggers and sets the language to English

Solution:
- pass the language in the dictionary to create the parent company

opw-6449407

Forward-Port-Of: odoo/odoo#281747

Description of the issue/feature this PR addresses:

Odoo supports WebP image fields, but `base_import` validates remote images with `PIL.Image.open()`. Odoo intentionally leaves Pillow's WebP decoder unloaded, so a valid WebP URL is rejected as an unidentified image.

Current behavior before PR:

Importing a valid WebP image URL fails with `cannot identify image file`. Oversized and unsupported WebP files are also rejected by Pillow before the import-specific size policy can be applied.

Desired behavior after PR is merged:

Use Odoo's existing WebP header parser for dimension validation. Valid WebP URLs import unchanged, unsupported WebP remains rejected, and the existing 42-million-pixel import limit remains enforced.

Tests cover valid, unsupported, and oversized WebP URL payloads. The complete `test_base_import` suite passes (56 tests, 0 failures/errors).

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#282133
Forward-Port-Of: odoo/odoo#276648

Steps to produce:
---
- Install `website_sale` and `stock` modules
- Create a product, publish it, and add it to the cart from website.
- Go to `Website > eCommerce > Orders > Orders`.
- Open the order, click on `Add shipping` > add `Standard Delivery`.
- Confirm the order, validate the delivery via the Delivery smart button.
- From the list view, click the `To fulfill` button.

Issue:
---
- The order that was just delivered still appears in the `To fulfill` filter results, even though all actual products have been fully delivered.

Root cause:
---
- The `_search_is_unfulfilled`[1] method checks whether any order line has `qty_delivered < product_uom_qty`. A delivery/shipping line (with `is_delivery = True`) is a service—it is never physically delivered, so its `qty_delivered` remains 0 while its `product_uom_qty` is typically 1. This means `0 < 1` is always true for delivery lines, causing every order with a shipping cost line to permanently appear as unfulfilled, regardless of whether all actual products have been fully delivered.

Solution:
---
- Added domain to exclude all service-type products from the unfulfilled orders check.
- Now, an order line is considered unfulfilled only when:
  - `qty_delivered < product_uom_qty` (under-delivered)
  - `product.type != 'service'` (not a service product — excludes services, delivery lines, etc.)

[1]https://github.com/odoo/odoo/blob/e5d6650c542e44441c7087c729b3b74af3c75fe0/addons/website_sale/models/sale_order.py#L171-L183

opw-6420723
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#279134

Steps to reproduce:
- make a few sales in the PoS and refund one of them
- close the session
- select all those orders, including the refund, and create a consolidated invoice

Issue:
The invoice is refused with "You cannot validate an invoice with a negative total amount. You should create a credit note instead.", while the total of the selected orders is positive.
If a cash rounding method is set on the PoS config, no error is raised but the posted document is a credit note carrying a rounding line equal to twice the order total (a credit note of 20.00 with a 40.00 "Rounding" line for sales of 10.00 + 20.00 and a refund of 10.00).

Cause:
_prepare_invoice_vals picked the move type from the presence of a refund in the group instead of its net amount: any group holding an order with is_refund set, or a negative amount_total, became an 'out_refund'. _get_invoice_lines_values then negates the quantities of every order whose direction differs from the move type, so the sales end up as negative lines of a credit note and the document totals -20.00 instead of +20.00. account.move refuses to post it.
When invoice_cash_rounding_id is set, the cash rounding line is computed to bring the document back to a total valid for its type, so it absorbs the whole sign error and the wrong credit note is posted silently.

Fix:
Choose the move type from the net amount_total of the group, as was done up to saas-18.3, and keep is_refund only as the tie-break when that net is zero so a lone zero-total refund still gives a credit note. The sign handling of the lines is unchanged: it already keys on each order's own direction, which is what makes a sale a negative line of a credit note and a refund a negative line of an invoice.

opw-6452996

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#281703

Steps to reproduce:
- Create a "Buy 2 Get 1 free" program whose rule and reward cover three products having the same price
- In the PoS, add one unit of each of the three products -> one free product is given
- Add three more units of the second product, 6 units in total

Issue:
Only one free product is given instead of two, the order total is 50 instead of 40.

Cause:
`_updateRewardLines` deletes the reward lines and re-applies each claimed reward. Beforehand it merges the claims having the same reward and the same price, which is the case for two free products of the same price even when they were claimed for two different products. The merged claim keeps the `_reward_product_id` of the first line only, with a quantity of two. On re-application, `_computeUnclaimedFreeProductQty` only counts in `available` the quantity of that single product, since the other lines are counted only while a reward line is still in the order and they have all just been deleted. It therefore returns 1 and the second free product is lost.

Fix:
Only merge claims that were made for the same free product. Gift card/ewallet claims have no `_reward_product_id` and claims of a reward having a single reward product all share the same one, so both keep being merged as before.

opw-6430385

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#282052

When creating a MO For a product with no variant, it will add an on apply on variant component, even if only one of it's attribute has a values that match with the product on the mo.

Steps to reproduce:
-------------------
* Create a Product with two never attributes (att1 and att2)
* Add values to both attributes
* Create a BOM with components with apply on variant for every possibility:
  - component att1 val1, att2 val1, apply on variant: att1 value 1 att2 value1
  - component att1 val1, att2 val2, apply on variant: att1 value 1 att2 value2
  - component att1 val2, att2 val1, apply on variant: att1 value 2 att2 value1
  - ...
* Add mto and manufacture to the product
* Create and confirm a SO for the product variant att1 value 1 and att value 2
-> On the MO every component that as at least one of the values will be present.

Observation:
-------------
When confirming the SO it will call action_confirm. Since we are in mto, it will create a procurement order of the manufacture type and will create a MO. When creating the workorder, it will call explote on the bom to know all the components: https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp/models/mrp_production.py#L626 Each line that does not respect the apply on variant condition will be ignored: https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp/models/mrp_bom.py#L450-L451 it will retrieve the line if at least one value from any attribute match: https://github.com/odoo/odoo/blob/f7fb0a941d6bac39b7057db36f57be079559912c/addons/mrp/models/mrp_bom.py#L623-L626

opw-6293259

Forward-Port-Of: odoo/odoo#271351

Steps to reproduce:
- Enable presets and set a preset carrying a tax-replacing fiscal position (e.g. "Takeout") as the default preset of the POS config
- Take an order with another preset that has no fiscal position (e.g. "Dine In")
- Refund that order from the ticket screen

Issue:
The refund is taxed with the fiscal position of the default preset instead of the one of the refunded order. The ticket screen displays the refund lines with the taxes of the original order, but the refund that is actually created maps them through the wrong fiscal position. With tax-included prices the totals still match on screen, so the operator only sees the discrepancy after going back.

Cause:
The destination order of a refund is an empty order, created with the default preset and therefore with that preset's fiscal position. In TicketScreen.onDoRefund, the fiscal position of the refunded order was only copied onto it when the refunded order had one, so an order taken without a fiscal position kept the default preset's one. When an already existing empty order is reused as destination, whatever fiscal position was last set on it survives for the same reason.

Fix:
Always assign the fiscal position of the refunded order to the destination order, an empty one included, so a refund is taxed exactly like the order it refunds instead of silently switching. The preset itself is left untouched: it drives the ordering workflow (timing slot, customer identification) which must not be imposed on a refund.

opw-6442664

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#281102
Forward-Port-Of: odoo/odoo#280672