Versions
--------
- 16.0+

Steps
-----
1. Install `website_sale_loyalty` with default configuration;
2. add a payment provider;
3. as a public user, buy a gift card via eCommerce.

Issue
-----
No email is sent with the gift card's code to the provided email address.

Cause
-----
The email template doesn't have an `email_from` field added. Without this value, it falls back on the current user, but because we're Public User, this also doesn't have an `email` value.

Additionally, if the order gets confirmed as a portal user, the email will be sent from the client's email address.

Solution
--------
Add a `_get_mail_author` hook to `loyalty.card`, which can be used when an email template lacks an `email_from` value.

Mail author precedence for cards without an order:
- current internal user > card's company > current company

Mail author precedence for cards with an order:
- salesperson > order's company


opw-4687107

Forward-Port-Of: odoo/odoo#205676
Forward-Port-Of: odoo/odoo#204644

When printing a delivery order with a kit product that has a BoM with a product template (not a product_id) and a packaging quantity, we encounter a traceback due to the conversion of the quantity from the product's UoM to the order line's UoM. This happens because the product's UoM is not defined.

Steps to reproduce the bug:
- Create a storage “P1”:
    - UoM: Kg

- Create a storable “Kit 1”:
    - UoM: unit
    - BoM:
       - set only the product template field (not the product_id)
        - 1 Kg of P1

- Create a delivery order for 1 unit of Kit 1
- Mark it as to do
- Set the quantity of P1 to 1kg
- try to print

Problem:
A traceback is triggered because we try to convert 1kg to an undefined uom

```
Error while render the template
UserError: The unit of measure Units defined on the order line doesn't
belong to the same category as the unit of measure False defined on
the product. Please correct the unit of measure defined on the order
line or on the product. They should belong to the same category.

```

opw-4619140

Forward-Port-Of: odoo/odoo#205591
Forward-Port-Of: odoo/odoo#205502

Currently, an error occurs when importing or testing data from a CSV file, particularly when setting related fields. This results in an unhandled error during the error message creation process.

** Steps to reproduce:**
- Open the **Product Variants** list view.
- Import the csv file: [file](https://drive.google.com/file/d/1pW9zBWQ0dzFRBHnLUk3DC34YWuK4tUV0/view?usp=drive_link)
- Set the Odoo fields as `Name` and `Products / Cost` accordingly.
- Click on `Test` or `Import` button.
- Observe the error at the backend.

**Error:**
`ValueError - not enough values to unpack (expected 1, got 0)`

The error occurs because `[columns]` attempts to unpack an empty list when `cr.fetchone()` returns `None` at [1].

This commit ensures that if `cr.fetchone()` returns `None`, `columns` is assigned an empty list without causing an unpacking error.

[1] - https://github.com/odoo/odoo/blob/30efa3c90226e77fb175b533dd60734f58a4f27c/odoo/orm/models.py#L7374

This issue will also fix Sentry IDs: 6398456413, 6518332727, 6316946127
Sentry - 6278940594

Forward-Port-Of: odoo/odoo#201500

During post-install tests, run the following code in a python terminal:

    import socket, time
    with socket.create_connection(('127.0.0.1', 8069)):
        time.sleep(6)

It opens a socket and connect to the running odoo server, but does nothing. After 5 seconds the odoo server closes the socket with a timeout.

The timeout is only set during tests in ``RequestHandler.setup``, and it set to a hardcoded value of 5 seconds. Since Werkzeug 2.1.0[^1], it logs an error in the logs. We want to get rid of that error log.

Those errors can occur when the test chrome browser is killed while it was performing http requests. Chrome doesn't TCP RST the sockets and just let those sockets die.

The socket timeout error actually cannot occurs in production, as all traffic is routed via nginx, and nginx will only proxy the connection to Odoo once nginx has all the requests headers.

That error log is silly, it is now ignored.

[^1]: pallets/werkzeug:d062807

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#204023
Forward-Port-Of: odoo/odoo#203757

Currently, an exception is generated when a user tries to save a product record without a barcode, whether it is a newly created record or an existing one.

Steps to reproduce:

1. Install the Inventory module.
2. Go to Inventory settings.
3. Set Barcode Nomenclature to Default GS1 Nomenclature.
4.  Go to Inventory -> Products, create a product with a barcode, and save it.
5. Edit the same product, remove the barcode, and save it again.
6. An error occurs.

Error: `StopIteration`

This issue [1] occurs because when a user tries to save the record without a barcode, the value is false, and an false value is not iterable.

[1] - https://github.com/odoo/odoo/blob/9eb6c16cd7d4fe9364d043e2af96876bf82a44d4/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L163

This fix resolves an issue where GS1 preprocessing was always applied when checking for duplicate product barcodes. By introducing the skip_preprocess_gs1 context flag, the GS1 preprocessing step is now bypassed when verifying barcode uniqueness.

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

sentry-6267124218

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

Forward-Port-Of: odoo/odoo#196438

Some website appointment pages are showing the wrong price, always using the price of the first variant it finds, not the current one.
The issue was introduced in Odoo 18.0 with commit [1].

- Create a product.template, add it some variants and for each variants have a different price (eg through the variant extra price).
- That product should be a service one
- Create an appointment, enable "Up-front payment" in the "Options" tab and add it one of the variant product. Note that it's a variant product that you set there, not a template.
- You should see next to the variant product you just selected a price per booking being displayed. It is correctly showing the product variant price and not the product template price.
- Repeat those 2 steps with the other product variants: create a new appointment and select another variant, you can see the price is correct in the form view.
- Now, go to the website appointment page `/appointment`, you will see that all those appointments will show the same price which is the one from the first variant.
- The same price error will appear once you click on an appointment (you should land on something like `/appointment/4?`)
- Note that if you go further in the appointment booking and land on the shop cart page, the price will be correct there, using the correct variant one. (You'll need to assign a user on the appointment in the backend to be able to book a slot)

Side note: Commit [1] seems to have broken commit [2] too.

[1]: https://github.com/odoo/enterprise/commit/26fb20ace27b7b522a1105c221e4a52cf224a508#diff-5ffc6d13c61e692b22e4c2fec9218cf96c0c86201aeac951ef36e53e7baa7620R4-R9
[2]: https://github.com/odoo/enterprise/commit/5068b0ae7d38cb03318ad1e97124021121fd66cb

opw-4678998

Forward-Port-Of: odoo/enterprise#83104

Description
-----------
When clicking the sharing button on a knowledge article, the system retrieves all members linked to the article. This includes members directly tied to the article or inherited through parent articles ( stopping at the first desynchronized article). In databases where articles have numerous associated members, the
`_get_article_member_permissions` method suffers from severe performance issues. It retrieves *all* articles and their associated members, collects all parent articles in the hierarchy, and only then applies grouping and filtering based on the `id` of `self`. This process includes a `LEFT OUTER JOIN` on related tables to fetch specific `fields` passed as arguments, resulting in an O(n^2) complexity on large tables such as `res.partner` and `knowledge.article.member` (the latter being a Many2many relationship that typically contains a high volume of rows).

This patch improves performance by shifting the grouping and filtering logic to the start of the process, effectively injecting all preconditions at the base of the recursion. This reduces the hierarchy of articles and memberships to explore. Additionally, the computation of inherited permissions—sourced from the "closest" ancestor article—is now handled at the SQL level instead of Python. This eliminates unnecessary rows in the process, avoiding unnecessary work in the business logic afterward.

Benchmark
---------
On a client's database with around 600 articles, 5k partners and 15k knowledge.article.member in total, for a specific article which has a total of 1.7k members (direct and inherited):

| Request                        | Before  | After | Speed-up  |
|--------------------------------|---------|-------|-----------|
| `_get_article_permission_data` | 4.7+min | 150ms | **1880x** |

Reference
---------
opw-4603551

Forward-Port-Of: odoo/enterprise#81264

**Year to date computation improvements**

-   Some inputs on the YTD can go to multiple rules. Therefore,
    we add manual recomputation of the inputs for payslips.
    It uses opening balances to compute the total payslip YTD
    values.
-   A major update is the addition of Income Stream types to
    Year to Date values. This allows for grouping payslips with
    income stream type for employees that may have multiple income
    stream through a single fiscal year. STP requires reporting
    the year to date values for each income stream type separately.

**Single Touch Payroll Improvements**

-   Adds income stream types to the STP report. This
    allows for users with multiple income streams in
    a single fiscal year to be repored without finalisation.

-   Fixes Termination payments for genuine and
    non-genuine redundancy payments and how taxes are
    reported for taxible and non-taxible components.

-   Fixing Full file replacement for STP. This adds
    constrains for FFR, allows old payments to auto reconcile
    on a changed payslip after resubmission.

-   Adds support for missed reporting of payslips.
    If a user forgets to report a pay period and continues
    with the next pay period, They have 2 options:
        1.  Create a back dated submit event with the old
            year to date values.
        2.  Create an update event that amends the year to date
            values at todays date.
    In odoo we go for option 2. For a missed report, we create an Update
    event that updates all the ytd values up til today's date.

-   Fixes zeroing of YTD on Single touch payroll.

-   Adds a correction input type for Basic salary corrections
    without having to make any changes to past payslips. This helps
    cover under or over-payments

-   Improve validation for Single touch payroll. With better
    testing and file generation. This adds better error
    handling before running the xml validation step. This
    lowers the possibility of errors after file generation.

-  Improve performance for YTD computation to allow batching and
   caching of the values using computes on the payslips. Relies fully 
  on the ORM using search_fetch to optimize queries for the YTD 
  computation. 
    
**AU Payroll Payment reconciliation**

-   Allows old payments to auto reconcile on a changed
    payslip after resubmission.

**Standard Fixes**
-   Allow auto install of hr_payroll_account if accounting and Payroll
    app are installed. This also subsequently installs localised versions.

-   Payment register wizard fails to compute the amount, journal, etc
    since the `_compute_from_lines` is not triggered. This is because
    partner_id is the only field in the view to trigger that compute before
    create. And when a default value is passed for the partner, there is no
    need for the compute to trigger on a new record before save.

-   Salary attachments with the same code inputs always
    used the last input in the sequence for all attachments.
    This commit changes the behavior to allow multiple
    attachments with the same code inputs.
    
    
-   Salary rules generate multiple payslip lines for
    multi rule lines, but the result_rules in the
    local_dict are not updated. This commit fixes that
    and sums up the totals and amounts for all the lines
    in that rule.
    
    Task# 4201469

Forward-Port-Of: odoo/enterprise#83038
Forward-Port-Of: odoo/enterprise#75695

Currently, an exception is generated when a user tries to save a product record without a barcode, whether it is a newly created record or an existing one.

Steps to reproduce:

1. Install the Inventory module.
2. Go to Inventory settings.
3. Set Barcode Nomenclature to Default GS1 Nomenclature.
4.  Go to Inventory -> Products, create a product with a barcode, and save it.
5. Edit the same product, remove the barcode, and save it again.
6. An error occurs.

Error: `StopIteration`

This issue [1] occurs because when a user tries to save the record without a barcode, the value is false, and an false value is not iterable.

[1] - https://github.com/odoo/odoo/blob/9eb6c16cd7d4fe9364d043e2af96876bf82a44d4/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L163

This fix resolves an issue where GS1 preprocessing was always applied when checking for duplicate product barcodes. By introducing the skip_preprocess_gs1 context flag, the GS1 preprocessing step is now bypassed when verifying barcode uniqueness.

Related Community PR:- https://github.com/odoo/odoo/pull/196438

sentry-6267124218

Forward-Port-Of: odoo/enterprise#80544