In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted:

- In company Origin, the invoice must be matched by a clearing entry
- In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no Outstanding account is configured on the payment method line.

Same but opposite thing must happen for credit notes in company Origin that match a reimbursement in company MoneyHandler.

Cancellation of a payment must be reflected on the entries: deleting when feasible, reversing when not (unless a lock date/hash is present, which would block the cancellation)

_(To do: testing/review, credit note, cancellation/reversal of the payment)_

Task [link](https://www.odoo.com/odoo/project.task/6037525)
task-6037525

Forward-Port-Of: odoo/odoo#259197

**PROBLEM**
`_cron_migrate_local_to_cloud_storage()` is used to migrate attachment to a cloud storage. It delete the attachment from the database, rendering it innacessible from the server-side. The problem is it can delete attachment used in business logic.

**STEP TO REPRODUCE**
1. Install and configure cloud_storage + a provider (e.g. cloud_storage_google) and cloud_storage_migration.
2. Install l10n_mx_edi and stamp a customer invoice. The CFDI XML is stored as an ir.attachment that:
  - is referenced by a business Many2one l10n_mx_edi.document.attachment_id (copied into account.move.l10n_mx_edi_cfdi_attachment_id),
  - has res_field = NULL (record attachment, not a field binary),
  - is posted to the chatter → it has a row in message_attachment_rel.
3. Add account.move to cloud_storage_migration_message_models and set a low enough cloud_storage_min_file_size.
4. Run the cron _cron_migrate_local_to_cloud_storage.
5. Open the invoice and trigger any recompute of the EDI chain (e.g. Update Payments, a reconciliation, or re-stamping).

**FIX**
Filters out attachment linked to a model listed by the already existing function `_get_cloud_storage_unsupported_models()`

opw-6347198

Forward-Port-Of: odoo/odoo#275945

Description of the issue/feature this PR addresses:

When reversing or replacing an invoice with a C-symbol (tax code requiring approval), the reverse_moves method used an undefined `_l10n_vn_edi_lookup_invoice`, which is an old artifact from 19.2.

This commit replaces it by a call to the SInvoiceService `lookup_invoice`, following the same pattern used throughout the rest of the module.

Steps to reproduce:
1- Install `l10n_vn_edi_viettel`
2- Use credentials to put in Account settings
3- Fill the TIN under res.company
4- Go to symbols under configuration, fetch and select a symbol with a 'C' in the name
5- Create invoice, use symbol for VN e-invoice. Click Send
6- Create Credit note, click confirm on wizard

Current behavior before PR:
Validating the Credit Note would raise a Traceback.
```
AttributeError: 'account.move' object has no attribute '_l10n_vn_edi_lookup_invoice'
```

Desired behavior after PR is merged:
Validating the Credit Note should process as expected, without errors.



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

Forward-Port-Of: odoo/odoo#274616

**Issue**
The priority of a purchase order is not propagated to the corresponding picking

**Steps to reproduce**
- Create a PO for a product
- Click on the star (set priority)
- Confirm the PO and open the corresponding picking -> The priority is not set on the picking

**Cause**
The feature was introduced in 19.2 and worked through `_prepare_picking()` (4eb64d15d10a258e2902818304c29681fe268553): 
https://github.com/odoo/odoo/blob/4eb64d15d10a258e2902818304c29681fe268553/addons/purchase_stock/models/purchase_order.py#L401

However a refactor in 19.3 removed that method without preserving the priority propagation (a1fb39eb6ae0d1abc12ab2aaf876b10baed4d7cd). Instead of using `_prepare_picking`, it creates the moves and confirm it: 
https://github.com/odoo/odoo/blob/a1fb39eb6ae0d1abc12ab2aaf876b10baed4d7cd/addons/purchase_stock/models/purchase_order.py#L387-L388 
which will create the picking (if needed):
https://github.com/odoo/odoo/blob/9221edd716ac241a301fa25d511fde0edb17b3f4/addons/stock/models/stock_move.py#L1449 https://github.com/odoo/odoo/blob/9221edd716ac241a301fa25d511fde0edb17b3f4/addons/stock/models/stock_move.py#L1476

opw-6275965

Forward-Port-Of: odoo/odoo#268880

Currently, if a discount program has a max discount, this value is not taken into account when computing the amount left to discount.

Steps to reproduce:
-------------------
* Create a loyalty program, it needs a reward as such: 100% discount on product A, maximum discount 100
* Create a discount code program, it needs a reward as such: 15% discount on product A
* Open pos, make an order, add product A, change its price to 1000
* In this order:
  * Add the loyalty program reward (100%)
  > Only 100$ discount since it's the max
  * Add the discount code reward
  > Nothing happens, no reward line added, no message saying the code didn't applied

Why the fix:
------------
When we compute the amount left to discount `getDiscountable` when we try to apply the last reward we have `discount = 1` as the loyalty reward line is set up to a 100% discount. This ends up leaving `remainingAmountPerLine[line.uuid]` to be 0.

The current state of the code does not take into account the maximum discount which, if triggered, means we still have something remaining to discount.

We introduce this discount in a straightforward way for the moment. We simply compare the theoretical discount `remainingAmountPerLine[line.uuid] * discount` to the max.

This is a simple version intended to make this work. In the future we could imagine taking all the lines the discount applies to and compute the proportion that is applied to the specific line. This approach was already discussed in the past for fixed amount discounts and was not implemented as it would make the code more complex (and unreadable) than needed. We're assuming the same approach applies here. We make it work first and see if there's ever a need to complexify it.

opw-6129625

Forward-Port-Of: odoo/odoo#262499

_**Steps to reproduce:**_

* Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings.
* Switch to a Polish company.
* Create an EU customer with a valid VAT number.
* Create a sale order containing a service product taxed with **0% EU S**.
* Confirm the sale order and create a down payment invoice.
* Send the invoice to KSeF and inspect the generated XML.

**_Observed behavior:_**

* The generated KSeF XML does not contain the `P_13_9` field.

**_Cause:_**

* For down payment invoices involving services taxed with **0% EU S**, the value corresponding to `P_13_9` was not being assigned during XML generation, causing the tag to be omitted from the exported KSeF document.

**_Fix_**:

* Populate the value of `P_13_9` during KSeF XML generation for service down payment invoices, ensuring the field is correctly included in the exported XML.
* This PR updates the computation of tag `P_13_10` to ensure consistency with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

opw-6294181

Forward-Port-Of: odoo/odoo#275755
Forward-Port-Of: odoo/odoo#270986

When Google sends a recurrence with UNTIL in UTC (UNTIL=...Z), users in timezones behind UTC can get one extra occurrence on the boundary day. Google's UNTIL represents the last allowed start in UTC, but that UTC date fell into the previous local day. Because Odoo was comparing event start times as naive local datetimes against a cutoff derived from the wrong date, the boundary occurrence passed the check and was created.

Steps to reproduce:
1. Set the user's timezone to a UTC-negative offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. In Google Calendar, create a weekly recurring event (e.g. every Thursday at 12:00 local).
3. Edit the series with "This and following events" so the old series ends with UNTIL set to 02:59:59 UTC of the next day (= 23:59:59 local of the last valid occurrence day).
4. Sync with Odoo -> an extra event is created on the day after the last valid Thursday, which does not exist in Google Calendar.

opw-6024835

Forward-Port-Of: odoo/odoo#274593
Forward-Port-Of: odoo/odoo#265297

Typing in an HTML field (e.g. a contact's Internal Notes) and validating
a URL-like token with Enter or Space can crash the editor with
"IndexSizeError: The index is not in the allowed range", leaving the
user unable to continue typing. It happens on Safari (not Chromium).

The trigger is a URL-like token that the editor auto-converts into a
link. The splitText calls in prepareConvertToLink, run during
beforeinput, leave Safari's native selection anchored on an empty text
node with an out-of-range offset. Anything reading the selection
afterwards then works from a broken position: on Enter, splitBlock
reads it and makeActiveSelection ends up throwing in Range.setStart;
on Space, the browser inserts the character in the wrong node and the
selection is corrupted the same way.

```
UncaughtClientError > IndexSizeError
Uncaught Javascript Error > The index is not in the allowed range.
    setStart@[native code]
    createEditorSelection@.../web.assets_web.min.js:12239:15
    getSelectionData@.../web.assets_web.min.js:12242:145
    updateActiveSelection@.../web.assets_web.min.js:12230:92
    @.../web.assets_web.min.js:12218:873
    handler@.../web.assets_web.min.js:14366:121
```

Steps to reproduce:

1. Use Safari (Chromium-based browsers work fine)
2. Open any record with an HTML field (e.g. Contacts -> a contact ->
   Internal Notes).
3. Type a URL-like token such as KF.16D2.0204.CG (.CG is a valid TLD,
   so the editor auto-links it). Do not paste it.
4. Place the caret at the end of that token and press Enter or Space.
5. IndexSizeError is raised and the editor stops accepting input.

Fix it at the source: re-anchor the selection right after the splits in
prepareConvertToLink, so every consumer sees a valid caret position.
Since moving the selection during beforeinput makes WebKit cancel the
pending text insertion, the Space case now prevents the default and
performs the conversion, the space insertion and the caret placement
itself, in two history steps so that undo still reverts the link
conversion while keeping the typed space.

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

Forward-Port-Of: odoo/odoo#276049
Forward-Port-Of: odoo/odoo#270910

CertificateAdapter presents a client certificate stored in the database instead of on disk when opening an HTTPS connection (used by the l10n_es EDI modules verifactu, sii and tbai). It loaded that certificate on the connection path of requests 2.31, but requests >= 2.32 changed that path (no longer calls get_connection()), so the step was skipped and the call crashed with: "TypeError: expected str, bytes or os.PathLike object, not certificate"

Odoo pins requests 2.31.0 (max depending on Python version), but online databases can use the version shipped by the OS (2.32.x on recent Ubuntu 26).

Set the certificate up when the adapter is created instead of on that connection call. That step runs the same on every requests version, so the fix works both before and after 2.32.

Steps to reproduce:
  - Spanish company with Veri*Factu and a certificate, on a server
  running requests >= 2.32 (saas-19.3 database for exemple on ubuntu 26)
  - Post a customer invoice and send it to Veri*Factu.
  => TypeError

Reference: https://github.com/psf/requests/blob/f361ead047be5cb873174218582f7d8b9fcd9f49/HISTORY.md?plain=1#L146

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

Forward-Port-Of: odoo/odoo#276456
Forward-Port-Of: odoo/odoo#275324

**Steps to reproduce:**
1. Go to Website > Edit a page.
2. Add multiple Badges side by side.
3. Save the page.
4. Switch the website language, click on Edit/Translate and
translate the badges.
5. Save.

**Issue:**
After saving in translate mode, all badge elements are merged into
one.

**Why this happens:**
During save, `cleanForSave` triggers `mergeAdjacentInlines` on a
detached clone of the dirty element. This clone lacks all the css
styling, so `getComputedStyle` returns `""` for all padding/margin
on detached nodes. Consequently, `areSimilarElements` incorrectly
considers sibling `s_badge` spans as identical and merges them.

A recent fix (https://github.com/odoo/odoo/commit/91972ec2bbd85f9cfd7a1af794bbb2385a312f30) applied to `BadgeOptionPlugin` registers
`s_badge` as unsplittable via `unsplittable_node_predicates`,
preventing the merge in normal edit mode. However, translate mode
loads a separate plugin, `BadgeTranslationPlugin`, which was added
in the commit https://github.com/odoo/odoo/commit/cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 that lacks the same predicate.

opw-6261146

Forward-Port-Of: odoo/odoo#276387
Forward-Port-Of: odoo/odoo#273986

Currently, flexible weekly overtime deducts the raw leave interval duration.

## **Steps to reproduce:**
- Install hr_holidays and hr_attendance
- Create an employee with flex 40h/week working schedule.
- Employee profile>setting>Default Ruleset>Employee schedule Rule and set `If the worked hours on a`: `week`.
- Create a public holiday on Monday.
- Record daily 8h from Tue to Sat (12 AM to 8 AM).

## **Observed Behavior:**
Attendance List View computes "Worked Extra Hours" incorrectly as 20:30h

## **Expected Behavior:**
"Worked Extra Hours" should be computed as 8h

## **Root Cause:**
In [_get_daterange_overtime_undertime_intervals_for_quantity_rule](https://github.com/odoo/odoo/blob/53448e5445c8bcbf12126bf27bd675f4b9883d05/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L290-L342), the system manually calculates overtime for flexible employees by deducting `schedule['leave']` durations from the expected working hours at [1]. However, for global public holidays, the system mishandles the timezone conversion within this schedule dictionary. Because public holiday intervals are stored and processed using UTC datetimes before being converted to the employee's local timezone, converting it to the employee's local timezone causes the holiday hours to shift and overlap into the next calendar day. As a result, the `schedule['leave']` calculation incorrectly thinks the employee had time off on normal working days, which throws off the final overtime amount.

[1]: http://github.com/odoo/odoo/blob/53448e5445c8bcbf12126bf27bd675f4b9883d05/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L304-L307

## **Fix:**
Replace the manual leave subtraction logic with the existing `_get_expected_hours_from_contract` method. This method naturally handles global public holidays and computes attendance intervals safely across different timezones without shifting hours into the wrong day.

**opw-6259328,6284145**

Forward-Port-Of: odoo/odoo#275885
Forward-Port-Of: odoo/odoo#269293

The "bus subscription is refreshed when channel is joined/left" tests were flaky:
- `mockDate` needs 2 digit date/time parts. The format used here didn't always produce them, so it silently fell back to a past date. That was enough to make the "left" test pass even without actually leaving.
- The "left" test never actually left the channel: a confirm dialog blocked it.
- The "join" test never actually joined the channel.
- The tests expected `runAllTimers` to guarantee that every initial subscription was done, but thats not the case, making the number of `subscribe` calls non-deterministic (e.g. flushing calls to `bus_service.add` but not ensuring the worker received them through its message port, and triggered the debounced `updateChannels`).

Fixing the tests exposed a real bug: `memberBusSubscription` is meant to trigger a refresh whenever membership changes relative to the bus start time. As a boolean, "member, no refresh needed" and "not a member" are indistinguishable (both `false`), so leaving a channel joined before the bus started never changed the value and never triggered a refresh.

This PR add a third state so membership and non-membership stay distinguishable regardless of when the bus started.

runbot-941462

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#276712
Forward-Port-Of: odoo/odoo#275938

**Steps to reproduce:**
- Install Contacts app
- Open any record
- Go to the chatter
- Create an activity with a description
- Duplicate the tab
- Go back to the initial tab
- Description doesn't appear anymore
- Refreshing shows it but will remove it from the other tab

**Issue:**
Behavior comes from the broadcasting of activity changes between tabs `new browser.BroadcastChannel("mail.activity.channel");`.

Computed fields are not recomputed on the receiver side after value insertion in `_onActivityBroadcastChannelMessage` (also related components are not (re)mounted, e.g. when a new activity is created the other tab doesn't show it without a refresh).

This means that `isNoteEmpty` keeps its default value `true` (added by `this.toData()`) and the `note` stays hidden here [1]:
```xml
<div t-if="!props.activity.isNoteEmpty" class="o-mail-Activity-note text-break" t-out="props.activity.note"/>
```

**Fix:**
Remove computed fields in activity `serialize` before broadcasting them to ensure they don't force the default value.

(note installing `calendar` in 19.3+ removes this issue due to [2] which overrides the condition on `isNoteEmpty`)

[1] https://github.com/odoo/odoo/commit/eb9f0658c3da1a9fef69f1cc1117c2d44f9d61b1
[2] https://github.com/odoo/odoo/commit/44e2c2c5ca07849fd8964140f3ca61122c47f0c6

opw-6247412

Forward-Port-Of: odoo/odoo#276032
Forward-Port-Of: odoo/odoo#275528

In multicompany, it can happen that one company (let's call it company Origin) cannot handle a payment method in their country, so it uses another company's (company MoneyHandler), even if it's in another country. The accounting flows must be then adjusted:

- In company Origin, the invoice must be matched by a clearing entry
- In company MoneyHandler, payment must match its move (if it exists) with a clearing entry. The payment move doesn't exist if `account_accountant` is installed but no Outstanding account is configured on the payment method line.

Same but opposite thing must happen for credit notes in company Origin that match a reimbursement in company MoneyHandler.

Cancellation of a payment must be reflected on the entries: deleting when feasible, reversing when not (unless a lock date/hash is present, which would block the cancellation)

_(To do: testing/review, credit note, cancellation/reversal of the payment)_

Task [link](https://www.odoo.com/odoo/project.task/6037525)
task-6037525

Forward-Port-Of: odoo/odoo#259197

Steps to produce:
---
- Install the `sales` module.
- Create a product and `enable track inventory.`
- Log in as user with only view access rights in products and also have the sales access rights.
- Create a sale order containing product and confirm it.

Issue:
---
-  An access error is raised during order confirmation.

Root cause:
---
- In [commit], to handle inventory tracking, the `qty_available` field
was moved to `product.product`. Unlike before, this value is increased
or decreased depending on the operation performed.

- As a consequence, creating or updating a sale order triggers a write
to this `qty_available` field on the related product. This
write happens under the current user's permissions, so users who
only have read access to products (but can create/edit sale orders)
hit an `AccessError`, since they lack write access on
`product.product`.


Solution:
---
- Use `sudo()` when accessing the required product quantity information
  to ensure the operation can be completed without requiring additional product
  access rights.

The same issue also occurs when confirming a purchase order.

[commit]: https://github.com/odoo/odoo/commit/ca96992919b11105da44238c3e522f8eec4a740b

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

Forward-Port-Of: odoo/odoo#276253
Forward-Port-Of: odoo/odoo#270067

Currently, if a discount program has a max discount, this value is not taken into account when computing the amount left to discount.

Steps to reproduce:
-------------------
* Create a loyalty program, it needs a reward as such: 100% discount on product A, maximum discount 100
* Create a discount code program, it needs a reward as such: 15% discount on product A
* Open pos, make an order, add product A, change its price to 1000
* In this order:
  * Add the loyalty program reward (100%)
  > Only 100$ discount since it's the max
  * Add the discount code reward
  > Nothing happens, no reward line added, no message saying the code didn't applied

Why the fix:
------------
When we compute the amount left to discount `getDiscountable` when we try to apply the last reward we have `discount = 1` as the loyalty reward line is set up to a 100% discount. This ends up leaving `remainingAmountPerLine[line.uuid]` to be 0.

The current state of the code does not take into account the maximum discount which, if triggered, means we still have something remaining to discount.

We introduce this discount in a straightforward way for the moment. We simply compare the theoretical discount `remainingAmountPerLine[line.uuid] * discount` to the max.

This is a simple version intended to make this work. In the future we could imagine taking all the lines the discount applies to and compute the proportion that is applied to the specific line. This approach was already discussed in the past for fixed amount discounts and was not implemented as it would make the code more complex (and unreadable) than needed. We're assuming the same approach applies here. We make it work first and see if there's ever a need to complexify it.

opw-6129625

Forward-Port-Of: odoo/odoo#262499

_**Steps to reproduce:**_

* Install `l10n_pl_edi` and enable **Allow KSeF integration** from Accounting settings.
* Switch to a Polish company.
* Create an EU customer with a valid VAT number.
* Create a sale order containing a service product taxed with **0% EU S**.
* Confirm the sale order and create a down payment invoice.
* Send the invoice to KSeF and inspect the generated XML.

**_Observed behavior:_**

* The generated KSeF XML does not contain the `P_13_9` field.

**_Cause:_**

* For down payment invoices involving services taxed with **0% EU S**, the value corresponding to `P_13_9` was not being assigned during XML generation, causing the tag to be omitted from the exported KSeF document.

**_Fix_**:

* Populate the value of `P_13_9` during KSeF XML generation for service down payment invoices, ensuring the field is correctly included in the exported XML.
* This PR updates the computation of tag `P_13_10` to ensure consistency with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

opw-6294181

Forward-Port-Of: odoo/odoo#275755
Forward-Port-Of: odoo/odoo#270986

When Google sends a recurrence with UNTIL in UTC (UNTIL=...Z), users in timezones behind UTC can get one extra occurrence on the boundary day. Google's UNTIL represents the last allowed start in UTC, but that UTC date fell into the previous local day. Because Odoo was comparing event start times as naive local datetimes against a cutoff derived from the wrong date, the boundary occurrence passed the check and was created.

Steps to reproduce:
1. Set the user's timezone to a UTC-negative offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. In Google Calendar, create a weekly recurring event (e.g. every Thursday at 12:00 local).
3. Edit the series with "This and following events" so the old series ends with UNTIL set to 02:59:59 UTC of the next day (= 23:59:59 local of the last valid occurrence day).
4. Sync with Odoo -> an extra event is created on the day after the last valid Thursday, which does not exist in Google Calendar.

opw-6024835

Forward-Port-Of: odoo/odoo#274593
Forward-Port-Of: odoo/odoo#265297

**Issue:**
The course-specific options should appear after the forum page options,
but they are displayed before them.

**Reason:**
Due to refactoring [commit], the course-specific options were inserted
after a generic page hook. Since `website_slides_forum` is loaded before
the forum module, the options were added before the forum page options,
resulting in an incorrect order.

**Steps to Reproduce:**
1. Go to /forum.
2. Enter edit mode.
3. Notice that the course-specific options appear before the forum page
   options.

**Fix:**
Extend the forum page options instead of the generic page hook ensuring
course-specific options to be inserted after the forum page options.

| Before | After |
| ----- | -----|
| <img width="285" height="267" alt="image" src="https://github.com/user-attachments/assets/73fb1f27-4edc-47eb-8bed-a873aea8a427" /> | <img width="285" height="268" alt="image" src="https://github.com/user-attachments/assets/d56aac2a-c66f-4c81-b04e-f204613d2c9c" /> | 


[commit]: https://github.com/odoo/odoo/commit/3f63c76da0b867facd5ed021beea79efabea15f1
task-[6359989](https://www.odoo.com/odoo/project/974/tasks/6359989)

Steps to reproduce:
===================
1. Drop an "Events" block on a website page.
2. In edit mode, try selecting the inner text by clicking multiple times.

=> Uncaught client error: TypeError: Cannot read properties of
   undefined (reading 'nodeType').

Root cause:
===========
When a mouse selection crosses an uncrossable element, the selection restriction plugin moves the focus to the deepest position of the element sibling adjacent to the uncrossable one.

When the first selected node is itself an uncrossable element (event cards are `div` elements) that has no previous/next element sibling, `node.previousElementSibling` is null and `tempFocusNode` was never assigned by a previous iteration, so it is undefined. `nodeSize` then reads `nodeType` on undefined and throws.

The plugin only exists from saas-19.3, which is why the issue is not reproducible on earlier versions.

Fix:
====
When there is no sibling to place the focus on, fall back to the boundary just outside the uncrossable node itself (`leftPos` when selecting left to right, `rightPos` when selecting right to left) instead of calling `nodeSize`/`getDeepestPosition` with undefined.

opw-6362955


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

**Steps to reproduce:**
- Create a fiscal position T1, with detect automatically
- Create another one T2, without the detect automatically
- When looking at the fiscal positions list, make sure T1 is on top, followed by T2
- Go to the PoS settings, check flexible taxes
- Put T2 as default and in allowed, don't put T1 in allowed
- Go to the PoS, chose a customer
- The fiscal position is T1 even though it's not allowed

**Why the fix:**

Currently, the fiscal position is chosen like this in order:
- A FP specified on the customer's profile
- A FP detected with the detect automatically setting
- The default FP from the PoS settings

When we have a tie, it's the first one in the fiscal positions list that is chosen.

Before this commit, we did not check that the fiscal position was allowed to be used in the PoS, so we just fetched whatever fiscal position fit the best for a given customer and didn't check if we could actually use it.

We now make sure that the fiscal position we try to use is allowed in the current PoS, and if it's not we fall back to the default one.

opw-6032031

Forward-Port-Of: odoo/odoo#271343

Version:
---------
- 19.0+

Steps to Reproduce:
-----------------------
1. Install sale_management, purchase, stock modules.
2. Create a storable product with Tracking: By Lot,
3. Create two Purchase Orders, each for 10 units.
   Receive PO-1 → 10 units with tagged as lot-1
   Receive PO-2 → 10 units with tagged as lot-2
4. Create two Sale Orders:
   SO-1 → deliver 2 units from lot-1 (validate)
   SO-2 → deliver 4 units from lot-2 (validate)
5. Open Inventory > Reporting > Stock,
   click "Total Value", then check the "Remaining Quantity" column

Issue:
-------
Observed : remaining_qty = 10 for lot-2 receipt, 4 for lot-1 receipt
Expected : remaining_qty = 8 for lot-1 receipt (10−2), 6 for lot-2 receipt (10−4)

Cause:
--------
When the "Remaining Quantity" column is computed, the following call
chain executes:

  stock.move._compute_remaining_qty()
    → calls product.product._get_remaining_moves()
        → calls product._run_fifo_get_stack()   ← HERE is the problem

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L372

`_get_remaining_moves` calls `_run_fifo_get_stack()` with NO lot
argument. Inside `_run_fifo_get_stack`, because no lot is given, it
computes the stack size from the TOTAL product qty across all lots:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L583

  fifo_stack_size = 14   (10 received lot-1 + 10 received lot-2
                          − 2 delivered lot-1 − 4 delivered lot-2)

It then builds a domain to find incoming moves with NO lot filter:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L607

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L614-L618

  ```Domain: [('is_in', '=', True), ('product_id', '=', X)]
  ↳ returns both receipts ordered:
      [lot-2 receipt (10 qty), lot-1 receipt (10 qty)]

then walks this list consuming `fifo_stack_size = 14`:
So it take: [move_lot1_receipt(10)]  First Lot

remaining_qty_on_first = min(10, 14) = 10 
after consuming fifo_stack_size →  14−10=4 left → move_lot1 gets 4
```
So back in `_get_remaining_moves`:

  qty_by_move = {
      lot-2 receipt → 10,   ← wrong (should be 6)
      lot-1 receipt →  4,   ← wrong (should be 8)
  }

- The root cause: `_run_fifo_get_stack` is designed for products that
have one shared FIFO stack. For lot-valuated products, each lot is an
independent inventory layer. Running a single combined stack mixes both
lots together, so the deductions (2 from lot-1, 4 from lot-2) are not
attributed to the correct receipt moves — the algorithm just consumes
from the oldest receipts first with no awareness of which lot was
actually delivered.

Fix:
-----
`_run_fifo_get_stack` already accepts a `lot=` argument that:
- sets `fifo_stack_size = lot.product_qty` (correct per-lot qty)
- adds `('move_line_ids.lot_id', 'in', lot.id)` to the domain
  so only the receipts that touched that specific lot are returned
The only missing piece was calling it per lot instead of once globally.

- With the fix, the stack for each lot is built correctly:
  lot-1: fifo_stack_size = 8 → lot-1 receipt remaining_qty = 8  ✓
  lot-2: fifo_stack_size = 6 → lot-2 receipt remaining_qty = 6  ✓

---

opw-6311341

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

Forward-Port-Of: odoo/odoo#272411

Steps to Reproduce
---
- Create a normal parent task with one normal sub-task and one template sub-task.
- Open the parent task form view and observe the Sub-tasks stat button count and
notebook tab, check the subtask view as well.
- Create a template parent task with one normal sub-task and one template sub-task,
then repeat the same checks.

Issue
---
- Task templates are handled like regular subtasks in the subtask count, notebook, and
subtask view, without taking the parent task type into account.

Current Behaviour
---
- For a normal parent task, both the normal sub-task and the template sub-task are
counted and shown in the opened subtask view and notebook.
- For a template parent task, the same filtering is applied, even though template subtasks
should remain accessible in that context.

Expected Behaviour
---
- For a normal parent task, only real sub-tasks should be counted and shown in the subtask
view and notebook, and on the project kanban card.
- For a template parent task, template subtasks should remain available in the subtask
view and notebook according to the parent template context.
- In the project kanban card, tasks must not be counted when their parent task is a template,
 even if the child task itself is not a template.

Fix
---
- Apply template-aware filtering to subtask counting,project kanban task count and subtask view
 behavior, depending on whether the parent task is a normal task or a template task.

task-5966684

Forward-Port-Of: odoo/odoo#275002
Forward-Port-Of: odoo/odoo#252403

Currently, if a discount program has a max discount, this value is not taken into account when computing the amount left to discount.

Steps to reproduce:
-------------------
* Create a loyalty program, it needs a reward as such: 100% discount on product A, maximum discount 100
* Create a discount code program, it needs a reward as such: 15% discount on product A
* Open pos, make an order, add product A, change its price to 1000
* In this order:
  * Add the loyalty program reward (100%)
  > Only 100$ discount since it's the max
  * Add the discount code reward
  > Nothing happens, no reward line added, no message saying the code didn't applied

Why the fix:
------------
When we compute the amount left to discount `getDiscountable` when we try to apply the last reward we have `discount = 1` as the loyalty reward line is set up to a 100% discount. This ends up leaving `remainingAmountPerLine[line.uuid]` to be 0.

The current state of the code does not take into account the maximum discount which, if triggered, means we still have something remaining to discount.

We introduce this discount in a straightforward way for the moment. We simply compare the theoretical discount `remainingAmountPerLine[line.uuid] * discount` to the max.

This is a simple version intended to make this work. In the future we could imagine taking all the lines the discount applies to and compute the proportion that is applied to the specific line. This approach was already discussed in the past for fixed amount discounts and was not implemented as it would make the code more complex (and unreadable) than needed. We're assuming the same approach applies here. We make it work first and see if there's ever a need to complexify it.

opw-6129625

Forward-Port-Of: odoo/odoo#262499

When Google sends a recurrence with UNTIL in UTC (UNTIL=...Z), users in timezones behind UTC can get one extra occurrence on the boundary day. Google's UNTIL represents the last allowed start in UTC, but that UTC date fell into the previous local day. Because Odoo was comparing event start times as naive local datetimes against a cutoff derived from the wrong date, the boundary occurrence passed the check and was created.

Steps to reproduce:
1. Set the user's timezone to a UTC-negative offset (e.g. America/Argentina/Buenos_Aires, UTC-3).
2. In Google Calendar, create a weekly recurring event (e.g. every Thursday at 12:00 local).
3. Edit the series with "This and following events" so the old series ends with UNTIL set to 02:59:59 UTC of the next day (= 23:59:59 local of the last valid occurrence day).
4. Sync with Odoo -> an extra event is created on the day after the last valid Thursday, which does not exist in Google Calendar.

opw-6024835

Forward-Port-Of: odoo/odoo#274593
Forward-Port-Of: odoo/odoo#265297

**Steps to reproduce:**
- create storable avco product
- set the cost to 10 
- set an onhand quantity of 100 in WH/stock
- create another warehouse (if you don't already 
have another one)
- create an internal transfer from WH/Stock 
to WH2
- open the 'stock' view 
- click on inventory at date 
- confirm

**Current behavior:**
the total value is 11.000

**Expected behavior:**
total value should be 10.000

**Cause of the issue:**
To compute the total_value of the product, 
_compute_value calls _run_average_batch
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/stock_account/models/product.py#L260
Inside run_average_batch we need the qty_available 
at the time of last manual value (which is when 
we set the cost to 10 manually) in order to value 
all this quantity at the value of the manual value.
https://github.com/odoo/odoo/blob/68f258e99f42693131a5309b3606c3b95f93d824/addons/stock_account/models/product.py#L435

This qty should be 0 cause we had no onhand quantity 
when we set the cost to 10. 
But it's actually going to be 10, here is why : 

Inside _compute_quantities_dict, because we're 
asking for a quantity in the past, the computation is 
current quantity - quantities that went in between 
the date in the past and now + quantities that went 
out between the date in the past and now. 
https://github.com/odoo/odoo/blob/154b49ec6be6230989ee4eb420e7f83b681ff520/addons/stock/models/product.py#L255
So we should have : 100 - 100 (moves_in_res_past) + 0 
(moves_out_res_past) = 0
because we have 100 now and between the date 
we're asking for (the time of the manual value) and 
now there is one move in (when we set a quantity of 100) 
and no move out.

But moves_out_res_past will actually be 10 for our product
instead of 0. 
That's because in the read_group, our internal move 
will be considered as a move out and be taken into account 
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L233-L234

That's because: 
When we called _run_average_batch from 
_compute_value, we called it on 'products_to_value', 
which is based on 'products', which was computed 
calling with_valuation_context() 
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock_account/models/product.py#L206
which passes the valued internal location in the context
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock_account/models/product.py#L366-L370
As wh2 is not internal (it's a view) it's not included in the locations 
from the context.
strict is also set to True

Therefore at the beginning of compute_quantities_dict, 
when we call _get_domain_location to compute 
domain_move_out_loc (on which domain_move_out_done 
will be based),
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L165
inside _get_domain_location, because a location is 
given in the context that's the one we're going to use. 
https://github.com/odoo/odoo/blob/60cf607d7148ebe389cc8513aa3b82e156cd4400/addons/stock/models/product.py#L365
and because strict is in the context, dest_location_domain_out
will be "location_dest_id not in [the list of valued location 
which does not include wh2]".
https://github.com/odoo/odoo/blob/7e95d32d669a7ee7c50b5e665697cb577be0af93/addons/stock/models/product.py#L402-L405
And back in compute_quantities_dict(), 
domain_move_out_loc will be "location_id in [the list 
of valued location] and location_dest_id not in 
[the list of valued location]".
Our internal move will therefore be considered 
as an out move and taken into account in the computation
mentioned above.

Which explains why quantity will be 10 inside 
run_average_batch and why the computation 
of total_value is wrong

**fix:**
in 19.0 the fix is in the xml to take less risk 
with regards to stable policy, however starting 
from 19.1 the fix will be in python
opw-6321636

Forward-Port-Of: odoo/odoo#275384
Forward-Port-Of: odoo/odoo#273388

**PROBLEM**
`_cron_migrate_local_to_cloud_storage()` is used to migrate attachment to a cloud storage. It delete the attachment from the database, rendering it innacessible from the server-side. The problem is it can delete attachment used in business logic.

**STEP TO REPRODUCE**
1. Install and configure cloud_storage + a provider (e.g. cloud_storage_google) and cloud_storage_migration.
2. Install l10n_mx_edi and stamp a customer invoice. The CFDI XML is stored as an ir.attachment that:
  - is referenced by a business Many2one l10n_mx_edi.document.attachment_id (copied into account.move.l10n_mx_edi_cfdi_attachment_id),
  - has res_field = NULL (record attachment, not a field binary),
  - is posted to the chatter → it has a row in message_attachment_rel.
3. Add account.move to cloud_storage_migration_message_models and set a low enough cloud_storage_min_file_size.
4. Run the cron _cron_migrate_local_to_cloud_storage.
5. Open the invoice and trigger any recompute of the EDI chain (e.g. Update Payments, a reconciliation, or re-stamping).

**FIX**
Filters out attachment linked to a model listed by the already existing function `_get_cloud_storage_unsupported_models()`

opw-6347198

Forward-Port-Of: odoo/odoo#275945

Currently, if a discount program has a max discount, this value is not taken into account when computing the amount left to discount.

Steps to reproduce:
-------------------
* Create a loyalty program, it needs a reward as such: 100% discount on product A, maximum discount 100
* Create a discount code program, it needs a reward as such: 15% discount on product A
* Open pos, make an order, add product A, change its price to 1000
* In this order:
  * Add the loyalty program reward (100%)
  > Only 100$ discount since it's the max
  * Add the discount code reward
  > Nothing happens, no reward line added, no message saying the code didn't applied

Why the fix:
------------
When we compute the amount left to discount `getDiscountable` when we try to apply the last reward we have `discount = 1` as the loyalty reward line is set up to a 100% discount. This ends up leaving `remainingAmountPerLine[line.uuid]` to be 0.

The current state of the code does not take into account the maximum discount which, if triggered, means we still have something remaining to discount.

We introduce this discount in a straightforward way for the moment. We simply compare the theoretical discount `remainingAmountPerLine[line.uuid] * discount` to the max.

This is a simple version intended to make this work. In the future we could imagine taking all the lines the discount applies to and compute the proportion that is applied to the specific line. This approach was already discussed in the past for fixed amount discounts and was not implemented as it would make the code more complex (and unreadable) than needed. We're assuming the same approach applies here. We make it work first and see if there's ever a need to complexify it.

opw-6129625

Forward-Port-Of: odoo/odoo#262499

Version:
---------
- 19.0+

Steps to Reproduce:
-----------------------
1. Install sale_management, purchase, stock modules.
2. Create a storable product with Tracking: By Lot,
3. Create two Purchase Orders, each for 10 units.
   Receive PO-1 → 10 units with tagged as lot-1
   Receive PO-2 → 10 units with tagged as lot-2
4. Create two Sale Orders:
   SO-1 → deliver 2 units from lot-1 (validate)
   SO-2 → deliver 4 units from lot-2 (validate)
5. Open Inventory > Reporting > Stock,
   click "Total Value", then check the "Remaining Quantity" column

Issue:
-------
Observed : remaining_qty = 10 for lot-2 receipt, 4 for lot-1 receipt
Expected : remaining_qty = 8 for lot-1 receipt (10−2), 6 for lot-2 receipt (10−4)

Cause:
--------
When the "Remaining Quantity" column is computed, the following call
chain executes:

  stock.move._compute_remaining_qty()
    → calls product.product._get_remaining_moves()
        → calls product._run_fifo_get_stack()   ← HERE is the problem

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L372

`_get_remaining_moves` calls `_run_fifo_get_stack()` with NO lot
argument. Inside `_run_fifo_get_stack`, because no lot is given, it
computes the stack size from the TOTAL product qty across all lots:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L583

  fifo_stack_size = 14   (10 received lot-1 + 10 received lot-2
                          − 2 delivered lot-1 − 4 delivered lot-2)

It then builds a domain to find incoming moves with NO lot filter:

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L607

https://github.com/odoo/odoo/blob/f4d079cc5a9c47672cf1a6747bb073e8e74f7350/addons/stock_account/models/product.py#L614-L618

  ```Domain: [('is_in', '=', True), ('product_id', '=', X)]
  ↳ returns both receipts ordered:
      [lot-2 receipt (10 qty), lot-1 receipt (10 qty)]

then walks this list consuming `fifo_stack_size = 14`:
So it take: [move_lot1_receipt(10)]  First Lot

remaining_qty_on_first = min(10, 14) = 10 
after consuming fifo_stack_size →  14−10=4 left → move_lot1 gets 4
```
So back in `_get_remaining_moves`:

  qty_by_move = {
      lot-2 receipt → 10,   ← wrong (should be 6)
      lot-1 receipt →  4,   ← wrong (should be 8)
  }

- The root cause: `_run_fifo_get_stack` is designed for products that
have one shared FIFO stack. For lot-valuated products, each lot is an
independent inventory layer. Running a single combined stack mixes both
lots together, so the deductions (2 from lot-1, 4 from lot-2) are not
attributed to the correct receipt moves — the algorithm just consumes
from the oldest receipts first with no awareness of which lot was
actually delivered.

Fix:
-----
`_run_fifo_get_stack` already accepts a `lot=` argument that:
- sets `fifo_stack_size = lot.product_qty` (correct per-lot qty)
- adds `('move_line_ids.lot_id', 'in', lot.id)` to the domain
  so only the receipts that touched that specific lot are returned
The only missing piece was calling it per lot instead of once globally.

- With the fix, the stack for each lot is built correctly:
  lot-1: fifo_stack_size = 8 → lot-1 receipt remaining_qty = 8  ✓
  lot-2: fifo_stack_size = 6 → lot-2 receipt remaining_qty = 6  ✓

---

opw-6311341

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

Forward-Port-Of: odoo/odoo#272411

**Steps to reproduce:**
Both problem are reproducible on runbot aswell 
but for more clarity (and for empty accounting), 
those steps are on a fresh db with no demo data

Problem 1 : 
- create a new db with stock_account, purchase 
and accountant
- In the companies view, select your company
- in the branch tab, create a branch for your company
- for both the branch and the company, in the settings 
set the valuation as periodic daily

With only the branch company selected:
- create a warehouse for your branch
- create a storable prod with a cost of 10
- validate a receipt for 1 unit of the prod
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'

With the main company selected: 
- Open journal items
- click on the journal entry of  any of the move line 
with label 'closing stock variation global for 
company [branch]'
- select the 'other info' tab


Problem 2: 
- create a new db with stock_account, purchase 
and accountant
- create a company 2 
- for both companies, in the settings 
set the valuation as periodic daily

With company 2 selected
- create a warehouse for company 2
- in the settings for fiscal localization set the 
'generic chart of account'
- create a storable product with a cost of 10
- validate a receipt for 1 quantity of the product
- open inventory valuation view and check 
that there is variation lines for 10
- open 'scheduled actions' view
- select 'inventory valuation closing' 
- click on 'run manually'


**Current behavior:**
Problem 1: 
the company of the account move 
is the main company

Problem 2: 
There is a traceback including 
'UserError: Everything is correctly closed'

**Expected behavior:**
Problem 1: 
It should be the branch company

Problem 2: 
Everything is closed in company 1, but 
it shouldn't prevent to generate the entries
for company 2

**Cause of the issue:**
Problem 1: 
Inside _cron_post_stock_valuation
we call action_close_stock_valuation for each company
(if periodic daily or periodic monthly and we're the last 
day of the month)
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L143-L144

Inside action_close_stock_valuation when creating 
the account move we add a context to be sure that 
the move is created for the main company selected 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L72
The fix comes from this PR 
https://github.com/odoo/odoo/pull/263828
and was improved starting from 19.1 
to simply add a the company_id on the moves_vals.

But the problem is that this fix failed to consider 
the case where we come from cron because 
in this case self.env.company is the main company 
of the user, which is a problem because  as we iterate 
through the companies we want each account 
move to be created for its own company.
This other PR https://github.com/odoo/odoo/pull/269152 corrects
this by using self.id instead of self.company.id
but only starting from 19.1.

The fix is essentially a back port of those 2 PR.

Problem 2: 
When you call action_close_stock_valuation from 
_cron_post_stock_valuation for the company 
that has no inventory valuation and thus no 
account move to create we will raise the user
error 
https://github.com/odoo/odoo/blob/b8e5291d103d9f43bd8db6d2dfe708076a57ea37/addons/stock_account/models/res_company.py#L58-L60
This makes sense if the method was called 
from the inventory valuation view. 
But in our case it's called from cron so we might 
also call it on other companies and therefore we 
don't want to raise an exception if there is no 
account move to create on one of the companies.

opw-6144294

Forward-Port-Of: odoo/odoo#275294

CertificateAdapter presents a client certificate stored in the database instead of on disk when opening an HTTPS connection (used by the l10n_es EDI modules verifactu, sii and tbai). It loaded that certificate on the connection path of requests 2.31, but requests >= 2.32 changed that path (no longer calls get_connection()), so the step was skipped and the call crashed with: "TypeError: expected str, bytes or os.PathLike object, not certificate"

Odoo pins requests 2.31.0 (max depending on Python version), but online databases can use the version shipped by the OS (2.32.x on recent Ubuntu 26).

Set the certificate up when the adapter is created instead of on that connection call. That step runs the same on every requests version, so the fix works both before and after 2.32.

Steps to reproduce:
  - Spanish company with Veri*Factu and a certificate, on a server
  running requests >= 2.32 (saas-19.3 database for exemple on ubuntu 26)
  - Post a customer invoice and send it to Veri*Factu.
  => TypeError

Reference: https://github.com/psf/requests/blob/f361ead047be5cb873174218582f7d8b9fcd9f49/HISTORY.md?plain=1#L146

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

Forward-Port-Of: odoo/odoo#275324

**PROBLEM**
`_cron_migrate_local_to_cloud_storage()` is used to migrate attachment to a cloud storage. It delete the attachment from the database, rendering it innacessible from the server-side. The problem is it can delete attachment used in business logic.

**STEP TO REPRODUCE**
1. Install and configure cloud_storage + a provider (e.g. cloud_storage_google) and cloud_storage_migration.
2. Install l10n_mx_edi and stamp a customer invoice. The CFDI XML is stored as an ir.attachment that:
  - is referenced by a business Many2one l10n_mx_edi.document.attachment_id (copied into account.move.l10n_mx_edi_cfdi_attachment_id),
  - has res_field = NULL (record attachment, not a field binary),
  - is posted to the chatter → it has a row in message_attachment_rel.
3. Add account.move to cloud_storage_migration_message_models and set a low enough cloud_storage_min_file_size.
4. Run the cron _cron_migrate_local_to_cloud_storage.
5. Open the invoice and trigger any recompute of the EDI chain (e.g. Update Payments, a reconciliation, or re-stamping).

**FIX**
Filters out attachment linked to a model listed by the already existing function `_get_cloud_storage_unsupported_models()`

opw-6347198

Forward-Port-Of: odoo/odoo#275945

The partner credit limit warning on quotations and customer invoices depends on which company the user is currently working in, instead of the company of the document itself.

Steps to reproduce:
- Enable Sale Credit Limit in the settings of My Company (San Francisco)
- Set a Credit Limit of 100 on a customer, e.g. Deco Addict
- Create a draft quotation of 500 for that customer => The credit limit warning banner is displayed, as expected
- Switch the active company to any other company, for example My Company (Chicago), keeping access to both companies
- Open the same quotation again => The warning banner is gone, although neither the quotation nor the
   customer changed

The credit fields used to build the warning are evaluated against the user's active company: credit_limit is a company-dependent field, and credit / credit_to_invoice are computed on the receivables of the current company. When the active company is not the document's company, the warning is checked against the wrong ledger and the wrong limit, so it can disappear on an over-limit customer or show up for a healthy one.

Both computes already contain the line that was meant to handle this, but the result of with_company() was discarded, making it a no-op. Assign it, as every other compute in these files already does, so the warning is always evaluated in the document's company.

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

Forward-Port-Of: odoo/odoo#276308

Issue:
- After confirming a sale order with a reward applied (e.g. an ewallet reward), unlocking it, and editing it so the reward line's cost changes (e.g. adding a product and re-claiming the reward), the coupon's point balance updates correctly.
- However, the corresponding loyalty.history record's used value is never refreshed, so it keeps showing the old cost instead of the new one.

Steps to reproduce:
- Enable Loyalty and Lock Confirmed Sales in Sales settings.
- Create an ewallet type loyalty.program and generate an ewallet for a partner with e.g. 1000 points.
- Create a sale order for that partner, add a product worth 100, and claim the ewallet reward (reward line created with points_cost = 100).
- Confirm the order. loyalty.history shows used = 100 (correct), card balance shows 900 (correct).
- Unlock the order, add a second product worth 100, and claim the reward again (same reward line updates to points_cost = 200).
- Lock the order again.
- Check the loyalty.card: balance is correctly 800.
- Check loyalty.history for that order: used still shows 100 instead of 200.

Fix:
- Updated _update_loyalty_history() in sale_order.py to create a new history line if none exists 
  for the given card and order combination.
- Updated write() in sale_order_line.py to correctly sync history lines when a reward line is 
  modified on a confirmed order, handling both same-coupon updates via delta and coupon 
  changes by subtracting the old coupon cost and adding the new one separately.
- Added test_loyalty_history_created_on_post_confirm_reward to verify that a history line is created 
  when a reward is claimed on a confirmed order where no history line existed before.
- Added test_loyalty_history_updated_on_points_cost_write to verify that history.used is updated by the 
  correct delta when points_cost changes on a reward line of a confirmed order.

Impact:
- Ensures a coupon's usage history stays accurate after a confirmed order is unlocked and edited.
- Prevents the loyalty.history used field from silently going stale while the actual point balance is correct.
- Not scoped to ewallet specifically — since points_cost semantics are the same across program types, this also corrects the same class of staleness for other reward types (discount, gift_card, etc.) when a reward line's cost changes post-confirmation.

When matching Purchase Order lines with Vendor Bill lines from the Bill Matching view,
if a PO and its vendor bill each contain several lines for the same product,
all bill lines of that product get matched to the first PO line only.
The remaining PO line(s) stay unmatched and are then added back
to the bill as new (duplicate) lines.

Steps:

- Create a purchase order with two lines for the same product and confirm
- Create a draft bill with the same configuration and same partner
- From the PO, click on "Bill matching" button
- Select the 4 lines and click on the "Match" button
-> On the purchase order, first line has qty_invoiced == 2 and the
   second one 0
-> On the bill, there is an additional line with 0 quantity

This is because we only match the first order line in case of having more than
one line with the same product. Then we add the remaining order lines to
the bill.
With this commit we match each line that need to be matched and we add
lines to the bill only if all order lines have been invoiced.

opw-6279755

When sending a batch of invoice, we first generate an unique PDF file regrouping every invoice.
When at least one invoice needs more than one page to be rendered entirely, the number of pages will
be greater than the number of invoices.

In this case, we use <hX> tags to split invoices:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/odoo/addons/base/models/ir_actions_report.py#L916-L923

This tag is added for PDF files, using the invoice's title:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/web/views/report_templates.xml#L627

In some localization modules, this title shouldn't be displayed and it is removed. Example for Chile:

https://github.com/odoo/odoo/blob/5ba945cdba6be3ff8838e56784ade16c6200de84/addons/l10n_cl/views/report_invoice.xml#L149

In this case, no `<h3>` tag will be added and an error is raised as we cannot separate invoices.

We propose to add an empty `<h3>` tag if the
document title is not defined.

opw-6281187

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

Translatable rows that are identified by a stable key rather than by
their text (e.g. selection option labels in ir.model.fields.selection,
and other module-reflected metadata written through upsert_en()) can
have their English source text changed by a module upgrade while
keeping the same key. For example product.template's selection value
'consu' went from meaning "Consumable" to meaning "Goods" between 17.0
and 18.0, without the stored value itself changing.

In that situation, upsert_en() always refreshes the 'en_US' entry from
the current code, so English is never wrong. But every other language
keeps whatever value it had, since upsert_en() blindly merges the new
'en_US' entry into the existing jsonb without checking whether the
previous 'en_US' value actually changed. When the module's .po file is
later reloaded, TranslationImporter.save() finds a non-empty value
already there for each language and, by design, does not overwrite it
unless explicitly asked to (`overwrite`) on a record that isn't
`noupdate`. That protection is correct when the English text hasn't
changed (it keeps manual translation customizations across upgrades),
but here it ends up protecting a translation of a source string that
no longer exists.

As a result, a value whose meaning changes across versions keeps
showing its old label in every language except English, forever,
unless someone forces a translation overwrite.

Fix this in upsert_en() itself: when the incoming 'en_US' value
differs from the one currently stored, drop every other language
already stored for that row instead of merging into it. Those
translations were made for a source string that no longer exists, so
there is nothing worth protecting. Once dropped, they are simply
missing from the jsonb, so TranslationImporter.save() naturally lets
the freshly (re)loaded translations in on its next run, without needing
to know anything about source drift, and `overwrite`/`noupdate` keep
their exact original meaning for every other case.

Task-6333080


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

Forward-Port-Of: odoo/odoo#275080

Description of the issue/feature this PR addresses:

Abandoned cart recovery emails can be sent more than once when the
`website_sale` cron runs concurrently (multiple Odoo workers, or
overlapping scheduler runs). `_send_abandoned_cart_email` only sets
`cart_recovery_email_sent` *after* `send_mail()`, so two workers can both
select the same cart while the flag is still unset.

This affects 17.0+ (verified on 17.0 and 19.0). Targeting 17.0 as the
oldest supported branch so it can be forward-ported.

Current behavior before PR:

Two overlapping cron runs both send the recovery email for the same
sale order. Customers receive duplicate abandoned-cart messages.

Desired behavior after PR is merged:

Each cart is claimed with an atomic `UPDATE ... WHERE
cart_recovery_email_sent IS NOT TRUE RETURNING id` before sending. Only
the worker that successfully claims the row sends the email; others skip
it. A regression test re-enters the cron once during `send_mail` and
asserts a single send.

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

Steps to reproduce:
-------------------------
1. Install hr_timesheet and create a second company (e.g., Company B).
2. Create a global project (no company assigned) with timesheets enabled.
3. Share the project with edit access to a portal user belonging to Company A.4
4. Create a task, switch to Company B, and log a timesheet on the task.
5. Log in as the portal user and try to access the project.

Issue:
-------
An `Access to unauthorized or invalid companies exception` is raised,
preventing the portal user from accessing a project they are legitimately shared on.

Cause:
----------
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L159-L173 During `_prepare_project_sharing_session_info`, hr_timesheet overrides the company determination logic through `_get_project_sharing_company()`. https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/hr_timesheet/controllers/project.py#L13-L18

For global projects, the company is derived from an existing timesheet if one exists. As a result, creating a timesheet in another company causes that company to be injected into the sharing session as the current company.

Since the portal user does not have access to that company, opening the project triggers an access error.

Solution:
----------
Remove the `_get_project_sharing_company()` override. The base implementation already falls back to the portal user's own company when the project has no company assigned, ensuring the sharing session only contains companies the portal user is allowed to access.
https://github.com/odoo/odoo/blob/b7b3292b6a46c3dbc17aeee0183df0af318bf810/addons/project/controllers/portal.py#L141-L142 
This allows portal users from Company A to continue accessing global projects without errors.

opw-6253960



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

Description of the issue/feature this PR addresses:

`_invoice_get_page_view_values` receives `access_token` as a named argument, then calls `_get_extra_payment_form_values(**kwargs)` without forwarding it. When `invoice_id` is also present in kwargs (query string on the portal invoice page, or an extending module injecting it for provider filtering), `_get_extra_payment_form_values` runs `_document_check_access` with `access_token=None` and raises `AccessError`.

`payment.PaymentPortal` already forwards the token via `payment_context` on `/payment/pay`; the invoice portal page did not. Verified on 17.0, 18.0, and 19.0 (18/19: same omission in `_get_common_page_view_values`). Targeting 17.0 as the oldest supported branch for forward-port.

Related CLA: https://github.com/odoo/odoo/pull/275749

Current behavior before PR:

Public portal invoice page returns AccessError/403 when `invoice_id` is present in the request kwargs without the named `access_token` being forwarded.

Desired behavior after PR is merged:

`_get_extra_payment_form_values` receives `access_token=access_token` so portal document access checks succeed.

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

Made with [Cursor](https://cursor.com)

For a logged-in user, some form fields are automatically prefilled from
their profile, such as a "Phone" field with their phone number.

**Issue:**
The prefill configuration is always preserved when we change options of
a field. While this is correct when updating few options, but it also
happens after the field is repurposed, causing it to inherit a prefill
value intended for a different field.

**Steps to reproduce:**
- Edit the /contactus page's form.
- Change the "Name" field's type to a "URL" or "CC" field.
- Save the changes.
- The "URL/CC" field is prefilled with the user's name.

A field is considered repurposed when:
- its type is changed (e.g. from "Phone" to "URL");
- a custom field is converted into an existing field.

**Fix:**
This commit preserves the prefill only when the field keeps the same
name and type. Otherwise, it clears the stale prefill so repurposed
fields no longer inherit incorrect values.

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