**Steps to reproduce:**
* Install the **Accounting** and **l10n_br_edi** modules.
* Create and post a Brazilian customer invoice using an **Avatax fiscal position**
* [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0)
* Confirm the invoice and **send it to e-invoice (Brazil)**.
* Confirm the **Brazil E-Invoice Status** shows **'Accepted'**.
* Click **Request Cancellation**, enter a cancellation reason, and submit the request.

**Observed behavior:**
* The invoice moves to **Cancelled** state.
* The cancellation XML is generated and attached in the chatter.
* SEFAZ returns a successful cancellation response.
* However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**.

**Cause:**
* In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`.
* `button_cancel()` internally triggers `button_draft()` for posted invoices.
* The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`.
* This clears the status that was just set, leaving the field blank.

**Fix:**
* move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method.

opw-5378542

Forward-Port-Of: odoo/enterprise#101438

Steps to Reproduce
===================
1. Upload more than 40+ files in a folder. (One page displays upto 40 docs)
2. Use the checkbox to select all files on the page (this selects only 40 files)
3. Click the 'Select All' button in the control panel to select all 40+ files.
4. Now, try duplicating or moving them to the trash.
=> Only the first 40 selected files (on the single page) are considered for
   action, not all the selected files.

Technical
==========
For documents control panel action we have custom handling for selecting records
and executing action. We use `model.root.selection` which only consider records
in current page, case of select all records from other pages is missed here.

After this PR
==================
- All selected records are considered for the actions
- Added custom `getResIds` method to get filtered `resIds` as per domain.

Note: `getResIds` in DynamicList doesn't have custom domain feature so create
our own as per use case

Task-4700841

Forward-Port-Of: odoo/enterprise#100791
Forward-Port-Of: odoo/enterprise#87634

Currently, an incorrect shipping address is assigned to invoices generated from 
POS orders when the customer has multiple delivery addresses.

**Steps to reproduce:**

- Install the `point_of_sale` and `contacts` modules.
- Enable `Customer Addresses` from the settings.
- Create a contact with `two` delivery addresses.
- Open POS and create an order using the `second delivery address` as the customer.
- Confirm the order with the `invoice`.
- Observe the `shipping address` on the invoice.

**Observation:**
The invoice incorrectly shows the first delivery address instead of the 
second delivery address.

**Cause:**
At invoice creation in POS, only `partner_id` is set and `partner_shipping_id` 
is missing at [1]. As a result, the invoice defaults to the customer's first 
delivery address instead of the delivery address selected in POS.

**Fix:**
This commit adds `partner_shipping_id` to the invoice values to ensure the 
POS invoice uses the exact delivery address selected during order creation. 
same as the `sale` module behaviour.

[1]:
https://github.com/odoo/odoo/blob/1d1cd8648ed1c3f13febbde8d48e28928e18583f/addons/point_of_sale/models/pos_order.py#L667-L684

opw-5350137

Forward-Port-Of: odoo/odoo#239663
Forward-Port-Of: odoo/odoo#238055

When registering to an event, customers are asked questions before reaching the payment page. By default, a *Name* question is included, but it can be removed by the organizer of the event. If the *Name* question is removed, but a name is asked in the delivery form, Odoo will try to compare the (missing) name from the event's questions with the (required) name from the delivery form.

https://github.com/odoo/odoo/blob/828a9504c7d43aa35ed91141268d04e0a55782c3/addons/portal/controllers/portal.py#L551

The issue is that if there's no *Name* question among the event's questions, a `res.partner` with its `name` field set to `False` is created. When attempting to call `.strip()` on its name, an `AttributeError` is raised (*'bool' object has no attribut 'strip'*).

This fix prevents the error by considering the name field as an empty string in case no name is provided.

### Steps to reproduce:
1. Install *Online Event Ticketing* (`website_event_sale`)
2. In Settings > Website, set *Sign in/up at checkout* to *Disabled (buy as guest)*
3. In Events, create a new Event
    - Give it any name
    - Add a product line for the Event Registration with a price greater than 0
    - In the *Questions* tab, remove the *Name* question
    - Click the *Go to website* smart button and publish the event
4. On the website, in incognito mode:
    - Click *Events*
    - Click the new event we created in Step 3
    - Click *Register*, (set the quantity to one ticket,) click *register*
    - Answer the questions (there should **not** be a *Name* question) and click *Confirm Registration*
    - Fill out the required fields of the delivery form (there **should** be a *Name* field)
    - Open the console, then click *Confirm* in the delivery form: An error appears, and the Payment page does not appear

opw-5259781

Forward-Port-Of: odoo/odoo#237154

This fix addresses an issue where selling multiple gift cards in a single POS order results in only one gift card being created with the total amount, instead of multiple gift cards with the correct individual amounts.

Step to reproduce:
- Create a new gift card and enable the option to sell this card in the POS
- Open the POS and try to sell multiple gift cards in the same order
- Validate the order
- Check the generated gift cards, only one gift card will be created with the total amount instead of multiple gift cards with the correct individual amounts

This issue occurs because the field `reward_point_split` is missing from the kanban view of loyalty rules. So, when creating a new gift card, this field value, which should be True for gift cards, is not returned by the onchange method, and since nothing triggers a new computation unless the program type is changed, the field remains False.

This fix simply restores this field in the kanban view (like before https://github.com/odoo/odoo/pull/172561) so that its value is correctly taken into account when creating a new gift card.

opw-5103652

Forward-Port-Of: odoo/odoo#238993

Steps to reproduce:
1. Install `loyalty` and `sale_management`
2. Activate another language with another date format, eg. English (AU)
3. Set that language on a contact
4. Sales > Product > Discount & loyalty
5. Create a record with program type coupons
6. Generate a coupon for that AU contact with an expiration date

Issue:
The coupon email received by the customer shows the expiration date using the yyyy-MM-dd format, and the attachment shows the same technical format instead of the customer’s localized date format.

Cause:
We are not using a formatted date according to the customer

before: Customer with English AU language
<img width="601" height="563" alt="image" src="https://github.com/user-attachments/assets/faea2840-aca6-4850-bfc9-b0d24da65a3b" />

<img width="1510" height="883" alt="image" src="https://github.com/user-attachments/assets/b0ebc0cc-6243-450d-ad12-cecda4858e26" />


After:
<img width="603" height="543" alt="image" src="https://github.com/user-attachments/assets/5be2332b-3237-4ce5-8122-0766cd274650" />

<img width="1482" height="886" alt="image" src="https://github.com/user-attachments/assets/99d31b4c-33fa-4f92-9970-56720181911e" />


opw-5247621

Forward-Port-Of: odoo/odoo#237880

### Steps to reproduce:

- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
    - Final Product (FP) with an empty bom
    - By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination

### Cause of the issue:

Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.

### Note:

The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f

opw-5350222

Forward-Port-Of: odoo/enterprise#101736
Forward-Port-Of: odoo/enterprise#101087

In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.

https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55

The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]

To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.

Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.

Steps to reproduce the initial error:
1. Install the following app and module:
    - Point of Sale (`point_of_sale`)
    - Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
    - Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.

opw-5171035

Forward-Port-Of: odoo/enterprise#101275
Forward-Port-Of: odoo/enterprise#99871