**Description of the issue/feature this PR addresses:** As `_compute_quantities_dict` does use `stock.move` as a source of calculation we need to make sure that the dedicated owner is set also on inventory moves which was forgotten and resulted in wrongly computed quantities in the past in case of such an use case. **Current behavior before PR:** As the owner was not set properly on inventory moves, the dates in the past calculation went wrong and included those moves. **Desired beha

**Description of the issue/feature this PR addresses:**

As `_compute_quantities_dict` does use `stock.move` as a source of calculation we need to make sure that the dedicated owner is set also on inventory moves which was forgotten and resulted in wrongly computed quantities in the past in case of such an use case.


**Current behavior before PR:**
As the owner was not set properly on inventory moves, the dates in the past calculation went wrong and included those moves.

**Desired behavior after PR is merged:**
From now on only the proper moves will be taken into account.

To get this properly for instances out in the wild, it would be helpful to include a fix for the moves without the proper owner somewhere (basically align with `owner_id` of the `stock.move.line`)
Let me know where we will fix this to have again consistency in databases...

Info: @wt-io-it




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

Forward-Port-Of: odoo/odoo#149334

**Description of the issue/feature this PR addresses:** In large database, the time to unlink a sale.order (or any record with mail.thread) can be take 1 seconde. After it is so fast. @tde-banana-odoo @rco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149296 Forward-Port-Of: odoo/odoo#149166

**Description of the issue/feature this PR addresses:**
In large database, the time to unlink a sale.order (or any record with mail.thread) can be take 1 seconde.

After it is so fast.

@tde-banana-odoo @rco-odoo 




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

Forward-Port-Of: odoo/odoo#149296
Forward-Port-Of: odoo/odoo#149166

In the lead's enrichment, the fields containing tags have an hardcoded background for some reason... which, in dark mode, makes the tags' label illegible (as it is a light text on light background). This commit fixes it by forcing a darker gray when rendered in dark mode (where the dark mode's bundle is applied, like in the backend). Steps to reproduce: - Open CRM - Create an opportunity using a well-known domain in the email address (for example) - Click "Enrich" - A card appears in t

In the lead's enrichment, the fields containing tags have an hardcoded background for some reason... which, in dark mode, makes the tags' label illegible (as it is a light text on light background).

This commit fixes it by forcing a darker gray when rendered in dark mode (where the dark mode's bundle is applied, like in the backend).

Steps to reproduce:
- Open CRM
- Create an opportunity using a well-known domain in the email address (for example)
- Click "Enrich"
- A card appears in the chatter containing the matching company's information
- Switch to dark mode => Sectors, Technologies Used... tags keep the light background

opw-3678598


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

Forward-Port-Of: odoo/odoo#149409

This reverts commit 6c59eea4215e38cb1253b6172e776cf7a4978ad3. smtplib is expecting the Context of ssl found in the stdlib and the Context object of the pyOpenSSL lib isn't a drop in replacement. The various `TLS_METHOD` constants are not the same and the Context object of pyOpenSSL lack a `wrap_socket`-like method. opw-3640374 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed t

This reverts commit 6c59eea4215e38cb1253b6172e776cf7a4978ad3.

smtplib is expecting the Context of ssl found in the stdlib and the Context object of the pyOpenSSL lib isn't a drop in replacement. The various `TLS_METHOD` constants are not the same and the Context object of pyOpenSSL lack a `wrap_socket`-like method.

opw-3640374

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

This PR addresses two issues: **First Issue:** The kanban records were undraggable only when `readonly="True"` was set, but draggable for `readonly="1"`. **Solution:** The `isReadonly` in `canMoveRecords` was updated to consider both `readonly="1"` and `readonly="True"`. This change enables both attributes to control the draggability of kanban records. **Second Issue:** Users could change the mailing stage from the Kanban view, which was inappropriate since stage changes should occur

This PR addresses two issues:

**First Issue:**
The kanban records were undraggable only when `readonly="True"` was set, but draggable for `readonly="1"`.

**Solution:**
The `isReadonly` in `canMoveRecords` was updated to consider both `readonly="1"` and `readonly="True"`. This change enables both attributes to control the draggability of kanban records.

**Second Issue:**
Users could change the mailing stage from the Kanban view, which was inappropriate since stage changes should occur within the defined workflow.

**Solution:**
The state field in the Kanban view was marked as readonly, preventing unintended stage changes. Users can no longer modify the mailing stage directly from the Kanban view. Instead, stage changes should occur through the workflow.

Forward-Port-Of: odoo/odoo#140081

**Impacted versions:** master, 17.0 **Description of the issue this PR addresses:** Potential error when trying to create a new shipping address during the website checkout process. This appears to have been introduced by 24c8ff9b28e9357d00a0a41447d9898dcf42995a on #139474. **Steps to reproduce:** 1. Log in as admin user * _The error also happens while logged in as portal user, but they do not see the traceback._ 2. Go to website, add item to cart, and click "Checkout" 3. Unde

**Impacted versions:** master, 17.0

**Description of the issue this PR addresses:** Potential error when trying to create a new shipping address during the website checkout process.

This appears to have been introduced by 24c8ff9b28e9357d00a0a41447d9898dcf42995a on #139474.

**Steps to reproduce:**

1. Log in as admin user
    * _The error also happens while logged in as portal user, but they do not see the traceback._
2. Go to website, add item to cart, and click "Checkout"
3. Under the "shipping' section, click "Add address"
4. Click save and an error is raised (see traceback below and in task comments)
    * _The error also occurs if you just leave one required field as blank, rather than all fields._

**Current behavior before PR:** If logged in as an internal user, a traceback error (below) is raised. If logged in as a portal user, a 500 error page is shown.
* **Video link:** https://github.com/odoo/odoo/assets/7907616/4e103c73-417f-4d1a-93e3-8c1d7beeb918
* <details>
    <summary>Traceback error...</summary>
    
    ```
    Traceback (most recent call last):
      File "/opt/odoo/core/odoo/http.py", line 1722, in _serve_db
        return service_model.retrying(self._serve_ir_http, self.env)
      File "/opt/odoo/core/odoo/service/model.py", line 133, in retrying
        result = func()
      File "/opt/odoo/core/odoo/http.py", line 1749, in _serve_ir_http
        response = self.dispatcher.dispatch(rule.endpoint, args)
      File "/opt/odoo/core/odoo/http.py", line 1866, in dispatch
        return self.request.registry['ir.http']._dispatch(endpoint)
      File "/opt/odoo/core/addons/website/models/ir_http.py", line 235, in _dispatch
        response = super()._dispatch(endpoint)
      File "/opt/odoo/core/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
        result = endpoint(**request.params)
      File "/opt/odoo/core/odoo/http.py", line 722, in route_wrapper
        result = endpoint(self, *args, **params_ok)
      File "/opt/odoo/core/addons/website_sale/controllers/main.py", line 1346, in address
        'use_same': is_public_user or ('use_same' in kw and str2bool(kw.get('use_same'))),
      File "/opt/odoo/core/odoo/tools/misc.py", line 468, in str2bool
        raise ValueError('Use 0/1/yes/no/true/false/on/off')
    ValueError: Use 0/1/yes/no/true/false/on/off
    ```
    </details>

**Desired behavior after PR is merged:** The "add address" page is shown with a red highlight around any required fields that are missing a value.
* [image](https://github.com/odoo/odoo/assets/7907616/16fc616a-224f-4839-9b14-93e06829fadd)

Support ticket number submitted via odoo.com/help: opw-3685876. Closes #149428.

---

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

Forward-Port-Of: odoo/odoo#149432

\*: mail, pos_sale, pos_self_order, website_sale ### 1. `oi-close` adaptation Prior to this commit, `oi-close` icon was based on the default sans-serif font. Depending on this, there could be alignment and size inconsistencies with the Odoo UI icon library. This commit adapts `oi-close` to use a custom icon from the UI icon library to make it more robust and maintain consistency with this library. ### 2. Corner UI icons adaptation Prior to this commit, directional icons related to the

\*: mail, pos_sale, pos_self_order, website_sale

### 1. `oi-close` adaptation
Prior to this commit, `oi-close` icon was based on the default sans-serif font.
Depending on this, there could be alignment and size inconsistencies with the Odoo UI icon library.
This commit adapts `oi-close` to use a custom icon from the UI icon library to make it more robust and maintain consistency with this library.

### 2. Corner UI icons adaptation
Prior to this commit, directional icons related to the four corners were misaligned.
This commit adapts these four icons so that they are properly aligned.

task-3618046


| 1 | Before | After |
|--------|--------|--------|
|  | <img width="123" alt="Capture d’écran 2023-12-01 à 14 51 59" src="https://github.com/odoo/odoo/assets/80679690/f0e4f53f-9b04-4f94-8d03-8bbe34ff9a51"> |  ![Capture d’écran 2023-12-04 à 17 09 50](https://github.com/odoo/odoo/assets/80679690/cb29eb61-b45f-4603-b01b-23f8eb27d427) |
|  | ![Capture d’écran 2023-12-01 à 16 57 15](https://github.com/odoo/odoo/assets/80679690/3efbe5ad-e3e8-47d3-b336-5a1d69719fad) | ![Capture d’écran 2023-12-01 à 16 58 49](https://github.com/odoo/odoo/assets/80679690/b25de8b8-12b0-4cfa-8046-85b17d076435) |

| 2 | Before | After |
|--------|--------|--------|
| | ![Capture d’écran 2023-12-01 à 17 00 04](https://github.com/odoo/odoo/assets/80679690/fce35d33-66cc-421c-a019-52e582993dec) | ![Capture d’écran 2023-12-01 à 17 00 34](https://github.com/odoo/odoo/assets/80679690/5e917b81-cf66-4016-86b5-f3ae543645f4) | 






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

Forward-Port-Of: odoo/odoo#144598

Update the OWL lib and adapt some tests/helpers. Release notes: https://github.com/odoo/owl/releases/tag/v2.2.8 https://github.com/odoo/owl/releases/tag/v2.2.9 These releases contain small improvements 2.2.8: - [IMP] template set config: getTemplate function - [IMP] parser: .trim modifier implies .lazy modifier - [REF] parser, template_set: factor out parseXML function 2.2.9: - [IMP] reactivity: replace sets with small arrays for performance Forward-Port-Of: odoo/odoo#149379 For

Update the OWL lib and adapt some tests/helpers.

Release notes:
https://github.com/odoo/owl/releases/tag/v2.2.8
https://github.com/odoo/owl/releases/tag/v2.2.9

These releases contain small improvements
2.2.8:
- [IMP] template set config: getTemplate function
- [IMP] parser: .trim modifier implies .lazy modifier
- [REF] parser, template_set: factor out parseXML function

2.2.9:
- [IMP] reactivity: replace sets with small arrays for performance

Forward-Port-Of: odoo/odoo#149379
Forward-Port-Of: odoo/odoo#149170

Steps: - Install planning app. - Open Planning. - Click on search bar menu. Issue: - The groupBy column width is more than expected. Cause: - groupBy and filter menu size changes depending on their groupBys and filters names so giving bigger name to filters and groupBy increase their size and there was no max-width set on then and because of setting name and giving bigger string on field makes that column unexpectly big. Fix: - set max-width on `o_filter_menu` and `o_group_by_

Steps:
- Install planning app.
- Open Planning.
- Click on search bar menu.

Issue:
- The groupBy column width is more than expected.

Cause:
- groupBy and filter menu size changes depending on their
groupBys and filters names so giving bigger name to filters
and groupBy increase their size and there was no max-width
set on then and because of setting name and giving bigger
string on field makes that column unexpectly big.

Fix:
- set max-width on `o_filter_menu` and `o_group_by_menu` to
avoid unexpected bigger size for filter and groupby columns.

task-3607270

Forward-Port-Of: odoo/odoo#140412

Current behavior: When you create a sale order with an analytic account, and settle it in the POS, the analytic account is not set on the POS order invoice lines. Steps to reproduce: - Create a sale order with an analytic account (in other info tab) - Confirm the sale order - Go to the POS and settle the order - Pay and invoice the order - Go to the invoice and check the analytic account on the invoice lines Note: I based my fix on what was already done in the sale_order creation to

Current behavior:
When you create a sale order with an analytic account, and settle it in the POS, the analytic account is not set on the POS order invoice lines.

Steps to reproduce:
- Create a sale order with an analytic account (in other info tab)
- Confirm the sale order
- Go to the POS and settle the order
- Pay and invoice the order
- Go to the invoice and check the analytic account on the invoice lines

Note:
I based my fix on what was already done in the sale_order creation to set the analytic distribution correctly on the invoice lines.

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

Forward-Port-Of: odoo/odoo#147737

Commit https://github.com/odoo/odoo/commit/ceb8b785fba1055deeff8d9075ccc707f2317278 introduced a mechanism to throw an error if some address fields were empty. The mechanism was introduced to prevent us from sending `False` as an address detail to Adyen when it was not set since it might negatively affect the fraud check score. It however caused some payments not to go through because it relied on Odoo's utils to extract the house number from the address, which would fail in some circumstanc

Commit https://github.com/odoo/odoo/commit/ceb8b785fba1055deeff8d9075ccc707f2317278 introduced a mechanism to throw an error if some address fields were empty. The mechanism was introduced to prevent us from sending `False` as an address detail to Adyen when it was not set since it might negatively affect the fraud check score. 

It however caused some payments not to go through because it relied on Odoo's utils to extract the house number from the address, which would fail in some circumstances (e.g., when the number is placed before the street name). In some other cases, empty address details that were previously accepted by Adyen caused the error to be thrown.

With this commit, we now pass `Unknown` instead of `False` or empty string for the address details that are not set and that are not required by Adyen in practice, unlike what is stated in AVS documentation. This delegates the responsibility to block the payment to Adyen as the address check and the related error are removed from Odoo.

Forward-Port-Of: odoo/odoo#149225
Forward-Port-Of: odoo/odoo#147960

The YearPicker component was mistakenly broken during a fix in PR #123245 due to a lack of tests. This commit reintroduces the intended behaviour. Task: 3668916 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#148984 Forward-Port-Of: odoo/odoo#148619

The YearPicker component was mistakenly broken during a fix in PR #123245 due to a lack of tests. This commit reintroduces the intended behaviour.

Task: 3668916

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#148984
Forward-Port-Of: odoo/odoo#148619

**Steps:** - Go to the project module. - Select any project. - Click the status button on the top left in the kanban view. - It will redirect to project update kanban view. **Issue:** - The status field in the Kanban view is unexpectedly editable after navigating to the project update Kanban view. **Cause:** - The absence of the 'non-editable' attribute configuration in the project update Kanban view led to the unintended editability of the status field. **Fix:** - By implementin

**Steps:**
- Go to the project module.
- Select any project.
- Click the status button on the top left in the kanban view.
- It will redirect to project update kanban view.

**Issue:**
- The status field in the Kanban view is unexpectedly editable after navigating to the project update Kanban view.

**Cause:**
- The absence of the 'non-editable' attribute configuration in the project update Kanban view led to the unintended editability of the status field.

**Fix:**
- By implementing the 'non-editable' attribute in the Kanban view, modifications can be prevented to the status field.

**Task**-3610481

Forward-Port-Of: odoo/odoo#144336

Before this commit, the `report_invoice_wizard_preview` was rendered well in html and in the preview (settings page) but not when downloading it ; the "total" table was pushed all the way to the right. opw-3648586 Forward-Port-Of: odoo/odoo#148337

Before this commit, the `report_invoice_wizard_preview` was rendered well in html and in the preview (settings page) but not when downloading it ; the "total" table was pushed all the way to the right.

opw-3648586

Forward-Port-Of: odoo/odoo#148337

Fix done directly on Github to not have to wait for the weekly sync. Already corrected on Transifex. Forward-Port-Of: odoo/odoo#149411

Fix done directly on Github to not have to wait for the weekly sync.
Already corrected on Transifex.

Forward-Port-Of: odoo/odoo#149411

The index is needed to be able to unlink/delete lines because of the check of foreign keys. Forward-Port-Of: odoo/odoo#149417

The index is needed to be able to unlink/delete lines because of the check of foreign keys.

Forward-Port-Of: odoo/odoo#149417

To reproduce: - Install POS with demo data - Install Indian localization(l10n_in) - Open POS terminal - Click on the load demo data - Traceback thrown Fix: The issue occurs when the demo data executes the closing of the sessions. The l10n_in _post method checks for a company state that is not yet set at that point. The quick fix here is to set the state before loading the onboarding data. It is important to note that this issue only arises when loading demo data on a DB that doesn't con

To reproduce:
- Install POS with demo data
- Install Indian localization(l10n_in)
- Open POS terminal
- Click on the load demo data
- Traceback thrown

Fix:
The issue occurs when the demo data executes the closing of the sessions. The l10n_in _post method checks for a company state that is not yet set at that point. The quick fix here is to set the state before loading the onboarding data. It is important to note that this issue only arises when loading demo data on a DB that doesn't contain demo data.

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

Have company 1 (main company) and company 2 Activate Website for company 1 Switch to company 2 Setup a POS In Settings > Point of Sale, activate 'Use QR code on ticket' Open POS session Make an order, save qr link from receipt, close session Open the saved link without being logged in Complete form and request invoice Issue: Error will block the operation ``` Incompatible companies on records: - '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS

Have company 1 (main company) and company 2
Activate Website for company 1
Switch to company 2
Setup a POS
In Settings > Point of Sale, activate 'Use QR code on ticket' Open POS session
Make an order, save qr link from receipt, close session Open the saved link without being logged in
Complete form and request invoice

Issue:
Error will block the operation
```
Incompatible companies on records:
- '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) 16%' belongs to company False and 'Account' (account_id: '209.01.01 VAT carried forward not collected') belongs to another company.
- '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) 16%' belongs to company False and 'Originator Tax Distribution Line' (tax_repartition_line_id: 'account.tax.repartition.line,54') belongs to another company.
- '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) Acoustic Bloc Screens' belongs to company False and 'Account' (account_id: '401.01.01 Sales and/or services taxed at the general rate') belongs to another company.
- '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) Acoustic Bloc Screens' belongs to company False and 'Taxes' (tax_ids: '16% (MX)') belongs to another company.
- '/ (Reversal of POS closing entry POSS/2024/01/0004 for order Shop/0004 from session POS/00002) 105.01.02 105.01.02' belongs to company False and 'Account' (account_id: '105.01.02 National customers (PoS)') belongs to another company.
```
This occurs because when Website is installed, requests from public user will keep in context the id of the company associated to the website, company 1 in this case.

opw-3629683

Forward-Port-Of: odoo/odoo#149061

Steps to reproduce: - Install website_sale_loyalty module and all dependencies. - Create a promo code with amount limit, like 1000$. - Now add one product to the cart that doesn't reach the limit and try the promo code. Issue: The `get_promo_code_error()` is being calle more than once, and when we try to access the `error_promo_code` from the session, it's empty as we have deleted it in the first run. Solution: Having a template to manage and store the message directly into the

Steps to reproduce:

- Install website_sale_loyalty module and all dependencies.
- Create a promo code with amount limit, like 1000$.
- Now add one product to the cart that doesn't reach the limit and try the promo code.

Issue:

The `get_promo_code_error()` is being calle more than once, and when we try to access the `error_promo_code` from the session, it's empty as we have deleted it in the first run.

Solution:

Having a template to manage and store the message directly into the cart will avoid us to lose the message before we can display it.

opw-3262476

Forward-Port-Of: odoo/odoo#139980
Forward-Port-Of: odoo/odoo#124701

When reconciling two exchange differences that should result into a full reconciliation the wizard raise an error. Forward-Port-Of: odoo/enterprise#54112

When reconciling two exchange differences that should result into a full reconciliation the wizard raise an error.

Forward-Port-Of: odoo/enterprise#54112

Mirror of the following PR for WorldlineDriver_W: https://github.com/odoo/enterprise/pull/53951 Apart from the changes same as in the mentionned PR desribed below this PR also improves the WorldlineDriver_W. It adds some very much needed logging and smart sleep mechanics already present in the WorldlineDriver_L. It also adds a unique buffer size for all the variables used by C++ code (also already on WorldlineDriver_W). Finally it adds some comments to the C++ variables mapping to easily i

Mirror of the following PR for WorldlineDriver_W: https://github.com/odoo/enterprise/pull/53951

Apart from the changes same as in the mentionned PR desribed below this PR also improves the WorldlineDriver_W.
It adds some very much needed logging and smart sleep mechanics already present in the WorldlineDriver_L.
It also adds a unique buffer size for all the variables used by C++ code (also already on WorldlineDriver_W).
Finally it adds some comments to the C++ variables mapping to easily identify them (you guessed it, also on WorldlineDriver_W already).

The description below matches the https://github.com/odoo/enterprise/pull/53951
Currently, if you have 2 browser tabs or 2 different PoS using the same Worldline terminal, there was a way to do some damage if requests were started at the same time
1) Since we call C++ code through a thread without a mutex, it was possible to get a race condition and provoke a segmentation fault
2) Even if there was no race condition, we were not specifying to who the driver is replying all the time. So a cancel request on the 1st PoS could cancel an active transaction on the 2nd PoS.

This PR fixes both issues by specifying the owner of the request and the cid in every single response sent from the driver to the frontend.
I am also adding the cid to the data sent in a cancellation request as otherwise we don't know which transaction line we're cancelling.
It replaces the threads by a queue to avoid race conditions in the future and respect the condition that all the Driver class logic must be executed in the "run" method for safe execution.
It also fixes the Last Transaction Status popup which could accidentally "catch" the response from a transaction since it doesn't care about the cid.
This PR also makes the popup consistent with the response (using error popup for a response resulting in an error).

task-3676153

Forward-Port-Of: odoo/enterprise#54073

Let's say a `sale.subscription.report` list is inserted into a spreadsheet (e.g. in the Subscriptions dashboard). Right click on one of the list cells and click on "See record". It opens an auto-generated form view which is unusable. Ideally we would want to be redirected to the related sale order form view. That's what is done when click on a `sale.subscription.report` in the list view. It's done with `action="action_open_subscription_order"` on the list arch. Unfortunatly, we don't have suc

Let's say a `sale.subscription.report` list is inserted into a spreadsheet (e.g. in the Subscriptions dashboard). Right click on one of the list cells and click on "See record". It opens an auto-generated form view which is unusable.

Ideally we would want to be redirected to the related sale order form view. That's what is done when click on a `sale.subscription.report` in the list view. It's done with `action="action_open_subscription_order"` on the list arch. Unfortunatly, we don't have such a mechanism to overwrite the action for lists in spreadsheet.

So, in this commit, we introduce a minimal form view allowing to go the sale order, without having to find the field among the many many fields in the auto-generated form view.

Task: 3680601

Forward-Port-Of: odoo/enterprise#54183

Versions: --------- saas-16.4 Steps: --------- - Installed planning module - Open Planning - Create shift and published - copy the shift Issue: --------- When we copy the published shift, a new shift published stage is created. Cause: --------- Copy true is given in the stage field, so the stage of the new shift is copied. Fix: --------- Prevent copying the status field when duplicating shifts. task-3524295 Forward-Port-Of:

Versions:
---------
  saas-16.4

  Steps:
---------
  - Installed planning module
  - Open Planning
  - Create shift and published
  - copy the shift
    
   Issue:
---------
  When we copy the published shift, a new shift published stage is created.

Cause: 
---------  
 Copy true is given in the stage field, so the stage of the new shift is copied.
    
 Fix:
---------  
  Prevent copying the status field when duplicating shifts.
    
    
task-3524295

Forward-Port-Of: odoo/enterprise#48614

Enterprise counterpart of https://github.com/odoo/odoo/pull/148619 Task: 3668916 Forward-Port-Of: odoo/enterprise#54095 Forward-Port-Of: odoo/enterprise#53905

Enterprise counterpart of https://github.com/odoo/odoo/pull/148619

Task: 3668916

Forward-Port-Of: odoo/enterprise#54095
Forward-Port-Of: odoo/enterprise#53905

Forward-Port-Of: odoo/enterprise#54294 Forward-Port-Of: odoo/enterprise#54135

Forward-Port-Of: odoo/enterprise#54294
Forward-Port-Of: odoo/enterprise#54135

Purpose ======= Improve the appointment general UI. Specifications ============ - Automatically set the calendar event duration to the related appointment type duration when creating a calendar event and there's the appointment_type_id in the context. - Improve the gantt booking form view. - Only allow appointment admins to reorder the appointment type in the list and kanban views. - Improve the resource list and form views. - Move the Share Links menu under Reporting. - Change t

Purpose
=======
Improve the appointment general UI.

Specifications
============
- Automatically set the calendar event duration
to the related appointment type duration when
creating a calendar event and there's the
appointment_type_id in the context.
- Improve the gantt booking form view.
- Only allow appointment admins to reorder the
appointment type in the list and kanban views.
- Improve the resource list and form views.
- Move the Share Links menu under Reporting.
- Change the calendar template to prevent displaying
'OdooBot' as the sender when recieving a calendar
event invitation.
- Improve the action helper for the Invitations menu
and create an action helper for the appointment type
questions answers list view.
- Change the location placeholder and the avatars_display
description in the appointment type form view.
- Align the '+X' with the many2many element names at display.
- Removing the 'Appointment' tags from the search tags as
events generated through a type can already be found otherwise.
- Open the gantt form view instead of the gantt planning view
when creating an event by clicking on a gantt cell.
- Fix the reserved capacity field display in the gantt form view.
- Create an access rule to restrict the internal user
access to show the open appointment types or the ones
where they are staff users, with only read access.


Task-3544915

Forward-Port-Of: odoo/enterprise#49719

How to reproduce: -Insert a datasource from a standard pivot view - open the corresponding sidepanel (top menu > Data > datasource in question) - undo 2-3 times so that the datasource is no longer in the sheet -> crash Task: 3551443 Forward-Port-Of: odoo/enterprise#49866 Forward-Port-Of: odoo/enterprise#48871

How to reproduce:

-Insert a datasource from a standard pivot view

- open the corresponding sidepanel (top menu > Data > datasource in question)

- undo 2-3 times so that the datasource is no longer in the sheet

-> crash

Task: 3551443

Forward-Port-Of: odoo/enterprise#49866
Forward-Port-Of: odoo/enterprise#48871

TaskID: 3672229 Forward-Port-Of: odoo/enterprise#53800

TaskID: 3672229

Forward-Port-Of: odoo/enterprise#53800

There is a field type 'reference' whose column type is 'varchar', but as reference is not a data type; it raises the traceback: "type 'reference' does not exist". So converted that reference field type to a text data type manually, as done for selection. reference: https://github.com/odoo/odoo/blob/60a3e7f9261bbf0b26cf815133bafd7628bc4133/odoo/fields.py#L2829 opw-3633753 Forward-Port-Of: odoo/enterprise#53482

There is a field type 'reference' whose column type is 'varchar', but as reference is not a data type; it raises the traceback: "type 'reference' does not exist". So converted that reference field type to a text data type manually,
as done for selection.

reference: https://github.com/odoo/odoo/blob/60a3e7f9261bbf0b26cf815133bafd7628bc4133/odoo/fields.py#L2829

opw-3633753

Forward-Port-Of: odoo/enterprise#53482

[FIX] account_consolidation: prevent too-long account name Issue: Requesting consolidation report for consolidation name that is more than 40 characters resulted in runtime error Steps to reproduce: 1- Install consolidation app 2- create a new consolidation with a name longer than 40 characters 3- click the smart button "Consolidated Balance" Solution: Issue was that while generating the consolidation report for long name we needed to check if it is to be exported to pdf or xml or ju

[FIX] account_consolidation: prevent too-long account name

Issue: Requesting consolidation report for consolidation name that is more than 40 characters resulted in runtime error

Steps to reproduce:
1- Install consolidation app
2- create a new consolidation with a name longer than 40 characters 3- click the smart button "Consolidated Balance"

Solution:
Issue was that while generating the consolidation report for long name we needed to check if it is to be exported to pdf or xml or just a normal request and no export. This was done by checking the options dictionary but using a key named 'print_mode' this key no longer exists and has been replaced with 'export_mode'.

opw-3629651

Forward-Port-Of: odoo/enterprise#53104

How to reproduce: - select multiple documents along with a spreadsheet. - try to open the spreadsheet. - Blank preview screen appears. Technical reason: - The document which we try to open/preview is passed under the `mainDocument` key. Ref: https://github.com/odoo/enterprise/blob/16.0/documents/static/src/views/kanban/documents_kanban_model.js#L27 After this commit: We are able to open the spreadsheet. task-3508537 Forward-Port-Of: odoo/enterprise#54297 Forward-Port-Of: odoo/

How to reproduce:
- select multiple documents along with a spreadsheet.
- try to open the spreadsheet.
- Blank preview screen appears.

Technical reason:
- The document which we try to open/preview is passed under the `mainDocument` key.

Ref:
https://github.com/odoo/enterprise/blob/16.0/documents/static/src/views/kanban/documents_kanban_model.js#L27

After this commit:
We are able to open the spreadsheet.

task-3508537

Forward-Port-Of: odoo/enterprise#54297
Forward-Port-Of: odoo/enterprise#49092