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

Found error during migration in customer database. when company is archived but will get that company on `self.env.company` of pos_config table,
this error is generated when it's try to create the record for pos config from pos_resturant module
by data file (defined on this commit)

https://github.com/odoo/odoo/commit/3236c1cb5025d2c2d446d11f67fda1ea51ceb992

as picking_type_id field in pos_config is required and we set default value by fetching warehouse for related company but here as company is archived, related warehouse is also archived and that why we didnot get picking_type_id for archived company and that will raise Error :

```
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4787, in _create
    cr.execute(SQL(
  File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.NotNullViolation: null value in column "picking_type_id" of relation "pos_config" violates not-null constraint
```

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

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

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

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

If the model `account.move.line` has custom field with name `source_line_id` or `source_move_id` or `source_line_account_type` then, when the computed field `payment_state` in model `account.move` is computed it causes `psycopg2.errors.AmbiguousColumn` during `GROUP BY` operation here[^1]. Because **account_move_line** is one of the joined tables in that query and it causes issue while grouping. Actually the issue can occur if any of the joined tables in that[^2] query has custom field with the names above, it will cause same issue.

To resolve this issue, I added a table alias
to the all 3 elements in GROUP BY clause.

Steps to reproduce:
1. Install module account in any version >= `saas~15.3`
2. Add custom field to the model `account.move.line` with name `source_move_id`.
3. Try to create invoice

You will face issue similar to this:

```
  File "/home/odoo/src/odoo/saas-15.3/addons/account/models/account_move.py", line 1430, in _compute_amount
    self._cr.execute(' UNION ALL '.join(queries), [stored_ids, stored_ids])
  File "/home/odoo/src/odoo/saas-15.3/odoo/sql_db.py", line 356, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "source_move_id" is ambiguous
LINE 20:                     GROUP BY source_line_id, source_move_id,...
```
I targeted this PR to `16.0` because branch `saas-15.3` is disbaled

[^1]: https://github.com/odoo/odoo/blob/8346b2a7561c178fd7e9f9d1fbd7dac3e3843fd1/addons/account/models/account_move.py#L912

[^2]: https://github.com/odoo/odoo/blob/8346b2a7561c178fd7e9f9d1fbd7dac3e3843fd1/addons/account/models/account_move.py#L896-L912

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

### Steps to reproduce:

- Enable Multi-Step routes in the settings
- Go Inventory >  Configuration > Warehouse Management > Warehouses
- Enable 2-step manufacturing on your Warehouse
- Create 2 storable products: - product P: tracked by SN - product COMP: tracked by lot
- Update the "on hand qty" of COMP by creating a lot with 10 units
- Create and confirm a manufacturing order for 1 unit of P
- Change the qty producing to 1 then assign a serial number to the final product
- Validate the transfer of components from stock to preproduction (The lot is automatically used on this transfer as it is available)

### Expected behavior:

Since the lot of COMP was used in the transfer from stock to preproduction it should be displayed on the raw move of the MO.

### Current behavior:

The raw move is not updated.

Note: if the transfer is validated before we set the qty producing the lot of the component is correctly updated.

### Cause of the issue:

When the `qty_producing` is changed, the '_set_qty_producing' is called in order to adapt the quantities of the MO (produce only one unit and consume accordingly):
https://github.com/odoo/odoo/blob/b26129c1ed6eb4806569e05d90c17dd9aa2e4c02/addons/mrp/models/mrp_production.py#L809-L811 https://github.com/odoo/odoo/blob/37c67ba6d2bef0bdca715619f117c3124ef5d334/addons/mrp/models/mrp_production.py#L1215-L1231 Now, changing the quantity of the stock move of the component to a positive quantity will trigger the inverse method '_set_quantity' of that field to adapt reservation by creating a stock.move.line. Therefore, validating the transfer of components from stock to pre-production will not update the lot of components on the raw move because the computed need will be at 0 here:
https://github.com/odoo/odoo/blob/3097ea49705a1b6319be9677152d65ebe3ce515b/addons/stock/models/stock_move.py#L1689-L1697 and the '_update_reserved_quantity' call will therefore be empty.

follow up of commit d7148a7

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

Forward-Port-Of: odoo/odoo#177894

Current behaviour:
---
When you create a campaign, if you add more activity (56) than the default pager limit (40)
The next pager page will be empty (instead of showing the remaining 16 activities)

Steps to reproduce:
---
1. Go to Marketing Automation
2. Create a campaign
3. Create more than 40 activities
4. Alternate parents/child when creating
5. The pager will appear, with at least 2 pages
6. Go to the second page
7. Nothing displayed 
NB: When inputting the number of activities in the pager, everything is rendered fine.

Cause of the issue:
---
To be displayed, the activities are hierarchised, by finding child and parents (`_getSortedRecordsByHierarchy`)
However this system works great when all the records are given. 
Using a pager, some records are not used in the hierarchy, causing the outputted list to be incomplete.
(ie if an activity A is in the first 40 and the child in the last 16, it will not be rendered correctly)

Fix:
---
Disabling the pager by setting a higher limit

opw-4006610

Forward-Port-Of: odoo/enterprise#69154
Forward-Port-Of: odoo/enterprise#67979

The case:
- I want to organise all my shop in order to be able to serve all the rental orders I planed for a week. And resupply the shop with different interwarehouse transfers

The issue, rental orders create a retun picking directly and their forecast could easily reach zero. (even more on small renting period)

An existing solution:
Correctly set a small lead time on reordering rule in order to have a fix day in order to have the forecast. However it only works if people check the replenishment report everyday and don't have weekend. And if they use automatic RR they lose the control over the warehouse that should resupply the product.

Also they can't use the visibility days feature and plan for a week.

In order to allow a better planning and flexibility we add a small parameter to ignore the returns of rental order. That way the forecast ignore returns and allow visibilty.

BUT it's DANGEROUS. Because it means that outgoing after return won't be correctly forecasted. So the user have to use a small lead time. E.g. Global lead days = 70 days, do a rental order in 10 days (for a day) and another in 20 days. With the parameter enable, it will suggest 2 units. However it should be one since one is returned.

Forward-Port-Of: odoo/enterprise#69015