Steps to reproduce:
- Install `l10n_dk` module
- Create the test branches under the `DK Company`
- Add both companies(parent and branch) in `Bank and Cash` account
- Go to Chart of Accounts and try to delete any account

Cause:
This error occurs because users can add multiple companies to a `Bank and Cash` account, although it should be prevented by the `_check_company_consistency` [constrain]. However, the code still allows it because, in this [commit], `depends_context=('uid',)` was set on the `company_ids` field to keep separate sudo/non-sudo caches for the field. As a result, during the validation [check], the user may still have stale cached values, causing the system to detect only a single company.

Solution:
Here, we first clear all cached values for the old record and force the ORM to re-fetch the values from the database, ensuring an updated recordset. So, the validation error is raised when saving multiple companies.

[constrain]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[check]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[commit]: https://github.com/odoo/odoo/pull/220294/changes/5096d083a38968425920aa5bf466b156eebb3dc7

Ticket [link](https://www.odoo.com/odoo/project.task/6125840)
opw-6125840

Forward-Port-Of: odoo/odoo#263246
Forward-Port-Of: odoo/odoo#260261

Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app).

To reproduce, 

Default "Outlook: synchronization" is ran every 12 hours. 

1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00
2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 
3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. 

This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar.

opw-5212908

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

Forward-Port-Of: odoo/odoo#262665
Forward-Port-Of: odoo/odoo#245964

### Issue:
Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data

This issue only occurs for `AttachedDocument` files

According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf

However, no strict validation is enforced, so variants should still be supported

### Cause:
When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:`

This causes issues with documents structured like:
```xml
<AttachedDocument>
	<CustomizationID>Documentos adjuntos</CustomizationID>
	<ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID>
</AttachedDocument>
```

In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian`

As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction

The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document

### Steps to reproduce:
- Install `l10n_co_dian`
- Go in Bills and import the test document: `import_attached_document_2`

Before the fix, nothing it extracted from the xml

opw-6083523

Forward-Port-Of: odoo/enterprise#115599

This commit fixes two issues regarding the filmstrip in the /shop page :

- Adding a minimum height to the elements of the `default` and `bordered` designs, so that their heights remain consistent whether they contain an image or not.
- Display a placeholder image for the `images` filmstrip if empty.

task-5491550

| Before | After |
|--------|--------|
| <img width="613" height="103" alt="image" src="https://github.com/user-attachments/assets/852ef2ce-6265-4622-9e30-4e8112bbf264" /> | <img width="618" height="114" alt="image" src="https://github.com/user-attachments/assets/0933c0c2-a669-4236-9148-a25226214ce6" /> |
| <img width="718" height="164" alt="image" src="https://github.com/user-attachments/assets/ac1b8d91-44fa-4ce0-8ddb-beba271a2423" /> | <img width="718" height="164" alt="image" src="https://github.com/user-attachments/assets/8676e9f9-074b-40e9-a75b-76561437c081" /> | 

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

Forward-Port-Of: odoo/odoo#263118
Forward-Port-Of: odoo/odoo#255543

Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.

This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.

In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.

Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.

opw-6075384

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

Forward-Port-Of: odoo/odoo#263200
Forward-Port-Of: odoo/odoo#261521

### Issue before this commit:
Sales taxes at 7% and 5% were incorrectly mapped to the same tax report  tags as the 18% sales taxes, causing them to be reported under the  'Taxable Goods/Services at 18%' line. In addition, the 7% and 5% report  lines displayed negative amounts instead of positive ones.

### Steps to reproduce the issue:
1. Install l10n_mt
2. Create invoices using 18%, 7%, 5% taxes
3. Go to Accounting > Reporting > Tax Report
4. See the amounts for Taxable Goods/Services at 18% is negative and  all the invoices are reported into the Taxable Goods/Services at 18%  even if the tax applied to the invoice is 5% or 7%

### Cause of the issue:
An automatic script (https://github.com/odoo/odoo/pull/225252)  missed to invert sign of formulas for the 7% and 5% lines, so their  values were displayed with the wrong sign. Moreover it is assigned to  the 7% and 5% Malta sales taxes the III.1_base  and III.1_tax tags, which belong to the 18% tax report line.

### Reason to introduce the fix:
The tag mapping must match the tax report structure so that 18%, 7%, and 5% sales taxes are reported in their respective lines. The report formulas for the 7% and 5% lines must also use the proper sign convention to display positive amounts consistently.

opw-6015509

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

Forward-Port-Of: odoo/odoo#263073
Forward-Port-Of: odoo/odoo#254894

### Issue:
With `l10n_ro_edi_stock_batch`, internal transfers using multi-step routes were requiring a delivery carrier
This makes no sense for internal moves

### Cause:
The method `_compute_l10n_ro_edi_stock_enable` was overridden to check for `not picking.batch_id`
However, for multi-step delivery routes, internal pickings still triggered the carrier validation, as no check on the `picking_type` was performed

### Steps to reproduce:
- Install `l10n_ro_edi_stock_batch` with demo data and switch to RO Company
- In Settings, enable `Multi-Step Routes`
- Set the RO Warehouse's Outgoing Shipments to `Pick then Deliver (2 steps)`
- Create a Product (e.g. RO product)
- Create a Delivery Method (e.g. RO Delivery, Partner: Any, Delivery Product: RO Product)
- Create and Confirm a Sale Order for the RO Product
- From the Sale Order, click Delivery and validate the picking 
### Before the fix, internal transfers raised:
`The picking RO Co/PICK/00001 is missing a delivery carrier.`

enterprise-PR: https://github.com/odoo/enterprise/pull/114166
opw-5925087

Forward-Port-Of: odoo/odoo#263036
Forward-Port-Of: odoo/odoo#257293

Currently, when a res.parter is given a parent, base_address_extended runs _onchange_city_id. This sees the city change and alters the zipcode to match the city's zipcode. However, this field can be manually altered to differ from the city's zipcode. Thus, when a parent has a city, the zipcode will override the manually entered zipcode for a child contact.

This commit solves this by checking for the parent's zipcode before blindly setting it to the city's zipcode.

Steps to reproduce:

1. Install `base_address_extended`
2. Enable "Enforce Cities" on a country `(res.country)`
3. Add a city to that country with a zipcode of 123
4. Create a new contact (parent) and select the configured country
5. Select the city (the zipcode will fill in from the city's zipcode)
6. Overwrite the zipcode with 456
7. Save the contact (parent)
8. Create a new contact (child)
9. Set the company to the parent contact and save
10. The zipcode of the child will be the city's zip (123), not the parents' zip (456), thus the addresses will be different, and the child contact type will be 'other'

opw-6131280
closes #262651

Forward-Port-Of: odoo/odoo#262651

**Steps to reproduce:**
Log in as admin and ensure notifications are handled in Odoo.
Enable push notifications and the 'Task Created' subtype for a project.
As a second user, create a new task in that project.

**Current behavior before PR:**
admin received escaped content in the push notification
(e.g., `A new task has been created in the "Project Name" project`)

**Cause:**
For inbox users, we send a client-side push notification using `previewText` as
the body. This field returns a markup object containing escaped characters,
which are converted to a string when passed to the notification body. Since the
notification body only accepts plain text, these characters are displayed
literally to the user.

**Desired behavior after PR is merged:**
admin receives the unescaped content in the push notification.
(e.g., `A new task has been created in the "Project Name" project`)

task-5112810

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

Forward-Port-Of: odoo/odoo#263187
Forward-Port-Of: odoo/odoo#240331

# Setup
For easiness of testing : have no purchase order in your dashboard

# How to reproduce
- Create a Purchase Order for Vendor X and with Product Y
- Click on Confirm Order -> Receive -> Validate
- Go back to the dashboard

# The problem
The displayed OTD is 0%, but when you go to the Vendor X form view and check his On-time Rate, it is 100%

# Cause
The computation for the On-time rate in the dashboard uses the whole datetime value, so if there is even a second of difference between `effective_date` and `date_planned`, the PO is not counted as on-time :
https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/purchase_stock/models/purchase_order.py#L253

That is not the case for the partner On-time rate computation, where we round the datetime value to the date value : https://github.com/odoo/odoo/blob/942cbbbf243ff28f84fdaa40ed73b6572e0032a6/addons/purchase_stock/models/res_partner.py#L57

opw-6128510

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

Forward-Port-Of: odoo/odoo#263015
Forward-Port-Of: odoo/odoo#260384

Steps to reproduce:
---
- Install the `Sales and Inventory` modules.
- Enable `Units of Measure & Packagings` from Settings.
- Go to `Sales > Configuration > Products > Units & Packagings.`
- Create a new unit > Pack of 12 with quantity 12 and unit Units.
- Create a new product > enable Track Inventory, set Quantity On Hand to 100, and in the `sales` tab,
 under `Upsell & Cross-Sell`, set `packaging` as` Pack of 12`.
- Create a Sales Order > add the product and set the quantity to 3, with a unit Pack of 12.
- Confirm the order and validate the delivery.
- Create and confirm the invoice.
- Return `1 unit` from the delivery and validate it.
- From the invoice, create a `credit note` with quantity 1 unit and confirm it.
- Go back to the Sales Order.

Issue:
---
- On the Sales Order: `Delivered Quantity` shows` 2.92` while `Invoiced Quantity` shows `2.91`.

Root cause:
---
- At [1] & [2], in `_compute_qty_invoiced`, the `_compute_quantity` method is called without specifying a `rounding_method`, so it defaults to `UP` (1/12 rounded to 0.09), while `_compute_qty_delivered` explicitly uses `HALF-UP` (1/12 rounded to 0.08), leading to inconsistent rounding.

Solution:
---
- In this PR, the same rounding method (HALF-UP) is applied when computing the invoiced quantity to ensure consistency with the delivered quantity.

[1]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale/models/sale_order_line.py#L896-L912
[2]https://github.com/odoo/odoo/blob/64c1f1a7d3b24ca613d0b29a2412f1094fea08d9/addons/sale_stock/models/sale_order_line.py#L193-L209

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

Forward-Port-Of: odoo/odoo#263011
Forward-Port-Of: odoo/odoo#258024

### Steps to reproduce:
- Download 'Sales', 'Project', 'Employees', and 'Timesheets' apps
- Create an employee and link them to a user that doesn't have any access rights except to 'Timesheets = User:own timesheets'
- In Sales, create a service with the following specifications:
    - 'Create on Order' is 'Project'
    - 'Invoicing Policy' is 'Based on Timesheets'
- Create a new quotation that requests this service and click 'Confirm'
- In 'Project' > 'Configuration' > 'Projects', choose the newly created project and add a line that has the new employee in the 'Invoicing' tab
- Log in as that employee and go to 'Timesheets'
- Create a new entry for the newly created project
- Click the project's name
> Access Error: You are not allowed to access 'Collaborators in project shared'
(project.collaborator) records.

### Cause of Issue:
This happens because the user doesn't have access rights to the 'Project' app, hence they don't have access to `collaborator_ids` which are retrieved here. https://github.com/odoo/odoo/blob/3dfb2849acd899ccbf4048f2a15dff3c74aed96d/addons/project/models/project_project.py#L1113-L1120

### Fix:
Since an access to the 'Projects' app isn't necessary to view a project assigned to you, `sudo()` is necessary for hr_timesheet users without project access rights.

opw-6074833

Forward-Port-Of: odoo/odoo#263152
Forward-Port-Of: odoo/odoo#258370

Steps to reproduce:

* Enable multiple languages
* Go to Sale Order Templates and create a new template
* Add a product line, then click the translate button on the description field
* A confusing validation error appears for missing `sale_order_template_id`

Issue:

* Instead of highlighting the missing required fields on the sale order template form view, it raises a misleading validation error on `sale_order_template_id`

Cause:

* `useTranslationDialog` always attempts to save the passed record directly. In O2M list views, the field can belong to a nested relational record, so the correct behavior is to save the root record instead.

Affected Version: 17.0

Before:
<img width="1919" height="1014" alt="image" src="https://github.com/user-attachments/assets/cd61381d-289a-4df4-bdf2-7881fa851939" />

After:
<img width="1920" height="887" alt="image" src="https://github.com/user-attachments/assets/5218c74b-c024-4994-b816-cb7ae69b420f" />

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

Forward-Port-Of: odoo/odoo#262988
Forward-Port-Of: odoo/odoo#262755

### Steps to reproduce:
- Download 'Sign' and 'Contacts' apps
- Create a contact with a really long name
- Create a sign document template with a multiline text field (Read-only) that has contact name value
- Click 'Sign Now' and put the new contact as the signer
- Sign and download
> The text appears as a single extended line exceeding field/page boundaries

### Cause of Issue:
The textarea and stamp field rendering only handled explicit newline characters (`\n`) and did not account for text that exceeded the field width. https://github.com/odoo/enterprise/blob/017743cbe97b629e9d9f1895b655014d4c3abbcb/sign/models/sign_document.py#L330-L345 When the HTML preview showed wrapped text, the PDF output rendered it as a single line. For continuous text without spaces, the text would overflow the field boundaries entirely.

### Fix:
Accounted for long texts that have spaces and long words to show all the information in the PDF

opw-6045062

Forward-Port-Of: odoo/enterprise#114813

Problem: When entering the barcode interface from a picking and scanning a different serial number than one already reserved, a new line gets created in certain situations. When exiting the barcode interface without validating the picking, both serial numbers show up on the picking view. However, the first serial number’s `stock.move.line` was deleted, so only one serial number should be there. 

When exiting the barcode interface a call to `post_barcode_process` is made, where the extra `stock.move.line` is deleted, but it doesn’t wait for the call to finish. 
https://github.com/odoo/enterprise/blob/d5a52cb79c9c41d792685d2858cfeb6aee147642/stock_barcode/static/src/models/barcode_picking_model.js#L1896

Purpose: By overriding `beforeQuit` to add the `_onExit` call, the component now waits for the `post_barcode_process` call to finish before navigating back to the picking view. This helps ensure the UI displays the updated data. 

Steps to reproduce on Runbot:
Create a product tracked by serial numbers.
Have 2 units on hand: serial 001 with a package, and serial 002 without a package. (This is needed so the barcode app will create a new line).
Create a delivery for 1 unit of our test product and mark it as todo.
Ensure that serial 001 is reserved.
Click the Barcode smart button and scan the barcode for serial 002.
Click the back button.
Observe that both serial numbers are shown on the picking. 
Refresh the page and observe only serial 002 is now shown. 

opw-6105740

Forward-Port-Of: odoo/enterprise#115491

Commit 072a8e4fd061ff23902e6e448a577624cb27e188 fixes edition of buttons by wrapping the editable button in an editable span. But it allows user to write outside the savable node, and allows user to copy website builder's branding attributes (which causes issues when pasted).

This commit adds a span inside the button instead of outside, and removes it before saving the content.

Steps to reproduce:
- Open website buider on `/product/item-1`
- Place the cursor in the "Add to cart" button
- Press left arrow, repeat until out of the button
- Bug: You can write text there, but it won't be saved

#####
- Open website buider on `/product/item-1`
- Select some text in the "Add to cart" button
- Copy (`ctrl+c`)
- Paste (`ctrl+v`)
- Bug: Some content seems duplicated: the branding of the savable button has been duplicated inside it and the automatic replication between identical fields is based on this branding, thus replicates the button's content inside it

Similar issue about copy+pasted branding: ec93d48ab17b4a72f61fa358e5a81d2abcb18897

Forward-Port-Of: odoo/odoo#257849

Currently, an error occurs when a user attempts to mark a payslip as paid.

**Steps to Reproduce:**

 - Install the `hr_payroll` module without demo data.
 - Go to `Payslips` and click on `New Off-cycle`.
 - Create a record > `Compute` > `Validate`, and Pay.
 - In the wizard, enable `Include Unpaid` and select `CSV` mode.
 - Click `Mark as Paid`.

**Error:**
`UnboundLocalError: cannot access local variable 'rows' where it is not associated with a value`

The error occurs when a user tries to mark a payslip as paid with Include Unpaid enabled. 
When the wizard is created from here [1], the default unpaid payslips are empty. In this case, 
the system assigns an empty set of payslips to process [2].and the rows variable is not 
defined because there are no payslips to work on, which raises the error [3].

This commit ensures that when the wizard is created, the matched unpaid payslips are passed to 
the wizard. If the Include Unpaid option is enabled, the unpaid payslips are assigned for processing, 
similar to [4]. The unpaid payslips cannot be empty, as they always include the currently 
processed payslip.
Also, the rows are redefined for each payslip case and updated accordingly. Therefore, this commit 
ensures that the rows are created at the end from grouped payments.

[1] https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip.py#L792-L809

[2] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L56

[3] https://github.com/odoo/enterprise/blob/e971fca0d09e564ae9029f3d7e166e078c44dcbb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L97

[4]: https://github.com/odoo/enterprise/blob/a784d118e076724b02e5c59d9ce5d1815c42b0bf/hr_payroll/models/hr_payslip_run.py#L274-L288

sentry-7436885639

### Steps to reproduce:

- In the settings Enable: "Automatic accounting"
- Create a storable kit product with a storable component both invoiced on delivered qty and in an "automated" ('real_time') inventory valuation.
- Create a kit product with a component invoiced on delivered qty
- Create and confirm a sale order for 1 units of your kit
- On the delivery add a new move for 1 unit of your kit and save
#### > The new line should be exploded into the component
- Set the quantity on both moves and validate
- On the sale order > Create draft invoice > confirm
#### > User Error: 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.

### Cause of the issue:

The issue occurs when the `_stock_account_get_anglo_saxon_price_unit` is launched on the account move line created for the extra component because the moves where generated from a kit and hence are associated with a `bom_line_id` but the the product it self is not a kit so that no bom will be found here:
https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L12-L23 In particular, the rest of the call that tries to treat it as a kit will fail because no bom is and should be provided to this line: https://github.com/odoo/odoo/blob/521111d50e9119a6286e4b0e236161b1b898f072/addons/sale_mrp/models/account_move.py#L34

opw-6041375

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

Forward-Port-Of: odoo/odoo#261878
Forward-Port-Of: odoo/odoo#258141

### Issue before this commit:
The XML export for branch companies incorrectly identified the branch as the sender, even when a Peppol parent company was configured.

### Steps to reproduce the issue:
1. Download Accounting, Contacts and l10n_be
2. Create a branch for a Belgium company
3. Enable Peppol sending on the parent company
4. Enable Peppol sending on the branch company using the parent company endpoint
5. Switch to branch company
6. Create a customer invoice in the branch company using a customer who is on the Peppol network (meaning insert a valid VAT number and then verify button in the Accounting tab)
7. Confirm and send the invoice via Peppol
8. Download the resulting xml file and check the "AccountingSupplierParty" nodes. It contains the data of the branch and not the ones of the parent company

### Cause of the issue:
The EDI export logic was fetching the supplier data directly from the invoice's company record without checking for a delegated Peppol parent company, ignoring the hierarchical relationship defined in the settings.

### Reason to introduce the fix:
This fix ensures that the AccountingSupplierParty in the UBL/CII file correctly reflects the parent company's data when applicable.

opw-6030526

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

Forward-Port-Of: odoo/odoo#260389

**Problem:**
After importing records through the Import action, the list view that opens with the imported records does not inherit the context of the originating action. Column visibility and default values that depend on that context (e.g. `default_move_type` on the shared invoice list) end up wrong.

**Steps to reproduce:**
1. Go to Accounting → Customers → Invoices
2. Click "Favorites → Import records"
3. Upload a CSV containing at least one valid customer invoice row
4. Run the import and look at the "Imported records" list that opens

**Current behavior:**
The imported records list opens with an empty context. Columns rendered conditionally on `default_move_type` (invoice-type-specific columns on `account.view_invoice_tree`) are not shown as they are when opening the list from the menu, and records created from that list have no default move type.

**Expected behavior:**
The imported records list should open with the same context as the action the user started the import from (e.g.
`{ default_move_type: 'out_invoice' }` for customer invoices), so columns and defaults match the previous view.

**Cause of the issue:**
`openRecords()` in `import_action.js` builds the follow-up `ir.actions.act_window` but never forwards `this.model.context`. The model already holds the context passed through the import action's `params.context`, but it is dropped when the redirect action is dispatched, so the window action opens with an empty context.

**Fix:**
Forwarding the context the import was launched with keeps the user inside the same functional scope (invoice type, default partner, company, etc.) when they land on the imported records list. Column visibility logic and default values that rely on that context behave identically to opening the list through the normal menu flow.

opw-6120758

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#261309

The session id rotates softly every 3 hours

For some features, the mobile app sometimes does requests "outside" of the mobile app, through a webview for instance, and if the session rotation interval is reached at that moment, it rotates the session and the `set-cookie`
instruction setting the new session cookie is received by the webview only, it's not propagated back to the mobile app.

Then, this could lead for the user to be logged out of the mobile app if the soft automatic session rotation happens at the very unfortunate moment the request through that webview happens.

For instance, the mobile app uses a webview to download attachments. If the session rotation happened during that request, the mobile app doesn't receive the `set-cookie` header and doesn't receive the new session id, leading for the user to be logged out of the mobile app.

This revision aims to provide an option for the mobile app to temporary skip the session rotation for a specific request, such as the requests done through the webview during downloads.

This option to be able to disable the rotation is not a security threat: If an attacker passes that header to disable the interval session rotation, he would avoid the session to be changed every 3 hours, but if he wouldn't he would still receive the new session id every 3 hours.
The session rotation is for legitimate user / computer to rotate their session every 3 hours so that in case of data leak of their browser cookies, there is a chance the session cookie is already no longer valid when published on the public web. Legitimate users have no benefit using this option header to disable the rotation.

Forward-Port-Of: odoo/odoo#263325

#### Issue:
The budget report displays duplicate analytic lines.

#### Steps to reproduce:
In a new company:
- Create a budget with one budget line (Analytic Account A).
- Create one analytic item (linked to Analytic Account A).
- Open the budget report and remove the default "open budget" filter.
Duplicate amounts appear in the pivot view and duplicate lines appear in the list view.

#### Cause:
In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report.

#### Fix:
Use three separate queries, each with specific filter conditions to guarantee unique results:
Q1 - Analytic lines with no matching budget line.
Q2 - Analytic lines matched to a budget line with no company (null-company).
Q3 - Analytic lines matched to a company-specific budget line.

OPW-6051696

Forward-Port-Of: odoo/enterprise#116612