Currently, a traceback is occurring when trying to refuse an application.

To reproduce this issue:

1) Install `hr_recruitment`
2) Open any job position
3) Create a new application record
4) Don't give any values and click on refuse button

Error:- 
```
TypeError: sequence item 0: expected str instance, bool found
```

This issue was occurring because of the refactoring from the below commit

https://github.com/odoo/odoo/pull/169955/commits/e9bad7ebc795c34052a667a227c2103aa58fb861

When the user clicks on the refuse button, `_compute_applicant_without_email` 
method triggers with the applicant as a new origin object.

Partner_name is not a required field and the applicant is a new origin object, 
So indeed we won't get any value for `display_name` or `partner_name`.

This leads to the above traceback from the below line

https://github.com/odoo/odoo/blob/1a1354727f965b018374aa2001b0bb7f981d1cc1/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L38-L42

sentry-6409185730

These commits fix two issues:
- If a block that has an image selected as background is given a
  border, its background image will fit awkwardly in the surrounding
  border, and similarly if the background image is positioned all the
  way to any edge, it does not cover all the block.
- If a video is selected as background for a block, the video does not
  always fill the block.

Steps to reproduce:

Bug 1
- Add a masonry block/big boxes block
- Add a background image to an element of the masonry/big boxes
- Add a big border
- Make the border translucent if it isn't already to better see the bug
=> The background image overflows on the border randomly
- Change the background position by shifting the image all the way to
  the left
=> The image does not cover all the border-box 

Bug 2
- Add a masonry block/big boxes block
- Add a video background
=> The video does not always fill the box, especially when the window
  gets resized

After the changes the image/video background completely covers its
block, even when resized or when a border is applied.

task-4174638

Forward-Port-Of: odoo/odoo#203571
Forward-Port-Of: odoo/odoo#201200

Steps to reproduce:
- go to a blog post with several paragraph
- edit translations

Issue 1:
- select several paragraph completely and use the translate tool
- insert the translation
=> the translation are not inserted

Issue 2:
- select 3 paragraphs but don't start at the beginning or end of
  the text
- insert translation
- see that all translations is inserted at end of paragraph 1, paragraph
  2 is emptied and paragraph 3 selected part is removed
- save
=> paragraph 1 and 2 are deleted (so we show original lang value),
   selected part of paragraph 3 is removed

Why:

In the blog post content, we are inside a "blog.post().content"
editable field, this allows the editor to select several translations
nodes which will work wrongly with the editor because translation mode
only expect to change the content of translation nodes.

The first paragraph translation is saved empty because the editor is
cloning the node with the same "data-oe-translation-source-sha"
because we are inserting several paragraphs inside it.

Fix: in translation mode, make the editable node of html fields around
translation nodes uneditable so we can't select several translation
nodes thanks to how browser handle selection and content editable.

Note: the added test step is very light, because in javascript it is
programmatically possible to select 2 separate content editable. At the
step that is added in the tour, with the fix it is not possible to
select both the H1 and P nodes.

opw-4221993
opw-4482717

pr note: opw-4221993 could possibly solved by this fix too (the video reproduction seemed to be about a bulleted list but I could not reproduce, and the original report video is deleted)

Forward-Port-Of: odoo/odoo#204188
Forward-Port-Of: odoo/odoo#197511

**Problem:**
In the purchase app, when selecting 2 Purchase Orders that have
different currencies, and clicking Action then Accrued Expense
Entry, a traceback will appear. It works as intended if the two
Purchase Orders have the same currency, but if there is more than
one currency, the traceback will be displayed.

**Steps to reproduce:**
- Go to the purchase app and select two Purchase Orders that have
different currencies (you can make a group by Currencies).
- Click on Action then Accrued Expense Entry.
- The traceback appears.

**Cause of the issue:**
https://github.com/odoo/odoo/blob/a07a8589a8cb391a801ef1ffd60e02d83fc963f8/addons/account/wizard/accrued_orders.py#L246
The currency is given as a parameter to a function that requires
only one parameter. With this code, if there are multiple
currencies in orders, all of them will be given, which
creates a traceback.

**Fix:**
After checking with a PO, the multiple currency use case is not
supported. Hence make sure that there is only one currency in the
quotations we are trying to work with. If there is more than one,
we throw an error telling the user to only pick quotations with
the same currency.

opw-4562933

Forward-Port-Of: odoo/odoo#204007
Forward-Port-Of: odoo/odoo#202733

We encountered an error when trying to open `Furniture` or `Clothes` from the 
`Dashboard` if the Administrator has been assigned Admin rights to a new user.

Step to Reproduce:
- Install the Point of Sale module without demo data.
- Navigate to `Settings` > `Users` and `create` a new user with `Admin rights` of POS.
- Log in with the newly created admin user.
- Try to load sample data for `Furniture` or `Clothes`.

Traceback:
```
while parsing /home/odoo/src/odoo/saas-18.1/addons/product/data/product_demo.xml:5, somewhere inside
<record id="base.group_user" model="res.groups">
            <field name="implied_ids" eval="[(4, ref('product.group_product_variant'))]"/>
        </record>
```

Error[2]  generated when solving above problem :

Traceback :
```
while parsing /home/odoo/odoo/community/addons/point_of_sale/data/orders_demo.xml:86, 
somewhere inside <function model="pos.session" name="update_closing_control_state_session" eval="[[ref('pos_closed_session_1')], '']"/>
```

This issue was occuring since new users does not have access right of `res.groups`.

This commit will fix the above errors by using Superuser environment to load data..

sentry-6239966848

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

Forward-Port-Of: odoo/odoo#195374

Description
-----------
The non-stored field `user_has_access` is the primary `ir.rule` used for a `knowledge.article` and is included in every query. As a result, the method `_search_user_has_access` is frequently called and quickly becomes a performance bottleneck. This is particularly noticeable when opening the Knowledge app, as it involves reading the displayed article along with loading the sidebar.

This update optimizes the method as follows:

- For generic article access, the optimization leverages the field `inherited_permission`, which already contains the propagated `internal_permission` of the article along the hierarchy. This removes the need to recompute these permissions dynamically with a complex query since the data has already been precomputed.
- For member access, the query logic has been revised while maintaining the same outcome: Previously, the process involved: `for all articles, append the member and their permission, recurse into child articles for all in-sync and permissionless articles, and propagate the member's permission. Finally, discard all articles without any set permission.`, The new approach reverses the logic to avoid the need for discarding at the end and iterating through all articles: `for the articles the member belongs to, propagate the member's permission to its child articles, provided the child is in-sync, has no explicit permission, and the partner is not already a member of that article.` Although the last condition may seem counterintuitive, the initial set of articles considered encompasses those the member is linked to already. This also avoids cases where a parent article's member permission would overwrite differing permissions on its child articles.
- Additionally, `set` manipulations are used to handle IDs, thereby preventing the injection of large ID lists into multiple domain leaves. This improves query parsing and avoids poor query execution plans that could be caused by excessively large ID lists.

Benchmark
---------
On odoo.com, opening the Knowledge app from the Apps dashboard:

| Request              | Before | After | Speed-up |
|----------------------|--------|-------|----------|
| web_read             | 1.69s  | 160ms | **10x**  |
| get_sidebar_articles | 1.64s  | 160ms | **10x**  |

In a shell, searching articles with `[('user_has_access', '=', True)]`:

| User Type             | Before | After | Speed-up |
|-----------------------|--------|-------|----------|
| `sudo`                | 251ms  | 35ms  | **7x**   |
| regular internal user | 577ms  | 58ms  | **10x**  |

Reference
---------
task-4633813

Notice
------
⚠️ Note to clients/partners that might read this: For the full benefits of the patch, deploy the indexes that were added in this PR. This can be done by Upgrading the module `knowledge`, or creating the indexes manually in database. The patch should still be a net-benefit even for database without the indexes deployed.

Forward-Port-Of: odoo/enterprise#82773
Forward-Port-Of: odoo/enterprise#80971

Currently, an exception is generated when the system tries to find the 'Out of Contract'  work_entry_type after it has been deleted.

Steps to Reproduce:

1 - Install hr_payroll module without demo data
2 - Navigate to hr payroll -> configuration -> work entry types 
3 - delete the 'Out of contract' work entry type
4 - Navigate to hr payroll -> Contracts -> Contract 
5 - Create a contract with a start date next to the current. 
6 - Navigate to hr payroll -> payslips ->  To pay
7 - Try to create Payslips To Pay for created contract 
8 - an error occurs

Error:
```ValueError
External ID not found in the system: hr_payroll.hr_work_entry_type_out_of_contract
```
This issue[1] occurs because when the system tries to reference the missing 'Out of Contract' work entry type it results in a ValueError due to a missing required record. The same issue [2] occurs in the `l10n_hk_hr_payroll` module.

[1] - 
https://github.com/odoo/enterprise/blob/265177dfd281f3aa1d61db6587ddfa37790570fe/hr_payroll/models/hr_payslip.py#L597

[2] -https://github.com/odoo/enterprise/blob/31e56779f8e0011ddc5c1a2821f68c8f041efbe4/l10n_hk_hr_payroll/models/hr_payslip.py#L180

This fix resolves the issue by ensuring that if the `Out of Contract` work entry type is missing, it returns a false value. A similar fix has been applied in `l10n_hk_hr_payroll`. Additionally, code has been added to prevent the deletion of any work entry type using @api.ondelete.

sentry-6277939517

Forward-Port-Of: odoo/enterprise#82659
Forward-Port-Of: odoo/enterprise#79053

When the fulfilment channel changes from Amazon, the user currently must delete the offer to create a new one, as they can't change the amazon_feed_ref.

(Please note that due to an API change, this field does in fact include a JSON containing the product type, fulfilment channel, and the feed reference.)

Indeed, when the listing is changed, Amazon doesn't get the information. This means we will continue to update the inventory if that offer was in FBM. Or not updating the inventory of a now FBM offer.

While that second case would only require the user to delete and recreate a new offer (which would be a bother but not that problematic), sending a quantity to a FBA offer would trigger a well known problem of ghost listing on Amazon, where Amazon will consider having both channels, and randomly set an order as either FBA or FBM, until that ghost listing quantity drop down to 0.

When catching a discrepancy, we'll thus reset the value of the amazon_feed_ref, so that it'd be pulled again later if needed by the sync inventory with, this time, the correct value. This would also stop the inventory synchronization of a potentially FBA offer.

As for any stock synchronization that might happen between the listing changes from Amazon side and the first order received in FBA, we decided against forcing the FBM quantity to 0 on all FBA offer every time, to avoid sending too many useless calls for a corner case. As the product was until now sold in FBM, in most cases, it can still be until the end of the ghost listing. If not, our support is aware of it and can force the quantity to 0 again.

opw-4681035

Forward-Port-Of: odoo/enterprise#82754