[FIX] project,hr_timesheet: create projects with company-specific customer Problem --- When creating projects with a customer whose company field is set, `_check_company` raises an Error because of a mismatch with the analytic account's company (False). Steps --- (from fresh db, with demo data) 1. install `project` and `sale_management` (so that projects can be billable) 2. in the settings, create a second company, (so that contacts' 'Company' field can be set) 3. on a con

[FIX] project,hr_timesheet: create projects with company-specific customer

Problem
---
When creating projects with a customer whose company field is set,
`_check_company` raises an Error because of a mismatch with
the analytic account's company (False).

Steps
---
(from fresh db, with demo data)
1. install `project` and `sale_management` (so that projects can be
   billable)
2. in the settings, create a second company,
   (so that contacts' 'Company' field can be set)
3. on a contact, set the 'Company' field (under: Sales & Purchase > Misc)
   to the current company ('YourCompany')
4. In Setting > Project: enable 'Timesheets'
5. Try to create a new billable project with 'Timesheets' enabled
   and the customer from step 3

Fix
---
Never set the partner on the analytic account when creating a new
project.
Note that we have to modify the corresponding test.
This is acceptable because in some flows (create project with
no partner, **then** set the partner) this is what
already happens and seems to not be a problem.

opw-3865150

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

Forward-Port-Of: odoo/odoo#162961

Following #156437, the mechanism to handle negative procurements was removed as it wasn't applicable with the new push flow. This was a mistakes, as : - The old pull flow is still available, so we still need to be able to propagate a negative quantity. - Even with the new push flow, this introduced a regression as we couldn't process negative quantity PO/SO anymore. The main issue was that with the new push flow, the whole picking chain might not exist yet by the time a negative quantity pr

Following #156437, the mechanism to handle negative procurements was removed as it wasn't applicable with the new push flow. This was a mistakes, as :
- The old pull flow is still available, so we still need to be able to propagate a negative quantity.
- Even with the new push flow, this introduced a regression as we couldn't process negative quantity PO/SO anymore.

The main issue was that with the new push flow, the whole picking chain might not exist yet by the time a negative quantity procurement is generated.
Let's take the following case, in 3 step delivery
- Stock -> Packing: qty = 5, status = 'done'
- Packing -> Output: qty = 5, status = 'assigned'

Here, we have the first step that was already processed, so the move from Packing -> Output has been created, while the one from Output -> Customer isn't yet (i.e. it will be when Packing -> Output is done). That means that if we were to create a procurement of -1 qty, we'd want:
- New: Packing -> Stock: qty = 1 (move back the excess qty)
- Packing -> Output: qty = 4 (merge the quantity into the existing move)
- NO Customer -> Output move, as the delivery move hasn't yet been created.

To achieve this, in the case of negative procurements, we instead generate the whole push chain of negative move then try to merge them. Then, we remove moves that shouldn't have been created.

Note: Also restores some tests that were disabled by the pull&push refactor now that it works again :roll_eyes: 

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

Forward-Port-Of: odoo/odoo#165100

A traceback is occurig when the user creating a SO without Qutation date. To reproduce this issue:- 1) Install `Sales` 2) Enable `Sales Credit Limit` in the settings 3) Try to create a `Quotation` by removing the default `Quotation Date` and then add a `Customer` 4) A traceback occurs Error:- ``` AttributeError: 'bool' object has no attribute 'date' ``` When the user removes the `date_order` its value will be false. This leads to the traceback when the `date` is extracte

A traceback is occurig when the user creating a SO without Qutation date.

To reproduce this issue:-

1) Install `Sales`
2) Enable `Sales Credit Limit` in the settings
3) Try to create a `Quotation` by removing the default `Quotation Date`
   and then add a `Customer`
4) A traceback occurs

Error:- 
```
AttributeError: 'bool' object has no attribute 'date'
```

When the user removes the `date_order` its value will be false. 
This leads to the traceback when the `date` is extracted from `date_order`.

https://github.com/odoo/odoo/blob/16e8de01b14ddac69cd706f8f64e762406769542/addons/sale/models/sale_order.py#L385

After applying this commit will resolve this issue by taking the current date if the 'date_order' is false. This makes code more robust.

senrty-5500467446

Forward-Port-Of: odoo/odoo#170355
Forward-Port-Of: odoo/odoo#169911

### Steps to reproduce: - Enable multi-step routes in the settings - Go to Invertory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a product: - Routes: MTO + Buy route - Variants: Color > Black, White - In the purchase tab of the product create two lines with: - Vendor 1 sells the Black variant - Vendor 2 sells the White variant - Create and confirm a sale order with 2 lines: - 1 x Black variant - 1 x White variant ### Expected behavior: Two purchase order

### Steps to reproduce:
- Enable multi-step routes in the settings
- Go to Invertory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a product: - Routes: MTO + Buy route - Variants: Color > Black, White
- In the purchase tab of the product create two lines with: - Vendor 1 sells the Black variant - Vendor 2 sells the White variant
- Create and confirm a sale order with 2 lines: - 1 x Black variant - 1 x White variant

### Expected behavior:

Two purchase order should be created:

- 1 x Black variant sold by Vendor 1
- 1 x White variant sold by Vendor 2

### Current behavior:

Only one purchase order is created so that Vendor 1 as the seller of both procurements even thought vendor 2 is the only real potential seller of the white variant.

### Cause of the issue:

Running the procurements of both lines of the Sale order will trigger the `_run_buy` method which will determine the seller by "default": https://github.com/odoo/odoo/blob/3383d5bd68bfc13b7881f72e5adbb7c27a6df30e/addons/purchase_stock/models/stock_rule.py#L70-L72 using the `_prepare_sellers` method. However, it relies solely on the `seller_ids` field of the `product.template` model https://github.com/odoo/odoo/blob/3383d5bd68bfc13b7881f72e5adbb7c27a6df30e/addons/product/models/product_product.py#L633-L634 Since both variants have the same template they will therefore both be associated with the same default seller.

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

Forward-Port-Of: odoo/odoo#166970

Before this commit, `sale.order.line._compute_qty_at_date` method would compute only some `forecast_expected_date` at a time per loop. After this commit, `forecast_expected_date` is computed for all relevant moves in a single call. Given that `forecast_expected_date` has potential to be a slow computing field, we should minimize the number of times it is called. Log line stats for loading sale order S05312 | | # queries | SQL time | Odo

Before this commit, `sale.order.line._compute_qty_at_date` method would compute only some `forecast_expected_date` at a time per loop. After this commit, `forecast_expected_date` is computed for all relevant moves in a single call.

Given that `forecast_expected_date` has potential to be a slow computing field, we should minimize the number of times it is called.

Log line stats for loading sale order S05312

|                                                    | # queries | SQL time | Odoo time                  |
|------------------------------------------|---------------|---------------|-------------------------------|
| before-commit                        | 31270       | 5.577 s      | 187.606 s (timeout) |
| after-commit                           | 31114       | 4.078 s      | 10.663 s                     |
| after-commit + PR #166784 | 233            | 0.430 s      | 5.905 s                       |

The PR #166784 stats are included just to show that there is not much more to be done in this PR to improve the query count, but that is addressed in the other PR.  

(Note that the customer's database is 17.0, not 15.0 - but I figured this could be made in 15.0 and fw-ported.)

opw-3920584

Forward-Port-Of: odoo/odoo#169213
Forward-Port-Of: odoo/odoo#167085

Current behavior: --- On the website, when changing the background color to a darker color (ie: black) then starting a survey, the background color for the survey is lighter (ie: gray) Expected behavior: --- The survey colors should be the same as the website theme. Steps to reproduce: --- 1. Go to the website 2. Click on Edit > Theme 3. Change the background color to black 4. Save then go to Survey 5. Select a survey 6. Remove the background image if there is one 7. Click

Current behavior:
---
On the website, when changing the background color to 
a darker color (ie: black) then starting a survey, 
the background color for the survey is lighter (ie: gray)

Expected behavior:
---
The survey colors should be the same as the website theme.

Steps to reproduce:
---
1. Go to the website
2. Click on Edit > Theme
3. Change the background color to black
4. Save then go to Survey
5. Select a survey
6. Remove the background image if there is one
7. Click on Test
8. Survey's background color is grey

Cause of the issue:
---
Introduced by https://github.com/odoo/odoo/blob/90c6e52f15277d44cbecdd5f6a70391551fb72bd/addons/survey/static/src/scss/survey_templates_form.scss#L22 
A box-shadow is used to make a "translucent white overlay" 
Which lighten the background color if there is no image

Fix:
---
Only lighten the background if there is a background image

opw-3834397

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

Forward-Port-Of: odoo/odoo#169903
Forward-Port-Of: odoo/odoo#161942

Currently, when the VAT number of a company is displayed on the POS receipt, its label `vat_label` on `res.country` is always displayed in English, despite the rest of the receipt being in the user's language. We want to display the VAT label also in the user's language. The reason is that the retrieval of the `res.country` records is done with an empty context (removing the current lang). Passing in the current context solves that. Forward-Port-Of: odoo/odoo#170147

Currently, when the VAT number of a company is displayed on the POS receipt, its label `vat_label` on `res.country` is always displayed in English, despite the rest of the receipt being in the user's language.

We want to display the VAT label also in the user's language.

The reason is that the retrieval of the `res.country` records is done with an empty context (removing the current lang). Passing in the current context solves that.

Forward-Port-Of: odoo/odoo#170147

Before this PR, the `delete starred message updates counter` test was sometimes failing. It occurs when the message is deleted before it is loaded. This PR ensures we wait for the message to be loaded before deleting it. runbot-61305,62004 Forward-Port-Of: odoo/odoo#170473

Before this PR, the `delete starred message updates counter` test was sometimes failing. It occurs when the message is deleted before it is loaded. This PR ensures we wait for the message to be loaded before deleting it.

runbot-61305,62004

Forward-Port-Of: odoo/odoo#170473

There are some small issues when transforming a normal column into a grid item: 1) When borders are set on columns, these columns do not look good when they become grid items: - In edit mode, drop the "Text-Image" snippet. - Set the columns "Border" option to a rather big number (e.g. 50px). - Toggle the grid mode. => The layout does not look good: the grid items are too small and not placed like how they were in normal mode (toggling the grid mode is supposed to place the items as close

There are some small issues when transforming a normal column into a grid item:

1) When borders are set on columns, these columns do not look good when they become grid items:

- In edit mode, drop the "Text-Image" snippet.
- Set the columns "Border" option to a rather big number (e.g. 50px).
- Toggle the grid mode. => The layout does not look good: the grid items are too small and not placed like how they were in normal mode (toggling the grid mode is supposed to place the items as close as possible as before the toggle).
- Drop the "Steps" snippet and set a border on a column.
- Drag the column and drop it in the "Text-Image" grid dropzone. => The content of the column overflows the grid area which does not look good.

This issue happens because when computing the grid areas, the border was not taken into account, resulting in grid items being too small (-> the width/height without the borders) and not having the right position (-> the starting position of the element "inside" the borders).

2) When a column becomes a grid item, its grid area is sometimes a bit too small to contain its content, making it overflow a bit:

- Drop the "Text-Image" snippet.
- In the first column, drop the "Rating" snippet and delete all the other content.
- Toggle the grid mode. => The "Rating" snippet overflows a bit the grid item (it is easier to see when using the browser inspector).

This overflow happens because when computing the grid areas, the grid padding was not taken into account, resulting in the content overflowing if it was barely fitting or if the grid padding was really big (e.g. when dropping a normal column in a grid mode "Big Boxes" snippet).

This commit fixes these issues by taking the borders and the grid padding into account in the grid areas computation when toggling the grid mode and when converting a normal column to a grid item when drag and dropping it.

task-3970022

Forward-Port-Of: odoo/odoo#169988
Forward-Port-Of: odoo/odoo#169090

Steps to reproduce: ------------------- 1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24. 2. Post the move, the deferred entries are created 3. Set the All User Lock Date to 31/12/23 4. Reset the move to draft - The deferral moves of 2024 are deleted. - The deferral moves of 2023 are still linked to the move - The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date) 5. Post

Steps to reproduce:
-------------------
1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24.
2. Post the move, the deferred entries are created
3. Set the All User Lock Date to 31/12/23
4. Reset the move to draft

- The deferral moves of 2024 are deleted.
- The deferral moves of 2023 are still linked to the move
- The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date)

5. Post the move again

A traceback is raised because of an assert that verifies that we shouldn't regenerate deferral entries if a move already has them.

Solution:
---------
1. The generated reversal of the deferrals of 2023 should be linked to the move.
2. Now that this is done, we can remove the assert because all deferral entries will cancel out each other (i.e. the aggregation will result in no deferral entries).
3. When reverting, we will now use the accounting date instead of the first day after the lock date (if there is one)

opw-3861179

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

Forward-Port-Of: odoo/odoo#164316

Adding tests to ensure that the feature that allows to automatically confirm sale orders through partial payments work correctly. See Task - 2672713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121640

Adding tests to ensure that the feature that allows to automatically confirm sale orders through partial payments work correctly.

See
Task - 2672713


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

Forward-Port-Of: odoo/odoo#121640

This commit addresses the same issue as in https://github.com/odoo/odoo/pull/137214 which is overflowing of search bar menu items when their name is too long while also adapting some width values and make it apply to the website name column. It also adds a height value to the containers so that the bottom is no longer squished when the content overflows and finally adds tooltips for long item names which will most likely be truncated. opw-3963754 Forward-Port-Of: odoo/odoo#170046 Forward-Po

This commit addresses the same issue as in https://github.com/odoo/odoo/pull/137214 which is overflowing of search bar menu items when their name is too long while also adapting some width values and make it apply to the website
name column. It also adds a height value to the containers so that the bottom is no longer squished when the content overflows and finally adds tooltips for long item names which will most likely be truncated.

opw-3963754

Forward-Port-Of: odoo/odoo#170046
Forward-Port-Of: odoo/odoo#169655

**Current behavior:** Switching from manual to automated valuation on a product that has a negative quantity will create entries in the valuation journal with incorrect debit/credit figures. **Expected behavior:** The lines generated in this manner should look like ones created when the valuation is generated for a product that was already valuated with the automated option. **Steps to reproduce:** 1. Create a product category with the default manual valuation method, create a storable

**Current behavior:**
Switching from manual to automated valuation on a product that has a negative quantity will create entries in the valuation journal with incorrect debit/credit figures.

**Expected behavior:**
The lines generated in this manner should look like ones created when the valuation is generated for a product that was already valuated with the automated option.

**Steps to reproduce:**
1. Create a product category with the default manual valuation method, create a storable product that belongs to it

2. Sell some quantity of the new product without adding any on-hand quantity (so that the qty is negative), confirm the order and generate the invoice

3. Swap to automated valuation in the product category that was created in step 1

4. In the entries for the stock valuation journal, observe that:
     A) the stock valuation account is getting *debited* instead of credited, and

     B) the other entry generated is for the stock input account
          instead of stock output, and

     C) the debit/credit amounts should be swapped here as well

**Cause of the issue:**
The negative quantity case is not considered when we do the empty/replenish sequence on valuation method change.

**Fix:**
Add an explicit check for negative quantity in the replenish step of changing valuation method.

opw-3810779

Forward-Port-Of: odoo/odoo#169764
Forward-Port-Of: odoo/odoo#165179

## Description Upon initial loading, the kiosk attendance screen will load all employee's related data for the current company. This would also include their avatars, which are encoded in base64. By default, the images size used are the 1024px versions, requires the download of a multi MiB page content which can be quite slow for users connected that have a bad service or slow internet connection. ## Solution Reduce the size of the loaded avatar to their 256px version, which should be 8x le

## Description
Upon initial loading, the kiosk attendance screen will load all employee's related data for the current company. This would also include their avatars, which are encoded in base64. By default, the images size used are the 1024px versions, requires the download of a multi MiB page content which can be quite slow for users connected that have a bad service or slow internet connection.

## Solution
Reduce the size of the loaded avatar to their 256px version, which should be 8x less content to download than before.

## Reference
opw-3978883

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

Forward-Port-Of: odoo/odoo#170163

From the dashboard, we already know in which sequence the gaps are. By filtering the moves based on that information, we can dramatically improve the performance by not querying the whole table. On a test server queries using this condition went from 10s to 5ms. When opening the list view from the dashboard, 2 queries are run for a total of 20s (`web_search_read` and `web_read_group`) Forward-Port-Of: odoo/odoo#167382

From the dashboard, we already know in which sequence the gaps are. By filtering the moves based on that information, we can dramatically improve the performance by not querying the whole table.

On a test server queries using this condition went from 10s to 5ms. When opening the list view from the dashboard, 2 queries are run for a total of 20s (`web_search_read` and `web_read_group`)

Forward-Port-Of: odoo/odoo#167382

**Before this PR:** - Some fields are associated with groups in XML files, but they are visible even though the groups are disabled. (Recurring Revenue is not ticked in settings, i.e., the feature is not activated). - automated_probability and message_bounce fields are visible in the measure in the pipeline graph view. **After this PR:** - recurring_revenue fields in the measure will only be visible when it is ticked in settings, i.e., only when the feature is activated. -

**Before this PR:**
- Some fields are associated with groups in XML files, but they are visible 
  even though the groups are disabled. (Recurring Revenue is not ticked in 
  settings, i.e., the feature is not activated).
- automated_probability and message_bounce fields are visible in the measure 
  in the pipeline graph view.

**After this PR:**
- recurring_revenue fields in the measure will only be visible when it is ticked
  in settings, i.e., only when the feature is activated.
- automated_probability and message_bounce fields will be hidden from the 
  measure in the pipeline graph view.

Task-3810415

Forward-Port-Of: odoo/odoo#170307
Forward-Port-Of: odoo/odoo#160638

**Before this PR**: While creating the E-way bill, when sending a request with the distance set to "Zero," the government portal updates the distance based on their own database and sends it back in the response as an alert in the format " , Distance between these two pincodes is \d+, ". However, the Odoo system did not update the distance field with this value. **After this PR**: The Odoo system now correctly parses the alert from the government portal response and updates the distance fie

**Before this PR**:
While creating the E-way bill, when sending a request with the distance set to "Zero," the government portal updates the distance based on their own database and sends it back in the response as an alert in the format " , Distance between these two pincodes is \d+, ". However, the Odoo system did not update the distance field with this value.

**After this PR**:
The Odoo system now correctly parses the alert from the government portal response and updates the distance field on the E-way bill with the computed distance.

**task**-3961833

Forward-Port-Of: odoo/odoo#168419

Problem --- Since the [portal redesign](https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8), made the "Quotations to review" button in the portal an alert, it no longer makes sense to display it when there are 0 quotes to review opw-3991880 Forward-Port-Of: odoo/odoo#169481

Problem
---
Since the [portal redesign](https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8), made the "Quotations to review" button in the portal an alert, it no longer makes sense to display it when there are 0 quotes to review

opw-3991880

Forward-Port-Of: odoo/odoo#169481

### Steps to reproduce: - Create a storable product with a vendor and using the buy route. - Create a reordering rule for that product: - min: 0.0 - max: 0.0 - multiple: 5.0 - Case 1: Create an SO for 4 units - Case 2: Create an SO for 9 units ### Expected behavior: Case 1: A PO is created for 5 units. Case 2: A PO is created for 10 units. ### Current behavior: Case 1: No PO is created. Case 2: A PO is created for 5 units. ### Cause of the issue: Since saas-17.2 (commi

### Steps to reproduce:

- Create a storable product with a vendor and using the buy route.
- Create a reordering rule for that product: - min: 0.0 - max: 0.0 - multiple: 5.0
- Case 1: Create an SO for 4 units
- Case 2: Create an SO for 9 units

### Expected behavior:

Case 1: A PO is created for 5 units.
Case 2:  A PO is created for 10 units.

### Current behavior:

Case 1: No PO is created.
Case 2: A PO is created for 5 units.

### Cause of the issue:

Since saas-17.2 (commit https://github.com/odoo/odoo/commit/e5d39368ee84238081c7a6b7f116e481a83f46e7) the max quantity of orderpoints has a meaning of storing capacity. As such the remainder quantity of a procuremnt can not exceed the max quantity of the orderpoint because of these lines: https://github.com/odoo/odoo/blob/c8985212fb4c937b814aaf7fe2ddca992b01735c/addons/stock/models/stock_orderpoint.py#L287-L289
However, the max quantity of 0 is usually interpreted as "to satisfy the demand" and should not be considered as a maximal storing capacity.

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

Forward-Port-Of: odoo/odoo#168898

Introduced by 09f31597163a3251e58bb7b08939301574e1f65a Steps to reproduce: 1. Activate user's permission **"Discount on line"** 2. Configure a pricelist with _discount_policy_ as **"Show public price & discount to the customer"** and set _selectable_ `True`. 3. Configure a price rule for a given product (e.g. Storage Box) Storage box _Sales Price_ is set on 10$ and I set a price rule in 5$ so its like a 50% of discount in that product 4. Go to website shop + select configured pri

Introduced by 09f31597163a3251e58bb7b08939301574e1f65a

Steps to reproduce:
1. Activate user's permission **"Discount on line"**

2. Configure a pricelist with _discount_policy_ as **"Show public price & discount to the customer"** and set _selectable_ `True`.

3. Configure a price rule for a given product (e.g. Storage Box)

Storage box _Sales Price_ is set on 10$ and I set a price rule in 5$ so its like a 50% of discount in that product

4. Go to website shop + select configured pricelist + add to cart "Storage box" + Go to cart page

5. Apply a loyalty program (ie: discount code program type) configure as its reward's applicability on "Order".

6. Claim that discount code on cart page.

Reward product price is 1$ when it should be 2$

Forward-Port-Of: odoo/odoo#170268
Forward-Port-Of: odoo/odoo#169284

**Steps to reproduce the bug:** - Create a storable product P1: - uom = KG - tracked by lot: L1 - update the quantity to 50 kg - Create a storable product P2 with BoM: - quantity: 1 unit of P2 - Component: - 50 000 g of P1 - create a MO to produce one unit of P2 - Need 50 000 g of P1, select the lot L1 in the detailed operation **Problem:** - only 50 g of P1 is reserved intsead of 50 000g. opw-3935230 Forward-Port-Of: odoo/odoo#169892 Forward-Por

**Steps to reproduce the bug:**
- Create a storable product P1:
    - uom = KG
    - tracked by lot: L1
    - update the quantity to 50 kg

- Create a storable product P2 with BoM:
    - quantity: 1 unit of P2
    - Component:
        - 50 000 g of P1

- create a MO to produce one unit of P2
- Need 50 000 g of P1, select the lot L1 in the detailed operation

**Problem:**
- only 50 g of P1 is reserved intsead of 50 000g.

opw-3935230

Forward-Port-Of: odoo/odoo#169892
Forward-Port-Of: odoo/odoo#168055

Before this PR: When loggin into a company, it would simply add the new company in the list of the currently selected/active companies, this made it harder to use or stay in single-company mode. After this PR: Logging into a company will now switch companies if we are in single-company mode, essentially making the user stay in single-company mode. The user can still toggle companies to enter multi-company mode. *This behaviour got lost when adding the branches system in the company s

Before this PR:
When loggin into a company, it would simply add the new company in the
list of the currently selected/active companies, this made it harder
to use or stay in single-company mode.

After this PR:
Logging into a company will now switch companies if we are in single-company
mode, essentially making the user stay in single-company mode. The user
can still toggle companies to enter multi-company mode.

*This behaviour got lost when adding the branches system in the company service.*

Task ID: 3927141

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

Forward-Port-Of: odoo/odoo#170033
Forward-Port-Of: odoo/odoo#165227

Since 17.0, the account_token field is limited to 43 characters But some database created before that version might still have some `iap.account` records with token longer than 34 characters. If the neutralization script tries to add `+disabled` (9 characters) to such records, it fails. This prevents the creation of duplicates on the SaaS and PaaS until the invalid records are purged for the database, which is not really obvious if you don't already know the details of the implementatio

Since 17.0, the account_token field is limited to 43 characters
But some database created before that version might still have some
`iap.account` records with token longer than 34 characters.

If the neutralization script tries to add `+disabled` (9 characters)
to such records, it fails. This prevents the creation of duplicates on
the SaaS and PaaS until the invalid records are purged for the database,
which is not really obvious if you don't already know the details of the
implementation of the `iap.account` model.

With this commit, the neutralization script will only try to retain the
original value of the token (with `+disabled` appended) if it is going
to succeed, and falls back to a dummy value in other cases.

opw-3999439

Forward-Port-Of: odoo/odoo#170004

Adapt [werkzeug version for Ubuntu Noble](https://packages.ubuntu.com/noble/python3-werkzeug) mainly to avoid deprecation warnings in python 3.12. While at it, adapt for Bookworm as it provides [python 3.11](https://packages.debian.org/bookworm/python3). Forward-Port-Of: odoo/odoo#170311

Adapt [werkzeug version for Ubuntu Noble](https://packages.ubuntu.com/noble/python3-werkzeug) mainly to avoid deprecation warnings in python 3.12.

While at it, adapt for Bookworm as it provides [python 3.11](https://packages.debian.org/bookworm/python3).

Forward-Port-Of: odoo/odoo#170311

Before this PR, searching for a partner using a mention ("@") could take up to 18 seconds on a channel with 200 members. As a result, the UI would freeze while waiting for the search function to return partners to display. After this PR, trying to mention a partner on the same channel only takes 80ms. Most of the time was consumed by the `sortPartnerSuggestions` function, specifically by the `discuss.members` compare function that looped over every channel member twice per comparison. T

Before this PR, searching for a partner using a mention ("@") could take up to 18 seconds on a channel with 200 members. As a result, the UI would freeze while waiting for the search function to return partners to display.

After this PR, trying to mention a partner on the same channel only takes 80ms.

Most of the time was consumed by the `sortPartnerSuggestions` function, specifically by the `discuss.members` compare function that looped over every channel member twice per comparison.

The rest of the time was consumed by owl's `reactive` (~1/3 of the time).

To solve this issue, this PR focuses on two points:
- Providing a set of member partner IDs to the compare functions to speed up membership tests.
- Removing unnecessary reactive callbacks by using `toRaw` (searching partners is not coupled to rendering).

Forward-Port-Of: odoo/odoo#170314

Current behavior before PR: - Cannot select projects with `company_id` = `False` when creating sale orders.  Desired behavior after PR is merged: - Allow to select projects with `company_id` = `False`.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port

Current behavior before PR:
- Cannot select projects with `company_id` = `False` when creating sale orders.
![image](https://github.com/odoo/odoo/assets/45560757/2981d705-4a8b-4b3a-b16f-87e5f3cd6282)

Desired behavior after PR is merged:
- Allow to select projects with `company_id` = `False`.
![image](https://github.com/odoo/odoo/assets/45560757/ebeaa02d-fc4c-4939-9fb5-848cdd2de18e)


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

Forward-Port-Of: odoo/odoo#167403
Forward-Port-Of: odoo/odoo#167144

In Point of Sale > Configuration > Settings enable 'Global Discounts' Create a tax [TAX A] included in price Create a tax [TAX G] as group of taxes, including only [TAX A] Configure a product [PROD] with [TAX G] Open POS session Add [PROD], hit 'Discount' button, add 50% discount Issue: Tax will not be included in the discount This occurs because the system does not take into account the tax group opw-3576452 Forward-Port-Of: odoo/odoo#169996 Forward-Port-Of: odoo/odoo#146337

In Point of Sale > Configuration > Settings enable 'Global Discounts' 
Create a tax [TAX A] included in price
Create a tax [TAX G] as group of taxes, including only [TAX A] 
Configure a product [PROD] with [TAX G]
Open POS session
Add [PROD], hit 'Discount' button, add 50% discount

Issue: Tax will not be included in the discount
This occurs because the system does not take into account the tax group

opw-3576452

Forward-Port-Of: odoo/odoo#169996
Forward-Port-Of: odoo/odoo#146337

- In Odoo v16 and above, the Place of Supply information was not displayed on the invoice report, unlike in previous versions. - This PR rectifies the issue, ensuring that the Place of Supply is correctly printed on the invoice report, maintaining consistency with earlier versions. **task**:3983822 Forward-Port-Of: odoo/odoo#170221 Forward-Port-Of: odoo/odoo#169202

- In Odoo v16 and above, the Place of Supply information was not displayed on the invoice report, unlike in previous versions.

- This PR rectifies the issue, ensuring that the Place of Supply is correctly printed on the invoice report, maintaining 
consistency with earlier versions.

**task**:3983822

Forward-Port-Of: odoo/odoo#170221
Forward-Port-Of: odoo/odoo#169202

After [this commit], when we allowed credit card accounts on bank journals, we changed the domain of the manual bank reconciliation widget to also make credit card accounts not selectable anymore. However, people are currently reconciling their bank journal entries with a credit card account, which is not possible anymore after this change. This commit fixes that by only preventing to reconcile with the same account as the one set on the journal. [this commit]: https://github.com/odoo/e

After [this commit], when we allowed credit card accounts on bank journals, we changed the domain of the manual bank reconciliation widget to also make credit card accounts not selectable anymore.

However, people are currently reconciling their bank journal entries with a credit card account, which is not possible anymore after this change.

This commit fixes that by only preventing to reconcile with the same account as the one set on the journal.

[this commit]: https://github.com/odoo/enterprise/commit/4f84a260e515cc5d52d7aa2d9ba0dca7d77a101c

Forward-Port-Of: odoo/enterprise#65176
Forward-Port-Of: odoo/enterprise#64877

When trying to create a custom slot of 15min in the calendar, two slots were created. This was because the fullcalendar library was detecting two events: a date selection and a date click. The date selection is correct but the size of the event (15 min) is the minimal size which execute a click using the default time. To prevent this behaviour, we use preventDefault to ignore the second event and so the creation of the second slot. task-3976122 Forward-Port-Of: odoo/enterprise#64000

When trying to create a custom slot of 15min in the calendar, two slots were created.
This was because the fullcalendar library was detecting two events: a date selection and a date click.

The date selection is correct but the size of the event (15 min) is the minimal size which execute a click using the default time.

To prevent this behaviour, we use preventDefault to ignore the second event and so the creation of the second slot.

task-3976122

Forward-Port-Of: odoo/enterprise#64000

Adapt the tests to match the changes done community-side to properly handle negative procurements. Community PR: odoo/odoo#165100 Forward-Port-Of: odoo/enterprise#64575

Adapt the tests to match the changes done community-side to properly handle negative procurements.

Community PR: odoo/odoo#165100

Forward-Port-Of: odoo/enterprise#64575

Steps to reproduce: ------------------- 1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24. 2. Post the move, the deferred entries are created 3. Set the All User Lock Date to 31/12/23 4. Reset the move to draft - The deferral moves of 2024 are deleted. - The deferral moves of 2023 are still linked to the move - The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date) 5. Post

Steps to reproduce:
-------------------
1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24.
2. Post the move, the deferred entries are created
3. Set the All User Lock Date to 31/12/23
4. Reset the move to draft

- The deferral moves of 2024 are deleted.
- The deferral moves of 2023 are still linked to the move
- The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date)

5. Post the move again

A traceback is raised because of an assert that verifies that we shouldn't regenerate deferral entries if a move already has them.

Solution:
---------
1. The generated reversal of the deferrals of 2023 should be linked to the move.
2. Now that this is done, we can remove the assert because all deferral entries will cancel out each other (i.e. the aggregation will result in no deferral entries).
3. When reverting, we will now use the accounting date instead of the first day after the lock date (if there is one)

opw-3861179

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

Forward-Port-Of: odoo/enterprise#61928

When settling a sale order with recurring product, the qty invoiced is not correctly update on the sale order. Steps to reproduce: ------------------- * Install Point of Sale and Sale Subscription * Create a recurring product A * Create a sale order with the product A and select any subscription plan * Open a PoS session, settle the order, validate it and invoice it * Go back to the sale order > Observation: The invoiced quantity is still 0 Why the fix: ------------ Before this fi

When settling a sale order with recurring product, the qty invoiced is not correctly update on the sale order.

Steps to reproduce:
-------------------
* Install Point of Sale and Sale Subscription
* Create a recurring product A
* Create a sale order with the product A and select any subscription plan
* Open a PoS session, settle the order, validate it and invoice it
* Go back to the sale order
> Observation: The invoiced quantity is still 0

Why the fix:
------------
Before this fix the `_get_subscription_qty_invoiced` method was not considering the pos_order_lines linked to the order_lines. It was happening because here https://github.com/odoo/enterprise/blob/77c76fecda9b63e2fc17431a4cd3623650f93724/sale_subscription/models/sale_order_line.py#L189-L196 The order lines with recurring product where not considered in the normal invoiced quantity computation.

opw-3992577

Forward-Port-Of: odoo/enterprise#64891

In fc84a6e a fix was added to prevent deleting EDI documents as they're sent to the government. This is not the case for vendor bills and vendor bill refunds. This commit allows the deletion of the documents for those move types. task-3999152 Forward-Port-Of: odoo/enterprise#64974

In fc84a6e a fix was added to prevent deleting EDI documents as they're sent to the government. This is not the case for vendor bills and vendor bill refunds. This commit allows the deletion of the documents for those move types.

task-3999152

Forward-Port-Of: odoo/enterprise#64974

Forward-Port-Of: odoo/enterprise#64863

Forward-Port-Of: odoo/enterprise#64863

In 17.0, a protection was added to the 281.50 tags on the partners (commit: 09439b46cbb8b6ef2447d67e1647cbc284d0e192). The code was forward ported but the function `user_has_groups` has been removed in saas-17.2 (in https://github.com/odoo/odoo/commit/cb31d4352c741a5f8a927a65debb8e027e87df22), causing a traceback. In this commit, we rather use the `has_group` function. task-3955109 Forward-Port-Of: odoo/enterprise#64971

In 17.0, a protection was added to the 281.50 tags on the partners (commit: 09439b46cbb8b6ef2447d67e1647cbc284d0e192).

The code was forward ported but the function `user_has_groups` has been removed in saas-17.2 (in https://github.com/odoo/odoo/commit/cb31d4352c741a5f8a927a65debb8e027e87df22), causing a traceback. In this commit, we rather use the `has_group` function.

task-3955109

Forward-Port-Of: odoo/enterprise#64971

**Before this PR:** Some fields are associated with groups in XML files, but they are visible even though the groups are disabled. (Recurring Revenue is not ticked in settings, i.e., the feature is not activated). **After this PR:** recurring_revenue fields in the measure will only be visible when it is ticked in settings, i.e., only when the feature is activated. Task-3810415 Forward-Port-Of: odoo/enterprise#65186 Forward-Port-Of: odoo/enterprise#60228

**Before this PR:**
Some fields are associated with groups in XML files, but they are visible even though the groups are disabled. (Recurring Revenue is not ticked in settings, i.e., the feature is not activated).

**After this PR:**
recurring_revenue fields in the measure will only be visible when it is ticked in settings, i.e., only when the feature is activated.

Task-3810415

Forward-Port-Of: odoo/enterprise#65186
Forward-Port-Of: odoo/enterprise#60228

Before, the end date of salary attachment was computed using today's date as a starting point. It really should be the salary attachment's starting date. Also, this will add a computed field to see the duration of the attachment. Task: 3947494 Forward-Port-Of: odoo/enterprise#63361

Before, the end date of salary attachment was computed using today's date as a starting point. It really should be the salary attachment's starting date. Also,
 this will add a computed field to see the duration of the attachment.

Task: 3947494

Forward-Port-Of: odoo/enterprise#63361

Currently when we look at lunch times, we do not take leaves into account, resulting in lunch-time being computed when you have public holidays or time off Forward-Port-Of: odoo/enterprise#64916

Currently when we look at lunch times, we do not take leaves into account, resulting in lunch-time being computed when you have public holidays or time off

Forward-Port-Of: odoo/enterprise#64916

Purpose ======= Fix the modal buttons which were badly displayed on mobile. Happening on the appointment type "Share" modal and the appointment type on-boarding step 2 "Preview" button modal. Specification ============= Usual modal buttons are direct children of the footer tag. However in these 2 cases, we're using a custom widget to add a modal button. The widgets are encapsulated into a "o_widget" div which messes up the button display. Restoring a good display for these widgets button

Purpose
=======
Fix the modal buttons which were badly displayed on mobile. Happening on the appointment type "Share" modal and the appointment type on-boarding step 2 "Preview" button modal.

Specification
=============
Usual modal buttons are direct children of the footer tag. However in these 2 cases, we're using a custom widget to add a modal button. The widgets are encapsulated into a "o_widget" div which messes up the button display.
Restoring a good display for these widgets buttons by making them take all the available space on mobile view and only the necessary space on higher screen sizes.

Task-3981072

Forward-Port-Of: odoo/enterprise#64924
Forward-Port-Of: odoo/enterprise#64235

To reproduce: - Create an asset linear yearly. - Reevaluate it next month, while decreasing the residual amount. => The amounts don't make sense, the decrease move has been deleted. Idem for the move before the reeval. The issue is that we delete all the moves that are draft. But if a move (like the decrease move) is created after the current day, it is in auto-post, and so, in draft. To correct that, we prevent their deletion and give the correct residual amount (it is a

To reproduce:
- Create an asset linear yearly.
- Reevaluate it next month, while decreasing the residual amount. 

=> The amounts don't make sense, the decrease move has been deleted.
     Idem for the move before the reeval.

The issue is that we delete all the moves that are draft. 
But if a move (like the decrease move) is created after the current day, 
it is in auto-post, and so, in draft.

To correct that, we prevent their deletion and give the correct residual amount 
(it is a computed non-stored field, so it has been given as an argument to the method).Another issue was found, related to already depreciated assets.
Create an asset with 10000 as original value, 4000 as Import amount
and 6000 as salvage value.
Confirm it (no moves should be created)
Sell or dispose it.

=> It creates a move before disposal while there shouldn't be any

The issue was that reevaluation didn't work with already depreciated assets and with no moves before the reevaluation.

opw-3945341

task-3444716

Forward-Port-Of: odoo/enterprise#65143
Forward-Port-Of: odoo/enterprise#62982

During an upgrade, if the user has used the record and modified its type, it will [trigger](https://github.com/odoo/odoo/blob/17.0/addons/stock/models/product.py#L890) the `UserError`: `You can not change the type of a product that was already used.` Forward-Port-Of: odoo/enterprise#64757

During an upgrade, if the user has used the record and modified its type, it will [trigger](https://github.com/odoo/odoo/blob/17.0/addons/stock/models/product.py#L890) the `UserError`:
 `You can not change the type of a product that was already used.`

Forward-Port-Of: odoo/enterprise#64757

"Switch audio input" test failed in an undeterminitic manner on this line: https://github.com/odoo/enterprise/blob/e808e583e9d406735a05dab42bf24f8b89899b67/voip/static/tests/softphone/device_selection_dialog.test.js#L54 After clicking the "Call" button, func `makeCall` has asynchronous call before setTimeout: https://github.com/odoo/enterprise/blob/e808e583e9d406735a05dab42bf24f8b89899b67/voip/static/src/core/user_agent_service.js#L268 https://github.com/odoo/enterprise/blob/e808e583e9d406735a

"Switch audio input" test failed in an undeterminitic manner on this line:
https://github.com/odoo/enterprise/blob/e808e583e9d406735a05dab42bf24f8b89899b67/voip/static/tests/softphone/device_selection_dialog.test.js#L54 After clicking the "Call" button, func `makeCall` has asynchronous call before setTimeout:
https://github.com/odoo/enterprise/blob/e808e583e9d406735a05dab42bf24f8b89899b67/voip/static/src/core/user_agent_service.js#L268 https://github.com/odoo/enterprise/blob/e808e583e9d406735a05dab42bf24f8b89899b67/voip/static/src/core/user_agent_service.js#L284 It may happen that because of the asynchronous call, our `advanceTime(5000)` is executed before we call `setTimeout` in `makeCall`. To avoid this, we check the dom change to make sure the asynchronous call has finished before we continue.

Forward-Port-Of: odoo/enterprise#64908

Add the studio.approval.rule models in the default models to studio export. Task-3748219 Forward-Port-Of: odoo/enterprise#57038

Add the studio.approval.rule models in the default models to studio export.

Task-3748219

Forward-Port-Of: odoo/enterprise#57038