Currently an exception is generated when the user tries to export (downlaod) a
`CSV` file of the `General Ledger` report as the below step:
- Install the `accountant` module with demo data
- Enable and change to the `French` language
- Go to `Comptabilité` > `Analyse` > `General Ledger`
- Click the cog icon in the menu > Click on `CSV`
- An error occurs in the log, and nothing is downloaded

Error: `TypeError: 'NoneType' object is not subscriptable`

This issue occurs after the recent refactoring changes in [1]. When
`_generate_csv_lazy_export` is called, it uses the `_()` method for
translation, which accesses `self.env`. However, at this point, the cursor
is already closed. As a result, when the code at [2] is reached from
`ormcache`, it raises the above error because
`model.env.transaction.ormcaches__` is `None` (code ref [3]).

This commit fixes the above issue by performing the translation
using the existing `handler` variable, which contains an environment
with the new cursor (see code ref [4]).


[1]: https://github.com/odoo/odoo/commit/13c3adf3a8b5ba6325190d6b9aea45fb8a6a8b2f
[2]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/cache.py#L111
[3]: https://github.com/odoo/odoo/blob/5ef7829895b2e05650da394c1e35dfdc3a23c066/odoo/orm/environments.py#L1012
[4]: https://github.com/odoo/enterprise/blob/912a47b8f0828ef8316b7e4ecdabf8a2f305b313/account_reports/models/account_general_ledger.py#L524

Sentry-7608119520

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

This commit fixes a couple things with this tour:
    
1. We need to confirm the dialog that appears when we try to confirm the payrun itself

2. Depending on whether or not a particular l10n_XX module is installed, the trigger that we were previously using to check whether or not a payslip had been confirmed, `.btn[name='action_payment_report']` might not be there; i.e., l10n_us_hr_payroll, among others: https://github.com/odoo-dev/enterprise/blob/7767024956325d52fb30239967025b04999a9188/l10n_us_hr_payroll_account/views/hr_payslip_run_views.xml#L11-L13

   It can be seen there ^ that that button is invisible under a slightly different condition than the base `hr_payroll` version of that button, causing an inconsistency in this test when that module is installed: https://github.com/odoo-dev/enterprise/blob/7767024956325d52fb30239967025b04999a9188/hr_payroll/vie
ws/hr_payslip_run_views.xml#L175

   We resolve this by checking for either button in that step: `trigger: ".btn[name='action_paid'], .btn[name='action_payment_report']"`

runbot-243607

…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

Forward-Port-Of: odoo/enterprise#124480

Steps to reproduce:
-------------------------------------------------
1. Install the `sale_project` module
2. Create a test user with Project User rights
3. Create a Project Role with the Created User as a Team Member
4. Create a Template Project as follows:
    * Add one task to the template project
    * Add the created Project role to the Task
5. Create a Service Type Product with:
    * Create on order: Project
    * Project Template: Created Template
6. Archive the Created User
7. Create and Confirm the Sale Order with the Created Product

Observation:
-------------------------------------------------
The generated task is assigned to the archived user, although the archived user is no longer part of the Project Role.

Issue:
-------------------------------------------------
While creating Project and Tasks from template, the context disable active record filtering (e.g., `active_test=False`), causing the assignment logic to fetch both active and inactive/archived users linked to the role. https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/odoo/orm/models.py#L4868

After that, during the `copy_data` method, It takes all the users from the roles without checking weather user is active or not
https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/addons/project/models/project_task.py#L890-L904

And even if we pass only Active users from this method, on moving further, it reassigns the users from roles without checking the Active field of the user

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L501-L503

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L544-L553

Due to this, the Archived User is also assigned to the tasks from the project roles

Solution:
-------------------------------------------------
Apply a `filtered('active')` check directly on the project role's users `(role.user_ids)` within the core task-copying logic in both `project` and `project_enterprise` modules. This ensures archived users are universally excluded from task assignments during template copying, regardless of what triggers the template instantiation.

Related Community PR: https://github.com/odoo/odoo/pull/274426

opw-6350841

Forward-Port-Of: odoo/enterprise#125637

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

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 the bug:
- Enable 2-step delivery (pick + ship) on a warehouse.
- Set both rules on the delivery route to "Pull" (instead of the default Pull + Push):
    - Pick rule (Stock -> Output): action = Pull, procure_method = make_to_stock
    - Ship rule (Output -> Customers): action = Pull, procure_method = make_to_order
- Create a sale order for qty 1 and confirm it.
- Validate the Pick transfer.
- Return the Pick transfer.
- Cancel the sale order.
- Set it back to quotation and confirm it again.

Problem:
The newly created delivery (ship) move ends up asking for a wrong, inflated quantity instead of the ordered one (e.g. 3 times the ordered qty for the scenario above; the multiplier depends on the number of prior confirm/cancel/return cycles).

`_action_cancel` (addons/sale_stock/models/sale_order.py) only cancels pickings that are not `done`, so after the pick is validated and returned, cancelling the SO only cancels the still-pending ship move. The pick move and its return stay `done` and linked to the sale order line.

`SaleOrderLine._get_outgoing_incoming_moves` determines which rule "started" the pull/push chain by picking the rule of the first surviving (non-cancelled) move, grouped by warehouse: https://github.com/odoo/odoo/blob/d7bad3dc6c068ffe8643ecb01da1865d743bfb8f/addons/sale_stock/models/sale_order_line.py#L338-L347

Once the ship move is cancelled, it is excluded from that computation, so the Pick rule is wrongly identified as the "triggering" rule instead of the Ship rule. The done pick move and its return share that rule, so they both end up wrongly classified as incoming (returned) quantities instead of being excluded from the computation like before the cancellation, corrupting `_get_qty_procurement`. On reconfirm, `_action_launch_stock_rule` computes
`product_qty = product_uom_qty - qty`, inflating the quantity requested on the new ship move.

Solution:
Identify the triggering rule from the sale order line's full move history, including cancelled moves, so cancelling a move later doesn't change which rule is considered to have started the chain.

opw-6364113

Forward-Port-Of: odoo/odoo#281709
Forward-Port-Of: odoo/odoo#280280

Steps to reproduce the bug:
- Create three storable products C1 ($10), C2 ($20), C3 ($5)
- Create a product P1 with a BoM: 1x C1 + 1x C2
- Create a Manufacturing Order for P1 and validate it
- Unlock the MO (Settings > Unlock)
- Add C3 as an extra component on the unlocked MO
- Open the MO overview

Problem:
The extra move had value=0 after creation, causing the unit_cost in the
MO overview to appear as 0. When a move is added to a done picking or MO
it is created with state='done' and quantity set immediately. This triggers
_set_quantity_done, which creates the move line and calls
_set_value(correction_quantity=delta). Inside _set_value, for outgoing
moves with a correction_quantity, the code computes:
  previous_qty = move.quantity - correction_quantity
Since the move had no prior quantity, previous_qty=0. The original code then
computed ratio=0 and applied move.value += 0, leaving value=0 instead of
computing it from scratch.

Solution:
When previous_qty=0, skip the ratio branch and fall through to the existing
from-scratch computation (standard_price * _get_valued_qty() for AVCO/standard
costing, _run_fifo() for FIFO).

opw-6377393

Forward-Port-Of: odoo/odoo#281008
Forward-Port-Of: odoo/odoo#276303

Before this commit, switching the camera input device during a call froze the local preview: the <video> element kept pointing at the old, already stopped MediaStream.

`CallParticipantVideo` assigns `srcObject` from `onMounted`/`onPatched`. Those callbacks run outside of any computation, so reading `session.getStream(type)` there subscribes to nothing, and the template does not read the stream either. On top of that, a child is only patched when one of its props changes identity, and switching the camera device keeps the same `session`, `type` and `inset`, and keeps `is_camera_on` true: it only swaps the stream object. Nothing was left to tell the element to update.

This commit replaces those lifecycle hooks with an effect, and the owl2 `useRef` with a signal ref, so that both the element and the stream are tracked and the element is updated as soon as the stream is replaced. The effect cleanup still clears `srcObject`, which is what allows the component to be garbage collected once detached.

task-6468610


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

Fix a series of service fee defects and add the missing coverage.

Discounts:
- stop duplicating the fee line on every recompute under a global
  discount: reconciliation is keyed on tax_ids alone, so the discount
  line's computation_key is stripped to keep one tax group;
- recompute the fee when a global discount is applied and when a reward
  is deactivated: both change the base the fee is carved from without
  emitting any event (pos_discount, pos_loyalty);
- keep a single fee line when a gift card / eWallet is used, and the fee
  out of the base it is carved from: it is money already paid, and it
  settles the whole bill, service fee included (pos_loyalty);
- keep the fee out of the base a discount on order is taken from, so
  pricing or scaling it no longer moves the promotion (pos_loyalty);
- keep a discount line out of the base the fee is carved from unless the
  fee is a percentage of the order total after discount: a discount
  covering the whole order collapsed that base to zero and the fee
  disappeared from the order (pos_discount, pos_loyalty).

Fixed fee:
- scale it exactly with its quantity (5 x $2 = $10.00, not 9.99 from
  per-unit tax rounding), and fix the cent it lost on recompute;
- let the cashier price it, not only scale it: the price is read the way
  the preset's amount is, a target total taxes included, and survives
  the next recompute.

Refunds:
- a refund order carries no preset, so recomputing its fee deleted the
  refunded fee lines. Skip the recompute: the cashier decides whether to
  give the fee back by selecting the line like any other.

Display:
- stop qualifying a fixed fee with the preset's `based on` mention, on
  the orderline and on the receipt: it states which order total a
  percentage is taken from.

Restaurant:
- keep the fee pinned to the bottom of the order (the last course);
- keep a single fee line when an order is transferred onto a table that
  already carries one: fee lines never merge, so the source's were
  copied over and the stale one was left on the order.

task-6372687

**Steps to reproduce:**
1. Install Sales and Loyalty modules
2. Create a Discount & Loyalty Program (type: Promotion) and save the form
3. Open the Reward modal and edit any values (e.g., 5% discount instead of 10%), save the new changes in the modal and then save the form
4. Re-open the reward modal

**Issue:**
The updated value (5% discount) is not saved, and the reward reverts to its previous state (10% discount). This issue will occur for any modifications.

**Why this happens:**
- The write method in `loyalty_program` uses `convert_to_cache` on `reward_ids` to make a constraint check before executing the actual super().write()
- A recent commit (9c52f6246d24d02457d34df6b559eecf7ec50687) modified `convert_to_cache` to update the cache for `Command.UPDATE` to fix premature computations during `onchange`
- This update alters the real record's cache without marking the fields as dirty
- When super().write() executes afterwards, the ORM sees the incoming values already match the cache, assumes no changes occurred, and drops the SQL UPDATE

**Fix:**
- Restrict the cache mutation to only apply to virtual/draft records
- This preserves the intended onchange behavior for NewId records while preventing cache corruption on real database records prior to write

opw-6405775

Steps:
- Install account_peppol.
- Go my account on the portal page.
- Select peppol supported county and set `By peppol` for `Receive invoices` field on my/account page.
- Select any wrong values for `Peppol e-Address (EAS)` or `Peppol Endpoint` fields

Issue:
- It allow to save those values on customer even though they are wrong, it should give proper error message according to Peppol validation same as in backend.

Cause:
- In this PR https://github.com/odoo/odoo/pull/262274 adeption of validation for account details is not properly adapted and because of that it skips those validation and allow user to save wrong details

Fix:
- Adapt validation for account details saving to have proper error message for wrong values.

### [FIX] account_peppol: fix Peppol fields requirement on address page
- Install account_peppol.
- Go my account on the portal page.
- Select peppol supported county and set `By peppol` for `Receive invoices` field
on my/account page.
- Don't select any value for any of Peppol related detail (routing_scheme,
routing_endpoint or invoice_edi_format).

Issue:
- Allowed to save `By peppol` for `Receive invoices` field even without
setting required details for peppol, it should make peppol related
details required and not allow to save that method unless user set
valid details for Peppol.

Cause:
- Since PR https://github.com/odoo/odoo/pull/192183 peppol related details
are not added to mandatory because there is not `invoice_sending_method`
related details in kwargs since it's moved to res.partner and it also
don't have any details in request.params and it does not update
required fields dynamically when we change `invoice_sending_method`
so current way to make those field required is not working and wrong.

Fix:
- Instead trying to make fields required on load, which will not work
when user change details. Check `peppol` related field requirements
on validation of address details and make those fields missing and
prevent to save address details for missing values.

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:
- 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

Forward-Port-Of: odoo/odoo#281512

### Issue before this commit:
Before commit f2965048f60fe6c815b3e50fa714c97a93dfb5d3, company_type allowed manually selecting whether a contact was an individual or a company. After the commit, is_company became a stored computed field derived from the VAT number, with no manual override available in the standard UI, and no exception was added for Spanish DNI/NIE formats.

### Steps to reproduce the issue:
1. Download Accounting and l10n_es
2. Set as VAT of ES company 47857909S (or similar but must be a DNI or NIE format)
3. Create an invoice for a Spanish customer
4. Send the invoice with Facturae
5. Check the XML created and see that the tag <PersonTypeCode> of <SellerParty> has a J (legal entity) rather than an F (individual)

### Cause of the issue:
The Spanish localization's _compute_is_company override only adds the check for CIF-formatted VAT numbers (for [legal entities](https://sede.agenciatributaria.gob.es/Sede/ayuda/manuales-videos-folletos/manuales-practicos/guia-practica-cumplimentacion-modelo-censal-036/anexos/anexo-01-solicitud-nif-documentacion-aportar/informacion-sobre-numero-identificacion-fiscal/composicion-nif/personas-juridicas-entidades.html)) but it has no corresponding negative check for DNI or NIE formats (for [standalone individuals](https://sede.agenciatributaria.gob.es/Sede/ayuda/manuales-videos-folletos/manuales-practicos/guia-practica-cumplimentacion-modelo-censal-036/anexos/anexo-01-solicitud-nif-documentacion-aportar/informacion-sobre-numero-identificacion-fiscal/composicion-nif/personas-fisicas.html)). Here the [rules](https://factuo.es/herramientas/verificador-nif) for regex.
https://github.com/odoo/odoo/blob/f014e0b7bc3ce56a9931e81339a4f8327a400422/addons/l10n_es/models/res_partner.py#L39-L51 As a result, any standalone partner with a valid non-void VAT inherits is_company = True from the base computation.
https://github.com/odoo/odoo/blob/f014e0b7bc3ce56a9931e81339a4f8327a400422/odoo/addons/base/models/res_partner.py#L824-L833

### Reason to introduce the fix:
The Facturae 3.2.2 export directly derives PersonTypeCode (F/J) and the LegalEntity/Individual XML structure from partner.is_company. Since a self-employed individual (autónomo) is required to use their personal DNI/NIE as NIF and is their own commercial partner, the current logic misclassifies them as a legal entity (J), producing a Facturae invoice with an incorrect PersonTypeCode and structure. Explicitly setting is_company = False for DNI/NIE-formatted Spanish VAT numbers restores the ability to correctly represent individual entrepreneurs in Facturae exports.

opw-6396314

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

Forward-Port-Of: odoo/odoo#277228

**Description of the issue/feature this PR addresses:**

[FIX] html_editor: ensure youtube videos loop correctly

When configuring a YouTube video to loop in the website editor, the video
currently fails to loop when it finishes playing.

This occurs because setting loop=1 in a YouTube iframe URL is not sufficient
on its own. The YouTube Iframe API explicitly requires the playlist parameter
to be present and set to the exact same video ID for looping to work. See: https://developers.google.com/youtube/player_parameters#loop

This commit resolves the issue by intercepting the video options before the
URL is generated and automatically injecting the playlist parameter when
looping is enabled. The playlist parameter is also registered in the
optionsConfig schema to ensure it is properly recognized and encoded into the
final URL.

**Steps to reproduce:**

- Website > Edit > add Youtube video > enable Autoplay and Loop > observe that loop does not work

**Current behavior before PR:**

- Looping does not work for embedded Youtube videos

**Desired behavior after PR is merged:**

- Looping works for embedded Youtube videos

opw-6411445

**Steps to reproduce:**
1. Install Sales and stock_delivery modules.
2. Create a new Sale Order and add a product to the order lines.
3. Confirm the Sale Order (which locks the order lines and creates a delivery move).
4. Attempt to click on the product name in the order line to open its external form.

**Issue:**
- The product name is unclickable when the sale order is confirmed.

**Expected behavior:**
- The product form should remain accessible and clickable

**Why this happens:**
- Following the recent OWL 3 upgrade (#269532), the framework changed how properties are defined and tracked.
- Inheriting props via `...super.props` inside a `static props` object fails because parent components now define schemas as instance fields.
- The compatibility layer never read `static props`, so extra keys defined in those schemas were not exposed on `this.props`

**Fix:**
- Update the schema definition to use the new OWL 3 instance field syntax (`props = props({...})`) and explicitly import and spread the parent component's exported props object instead of relying on `super.props`.

opw-6447573

Steps to reproduce:
-------------------------------------------------
1. Install the `sale_project` module
2. Create a test user with Project User rights
3. Create a Project Role with the Created User as a Team Member
4. Create a Template Project as follows: 
    * Add one task to the template project
    * Add the created Project role to the Task
5. Create a Service Type Product with:
    * Create on order: Project
    * Project Template: Created Template
6. Archive the Created User
7. Create and Confirm the Sale Order with the Created Product

Observation:
-------------------------------------------------
The generated task is assigned to the archived user, although the archived user is no longer part of the Project Role.

Issue:
-------------------------------------------------
While creating Project and Tasks from template, the context disable active record filtering (e.g., `active_test=False`), causing the assignment logic to fetch both active and inactive/archived users linked to the role. https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/odoo/orm/models.py#L4868

After that, during the `copy_data` method, It takes all the users from the roles without checking weather user is active or not
https://github.com/odoo/odoo/blob/8ec646e51497b38d34ea59296e0fc8644a50ee3a/addons/project/models/project_task.py#L890-L904

And even if we pass only Active users from this method, on moving further, it reassigns the users from roles without checking the Active field of the user

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L501-L503

https://github.com/odoo/enterprise/blob/5abb147f9bf725daafc202d8259a5bb8a9b78d94/project_enterprise/models/project_task.py#L544-L553

Due to this, the Archived User is also assigned to the tasks from the project roles

Solution:
-------------------------------------------------
Apply a `filtered('active')` check directly on the project role's users
`(role.user_ids)` within the core task-copying logic in both `project` and
`project_enterprise` modules. This ensures archived users are universally
excluded from task assignments during template copying, regardless of what
triggers the template instantiation.

Related Enterprise PR: https://github.com/odoo/enterprise/pull/125637

opw-6350841

Forward-Port-Of: odoo/odoo#274426

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#282342
Forward-Port-Of: odoo/odoo#276648