Issue:
======
The label of link doesn't auto save.

Steps to reproduce the issue:
=============================
- Go to email marketing
- Add text block
- Select some text and convert it to link
- Change the label of link from the link tools
- Click on the top , outside the editable
- The label sets back to it's original value

Origin of the issue:
====================
`onSelectionChange` is called from the flow of `obeserverApply` which
calls `deselectTable` here [1] and it deactivate the observer which
clears `this.observerTimout` so `historyStep` don't get caled.

Solution:
=========
- We don't unactivate the observer when there are no `td` elements to
  process.


[1]: https://github.com/odoo/odoo/blob/saas-16.3/addons/web_editor/static/src/js/editor/odoo-editor/src/OdooEditor.js#3931

---

Issue:
======
Traceback after discard mass mailing with selection

Steps to reproduce the issue:
=============================
- Create a new mass mailing
- Choose the welcome template
- Click outside the editable
- Select the first paragraph in the template such that the toolbar
  appears
- discard the record
- traceback

Origin of the issue:
=====================
The flow goes as follows, create a new mass mailing, click outside the
editable will trigger commitChanges, now we click again inside the
editable, `activeSnippet` is called which will add some item to the
list of snippetEditors in `SnippetsMenu`.

Now clicking on discard will goes as follows, `onWillUnmount` will be
called and we find the record dirty because the commited changes have
already been cleared from `record.data` so we have 2 flows going in
parallel , one for the commitChanges and one for the destroy which
will be called in this order while running, commitChanges -> destroy
-> observerUnactive -> observerFlush -> observerApply -> contentChanged
-> updateCurrentSnippetEditorOverlay -> cover ->
`ownerDocument.defaultView` but the docuemnt doesn't have a window
anymore so its value is null thus the traceback.

Solutions:
==========
We add check on the default view to make sure it's not null before
accessing it.


task-3857016

Forward-Port-Of: odoo/odoo#166233
Forward-Port-Of: odoo/odoo#161845

Description of the issue/feature this PR addresses:
  Improve versatility of `_get_cart_qty` method for 'product.product' model. As of now, this method automatically returns zero, for all products that allow ordering when out-of-stock. This bit of logic is only necessary in one place (to generate combination info to display in `website_sale_stock.product_availability` view), making the method effectively useless in other places, like community modules. This commit simplifies the `_get_cart_qty` method logic, to make it more usable, and delegates the removed check only to the `_get_additionnal_combination_info` override. This also allows the method to be used in `_get_cart_and_free_qty`, to avoid needing to override cart quantity acquisition logic in multiple places.

Current behavior before PR:
  The `_get_cart_qty` method, automatically returns zero, for all products, that allow ordering out-of-stock, preventing acquisition of cart quantity using this method, for these products. 

Desired behavior after PR is merged:
  Being able to get the current cart quantity for all products, using this method.

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

Forward-Port-Of: odoo/odoo#164785

When the user tries to delete the toppings,
a traceback appears.

Steps to reproduce the error:
- Go to Lunch > Configuration > Vendors > Open any vendor
- Now add extra 2 (topping 2) > Save
- Delete that extra 2 (topping 2) > Save

Traceback:
```
IndexError: list index out of range
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1827, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1847, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1825, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1832, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2057, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 739, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 71, in web_save
    self.write(vals)
  File "addons/lunch/models/lunch_supplier.py", line 193, in write
    topping_values = topping[2]
```

https://github.com/odoo/odoo/blob/07f6d71e4dd3fac7b4cacc545819430aa48823cd/addons/lunch/models/lunch_supplier.py#L192-L193 Here when the user deletes the extra 2 (topping 2),
"topping" will be [2,2] instead of [2,2,False].
So when it tries to access topping[2],
It will lead to the above traceback.

sentry-5203693767

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

Forward-Port-Of: odoo/odoo#162207

**Impacted versions:**
 
 - 17.0
 - 16.0

**Description of the issue/feature this PR addresses:**

The addition of `request._post_init()` in #104573, introduced the possibility that `_request_stack.pop()` is not called after `_request_stack.push(...)` was called before. This would happen in the case if request._post_init() raised an Exception.

Even though with the standard `SessionStore` this is extremely unlikely to happen the possibility remains. In any case, one shouldn't set the expectation that `request._post_init()` isn't allowed to raise, therefore by moving the function call into the try block, it makes sure that `_request_stack.pop()` is called in the finally block.

**Current behavior before PR:**

If `request._post_init()` raises an Exception, `_request_stack` is left in a polluted state. This can cause issues during RPC-Calls, since during an RPC-Call, the request in `_request_stack` is borrowed with the expectation that `_request_stack` is empty.

This can cause issues further down the line for completely separate requests which may break here:
https://github.com/odoo/odoo/blob/4b6dea23a04d7b5317a94e75c8a670de82762276/odoo/addons/base/models/ir_qweb.py#L879

It breaks because, `request` will not be `None` (as would be expected due to borrowing) but `session` is not set on the `Request` object since that only happens if `_post_init()` succeeds. This results in the following error for completely unrelated requests going forward:

```
AttributeError: 'Request' object has no attribute 'session'
```

As a side-note, in our environment this happened likely due to using [camptocamp/odoo-cloud-platform/session_redis](https://github.com/camptocamp/odoo-cloud-platform/tree/16.0/session_redis). I did a write-up of the specific issue I ran into myself and reproduction steps here: https://gist.github.com/Jenjen1324/81d3547e5713ba253b67970bc8388147

I'm also not sure if there might be any security implications leaving a *partially* constructed object in this stack.

**Desired behavior after PR is merged:**

It is no longer possible to have a broken request hanging on in `_request_stack`, be it in stock Odoo or with customizations.


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

Forward-Port-Of: odoo/odoo#166524

Versions
--------
- 17.0+

Steps
-----
1. Ensure debug mode is off;
2. go to Employees / Configuration / Employee / Working Schedules;
3. select a schedule and switch it to a 2 week calendar;
4. try to reorder one of the rows.

Issue
-----
Row resets to original place.

Cause
-----
Commit a9b804b1ad6c added a `default_order` to the view, its values get passed to the `_sort` function of `StaticList`, which then compares them to the `activeFields` of the loaded model.

One of the fields given to `default_order` is `week_type`, which isn't included in the `activeFields` of the loaded model unless you're in developer mode. This is a consequence of being assigned to the group `base.group_no_one`.

Because of this mismatch, it assumes the model isn't loaded yet, and creates a new one with the `week_type` field in order to sort them, leaving the original records (the ones in view) unchanged.

Solution
--------
Remove the `groups` attribute from `week_type`, and make it an optional field.

Also switch `editable` from `top` to `bottom` to make the line appear right above the `Add a line` line.

opw-3773432

Forward-Port-Of: odoo/odoo#165113

Currently the analytic distribution is applied to the journal items of the invoice but not to the ones of the cash basis entries.

This leads to the following problem.
The journal items of the invoice (may) contain transfer / transitional accounts.
For each payment a crash basis entry is created (on the date of the payment). The cash basis entries "move" the amounts from the transfer accounts to the "real" accounts.
Thus currently the analytics are only applied to the transfer accounts and not to the "real" accounts.

After this commit:
Consider the creation of a new cash basis entry for an invoice. The analytic distribution from the journal items of the invoice will now also be applied to the lines of the new cash basis move.

A test was replaced.
The old test checked that the base lines are duplicated for different analytic distributions.
The newer test is more detailled and also covers the old test.

task-3340797

Forward-Port-Of: odoo/odoo#166540
Forward-Port-Of: odoo/odoo#155696

This test was not working on Debian Bookworm and Ubuntu Noble. This is probably because they use `werkzeug 3.0.1`, which seems to be ordering the routing map differently.

Results in the test with current requirements.txt:
```
[
  {'loc': '/forum/testforum-18'},
  {'loc': '/forum/testforum-18/renameit-37', 'lastmod': FakeDate(2023, 5, 31)}
]
```

Results in the test with werkzeug 3.0.1 and some tweaks to be close to Noble:
```
[
  {'loc': '/forum/testforum-17/renameit-35', 'lastmod': FakeDate(2023, 5, 31)},
  {'loc': '/forum/testforum-17'}
]

```

You see that the forum post route is added in a different order. The code then simply crash when doing `list(locs)[1]['lastmod']`

Step to reproduce:
- Install/run python3.12
- Tweak a bit the requirements.txt
  - Comment the 2 `greenlet` lines
  - replace the 2 lxml lines by 
  ```
        lxml==4.6.5; python_version < '3.12' # min version = 4.5.0 (Focal - with security backports)
        lxml==5.2.1; python_version >= '3.12' # (Noble - removed html clean)
        lxml-html-clean; python_version >= '3.12' # (Noble - removed from lxml, unpinned for futur security patches)
  ```
  - replace werkzeug line by `Werkzeug==3.0.1`
- Install a db with `website_forum`
- Run the `test_01_forum_sitemap` test
- It will crash: 
  ```
      Traceback (most recent call last):
        File "/data/build/odoo/addons/website_forum/tests/test_sitemap.py", line 23, in test_01_forum_sitemap
          self.assertEqual(list(locs)[1]['lastmod'].strftime("%Y-%m-%d"), datetime)
                           ~~~~~~~~~~~~~^^^^^^^^^^^
      KeyError: 'lastmod'
  ```
runbot-65289

Forward-Port-Of: odoo/odoo#165988

[FIX] web_editor: fix the translation of invisible elements

Steps to reproduce:

- Add a second language and enable the "Cookies Bar" in your website
settings.

- Go to a website page (in translation mode) > Traceback.

The implementation from [1] allowed to use text options (text animations
& text highlights) in the translation mode by only creating snippet
editors if the target is a text option snippet.

This code unintentionally prevented editor creation for invisible
snippets, which was required to correctly add entries for every
invisible snippet in the sidebar box (see [2] and [3]).

The goal of this commit is to fix this behavior by forcing the editor's
creation to consider "invisible" elements.

A small adaptation of the `_activateSnippet()` method is also required
to prevent activating invisible snippets when their related sidebar
buttons are clicked.

[1]: https://github.com/odoo/odoo/commit/3a149e36f7e6deaf156a7ee35e654aad61cf2e5d
[2]: https://github.com/odoo/odoo/commit/e9096a3844459b271cecbcc5e50df4a18c4c3d2a
[3]: https://github.com/odoo/odoo/commit/f45a6ea38553566ff35cde3eceb2e4220075205d

opw-3941516 (main one)

Marked as similar:
opw-3936669
opw-3939855
opw-3940168
opw-3940210
opw-3940218
opw-3940224
opw-3940407
opw-3940776
opw-3940845
opw-3940982
opw-3941047
opw-3941333
opw-3941377
opw-3941986
opw-3942480
opw-3944506
opw-3944641
opw-3944862
opw-3944893
opw-3945094
opw-3945589

Forward-Port-Of: odoo/odoo#166380

**Steps to reproduce:**

- Install `documents_project` module (for test purposes)
- Create a new activity type with:
  - `action`: `Upload Document`
  - `folder_id`: `Internal`
  - `model_id`: `Task`
- Go to settings and enable `Centralize files attached to projects and tasks` (from 16.0, set a default folder on the project)
- Go to any task and add a new activity with the new activity type
- Click on `Upload Document` and select a file

**Issue:**

  Access right error message.

**Cause:**

Simple explanation:
2 documents are created (one on the activity creation and one on the attachment upload) and the attachment is linked to the second document. When trying to fisrt unlink the second document and then link the attachment to the first document, the attachment is already unlinked.

Detailed explanation:
When creating the activity, if a folder_id is set on the activity, an empty document is first created with the request_activity_id. https://github.com/odoo/enterprise/blob/a23a18681bddc5995c5dac8cacfb074c06fc5ea8/documents/models/mail_activity.py#L46

When uploading the file, if the related record model is an inherit of `documents.mixin` model and the documents settings (in this case `Document Project Settings`) are activated, it will create the document with the attachment.
https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/ir_attachment.py#L63

Then, in the action done, we will unlink the last document record created and try to link it's attachment (already unlinked) to the first document record (with the `request_activity_id`). https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/mail_activity.py#L33

Since the following commit, when unlinking a document, it unlink also it's attachment: https://github.com/odoo/enterprise/commit/a999f2c32ab542ca7aa44cf34970dc7cca4fdaf8

**Solution:**

Override the upload route (`/mail/attachment/upload`) so that it skip the creation of the second document (by adding `no_document` to the context) if an activity ID is available and that a document with a `request_activity_id` with the same activity ID already exists.

COM PR: https://github.com/odoo/odoo/pull/159943

opw-3458850

Forward-Port-Of: odoo/enterprise#62400
Forward-Port-Of: odoo/enterprise#59796

Steps to reproduce:
- Install `stock_barcode`
- Create two product "aaa" and "bbb" with both of them being tracked by
  lots with the same lot number "123"
- Open the Inventory app and go to Configuration > Operation Types >
  Delivery Orders
- Enable Product in the Barcode App
- Go to the barcode app > Operations > Delivery Orders and click on New
- Scan 123
- Scan aaa (or bbb it probably depends on order of creation of product)
- Scan 123

Issues:
bbb has been added even though we never scanned it.

The reason for this bug is that when we scan 123 we don't have it in the
cache as such we make an RPC and store 123 in `missCache`.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L184-L185

After this when we scan aaa we retrieve the record, and add the line as
intended. The problem arise when we scan 123, since it's already in our
cache.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L130

However that record is not right since this lot is linked to the wrong
product bbb.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L135-L138

We will try to retrieve again the right record, however we will once
again get a hit on the cache. As such no RPC call will be made to
retrieve the lot we're looking for.

We will go in the function once again, where we will have the same
problem this time in the `if (model)` condition.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L112-L115

Later in the execution we will get to this line where we call the
function without a filters which will allow the wrong record to be
added.

https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/models/barcode_model.js#L943

The root of this problem lies in the way we set the key to the cache,
since two product can share the same barcode we need a more precise
cache key to differentiate them.

The proposed solutions is to cache result based on the provided
arguments to the function. This means fewer hit if we retrieve the same
record with different filter for example, however it's safer as when we
hit we are sure to get the right record.

opw-3862263

Forward-Port-Of: odoo/enterprise#61844

This PR fixes two issues with the portal web client of Knowledge:

- When a portal user opens an article and clicks on an article of the sidebar, the article id specified in the route url and the session are not updated. The router only updates the url params of the url. When the user loads the page, the client script will load the article specified in the session. As the session is not updated when switching article, the script can load an incorrect article when reloading the page. This PR aims to fix that issue by ensuring that the client script will load the article with the id specified in the url params of the url.
- When a portal user opens an article, clicks on an article of the sidebar and presses the back button, the system updates the url params and set the right id but it doesn't load the corresponding article in the view. This PR aims to fix that issue by ensuring that the web client load the article whenever the url changes.

task-3743416

Forward-Port-Of: odoo/enterprise#62861
Forward-Port-Of: odoo/enterprise#60845

The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location.
But for immediate transfer, it is not very wise to limited which location the user can scan because they have no way to set source or destination for picking created on the fly from the Barcode app. This commit fixes this issue.

How to reproduce:
- Inventory -> Settings -> Enable "Multi-Step Routes";
- Go to your warehouse and choose 3 steps for incoming and/or outgoing shipments;
- Go to the Barcode App > Operations > Internal Transfers > New;
- In the newly created transfer, try to scan who is not a sublocation of WH/Stock (WH/input for example, barcode: WH-INPUT)
  - :arrow_right:  An error message is displayed because you are not allowed to scan this location.

The exact same issue happens for destination too since 61d378b0a49ba734cff84a39aa2693fe4226225d.

Also, fix a minor unrelated bug where locations on the barcode line are
not correctly written when there name include the picking's defaut
location's name (eg.: WH/Stock 2 when the default location is WH/Stock.)

[OPW-3843358](https://www.odoo.com/web#id=3843358&cids=1&model=project.task&view_type=form)

Forward-Port-Of: odoo/enterprise#62733
Forward-Port-Of: odoo/enterprise#62480