Steps to reproduce:
1. Install `website_hr_recruitment`
2. Create a job position from form view
3. Click on Published toggle button

Issue:
- Publishing a job position from the `hr.job` form is showing an incorrect first-click result: the website page is actually published, but the form autosave response still return `website_published = false`, so the toggle flips back to unpublished until the next refresh.

Cause:
- In v19.0, `website.published.mixin.write()` was effectively a thin wrapper around `super().write()`. The backend autosave path used by boolean toggles (`web_save`) performs a `write()` and then an immediate `web_read()` in the same request, and that simple flow returned the fresh publish state.

- In saas-19.1, the publish flow became more complex:
  - `website.published.mixin.write()` now  triggers `_finalize_publication()`
  - `_finalize_publication()` performs an additional internal `write()`

- The record is published correctly, but the immediate `web_save()` readback can still use cached values for  `website_published` from the same ORM environment. This makes the first form response inconsistent with the actual state.

Solution:
- Invalidating `website_published` field after the`write()` in `_finalize_publication()` so the immediate `web_read()` performed by `web_save()` returns the real post-write state on the first click.

opw-6012359

**Steps to reproduce:**

- Download the German language
- Set the restaurant to QR + Ordering
- Set the Service at Table, pay after each order
- Set the language to German
- Go to the Self and order something while the language is German
- Chose table 12
- Go to the kitchen display
- The title is truncated, meaning we can't see the table number

**Why the fix:**

If the title is more than 150px it will be truncated and "..." will replace the table number. This has been introduced in 
ed5b010dc7b5c11bbbc8513c1edb0ec4f58778c1 but not being able to see the table number might be bad as some people would need to spend time trying to figure out which table the order is for, instead of just having to look at the kitchen display.

We now revert this change to break to a new line in the case where the card title is too long, so we can always see the table number.

Before:
<img width="317" height="156" alt="image" src="https://github.com/user-attachments/assets/25e76026-bdad-4639-9dfc-0d75ffa8d8c8" />

Afer:
<img width="329" height="174" alt="image" src="https://github.com/user-attachments/assets/f387dd5f-96d3-4148-bc76-215393c76e67" />


opw-6096111

### Issue:
When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30.

### Cause:
The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`.

### Steps to Reproduce:
- Costing Method = AVCO, Inventory Valuation = Automated
- Comp A (cost 10), Comp B (cost 20), Kit X (cost 0)
- Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B
- Create and confirm a SO for 1 x Kit X
- Expected SO line cost: 30
- Actual SO line cost: 360

Solution:
This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs.

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

Forward-Port-Of: odoo/odoo#259005
Forward-Port-Of: odoo/odoo#253406

Issue:
---
In `tax included` companies, the down payment section is not correctly calculated.

Steps to reproduce:
- Configure selected company's field account_price_include to be "tax_included"
- Create a sales order
- Create 1 or more down payment invoices for the SO and confirm
- Create a final invoice that pays for the rest of it
- On this final invoice where the down payment(s) are also listed, click on the preview button

Current behavior:
- The down payment section's total is the sum of the subtotal

Expected behavior:
- The down payment section's total should be the sum of the totals

Justification:
---
The amounts included in the invoice report are dependent on the
`company_price_include` field in `res.partner`. If tax_excluded,
subtotals are listed. If `tax_included`, totals are listed.
There was a mismatch between the entries and the section total;
the section entries could have the total as the amount while
the section's sum would be in terms of subtotals.

Fix:
---
On stable we can still rely on `section_subtotal` but set its
amount to total instead of subtotal in case of `tax_included`.

However, this fix is not stable as there is a xpath on `t-set`
expression in `l10n_ar`.
To avoid breaking the views, we can re-set the `section_subtotal`
in the next lines.
This would still cause issues as it will replace the overridden
logic in the `l10n_ar` implementation.
To prevent that issue, we can re-set the `section_subtotal` only
if the value is the same as `get_section_subtotal`, which means
we are in the main implementation and it's safe to re-set the value.

opw-6127615

Forward-Port-Of: odoo/odoo#261372

On a multi-website / single-company setup, helpdesk notification emails posted after the initial confirmation contained a "View Ticket" button pointing to the wrong website, always the company's default website instead of the website the ticket was created from.

Steps to reproduce:
===================
1. Create two websites W1 (seq 1) and W2 (seq 2) under the same company, with distinct domains.
2. Create two helpdesk teams with "Submit a Ticket" enabled, each bound to one website (Helpdesk1 -> W1, Helpdesk2 -> W2).
3. From W2, submit a ticket on /helpdesk/helpdesk2.
4. In the ticket, send email from the chatter.
5. Inspect the outgoing notification email.

=> "View Ticket" button points to W1's domain.

Root cause:
============
`helpdesk.ticket` has no `website_id`, so `Base.get_base_url`
 falls through to `company_id.website_id.domain`, i.e. the first
website of the company by sequence. The first confirmation message looked right only because it was posted inside a website request, where `website.get_current_website()` provided the correct context; subsequent agent replies are posted from the ticket with no such context, so the fallback kicked in.

Override `get_base_url` on `helpdesk.ticket` to prefer `team_id.website_id.domain` when set, so every notification on the ticket links back to the website the customer submitted it from.

=> "View Ticket" button points to W2's domain (the site the
   customer is browsing).

opw-6071999

Forward-Port-Of: odoo/enterprise#114693

**problem:**
On timesheets, the overtime indication next to an employee's name is incorrect when using flexible work schedules. for example: a "Flexible 20h" schedule (4h a day) shows 1h of negative overtime even when the employee has logged exactly 20h for the week.

**steps to reproduce:**
1. Create a new working schedule with flexible hours enabled for example (20h/week, 4h/day average)
2. Assign this schedule to an employee
3. Go to Timesheets, search for the employee
4. Navigate to a past week
5. Enter 4h on each working day
6. Observe the overtime indication shows incorrect value (-01:00)

**cause:**
In `resource/models/resource_calendar.py`, the flexible hours algorithm that determines the date range by converts UTC boundaries to the employee's timezone. When the employee's timezone has a positive UTC offset (UTC+1, like in brussels time zone), `Sun 23:59:59 UTC` becomes `Mon 00:59:59 CET`, pushing `end_date` to the next Monday. This creates an 8 day range instead of 7. The algorithm then starts a new weekly budget for the spillover day and allocates 1 extra hour, making `allocated_hours` 20.9999998 instead of 20.

**fix:**
- Use the UTC date before conversion to the employee's timezone when determining the flexible date range.
- prefer `self` when it is the flexible calendar being queried, so hr_contract's `_get_calendar_at()` override cannot substitute the contract's calendar parameters (full_time_required_hours, hours_per_day) for the flexible ones.

**note**
Updating the test (`test_no_carried_over_leaves_for_flexible_resource`) in `hr_holidays/tests/test_expiring_leaves.py` expected duration logic, is to match the corrected inclusive day range and prevent asserting the previous spillover behavior.
link to the enterprise PR: https://github.com/odoo/enterprise/pull/112879

link to the community PR: https://github.com/odoo/odoo/pull/257269

opw-5970511

---

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

Forward-Port-Of: odoo/enterprise#115693
Forward-Port-Of: odoo/enterprise#112879

**Steps-to-Reproduce**
- In v19, install subscriptions.
- create new subscription + service product with allow one time sale enabled.
- make a SO with that product,any reccuring plan and any end date. 
```
id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 1_draft            |                   | 2026-05-02
```

- confirm the SO
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         | 2026-05-01        | 2026-05-02
```
- remove its recurring plan (some product sold for months for testing then converted to one time sale )
```
 id |  name  | subscription_state | next_invoice_date |  end_date  
----+--------+--------------------+-------------------+------------
  1 | S00001 | 3_progress         |                   | 2026-05-02
```

- upgrade to v19.1 will fail or opening sales > To Invoice > Orders To Invoice gives this error or add amount_to_invoice in list view using studio to produce in v19 :
```
File "/home/odoo/odoo18/enterprise/sale_subscription/models/sale_order_line.py",
 line 175, in _compute_amount_to_invoice
    and (not order.end_date or order.next_invoice_date < order.end_date)
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```

- upgrade failing for v19.1 because amount_to_invoice added to list view [here](https://github.com/odoo/odoo/commit/427232efd121410380b62acf4fd2e9ee369e6542#diff-48cb4309a6006f91b2b40e4c1049860218d419fce1782c7dcc278329803129caR193-R213).

upg - [4220658](https://upgrade.odoo.com/odoo/upgrade.request/4220658)
opw - [6128033](https://www.odoo.com/odoo/project/70/tasks/6128033)

Forward-Port-Of: odoo/enterprise#115976

**Steps to Reproduce:**
1. Install `hr_contract_salary_payroll` with demo data.
2. Open Employee (e.g; Abigail Peterson) > Payroll tab > Gear Icon > Edit Properties.
3. Add a new property for Payroll and fill in the value also.
4. Go to Payroll > Configuration > Benefits.
5. Create a new benefit with:
   Salary Structure Type: Worker
   Cost Field: Payroll Properties (Employee Contract)
6. Save the record.

Video: https://drive.google.com/file/d/1gHRkDW5G0bURlo9_IRgCnvqpE-8Fk1xa/view?usp=drive_link

**Error:**
`TypeError - unsupported operand type(s) for +: 'int' and 'Property'`

**Cause:**
The method `_get_benefits_costs()` directly sums values using: 
```
self[benefit.cost_field]
```
When the selected cost field is a property field, it returns a **fields_properties.Property** object instead of a numeric value, and this object is not directly compatible with the arithmetic sum operation.

Before 19.0, property fields were not allowed to be selected as a cost field - [1].

**Fix:**
This commit prevents selecting property fields as cost fields from the list of supported field types.

[1] : https://github.com/odoo/enterprise/blob/04224abcc7eec1c81df7ad57a9213fd091774888/hr_contract_salary/models/hr_version.py#L183

sentry-7388663038

Forward-Port-Of: odoo/enterprise#113238

### Issue:
When reconciling an invoice in a foreign currency with multiple bank statement lines in the same foreign currency, the balance becomes hidden after selecting the second transaction

Additionally, after selecting and unselecting a line with another currency, the balance can remain hidden even when no lines are selected

### Cause:
In `changeInSelectedMoveLine(selectedLines),` when the currency differs from the company currency, `selectedLineCurrencies` is built as a simple mapped array

This array may contain duplicate currencies, which should not prevent computing the balance but incorrectly impacts the logic that determines whether to display it
There is no reason to block the sum of lines with the same currency

When there is no selectedLines, the function returns early and doesn't unhide the balance

### Steps to reproduce:
- Install `account_accountant` with demo data
- Enable a foreign currency like EUR
- Create and confirm 2 invoices (Customer: Acme Corporation, Currency: EUR, Add a line for 100€)
- Go to the Dashboard, and select Bank
- Create a new transaction (Label: Multi-currencies, Partner: Acme Corporation, Price: 500$)
- Switch to the List View, and display the 2 columns `Foreign Currency` and `Amount in Currency`
- Modify the line Multi-currencies (Foreign Currency: EUR, Amount in Currency: 300$)
- Switch to the Kanban View and Reconcile the line Multi-currencies
- Select your 2 invoices one by one
Before the fix, after selecting the second invoice, the balance is displayed as `/`

For the additional case:
- Unselect all lines
- Select a line in another currency (e.g., USD), then unselect it
The balance remains hidden

opw-6063366

Forward-Port-Of: odoo/enterprise#115101

Step to reproduce:
- install "purchase_stock" and "point_of_sale"
- Create a product attribute -> Display Type: Radio Button
-> Variant Creation Mode: Never create variants
-> Add two attribute values, ensuring that one includes a 'is_custom' field.
- Create a product and assign this attribute to it.
- Enable the MTO (Make To Order) route.
- Add a vendor to the product.
- Create and confirm a POS order for this product. (add text for custom attr)
- Observe that a Purchase Order is generated automatically.

Observation:
- the PO does not have that text in description

Cause:
- After commit [1], `description_picking` became a computed field.
- Previously, its value (`product_description_variants`) was set in `_prepare_procurement_values`.
- That key is no longer used for this purpose, so the information is not propagated and the data is lost.

https://github.com/odoo/odoo/blob/71b1267e54fd53fb283c41b579756c72e393cbfa/addons/stock/models/stock_rule.py#L341-L343

above code is removed following that commit

Fix:
- The description is computed for pos orders

[1] https://github.com/odoo/odoo/commit/6b2d3af64a076654e04494972acc4c42d7c54bd8

opw-5969378


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

Forward-Port-Of: odoo/odoo#262503
Forward-Port-Of: odoo/odoo#253231

Steps to reproduce:
-------------------------------------
1. Install `hr_holidays_attendance` module
2. Time off > configurations > Time off types
3. Create new time off type as follows:
* Set Approval to Approved by time off officer
* Change Take time off In to Hours
4. Save the record and enable Deduct Extra Hours
5. Go to Management > Allocations
6. Create new allocation with created time off type and select 'Audrey Peterson' in Employee
7. Try to save record > Validation Error > Discard changes
8. Change time off type to Paid Time Off > add 'Audrey Peterson' > save record
9. Now change Time Off type to Created Time Off type > Save

Observation:
-------------------------------------
No Validation Error raised, as the employee and time off type are still the same as they were during creating allocation.

Issue:
-------------------------------------
In `write` method, there was no any check for the employee if it has enough overtime hours when we change Time off type (`holiday_status_id`) to overtime-deductible leave type.

Check was only present in the `create` method:
https://github.com/odoo/odoo/blob/a95c639db68f98351c7162de58a041a1c0ee13c5/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L39-L49

Solution:
-------------------------------------
1. Create new function for validate overtime and to create adjustment
2. Added that function to `create` as well as in `write` method
3. Prevents creating a duplicate overtime adjustment for an allocation that already has one

opw-5937185

Forward-Port-Of: odoo/odoo#262716
Forward-Port-Of: odoo/odoo#249793

Currently, error occurs when user tries to merge a mailing list.

Steps to replicate:
- Install `mass_mailing`.
- Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view.
- Select a single record, and from cog menu Click merge.

Warning:
```
odoo.http: Record does not exist or has been deleted.
(Record: mailing.list(6,), User: 2)

```

Cause:
- When the user clicks Merge, the `mailing.list.merge` form opens and `default_get()` is executed to populate defaults.
- At this point, `src_list_ids` is added to res in a structured format like `[(6, 0, ids)]` [1].
- Later, `res.get('src_list_ids')` is reused and assigned to `src_list_ids` [2].
- Taking `src_list_ids[0]` [3] returns `(6, 0, ids)`, and its first element `6` is incorrectly treated as a record ID and assigned to `dest_list_id`.
- This leads to an attempt to access a record with ID 6, which does not exist, causing the error.

Solution:
- Instead of reading `src_list_ids` back from `res` after it has been set, we initialize and reuse local variables (src_list_ids, active_ids) at the beginning of the method.

- This avoids relying on transformed values in `res` and ensures that `dest_list_id` is computed using a consistent and valid list record IDs.


[1]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L20-L22

[2]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L24

[3]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L26

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

Forward-Port-Of: odoo/odoo#262466

## Issue
When creating an invoice for a sale order with a recurring plan using a `billing_period_value` >= 1 and aligning, that value is not taken into account, and the invoice only covers one unit of time (week/month/year).

## Steps to reproduce
1. Install *Subscriptions* (`sale_subscription`)
2. Create a Recurring Plan RP:
    - *Billing Period*: 6 Months
    - *Align to Period Start*: Checked
3. Create a Subscription Product P
4. Create a Subscription SO:
    - Any Customer
    - Recurring Plan RP
    - Product P (any quantity/price)
5. Confirm the SO and create the invoice
6. **In the line of the SO, only one month is covered by the invoice. If we generate the next invoice, only one month will be covered as well.**

## Cause
Since https://github.com/odoo/enterprise/commit/45f28f6c288f5213a4e29c816ec68d2c3966b55f, the `next_date_1st` is evaluated by taking the last day of the month/year and incrementing it by one day, to reach the first day of the next month/year.

https://github.com/odoo/enterprise/blob/2d2056766441157dc45ebc37b677841c44e5c513/sale_subscription/models/sale_order_line.py#L377-L382

This is inaccurate when working with recurring plan which are not monthly/yearly, as it will always set the `next_date_1st` to the next month/year, without taking in account the `billing_period_value`.

## Fix
There are two ways to align dates to the period start. Given a subscription starting on January 15, with a billing period of 3 months, we could:
1. Invoice from January 15 to January 31, then from February 1 to April 30. This aligns the invoice to the closest month, then apply the 3 months period for the next invoices.
2. Invoice from January 15 to March 31, then from April 1 to June 30. This applies most of the billing period for the first invoice, while still aligning it to the start of the month, then apply the 3 months period normally for the next invoices.

**Here, we chose the second option** to avoid making the code more complex and keep the diff minimal.

opw-6151530

Forward-Port-Of: odoo/enterprise#115830

**Issue**
Lots manually indicated on stock move lines can be overridden when producing a Manufacturing Order.

**Steps to reproduce**
- Create a storable product P tracked by lot
- Create two lots for product P with 2 units each
- Create a MO for a product consuming two units P and confirm it
- On the raw move, manually set 1 unit for each lot
- Click on "Produce All"
- Check the move line associated to the product P -> 2 units associated to the first lot consumed instead of 1 unit each

**Cause**
While producing:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2109-L2110 It sets the quantities:
https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/mrp/models/mrp_production.py#L2246 This calls `_set_quantity_done_prepare_vals` with a qty of 2: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2264 which will, for each move line:
- Take the quantity indicated by move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2274 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2296-L2297
- Then take all the available quantity left for the lot associated to the move line: https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2302-L2309 https://github.com/odoo/odoo/blob/0fe2023dc57b6cc02bd399d3c8fc5d6c8ed6e833/addons/stock/models/stock_move.py#L2326-L2327 Instead of first taking all the quantity indicated by the move line, before checking available quantity

**Solution**
Assume that raw move lines being created in mrp without changing the producing quantity are manually created

opw-5946439

Forward-Port-Of: odoo/odoo#260518
Forward-Port-Of: odoo/odoo#257258

Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription

Steps to reproduce:
1. Install Subscriptions
2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago
3. Confirm the subscription
4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token"
5. Go back to the previously created subscription (see that a reminder email has been added in the chatter)
6. Duplicate the subscription and confirm the duplicate
7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again
8. There are no reminder for the duplicate subscription

Issue:
The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here
https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120

Solution:
Set `copy=False` on the field `last_reminder_date`

opw-6167356

Forward-Port-Of: odoo/enterprise#116335
Forward-Port-Of: odoo/enterprise#115509

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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/fcdbaa36ed [FIX] chart: ensure chart values remain visible (remove clipping) [Task: 5993132](https://www.odoo.com/odoo/2328/tasks/5993132)
https://github.com/odoo/o-spreadsheet/commit/b4e8b1ffcb [FIX] Gauge chart: error message in the side panel [Task: 6179300](https://www.odoo.com/odoo/2328/tasks/6179300)
https://github.com/odoo/o-spreadsheet/commit/dfe8311831 [FIX] grid overlay: unhide buttons visibility [Task: 6127335](https://www.odoo.com/odoo/2328/tasks/6127335)
https://github.com/odoo/o-spreadsheet/commit/47fa9a64c9 [REF] lint: enforce braces for all control statements [Task: 6140827](https://www.odoo.com/odoo/2328/tasks/6140827)
https://github.com/odoo/o-spreadsheet/commit/ac35849ad1 [FIX] package: add missing types dependency [Task: 6140820](https://www.odoo.com/odoo/2328/tasks/6140820)
https://github.com/odoo/o-spreadsheet/commit/3784e2be25 [FIX] pivot: `getPivotCellFromPosition` will throw on invalid formula [Task: 6109696](https://www.odoo.com/odoo/2328/tasks/6109696)
https://github.com/odoo/o-spreadsheet/commit/faf0440efd [FIX] format: don't humanize scientific format [Task: 6068353](https://www.odoo.com/odoo/2328/tasks/6068353)
https://github.com/odoo/o-spreadsheet/commit/ff534e926a [FIX] zoom: scorecard chart rendering with zoom [Task: 6072348](https://www.odoo.com/odoo/2328/tasks/6072348)
https://github.com/odoo/o-spreadsheet/commit/b307b467b9 [FIX] Data filter : clear/select all button [Task: 6075166](https://www.odoo.com/odoo/2328/tasks/6075166)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

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

### Steps to reproduce:
	- Create a salary rule for expenses
	- Set a debit account for this rule with a type other than 'Payable'
	- Create an expense for an employee and report it for the next payslip
	- Create a payslip for this employee
	- Notice an error is shown that 'No debit account for Expenses rules'
	- Go to the expense rules and change the debit account type to 'Payable'
	- Go back to the payslip and notice the error didn't disappear and a new warning showed up

### Cause:
When changing the type of an account_debit that is linked to an expense
rule we will try to recompute the errors and issues but the env company
will be set to be equal to the default company of the env user. So if this
company is different than the payslips' company it won't be able to fetch
the correct account_debit in the rule

### Fix:
Access account_debit and journal_id using with_company() to make sure we get the correct company-related value.

opw-6013423

Forward-Port-Of: odoo/enterprise#114878

## Issue
In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sign a same template twice, using the same subject S1. This gives us Documents D1 an D2.
3. (Optionally), sign the same template a third time, using a different subject S2, creating document D3.
4. In Sign > Documents, select the 2 (3) signed documents and click *Download*.
5. **In the resulting zip file, there's one folder S1 containing a single pdf document (D1) (and one folder S2 containing D3). Document D2 is missing from the zip file.**

## Cause
When generating the zip file, the path used for each document is `{subject}/{doc_name}`.

https://github.com/odoo/enterprise/blob/863abc99469c12acdebcab05788d566c370bb46f/sign/controllers/main.py#L276-L286

Neither of this attribute are unique, which means that two signed documents with the same name and subject can be downloaded simultaneously, but will then overwrite each other.

## Fix
Before version 18.3, the zip file would contain folders named with the (unique) request id, which would consistently make them distinct from one another. This behavior was changed by https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b to use the `sign_request.subject` instead. This commit adds the `request.id` after the subject to keep the clarity of the subject, and add the uniqueness of the id.

opw-6143128

Forward-Port-Of: odoo/enterprise#116179
Forward-Port-Of: odoo/enterprise#116013

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#262136
Forward-Port-Of: odoo/odoo#245964

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#262884
Forward-Port-Of: odoo/odoo#258370

**Description of the issue/feature this PR addresses:**
----------------------------------------------
When replying to messages from the History (Inbox) view, opening the full
composer and discarding it could incorrectly trigger a toast notification
indicating that a message was posted. This behavior is misleading, as no
message is actually sent when the composer is discarded.


**Current behavior before PR:**
----------------------------------------------
- Replying to a message from History opens the full composer
- Discarding the full composer closes the dialog normally
- A “Message posted” toast is shown even though no message was sent
- Notification logic depends on dialog close behavior, leading to incorrect triggers

**Desired behavior after PR is merged:**
----------------------------------------------
- Discarding the full composer does not show any notification
- Notifications are only shown when a message is actually sent

Task-5431682

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

Forward-Port-Of: odoo/odoo#262004
Forward-Port-Of: odoo/odoo#241705

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

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

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