Steps to reproduce:
------------------------------
1. Install Subscription module
2. Create a new subscription and confirm it
3. Create an invoice from the subscription.
  * Register a payment and ensure the invoice is in the Paid state.
4. Go back to the subscription and close it with any reason
5. Open the related invoice.
  * Create and Confirm Credit Note.
  * Register a payment for the credit note.
6. Go back to subscription

Observation:
------------------------------
The subscription is automatically set back to `In Progress` even  though it was previously churned.

Issue:
------------------------------
The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid.

Solution:
------------------------------
Add a condition to exclude refund invoices from the reopening logic

opw-5947999

Forward-Port-Of: odoo/enterprise#108487

Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx).

- Fill the text field with a value (e.g., "John Doe") and save the PDF.
- (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field).
- Upload this PDF to the Sign app.

**Current behavior:**
The text field's string value is ignored and replaced with a checkmark (✓).

**Expected behavior:**
The text field should correctly render the string value that the user entered.

**Cause of the issue:**
In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713).
However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons.

**Solution:**
This PR fixes the issue safely for stable versions across two commits:

[REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit.

[FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. 

Task: 6018260

Forward-Port-Of: odoo/enterprise#110292

Prerequisites:
------------------------------
1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket
2. From Settings, create one Alias Domain

Steps to reproduce:
------------------------------
1. Install Helpdesk module
2. Open Helpdesk Team > Settings
3. Inside Channels, Set the mail used for the incoming server and the alias created
4. Set Accept Emails From to Everyone
5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`)
6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail.
7. Open Incoming mail sever  > Click on Fetch Now
8. Open Created Contact

Observation:
------------------------------
The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost

Issue:
------------------------------
After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update.

https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369

Solution:
------------------------------
Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails

Note for reviewer
-----------------------------
After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address.

That said, we should also avoid automatically clearing or altering the existing value in the field.

Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint.


opw-5478067

Forward-Port-Of: odoo/enterprise#107808

Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient.

### Steps to reproduce

1. Drag and drop multiple files into a WhatsApp Discuss channel.
2. Send the message.

-> Odoo shows all files, but only the first reaches the destination.

### Cause

WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest.

### Fix

Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss.

opw-5889035

Forward-Port-Of: odoo/enterprise#111001
Forward-Port-Of: odoo/enterprise#107424

- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.

```sql

Traceback (most recent call last):
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
    return self.mock_act_window(action)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
    [data] = record.read(fields_list)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
    return needle(*args)
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
    delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
   File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
    delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
 MemoryError

(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682

Lot_id 11412: delivery_by_lot size = 7420, parents = 3

Lot_id 11753: delivery_by_lot size = 0, parents = 7

Lot_id 12845: delivery_by_lot size = 11, parents = 5

Lot_id 14646: delivery_by_lot size = 12, parents = 2

Lot_id 15801: delivery_by_lot size = 1700, parents = 3

Lot_id 19817: delivery_by_lot size = 0, parents = 4

Lot_id 22370: delivery_by_lot size = 0, parents = 1

Lot_id 25072: delivery_by_lot size = 6827, parents = 2

Lot_id 25134: delivery_by_lot size = 3, parents = 2

Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones

UPG - 3869661
OPW - 5900313

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

Forward-Port-Of: odoo/odoo#248826

# How to reproduce
- Create a BOM for a product
- Create a MO for a set quantity (Exemple: 1) for that product
- Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3)
- Confirm the unbuild
- Go to the stock moves of that unbuild via the smart button

# The problem
3 stock move lines are created, 2 in the 'Done' state and 1 in the 'Available' state. This last move line is stuck and cannot be validated

# Why
The cause of this issue is due to a discrepency between the quantity set for the move lines and the quantity set for their respective moves.

When creating the move lines for the produce move, we use the original move of the MO (this is done to keep Lots consistent). If the quantity of product to unbuild is more than the quantity of product built by the MO, the quantity of the move lines will be less than expected.

This will then create a backorder when the produce move is set to done. This backorder will then be unvalidatable because the unbuild it is linked to will be set to 'Done'.

opw-5915981

opw-5449109

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

Forward-Port-Of: odoo/odoo#254016
Forward-Port-Of: odoo/odoo#248056

**Steps to reproduce:**
- Create a product tracked by lot, set it's price to 1000
- Create a quotation add a line with the created product and change the price to 1200
- Add another line with the same product and change it's price to 600
- Go to PoS and settle this quotation
- The lines' prices will be 1000 and 600 instead of 1200 and 600

**Why the fix:**
In the event of a settle with a product tracked by lots, we are setting the price of all *related_lines* (lines with the same product in this case) to it's base price, not taking into account the fact that this price has been modified by the user when making the quotation.

This only happens for related lines, which explains why one line's price is still 600 while the other was reverted to the base price of 1000 instead of being 1200 as it was previously set.

To avoid this, we now set the price_unit back to the base one only if the price hasn't been changed manually.

opw-5223463

Forward-Port-Of: odoo/odoo#254260
Forward-Port-Of: odoo/odoo#238295

Backport of https://github.com/odoo/odoo/pull/249869

Description
This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a default account linked to an existing journal has been archived.

Current Behavior
Currently, when a user creates a new journal (e.g., a "Bank" type journal), the system automatically generates or assigns a default account. If the user subsequently archives that default account, any future attempt to create a new journal of the same type results in a Validation Error:

"Account codes must be unique. You can't create accounts with these duplicate codes: [XXXXXX]"

This happens because the system's uniqueness check for account codes includes archived accounts, but the automated journal setup logic fails to account for this state, effectively locking the user out from creating new journals until the archived account is manually renamed or unarchived.

Desired Behavior
After this PR is merged, users should be able to create new journals seamlessly, even if previous journals have archived default accounts.

video
https://drive.google.com/file/d/1VzAskdTwF7lNc1y8PIpvN0T2zzKTMtdJ/view

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#251025

When vendor bills digitization is deactivated, subscribers to the "Purchases" journal are not notified when a vendor bill is sent to the email alias set on the "Purchases" journal

Steps to reproduce:
1. Install Accounting
2. Go to Settings > Accounting > Digitization and set Vendor Bills to "Do not digitize"
3. Go to Settings > Technical > Email > Alias Domains and create a new alias domain (e.g. "odoo.com")
4. Go to Settings > Technical > Email > Incoming Mail Servers and create a new incoming mail server (e.g. "megu@odoo.com", you may need to setup POP access on your email address and create an app password, see https://support.google.com/mail/answer/7104828)
5. Go to Accounting > Configuration > Journals and open journal "Purchases"
6. Go to Advanced Settings tab and set the Email Alias and the Send Copy To fields (e.g. "megu@odoo.com" for both)
7. Send a mail with an attachment to the email alias set on the "Purchases" journal
8. Go to the previously created incoming mail server and click on Fetch Now
9. Go to Settings > Email > Technical > Emails
10. No email has been sent to the subscriber of the "Purchases" journal

Issue:
`_extend_with_attachments` returns None if the OCR import failed https://github.com/odoo/odoo/blob/b44295bb6ce621ff87cbc96860492650d90d0ad7/addons/account/models/account_document_import_mixin.py#L340-L349 which prevents the call to method `_notify_invoice_subscribers`

Solution:
Send an email regardless of the result of the OCR import

opw-5914096

Forward-Port-Of: odoo/odoo#252442

Problem
------------------------
When an employee has approved leaves, and a group leave is created that overlaps with the approved leave and overrides it, the duration of the new group leave is not computed correctly. The duration does not include the overridden days. To reproduce:
1. Create allocated leave for employee and approve and validate it.
2. Go to Management > Time Off and create a group leave for the employee that includes the approved time off dates. The dates of all leaves are updated correctly, but the duration of the group leave is incorrect.

Objective
---------------------------
Even though conflicting leaves were correctly split in the multi leave generation wizard, the resource.calendar.leaves table was not synchronized within the same transaction. Because the leave types required allocation, the duration was computed by subtracting the old time off days from the new leave's duration, since they were treated as unavailable.

Solution
--------------------------
Manually unlink the resource.calendar.leaves records associated with the conflicting leaves before calculating the new duration. The clears the employee's schedule in the database so that the dates are correctly processed as available. The calendar blocks for the remaining days of the approved time off and the new group leave are generated when the leaves are created.

Task: 5911074





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

Forward-Port-Of: odoo/odoo#253837
Forward-Port-Of: odoo/odoo#249527

…f uom

**Problem:**
partial cogs are computed incorrectly when 
the uom of the invoice is different than the one 
of the product

**Steps to reproduce:**
-1) created a stored product with category std price perpetual
-2) set a cost of 1 and an on hand quantity of 12
-3) for the invoicing policy select 'delivered quantities'
-4) in the sales tab add the packaging 'pack of 6'
-5) confirm a sale order for 2 packs of 6

Problem A: 
-6a) validate the delivery
-7a) create and confirm an invoice for all the quanity 
-8b) on the delivery create a return for a quantity of 6 and validate
-9b) select 'create invoice' on the sale order
-10b) confirm the credit note

Problem B: 
-6b) change the quantity to 6 units on the delivery
-7b) validate with backorder
-8b) create and confirm an invoice for the delivered quantity
(1 pack of 6)
-9b) validate the back order
-10b) create and confirm an invoice for the remaining (1 pack of 6)

**Current behavior:**
Problem A : 
the cogs lines are : 
- crediting stock valuation of 54$
- debiting expenses of 54$

Problem B: 
the cogs lines are: 
- debiting stock valuation of 24
- crediting expenses of 24

**Expected behavior:**
Problem A:
the cogs lines should be: 
- debiting stock valuation of 6
- crediting expenses of 6

Problem B: 
the cogs lines should be: 
- crediting stock valuation of 6
- debiting expenses of 6

**Cause of the issue:**
Both problems have the same cause.
To compute the price unit for the cogs we call _get_cogs_value()
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move.py#L122
Inside _get_cogs_value, in the computation of the return value:
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L74
- price_unit is computed (in both use cases) using _get_cogs_price_unit
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L68
and is expressed in the uom of the product 
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/stock_move.py#L238-L240
- self.quantity is expressed in the uom of the invoice (pack of 6)
- cogs_qty is computed using _get_cogs_qty()
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L66
and is expressed in the uom of the invoices (pack of 6)

Because of this, in both use cases, the computation is incorrect.

**fix:**
we use the uom of the product everywhere because _get_cogs_value()
should return the price unit in the products uom
https://github.com/odoo/odoo/blob/b071bc3cb9e1d91d9d0fbce7961c3c75f28ef874/addons/stock_account/models/account_move_line.py#L51-L52

opw-5901706

Forward-Port-Of: odoo/odoo#253938
Forward-Port-Of: odoo/odoo#250154