*: im_livechat, im_livechat_mail_bot Since odoo/odoo#110188 `canned_response_ids` is not being passed to `mail_message_post` and since odoo/odoo#127382 canned response is enabled in only non-channel threads so odooBot onboarding crashes on the canned response step. This commit allows using `canned responses` in `chat with odooBot` and makes sure that we send them with the message post data. Related to odoo/odoo#157997 Forward-Port-Of: odoo/odoo#163607 Forward-Port-Of: odoo/odoo#162234

*: im_livechat, im_livechat_mail_bot

Since odoo/odoo#110188 `canned_response_ids` is not being passed to `mail_message_post` and since odoo/odoo#127382 canned response is enabled in only non-channel threads so odooBot onboarding crashes on the canned response step. This commit allows using `canned responses` in `chat with odooBot` and makes sure that we send them with the message post data.

Related to odoo/odoo#157997

Forward-Port-Of: odoo/odoo#163607
Forward-Port-Of: odoo/odoo#162234

In this PR: - Added Ladakh (LA, 38), Foreign Country (IN_OC, 96), and Other Territory (IN_OT, 97). - Renamed `Dadra & Nagar Haveli` to `Dadra & Nagar Haveli & Daman & Diu` (Code 26). Ref: https://einvoice1.gst.gov.in/Others/MasterCodes Task ID: [3878468](https://www.odoo.com/web#id=3878468&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#163598 Forward-Port-Of: odoo/odoo#162624

In this PR:
- Added Ladakh (LA, 38), Foreign Country (IN_OC, 96), and Other Territory (IN_OT, 97).
- Renamed `Dadra & Nagar Haveli` to `Dadra & Nagar Haveli & Daman & Diu` (Code 26).

Ref: https://einvoice1.gst.gov.in/Others/MasterCodes

Task ID: [3878468](https://www.odoo.com/web#id=3878468&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form)

Forward-Port-Of: odoo/odoo#163598
Forward-Port-Of: odoo/odoo#162624

Problem --- When logged in as a portal user, if the `/jobs` route is configured to allow filtering by department the user gets a 403 when choosing a department to filter by and an `AccessError` is thrown for the `hr.department` model Steps --- * install website, and create a "Career" page in the wizard * on the `.../jobs` page: Editor > Edit > Customize > toggle 'Departments Filter' * log out and log in as `portal` (pw: `portal`) * go to `.../jobs` and select a department to filt

Problem
---
When logged in as a portal user,
if the `/jobs` route is configured to allow filtering by department
the user gets a 403 when choosing a department to filter by
and an `AccessError` is thrown for the `hr.department` model

Steps
---
* install website, and create a "Career" page in the wizard
* on the `.../jobs` page:
  Editor > Edit > Customize > toggle 'Departments Filter'
* log out and log in as `portal` (pw: `portal`)
* go to `.../jobs` and select a department to filter by
  (dropdown in the topbar)
* An `AccessError` is thrown

Fix
---
Give access rights to the responsible piece of code,
so the website functions as expected.

opw-3874665

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

Forward-Port-Of: odoo/odoo#162396

Issue ----- The trailing text on the `ir.sequence` view is unreadable due to spanning only one column which leads to awkward line-wrapping. Steps ----- - Go to Settings -> Technical -> Sequences. - Select the sequence with code "sale.order". - Have a look at the legend. Cause ----- The `<div>` containing the text spans only one column which is not suitable for long text. opw-3820141 Forward-Port-Of: odoo/odoo#161403 Forward-Port-Of: odoo/odoo#160912

Issue
-----

The trailing text on the `ir.sequence` view is unreadable due to spanning only one column
which leads to awkward line-wrapping.

Steps
-----

 - Go to Settings -> Technical -> Sequences.
 - Select the sequence with code "sale.order".
 - Have a look at the legend.

Cause
-----

The `<div>` containing the text spans only one column which is not suitable for long text.

opw-3820141

Forward-Port-Of: odoo/odoo#161403
Forward-Port-Of: odoo/odoo#160912

In saas-16.2, the peppol_endpoint and peppol_eas fields were added to the partner. When importing an xml inheriting from EN16931 (Peppol Bis 3, A-NZ, E-FFF, NLCIUS, etc), use the peppol endpoint and eas to retrieve the correct partner, by passing a search domain to `_retrieve_partner` (through the `domain` argument). Hence, when retrieving the partner (using `_retrieve_partner`), we will sequentially: 1. search for a partner with a matching VAT 2. if there's a domain provided, search

In saas-16.2, the peppol_endpoint and peppol_eas fields were added to the partner.

When importing an xml inheriting from EN16931 (Peppol Bis 3, A-NZ, E-FFF, NLCIUS, etc), use the peppol endpoint and eas to retrieve the correct partner, by passing a search domain to `_retrieve_partner` (through the `domain` argument).

Hence, when retrieving the partner (using `_retrieve_partner`), we will sequentially:

1. search for a partner with a matching VAT

2. if there's a domain provided, search a partner matching the domain

3. search for a partner with a matching phone or email

4. search for a partner with a matching name

If not partner is found, we create a new one.

opw-3815296

Forward-Port-Of: odoo/odoo#163563
Forward-Port-Of: odoo/odoo#159742

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 c

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

[FIX] hr_expense: allow to create expenses via alias for employees not related to a user Current behavior: When trying to create an expense using alias, if a `hr.employee` not linked to a user want to, he won't be able This bug occurs after this [commit](https://github.com/odoo/odoo/commit/fbeb7aebcadbe77ff7774b538550373650b329fe) Steps to reproduce the error : - Create an employee not related to a user - Configure alias for expenses - Try to send an email to the expense's alias and

[FIX] hr_expense: allow to create expenses via alias for employees not related to a user

Current behavior:
When trying to create an expense using alias, if a `hr.employee` not linked to a user want to, he won't be able

This bug occurs after this [commit](https://github.com/odoo/odoo/commit/fbeb7aebcadbe77ff7774b538550373650b329fe)

Steps to reproduce the error :
- Create an employee not related to a user
- Configure alias for expenses
- Try to send an email to the expense's alias and check at the logs

After this commit:
Employees without a related user will be able to create an expense from an email alias

opw-3892778
opw-3892701
opw-3893319
opw-3893591

Forward-Port-Of: odoo/odoo#163672
Forward-Port-Of: odoo/odoo#163494

### Steps to reproduce the issue: 1. Create a purchase Tax and tick Include in Price in the Advanced Options 2. Create a Purchase Order with Analytic Distribution towards a Project in the Order Line 3. Set the purchase Tax created before as the tax of the Order Line 4. Confirm the Purchase Order 5. Make sure the Project is Billable, then go to the Project Updates 6. The profitability calculated the price with the included Tax 7. Create a Vendor Bill and set the same Tax and Analytic Dis

### Steps to reproduce the issue:

1. Create a purchase Tax and tick Include in Price in the Advanced Options
2. Create a Purchase Order with Analytic Distribution towards a Project in the Order Line
3. Set the purchase Tax created before as the tax of the Order Line
4. Confirm the Purchase Order
5. Make sure the Project is Billable, then go to the Project Updates
6. The profitability calculated the price with the included Tax
7. Create a Vendor Bill and set the same Tax and Analytic Distribution as the Purchase order
8. Confirm the Bill
9. Return to the Project Updates
10. The profitability doesn't calculate the included Tax

### Explanation:

In `project.project._get_profitability_items`, we can find an inconsistency in the queries. The query for `purchase.order.line` is looking for `price_unit`, which takes included taxes into account. https://github.com/odoo/odoo/blob/249aaac7bd1a13d62c947cddb1835772659aabff/addons/project_purchase/models/project.py#L125-L132 The query for `account.move.line` retrieves `price_subtotal`, which does not. https://github.com/odoo/odoo/blob/249aaac7bd1a13d62c947cddb1835772659aabff/addons/project_purchase/models/project.py#L171-L181

### Suggested fix:

In `project.project._get_revenues_items_from_invoices`, the `account.move.line` query retrieves `price_subtotal` as well. https://github.com/odoo/odoo/blob/8750b94c53c6ab58567873b0745fa6d9a18c97d0/addons/sale_project/models/project.py#L467-L474 With above information and input of PO (olma), taxes will not be calculated in `project.project._get_profitability_items`, therefore we will replace `price_unit` with `price_subtotal` in the `purchase.order.line` query.

opw-3781426

Forward-Port-Of: odoo/odoo#163567
Forward-Port-Of: odoo/odoo#161634

This commit add the logging of hash string data. By printing the string to hash, it becomes easier to investigate issues. opw-3839287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163018

This commit add the logging of hash string data. By printing the string to hash, it becomes easier to investigate issues.

opw-3839287

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

Forward-Port-Of: odoo/odoo#163018

Currently when we have an Analytic Filter applied on an accounting report, we lose that filter when we click on any amount to audit the journal items. This fix makes sure that when auditing, we only view the journal items filtered by the Analytic Filter. In order to do that, we extend the search function in the analytic mixin to allow searching on analytic account ids. [task-3718751](https://www.odoo.com/web#id=3718751&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view

Currently when we have an Analytic Filter applied on an accounting report, we lose that filter when we click on any amount to audit the journal items.

This fix makes sure that when auditing, we only view the journal items filtered by the Analytic Filter.

In order to do that, we extend the search function in the analytic mixin to allow searching on analytic account ids.

[task-3718751](https://www.odoo.com/web#id=3718751&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form)

Related to https://github.com/odoo/enterprise/pull/55972

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

Forward-Port-Of: odoo/odoo#161873
Forward-Port-Of: odoo/odoo#152897

Before fce296acd9f4187c8473ca5ae0b68fb96e9026ff, the retrieve partner function first looked for a partner with company_id = env.company.id. If a parter wasn't found, a global search without constraining `company_id` was made. Thus, a search in a database with 2 partners with the same VAT (one has a company_id, the other not) would return the partner linked to the right company. After fce296acd9f4187c8473ca5ae0b68fb96e9026ff, it is no longer the case. The search is done with `[('company_id'

Before fce296acd9f4187c8473ca5ae0b68fb96e9026ff, the retrieve partner function first looked for a partner with company_id = env.company.id. If a parter wasn't found, a global search without constraining `company_id` was made.

Thus, a search in a database with 2 partners with the same VAT (one has a company_id, the other not) would return the partner linked to the right company.

After fce296acd9f4187c8473ca5ae0b68fb96e9026ff, it is no longer the case. The search is done with `[('company_id', 'in', [self.env.company.id, False])`, so 2 partners are found, and none are returned.

We reintroduce that loop in this commit to fix that case.

Forward-Port-Of: odoo/odoo#163386
Forward-Port-Of: odoo/odoo#163188

Otherwise we leave the constraints in the table. Common source of upgrade issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161115

Otherwise we leave the constraints in the table. Common source of upgrade issues.

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

Forward-Port-Of: odoo/odoo#161115

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. Add

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

Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time Off** app * Select **Configuration** > **Time Off Type** * Create a new time off type * Approval: By Employee's Approver and Time Off Oficcer * Requires allocation: Yes * Employee Requests: Extra Days Requests Allowed * Approval: Approved by Time Off Officer * Notified Time off offi

Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user.

Steps to reproduce:
-------------------
* Go to the **Time Off** app
* Select **Configuration** > **Time Off Type**
* Create a new time off type
  * Approval: By Employee's Approver and Time Off Oficcer
  * Requires allocation: Yes
  * Employee Requests: Extra Days Requests Allowed
  * Approval: Approved by Time Off Officer
  * Notified Time off officer: Mitchell Admin
* Select **Management** > **Allocations**
* Create a new allocation
  * Employees: Mitchell Admin
  * Time off time: The one created previously
* Validate the allocation
* Select **Management** > **Time Off**
* create a new time off
  * Employees: Any Employee A & Employee B
  * Time off type:
  > Observation: The new time off time is present in the name search while both employees don't have any allocation for it.

Why the fix:
------------
The name search searches for time off type with
```
['|', ['requires_allocation', '=', 'no'], '&', ['has_valid_allocation', '=', True], '&', ['max_leaves', '>', '0'], '|', ['allows_negative', '=', True], '&', ['virtual_remaining_leaves', '>', 0], ['allows_negative', '=', False]]
```
By configuration, the time off has `requires_allocation = yes` therefore it shouldn't appear here and it does not -> ok

`has_valid_allocation` has a search method `_search_valid` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L109-L138

`max_leaves` has a search method `_search_max_leaves` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L165-L192

Both use the function `_get_contextual_employee` to make their search. https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_employee.py#L386-L388

When there are more than one employee selected on the hr leave form, the context contains `employee_id: False`. Thus here we are making the search using the current user, which is Mitchell Admin.

The search shouldn't be made using the current user in this case since he doesn't correspond to any of the employees we added of the form.

opw-3816442

Forward-Port-Of: odoo/odoo#161713

If you create an applicability and remove the company field, they are never used. An applicability like this should be valid for all companies. We put a 0.5 value for the company field so an applicability so it has a lesser priority than other fields. Same idea as the distribution models. opw-3847415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162152

If you create an applicability and remove the company field, they are never used.
An applicability like this should be valid for all companies.
We put a 0.5 value for the company field so an applicability so it has a lesser priority than other fields.
Same idea as the distribution models.

opw-3847415




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

Forward-Port-Of: odoo/odoo#162152

The cover scss rule first stretches the image to fill the container completely, then cropped at the size of the container. This results in some poor display result if the image has a weird aspect ratio. This is a behaviour change from saas-16.3 where the image wasn't cropped and simply resized to fit inside the container. opw-3826349 saas-16.3:  saas-16.4: ![image](https://github.com/odoo/

The cover scss rule first stretches the image to fill the container completely, then cropped at the size of the container.

This results in some poor display result if the image has a weird aspect ratio.

This is a behaviour change from saas-16.3 where the image wasn't cropped and simply resized to fit inside the container.

opw-3826349

saas-16.3:
![image](https://github.com/odoo/odoo/assets/57365423/3b256ccb-8682-4050-8a07-c6aca5a80fe8)

saas-16.4:
![image](https://github.com/odoo/odoo/assets/57365423/b840fcc2-a999-462c-a61e-4a1c5b32bfa5)

fixed locally (16.4):
![image](https://github.com/odoo/odoo/assets/57365423/3a5206c0-7495-4b3f-b00b-ca9d7a64b0a8)

Forward-Port-Of: odoo/odoo#161111
Forward-Port-Of: odoo/odoo#161038

The survey.survey_user_input_rule_survey_user_read rule is override in both hr_appraisal_survey and in hr_recruitment_survey. The problem arises when both modules are installed. If so, the domain is taken from the module that is installed the last. This should not be case, instead domain should be combined. On top of it, the domain is not corrected when the app is unistalled. This commit fixes that too task - 3597033 Description of the issue/feature this PR addresses: Current b

The survey.survey_user_input_rule_survey_user_read rule is override in both hr_appraisal_survey and in hr_recruitment_survey.

The problem arises when both modules are installed. If so, the domain is taken from the module that is installed the last.

This should not be case, instead domain should be combined.

On top of it, the domain is not corrected when the app is unistalled. This commit fixes that too

task - 3597033

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#163138
Forward-Port-Of: odoo/odoo#162238

We are in the context of anglo-saxon accounting, when selling a product having an automated valuation. The invoice linked to the `pos.order` should have its stock output line reconciled with its counterpart in the stock valuation journal. That is what happens if you create the invoice directly from point of sale. Currently, if you do not create the invoice, keep the session open and then click the "Invoice" button on the pos order, the stock output line will not be reconciled. This

We are in the context of anglo-saxon accounting, when selling a product
having an automated valuation.  The invoice linked to the `pos.order`
should have its stock output line reconciled with its counterpart in
the stock valuation journal.  That is what happens if you create the
invoice directly from point of sale.

Currently, if you do not create the invoice, keep the session open and
then click the "Invoice" button on the pos order, the stock output line
will not be reconciled.

This happens because in `action_pos_order_invoice`, the picking is
created after the invoice.  But the reconciliation happens when creating
the invoice.  As it doesn't have its valuation counterpart yet (which is
created from the picking), it then do not reconcile with anything.

The fix here is to create the picking before.

opw-3702345

Forward-Port-Of: odoo/odoo#162594
Forward-Port-Of: odoo/odoo#154595

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

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 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/od

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

Steps to reproduce the bug: - Create a storable product “P1”. - Update its quantity to 10. - Create a delivery picking: - Add the product “P1” with 10 units. - Mark as to do. - Scrap 1 quantity of “P1”. - Try to validate the picking. Problem: A wizard asking to create a backorder is triggered. This occurs because the move of the scrap is created, linked to the picking, and marked as 'done' (so, picked). Therefore, when validating the picking, we will checks if all the move

Steps to reproduce the bug:
- Create a storable product “P1”.
- Update its quantity to 10.
- Create a delivery picking:
    - Add the product “P1” with 10 units.
    - Mark as to do.
    - Scrap 1 quantity of “P1”.
- Try to validate the picking.

Problem:
A wizard asking to create a backorder is triggered. This occurs because the move of the scrap is created, linked to the picking, and marked as 'done' (so, picked). Therefore, when validating the picking, we will checks if all the moves are picked (Even if not picked, it will work because we'll set them all to 'picked'). but as the first move is not picked and the scrap one is picked, the backorder wizard is raised.

opw-3821869

Forward-Port-Of: odoo/odoo#163395

Steps to Reproduce on Runbot: - Install MRP - Create a second warehouse - Go to Warehouse -> Routes -> Manufacturing. - Set the "Supplied Warehouse" to the first warehouse. - In Inventory > Opertaions > Replenishment - Create a new Replenishment with Manufacturing route - click on Replenishment information (small "i" button) - Expected singelton traceback error. Fix: get_lead_time in Manufacturing expects a single rule using _get_rule to determine the correct rule as the comment sug

Steps to Reproduce on Runbot:
- Install MRP
- Create a second warehouse
- Go to Warehouse -> Routes -> Manufacturing.
- Set the "Supplied Warehouse" to the first warehouse.
- In Inventory > Opertaions > Replenishment
- Create a new Replenishment with Manufacturing route
- click on Replenishment information (small "i" button)
- Expected singelton traceback error.

Fix:
get_lead_time in Manufacturing expects a single rule
using _get_rule to determine the correct rule as the comment suggested 


opw-3838099

Forward-Port-Of: odoo/odoo#163318

Since the introduction of `user_id` field, it makes sense to allow those users to update/read/delete templates they have been assigned to. task-3748816 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#162400

Since the introduction of `user_id` field, it makes sense to allow those users to update/read/delete templates they have been assigned to.

task-3748816

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

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

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

Commit [1] made a mistake when adapting the `guardedCatch` handler. [1]: https://github.com/odoo/odoo/commit/fcb16a3b1bd373726ffb54f0fbe41fb6d1784769 Forward-Port-Of: odoo/odoo#163486

Commit [1] made a mistake when adapting the `guardedCatch` handler.

[1]: https://github.com/odoo/odoo/commit/fcb16a3b1bd373726ffb54f0fbe41fb6d1784769

Forward-Port-Of: odoo/odoo#163486

Problem: when configuring a provider (from the form view) in shipping methods, after: * setting the provider to "Fixed Price" * setting the free_over / amount field * changing the provider to "Based on Rules" the free_over / amount still applies even though the field becomes hidden. Desired behavior after: When the provider is "Based on Rules", ignore the `free_over` / `amount` if it is set (but don't unset it, still hide it in the view). opw-3852858 --- I confirm I have signed t

Problem:
when configuring a provider (from the form view) in shipping methods, after:
* setting the provider to "Fixed Price"
* setting the free_over / amount field
* changing the provider to "Based on Rules" the free_over / amount still applies even though the field becomes hidden.

Desired behavior after:
When the provider is "Based on Rules", ignore the `free_over` / `amount`
if it is set (but don't unset it, still hide it in the view).

opw-3852858

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

Forward-Port-Of: odoo/odoo#162980
Forward-Port-Of: odoo/odoo#160975

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

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 mentionn

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

**Current behavior:** If a recurring sale order has an associated sale order option and the recurring plan of the order is changed, a trace back occurs. **Expected behavior:** The recurring plan can be changed as it ordinarily would. **Steps to reproduce:** 1. Add a recurring product to a sale order 2. Add an optional recurring product to the order 3. Try to change the recurring plan of the order to encounter the trace back **Cause of the issue:** This flow causes some 'phanto

**Current behavior:**
If a recurring sale order has an associated sale order option and the recurring plan of the order is changed, a trace back occurs.

**Expected behavior:**
The recurring plan can be changed as it ordinarily would.

**Steps to reproduce:**
1. Add a recurring product to a sale order

2. Add an optional recurring product to the order

3. Try to change the recurring plan of the order to encounter the trace back

**Cause of the issue:**
This flow causes some 'phantom' sale order lines to have their price recalculated (phantom because they have no price, qty, currency, nor order_id field values). During this recalculation a currency_id is expected either in the line itself or in the sale order it is a part of. Because there is no value for either of these, it fails the ensure_one() method in the sequence (0 vals, expects 1).

The phantom lines are created in the `sale.order.option` model in the `sale_management` module, in `_compute_price_unit()` and `_compute_discount()`.

**Fix:**
Call `invalidate_recorset(flush=False)` on these cached records at the end of the methods in which they are created.

Test added in https://github.com/odoo/enterprise/pull/58264

opw-3754297

Forward-Port-Of: odoo/odoo#158950
Forward-Port-Of: odoo/odoo#157515

Some databases have a default column value `undefined` on l10n_mx_edi_cfdi_sat_state. When assigning `undefined` to `l10n_mx_edi_cfdi_sat_state`, the orm raises an error because it's no longer a valid value for this selection field. To not block people, let's set the field to None by default. Forward-Port-Of: odoo/enterprise#61686

Some databases have a default column value `undefined` on l10n_mx_edi_cfdi_sat_state. When assigning `undefined` to `l10n_mx_edi_cfdi_sat_state`, the orm raises an error because it's no longer a valid value for this selection field. To not block people, let's set the field to None by default.

Forward-Port-Of: odoo/enterprise#61686

Missing condition that is hiding the "Reset to Draft" button on all journal entries. Forward-Port-Of: odoo/enterprise#61677

Missing condition that is hiding the "Reset to Draft" button on all journal entries.

Forward-Port-Of: odoo/enterprise#61677

The Belgian "Post a tax report entry" wizard was modified to pop only when the closing entry corresponds to a Belgian tax. Prior to this commit, the "Post a tax report entry" wizard would pop when attempting to post a closing entry that corresponds to non-Belgian taxes. It should not pop up. task-3829124 Forward-Port-Of: odoo/enterprise#61556 Forward-Port-Of: odoo/enterprise#61223

The Belgian "Post a tax report entry" wizard was modified to pop only when the closing entry corresponds to a Belgian tax.

Prior to this commit, the "Post a tax report entry" wizard would pop when attempting to post a closing entry that corresponds to non-Belgian taxes. It should not pop up.

task-3829124

Forward-Port-Of: odoo/enterprise#61556
Forward-Port-Of: odoo/enterprise#61223

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 c

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

To reproduce: ============= - configure helpdesk team with email address - contact this email address with a contact doesn't exist in the database -> the created ticket won't have a description Problem: ======== the message's `author_id` is not set, which prevents the description to be set, as we compare the `partner_id` of the ticket with the message's `author_id` to make sure to deal with real customer and not Odoobot or anything else. Solution: ========= instead of comparing t

To reproduce:
=============
- configure helpdesk team with email address
- contact this email address with a contact doesn't exist in the database
-> the created ticket won't have a description

Problem:
========
the message's `author_id` is not set, which prevents the description to be set,
as we compare the `partner_id` of the ticket with the message's `author_id`
to make sure to deal with real customer and not Odoobot or anything else.

Solution:
=========
instead of comparing the `partner_id` of the ticket with the message's `author_id`,
we compare the `partner_email` of the ticket with the message's `email_from`.

opw-3850228

Forward-Port-Of: odoo/enterprise#60858

Currently when we have an Analytic Filter applied on an accounting report, we lose that filter when we click on any amount to audit the journal items. This fix makes sure that when auditing, we only view the journal items filtered by the Analytic Filter. [task-3718751](https://www.odoo.com/web#id=3718751&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Related to https://github.com/odoo/odoo/pull/152897 Forward-Port-Of: odoo/enterprise#60742 Forward-Port-

Currently when we have an Analytic Filter applied on an accounting report, we lose that filter when we click on any amount to audit the journal items.

This fix makes sure that when auditing, we only view the journal items filtered by the Analytic Filter.

[task-3718751](https://www.odoo.com/web#id=3718751&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form)

Related to https://github.com/odoo/odoo/pull/152897

Forward-Port-Of: odoo/enterprise#60742
Forward-Port-Of: odoo/enterprise#55972

The error was caused by the fact that the receipt component was wrongly overridden. There was no any check to see if the company was using the Chilean localization, so the error was raised. This commit fixes: [runbot/error#61720](https://runbot.odoo.com/web#id=61720&model=runbot.build.error), [runbot/error#61722](https://runbot.odoo.com/web#id=61722&model=runbot.build.error), [runbot/error#61723](https://runbot.odoo.com/web#id=61723&model=runbot.build.error), [runbot/error#61724](https://runb

The error was caused by the fact that the receipt component was wrongly overridden. There was no any check to see if the company was using the Chilean localization, so the error was raised.

This commit fixes: [runbot/error#61720](https://runbot.odoo.com/web#id=61720&model=runbot.build.error), [runbot/error#61722](https://runbot.odoo.com/web#id=61722&model=runbot.build.error), [runbot/error#61723](https://runbot.odoo.com/web#id=61723&model=runbot.build.error), [runbot/error#61724](https://runbot.odoo.com/web#id=61724&model=runbot.build.error)

Forward-Port-Of: odoo/enterprise#60737

…ements - Add partner name check for Ultimate Debtor/Creditor (UltmtDbtr/UltmtCrdt) - Add transaction name check for Additional Remittance Information (AddtlRmtInf) Initial request from Swedish partner @daniel-stenlov, confirmed with documents: https://www.nordea.com/en/doc/nordea-caar-camt.053.001.02-account-statement-extended-0.pdf Related: https://github.com/odoo/enterprise/pull/49542 Co-authored-by: daniel-stenlov Forward-Port-Of: odoo/enterprise#59927

…ements

- Add partner name check for Ultimate Debtor/Creditor (UltmtDbtr/UltmtCrdt)
- Add transaction name check for Additional Remittance Information (AddtlRmtInf)

Initial request from Swedish partner @daniel-stenlov, confirmed with documents: https://www.nordea.com/en/doc/nordea-caar-camt.053.001.02-account-statement-extended-0.pdf

Related: https://github.com/odoo/enterprise/pull/49542

Co-authored-by: daniel-stenlov

Forward-Port-Of: odoo/enterprise#59927

Mandatory Analytic Plans should be mandatory. This was not checked when reconciling a bank statement. This commit adds a check to ensure that the analytic distribution is correct when reconciling a bank statement. Task: 3864633 Forward-Port-Of: odoo/enterprise#60740

Mandatory Analytic Plans should be mandatory. This was not checked when reconciling a bank statement. This commit adds a check to ensure that the analytic distribution is correct when reconciling a bank statement.

Task: 3864633

Forward-Port-Of: odoo/enterprise#60740

The survey.survey_user_input_rule_survey_user_read rule is override in both hr_appraisal_survey and in hr_recruitment_survey. The problem arises when both modules are installed. If so, the domain is taken from the module that is installed the last. This should not be case, instead domain should be combined. task - 3597033 Forward-Port-Of: odoo/enterprise#61363 Forward-Port-Of: odoo/enterprise#60941

The survey.survey_user_input_rule_survey_user_read rule is override in both hr_appraisal_survey and in hr_recruitment_survey.

The problem arises when both modules are installed. If so, the domain is taken from the module that is installed the last.

This should not be case, instead domain should be combined.

task - 3597033

Forward-Port-Of: odoo/enterprise#61363
Forward-Port-Of: odoo/enterprise#60941

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

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

Problem: For a peruvian company, there is many choices of identification type and when creating an invoice, the identification type is always "RUC" whatever the identification type really is Steps to reproduce: - Install the "contacts" and the "accounting" apps - Add a peruvian company from the settings and set the "fiscal localization" as "Peru" for this company - Create a new contact from Peru and set the "Identification Number" as DNI and fill in the number - Create an invoice for thi

Problem:
For a peruvian company, there is many choices of identification type and when creating an invoice, the identification type is always "RUC" whatever the identification type really is

Steps to reproduce:
- Install the "contacts" and the "accounting" apps
- Add a peruvian company from the settings and set the "fiscal localization" as "Peru" for this company
- Create a new contact from Peru and set the "Identification Number" as DNI and fill in the number
- Create an invoice for this customer and preview the invoice
- You will see written on top right "RUC:" instead of "DNI:"

Cause:
The identification type shown on the invoice is the default one for the country and then is not updated depending on the selection

Solution:
Replace the field to the selected one for Peru

opw-3846814

Forward-Port-Of: odoo/enterprise#61123

Purpose: -------- Add a button in the front end view that allows users to end the current booking (to make the room appear as free), as the only way to do it for now is to delete the booking, which is not suitable if one would like to track the bookings in the backend view. The "book now" button is reworded to "start now" and the "schedule booking" button to "Add a booking" because it was observed that users were sometimes confused with these two buttons. The "booked room" icon has be

Purpose:
--------
Add a button in the front end view that allows users to end the current
booking (to make the room appear as free), as the only way to do it for
now is to delete the booking, which is not suitable if one would like to
track the bookings in the backend view.

The "book now" button is reworded to "start now" and the
"schedule booking" button to "Add a booking" because it was observed
that users were sometimes confused with these two buttons.
The "booked room" icon has been changed to not use the same as in the
new "end booking "button. Colors of the buttons have been updated.

The remaining time is now centered vertically in all display formats
(it was not always the case).

Task-3792497

Forward-Port-Of: odoo/enterprise#61300

Issue: ------ The commit[^1] filters groupby in the gantt view according to whether it is a propertie or not. However, fields of type `date` and `datetime` use `:` to refer to the granularity (example `check_in:year`). To avoid const { type } = metaData.fields[fieldName:granularity]; to trigger an error, it is therefore necessary to adapt the diff of commit[^1]. opw-3893042 [^1]: https://github.com/odoo/enterprise/commit/6ee5fe8220d692173187402a7361f77883dca921 Forward-Port-Of: odoo

Issue:
------
The commit[^1] filters groupby in the gantt view according to whether it is a propertie or not.
However, fields of type `date` and `datetime` use `:` to refer to the granularity (example `check_in:year`).
To avoid const { type } = metaData.fields[fieldName:granularity]; to trigger an error, it is therefore necessary 
to adapt the diff of commit[^1].

opw-3893042

[^1]: https://github.com/odoo/enterprise/commit/6ee5fe8220d692173187402a7361f77883dca921

Forward-Port-Of: odoo/enterprise#61522