Steps to reproduce:
===================
1. Add a Text Cover block to a page.
2. Optionally remove the text column so only the image remains.
3. Open the image column options and set "Visible on Mobile".
4. Switch to mobile view.

=> Image column is empty.

Root cause:
============
The image grid item is empty (background-image only) and relies on the parent `.o_grid_mode` being `display: grid` to be sized via `grid-area`. That `display: grid` rule is gated at `media-breakpoint-up(lg)` https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/web_editor/static/src/scss/web_editor.frontend.scss#L66 so below `lg` the item is a normal `display: block` element with no `col-*` class active (it has `g-col-lg-6 col-lg-6`, both `lg`-only) and no `g-height-*` CSS effect outside grid mode. The element therefore collapses to 0 height and the background image paints nothing.

This regressed when the mobile-hidden breakpoint was extended from `md` to `lg`:

- (See [1]) changed `d-none d-md-block` to `d-none d-lg-block o_snippet_mobile_invisible`. Before that, hiding only applied below `md`, where the image was rarely shown; afterwards the user can ask for it on mobile but gets an empty box.

Fix:
====
Give the empty `oe_img_bg` grid item a `min-height` below `lg` so it has something to paint when the user makes it mobile-visible.

[1]: https://github.com/odoo/odoo/commit/079575b8ba645e7ec564967698d76a94d18022c1
opw-6228392


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

Steps to reproduce:
-------------------
- Install `l10n_din5008`
- Configure the document layout as DIN 5008
- Create and validate a delivery order
- Print the delivery slip

Issue:
------
The delivery slip still displays the information block (Order, Shipping Date, Total Weight, etc.), 
although the DIN 5008 layout is expected to hide it.

 Cause:
---------

The DIN 5008 layout made to hides the delivery slip `information` block: https://github.com/odoo/odoo/blob/674c748458e6e29715ad3763f267802d921dce55/addons/l10n_din5008/static/src/scss/report_din5008.scss#L73

Unfortunately, this behavior was broken in this [commit](https://github.com/odoo/odoo/commit/28c1cc6025005cd0937afbc452a722235cc5a38d):

The main purpose of this commit was to fix the alignment of the delivery slip. 
As part of the fix, it added `class="report-wrapping-flexbox"`:

https://github.com/odoo/odoo/blob/674c748458e6e29715ad3763f267802d921dce55/addons/stock/report/report_deliveryslip.xml#L49

This prevents the information block from being hidden because of the CSS `!important` property:

https://github.com/odoo/odoo/blob/674c748458e6e29715ad3763f267802d921dce55/addons/web/static/src/webclient/actions/reports/bootstrap_review_report.scss#L59-L62

So when switching to the DIN 5008 format, it tries to hide the information block,
but the `!important` property prevents it from being hidden.

 Solution:
------------
Backport this [commit](https://github.com/odoo/odoo/commit/8d588f8198d9057311304e596c009a0795ca6ec7):

In this commit, instead of targeting the `#information_block` itself, 
it targets its children and hides all of them except `plan`.

As a result, all other children of the information block become hidden. 
Since there is no `!important` rule on the children, they can be hidden successfully. 
The information block then becomes empty and nothing is displayed.

<details>
  <summary>Click here to see the results:</summary>

  <p><strong>Before:</strong></p>
  <div class="image-row">
    <img  src="https://github.com/user-attachments/assets/7529dec3-977b-4bee-8c0c-5ce8c09a09e9" />
  </div>

  <p><strong>After:</strong></p>
  <div class="image-row">
    <img src="https://github.com/user-attachments/assets/96ed3f8f-c874-4059-a19f-5ea3b380aba3" />
  </div>
</details>

Why this fix:
--------------

These two different behaviors up to saas-18.4 and 19.0 led to a misunderstanding.

---

opw-6250072

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

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

Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required.

## Steps to produce:
- Install the Inventory module
- Go to Settings and enable Storage Locations.
- Inventory > Configuration > Operation Types > Internal Transfers > Barcode App
- Configure the Destination Location to require scanning after each product.
- Create an Internal Transfer for Pedal Bin, demand 1.
- Mark the transfer as To Do and open it in the Barcode app.
- Add quantity using +1, then scan the barcode for the Pedal Bin(Barcode: 6016478556493).
- Delete the newly added line and attempt to Validate.

## Observed Behavior:
The system should prevent transfer validation when the destination location has not been scanned and display a notification to the user, similar to the behavior before user deleted the newly added line.

## Root cause:
This issue occurs because when the delete button is pressed, the deleteLine function [1] removes the line, but the deleted line becomes the selected line due to [2] being triggered before the UI updates.

As a result, the selected line is now undefined. Since the selected line is undefined, it fails to meet the condition at [3] during validation. This prevents notifications from being triggered and allows the transfer to be validated before the destination location has been scanned.
[1]:
https://github.com/odoo/enterprise/blob/3476d15bf8e75eb6530658dd623861b60963ab40/stock_barcode/static/src/models/barcode_model.js#L826-L836 [2] :
https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/stock_barcode/static/src/components/line.js#L129-L133 [3]:
https://github.com/odoo/enterprise/blob/6ff158ca3a6d2d2b3d285a7f8317622844811688/stock_barcode/static/src/models/barcode_picking_model.js#L945-L948

## Solution:
We can prevent users from validating if any line has an unscanned destination location when destination-location scanning is mandatory after scanning each product.

To enforce this behavior, we can track whether a line has been modified and whether a destination location has been scanned and applied to that line. This allows us to identify which lines still require destination location scanning before validation can proceed.

However, line state information is currently discarded and recreated on every save. As a result, information about lines that were updated and already had their destination location scanned is lost. This may incorrectly require users to rescan the destination location, even though it was previously scanned.

To address this, we preserve the destination-scanned and modified state by carrying it forward from existing lines to their corresponding newly created versions using a loop. This ensures that destination location scan status is retained and users are not asked to rescan unnecessarily.

opw-6069614

Steps to reproduce:
-------------------
1. Install Time Off
2. Create an employee with a 38-hour working schedule (7.6h/day)
3. Create a time off type with request unit set to "Hours"
4. Create an allocation for this employee with a duration of 8 hours
5. Observe the allocation title displaying a long decimal value. (e.g., 7.999999999999999)

Issue:
------
The `number_of_days` is calculated in `_compute_number_of_days` using: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L261-L262

For an 8-hour request on a 7.6h/day schedule, this results in ~1.052631579 days.
In `_get_title`, this value is multiplied back to show hours: https://github.com/odoo/odoo/blob/ca01e606928a7704c6b2e4f430710f895be2653d/addons/hr_holidays/models/hr_leave_allocation.py#L151

This multiplication leads to the long decimal values being displayed in the title.

Solution:
---------
Round the computed duration to two decimal places using `float_round`.

**NOTE:**
This issue is already fixed in saas-19.1 (commit 01d86a7).

However, **no change** is required in the multi-allocation wizard, as the duration
there directly uses user input and is not computed from working hours.

opw-6091424





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

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