Issue: - unable to set up different journals on duplicated payment providers. - As a result, customers cannot set up different currencies for the same payment provider in one company database. A very common case with Authorize.Net -> for each currency, a different account needs to be created: USD and CAD.The customers are unable to set up different journals on a payment provider. Steps To Reproduce: - Under one company duplicate a payment acquirer. - Try to set a different journal per eac

Issue:
- unable to set up different journals on duplicated payment providers.
- As a result, customers cannot set up different currencies for the same payment provider in one company database. A very common case with Authorize.Net -> for each currency, a different account needs to be created: USD and CAD.The customers are unable to set up different journals on a payment provider.

Steps To Reproduce:
- Under one company duplicate a payment acquirer.
- Try to set a different journal per each duplicate.
- Notice changing journal on one acquirer changes it on the duplicate.

Solution:
- WIP

Ticket [link](https://www.odoo.com/web#model=project.task&id=3704407)
opw-3704407

Forward-Port-Of: odoo/odoo#166352
Forward-Port-Of: odoo/odoo#154351

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 deac

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

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

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

`action_view_carryover_lines` calls account.report._get_date_bounds_info which is only defined in `account_reports`, and is itself only called from `account_reports`. It wouldn't have worked anyway for anyone who would have tried to call it without account_reports installed. So we take the liberty of moving it to account_reports in stable. See https://github.com/odoo/odoo/pull/155614#discussion_r1609626035 for context Forward-Port-Of: odoo/odoo#166586 Forward-Port-Of: odoo/odoo#166545

`action_view_carryover_lines` calls account.report._get_date_bounds_info which is only defined in `account_reports`, and is itself only called from `account_reports`.

It wouldn't have worked anyway for anyone who would have tried to call it without account_reports installed.

So we take the liberty of moving it to account_reports in stable.

See https://github.com/odoo/odoo/pull/155614#discussion_r1609626035 for context

Forward-Port-Of: odoo/odoo#166586
Forward-Port-Of: odoo/odoo#166545

This PR aims to decrease a bit the contrast of placeholder textin order to avoid confusion with regular text. Prior to this PR, placeholder texts were using a gray value from the grayscale, which was very similar to the `$body-color` in some context. To fix that issue, the color of the placeholder has been reduced to make it lighter, even though it doesn't meet `3.5:1` contrast ratio. task-3686510 - requires https://github.com/odoo/enterprise/pull/62029 Forward-Port-Of: odoo/odoo#1665

This PR aims to decrease a bit the contrast of placeholder textin order to avoid confusion with regular text.

Prior to this PR, placeholder texts were using a gray value from the grayscale, which was very similar to the `$body-color` in some context.

To fix that issue, the color of the placeholder has been reduced to make it lighter, even though it doesn't meet `3.5:1` contrast ratio.

task-3686510
- requires https://github.com/odoo/enterprise/pull/62029

Forward-Port-Of: odoo/odoo#166581
Forward-Port-Of: odoo/odoo#164510

**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 ex

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

Fix the section subtotal on the 'report_saleorder_document' to consider the lines displayed on the report ('lines_to_report') instead of all the sale order lines --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166558

Fix the section subtotal on the 'report_saleorder_document' to consider the lines displayed on the report ('lines_to_report') instead of all the sale order lines


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

Forward-Port-Of: odoo/odoo#166558

This was currently defined in `crm_enterprise` which made impossible to run QUnit tests dependent on this model in community. runbot-65889 https://github.com/odoo/enterprise/pull/63056 Forward-Port-Of: odoo/odoo#166475

This was currently defined in `crm_enterprise` which made impossible to run QUnit tests dependent on this model in community.

runbot-65889

https://github.com/odoo/enterprise/pull/63056

Forward-Port-Of: odoo/odoo#166475

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

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

Steps to reproduce: - Create an expense - Add a product (with units) - Save - Add an attachement - Change the units Issue: The price unit will change to match the total Cause: We wanted to avoid using the _price_compute in case of the OCR Solution: We are making sure that the price unit is only recomputed when using the OCR enterprise: https://github.com/odoo/enterprise/pull/62425 opw-3869104 Forward-Port-Of: odoo/odoo#165352

Steps to reproduce:
- Create an expense
- Add a product (with units)
- Save
- Add an attachement
- Change the units

Issue:
The price unit will change to match the total

Cause:
We wanted to avoid using the _price_compute in case of the OCR

Solution:
We are making sure that the price unit is only recomputed when using the OCR

enterprise: https://github.com/odoo/enterprise/pull/62425

opw-3869104

Forward-Port-Of: odoo/odoo#165352

Steps to reproduce: - add a pivot in a spreadsheet - create a From/To global filter - match the filter with a datetime field of the pivot - set some values in the filter => the domain contains dates, but they should compare the values with datetimes, because a date in a given timezone might start the previous day in UTC time. opw-3805775 Task:3853821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166335

Steps to reproduce:
- add a pivot in a spreadsheet
- create a From/To global filter
- match the filter with a datetime field of the pivot
- set some values in the filter

=> the domain contains dates, but they should compare the values with datetimes, because a date in a given timezone might start the previous day in UTC time.

opw-3805775
Task:3853821


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

Forward-Port-Of: odoo/odoo#166335

Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: 1 unit of C1 - By-product: 1 unit of C2 - Create a manufacturing order to produce 2 unit of P1 - Confirm the MO - Set the qty producing to 1 unit and mark it as done Problem: The quantity displayed for the byproduct is the quantity to produce (product_uom_qty) instead of the quantity produced (Quantity) https://github.com/odoo/odoo/blob/a94f3f4dcb24e08cd4db7fd50ea704e9a065fd83/addons/mrp/re

Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
    - Component: 1 unit of C1
    - By-product: 1 unit of C2

- Create a manufacturing order to produce 2 unit of P1
- Confirm the MO
- Set the qty producing to 1 unit and mark it as done

Problem:
The quantity displayed for the byproduct is the quantity to produce (product_uom_qty) instead of the quantity produced (Quantity)

https://github.com/odoo/odoo/blob/a94f3f4dcb24e08cd4db7fd50ea704e9a065fd83/addons/mrp/report/mrp_report_mo_overview.py#L434

opw-3903182

Forward-Port-Of: odoo/odoo#165612

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 th

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

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'

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

If you have "repeat interval" set to "0" in the Maintenance request, and if you go to the Maintenance calendar, then the system crashes. Adding a validationError to avoid the crash. To Reproduce on Runbot: 1. Go to Maintenance Request 2. Make a new request with Maintenance type as Preventive, Recurrent checked, and Repeat Every to 0. 3. Save it 4. Go to Maintenance Calendar 5. The system crashes opw-3859966 Description of the issue/feature this PR addresses: Current behavior bef

If you have "repeat interval" set to "0" in the Maintenance request, and if you go to the Maintenance calendar, then the system crashes. Adding a validationError to avoid the crash.

To Reproduce on Runbot:
1. Go to Maintenance Request
2. Make a new request with Maintenance type as Preventive, Recurrent checked, and Repeat Every to 0.
3. Save it
4. Go to Maintenance Calendar
5. The system crashes

opw-3859966

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

Description of the issue this PR addresses: Previously, if a mouseup event occured outside the editable area, `currentMouseState` remained as mousedown, causing unnecessary calls to `_handleSelectionInTable` and some other functions such as `getDeepRange`, `getDeepestPosition`, `ancestors`, `closestElement`, etc., during mousemove in editable area. This commit makes sure that when a mouseup event happens outside the editable area, `currentMouseState` is updated to mouseup, preventing these un

Description of the issue this PR addresses:

Previously, if a mouseup event occured outside the editable area, `currentMouseState` remained as mousedown, causing unnecessary calls to `_handleSelectionInTable` and some other functions such as `getDeepRange`, `getDeepestPosition`, `ancestors`, `closestElement`, etc., during mousemove in editable area. This commit makes sure that when a mouseup event happens outside the editable area, `currentMouseState` is updated to mouseup, preventing these unnecessary calls.

Forward-Port-Of: odoo/odoo#166342

The date on an event ticket can be wrong. To reproduce, create an event with a date_begin datetime that falls on the next UTC day. For example, specifying 2024-05-23 18:30 with the user's timezone as America/Los_Angeles results in a stored UTC time of 2024-05-24 01:30:00 (next day). Make sure the timezone of the public user is unset for simplicity's sake (it will fall back on that timezone), and then register for the event in an incognito window through the website. After registering, click "Dow

The date on an event ticket can be wrong. To reproduce, create an event with a date_begin datetime that falls on the next UTC day. For example, specifying 2024-05-23 18:30 with the user's timezone as America/Los_Angeles results in a stored UTC time of 2024-05-24 01:30:00 (next day). Make sure the timezone of the public user is unset for simplicity's sake (it will fall back on that timezone), and then register for the event in an incognito window through the website. After registering, click "Download Tickets". The ticket PDF will display the UTC date.

The event_registration_report_template_full_page_ticket wrapper sets the timezone in context:

<t t-set="event" t-value="attendee.event_id._set_tz_context()"/>

But ir.qweb.field.datetime doesn't use the record with attached context and only looks directly at the value. To make it work, tz_name must be specified explicitly. This is already done for the time part of date_begin below.

opw-3930916

Forward-Port-Of: odoo/odoo#166071

Since [1], Werkzeug discards any remaining data in the read socket after sending the response. In the case of WebSocket connections, the socket is not closed, and data keeps coming. As a result, WebSocket connections to the threaded server hang indefinitely in this discarding phase and never reach the processing phase. Thus, frames sent to the server are never processed. To solve this issue, rfile and wfile are replaced by dummy byte streams to ensure that our socket remains intact.

Since [1], Werkzeug discards any remaining data in the read socket
after sending the response.

In the case of WebSocket connections, the socket is not closed, and
data keeps coming. As a result, WebSocket connections to the threaded
server hang indefinitely in this discarding phase and never reach the
processing phase. Thus, frames sent to the server are never processed.

To solve this issue, rfile and wfile are replaced by dummy byte
streams to ensure that our socket remains intact.

[1]: https://github.com/pallets/werkzeug/commit/4f7048e7a31752142f18eefeccd49acc42a89e31

Forward-Port-Of: odoo/odoo#166379
Forward-Port-Of: odoo/odoo#166231

Steps to reproduce: - Install Project and Timesheet modules - In Timesheets, navigate to Configurations and choose 'Days / Half-Days' as the Encoding Method. - Create a new project. Then, create a task within the project and assign a Timesheet entry to it for 1 Day. - Share the project and copy the link provided. - When opening the link, the task previously recorded as 1 Day in the Timesheet now appears as 1.0 Hour Spent in the customer's portal Current behavior before PR: We are n

Steps to reproduce:
	- Install Project and Timesheet modules
	- In Timesheets, navigate to Configurations and choose 'Days / Half-Days' as the Encoding Method.
	- Create a new project. Then, create a task within the project and assign a Timesheet entry to it for 1 Day.
	- Share the project and copy the link provided.
	- When opening the link, the task previously recorded as 1 Day in the Timesheet now appears as 1.0 Hour Spent in the customer's portal

Current behavior before PR:
We are not passing the 'is_uom_day' value in the project portal view. So in XML when it checks this variable it will get undefined. so, always will go with the else condition.

https://github.com/odoo/odoo/blob/16.0/addons/hr_timesheet/views/project_portal_templates.xml#L50:L53

Desired behavior after PR is merged:
We are now passing this value to check if the timesheet unit is days so it will be shown as 'Days spent' instead of 'Hours spent'

opw-3925368

Forward-Port-Of: odoo/odoo#166281
Forward-Port-Of: odoo/odoo#165737

- Before this commit The "debug" word in the command palette should display the item to activate the debugging feature. The problem is that the command palette still applies the fuzzy search to this item's name. If the lokked up string does not fuzzily match the letters "debug", the item will not get displayed. - After this commit The debug command name will now always have the `debug` word as a non translated part. opw-3889254 Forward-Port-Of: odoo/odoo#165756 Forward-Port-Of: o

- Before this commit
  The "debug" word in the command palette should display the item to activate the debugging feature. The problem is that the command palette still applies the fuzzy search to this item's name. If the lokked up string does not fuzzily match the letters "debug", the item will not get displayed.

- After this commit
  The debug command name will now always have the `debug` word as a non
  translated part.

opw-3889254

Forward-Port-Of: odoo/odoo#165756
Forward-Port-Of: odoo/odoo#165224

[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,

[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

Before this commit, if a website had at least two languages and the copyright area was disabled, a redundant "Language Selector" button would appear. This is not necessary anymore since the "Language Selector" option is already included within the copyright options. Steps to reproduce: - Navigate to the website editor - In the "Theme" tab, click "Add a Language" to add another language - Type "French" or another language and install it - A language selector will appear in the copyrig

Before this commit, if a website had at least two languages and the
copyright area was disabled, a redundant "Language Selector" button
would appear. This is not necessary anymore since the "Language
Selector" option is already included within the copyright options.

Steps to reproduce:

- Navigate to the website editor
- In the "Theme" tab, click "Add a Language" to add another language
- Type "French" or another language and install it
- A language selector will appear in the copyright area
- Click on "or edit master"
- Click on the "copyright" area at the bottom of the page
- Disable the copyright switch button in the right panel
- A "Language Selector" will appear below the "Copyright" switch button
  -> redundant

For the same reason, the "None" option for the language selector in the
navbar has been removed. The new "Header" options include a "Show/Hide"
element specifically for the language selector.

This commit addresses these behaviours.

task-3576937

Forward-Port-Of: odoo/odoo#140441

Fine-tunning of 447ac7fb97b5373ce8623461dc89ab78eade7121 Forward-Port-Of: odoo/odoo#166240 Forward-Port-Of: odoo/odoo#166147

Fine-tunning of 447ac7fb97b5373ce8623461dc89ab78eade7121

Forward-Port-Of: odoo/odoo#166240
Forward-Port-Of: odoo/odoo#166147

**Steps to reproduce:** - Install Accounting, l10n_it_edi and Contacts - Switch to an Italian company (e.g. IT Company) - Go to Contacts - Create an EU contact with "/" or "NA" as VAT (e.g. a German contact with a full address) - Create an invoice: * Customer: [the created contact] * Product: [any] - Confirm the invoice - Process the electronic invoice - Check the generated electronic invoice **Issue:** When a customer has not VAT number, a special value is used in the XML (i.e

**Steps to reproduce:**
- Install Accounting, l10n_it_edi and Contacts
- Switch to an Italian company (e.g. IT Company)
- Go to Contacts
- Create an EU contact with "/" or "NA" as VAT (e.g. a German contact with a full address)
- Create an invoice:
  * Customer: [the created contact]
  * Product: [any]
- Confirm the invoice
- Process the electronic invoice
- Check the generated electronic invoice

**Issue:**
When a customer has not VAT number, a special value is used in the XML (i.e. 0000000).
However, "/" and "NA" that are equivalent to an empty VAT, do not have the special value.
Instead, the "IdFiscaleIVA" section is empty in the XML.

**Cause:**
"/" and "NA" are handled as a normal VAT and are truncated because the 2 first characters are not digits.

opw-3889051



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

Forward-Port-Of: odoo/odoo#166404
Forward-Port-Of: odoo/odoo#166316

Issue: ====== Extra down-payment line is creating Steps to reproduce the issue: ============================= - create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice. - go back to SO create another downpayment with 30% Solution: ========= Typically, when calculating the value of down-payment lines, we only consider sales order lines for products, not down-payment lines. This is because, accor

Issue:
    ======
   	Extra down-payment line is creating

    Steps to reproduce the issue:
    =============================
    - create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice.
    - go back to SO create another downpayment with 30%

    Solution:
    =========
	Typically, when calculating the value of down-payment lines,
	we only consider sales order lines for products, not down-payment lines.
	This is because, according to the Odoo workflow,
	down-payment lines are created based on product lines in the sales order,
	not on down-payment lines themselves. Therefore, I am filtering out those lines here.

    closes odoo/odoo#163699

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

Issue: ====== Email doesn't have applied design changes (format , color ..) Steps to reproduce the issue: ============================= - Go to Email marketing - Create a new one - Add a subject, mailing list, and choose any template that have some blocks - Go to design tab in editor and change any color or size of something - Click save and test sending the email - The email doesn't have the changes applied Origin of the issue: ==================== When first rendering , Css

Issue:
======
Email doesn't have applied design changes (format , color ..)

Steps to reproduce the issue:
=============================
- Go to Email marketing
- Create a new one
- Add a subject, mailing list, and choose any template that have some
  blocks
- Go to design tab in editor and change any color or size of something
- Click save and test sending the email
- The email doesn't have the changes applied

Origin of the issue:
====================
When first rendering , CssRules are calculated using the first version
of the template and styles. When we update the design so the css rules,
they are not applied in the inlineHtml since it uses the old cssRules.

Solution:
==========
We only use `_rulesCache` defined in `wysiwyg` and we already handle
everything in `toInline` from calculating the `cssRules` to saving them
in the cache, so we just pass `undefined` as cssRules and let it take
care of everything.

task-3289131

Forward-Port-Of: odoo/odoo#166340
Forward-Port-Of: odoo/odoo#153180

Due to recent rule changes for E-faktur, now NIK and NPWP are complement to each other. Which means now, when the person is filling in 000000000000000, e-faktur should be taking the NIK as NPWP column in e-Faktur 3815006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166339 Forward-Port-Of: odoo/odoo#163707

Due to recent rule changes for E-faktur, now NIK and NPWP are complement to each other. Which means now, when the person is filling in 000000000000000, e-faktur should be taking the NIK as NPWP column in e-Faktur

3815006

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

Forward-Port-Of: odoo/odoo#166339
Forward-Port-Of: odoo/odoo#163707

Few improvements for commit [1]: \- Before [1], `_find_global_route`, was not supposed to create any route. Let's keep it like that \- `_find_global_route` is sometimes calls with an empty `self` \- The name of the copied route should not contain "(Copy)" \- When looking for a route, we should skip the `active` criteria [1] https://github.com/odoo/odoo/commit/961ac2d70e897fb235d2d581db3a91b7c4163a41 OPW-3889889 OPW-3888885 Forward-Port-Of: odoo/odoo#166372 Forward-Port-Of: odoo/odoo

Few improvements for commit [1]:
\- Before [1], `_find_global_route`, was not supposed to create any
route. Let's keep it like that
\- `_find_global_route` is sometimes calls with an empty `self`
\- The name of the copied route should not contain "(Copy)"
\- When looking for a route, we should skip the `active` criteria

[1] https://github.com/odoo/odoo/commit/961ac2d70e897fb235d2d581db3a91b7c4163a41

OPW-3889889
OPW-3888885

Forward-Port-Of: odoo/odoo#166372
Forward-Port-Of: odoo/odoo#165728

**[FIX] website: fix close offcanvas on page click** Steps to reproduce the bug: - In "Website" edtit mode. - Drop some snippets. - Select a Hamburger menu header template or resize the screen at MD to have the mobile menu. - Open the menu => the offcanvas backdrop is transparent and we see the snippets behind it. - Click on the page to close it and then reopen it. => The offcanvas is not transparent anymore and the layout looks broken. This is due to the fact that the code handles

**[FIX] website: fix close offcanvas on page click**

Steps to reproduce the bug:

- In "Website" edtit mode.
- Drop some snippets.
- Select a Hamburger menu header template or resize the screen at MD to have the mobile menu.
- Open the menu => the offcanvas backdrop is transparent and we see the snippets behind it.
- Click on the page to close it and then reopen it. => The offcanvas is not transparent anymore and the layout looks broken.

This is due to the fact that the code handles the hint preview for the "Powerbox" considers that it must insert the hint in a "<div>" if it's empty. See the "_makeHint()" function in this commit [1].

In this commit, we fix this by preventing selection on the backdrop. There's probably a better way to fix it. But until the problem is solved more generally, we simply fix it in CSS for the "Backdrop".

[1]: https://github.com/odoo/odoo/commit/4600086e7a2831664cc104a143e1014870874427

task-3853573

-----------------------------

**[FIX] website: fix overlay header when mobile menu is open**

Steps to reproduce the bug:

- Open a page in Website edit mode.
- Click on the header.
- Select a red color for the background option of the header.
- Choose "Over The Content" for the "Header Position" option.
- Resize the screen to MD to have the mobile menu.
- Click on the "hamburger button".
=> Bug: The header is red instead of transparent.

The bug arises because since this commit [2], the transparent background
of the "Over The Content" header is removed when the mobile menu is
open.

[2]: https://github.com/odoo/odoo/commit/e10913daf7025accb3b93808ae12ce4a50db1510

task-3853573

Forward-Port-Of: odoo/odoo#162870

This commit is used for the enterprise PR (odoo/enterprise#62261). When creating an invoice for a previous order in the POS, the class InvoiceButton handles missing partners, writing the selected partner to pos.order. But since the partner was not set to the order, the JS client cannot retrieve the partner directly. This commit remedies that by setting the partner to the order. task-3865331 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr F

This commit is used for the enterprise PR (odoo/enterprise#62261).

When creating an invoice for a previous order in the POS, the class InvoiceButton handles missing partners, writing the selected partner to pos.order. But since the partner was not set to the order, the JS client cannot retrieve the partner directly.

This commit remedies that by setting the partner to the order.

task-3865331


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

Forward-Port-Of: odoo/odoo#166283
Forward-Port-Of: odoo/odoo#165464

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

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

STEP TO REPRODUCE: -Add gif api key -Go to a channel and choose any gif to be favorite -Then go to favorites category and we will the gif has been duplicate although we only choose one REASON: because we use 'this.pushGif(gif);' 2 time first when loading favorites gif and second is open it 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 ww

STEP TO REPRODUCE:
-Add gif api key
-Go to a channel and choose any gif to be favorite -Then go to favorites category and we will the gif has been duplicate although we only choose one

REASON: because we use 'this.pushGif(gif);' 2 time first when loading favorites gif and second is open it

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

Problem: When the user checks their activities, the overdue count is including done activities for Tasks and To-do. The bug occurs when "keep done" is enabled for activity types. Purpose: The overdue counts should not be factoring in done activities. Steps to Reproduce on Runbot17.1: 1. Install project and project_todo 2. Enable "Keep Done" on activity type "To-Do" 3. Create an overdue to-do activity on a project task 4. Mark the activity as done 5. Notice that the overdue count did

Problem: When the user checks their activities,
the overdue count is including done activities for Tasks and To-do. The bug occurs when "keep done" is enabled for activity types.

Purpose: The overdue counts should not be factoring in done activities.

Steps to Reproduce on Runbot17.1:
1. Install project and project_todo
2. Enable "Keep Done" on activity type "To-Do"
3. Create an overdue to-do activity on a project task
4. Mark the activity as done
5. Notice that the overdue count did not go down.

opw-3877089

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

Forward-Port-Of: odoo/odoo#165857

**Current behaviour before PR:** Selecting multiple tables using mouse throws traceback. This happens because in _selectTableCells method, range has no table as closest element of commonAncestorContainer which gives traceback later. This method needs a table as closest element to be worked. **Desired behaviour after PR:** There should be no traceback. This can be handled by returning the method if we don't find the closest table. task-3922517 --- I confirm I have signed the

**Current behaviour before PR:**

Selecting multiple tables using mouse throws traceback. This happens because in _selectTableCells method, range has no table as closest element of commonAncestorContainer which gives traceback later. This method needs a table as closest element to be worked.

**Desired behaviour after PR:**

There should be no traceback. This can be handled by returning the method if we don't find the closest table.

task-3922517




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

Forward-Port-Of: odoo/odoo#165234

Creating a 308 which redirects to an existing controller will have unpredictable (and unwanted) behaviors. Indeed, 308 are there to redirect an existing URL (like `/shop`) to a non-existing URL (like `/my-super-shop`) and to make it so that non existing URL will respond with the content of the existing URL. The way it's done is that it simply replace the routing map rule for the given URL by two new rules: - One for the non-existing URL (chosen url_to) which will serve the existing url en

Creating a 308 which redirects to an existing controller will have unpredictable (and unwanted) behaviors.

Indeed, 308 are there to redirect an existing URL (like `/shop`) to a non-existing URL (like `/my-super-shop`) and to make it so that non existing URL will respond with the content of the existing URL.

The way it's done is that it simply replace the routing map rule for the given URL by two new rules:
- One for the non-existing URL (chosen url_to) which will serve the existing url endpoint
- One for the existing URL, which will be turned into a redirect endpoint

This works fine except if you actually select an existing controller as url_to in the 308 rewrite.

In this case, there will be 2 werkzeug Rules for the same URL, which is bad. Worst than that, depending of the selected controller the order of those 2 Rules will change, leading to different behavior.

Step to reproduce:
- Create a 308 from /blog to / (note that "/" is a controller)
- Go to /blog, it will redirect and show the homepage
- Go to /, it will show the homepage
- Now edit the 308 and redirect /shop to /
- Go to /shop, it redirects to / but won't show the homepage, it will show the shop page
- Go to /, it will show the shop page

Technically, here is the routing map for both cases:
1. 308 shop case
```
<FasterRule '/' -> functools.partial(<bound method WebsiteSale.shop of <odoo.http.CustomerPortal (extended by PortalAccount, PaymentPortal, CustomerPortalExternalTax, SaleStockPortal, CustomerPortal, PaymentPortal, PaymentPortal, WebsiteSaleDelivery, WebsiteSaleExternalTaxCalculation, WebsiteSale, WebsiteSaleStockRenting, WebsiteSaleStockRenting, WebsiteSale, WebsiteSaleRenting, PaymentPortal, CustomerPortalExternalTax, CustomerPortal, WebsiteAccount) object at 0x7f4d9468a6b0>>)>,
<FasterRule '/' -> functools.partial(<bound method Website.index of <odoo.http.Home (extended by Home, Home, Routing, AuthSignupHome, Website) object at 0x7f4d94583460>>)>,
```
2. 308 blog case
```
<FasterRule '/' -> functools.partial(<bound method Website.index of <odoo.http.Home (extended by Home, Home, Routing, AuthSignupHome, Website) object at 0x7f7fc9ebd7e0>>)>,
<FasterRule '/' -> functools.partial(<bound method WebsiteBlog.blog of <odoo.http.WebsiteBlog object at 0x7f7fc9d69090>>)>,
```

You see that the Rule order is inverted from one case to another.

We could have decided to do another fix and adapt the `_generate_routing_rules()` method to keep only one Route but that seems worst as:
1. 308 are not designed for that in the first place, not even sure what we would want
2. it will technically be far from ideal, having the check routing map to check if exists already and ensure the same behavior all the time

Note that testing a few main controllers, only the /shop seems to lead
to this different behavior.

Note that it's a bit of a non-stable change, so 17.0 seems like a good
compromise. Especially since the /shop example is not buggy before 17.0
as somehow the `Website.index` Rule is before the `WebsiteSale.shop`.
```
<FasterRule '/' -> functools.partial(<bound method Website.index of <odoo.http.Home (extended by Home, Home, Routing, AuthSignupHome, Website, WebsiteTest) object at 0x7fad28571660>>)>,
<FasterRule '/' -> functools.partial(<bound method WebsiteSale.shop of <odoo.http.WebsiteSale (extended by WebsiteSaleDelivery, WebsiteSale) object at 0x7fad28435e40>>)>,
```

opw-3901713

Forward-Port-Of: odoo/odoo#166070
Forward-Port-Of: odoo/odoo#165083

Steps to reproduce: - Create two warehouses A & B - Open the warehouse B form - Set warehouse A as resupply and save - Remove warehouse A as resupply and save - Set warehouse A as a resupply again and save Issue: Instead of unarchiving the existing resupply route, it created a new route instead, meaning we have now two resupply routes from the same warehouse to the same warehouse. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-

Steps to reproduce:
- Create two warehouses A & B
- Open the warehouse B form
- Set warehouse A as resupply and save
- Remove warehouse A as resupply and save
- Set warehouse A as a resupply again and save

Issue:
Instead of unarchiving the existing resupply route, it created a new route instead, meaning we have now two resupply routes from the same warehouse to the same warehouse.

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

Forward-Port-Of: odoo/odoo#165859
Forward-Port-Of: odoo/odoo#165129

opw-3904133 Forward-Port-Of: odoo/odoo#165801

opw-3904133

Forward-Port-Of: odoo/odoo#165801

l10n_br_edi_services defines l10n_br_property_service_code_origin_id on product.template. It's a property field, so to ensure it's read correctly by ir_cron_account_move_send that runs as OdooBot we explicitly set the company for the entire flow. Although not strictly needed in l10n_br_edi, fixing it here is the cleanest and most complete. The *_services modules will be merged into the main ones anyway. task-3887264 Forward-Port-Of: odoo/enterprise#63110

l10n_br_edi_services defines l10n_br_property_service_code_origin_id on product.template. It's a property field, so to ensure it's read correctly by ir_cron_account_move_send that runs as OdooBot we explicitly set the company for the entire flow.

Although not strictly needed in l10n_br_edi, fixing it here is the cleanest and most complete. The *_services modules will be merged into the main ones anyway.

task-3887264

Forward-Port-Of: odoo/enterprise#63110

The payment acquirer must always be linked to a single journal, one per company. It's currently an hard constraint So after the duplication, both are always linked to the same journal but only one appear on it. This "fix" is improving that allowing the duplication of an existing acquirer and to be able to link them to diffe opw-3704407 Forward-Port-Of: odoo/enterprise#62989 Forward-Port-Of: odoo/enterprise#62744

The payment acquirer must always be linked to a single journal, one per company. It's currently an hard constraint So after the duplication, both are always linked to the same journal but only one appear on it. This "fix" is improving that allowing the duplication of an existing acquirer and to be able to link them to diffe

opw-3704407

Forward-Port-Of: odoo/enterprise#62989
Forward-Port-Of: odoo/enterprise#62744

Since the commit https://github.com/odoo/enterprise/pull/52348/commits/5c11c94b972d1993de4147d96fc3faaaaddc7c57 a test has been added that check the cloc result it stored on a ICP. But the result can be a bit different then expected during custom build if custom module are installed prior mail_enterprise. Solution: Check only the value of odoo/studio module that give the custom line in database that should be always empty during installation Forward-Port-Of: odoo/enterprise#63108 Forward-

Since the commit https://github.com/odoo/enterprise/pull/52348/commits/5c11c94b972d1993de4147d96fc3faaaaddc7c57 a test has been added that check the cloc result it stored on a ICP.

But the result can be a bit different then expected during custom build if custom module are installed prior mail_enterprise.

Solution: Check only the value of odoo/studio module that give the custom line in database that should be always empty during installation

Forward-Port-Of: odoo/enterprise#63108
Forward-Port-Of: odoo/enterprise#62909

`action_view_carryover_lines` calls account.report._get_date_bounds_info which is only defined in `account_reports`, and is itself only called from `account_reports`. It wouldn't have worked anyway for anyone who would have tried to call it without account_reports installed. So we take the liberty of moving it to account_reports in stable. See https://github.com/odoo/odoo/pull/155614#discussion_r1609626035 for context Forward-Port-Of: odoo/enterprise#63114 Forward-Port-Of: odoo/enterpr

`action_view_carryover_lines` calls account.report._get_date_bounds_info which is only defined in `account_reports`, and is itself only called from `account_reports`.

It wouldn't have worked anyway for anyone who would have tried to call it without account_reports installed.

So we take the liberty of moving it to account_reports in stable.

See https://github.com/odoo/odoo/pull/155614#discussion_r1609626035 for context

Forward-Port-Of: odoo/enterprise#63114
Forward-Port-Of: odoo/enterprise#63092

This PR aims to decrease a bit the contrast of placeholder textin order to avoid confusion with regular text. Prior to this PR, placeholder texts were using a gray value from the grayscale, which was very similar to the `$body-color` in some context. To fix that issue, the color of the placeholder has been reduced to make it lighter, even though it doesn't meet `3.5:1` contrast ratio. task-3686510 - requires https://github.com/odoo/odoo/pull/164510 Forward-Port-Of: odoo/enterprise#631

This PR aims to decrease a bit the contrast of placeholder textin order to avoid confusion with regular text.

Prior to this PR, placeholder texts were using a gray value from the grayscale, which was very similar to the `$body-color` in some context.

To fix that issue, the color of the placeholder has been reduced to make it lighter, even though it doesn't meet `3.5:1` contrast ratio.

task-3686510
- requires https://github.com/odoo/odoo/pull/164510

Forward-Port-Of: odoo/enterprise#63111
Forward-Port-Of: odoo/enterprise#62029

This was currently defined in `crm_enterprise` which made impossible to run QUnit tests dependent on this model in community. runbot-65889 https://github.com/odoo/odoo/pull/166475 Forward-Port-Of: odoo/enterprise#63056

This was currently defined in `crm_enterprise` which made impossible to run QUnit tests dependent on this model in community.

runbot-65889

https://github.com/odoo/odoo/pull/166475

Forward-Port-Of: odoo/enterprise#63056

In certain scenarios, the `_compute_l10n_mx_edi_idccp()` method does not assign a value to its related field. This omission results in a traceback because non-stored computed fields must be assigned a value by the end of their compute method's execution. opw-3923109 Forward-Port-Of: odoo/enterprise#62533

In certain scenarios, the `_compute_l10n_mx_edi_idccp()` method does not assign a value to its related field. This omission results in a traceback because non-stored computed fields must be assigned a value by the end of their compute method's execution.

opw-3923109

Forward-Port-Of: odoo/enterprise#62533

To reproduce the issue, on a runbot with the demo data: 1) Setup a prefix group threshold of 2 on the Partner Ledger 2) Open the Partner Ledger ==> The lines created for the prefix groups show "0.0" in the columns supposed to contain non-number values. Instead, these columns should contain empty values on those lines. The bug originates in the common helper called to generate the prefix group lines, so it does not only impact the Partner Ledger. We fix it and modify the test a little bi

To reproduce the issue, on a runbot with the demo data:

1) Setup a prefix group threshold of 2 on the Partner Ledger 2) Open the Partner Ledger

==> The lines created for the prefix groups show "0.0" in the columns supposed to contain non-number values. Instead, these columns should contain empty values on those lines.

The bug originates in the common helper called to generate the prefix group lines, so it does not only impact the Partner Ledger. We fix it and modify the test a little bit to check that behavior as well.

Forward-Port-Of: odoo/enterprise#63052
Forward-Port-Of: odoo/enterprise#62740

Steps to reproduce: - Create an expense - Add a product (with units) - Save - Add an attachement - Change the units Issue: The price unit will change to match the total Cause: We wanted to avoid using the _price_compute in case of the OCR Solution: We are making sure that the price unit is only recomputed when using the OCR community: https://github.com/odoo/odoo/pull/165352 opw-3869104 Forward-Port-Of: odoo/enterprise#62425

Steps to reproduce:
- Create an expense
- Add a product (with units)
- Save
- Add an attachement
- Change the units

Issue:
The price unit will change to match the total

Cause:
We wanted to avoid using the _price_compute in case of the OCR

Solution:
We are making sure that the price unit is only recomputed when using the OCR

community: https://github.com/odoo/odoo/pull/165352

opw-3869104

Forward-Port-Of: odoo/enterprise#62425

An error is raised when accessing customer statement from contact page in studio. ### Steps to reproduce: - Install Studio, Contact apps and the l10n_account_customer_statements module. - Open studio and go to Reports - When clicking on the Customer Statements report an error is raised ### Cause: Studio uses the partner res.partner(0,) to display the report in edit mode, but the method _get_report_values is always searching for the partner data to fill the report. The error is raised b

An error is raised when accessing customer statement from contact page in studio.

### Steps to reproduce:
- Install Studio, Contact apps and the l10n_account_customer_statements module.
- Open studio and go to Reports
- When clicking on the Customer Statements report an error is raised

### Cause:
Studio uses the partner res.partner(0,) to display the report in edit mode, but the method _get_report_values is always searching for the partner data to fill the report. The error is raised because res.partner(0,) does not reference any partner.

### Solution:
Modify _get_report_values to search for partner data only if the partner id is different from 0.

opw-3920298

Forward-Port-Of: odoo/enterprise#62891

Fixed typo for `cdfi` that not generates the section for bank accounts on the PDF for payment complement, and with this fix was improved the way to get the values from the dict, because not in all the cases are assigned all the values. https://github.com/odoo/enterprise/blob/17.0/l10n_mx_edi/models/account_move.py#L392 Forward-Port-Of: odoo/enterprise#62836

Fixed typo for `cdfi` that not generates the section for bank accounts on the PDF for payment complement, and with this fix was improved the way to get the values from the dict, because not in all the cases are assigned all the values.

https://github.com/odoo/enterprise/blob/17.0/l10n_mx_edi/models/account_move.py#L392

Forward-Port-Of: odoo/enterprise#62836

Currently, when importing a CAMT file, the system fails to use `<AddtlNtryInf>` as a fallback for the payment reference. ### Steps to Reproduce 1. Install `account_bank_statement_import_camt`. 2. Import a CAMT file with a statement that includes `<TxDtls>` but no `<RmtInf>`, and has `<AddtlNtryInf>` defined. (You can use the one provided in the tests) **Expected Result:** The imported statement's payment reference should contain the value of `<AddtlNtryInf>`. **Actual Result:** The

Currently, when importing a CAMT file, the system fails to use `<AddtlNtryInf>` as a fallback for the payment reference.

### Steps to Reproduce

1. Install `account_bank_statement_import_camt`.
2. Import a CAMT file with a statement that includes `<TxDtls>` but no `<RmtInf>`, and has `<AddtlNtryInf>` defined. (You can use the one provided in the tests)

**Expected Result:** The imported statement's payment reference should contain the value of `<AddtlNtryInf>`.

**Actual Result:** The imported statement's payment reference contains `/` instead.

### Cause

The system attempts to use `<AddtlNtryInf>` as a fallback for `payment_ref`. However, it looks in the wrong place. It searches inside `<TxDtls>`, whereas `<AddtlNtryInf>` is actually a child of `<Ntry>`.

opw-3878785

Forward-Port-Of: odoo/enterprise#62703

Currently, applying an analytic filter on the general ledger results in a traceback. ### Steps to reproduce * Install `account_reports` * Open the General Ledger * Unfold all the lines * Attempt to apply an analytic filter You will encounter a traceback: `psycopg2.ProgrammingError: can't adapt type 'SQL'` ### Cause Commit odoo/odoo@467cabacc49893c433e69ca7a2cd65add068098b introduced new SQL queries using the `SQL()` wrapper. However, these `SQL()` wrapped queries are being mixe

Currently, applying an analytic filter on the general ledger results in a traceback.

### Steps to reproduce

* Install `account_reports`
* Open the General Ledger
* Unfold all the lines
* Attempt to apply an analytic filter

You will encounter a traceback: `psycopg2.ProgrammingError: can't adapt type 'SQL'`

### Cause

Commit odoo/odoo@467cabacc49893c433e69ca7a2cd65add068098b introduced new SQL queries using the `SQL()` wrapper. However, these `SQL()` wrapped queries are being mixed with regular string queries and end up being used as parameters for `cr.execute()`, which produces the error.

opw-3910410

Forward-Port-Of: odoo/enterprise#62513

0 lines are still included in exported report when Hide lines at 0 is toggled Steps to reproduce: - Open a report, e.g. Balance Sheet (Accounting > Reporting > Balance Sheet) - In options, toggle 'Hide lines at 0' - Click in PDF to export a PDF version of the report - 0 lines are included in the PDF file When "Hide lines at 0" is toggled, lines at 0 are still included in the PDF/XLSX report, despite being hidden in the report view. This leads to a difference between what the user sees

0 lines are still included in exported report when Hide lines at 0 is toggled

Steps to reproduce:
- Open a report, e.g. Balance Sheet (Accounting > Reporting > Balance Sheet)
- In options, toggle 'Hide lines at 0'
- Click in PDF to export a PDF version of the report
- 0 lines are included in the PDF file

When "Hide lines at 0" is toggled, lines at 0 are still included in the PDF/XLSX report, despite being hidden in the report view. This leads to a difference between what the user sees and what is printed.

Another reason to hide lines at 0 from the printed report is that lines with Hide if Zero checked does impact the PDF. This means the two options (Hide lines at 0 and Hide if Zero) have similar impacts in the user view but different behavior in printed reports.

This commit implements the function _filter_out_0_lines to remove lines at 0 from printed report if "Hide lines at 0" is toggled, and adds a test.

task-3888290

Forward-Port-Of: odoo/enterprise#63000

The tour is failing rarely and undeterministically. It seems like the reason is because 2 steps from the tour are done before a request is done (and so the number of the call to the function). We add a step to enforce that the request is made before the next step of the tour. We also enforce that we don't do the last action before closing the tour. In ulterior versions, the tour can be stuck when adding a product. Our guess is that the button is clicked before the page is fully loaded.

The tour is failing rarely and undeterministically. 
It seems like the reason is because 2 steps from the tour are done before a request is done (and so the number of the call to the function). 
We add a step to enforce that the request is made before the next step of the tour.
We also enforce that we don't do the last action before closing the tour.

In ulterior versions, the tour can be stuck when adding a product. 
Our guess is that the button is clicked before the page is fully loaded. 
The tour would then consider it did click the button, while the action didn't happen.

We add a check to wait for the page to be fully loaded before clicking.

Linked to runbot error 61458, 63532, 59031 (and happened before already).

Forward-Port-Of: odoo/enterprise#62873
Forward-Port-Of: odoo/enterprise#61964

Issue: ------ When we go to a gantt view with the day view, the time format is always displayed in 12-hour format followed by "am" or "pm". Depending on the location, this format may also be 24 hours. Solution: --------- Use the current localization to determine the time display format. opw-3867317 Forward-Port-Of: odoo/enterprise#62762 Forward-Port-Of: odoo/enterprise#61209

Issue:
------
When we go to a gantt view with the day view, the time format is always displayed in 12-hour format followed by "am" or "pm". Depending on the location, this format may also be 24 hours.

Solution:
---------
Use the current localization to determine the time display format.

opw-3867317

Forward-Port-Of: odoo/enterprise#62762
Forward-Port-Of: odoo/enterprise#61209

Before this commit: request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data. After this commit: request timeout increased to 60 seconds. opw-3890386 Forward-Port-Of: odoo/enterprise#62043

Before this commit:
request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data.

After this commit:
request timeout increased to 60 seconds.

opw-3890386

Forward-Port-Of: odoo/enterprise#62043

In the view when `email_from` precomputation isn't triggered because one of its dependencies `mail_server_id` isn't present in the view, because of that `email_from` stays NULL which raises an error since it's a required field. task-3901450 Forward-Port-Of: odoo/enterprise#62860 Forward-Port-Of: odoo/enterprise#62164

In the view when `email_from` precomputation isn't triggered because one of its dependencies `mail_server_id` isn't present in the view, because of that `email_from` stays NULL which raises an error since it's a required field.

task-3901450

Forward-Port-Of: odoo/enterprise#62860
Forward-Port-Of: odoo/enterprise#62164

Check if the user selected the carrier for storable/consumable products before proceeding to payment. opw-3810367 See also: - https://github.com/odoo/odoo/pull/161476 Forward-Port-Of: odoo/enterprise#62914 Forward-Port-Of: odoo/enterprise#60550

Check if the user selected the carrier for storable/consumable products before proceeding to payment.

opw-3810367

See also:

- https://github.com/odoo/odoo/pull/161476

Forward-Port-Of: odoo/enterprise#62914
Forward-Port-Of: odoo/enterprise#60550

Steps to reproduce: - Install l10n_es_reports - Switch to a Spanish company (e.g. ES Company) - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Check that a Spanish Tax Report is selected (i.e. Mod 111/115/303/347/349) - Click on "Save" - Select "BOE" for "Export To" option - Export Issue: A traceback is raised: "KeyError: 'res_id'" Cause: In previous versions, "open_boe_wizard" method was creating the wizard and returning its "id". It's not the case anymore.

Steps to reproduce:
- Install l10n_es_reports
- Switch to a Spanish company (e.g. ES Company)
- Go to "Accounting / Reporting / Statement Reports / Tax Report"
- Check that a Spanish Tax Report is selected (i.e. Mod 111/115/303/347/349)
- Click on "Save"
- Select "BOE" for "Export To" option
- Export

Issue:
A traceback is raised:
"KeyError: 'res_id'"

Cause:
In previous versions, "open_boe_wizard" method was creating the wizard and returning its "id".
It's not the case anymore.

Complement of https://github.com/odoo/enterprise/commit/e8d5582a773d7f31669fa8be576569681ed3f110

opw-3856749

Forward-Port-Of: odoo/enterprise#62841

The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user. As a result, invalid NumCta values were generated, whi

The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user.

As a result, invalid NumCta values were generated, which would include parts of the account name if dots were present in it, or the value would be too long if the code had more than two dots.

Subdividing the code into further levels is allowed, they'll get aggregated into the allowed SAT code (of the form XXX or XXX.YY). Dots in account names shouldn't matter.

This fix makes the parsing of the NumCta value more strict so it supports the above use cases.

In case the prefix doesn't match the expected pattern, an error is shown to the user. Normally this shouldn't happen, since the line would have been filtered out if it didn't match a valid prefix from the upper levels. It was added to make the code more robust against refactoring and customization, and to prevent an uncaught traceback in that case.

opw-3878763

Forward-Port-Of: odoo/enterprise#62920
Forward-Port-Of: odoo/enterprise#62113

Steps to reproduce: 1. In the contact page for a Mexican-based contact, add a default usage 2. Start a new session in point of sale 3. Select the client with a default usage, add go to payment 4. Select invoice. The usage field shows 'Acquisition of merchandise', despit the default usage selected before Currently, the popup only takes into account the l10n_mx_edi_usage selected in the POS session or the code 'Acquisition of merchandise' if the field is undefined. The same behaviour hap

Steps to reproduce:
1. In the contact page for a Mexican-based contact, add a default usage
2. Start a new session in point of sale
3. Select the client with a default usage, add go to payment
4. Select invoice. The usage field shows 'Acquisition of merchandise', despit the default usage selected before

Currently, the popup only takes into account the l10n_mx_edi_usage selected in the POS session or the code 'Acquisition of merchandise' if the field is undefined.

The same behaviour happens if an invoice is created for a previous order.

This commit adds l10n_mx_edi_usage to the partner fields to be loaded when loading the pos data. Then, the field in the popup can be filled with the default CDFI usage of the partner if it exists. Else, it behaves as before, displaying either the usage code selected in the POS session or code 'Acquisition of merchandise' if the field is undefined.

task-3865331

Forward-Port-Of: odoo/enterprise#62942
Forward-Port-Of: odoo/enterprise#62261

**Steps to reproduce:** - Install account_reports - Install a RTL language (e.g. Arabic) - Set the RTL language on the current user - Set the currency of the company to SR - Go to "Accounting / Reporting / Partner Ledger" - Make sure there are some partners with long name (but less than 50 chars) - Print PDF **Issue:** In RTL, the partner column overflows outside of the page width. **Cause:** The break-word is only activated when the name has more than 50 characters. In RTL, the

**Steps to reproduce:**
- Install account_reports
- Install a RTL language (e.g. Arabic)
- Set the RTL language on the current user
- Set the currency of the company to SR
- Go to "Accounting / Reporting / Partner Ledger"
- Make sure there are some partners with long name  (but less than 50 chars)
- Print PDF

**Issue:**
In RTL, the partner column overflows outside of the page width.

**Cause:**
The break-word is only activated when the name has more than 50 characters. In RTL, the cell to display the partner is smaller.

**Solution:**
Do not use a minimum length of 50 characters to activate "break-word" in RTL.

opw-3888122

Forward-Port-Of: odoo/enterprise#62626

Since we don't create anymore a contract by default, we don't need to change the values of the contract on the newly created bike. More over, if there is a customization of the creation of vehicle it will scratch it Forward-Port-Of: odoo/enterprise#62455

Since we don't create anymore a contract by default, we don't need to change the values of the contract on the newly created bike. More over, if there is a customization of the creation of vehicle it will scratch it

Forward-Port-Of: odoo/enterprise#62455

Steps to reproduce: ------------------- - create a project; - create a new planning slot for the project with a resource (user); - go to the project and create a task; - record timesheet in the planning slot time range in the task; - go to the planning slot view (via list view) Issue: ------ The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`. Cause: ------ The `effective_hours` field will be recomp

Steps to reproduce:
-------------------
- create a project;
- create a new planning slot for the project with a resource (user);
- go to the project and create a task;
- record timesheet in the planning slot time range in the task;
- go to the planning slot view (via list view)

Issue:
------
The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`.

Cause:
------
The `effective_hours` field will be recomputed if one of its dependencies changes (in this case, `timesheet_ids`). For `timesheet_ids` to be marked for compute,
one of its dependencies must change.

`project_id.analytic_account_id.line_ids`
is different from `project_id.timesheet_ids`.

As a result, the method which computes `effective_hours` is not triggered.

Solution:
---------
Add `project_id.timesheet_ids` in dependencies.

opw-3891624

Forward-Port-Of: odoo/enterprise#61668

Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work order using the work center from the previous step. On the miscellaneous tab, add an analytic account. 4. Confirm the MO. 5. On the Work Orders tab, change the Real Duration to 60:00 6. Analytic account smart button > the gross margin is correctly set. 7. Either change the real duration to 0:

Steps
-----
1. Install accounting and mrp_workorder_hr, activate analytic accounting in
settings.
2. Select a work center and check "Requires Log In"
3. Create a manufacturing order and add a work order using the work center from
the previous step. On the miscellaneous tab, add an analytic account.
4. Confirm the MO.
5. On the Work Orders tab, change the Real Duration to 60:00
6. Analytic account smart button > the gross margin is correctly set.
7. Either change the real duration to 0:00 or open the work order and delete a
line from the Time Tracking tab.
Note: decreasing the Real Duration on the Manufacturing Order page will not lead
to an issue as long as no time record is deleted on the work order (typically,
when decreasing the time by a small amount).

Issue
-----
The gross margin still takes into account the employee's cost for the deleted time.
Note that the workcenter's cost is removed from the gross margin as expected.
Either by _create_or_update_analytic_entry in case the time of the work order
is modified, or unlink if the work order is deleted.
https://github.com/odoo/odoo/blob/16.0/addons/mrp_account/models/mrp_workorder.py

Fix
-----
When deleting a time record, modify the analytic account accordingly.
We create an analytic entry with a previous_duration equal to the
double of the time that is deleted.
https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L16
That way, we create an analytic entry with a duration equal to the negative
of the deleted time. This will add a positive amount to the analytic
account.
https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L21-L22
This  makes the analytic account's gross margin consistent with the time
worked.

**opw-3759144**

Forward-Port-Of: odoo/enterprise#61881
Forward-Port-Of: odoo/enterprise#58760