Currently, when a user has 2 pos preparation displays, one set on some categories the other on all, if you add on the order a product that is not in the categories of the first display, the order will show no changes.

Steps to reproduce:
-------------------
* Go to the **Kitchen display** App
* Have two displays created
  * Display 1: `Product Categories`: Food
  * Display 2: `Product Categories`: All (Leave blank)
* Go to the **Point of Sale** App
* Open restaurant session
* Select a table and add a drink to the order
> Observations: The order button is not highlighted.

Why the fix:
------------
Before the refactoring, the categories loaded for each display would use the function `_get_pos_category_ids()`. This function would return a list of all possible categories (ex: `[1, 2, 3, 4, 5]`) when the setting was set on all categories.

After the refactoring, the categories loaded correspond to the setting of the display. Thus, in the case of a display on all categories it would return `[]`.

At the end, we would end up concatenating stuff like `([5], [])` instead of `([5], [1, 2, 3, 4, 5])`. Only displays with categories set would be taken into account.

opw-3923383

Forward-Port-Of: odoo/enterprise#63315

Purpose
-------

Let's say a user works a lot on a spreadsheet and performs a lot of heavy operations generating very large revisions (with lots of commands), such as copy-pasting a very large zone (there's one UPDATE_CELL command per copy-pas cell)

If the user does multiple such very large revision, one after the other, every thing is fine client side.

The next time the spreadsheet is open though: the server needs to load all those revisions to send them to the client. The revisions can be so large it can blow up the server memory limit.
The spreadsheet cannot be open anymore.

Solution
--------

In this commit, we increase the number of snapshot by snapshotting more often.

Previously, we used to snapshot when opening a spreadsheet and no activity was done in the spreadsheet in the last 12 hours. It's reduced to 2 hours in this commit.
The reason we don't want to snapshot too often is that it kills the local history (CTRL+Z) of connected users.

Task: 3940465

Forward-Port-Of: odoo/enterprise#63741

With this commit whenever utm.source name is written it will check its uniquness (generating a unique name if necessary).

[Reproduce]
- Install marketing_automation
- Have Campaign with a Template: - Access the Campaign's Template and go to the Settings tab. - Note down the NAME of the `utm.source` (found in the Advanced section, under the field "Name"). - Delete this template (which will also delete associated `mailing.mailing` records.)
- Create new template (by returning to the Campaign form, opening an activity, creating template)
- Open the Campaign's Template: - Disable read-only on the Name field in Advanced section (modify the `mailing.mailing.form` view). - Change its name to the previously noted `utm.source` NAME. - Save -> BUG: Trackback "The name must be unique"

[Why this bug happens?]
When you delete a template (`mailing.mailing`) related to a `utm.source`, the `utm.source` will still exist. Then, when attempting to change the `utm.source` name, the system is supposed to detect if the name already exists and generate a new unique name if necessary. However, due to the mechanism utilized in the function (ref.1), which searches for existing names based on existing templates (`mailing.mailing`), which you have deleted, the existing `utm.source` NAME won't be found. Consequently, the function mistakenly believes the name is unique and doesn't generate a new name, leading to the encountered error.

(ref.1) `UtmMixin._get_unique_names`
https://github.com/odoo/odoo/blob/205caa3d6539187009a8b8bbd1557e75fe045ff3/addons/utm/models/utm_mixin.py#L77

opw-3835704

Forward-Port-Of: odoo/enterprise#64071
Forward-Port-Of: odoo/enterprise#63360

Current behavior:
---
When logged as a mass mailing user, in a mailing, using the editor, 
when applying a shape to an image, the image disappears.

Steps to reproduce:
---
1. Make sure Marc Demo has the role User
2. Log in as Marc Demo
3. Create a new mailing
4. Select a template
5. Insert a picture
6. Select the picture
7. Change its shape to round
8. (preview works fine)
9. Save the mailing
10. Picture disappears

Cause of the issue:
---
When applying a shape to an image, the resulting file is of mimetype 'image/svg+xml', 
when sending it to the server, the attachment is going to go through _check_contents https://github.com/odoo/odoo/blob/d752abb24d9b25bb6d10e411961447c8c8e28bba/odoo/addons/base/models/ir_attachment.py#L364 and if the mimetype is "xml_like", it will check for views write rights, 
without what the mimetype will be forced to text/plain. 

But in web_editor, when computing the image src
https://github.com/odoo/odoo/blob/b6392e2c7dbc8e1ece326e28a9698801142714b7/addons/web_editor/models/ir_attachment.py#L34 if the mimetype is not a supported image type, src will be False.

Fix:
---
Override of _writeShape to use canvas to convert the image from svg to png.

opw-3672798

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

Forward-Port-Of: odoo/odoo#164703
Forward-Port-Of: odoo/odoo#159497

**Current behavior:**
Depending on the created picking type and product costing
method, unlocking a validated picking and changing the quantity
field of a move will not update the qty_received field of the
respective purchase order line.

**Expected behavior:**
These values will be synchronized.

**Steps to reproduce:**
1. Make a purchase order with a following combination:
    A) `picking_type = receipt`
       `product cost_method != standard`

    B) `picking_type = dropship`
       (product cost_method is arbitrary)

2. Confirm the order, validate the picking

3. Unlock the picking and change the quantity value of the stock
     move

4. Observe that the purchase order's qty_received value does not
     change

**Cause of the issue:**
In the case of the receipt picking type, when creating a stock
valuation layer for the related move with a 'standard' product
costing method we do not call `_get_price_unit()`. This method
will compute the qty_received value of a purchase order line.
After we unlock the picking and change the move quantity, this
field will not be recomputed (because it is stored). Thus, it is
not updated.

The dropship case is similar, except in the creation of a
dropship SVL, `_get_price_unit()` is called before checking the
product's cost method- so the bug always occurs.

**Fix:**
Make the purchase order line's qty_received field depend on it's
stock moves' quantities.

Reorder the conditional in the dropship SVL creation so it
matches that of the incoming SVL creation- this is for
improving consistency rather than a necessary modification for
the fix.

opw-3863510

Forward-Port-Of: odoo/odoo#166366

Small fix on commit 71ab15e4 to remove the `required` attribute on `currency_field` in the form view, which makes it impossible to save the form if the field is not set and editing something unrelated on a monetary field, for ex. the field label or the translations.

The checks in the constraint `_check_currency_field()` added in the same commit should be enough to ensure the `currency_field` is set as needed.

Impacted branches:

`17.0` and `master`

Steps to reproduce:

 1. Go to the Technical menu -> Fields and select a monetary type field
 2. Try to update the Field Label or any field translation

Current behavior:

The editing is blocked by the required 'Currency field'.

Expected behavior:

Allow editing the form view or the related translations.

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

Since Babel issue 621 [0] searching the week number of a date alongside with the year can lead to a wrong year in the result. e.g.: `2023-01-01` gives `W1 2022`

Before the present commit, the tests were surprisingly expecting the wrong result.

An attempt was made [1] to fix the upstream issue but was never merged.

In the meanwhile, Debian reverted the Babel issue 621 [2] in their package.

It means that our test would fail with the patched Debian package like in Ubuntu Noble or Debian Bookworm. On the other hand, if we fix the test to expect the correct value, it would fail on unpatched version of the Babel lib.

So, this commit mitigate the issue by guessing the expected value even if the result is wrong.

[0]: https://github.com/python-babel/babel/pull/621
[1]: https://github.com/python-babel/babel/pull/887
[2]: https://sources.debian.org/patches/python-babel/2.10.3-1/



For reference (from @Xavier-Do )

Pip version and Jammy
```python
In [1]import babel.dates

In [2]: import datetime

In [3]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "fr_BE")
Out[3]: 'dim. 52 2022'

In [4]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "en_US")
Out[4]: 'Sun 1 2022'
```

It looks like the week year used is actually not localized, adding a cornercase on Sunday

Noble version

```python
In [1]import babel.dates

In [2]: import datetime

In [3]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "fr_BE")
Out[3]: 'dim. 52 2022'

In [4]: babel.dates.format_date(datetime.datetime(2023, 1, 1), "EEE w YYYY", "en_US")
Out[4]: 'Sun 1 2023'
```

Forward-Port-Of: odoo/odoo#168132

Currently, when buying products with variants the attribute values are not reflected on the backend order.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** app
* Open a shop session
* Make an order for the product `Desk Organizer`
* Select any option from the product configuration popup
* Pay and Validate the order
* Go in the backend
* Navigate to **Orders**
* Select the last order
> Observation: Selected options for the product are not reflected

Why the fix:
------------
The function `set_full_product_name()` was changed with https://github.com/odoo/odoo/commit/672c853ab7d77ac1cebd2f4d16bd98fc454b2d55

It basically changed the behavior to set the `full_product_name` to `display_name` where it was previously computed with the attribute values.

The fix is based on the fix made for the `pos_retaurant` module. https://github.com/odoo/odoo/commit/3b6455eb979078354e3b1009a354ca7010e5fec9

This will re-introduce a feature removed from the first commit mentioned which is to show the attribute values in full name of the product. This has already been re-introduced in later versions

https://github.com/odoo/odoo/blob/8e00b5337a2ee30e667b0b2e6ff26b7df9fef2e3/addons/point_of_sale/static/src/app/store/models.js#L315-L320

This is in sass-17.2

opw-3950366

Forward-Port-Of: odoo/odoo#168697
Forward-Port-Of: odoo/odoo#168121

### Issue:
When in firm mode, it is possible to change manually the name of an invoice, so it is possible to change its sequence number when the invoice is in draft. If the invoice sequence is more than 1, it is impossible to change the journal afterward. The client need to reset the name to nothing, change the journal and then rechange the name if he wants to change the journal.

The same thing happens with Vendor Bills when the firm setting is activated.

### Steps to reproduce:
- In Settings > Accounting > 'Accounting Firms Mode' select "Customer Invoices and Vendor Bills"
- In Accounting > Customers > Invoices create a new Invoice
- Choose a name, for example 'INV234' and a journal
- Save the record
- Change the journal
- When saving a popup indicates it is impossible to change the journal when a sequence number is assigned

### Cause:
When not in firm mode the invoice can't be filled (displays as Draft) and will be generated from the previous invoice name (In fact the user can only modify the name of the first invoice created in the journal, not the next ones). With the firm mode activated, the user can always modify the name of the draft invoice, giving it a sequence number. Then when changing the journal, it is blocked because the user is not supposed to change the journal of an invoice with a sequence number greater than 1. The check: https://github.com/odoo/odoo/blame/16.0/addons/account/models/account_move.py#L2303

### Solution:
Modify the condition of the UserError so that it is not triggered when the 'Firm Mode' is active.

opw-3925402

Forward-Port-Of: odoo/odoo#168319

Prior to this PR, colors of "Today" were inconsistent depending on the view in calendar, sometimes red, sometimes purple. There was also a contrast issue when switching to dark mode.

This PR adjusts the color of "Today" to maintain color consistency and to provide contrast in bright mode and dark mode.

task-3754159
Part of task-3575827

| Before | After |
|--------|--------|
| ![image](https://github.com/odoo/odoo/assets/80679690/62476368-c3cd-4652-a8a4-19afc09631a1) | ![Capture d’écran 2024-02-21 à 11 40 56](https://github.com/odoo/odoo/assets/80679690/62b8cd53-4f4e-4f41-9b93-803b83e49d7d) |
| ![image](https://github.com/odoo/odoo/assets/80679690/274fb188-5779-4259-9681-ae7eb402b842) | ![Capture d’écran 2024-02-21 à 11 41 46](https://github.com/odoo/odoo/assets/80679690/35148fb7-1eea-49f1-b5b0-7aff46593a99) |
| ![Capture d’écran 2024-02-21 à 11 42 51](https://github.com/odoo/odoo/assets/80679690/536f6b4e-bff2-4ecb-963d-72c9acc78a59) |  ![Capture d’écran 2024-02-21 à 11 43 24](https://github.com/odoo/odoo/assets/80679690/3d2c3b20-b49b-4cb0-98e6-4c655778bd3d) |
| ![Capture d’écran 2024-02-22 à 08 39 12](https://github.com/odoo/odoo/assets/80679690/f91f0375-4768-4929-a89a-60152ead96a6) | ![Capture d’écran 2024-02-22 à 08 38 17](https://github.com/odoo/odoo/assets/80679690/daf670c1-86b6-4e2a-bfb6-dfceb4de6de5) |


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

Forward-Port-Of: odoo/odoo#154856

Steps to reproduce:
- Install eCommerce and `l10n_be` (to get a second company)
- Enable online payment in the settings
- Go to the payment provider and duplicate it for belgium company
- Publish the payment provider
- Make an invoice for a customer
- Send or generate the link
- Open the link in incognito
- Pay the invoice

Issues:
When we create the `temp_move` we don't provide the `company_id` as such we will go in the compute which will fail.

https://github.com/odoo/odoo/blob/f1d6ad2645fcc206b43454400e2c70d1d23a4ee3/addons/account/models/account_journal.py#L363

https://github.com/odoo/odoo/blob/17d85347f92d813704d3f8faef366166bbbaa730/addons/account/models/account_move.py#L693

In this line we call the `_accessible_branches` method on the belgium company as expected, in this method we use `self.env.companies` (default company) and we do an intersection with the current company (belgium).
This results in an empty recordset for the company.

Later in the stock we face this instruction which ends up in an empty recordset error as we have an ensure one at the beggining of `_get_violated_lock_dates`.

https://github.com/odoo/odoo/blob/f1d6ad2645fcc206b43454400e2c70d1d23a4ee3/addons/account/models/account_move.py#L4394

https://github.com/odoo/odoo/blob/f1d6ad2645fcc206b43454400e2c70d1d23a4ee3/addons/account/models/company.py#L370

Website solve it by copying the `public_user` and affecting it to the desired company.

https://github.com/odoo/odoo/blob/9079b7038754ca4fe547086d3fe8947a4bb6ddce/addons/website/models/res_company.py#L43-L57

A potential approach to solve this problem could be to allow `public_user` to access all of the companies (possibly problematic w.r.t. security).

The solution chosen for this PR is a local solution as it makes more sense for stable.

opw-3859791

Forward-Port-Of: odoo/odoo#162058