Since the rule refactor, additional byproducts are not considered in the post production picking. The problem is when we add a new byproduct, the backend do not add the warehouse_id on the stock move, and without a warehouse id, it was impossible to find a stock rule for it. Now, with the correct warehouse and stock rule, the stock move is added on the transfers.

Testing steps:
---------------------
- go to configuration > settings > enable Multi-step routes 
- go to configuration > warehouses and enable either 2 or 3 step manufacture
- go to configuration > enable byproducts
- create a BOM with some components/byproducts
- create a MO with the BOM above, confirm it.
Now, we can see the 'transfers' button with 2 transfers, one by the components and another one for the final products and the byproducts.
- add a new byproduct with some produced quantity.

Problem:
-------------
No picking for the new byproduct when clicking on the transfer button

Expected behaviour:
------------------------------
The byproduct should be in the list

task: 3982566

Forward-Port-Of: odoo/odoo#177730
Forward-Port-Of: odoo/odoo#170280

If you created an event using GNOME Evolution/Calendar, it could add an `X-EVOLUTION-ENDDATE` parameter to the event's `RRULE`.

When that happens, if the event is pushed to a Google Calendar and synced in Odoo, all participants' calendars stop syncing from there onwards.

<details>

```
2024-06-26 07:10:57,942 41 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(15,)] Calendar Synchro - Exception : unsupported property: X-EVOLUTION-ENDDATE=20371102T114500Z !
Traceback (most recent call last):
  File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 100, in _sync_all_google_calendar
    user.with_user(user).sudo()._sync_google_calendar(google)
  File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 78, in _sync_google_calendar
    synced_recurrences = self.env['calendar.recurrence'].with_context(write_dates=recurrences_write_dates)._sync_google2odoo(recurrences)
  File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 185, in _sync_google2odoo
    odoo_record.with_context(dont_notify=True)._write_from_google(gevent, vals)
  File "/opt/odoo/auto/addons/google_calendar/models/calendar_recurrence_rule.py", line 88, in _write_from_google
    super()._write_from_google(gevent, vals)
  File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 304, in _write_from_google
    self.write(vals)
  File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 71, in write
    result = super().write(vals)
  File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3808, in write
    fields[0].determine_inverse(real_recs)
  File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1401, in determine_inverse
    determine(self.inverse, records)
  File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 98, in determine
    return needle(*args)
  File "/opt/odoo/auto/addons/calendar/models/calendar_recurrence.py", line 219, in _inverse_rrule
    values = self._rrule_parse(recurrence.rrule, recurrence.dtstart)
  File "/opt/odoo/auto/addons/calendar/models/calendar_recurrence.py", line 366, in _rrule_parse
    rule = rrule.rrulestr(rule_str, dtstart=date_start)
  File "/usr/local/lib/python3.10/site-packages/dateutil/rrule.py", line 1730, in __call__
    return self._parse_rfc(s, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/dateutil/rrule.py", line 1698, in _parse_rfc
    raise ValueError("unsupported property: "+name)
ValueError: unsupported property: X-EVOLUTION-ENDDATE=20371102T114500Z
```

</details>

In https://discourse.gnome.org/t/working-with-evolution-mail-and-web-calendar-using-rrule-fail-because-of-x-evolution-enddate-in-rrule/19710/3 it explains why this happens and how it's actually a supported feature of RFC 5545.

Dateutil doesn't support that feature. It just fails with `ValueError`. Progress is being tracked in https://github.com/dateutil/dateutil/pull/1374.

Regarding what matters to Odoo, we can just strip any X-named params from the RRULE prefix and live happy with the rest (or fail if there's really a wrongly-formatted RRULE param). This way we avoid dateutil to fail unnecessarily and unlock users Google calendars synchronizations.

@moduon MT-6287



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

Forward-Port-Of: odoo/odoo#171784

### Steps to reproduce the issue:

1. Make sure you have access to the Analytic Distribution fields
2. Create an expense
3. Open the Split Expense Wizard and add Analytic Distribution to the new Expenses
    - Click out of the Analytic Distribution widget to close it, don't use the close icon
4. Finish the splitting process
5. On the Tree view that follows, the Analytic Distribution fields are empty

### Explanation:

`onWindowClick` checks if the `analytic_distirbution` widget should close. If the conditions are met, `forceCloseEditor` is called and the data is saved.
In this case, one of the `selectors` is retrieved by `ev.target.closest`, namely `.modal:not(.o_inactive_modal)`, therefore not meeting the conditions to call `forceCloseEditor`, but the widget still closes.

### Fix reasoning:

We want `forceCloseEditor` to be called in this situation, since the user is not clicking on an element related to `analytic_distribution`. We can use  `o_act_window` to filter Search More modals from Wizards, as it is absent from the former.

opw-4001757

Forward-Port-Of: odoo/odoo#178136
Forward-Port-Of: odoo/odoo#177161

Steps to reproduce:

- Go to a website blog post page > Drop a "Table of Content" snippet
inside the blog post content.

- Switch to translation mode > Try to translate a TOC title > The 
corresponding navigation label won't be automatically updated.

- Save > The translation will be applied depending on whether the title
and the navbar item have exactly the same content or not [*].

Starting from [1], the translation of a "Table of Content" navigation
label was automatically applied (only the text content) when the
corresponding title was translated, and the user was also warned when
trying to edit them directly in "translation" mode.

This implementation relied on the field observers mechanism to
synchronize translations for the table of content navigation and content
headers.

Unfortunately, the field mutations handler doesn't take translation
fields into consideration when they are part of another field's DOM:

1. Before trying to set the updated field value on its duplicates in the
DOM, the handler is using `_pauseOdooFieldObservers()` to `disconnect()`
all the observers of other fields to prevent receiving mutations from
its own updates.

2. In translation mode, and when the updated field has some inner
translation `<span/>`s, their observers will be disconnected too, and
their mutations will never be linked to the right target.

3. Finally, the `_observeOdooFieldChanges()` is used to observe the
fields again.

Let's take the following example: 
```
<div data-oe-model="...">
    <span data-oe-translation-initial-sha="...">Text Content</span>
</div>
```

In this case, two observers are created, one for the `[data-oe-model]`
(`O1`) and the other for the `[data-oe-translation-initial-sha]` (`O2`).

When editing the "Text Content" of the `<span/>`, `O1` will be triggered
(for the parent field) and will temporarily disconnect all other fields

observers (including (`O2`)) and as a consequence, `O2` won't be able to
synchronize the value of the translation field on the ones with the same
`data-oe-translation-initial-sha` (which is the same situation as in a
"Table of Content" block).

The goal of this commit is to simply prevent disconnecting inner
translation field observers to allow the translation synchronization
inside a parent field DOM.

[*]: Remark: when a TOC title and its navigation item have different DOM
(e.g., the font color of the title changed), the code from [1] will
always temporarily set the same `data-oe-translation-initial-sha` on
both of them (and restore the original ones before saving), which
explains the different translation values when the field observers are
not working correctly.

[1]: https://github.com/odoo/odoo/commit/5776a358e1b42186d2c26c9bc25010a12811f416

opw-3990039
opw-3888871

Forward-Port-Of: odoo/odoo#178439
Forward-Port-Of: odoo/odoo#176198

### Issue:
The bank accounts of a company are not accessible from the branches of this company.

### Steps to reproduce:
- In Settings, create a company and a branch company
- In the contact app, add a bank account for the company
- Switch to the branch company
- In the Accounting app, create a Customer invoice
- In the "Other Info", change the Company to the branch
- The bank account created does not show up in the selection of the field "Recipient Bank"

### Cause:
The current domain is `domain="[('partner_id', '=', bank_partner_id)]"` which is only taking the res.partner.bank record linked with the partner of the company (bank_partner_id).

### Solution:
The solution must work on companies not partners and use the 'parent_of' keyword so that the branches can access the records. Changing the domain to `[('partner_id.ref_company_ids', 'parent_of', company_id)]` works.

### Note:
- The field `ref_company_ids` is an old field that is almost not used anymore, but it is the only link between res.partner.bank and the company it is linked to.
- This domain used `partner_id.ref_company_ids` in an old version of Odoo, but it was changed in this commit: https://github.com/odoo/odoo/commit/1db371721f3549276ee622e8b4369db7ce13863c because of a bug. I did not manage to reproduce the bug in v17 with this fix.

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

Forward-Port-Of: odoo/odoo#173287