[FIX] website_blog: prevent "List" layout from overflowing on mobile

Steps to reproduce:
- Go to the "/blog" page.
- In edit mode, set the "Layout" option to "List" and save.
- Toggle the mobile preview or reduce the screen size at around 580px or
  below.
=> There is a horizontal scrollbar.

The scrollbar appears because the row containing the blog posts has a
bigger width than its container, which makes it overflow from it. It
happens because of the `o_container_small` class set on the container,
which has a rule forcing its horizontal padding to 0, where it was
supposed to compensate the row margins.

This commit therefore fixes this issue by forcing the row horizontal
margins to 0 for screen sizes under the `MD` screen breakpoint, which is
approximately where the blogs layout becomes mobile.

This fix also has the advantage of improving the "List" mobile layout by
making it look similar to the "Grid" layout one, that is, with a bit of
space around the posts, instead of being glued to the viewport.

opw-4052853

---
[FIX] web_editor: prevent grid item inner row child from overflowing

Steps to reproduce:
- In edit mode, drop the "Team" snippet.
- Toggle it to grid mode.
- Set the "Content Width" option to "Full".
=> A horizontal scrollbar appears.

This happens because the `.row` elements generally have a `--gutter-x`
CSS variable set to 30px that is used to compute their horizontal
margins, such that it compensates the padding of the parent (generally a
`.container` element) which is set to the same value. So the parent is
supposed to always have a padding of 15px, which is compensated by the
row margins, set to -15px.

When a row is a direct child of a grid item, the row can overflow its
parent if the grid item has a padding below 15px. Indeed, the row
expects its parent to have a 15px padding, so its margins are too big if
the value is below. A horizontal scrollbar can therefore appear, if the
snippet container takes the whole screen width.

This commit fixes this issue by making the margins of row elements that
are direct children of a grid item compensate the padding of this grid
item, while it is below 15px. When it is set to 15px or above, they are
back compensating the usual 15px.

opw-4052853
opw-3981579

Forward-Port-Of: odoo/odoo#176975
Forward-Port-Of: odoo/odoo#176421

**Issue:**
When several invoices are selected and sent via "Send & print"
action, it happens that some invoices are sent several times.
It seems to be caused by a serialization failure on an invoice
in "_compute_debit_credit" when a concurrent write operation is
executed on an invoice being sent.
This serialization failure cause a retry on the batch being sent,
resulting on the invoice to be re-sent.

**Cause:**
"Send & print" action triggers "_compute_debit_credit" method that
writes on debit and credit fields.
The values are generally the same, so no write is really performed.
However, for some values (e.g. 14.79), there is a floating point
issue (i.e. 14.790000000000001) and the "get_records_different_from"
method considers the record as different and triggeres an actual
write.

**Solution:**
In "get_records_different_from" method, for monetary fields, apply
the same rounding to the current value than the one applied when the
value is converted to cache.

opw-3773287




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

Forward-Port-Of: odoo/odoo#176218

Before this commit, accessing start and stop values directly from new event values could lead to a KeyError if these keys were missing. This commit adds a safeguard to prevent such errors by checking for the existence of these keys before attempting to access them, ensuring a more robust handling of event data.

Here is traceback:
```
  File "/home/odoo/src/odoo/addons/google_calendar/controllers/main.py", line 46, in google_calendar_sync_data
    need_refresh = request.env.user.sudo()._sync_google_calendar(GoogleCal)
  File "/home/odoo/src/odoo/addons/google_calendar/models/res_users.py", line 73, in _sync_google_calendar
    synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
  File "/home/odoo/src/odoo/addons/google_calendar/models/google_sync.py", line 197, in _sync_google2odoo
    odoo_record.with_context(context)._write_from_google(gevent, vals)
  File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in _write_from_google
    if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
  File "/home/odoo/src/odoo/addons/google_calendar/models/calendar_recurrence_rule.py", line 122, in <genexpr>
    if old_event_values and any(new_event_values[key] != old_event_values[key] for key in base_event_time_fields):
KeyError: 'start'
```

opw-4100958

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

Forward-Port-Of: odoo/odoo#176634

**Current behavior:**
If a production spawns some backorder which has available
component quants in a package, the backorder will not have that
quantity reserved automatically.

**Expected behavior:**
This available quantity should be reserved by rule (based on the
manufacturing picking type's reservation configuration)
automatically.

**Steps to reproduce:**
1. Enable packages and 2-step manufacturing, use the default
    `at_confirm` option for the manufacturing method's
    `reservation_method`

2. Create an MO for 10 of some storable product that has 10 of
     some storable product as a component -> confirm the MO

3. In the generated pick operation for the MO, assign the 10
     units of the storable product to the move's quantity

4. In barcode, open the picking and manually add 1 of the
     components -> put it in a pack

5. Repeat step 3 an additional time

6. Validate the picking -> create the backorder

7. Open the initial manufacturing order in barcode

8. Consume one of the created packaged quants of the component,
     ensuring to also add the +1 quantity to the final product
     barcode line

9. Validate the MO -> create the backorder

10. In the backend, open the backorder to see that there is 0
     quantity reserved

**Cause of the issue:**
In this scenario, the backorder's raw move does not gain any
availability until after the original order is marked done,
after which there is never any logic for the reservation to
occur.

**Fix:**
During the backorder generation and the mark done for the
original order, attempt to assign any backorder productions at
the instant when some component quantity becomes available.

opw-3989977

Forward-Port-Of: odoo/odoo#172955

Steps to reproduce :

- Add a second language in your website settings.
- Drop a "Text" block in a new page.
- Add a highlight to some text > Save.
- Switch to the translation mode.
- Select the highlighted text > The text highlight options are shown.
- Select a text without any option > The highlight options remain
displayed.

Starting from [1], we allow using text options (text animations & text
highlights) in the translation mode, mainly by allowing the creation of
snippet editors if the target is a text option snippet.

Another fix (from [2]) was added later to exceptionally authorize the
editor's creation for "invisible" elements in translate mode, with a
small adaptation on `_activateSnippet()` to prevent activating invisible
snippets when their related sidebar buttons are clicked.

This code unintentionally leads to keeping the old editors created for a
text snippet when switching to another one in the DOM.

To fix this behaviour, we still need to ensure existing editors are
destroyed so we only create the ones we need in translate mode.

[1]: https://github.com/odoo/odoo/commit/3a149e36f7e6deaf156a7ee35e654aad61cf2e5d
[2]: https://github.com/odoo/odoo/commit/67efd1d98072f36caf9c473e97984631eb6bc8a3

task-3975683

Forward-Port-Of: odoo/odoo#168642

**Current behavior:**
In a scenario where dropshipping and subcontracting are being used to fulfill an order, if the dropship is split via backorder then the valuation layers which get created for each subsequent backorder will have a cumulative value instead of reflecting the value for the sequence portion for which they were generated.

**Expected behavior:**
The SVL records should have a value which accurately reflects the moves involved in the portion of the valuation sequence that they are being created with respect to.

**Steps to reproduce:**
1. Create a component_product such that: - is storable - category has automated valuation and avg cost method - has the `dropship subcontractor on order` route - has some vendor

2. Create a final_product such that: - is storable - category has automated valuation and avg cost method - invoice policy is on quantity delivered - has a subcontract bom that consumes some quantity of component_product - has a subcontractor vendor

3. Create a sale order for >1 of the final_product, set the route on order line to dropship, confirm the SO and the PO which is generated

4. In the dropship transfer, set the quantity to half the demand and validate -> generate the backorder

5. On the SO, create an invoice for the completed quantity and confirm it

6. Complete the rest of the order in the backordered dropship transfer and create and confirm another invoice on the SO

7. Go to the SVL tree view and observe that the latest SVL is ~2x (before the compensatory SVL difference is applied)

**Cause of the issue:**
When the SVL is created, its value is calculated by taking the difference of subcontract SVL(s) values and dropship SVL(s) values. The subcontract SVLs come from the `move_orig_ids` of the current SVL's move.

When the sequence is broken up by backorders, these moves are still used in the calculation for the value of future SVLs. This results in the inaccuracy.

**Fix:**
Only use SVLs from the move in the current move's
`move_orig_ids` which has the maximum `backorder_sequence`.

opw-4078510

Forward-Port-Of: odoo/odoo#176958
Forward-Port-Of: odoo/odoo#176163

**Current behavior:**
If a production spawns some backorder which has available
component quants in a package, the backorder will not have that
quantity reserved automatically.

**Expected behavior:**
This available quantity should be reserved by rule (based on the
manufacturing picking type's reservation configuration)
automatically.

**Steps to reproduce:**
1. Enable packages and 2-step manufacturing, use the default
    `at_confirm` option for the manufacturing method's
    `reservation_method`

2. Create an MO for 10 of some storable product that has 10 of
     some storable product as a component -> confirm the MO

3. In the generated pick operation for the MO, assign the 10
     units of the storable product to the move's quantity

4. In barcode, open the picking and manually add 1 of the
     components -> put it in a pack

5. Repeat step 3 an additional time

6. Validate the picking -> create the backorder

7. Open the initial manufacturing order in barcode

8. Consume one of the created packaged quants of the component,
     ensuring to also add the +1 quantity to the final product
     barcode line

9. Validate the MO -> create the backorder

10. In the backend, open the backorder to see that there is 0
     quantity reserved

**Cause of the issue:**
In this scenario, the backorder's raw move does not gain any
availability until after the original order is marked done,
after which there is never any logic for the reservation to
occur.

**Fix:**
During the backorder generation and the mark done for the
original order, attempt to assign any backorder productions at
the instant when some component quantity becomes available.

opw-3989977

Forward-Port-Of: odoo/enterprise#66496