Description
-----------
Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant `order_id` `id` or `project_id`. `project_id` is not indexed, leading to a heavy non-selective scan on the primary key for databases with many `sale. order` records. There is poor selectivity with the filter on `sale. order.line` resulting in a heavy join between `sale.order` and `sale.order.line`.

This commit adds the missing index, allowing for `Bitmap Heap Scan` on both indexes and leveraging the selectivity of the project being currently opened.

Benchmark
---------
On a database with 3.5M `sale.order`, 12M `sale.order.line`, opening the "Settings" page of a project with a few sale lines associated with it took:

|              | Before | After |
|--------------|--------|-------|
| Timing (hot) | 9.1s   | 5ms   |

Reference
---------
opw-5280364

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

Forward-Port-Of: odoo/odoo#239114
Forward-Port-Of: odoo/odoo#238995

Step to reproduce:
- Install l10n_in_hr_payroll.
- Create 3-4 employee with labour welfare fund, all in different departments.
- Open the LWF report wizard and do not select any department.
- Download report , all employee will come in report.
- Now select any department and download report again.
- All employee(It is fetching previous data) + employee from selected
  department will come in report.

Cause:
- In '_compute_line_ids()' wizard computed field 'line_ids' doesn't properly
   reset previous lines as a result previous data remains in lines.
- When the department is changed, the wizard id remain same,
  so previously lines added to wizard are coming with new lines.
- Using `Command.link()` for new lines is invalid because it requires an
  existing database record ID, but wizard lines are creating inside a compute
  method so their IDs are only saved after the flush.

Fix:
- Since this is a stable version, clear the previously existing lines using
  'Command.clear()' before creating new ones.

Task - 5366498

Forward-Port-Of: odoo/enterprise#101190

Clicking a record in the Employee Skills pie chart report currently triggers a traceback.

Steps to reproduce the error:
- Install ``hr_skills`` module with demo data
- Open any employee > In Resume tab, Click on TIMELINE
- Switch to Pie chart > click on any record

Traceback:
```py
UndefinedColumn: column hr_employee_skill_history_report.id does not exist
LINE 1: SELECT "hr_employee_skill_history_report"."id" FROM "hr_empl...
```

``hr.employee.skill.history.report`` model is ``_auto=False``,
meaning that no database table is created for this model.
In earlier versions, clicking on the record opens the list view.
In the [commit](https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e), list view was removed.
So, now clicking on the record will lead to the above traceback.

[1]: https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e

sentry-7099766240

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

#### [FIX] snailmail: extract report PDF generation function
We extract a function `_generate_report_pdf` from `_fetch_attachment`
to create the report PDF (and its filename).
The resulting PDF's margins are fixed and a cover page is added to it
after the function is called in `_fetch_attachment`.

The new function is extended in the related enterprise commit to generate the
followup report inside `_fetch_attachment` (when sent via snailmail).
This way it will respect the cover page option and page layout / size requirements.
(See the related enterprise PR for more details.)

#### [FIX] snailmail: extract letter resending function

We extract a function `_resend_letters` from the `update_resend_action`.
It handles the regeneration of letters after the cover option has been updated.
This way the resending logic can easily extended to adjust the logic depending
on attributes of the letter.

The new function is extended in the related enterprise commit to disable
the resending for followup report letters.
This is necessary because the followup report requires special options
to be generated that are not available at the point of the regeneration.

#### references

opw-5160121
opw-5209504
opw-5226366

Forward-Port-Of: odoo/odoo#238905
Forward-Port-Of: odoo/odoo#235699

#### [FIX] snailmail_account_followup: fix address, cover page and layout

Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
   lead to problems with the service we use to send the actual letter.
   They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
   So we can not work around problems with the address generation
   by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
   with our current snailmail provider (Pingen). But there is no error
   message about it. (Although we do have something in the usual
   snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
   so the user does not receive any feedback.
   This could be an issue in case multiple follow-up reports are sent
   at the same time.

This commit fixes these issues. (See below for details.)

(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.

(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
  not rejected by Pingen because of this

But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.

(4)
We try to print / send the letter even if the address is invalid

Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
   (Settings -> Accounting -> section "Customer Invoices")
   - enabled to test for the cover page
   - disabled to test that the address generation is adjusted
4. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
   In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
   (or just search for "snailmail" in the main screen)
   And select the letter
6. Download the PDF document

#### [FIX] snailmail_account_followup: forbid regenerating failed letters

The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.

Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).

After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.

Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
   Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)

#### references

opw-5160121
opw-5209504
opw-5226366

Forward-Port-Of: odoo/enterprise#101596
Forward-Port-Of: odoo/enterprise#99491

Steps to reproduce
-----
- Enable batch pickings
- Create a product
- Create 2 receptions for the product (qty > 1)
- Create a batch with the 2 transfers
- Open the batch in barcode
- Scan part of both pickings
- Go back to the barcode main screen
- Open the batch again

> Both pickings have their demand = partially delivered quantity

Cause
-----
When leaving the page, we trigger

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68

in which we end up merging the moves together

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51

This has been added by 9753c24 (ade0bef in 17.0)

The problem is that `_merge_moves` merges all of the moves into the first of `merge_into`

https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088

This, however, doesn't make much sense for batches because the moves can be from different pickings.

-----
Ticket:
opw-5163740

Forward-Port-Of: odoo/enterprise#101630
Forward-Port-Of: odoo/enterprise#100940

BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there

**issue**:
When previewing the document, it still shows the old attachment name.

**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:

1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130

2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383

**solution**:
Use the document name when previewing it

BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.

**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.

**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.

Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.

**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.


**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
    After:
   <img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>

</details>

opw-5065433

Forward-Port-Of: odoo/enterprise#101183
Forward-Port-Of: odoo/enterprise#95111

Issues:

1. Resetting options when dialog is closed without modification:
When the media dialog is closed without changing any options
and "Add" is clicked, the videoSelector component is reset, causing
previously selected parameters to be lost.

- Steps to reproduce:
    - Drop a Video snippet.
    - Double-click the snippet and toggle a few options (e.g., "Loop").
    - Save the video configuration.
    - Double-click the snippet again to open the video configurator.
    - Save without making any changes.
    - The options will be reset.

2. Embedding videos via Powerbox does not capture URL query parameters:
When embedding a video via Powerbox, option values from the URL
query parameters (like loop or autoplay) are not correctly applied.

- Steps to reproduce:
  - Add any Text snippet.
  - Paste a YouTube video URL with query parameters (e.g., ?loop=1&autoplay=1).
  - Choose to embed the YouTube video from the Powerbox popup.
  - The Video snippet is added without options enabled for the pasted URL.

3. Manual URL editing does not synchronize options:
Editing the video URL manually does not update the toggle states
of corresponding options.

- Steps to reproduce:
  - Drop a Video snippet.
  - Double-click the snippet and append query parameters to the URL.
  - The option buttons should toggle according to the parameters, but they do not.

4. Dailymotion preview fails for protocol-independent URLs:
Previewing Dailymotion videos fails for URLs like //[www.dailymotion.com/](http://www.dailymotion.com/)....

 - Fixes implemented:
    - Preserve selected options when saving the Video snippet without any changes.
    - Retrieve all query parameters from the URL and include them in the RPC request.
    - Synchronize option toggles with the URL input when the user manually edits it.
    - Fixed the Dailymotion regular expression to support protocol-independent
    URLs (e.g., //[www.dailymotion.com/](http://www.dailymotion.com/)...).

task-4529118

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

Forward-Port-Of: odoo/odoo#238732
Forward-Port-Of: odoo/odoo#210596

### Issue:
When installing "l10n_tr_nilvera" on a new DB the Turkish language is installed but
the translation of previously installed modules are not updated.

### Steps to reproduce:
- Install 'l10n_tr_nilvera' and switch to a Saudi company
- Check the view "report_invoice_document"
- Click the translation icon on the view
- No Turkish translations are loaded

### Cause:
When installing "l10n_gcc_invoice" the Arabic language is installed ([src](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/addons/l10n_gcc_invoice/__init__.py#L4-L5)). But the method [`_activate_lang()`](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/odoo/addons/base/models/res_lang.py#L161-L169) only activates the language, it does not update the translations.

### Solution:
Create a new method that activate the language and calls `_update_translations()` on the installed modules.

opw-5219783

Forward-Port-Of: odoo/odoo#239310
Forward-Port-Of: odoo/odoo#237041

This improvement enhances user control over cookie preferences by making
the Cookie Policy page (/cookie-policy) more accessible and allowing
users to modify their consent at any time.

**Issue:**

- Previously, the only way to access the Cookie Policy page was through
  the link in the cookie consent popup. However, once users accepted
  cookies, the popup was no longer displayed, making it impossible to
  navigate to the policy page later.

- Additionally, the Cookie Policy page had a button to reopen the cookie
  consent popup, but it was only visible if cookies were not accepted.
  Once cookies were accepted, the button was hidden, preventing users
  from changing their preferences.

**Improvements:**

- Added a permanent link to the Cookie Policy page in the copyright
  footer, ensuring it remains accessible at all times.

- The cookie consent toggle button now remains visible even after a user
  has accepted cookies, allowing them to update their preferences at any
  time.

task-[4502416](https://www.odoo.com/odoo/project/974/tasks/4502416)

Forward-Port-Of: odoo/odoo#238772
Forward-Port-Of: odoo/odoo#203409

Currently, an error occurs when trying to create a consolidated invoice for 
multiple POS orders associated with the same customer.

**Steps to reproduce:**

- Install the `l10n_sa_pos` module and switch to the `SA company`.
- Create two POS orders for the `same customer` without invoicing at checkout.
- Close the POS session and go to `Point of Sale` > `Orders`.
- Select both orders > click `Create Invoice` > `confirm` the action. (Make sure `Consolidated Billing` is enabled)

**Error:**
`ValueError: Expected singleton: pos.order(8, 7)`

**Root cause:**
At [1], the code accesses `self.date_order` and `self.l10n_sa_reason`, but when 
consolidated billing is enabled, self contains multiple POS orders, which 
causes an error.

**Fix:**
This commit prevents the error by ensuring that the current datetime is
assigned when creating a consolidated invoice, same as [2]. 
For the refund reason, a fix similar to [3] has been applied.

[1]:
https://github.com/odoo/odoo/blob/0c87b6b8836522913dbe77b57a018ac26012edca/addons/l10n_sa_pos/models/pos_order.py#L17-L18

[2]:
https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/point_of_sale/models/pos_order.py#L828-L832

[3]:
https://github.com/odoo/odoo/blob/0c87b6b8836522913dbe77b57a018ac26012edca/addons/l10n_es_edi_tbai_pos/models/pos_order.py#L103-L107

opw-5266908

Forward-Port-Of: odoo/odoo#237677

Before this commit, internal URLs (i.e. "blob:" and "data:") required                                                                                                                     
'fetch' to be mocked to work. This is wierd because these requests are                                                                                                                    
handled directly by the browser and shouldn't require any particular                                                                                                                      
manipulation from the (mocked) server.                                                                                                                                                    
                                                                                                                                                                              
This commit ensures that internal URLs still work without fetch being                                                                                                                     
mocked.    

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

Forward-Port-Of: odoo/odoo#239237
Forward-Port-Of: odoo/odoo#239011

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

opw-4760550

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

Forward-Port-Of: odoo/odoo#236014
Forward-Port-Of: odoo/odoo#233757

Currently, updating a POS appointment reservation from the gantt view to increase the number of people does not update the allocated resources. The booking modification is not saved and the UI appears unchanged.

Steps to Reproduce:
1) Install Restaurant and Appointments app with a demo. Enable booking for the restaurant 
2) Open POS restaurant and go to Booking, switch to Gantt view. 
3) Create a reservation for 2 people on a table with capacity 2. 
4) Edit the booking to 4 people and add another table with capacity 2 and save. 
5) The reservation remains at 2 seats and changes are lost.

Root cause:
After [this commit](https://github.com/odoo/enterprise/pull/81810/commits/e710cebceab096f48e044b5b0229de743a204864), the field `waiting_list_capacity` was introduced but the write() method was not present to propagate this value to
`resource_total_capacity_reserved`, causing incorrect capacity computation in the `_inverse_resource_ids_or_capacity` method at [1].

FIX:
Add `write()` to propagate `waiting_list_capacity` into `resource_total_capacity_reserved` to ensure correct recompute and resource update.

[1]- https://github.com/odoo/enterprise/blob/763b34029253a786d1e4bf09a780c1fb799f0ba5/appointment/models/calendar_event.py#L265-L266

Before Fix:
<img width="1911" height="965" alt="image" src="https://github.com/user-attachments/assets/1470c656-7e8b-42bc-96c5-1fd240489ec0" />

After Fix:
<img width="1909" height="961" alt="image" src="https://github.com/user-attachments/assets/ce3b1a46-4e33-42f8-a902-461e05220c23" />


Note:
This fix needs to be merged only in versions 18.3 and 18.4. since in version 18.0-18.2 and 19.0 the `resource_ids` is calculated based on `resource_total_capacity_reserved`(for 18.0-18.2) and `total_capacity_reserved`(for 19.0).

opw-5354559

**PROBLEM**
With a Mexican company, when trying to send a CFDI with a global discount, it can happen that after the repartition of the discount we have lines with a negative amount, so we can't send the CFDI.

**STEP TO REPRODUCE**
1. Take a Mexican company
2. create a quotation with, product A = 1$, product B = 100$, global discount of 15%
3. create an invoice using this quotation, confirm it and try sending the CDFI.
4. the following error will appear : "Error when sending the CFDI to the PAC: Failed to distribute some negative lines"

**CAUSE**
In account, the function `_normalize_target_factor()` takes a list of dictionary `target_factors`, with the keys being invoice lines (the targets) and the keys being weights (the factors). It is used to normalize the weight associated with the lines, to later use them to dispatch things like discounts to those lines. This function also does a sort on the weight, and return a list containing pairs of index and weights. This is useful only in the function `_distribute_delta_amount_smoothly()`, other functions doesn't work well with the sorted returned list: they don't use the index, and dispatch discounts to the wrong lines.

https://github.com/odoo/enterprise/pull/101109 adds a test in l10n_mx to reproduce the client use case.

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

opw-4760550

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

Forward-Port-Of: odoo/odoo#236014
Forward-Port-Of: odoo/odoo#233757

## Reproducing steps
1. Create a DB with demo data (hr,hr_payroll,accountant modules)
2. Set the bank account of Mitchell Admin (in Personal employee notebook page): create a new one by specifying the account number (here is a random account IT22M8576110068R4A56E760901) and setting it as "trusted")
3. Set the bank account of the Internal Revenue Service (IRS) partner (also set it as trusted, and here is another random account: IT77H400725028682A0R202P050)
4. Create a new Off-Cycle Payslip : 
a. Payroll -> Payslips -> Payslips -> New Off-Cycle button
b. Set Mitchell Admin as the employee of the payslip
c. Change the Structure to "United States: Regular Pay"
d. Compute Sheets
5. Create payments :
a. Go to the Journal Entries linked to the payslip, and Post them
b. Go back to the payslip and 'Pay'
c. In the new wizard: Click on 'Create Payments'
6. Go back to the journal entries, a new button should've appeared on top of the page for the payments (click it now!)
7. Click on the PAY00001 (it the Federal Income Tax which is made to the Internal Revenue Service (ISR) and notice that the bank account used in payment is the bank account of the employee (should be the ISR account obviously)

## Purpose
Modifying `account.payment.register` for fixing `hr.payslip` payments generation so that each payment is assigned the correct `partner_bank_id`.

Also, fixing a SEPA payslip payment bug which says that the employee bank account is untrusted even if it isn't. 

## Tests
Adding `test_bank_account_partner_payment_payslip` test to check that the payment generated for Professional Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment).

Adding `test_sepa_payslip_partner_bank_id` test to check that the `partner_bank_id` is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the `account_register_payment` wizard) doesn't raise any error.

This second test is not really specified in the specs, I just stumbled upon some stacktrace when coding this PR and decided to add a test to check the flow of sepa payment.

[community#235475](https://github.com/odoo/odoo/pull/235475)
[task-4979220](https://www.odoo.com/odoo/action-4043/4979220)

Forward-Port-Of: odoo/enterprise#99373

…f related line is complete

### Steps to reproduce:

- In the settings enable Lots & Serials and Batch transfers
- On the delivery operation types enable show reserved lots in the barcode tab
- Create a storable product tracked by lots and put 10 x lot1 in stock
- Create and confirm a delivery for 10 units
- Create a batch transfer with your delivery
- Process your transfer from the barcode app
- Scan one unit of LOT1 and put in pack
- Toggle sublines select the 0/9 subline without lots nor package
- Scan LOT1
#### > The 1/1 LOT1 line with a pack is updated to 2/1 rather than the 0/9

### Cause of the issue:

Since e45249c2f6883d743a4e7d19e736c622e26a3d58 and 27bfb985a29e9f0abe94dec8a76bf6d08560fbc9 an override of the `_findLine` method has been introduced in `BarcodePickingBatchModel` to ensure that scanning a lot referenced by an already existing line of the batch transfer triggers an update of that line rather than an override of the lot of an other line. However, these lines should not priorities a completed line when there is line without a set lot.

opw-5340865

Forward-Port-Of: odoo/enterprise#101611

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#101625
Forward-Port-Of: odoo/enterprise#100275

### Issue:
The field `l10n_sa_leaves_count_compensable` is a computed field with no compute method.
When in debug mode, trying to look at the fields of an employee results in a traceback because of this.

### Cause:
This [forward port](https://github.com/odoo/enterprise/commit/4124dc4c13055d39d233d7ea9374b5191afdfcf2#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5) had a conflict that was badly resolved by re-adding a previously deleted field.
The field was replaced by `l10n_sa_remaining_annual_leave_balance` in [this commit](https://github.com/odoo/enterprise/commit/339bc032aa763c62d4dd27b73fc42488b3e1c3aa#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5).

[Failing FWP](https://github.com/odoo/enterprise/commit/b3f276d0d73a24faf322aa2ae8965c3d5aad4a87#diff-1d84d9d2c9ad02353f40d1b88baa5c66af063880df1e14459befd2d02d66cae5)

### Solution:
We can no longer delete the field because of the stable policy. The solution is to remove the compute and add `store=False`. Then remove the field in master.

opw-5352456

Forward-Port-Of: odoo/enterprise#100756

Currently, an error occurs when a user sets the partner on a statement line.

**Steps to Reproduce**([video](https://drive.google.com/file/d/1ZQBBh4yjSljeqqL_jT8dh_QJ6LtFZdPb/view)):
 - Install the `account_accountant` module.
 - Go to `Invoices` and create `two invoices` with the `same partner` and the `same total amount` by adding 
    an `invoice line`.
 - Go to the `Dashboard` and click `Last Statement` under the `Bank journal`.
 - Create a `new statement line` with the `same amount` as the `invoice amount`.
 - Click `Set Partner` and select the `same partner` used in the invoices.

`TypeError: '<=' not supported between instances of 'bool' and 'datetime.date'`

After [this commit], when a user sets the partner on the statement line, the system attempts to automatically reconcile the line. It then searches for a single invoice matching the statement line amount [1] and tries to select the one with the closest prior or equal date. However, draft invoices have not an invoice_date, and when the system attempts to filter on this field, and the error is raised [2].

This commit ensures that the comparison between invoice date and statement date occurs only when the invoice date is present.

[this commit]: https://github.com/odoo/enterprise/pull/98269

[1]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L585

[2]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L249

sentry-7063516380

Forward-Port-Of: odoo/enterprise#100576

**Steps to reproduce:**
* Install the **Türkiye - Nilvera E-Invoice (l10n_tr_nilvera_einvoice)** modules
* Configure test mode following the [setup guide](https://docs.google.com/document/d/1EUzvTBnSm9-VwIfBsX299MHGXIVys-uijnsJ1fpz7vI/edit?tab=t.0).
* Create a bank account for the main company and fill the **Bank** selector (bank identifier dropdown).
* Create and attempt to send a customer invoice via Nilvera.

**Observed behavior:**
* A server error occurs: `KeyError: 'country_id'` in `l10n_tr_nilvera_einvoice/models/account_edi_xml_ubl_tr.py` at line 172 while generating `<cac:PayeeFinancialAccount>`.
* The invoice cannot be sent.

**Cause:**
* `_get_address_node()` determines field names using `vals.get('model', 'res.partner')`.
* When the parent class calls `_get_address_node({**vals, 'partner': bank})` with a `res.bank` record, it does **not** pass a `model` parameter.
* The method falls back to `'res.partner'` and attempts to read `country_id` from a `res.bank` record, which instead uses the field `country`.
* This mismatch triggers a `KeyError`.

**Fix:**
* Detect the appropriate field set by checking `partner._name` rather than relying on `vals.get('model')`.
* Use `country` / `state` when the record is `res.bank`.
* Use `country_id` / `state_id` when the record is `res.partner`.

opw-5380246

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

opw-4760550

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

Forward-Port-Of: odoo/odoo#236014
Forward-Port-Of: odoo/odoo#233757

Description
-----------
Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant `order_id` `id` or `project_id`. `project_id` is not indexed, leading to a heavy non-selective scan on the primary key for databases with many `sale. order` records. There is poor selectivity with the filter on `sale. order.line` resulting in a heavy join between `sale.order` and `sale.order.line`.

This commit adds the missing index, allowing for `Bitmap Heap Scan` on both indexes and leveraging the selectivity of the project being currently opened.

Benchmark
---------
On a database with 3.5M `sale.order`, 12M `sale.order.line`, opening the "Settings" page of a project with a few sale lines associated with it took:

|              | Before | After |
|--------------|--------|-------|
| Timing (hot) | 9.1s   | 5ms   |

Reference
---------
opw-5280364

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

Forward-Port-Of: odoo/odoo#239338
Forward-Port-Of: odoo/odoo#238995

Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module.

**Steps to Reproduce:**
1. Install `hr_appraisal_skills` without demo data.
2. Create a new company and switch to it.
3. Appraisals > Click "Load sample data".

**Traceback:**
```
AccessError
Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Sengsourigna Phonkaseumsouk (id=2) doesn't have 'read' access to:
- Employee, Emma Granger (hr.employee: 3, company=TPX Solutions)

Blame the following rules:
- Employee multi company rule

If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.

This seems to be a multi-company issue, you might be able to access the record by switching to the company: TPX Solutions.

ParseError
while parsing /home/odoo/src/enterprise/19.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside <function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref('hr_appraisal.hr_appraisal_2')]"/>

ValueError
ParseError('while parsing /home/odoo/src/enterprise/19.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside\n<function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref(\'hr_appraisal.hr_appraisal_2\')]"/>') while evaluating 'action = model._load_demo_data()'
````
**Cause:**
The demo data loading process attempts to access employee records without the required permissions. Since the user belongs to a different company, the multi-company security rules prevent reading those employees.

**Fix:**
This commit resolves the issue by using sudo during demo data loading to ensure the required access rights are granted.

sentry-7032880299

**[IMP] account: Add new tax helpers for EDI** (backport)

task_id: 5096249

**[FIX] account_edi_ubl_cii: Fix management of fixed taxes** (backport)

This commit contains 2 things:
- an helper to extract any tax_data and move it to another base_line
- the usage of this helper in UBL to turn emptying taxes into additional base_lines

== Add helpers to turn tax_data into new base_lines easily ==

With this helper, you can now exclude any tax from any base line and turn
them into new base lines.

Also, I changed a bit the smooth distribution of rounding because the math.ceil
is sometimes too greedy and make the whole results to be less accurate.

== Make a different behavior between recycling contribution taxes / emptying taxes ==

In UBL, all fixed taxes are treated as allowances/charges.
In this commit, we make a clear distinction between recycling contribution taxes
that are treated as allowances/charges and emptying taxes that are exempted of tax
and are treated as addition invoice lines in the document.

== Fix a small issue with aggregate_function passed to reduce_base_lines_with_grouping_function ==

The aggregator wasn't called when setting the 'target_base_line' at the very first time.

task_id: 5182783

**[FIX] account_edi_ubl_cii: Reword export BIS3**

- Separate the BIS3 from the annoying dependency between all the UBL files.

You are not supposed to generate an UBL 2.0 & 2.1 UBL files. Those are templates
with all the options you have to build your format on top of it. However, since
we used them as a hierarchy and since most of the code and implementation are
inside UBL 2.0, "fixing" any use case for one single implementation has impacts in
all others.
In order to fix issues about ways amounts are computed in BIS3, we first split BIS3
to be independant from UBL 2.0 / UBL 2.1 but using new generic helpers that could be
used for any single format.
The future goal will be to make all formats independant but that part is already big
enough and we are in a hurry. "To be continued in a next PR"

- Reword the test suite for exported files to be more explicit about which test is testing what exactly.

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

### Issue:
When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs.

### Steps to reproduce:
- Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step)
- Refuse all time off for "Anita Oliver" (to avoid side effect in next step)
- Create a user for the employee "Anita Oliver"
- Link the employee and the user
- Create 2 payslips
	- 1 for "Mitchell Admin"
	- 1 for "Anita Oliver"
- Compute sheet and confirm both payslips
- Run scheduled action: "Payroll: Generate pdfs"
- Nothing happens

### Cause:
The traceback is raised on the line `self._get_document_partner().id`
 because `_get_document_partner()` can return a recordset.

### Solution:
Call `ids` instead of `id`.

### Note:
Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`.

The final code works fine as `_check_create_documents()` is called agion individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86).

opw-5213979

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

**Steps to reproduce:**
- (Firefox only)
- Go to any record which uses a chatter (e.g. Contact)
- Send message > Full composer > click the schedule message icon (lower right corner)
- Schedule the message in the future and click send
- You should see now a post in the chatter indicating that the message will be sent
- Now click Send message and repeat the above steps again to schedule a second message
- Whole page will be freezed
- Reloading doesn't help

**Issue:**
Infinite loop in reactive callback on firefox.
The code gets stuck in
```js
for (const callback of [...callbacks]) {
    clearReactivesForCallback(callback);
    callback();
}
```
because of
```js
const sortProxy2 = reactive(recordProxy, function sortObserver() {
    self.requestSort(record, fieldName);
});
this.fieldsSortProxy2.set(fieldName, sortProxy2);
```
which loops over `store._.ADD_QUEUE("sort", record, fieldName);`

(Forcing the `requestSort` only change the infinite loop into a recursion error)

The recomputation seems to be caused by a bad sorting here:
```js
this.scheduledMessages = Record.many("ScheduledMessage", {
    sort: (a, b) => {
        if (a.scheduled_date === b.scheduled_date) {
            return a.id - b.id;
        }
        return a.scheduled_date < b.scheduled_date ? -1 : 1;
    },
```
In the case both datetimes are equal the first condition doesn't properly catches it:
```
> a.scheduled_date - b.scheduled_date
> 0
> a.scheduled_date === b.scheduled_date
> false
> a.scheduled_date < b.scheduled_date
> false
> a.scheduled_date > b.scheduled_date
> false
```
Which make the ordering change on each sort iteration:
```
>  Array [ "ScheduledMessage,14", "ScheduledMessage,13" ]
> recordsFullProxy.sort(func);
>  Array [ "ScheduledMessage,13", "ScheduledMessage,14" ]
> recordsFullProxy.sort(func);
>  Array [ "ScheduledMessage,14", "ScheduledMessage,13" ]
```
Chromium based browsers probably use a different sorting algorithm than Firefox, which seems to prevent the issue.

**Fix:**
Use `compareDatetime` to ensure the ordering is constant for the same datetime values.

opw-5367371

Version
- 18.0

Steps to Reproduce:
Issue 1: Incorrect tooltip text
  1. Go to Products → Products in subscription app.
  2. Open a product page and select goods product type
  3. observe product_tooltip show incorrect wording:
       * "Based on order" showed end of the period.
       * "Based on delivered" showed beginning of the period.

Issue 2: Product card shows both recurring and sales price
  1. Go to Products → Products in subscription app.
  2. Observe that the product card displays both recurring price and sales price

After this PR:
- Tooltip now correctly states:
   * for "based on order" invoice_policy -> beginning of period
   * for "based on delivery" invoice_policy -> end of period
- Product cards show only the recurring price when applicable.

task-5156390
<img width="1002" height="436" alt="image" src="https://github.com/user-attachments/assets/39f00555-e37a-44a5-8786-d7f8d6882de7" />
<img width="968" height="262" alt="image" src="https://github.com/user-attachments/assets/0d6d5c2d-d5ab-4376-bc03-dba243abce8b" />

Currently a user that connected to a pos user cannot go backend if he was not the person who opened the session the first time.

Steps to reproduce:
-------------------
* Modify settings of the shop to use employee feature
* Make sure admin and demo can access the shop, set them advenced employee for example.
* Logged as Mitchell Admin, open the pos (It should have been closed before)
* Use Mitchel admin employee
* Complete cash control
* Go backend
* Log out
* Log back in with Marc Demo
* Enter the shop (it was already "opened" by Admin)
* Use Marc demo employee
* Now try to see the backend button
> Observation: Backend button is not available

Why the fix:
------------
Quoting this commit: https://github.com/odoo/odoo/commit/61df2871e1aac0144d26022a2a49c75ea9ecad4a
> Now, the only employees that can go back to the backend are those binded to the user connected.

However, `this.pos.session.user_id` only reflects the user who opened the pos the first time, in our case Mitchell Admin. It does not represent the connected user.

opw-5276950

### Issue:
In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file.

### Steps to reproduce:
- Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company
- Make sure the company has a "Partena Affiliation Number"
- Create an employee for this company, with a "Partena code"
- Create a contract for this employee, set it a running
- Create a new Belgian company with a different "Partena Affiliation Number"
- Activate both Belgian companies, but set the second one as active
- Payroll > Reporting > Export work entries to Partena
- Create a new one, populate it with the employee just created
- Click "Generate Export File"

### Cause:
When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values.

### Solution:
Use `self.company_id` instead of `self.env.company_id`.

Also adds the test class with basic tests.

opw-5345786

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

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

Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered.

Steps to replicate:
- Install `sale_management` with demo and create a new SO.
- Add a combo product and remove the combo name and click Edit Configuration (pencil icon).

Error:
`TypeError: SaleProductConfiguratorController.sale_combo_configurator_get_data() missing 1 required positional argument: 'product_template_id'`

Cause:
- When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_combo_configurator_get_data()` which expects `product_template_id` at [1] and since it is removed from order line the error is encountered.

Solution:
- Changed the content of method `isCombo()` to use the product_template_id to make sure the Edit Configuration is only visible when product template is present.

Similar PR for reference: https://github.com/odoo/odoo/pull/217464

[1]: https://github.com/odoo/odoo/blob/fa4307b9758800f26c9ee87cf3698fd60bfd1ab5/addons/sale/controllers/combo_configurator.py#L12-L14

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

uprade pr: https://github.com/odoo/upgrade/pull/8648

**Steps to reproduce:**
1. Install `eCommerce` and `Rental` modules.
2. Create a rental product.
3. Create a new attribute with two values with extra price. Set display type to multi-checkbox.
4. Add attribute and its values to the product.
5. Activate rental for the product and configure rental pricing.
6. Open the product page on the eCommerce store.
7. Select values from both attributes including multi-checkbox options.

**Observed behavior:**
* Multi-checkbox attribute values can be selected, but their extra prices are ignored in the cart subtotal and product configurator price display.

**Root cause:**
* The rental pricing logic bypassed the standard price computation that includes extra prices from no_variant attributes. In `_get_pricelist_price()`, the rental price was computed using rental-specific rules without adding extra prices from `product_no_variant_attribute_value_ids`. Similarly, in the product configurator (`_get_combination_info_variant()`), price_extra from no_variant attributes was not added to the rental price. The template also hid extra price badges for rental products.

**Solution:**
1. In `sale_order_line._get_pricelist_price()`, add extra prices from no_variant attributes after computing the rental price.
2. In `product_template._get_combination_info_variant()`, add `price_extra` to `current_price` for rental products.
3. Remove the template override that hid extra price badges for rental products, allowing customers to see extra prices in the product configurator.

opw-4937869

In OCA we develop a module that assigns dynamic attributes to a product. In odoo 16.0 and prevous 14.0 the module is running smoothly with odoo. In this version convert_to_read method is introduced and it deals with use_display_name and value, it assumes value record is always has a value Aluthough use_display_name can be False or value record can be empty. In that case I retun False instead of causing the server to raise error because it assumes value has id and it is just an empty recordset.

Description of the issue/feature this PR addresses:

Current behavior before PR:

========================================================================================

2025-02-19 20:15:58,724 46176 ERROR pim_17_1 odoo.http: Exception during request handling. 
Traceback (most recent call last):
  File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 2206, in __call__
    response = request._serve_db()
               ^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 1782, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/service/model.py", line 133, in retrying
    result = func()
             ^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 1809, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 2013, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/addons/base/models/ir_http.py", line 221, in _dispatch
    result = endpoint(**request.params)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/addons/web/controllers/dataset.py", line 24, in call_kw
    return self._call_kw(model, method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/addons/web/controllers/dataset.py", line 20, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/api.py", line 468, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/addons/web/models/models.py", line 86, in web_read
    values_list: List[Dict] = self.read(fields_to_read, load=None)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/models.py", line 3557, in read
    return self._read_format(fnames=fields, load=load)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/models.py", line 3770, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/kobros/Workspace/odoo17/odoo/odoo/fields.py", line 3110, in convert_to_read
    return value.id
           ^^^^^^^^
Attri
buteError: 'mail.thread' object has no attribute 'id'

========================================================================================

Desired behavior after PR is merged:
The method can just retun False if no condition is met.

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





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