if their is nothing to read in attachment file related spreadsheet. So, it will bring empty byte [``b''``](https://github.com/odoo/odoo/blob/9bba9f8246a0a046a631fb849846109131e74750/odoo/addons/base/models/ir_attachment.py#L234) that is here and when it go for [decode](https://github.com/odoo/enterprise/blob/c072e9e104a4ed24d345062f66a44d84aaeb074b/spreadsheet_edition/models/spreadsheet_mixin.py#L233) it will raise this traceback
```
Traceback (most recent call last):
   File "/tmp/tmp3fwx3zdj/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
    self.mock_action(action_vals)
   File "/tmp/tmp3fwx3zdj/migrations/base/tests/test_mock_crawl.py", line 429, in mock_action
    mock_method(model, view, fields_list, domain, group_by)
   File "/tmp/tmp3fwx3zdj/migrations/base/tests/test_mock_crawl.py", line 532, in mock_view_kanban
    self.mock_web_search_read(model, view, [domain], fields_list)
   File "/tmp/tmp3fwx3zdj/migrations/base/tests/test_mock_crawl.py", line 591, in mock_web_search_read
    data = model.search_read(domain=domain, fields=fields_list, limit=80)
   File "/home/odoo/src/odoo/saas-17.4/odoo/models.py", line 5847, in search_read
    return records._read_format(fnames=fields, **read_kwargs)
   File "/home/odoo/src/odoo/saas-17.4/odoo/models.py", line 3902, in _read_format
    vals[name] = convert(record[name], record, use_display_name)
   File "/home/odoo/src/odoo/saas-17.4/odoo/models.py", line 6727, in __getitem__
    return self._fields[key].__get__(self)
   File "/home/odoo/src/odoo/saas-17.4/odoo/fields.py", line 1263, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/saas-17.4/odoo/fields.py", line 1445, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/saas-17.4/addons/mail/models/mail_thread.py", line 428, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/saas-17.4/odoo/models.py", line 5037, in _compute_field_value
    fields.determine(field.compute, self)
   File "/home/odoo/src/odoo/saas-17.4/odoo/fields.py", line 101, in determine
    return needle(*args)
   File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 44, in _compute_current_revision_uuid
    snapshot = spreadsheet._get_spreadsheet_snapshot()
   File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 233, in _get_spreadsheet_snapshot
    return json.loads(base64.decodebytes(snapshot))
   File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
    return _default_decoder.decode(s)
   File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
   File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
 json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```

for preventing this added a condition to return false because their is no meaning at all decoding this data
This taceback is raising during upgrade why field data is empty byte ``b''`` due to that above tracbeack is raised
why as this field introduced in kanban [view](https://github.com/odoo/enterprise/commit/a055dfeb84abc34015b269422264534d97a83d8f)  on computing it blocking the upgrade process during read call

When importing a sale in PoS and doing a downpayment there was only one downpayment line created. And because of this the taxes where not always correct. If you do a 100% downpayment you would end up with negative untaxed amount on the invoice.

Steps to reproduce:
-------------------
* Create 2 taxes, A and B with 5% and 10%
* Create 2 products, A and B. Assign the 2 taxes to the products
* Create a sale order with the 2 products
* Open the sale order in PoS and make a downpayment for it
> Observation: There is only one downpayment line when it should have 2.

Why the fix:
------------
If you do the same flow in the sales app, you get 2 downpayment lines. We do this to allign the behavior in sales and PoS. For each unique tax combination we compute what part of the total downpayment should be assigned to it. Then we make sure that the taxes are assigned to the line and that the line has the right value.

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

Forward-Port-Of: odoo/odoo#175236
Forward-Port-Of: odoo/odoo#174076

### Steps to reproduce:
	- Install eCommerce module
	- Go to Website > Cart
	- Click on Edit > Customize > Extra Info
	- Go to Website settings and Check 'Extra Step During Checkout'

### Current behavior before PR:
The 'Extra Step During checkout' setting is not synchronized when turning on and off from website editor or from website settings. This actually leads sometimes that you might turn it on from website settings and it won't be visible in the checkout process. This is happening because in the 'res.config.settings' we are dealing with 'ir.ui.view' that is not linked to any website but in the website editor we are dealing with 'ir.ui.view' that is linked to the website you are editing.
https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/res_config_settings.py#L68 https://github.com/odoo/odoo/blob/17.0/addons/website_sale/models/website.py#L588

### Desired behavior after PR is merged:
When turning on/off the setting from the website settings now we are dealing with the 'ir.ui.view' that is linked to a website. So the setting is now website dependant.

opw-3992571

Forward-Port-Of: odoo/odoo#176392
Forward-Port-Of: odoo/odoo#170639

In order to be more accessible, commit [1] allowed the hoverable menus to have an outline when they are focused by using the Tab key. When hovering these menus with the mouse, the outline should not appear, unless it was already focused (with the Tab key). Also, when hovering, the focus should stay on the already focused element.

This last part causes some issues: indeed, the focus is kept by calling the `focus` function and the issue with it is that it scrolls to the element on which it is called. This made the screen scroll unexpectedly anytime we hovered a hoverable menu, to bring the focused element into view.

This commit fixes this issue by specifying that the screen should not scroll when focusing the element.

Steps to reproduce:
- In the menu editor, add some submenus.
- In edit mode, click on the header and set the "Sub Menus" option to "On Hover" and the "Scroll Effect" option to "Scroll".
- Go to the "/shop" page.
- In edit mode, add the cart button on the products and then save.
- Scroll down the page and add a product to the cart.
- Scroll up the page and hover the menu with a submenu. => The page scrolls down to the product we just added, since it was the focused element.

[1]: https://github.com/odoo/odoo/commit/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4

opw-4069610

Forward-Port-Of: odoo/odoo#175710

Description of the issue/feature this PR addresses:

- Commit [1] changed `getDeepestPosition` to let it change the selection to its
next block. This commit partially reverts commit [1] and ensures that it only
changes blocks when the node is invisible.

- Commit [2] changed the behavior of Ctrl+A when the first child of an editor was
contenteditable false element, causing it to not select the first element. This
behavior is incorrect, as Ctrl+A should always select all contents. This commit
partially reverts commit [2] and provides an alternative solution to the
original issue.

- Inserting a horizontal rule was only possible on paragraph related
elements. This PR makes sure horizontal rule can be inserted directly to
block elements such as div.

task-3850023

[1]: https://github.com/odoo/odoo/commit/ddc8587f8a712fdddaa714bee2931cb149c03a38
[2]: https://github.com/odoo/odoo/commit/530f102720458e5e1c224bf38073cd763309bf0a

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

Forward-Port-Of: odoo/odoo#173849
Forward-Port-Of: odoo/odoo#164345

When the public users access the `/knowledge/home` route, the system will open the first accessible, visible and published article using a domain involving different search compute methods.

In the `_search_is_article_visible` search method, the system will fetch the members associated to the current user. However, the public users do not have access to that model. As a result, the public user will get an access error and the server will display the 403 error page.

Steps to reproduce the error:
1. Install `website_helpdesk_knowledge` module.
2. On the Odoo homepage, click on the helpdesk icon.
3. On the helpdesk overview, click on the vertical dots of the "Customer Care" team card.
4. On the dropdown menu, click on the "Settings" option.
5. On the "Help Center" section, click on the "Knowledge" option.
6. On the "Visibility & Assignment" section, click on "Invited portal users and all internal users" option.
7. Save the changes.
8. Open a new browser in incognito and go on your website.
9. Click on the "Customer Care" navbar link of your website.
10. Click on the "Browse articles" button
11. You should get a 403 error page

=> TO BE: You shouldn't get a 403 error page.

Since the public users cannot be added to the article members list, we will skip the members fetching for those users and return an empty domain. The condition will then be ignored and the search method will not raise any exception.
 
task-3980714

Forward-Port-Of: odoo/enterprise#64377

Issue
-----
[Approvals, Purchase, Stock]
1. In approvals, set the current user as the approver for the "Create RFQ's" approval type.
2. Approvals > New Request > Create RFQ's > Select a product with a vendor setup ("Acoustic bloc screen" for example) > Submit > Approve > Create RFQ >
Click smart button to navigate to the PO > Confirm the PO (should work)
4. Repeat step 2, ValidationError when trying to confirm the PO.

Note: the issue only arises in this specific flow, the PO can still be confirmed by for example just refreshing the page.

Issue
-----
A 'default_name' key is added to the context when creating a request for a category which uses sequential names (which is the case for RFQ's approvals). https://github.com/odoo/enterprise/blob/65a8e25f1ff2d0faf17ad73c1402615d320ffc48/approvals/models/approval_category.py#L154

As a result, it gets propagated all the way to the creation of the picking when the PO is confirmed.
https://github.com/odoo/odoo/blob/beb8c7d86ae6062dbad9fcb17bc3141d14a9fcdc/addons/stock/models/stock_picking.py#L721 As pickings require a unique (name, company_id), a first picking can be created with the name 'New', but later ones will fail.

Fix
-----
Avoid propagating the default_name key when opening the purchase orders so the picking created when confirming the order will have the correct name.

opw-3990816

Forward-Port-Of: odoo/enterprise#66504

To reproduce the issue, on a fresh db with nothing else:

1) Create a new accounting report from srcatch, so that:
    - it has 2 columns
    - it has 1 line, with two expressions:
        - the expression going in column 1 is a domain, doing [('debit', '>', 0)]
        - the expression going in column 2 is also  a domain, doing [('balance', '>', 0)]
    - it has analytics groupby enabled

2) Create a vendor bill, with only 1 line of 100€. Assign it an analytic distribution of 100% into some analytic account.

3) Open your report, activate the analytic groupby on the analytic account used in point 2).

====> The column considering the balance shows 100€, while the one considering the debit shows 0. This is wrong; both columns should show 100€.

This is due to the fact the sign of the debit is inverted in the SQL shadowing of the move lines made to handle analytics in the report engine. Instead of 100, it sees -100 here, which does not match the domain.

Forward-Port-Of: odoo/enterprise#67018