Currently, an error occurs when a user sets a non-numeric value as the journal's next check number.

**Steps to Reproduce:**
 - Install the `account_check_printing` module with demo data.
 - Go to `Invoicing` > `Configuration` > `Accounting` > `Journals`.
 - Open the `bank journal`.
 - In the `Outgoing Payments` tab > Enable `Manual Numbering`.
 - Set the `next check number` to a `non-numeric` value `(e.g. FA1234)` and `save`.

`ValueError: invalid literal for int() with base 10: 'FA1234'`

After [this commit], the next check number is converted to an integer without first validating that it 
contains only numeric characters [1]. Since the value can be non-numeric, converting it directly 
to an integer raises the error.

This commit ensures that the next check number is converted to an integer only after verifying 
that it contains numeric characters only.

[this commit]: https://github.com/odoo/odoo/commit/cc2004404462ecb523f7877569ce6a06b05341b4

[1]- https://github.com/odoo/odoo/blob/00dd75f345d7f5ddb04cecf52eca07e5a22c7d3c/addons/account_check_printing/models/account_journal.py#L57-L61

sentry-7498755988

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

Forward-Port-Of: odoo/odoo#266280

Currently, an error occurs when the user clicks on the translate button.

**Steps to Reproduce:**

 - Install the `CRM` module.
 - Go to `settings` and in `Languages` add 1 more language.
 - Go to `CRM` > `Configuration` > `Pipeline` > `Tags`.
 - Click `New` and, in the `Name` field click the `translate button` on the right.

**Behavior in 18.0**

When the tag name is not set, the translation dialog opens immediately. If a tag name is entered, 
the translation dialog shows the translated value on the second click.

**Behavior in saas-19.1**

`AssertionError: Invalid falsy real id`

Error:
After this [recent commit], when the user clicks on the translate button, if the record has a 
root record, the root record is saved before opening the translation dialog. However, in the 
case of an editable DynamicList view, the record does not have a root record so saving 
the record returns a promise instead of the resolved value [1].
Because of this promise, the condition fails [2], and the translation dialog is opened with a 
falsy ID since the record is not yet saved [3]. 
In saas-19.1, this issue raises Invalid falsy real id error after [this commit](https://github.com/odoo/odoo/commit/4290724a4c8c57fba4f4d3d688d38f65dadcc38f).

This commit ensures that await is used so the resolved value is returned after the record is 
saved before opening the translation dialog.

[recent commit]: https://github.com/odoo/odoo/commit/5245ec39a12e7d3a10fcc4c2c92b0f7dbf52d3be

[1]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L23

[2]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L24-L26

[3]: https://github.com/odoo/odoo/blob/9e3fc9568fcebcb1de6486d2ab7134e8a12087b7/addons/web/static/src/views/fields/translation_button.js#L29-L41

sentry-7384270487

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

Forward-Port-Of: odoo/odoo#267914

Steps to reproduce:
===================
1. Edit a page, add a Cover/Banner block.
2. Set its background to a video, paste an Instagram URL
3. Save and open the published page.

=> Instagram embed is broken (iframe shows nothing / error).

Cause:
=======
Background videos broke for Instagram because the BackgroundVideo interaction unconditionally appends "&enablejsapi=1" to the iframe URL on start. Instagram embed URLs have no query string (`//www.instagram.com/p/<id>/embed/`), so the append produces `//www.instagram.com/p/<id>/embed/&enablejsapi=1` the `&` ends up in the path and Instagram refuses to render.

The unconditional append is itself a regression from the public-widget → interaction refactor in [2].
The original code in 18.0 only added the param when `isYoutubeVideo && isMobileEnv`, as a workaround for old YouTube records that lacked it. Since [1], `enablejsapi=1` is already injected server-side in `html_editor/tools.py` / `web_editor/tools.py` when building YouTube autoplay embed URLs, so any YouTube background saved via the media dialog from 17.0 onward already has it. The JS append is redundant for YouTube and harmful for Instagram.

Solution:
=========
remove the unconditional append of `&enablejsapi=1` in the BackgroundVideo interaction

[1]: https://github.com/odoo/odoo/commit/ca60af9dadc25adbc9eb159870ce1233a2886492
[2]: https://github.com/odoo/odoo/commit/b9b3a605e0f4

opw-6233081

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

Forward-Port-Of: odoo/odoo#267016

Issue:
After manually modifying the taxes on a vendor bill that generates COGS lines, confirming the vendor bill causes the taxes to revert to their original values before the manual edit. This happens because the product’s purchase taxes are applied to the generated COGS lines, which triggers the tax recomputation logic and overwrites the manually adjusted tax amounts. However, COGS lines represent internal operations and should not have taxes applied to them

Steps to reproduce:
1. Turn on Anglo-Saxon accounting
2. Turn on automatic accounting
3. Make a FIFO product category and make the valuation automatic
4. Make a new product and set the FIFO product category on it
5. Make sure the product has a vendor tax set
6. Make a purchase order for 10 of the FIFO product category at $10
7. Create and validate the receipt for 10
8. Make a sales order for 6 of the FIFO product category at $10
9. Create and validate the delivery for 6
10. Create the vendor bill for 10 the purchase order created above (make sure that there is a tax set on the vendor bill; the vendor tax that was set on the product). Make this vendor bill set for 10 at $20
11. Edit the tax at the bottom of the total
12. Confirm the vendor bill
13. Notice that the tax at the bottom of the total changes
14. Reset the vendor bill
15. Remove the purchase tax from the product
16. Confirm the vendor bill again and notice that the tax at the bottom of the total does not change this time

Cause:
On confirmation, the COGS lines on the vendor bill will be generated and “_compute_tax_ids” will be triggered on those lines. Since COGS lines have a “product_id” set on them, those lines will receive the purchase tax set on the product. Setting the “tax_ids” on those COGS lines will cause tax computation to trigger again, which will reset the manually edited tax amount to the new computed amount. However, since COGS lines come in pairs that are equal and opposite in amount, the taxes from both COGS lines will cancel out, and the new computed tax amount does not change

Solution:
Skip setting the purchase taxes of the product onto COGS lines in “_compute_tax_ids”

opw-6110692

Forward-Port-Of: odoo/odoo#268269
Forward-Port-Of: odoo/odoo#265352

The [commit] introduced the method for inverting the interval inside the given limits.
The method was failing for the following edge cases:
```python
>>> invert_intervals([(1, 2), (4, 5)], 0, 10)
result - [(2, 4), (5, 10)]
expected - [(0, 1), (2, 4), (5, 10)]?
>>> invert_intervals([(-2, -1)], 0, 10)
result - [(0, 10)]
expected - same
>>> invert_intervals([(11, 12)], 0, 10)
result - []
expected - [(0, 10)]
>>> invert_intervals([(-1, 1), (2, 5), (8, 12)], 0, 10)
result - [(1, 2), (5, 8)]
expected - same
>>> invert_intervals([(2, 5), (8, 12)], 0, 10)
result - [(5, 8)]
expected - [(0, 2), (5, 8)]
>>> invert_intervals([(2, 5), (11, 12)], 0, 10)
result - []
expected - [(0, 2), (5, 10)]
```

This commit fixes the function to correctly handle all the cases. The test cases are also added to test all the edge cases.

[commit]: https://github.com/odoo/enterprise/commit/53450065be0c3ec9d648d4fd39ec3a9a912bd06c

Forward-Port-Of: odoo/odoo#268161
Forward-Port-Of: odoo/odoo#267917

## Steps to reproduce:
- Install the `quality_mrp` module.
- Create a new product.
- Create a Quality Point with: 
  Type: Measure,
  Control per: Product/Operation
  Operations: Manufacturing
- Create and confirm MO for the product.
- Update the Quality Point: 
  Remove the 'manufacturing' operation type and add 'receipts' type. 
  Change Control per to 'Quantity'.
- Open the MO and start a quality check.
- Enter an invalid measure and try to validate it.

## Error:
`AttributeError - 'mrp.production' object has no attribute 'lot_producing_id'`

## Cause:
Since commit https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e, the `lot_producing_id` field on MO was replaced by the Many2many field `lot_producing_ids`. Invalid references to the removed field lead to an error.

## Fix:
This commit uses the first lot/serial from the MO.
Note: Multiple produced lots are only possible for serial-tracked products.

sentry-7511513479

Forward-Port-Of: odoo/enterprise#119231

**Steps to reproduce:**

- Setup a Verifactu installation and a Spanish company
- Go to the PoS, make a Sale
- Keep the ticket
- Go to the /pos/ticket URL and enter the ticket informations
- Last step also works when requesting an invoice in the backend on the order
- Go to the order in the backend, an error is shown, the cancellation didn't go through
**Veri*Factu documents can only be generated for paid or posted Point of Sale Orders.**

**Why the fix:**

When we directly invoice an order, we do not go through the verification of being paid and done. This is why is works, but when making the invoice after the sale is done, we cancel the order first, then we register the invoice instead. When trying to cancel the order, we check if the order is either paid or done, but it is currently invoiced as we just generated the invoice.

We now allow no errors if the order is in the invoiced state, and let it pass through.
With this flow we get the same result as the direct invoice from the PoS.

The new cancellation on the order  and submission on the invoice may take a bit of time to get accepted but they will be eventually.

opw-6139200

Forward-Port-Of: odoo/odoo#267869
Forward-Port-Of: odoo/odoo#264272

[FIX] product_barcodelookup: avoid crash on invalid image URLs
**Steps to Reproduce:**
-  Install Sales module.
- Configure a valid Barcode Lookup API key.
- Create a product without an image.
- Set a barcode whose returned image URL is broken or returns HTTP 404
  (e.g. `8426904171073`).
- Select the product and trigger the server action:
  `Action -> Get Pictures from Barcode Lookup`

Issue:

**During image fetching:**

-  Barcode Lookup API successfully returns product data and image URLs.
- `_get_image_from_url()` attempts to download the image.
- The image URL responds with HTTP 404.
- `barcode_lookup_request()` returns a dict for non-200 responses.
-  `_get_image_from_url()` assumes the response is always a `requests.Response`
   object and directly accesses:  `response.status_code`
- This causes: `AttributeError: 'dict' object has no attribute 'status_code'`

**Root Cause:**
- `barcode_lookup_request()` returns inconsistent response types:
     - `requests.Response` for successful requests
     - `dict` for failed requests
- _get_image_from_url() does not handle the dict response before accessing
   response attributes.

**Solution:**
- Make barcode_lookup_request() always return a One Response
  object.
- Move the response validation to the callers instead of returning custom
  dict objects.

**Result:**
- No RPC crash when image URLs are invalid or return 404.
- Broken image URLs are safely ignored.

**OPW-6200749**

Forward-Port-Of: odoo/enterprise#116925

**Steps to reproduce:**
- Install eLearning app with gamification
- Go to Settings > Gamification Tools > Challenges
- Set a challenge with multiple participants (portals / internals)
- Set its state to Done
- Notification email is sent to every participants
- They can see each other in the mail header
(portal user can see all other portal users, internal user can see all portal users)

**Issue:**
Since [1] external recipients are added in the mail header, but this is not adequate for every flows
(here there is no need for the participants to be aware of each other).

**Fix:**
In [2] this issue was mitigated by removing the `'X-Msg-To-Add'` from the header for models which don't need it.
Then in [3] the solution was replaced by a more generic approach using `_CUSTOMER_HEADERS_LIMIT_COUNT = 0`.

[1] https://github.com/odoo/odoo/commit/42aaaef59d21558438c767c6dd8a21674e5df9df
[2] https://github.com/odoo/odoo/commit/e6c13ce4436b3c8b3a2058d2ccf65a7da1b256b2
[3] https://github.com/odoo/odoo/commit/c4dbd868b9c7e26f11db4d2cacef7ffce6c87082

opw-6099745

Forward-Port-Of: odoo/odoo#267192

When creating a credit note, it is possible for the compute method _compute_partner_bank_id to be called in a context where active_test is falsy, leading to moves that cannot be validated because it would raise with the following error message:
> The recipient bank account linked to this invoice is archived.
So you cannot confirm the invoice.

The state of the 'active_test' ctx key cannot be known in advance in a compute and should not be assumed as True; according to the framework team:
> In practice, a compute method cannot expect active_test to have
> a particular value. It may be invoked with any context. There is no
> "context purge" done by the ORM. The computation may be "prepared"
> with a context (the one of modified()) and actually done with another
> context (code accessing the field before some explicit flush). In
> other words, if the compute method searches for a record that matches
> some conditions, and if that record cannot be inactive, then this
> condition must be explicit in the search domain (or in the context).

opw-6229286

Forward-Port-Of: odoo/odoo#267398

# How to reproduce
- Install the Accounting module
- In the settings, enable "Sales Credit Limit"
- Remove the Accounting access rights of the current user
- Try to create a new user

# The issue
An access error is raised on the field `credit_limit`

# Cause
Enabling the "Sales Credit Limit" setting will create an `ir.default` for the `credit_limit` field. This field is restricted to a specific group : https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/account/models/partner.py#L515-L518

When creating a record, we check field permissions before adding default values, so the creation of the user is fine. However, since `res.users`  inherits from `res.partners`, a new partner will also be created, but this time with the default values in `vals_list`, which will trigger an access right error.

# Proposed solution
Back port of this commit : https://github.com/odoo/odoo/pull/267193

Access right checks when creating a record were introduced in 18.3 by : https://github.com/odoo/odoo/commit/15132342960df76fcefd3284a9eff2d4d3273150

opw-6240494

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

Forward-Port-Of: odoo/odoo#268303
Forward-Port-Of: odoo/odoo#268039