When the user tries to duplicate multiple invoices of different journals,
a traceback will appear.

Steps to reproduce the error:
- Go to Accounting > Configuration > Journals > Create new journal (Type: Sales)
- Go to Customers > Invoices > Create new invoice with newly created journal
- Create another invoice with a different journal
- Select both invoices > Duplicate

Traceback:
```
ValueError: too many values to unpack (expected 1)
  File "odoo/models.py", line 5848, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: account.journal(17, 11)
  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/account/models/account_move.py", line 2652, in copy
    new_moves = super().copy(default)
  File "odoo/models.py", line 5563, in copy
    vals_list = self.with_context(active_test=False).copy_data(default)
  File "addons/stock_account/models/account_move.py", line 29, in copy_data
    vals_list = super().copy_data(default=default)
  File "addons/account/models/account_move.py", line 2646, in copy_data
    if not self.journal_id.active and 'journal_id' in vals_list:
  File "odoo/fields.py", line 1202, in __get__
    record.ensure_one()
  File "odoo/models.py", line 5851, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

https://github.com/odoo/odoo/blob/6c621e62d4b501bb0626276df798b3f8f585fa75/addons/account/models/account_move.py#L2657
Here, self has multiple records when the user duplicates multiple invoices,
So, it will lead to the above traceback.

sentry-5231989306

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

Steps to reproduce:
-------------------
- create a product:
	- service
	- based on timesheets
	- create a project and task on order
- create an order with this product
- confirm the order

- open an helpdesk ticket for the same customer
- select the previous created sale order item
- create a timesheet for this helpdesk ticket

- from the sale order, create the invoice
- confirm the invoice

- go to the invoice and click on preview
- click on view timesheets

--> we have the correct timesheet (OK)

- go to the task and create a timesheet
- create the second invoice from the sale order

- go to the second invoice and click on preview
- click on view timesheets

--> we have the two timesheets which is wrong (KO)

Cause:
------
When we build the domain to search for timesheets linked to an invoice, we add an `OR` domain which takes into account timesheets linked to helpdesk tickets (and on the same sale order line).

Solution:
---------
When searching by invoice, it is necessary to look for timesheets in the helpdesk tickets, but making sure that they are not linked to an invoice that may not be the one requested in the search.

opw-3865963

Forward-Port-Of: odoo/odoo#163617
Forward-Port-Of: odoo/odoo#162960

### Steps to reproduce:

Be sure to have the `sale_sms` module installed.

- Connect as Marc Demo. Note: Marc has the administrator access rights in every service application including projects,...
- Go to the field service app create a new task and change its state to `planned`.

**> Access error: you are not allowed to access 'SMS Templates'**

### Expected behavior:

Since the newly created user has the rights to modify the state of the task and since he does not try to access the content of any sms.template he should not raise this access error.

### Cause of the issue:

The stage `planned` is associated with an SMS template. As such, when a task is moved to this stage, an sms will be sent using the template. This action is done during the `write` override of the `project_sms` module:
https://github.com/odoo/odoo/blob/5f1a3bdcaa63492cf169f6f5f3eb2e2281ad5ab5/addons/project_sms/models/project_task.py#L24-L32 However, this `_send_sms` method will need to 'read' the sms.template to generate the sms:
https://github.com/odoo/odoo/blob/e6be732450d9ef662a48ba074e1ca1ad32e35c04/addons/sms/models/mail_thread.py#L191-L192 Since the user does not have the acess rights to 'read' this template because of the `ir_rule_sms_template_so_sale_manager` acess rule defined in the `sale_sms` module, the access error will be raised.

### Fix:

Since the `_send_sms` method will only read records in order to generate the sms that will be send, we should bypass access rigths checks during the call of this method.

Note: this was already the solution used for portal users.

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

Forward-Port-Of: odoo/odoo#163359
Forward-Port-Of: odoo/odoo#157702

Steps to reproduce the problem:

1. Add a many2one field to lines of a model, example: sale.order.line
2. Add it to form view of the lines with a domain
3. Click on Search more... option
4. You will see results out of the scope of the domain

In the getDomain is passed an object that has only the key fieldName but for knew in what view is the field placed it needs to be provided the key viewType, this both are placed on the class object this.recordParams builded at:
https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L129

If this key is not provided the viewType is beeing filled with the element viewType, this element is the record opened placed in the parent view, so by default if will be kanban or list. So if the domain is filled just in the form view, the search panel will get the domain [], so all the entries will be displayed and they will be able to be selected.

If we see the next line:
https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L431 We will see that getContext is getting this.recordParams as argument, for the same reason that the domain should have it.

With this changes the getDomain method is getting the viewType to take the domain instead of the viewType of the lines displayed on the parent view.

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#163513
Forward-Port-Of: odoo/odoo#162983

Previously, when receiving a new email to create a job applicant for an existing partner, the process would inadvertently erase the phone and mobile numbers on the partner by using the inverse method.

With this commit, the behavior is adjusted so that phone numbers are only written in the inverse method on the partner if there is a number present on the applicant. This prevents the inadvertent removal of phone numbers on the
 partner when creating new applicants for existing partners.

Additionally, this commit ensures that phone numbers from the partner are computed on the applicant as if they were related non-stored fields. This avoids the need for manual re-encoding of numbers later and prevents the inverse method from being forced again.

Furthermore, to optimize the process, email changes are now only processed using the inverse method if the normalized version of the email is different. This prevents unnecessary method calls on the highly used res.partner model when the email is updated, particularly for cases where the normalized version remains the same.

Previously, changing the partner's email from `jke@odoo.com` to `"JKE" jke@odoo.com` would resend all waiting sign requests because the normalized versions of the email were distinct. While ideally, this check could be performed within the sign request code itself, this optimization now helps prevent unnecessary overrides across all modules simultaneously.

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

Since commit 7d2baaa0c726a7b0dd4fe7226862f960c9c59b73 ("Unity read"), we are able to pass a full specification to subfields in a view and retrive records directly according to that specification. This could include "order".

In the case of a list view that has a `widget="handle"`, this order is automatically set to "[handle_field] ASC".

Before the unity read feature, it did not cause problems for one2manys because the ids of records were retrieved in python using the  "natural order" of the model (the `model._order` slot), which usually had the right parameters. (see `sale.order.line` for example). When fetching the ids of the one2many, those were already sorted in natural order.

In unity read, the natural order is overriden by the specification and became only "[handle_field] ASC". This was insufficient as more often than not, sequences on model are set up with a default. So eventually, all records couls have the same sequence. The sorting in SQL becomes undeterminate.

After this commit, we had the sorting key "id ASC" to avoid any unwanted results.

opw-3790378

see discord https://discord.com/channels/678381219515465750/687338039717920792/1231977078564585555 for a detailed discussion.

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

See discussions on https://github.com/odoo/odoo/pull/85494/. TLDR: webp image format needs to be supported, but we should avoid going through the Pillow library as it is largely unsafe for that format. jpg attachment are created in JS at upload time.
Wkhtmltopdf doesn't support webp, so, in reports, we should display one of those jpg copies This work is handled by `ir.qweb: _get_converted_image_data_uri` which is used as:
```xml
<img src="image_data_uri(some_b64value)" />
```

The mentionned PR did not however adapt the ir.qweb.field.image that, when passed the option `qweb_img_raw_data` should return a base64 url such as `data:[mimetype],base64,[datas]`. usage:
```xml
<span t-field="object.image_field" t-options-qweb_img_raw_data="1" />
```

Hence, before this commit, there was a crash as we tried to pass that value to PIL.

After this commit, there is no crash, and the image displays correctly as JPG in the PDF

opw-3859423

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

The goal of this commit is to forward port [the original commit] which was introduced in 16.4 but, due to an error, has not been forward ported.

Original commit message:
Since [1] when uploading images from URL the data is downloaded and then hosted on the Odoo instance. As stated in its task (task-3129360) it should not have been applied to document URLs.
Because of this, when hitting a CORS issue to fetch binary data, we try to fetch the data through an `<img>` element by setting its `src` field
- which also fails when the data is not an image.

This commit makes the changes of [1] specific to image uploads and restores the previous behavior for other files.

Steps to reproduce:
- Drop a "Text - Image" snippet.
- Double-click on the image.
- Go to the Documents tab.
- Click on "Add URL".
- Enter an example PDF URL. E.g.: https://www.africau.edu/images/default/sample.pdf
- Click on "Add URL".

=> Fails because of a CORS issue.

[the original commit]: https://github.com/odoo/odoo/commit/238566d1dea29fd11353e7e6529d29843c4f658b
[1]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5a

task-3493618

Forward-Port-Of: odoo/odoo#163576

Steps to reproduce:
-------------------
- create a product:
	- service
	- based on timesheets
	- create a project and task on order
- create an order with this product
- confirm the order

- open an helpdesk ticket for the same customer
- select the previous created sale order item
- create a timesheet for this helpdesk ticket

- from the sale order, create the invoice
- confirm the invoice

- go to the invoice and click on preview
- click on view timesheets

--> we have the correct timesheet (OK)

- go to the task and create a timesheet
- create the second invoice from the sale order

- go to the second invoice and click on preview
- click on view timesheets

--> we have the two timesheets which is wrong (KO)

Cause:
------
When we build the domain to search for timesheets linked to an invoice, we add an `OR` domain which takes into account timesheets linked to helpdesk tickets (and on the same sale order line).

Solution:
---------
When searching by invoice, it is necessary to look for timesheets in the helpdesk tickets, but making sure that they are not linked to an invoice that may not be the one requested in the search.

opw-3865963

Forward-Port-Of: odoo/enterprise#61596
Forward-Port-Of: odoo/enterprise#61287

HOW TO REPRODUCE
================

Log in as an internal user who is not a member of the `documents_user` group. Go to your profile. You should see the "Documents" smart button.

However, the button has a `groups` attribute to restrict its visibility to the members of the `documents_user` group.

HOW TO FIX
==========

This issue is already known and a tolerated side-effect (see this [commit](https://github.com/odoo/odoo/pull/29659/commits/3651a3721865a465f5457b67436939a91f904bd1))

Moreover, it makes sense for any internal user to be able to access the Documents application, whether they have rights on it or not. As an employee, they may have documents they need to access (e.g.: contract, payslip...)

The solution would be to remove the `groups` attribute from the smart button to reduce confusion among developers. And also, clarify that, indeed, any internal users can see the "Documents" smart button in their profile.

task-3688377

Forward-Port-Of: odoo/enterprise#61227

### Issue:

Tours from `tour_shopfloor.js` fail in "No demo" databases.

### Explanation:

This is due to the setting `group_mrp_routings` being disabled.
When it is enabled, a pop-up appears when entering Shop Floor and the tours take it into account since the setting is enabled with Demo Data.
When it is disabled, the pop-up does not appear, and the tests fail at the first step because of it.
https://github.com/odoo/enterprise/blob/4b34efc77b57562e4c92956c63c8c20e6de53bf0/mrp_workorder/static/src/mrp_display/mrp_display.js#L107 https://github.com/odoo/enterprise/blob/4b34efc77b57562e4c92956c63c8c20e6de53bf0/mrp_workorder/static/src/mrp_display/mrp_display.js#L114-L119

### Fix:

Due to both tests failing for the same reason, the setting will automatically be enabled in `setUpClass`.
`test_shop_floor` also needs an employee named 'Marc Demo', adding the creation of the employee for "No demo" databases. https://github.com/odoo/enterprise/blob/74e0f4fec69d6512e213312bf42f3d743f7a27b3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L28-L31

error-60565
error-58036

Forward-Port-Of: odoo/enterprise#60868