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

Issue:
======
Colorpicker disappears randomly when the selection is in the end column of
the table.

Steps to reptoduce the issue:
=============================
- Go to notes
- Add a table
- Fill the first cell of the last column until the end
- Select some content of the end of the text (we need the toolbar to
  have some part ouside the editable)
- Try to change the color of the text/background
- The toolbar disapears
- You may need to do this multiple times to get the issue and make sure
  to go to the toolbar by sliding the cursor over the visible right edge
  of the table first

Origin of the issue:
====================
The right edge of the table is at the end of the editable so passing by
it will trigger `_onMouseMove`  which will detect that we are hovering
on the td border of the table so it will add the class `o_col_resize` or
`o_row_resize` to the editable.

In `_updateToolbar` we check if we have one of those mentioned classes
we don't show the toolbar so we hide it. That's why when hovering on a
color in the colorpicker it will disappear.

Note: The issue isn't always reproduceable because if we go so fast or
so slow the hovering may not get detected or even get detected and then
removed.

Solution:
=========
When we leave the editable, we toggle the resizeing classes if we are
not in resizing state.

opw-3950584

Forward-Port-Of: odoo/odoo#167480

Steps to reproduce:
-------------
- Install project_sale_expenses and timesheet_grid

- Create a new product
  - Can be Expensed.
  - Re-Invoice Expenses set to Sales price
  - Set sales price and cost to 957
- Create a project(service type)
- Create a sale order with the service type product
  and confirm

- Go to the expense App
- Create a expense:
    - Choose a category (the product with Expensed).
    - Customer to Reinvoice: Select the above sale order.
- Expense posted and approved

- Go to project and open project update
- Check the margin percentage to bill.

Issue:
-------------
Sometimes, the margin percentage of the 'to bill' item becomes unexpectedly
incorrect.

Cause:
-------------
In the _get_expenses_profitability_items function of project_sale_expense,
rounding during currency conversion may lead to minor variations
(e.g., 832.17 to 832.1700000000001)for some values, not all. These differences
accumulate when subtracting untaxed amounts from amount_to_bill, resulting
in a residual value (e.g., 1.1368683772161603e-13) instead of zero, causing
unexpected margin percentages.

Solution :
----------------
  The _convert method will not round the value since we passed the round=False in the _convert method.

task-3706741

Forward-Port-Of: odoo/odoo#168156
Forward-Port-Of: odoo/odoo#153620

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

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

Currently, an error is generated when run 'Mail: Fetchmail Service' scheduled action.

Step to produce:

- Install the 'l10n_cl_edi' module.
- And manually trigger the 'Mail: Fetchmail Service' scheduled action.

Stacktrace

```
TypeError: FetchmailServer.fetch_mail() got an unexpected keyword argument 'raise_exception'
  File "odoo/tools/safe_eval.py", line 383, in safe_eval
    return unsafe_eval(c, globals_dict, locals_dict)
  File "ir.actions.server(128,)", line 1, in <module>
  File "addons/mail/models/fetchmail.py", line 186, in _fetch_mails
    return self.search([('state', '=', 'done'), ('server_type', '!=', 'local')]).fetch_mail(raise_exception=False)
ValueError: <class 'TypeError'>: "FetchmailServer.fetch_mail() got an unexpected keyword argument 'raise_exception'" while evaluating
'model._fetch_mails()'
  File "odoo/addons/base/models/ir_cron.py", line 388, in _callback
    self.env['ir.actions.server'].browse(server_action_id).run()
  File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
    res = super().run()
  File "odoo/addons/base/models/ir_actions.py", line 972, in run
    res = runner(run_self, eval_context=eval_context)
  File "odoo/addons/base/models/ir_actions.py", line 802, in _run_action_code_multi
    safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self))  # nocopy allows to return 'action'
  File "odoo/tools/safe_eval.py", line 397, in safe_eval
    raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```

The issue arises during the execution of the 'Mail: Fetchmail Service' scheduled action because the 'fetch_mail()' method call without argument, as we can see at [1], And this argument is added from this PR https://github.com/odoo/odoo/pull/152637.

link [1]: https://github.com/odoo/enterprise/blob/ba99dd4c236353c43376210a9aabcb0af5bd0299/l10n_cl_edi/models/fetchmail_server.py#L51

To resolve the issue, Add a default keyword argument at [2] to prevent an issue.

link [2]: https://github.com/odoo/enterprise/blob/ba99dd4c236353c43376210a9aabcb0af5bd0299/l10n_cl_edi/models/fetchmail_server.py#L51

sentry-5284073241

Forward-Port-Of: odoo/enterprise#61836

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

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#64240
Forward-Port-Of: odoo/enterprise#63360

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