There is a bug with traceback while going to "Accounting / Configuration / Settings" with "Spanish (Latin America)" language selected on user config (install l10n_ar_edi module and take position on company "(AR) Responsable Inscripto"). This pr fixes it. The bug was introduced on this pr https://github.com/odoo/enterprise/pull/71027 .

Bug with traceback:
UncaughtPromiseError > OwlError
Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property)
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
    Error: An error occured in the owl lifecycle (see this Error's "cause" property)
        at handleError (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:916:101)
        at App.handleError (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1548:29)
        at Fiber._render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:941:19)
        at Fiber.render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:939:6)
        at ComponentNode.initiateRender (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1007:47)

Caused by: EvalError: Can not parse python expression: (bool(“l10n_ar_afip_ws_crt”))
    Error: Invalid expression
    EvalError: Can not parse python expression: (bool(“l10n_ar_afip_ws_crt”))
    Error: Invalid expression
        at evaluateExpr (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:3050:128)
        at SettingsFormRenderer.evaluateBooleanExpr (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:3054:8)
        at SettingsFormRenderer.slot533 (eval at compile (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1502:374), <anonymous>:9209:26)
        at callSlot (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1108:25)
        at SearchableSetting.template (eval at compile (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1502:374), <anonymous>:56:13)
        at Fiber._render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:940:96)
        at Fiber.render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:939:6)
        at ComponentNode.initiateRender (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1007:47)

Ticket Adhoc side: 81698
Task latam side: 1279

Forward-Port-Of: odoo/enterprise#72155

For the longest time, the base `ModelConverter` (and `ModelsConverter`) have added a group around their regex. That was (apparently) never useful but Werkzeug didn't care.

Except, it turns out, Werkzeug 2.2 specifically, which is the one we require for Python 3.11, because it's the one bundled in Debian Bookworm.

In this version and this version only werkzeug gets tripped up by our extra group, and doubles up the parameters. This makes it very hard to see as:

- we need a version which uses at least two converters, at least one of which is `model` or `models` in non-last position
- we need to realise that the latter converter gets a copy of the former

The first one is relatively common (70 cases in community, of which 48 use multiple `model` or `models`), however the part where it has to be test and noticed is a lot less likely as we don't routinely test this configuration. Unless somebody happens to use 3.11 locally and follow the `requirements.txt` when installing odoo...

Fixes runbot error 73290

Repro case:

- install tox
- create a file `tox.ini` containing:

    ```ini
    [tox]
    requires = tox >= 4
    env_list = werkzeug{016,10,21,22,23,3}

    [testenv]
    deps =
        pytest
        werkzeug016: werkzeug~=0.16.0
        werkzeug10: werkzeug~=1.0.0
        werkzeug21: werkzeug~=2.1.0
        werkzeug22: werkzeug~=2.2.0
        werkzeug23: werkzeug~=2.3.0
        werkzeug3: werkzeug~=3.0
    commands = pytest app.py
    ```
- create a file `app.py` containing:

    ```python
    import json

    import pytest
    from werkzeug.wrappers import Response
    from werkzeug.test import Client
    from werkzeug.routing import Map, Rule, BaseConverter

    class ModelConverter(BaseConverter):
        regex = r'([0-9]+)'

        def to_python(self, value: str) -> int:
            return int(value)

    class ModelsConverter(BaseConverter):
        regex = r'([0-9,]+)'

        def to_python(self, value: str) -> list[int]:
            return [int(v) for v in value.split(',')]

    url_map = Map(
        [
            Rule("/id/<id:a>"),
            Rule("/id/<id:a>/<id:b>"),
            Rule("/ids/<ids:as>"),
            Rule("/ids/<ids:as>/<id:b>"),
        ],
        strict_slashes=False,
        converters={
            'id': ModelConverter,
            'ids': ModelsConverter,
        }
    )

    def application(environ, start_response):
        urls = url_map.bind_to_environ(environ)
        endpoint, args = urls.match()

        start_response('200 OK', [('Content-Type', 'text/plain')])
        return [json.dumps(args)]

    @pytest.mark.parametrize('url,res', [
        ("/id/1", {'a': 1}),
        ("/id/1/2", {'a': 1, 'b': 2}),
        ("/ids/1,2,3", {"as": [1, 2, 3]}),
        ("/ids/1,2,3/4", {"as": [1, 2, 3], "b": 4}),
    ])
    def test_routing(url, res):
        c = Client(application, Response)
        r = c.get(url)
        assert json.loads(r.get_data()) == res
    ```

- run `tox`
- observe that Werkzeug 2.2 and that version only blows up on cases 2 and 4

Removing the parenthesis inside the regexes fixes the issue.

Forward-Port-Of: odoo/odoo#184277

Issue:
======
Empty inline code block isn't working as expected and produces issues in
the following flows:

First Flow:
- Create a note
- Add ` 2 times
- Delete forward 2 times
- The button send message is modified!!

Second Flow:
- Log a note in the chatter of the note
- Open composer
- Add ` 2 times
- Delete forwart 2 times
- Traceback

Origin of the issue:
=====================
After adding the {backtick} 2 times, it will have the following html
`<p>{backtick}[]<code class="o_inline_code">{backtick}</code></p>` which
is not the expected behavior. now after delete forward we will have the
following html
`<p>{backtick}[]<code class="o_inline_code" data-oe-zws-empty-inline></code></p>`
now we delete forward again it will delete the inline block which
validate the following condition [1] which forces a deleteForward in the
parent element at offset one which is basically here
`<p>{backtick}[]<p>` which now will reach this part of code [2] and the
`findNode` will return a node outside the editable because we didn't
specify the `root` element as a stopping condition.

Solution:
=========
- First we fix the spec of the inline code block which should do nothing
  in case there is no content inside it.
- We add the root as stopping condition while generating the path.

[1]: https://github.com/odoo/odoo/blob/16.0/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L125-L143
[2]: https://github.com/odoo/odoo/blob/d0828eecf60f7c8622d6875b8651eb663bc7d695/addons/web_editor/static/src/js/editor/odoo-editor/src/commands/deleteForward.js#L214-L241

opw-4254182

Forward-Port-Of: odoo/odoo#183567

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

Steps
-----
1. Enter debug mode;
2. create an Automation Rule;
3. select Task as model;
4. set trigger to Stage is set to New;
5. set domain to a specific customer;
6. add send email as action;
7. create a task.

Issue
-----
Email is sent after task creation, regardless of the customer.

Cause
-----
The triggers added to 0a744accc2aa automatically compute the `filter_domain` value, and hide the field in view. With debug mode enabled, the `filter_pre_domain` field is still visible & editable.

The newly added triggers are applied on both create & update, while `filter_pre_domain` is only applied on update. This leads to confusion when clients add a domain which appears to be ignored, as the selected trigger is immediately hit on creation.

Solution
--------
1. Specify in the help string that `filter_pre_domain` is ignored on creation.
2. When entering debug mode, also show the `filter_domain` field, allowing users to further modify the domain computed by the selected trigger, and helping to distinguish itself from `filter_pre_domain`.

opw-3928082

Forward-Port-Of: odoo/odoo#180209

Steps to reproduce the bug:
- Create a storable product P1 with the following BoM:
    - Components:
        - Component 1
        - Component 2
        - Kit (which has its own BoM)

- BoM of the kit:
    - Component 3
    - Component 4

- Create a Mo for one unit of P1
- Confirm the MO

- Update the BoM of P1:
    - Delete Component 2

- Go back to the MO
- Refresh the page
- Click "Update from BoM"

Problem:
Only the move for Component 1 is retained. The moves for Components 2 (which were deleted) and for Components 3 and 4 (which belong to the kit) are removed, while the kit should be decomposed into its own components (3 and 4) and their moves retained.
The current logic did not handle kit products properly when updating the MO. It only compared the components at the top level of the BoM, ignoring the fact that kits contain their own components. As a result, the moves corresponding to the kit's components were not detected and were deleted when updating the MO.

opw-4247193

Forward-Port-Of: odoo/odoo#183638