Before this commit, a toaster notification would be shown in addition to the dedicated error div in the inline payment form when an exception is raised while trying to archive a payment token. Forward-Port-Of: odoo/odoo#82248

Before this commit, a toaster notification would be shown in addition to
the dedicated error div in the inline payment form when an exception is
raised while trying to archive a payment token.

Forward-Port-Of: odoo/odoo#82248

Attachments that are uploaded on a record that isn't saved yet are created with res_id set to 0. In the case of attachments linked through a m2m rather than the usual (res_model, res_id), it means they may not be readable afer the creation of the record, except by their creator. Re-attaching them to the mailing / template at the end of the create() call fixes the ownership. Fixes #81935 Forward-Port-Of: odoo/odoo#82111 Forward-Port-Of: odoo/odoo#82105

Attachments that are uploaded on a record that isn't saved yet are
created with res_id set to 0. In the case of attachments linked through
a m2m rather than the usual (res_model, res_id), it means they may not
be readable afer the creation of the record, except by their creator.

Re-attaching them to the mailing / template at the end of the create()
call fixes the ownership.

Fixes #81935

Forward-Port-Of: odoo/odoo#82111
Forward-Port-Of: odoo/odoo#82105

Step to reproduce: - Inventory > Configuration > Operations Types > Manufacturing (or any other operation type with code 'mrp_operation') - Change 'Type of Operation' to 'Receipt' (or any other but 'manufacturing') - Uncheck box field 'Use Existing Lots/Serial Numbers' - Change 'Type of Operation' back to 'Manufacturing' - Set correct value for 'Default Source Location' (type Receipt changed the value to 'Vendor', need to fix it) - Create a storable product with the route 'Manufacture' s

Step to reproduce:
- Inventory > Configuration > Operations Types > Manufacturing (or any other operation type with code 'mrp_operation')
- Change 'Type of Operation' to 'Receipt' (or any other but 'manufacturing')
- Uncheck box field 'Use Existing Lots/Serial Numbers'
- Change 'Type of Operation' back to 'Manufacturing'
- Set correct value for 'Default Source Location' (type Receipt changed the value to 'Vendor', need to fix it)

- Create a storable product with the route 'Manufacture' selected.
- Create a BoM for this product, with a component tracked by lot (Add quantity to component)
- Create a MO for the product > Confirm > Check Availability

Current Behaviour :
Quantity are reserved, but the lot_ids are not visible

Behaviour after PR :
Lot ids are shown no matter the hidden configuration of picking type

opw-2680370

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

Forward-Port-Of: odoo/odoo#82154
Forward-Port-Of: odoo/odoo#81290

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

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

Header of XML files should not be translated. Before this commit, some users may translate the XML header and get invalid XML if translating words like "encoding" Fixes odoo/odoo#82155 Forward-Port-Of: odoo/odoo#82428 Forward-Port-Of: odoo/odoo#82386

Header of XML files should not be translated.
Before this commit, some users may translate the XML header and get
invalid XML if translating words like "encoding"

Fixes odoo/odoo#82155

Forward-Port-Of: odoo/odoo#82428
Forward-Port-Of: odoo/odoo#82386

createTransactionRequests can return responses like this: ``` {'messages': {'message': [{'code': 'E00027', 'text': 'The transaction was unsuccessful.'}], 'resultCode': 'Error'}, 'transactionResponse': {'SupplementalDataQualificationIndicator': 0, 'accountNumber': 'XXXXXXXX', 'accountType': 'eCheck', 'authCode': '', 'avsResultCode': 'P',

createTransactionRequests can return responses like this:

```
{'messages': {'message': [{'code': 'E00027',
                          'text': 'The transaction was unsuccessful.'}],
             'resultCode': 'Error'},
'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
                        'accountNumber': 'XXXXXXXX',
                        'accountType': 'eCheck',
                        'authCode': '',
                        'avsResultCode': 'P',
                        'cavvResultCode': '',
                        'cvvResultCode': '',
                        'errors': [{'errorCode': '33',
                                    'errorText': 'Bill To Address is '
                                                 'required.'},
                                   {'errorCode': '33',
                                    'errorText': 'Bill To State/Province is '
                                                 'required.'}],
                        'refTransID': '',
                        'responseCode': '3',
                        'testRequest': '0',
                        'transHash': '',
                        'transHashSha2': 'xxx',
                        'transId': '0'}}
```

_make_request() threw out the detailed errors ("Bill To Address is
required" and "Bill to State/Province is required") and only returned:

```
{
  'err_code': 'E00027',
  'err_msg': 'The transaction was unsuccessful.'
}
```

which results in the following vague error on an SO:

```
  The transaction with reference SO1111/1111111 for US$ 100.00
  encountered an error (Authorize.net). Error: Authorize.Net: Received
  data with status code "3" and error code "The transaction was
  unsuccessful."
```

This commit extracts the transaction errors and appends them to
'err_msg'. After this commit the above response results in this chatter:

```
  The transaction with reference SO1111/1111111 for $ 100.00
  encountered an error (Authorize.net). Error: Authorize.Net: Received
  data with status code "3" and error code "The transaction was
  unsuccessful. Bill To Address is required. Bill To State/Province is
  required."
```
Ideally the error handling logic would be rewritten so that
_make_request() doesn't handle specific errors like this. But changing
it is too high risk in a stable release.

opw-2718318

Forward-Port-Of: odoo/odoo#82007

Description of the issue/feature this PR addresses: put/remove money in cash box do not use internal transfer account Indeed here the correct account is passed in the context https://github.com/odoo/odoo/blob/1bcbd64065c283accc705ce08aa5490dde9756b8/addons/account/wizard/pos_box.py#L37 And here the code try to read it from the vals (and so no account is found) https://github.com/odoo/odoo/blob/5169fc0c20695907228fc16737060a50e1569f8f/addons/account/models/account_bank_statement.py#L858

Description of the issue/feature this PR addresses:

put/remove money in cash box do not use internal transfer account
Indeed here the correct account is passed in the context
https://github.com/odoo/odoo/blob/1bcbd64065c283accc705ce08aa5490dde9756b8/addons/account/wizard/pos_box.py#L37

And here the code try to read it from the vals (and so no account is found)
https://github.com/odoo/odoo/blob/5169fc0c20695907228fc16737060a50e1569f8f/addons/account/models/account_bank_statement.py#L858

Note : 15 and master are also impacted

Current behavior before PR:

put/remove money in cash box use suspense account

Desired behavior after PR is merged:

put/remove money in cash box use internal transfer account


@smetl @alexis-via @PierrickBrun 

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

Forward-Port-Of: odoo/odoo#82123

Description of the issue/feature this PR addresses: account.move.line has a journal_id field that is related on move_id.journal_id. By searching on journal_id we avoid a useless join, offering more room for database query optimizations. Current behavior before PR: Desired behavior after PR is merged: @qdp-odoo this is in the same vein as #80701 and #81793 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#81797

Description of the issue/feature this PR addresses:

account.move.line has a journal_id field that is related on move_id.journal_id.
By searching on journal_id we avoid a useless join,
offering more room for database query optimizations.

Current behavior before PR:

Desired behavior after PR is merged:

@qdp-odoo this is in the same vein as #80701 and #81793


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

Forward-Port-Of: odoo/odoo#81797

In automated-AVCO configuration, buying a kit at a higher price than its cost can create inconsistencies in the accounting. To reproduce the issue: (Need account_accountant. Use demo data) 1. Create a product category PC: - Costing Method: AVCO - Inventory Valuation: Automated - Set up the Price Difference Account PDA 2. Create 3 products P_kit, P_compo01, P_compo02 - Type: Storable - Category: PC - P_compo01: - Cost: 10 - P_compo02: -

In automated-AVCO configuration, buying a kit at a higher price than its
cost can create inconsistencies in the accounting.

To reproduce the issue:
(Need account_accountant. Use demo data)
1. Create a product category PC:
    - Costing Method: AVCO
    - Inventory Valuation: Automated
    -  Set up the Price Difference Account PDA
2. Create 3 products P_kit, P_compo01, P_compo02
    - Type: Storable
    - Category: PC
    - P_compo01:
        - Cost: 10
    - P_compo02:
        - Cost: 20
3. Create a bill of materials:
    - Product: P_kit
    - Type: Kit
    - Components:
        - 1 x P_compo01
        - 1 x P_compo02
4. On P_kit's form, "Compute Price from BoM":
    - The cost should be $30
5. Create a purchase order PO with one line:
    - Product: P_kit
    - Quantity: 1
    - Unit Price: 100
6. Confirm PO and process the receipt
7. Create and Post the bill

Error: There is an error in the journal items of the bill: the value for
PDA is $85

When posting the bill, for each account move line, the module computes
the stock valuation of the associated product and the price difference.
To do so, it sums the valuation of all related outgoing stock moves and
divides by the quantity to get the value per unit, then it compares with
the unit price used on the PO's line. Here is the issue: in case of a
kit, there is one outgoing move per component while the PO's line is
linked to the kit itself.

Therefore, in the above case, it uses the outgoing moves of P_compo01
and P_compo02, adds up their value ($10 + $20 = $30) and then divides by
the total quantity (one P_compo01 and one P_compo02, thus $30 / 2 =
$15). This is the reason why it considers that the unit value of P_kit
equals $15. Then, since the unit price on the PO's line is $100, it gets
a price difference value equal to $85.

When comparing the unit value of the kit and its unit price, the unit
value should not be divided by the quantity of components ($30 should
not be divided by 2). Moreover, when buying such a kit at $100, the
surplus ($70) should be distributed among each component. However, it is
difficult to define a rule to correctly weight this distribution.
Therefore, this surplus will be considered as a price difference.

OPW-2566546

Forward-Port-Of: odoo/odoo#82409
Forward-Port-Of: odoo/odoo#82158

Currently, when importing an invoice/credit note, it is assumed that it is a vendor (bill/credit note). But it is not always the case (accounting firms for example). This is why the counterpart is now adapted based on the move_type. opw-2697984 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#82447 Forward-Port-Of: odoo/odoo#82391

Currently, when importing an invoice/credit note,
it is assumed that it is a vendor (bill/credit note).
But it is not always the case (accounting firms for example).

This is why the counterpart is now adapted based on the move_type.

opw-2697984

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

Forward-Port-Of: odoo/odoo#82447
Forward-Port-Of: odoo/odoo#82391

Before this commit, attachments in attachment box (chatter) had no left padding. Mistakenly introduced by https://github.com/odoo/odoo/pull/80060 which changes classname passing from parent component to child component with `t-attf-class`. AttachmentCard and AttachmentImage components did not `t-attf-class` not on root node, which caused the broken style that this commit fixes. Forward-Port-Of: odoo/odoo#82501

Before this commit, attachments in attachment box (chatter) had no
left padding.

Mistakenly introduced by https://github.com/odoo/odoo/pull/80060
which changes classname passing from parent component to child
component with `t-attf-class`. AttachmentCard and AttachmentImage
components did not `t-attf-class` not on root node, which caused
the broken style that this commit fixes.

Forward-Port-Of: odoo/odoo#82501

- Move extra class to field to avoid reliance on specific template. - Rename prop to be generic. - Remove extra margin-top in message view outside of thread view (bonus fix). - Move code using message view component out of message list update to break infinite loop. task-2728107 Forward-Port-Of: odoo/odoo#82186

- Move extra class to field to avoid reliance on specific template.
- Rename prop to be generic.
- Remove extra margin-top in message view outside of thread view (bonus fix).
- Move code using message view component out of message list update to break
  infinite loop.

task-2728107

Forward-Port-Of: odoo/odoo#82186

Avoid hack because of slot (as strongly suggested on the original PR it should not have used slot in the first place, but out of scope to remove it). Indeed lifecycle hooks and render overrides are both broken when using slots, and shouldUpdate always true on message is not acceptable until Owl 2. task-2728107 Forward-Port-Of: odoo/enterprise#23227

Avoid hack because of slot (as strongly suggested on the original PR it should
not have used slot in the first place, but out of scope to remove it).

Indeed lifecycle hooks and render overrides are both broken when using slots,
and shouldUpdate always true on message is not acceptable until Owl 2.

task-2728107

Forward-Port-Of: odoo/enterprise#23227

Before this commit, we could have a recursion when creating a resource and an employee because of the `from_planning` key in the context. When the user creates a resource via the form view of a `planning.slot`, by default, we want to create an employee resource. So, in the create method, we check if the `from_planning` key is in the context. If yes then we create an employee. The problem arise when the employee is created as the employee creates a mail.thread and then creates a resource. I

Before this commit, we could have a recursion when creating a resource and
an employee because of the `from_planning` key in the context. When
the user creates a resource via the form view of a `planning.slot`, by
default, we want to create an employee resource. So, in the create
method, we check if the `from_planning` key is in the context. If yes then
we create an employee. The problem arise when the employee is created as the
employee creates a mail.thread and then creates a resource. In that case, if the flow
come from planning, the context key remains and so the resource will create again the employee,
causing a recursive loop.

This commit removes the `from_planning` context key when the employee is
created in the create method in the `resource.resource` model.

Forward-Port-Of: odoo/enterprise#23329

Before this commit, when you try to open the report "Quotation/Order" in studio when there is no record, there is a server error. This commit fix it by raising a user error when he tried to open an empty report in studio. Steps to reproduce: ================== 1) Use a DB without demo data 2) install sales ad studio 3) go on sales → studio 4) click on Reports 5) try to open any reports Expected Behaviour: ================== We should raise a user error to explain what append to

Before this commit, when you try to open the report "Quotation/Order" in studio when there is no record, there is a server error.

This commit fix it by raising a user error when he tried to open an empty report in studio.

Steps to reproduce:
==================
1) Use a DB without demo data
2) install sales ad studio
3) go on sales → studio
4) click on Reports
5) try to open any reports

Expected Behaviour:
==================
We should raise a user error to explain what append to the user

Actual Behaviour:
================
There is a server error and a traceback

Forward-Port-Of: odoo/enterprise#23319

- Enable "Batch Payments" - Create two payments with same customer and select Batch Deposit as a payment method - In the view list, select the two payments, then click on Action/Create batch payment (do not validate the batch) - Create a bank statement, add a line with a label, the partner of the payments, the total amount of the payments. - Save and post the bank statement, and click on Reconcile - Remove the partner, the batch payment is proposed - Select the batch payment and validate

- Enable "Batch Payments"
- Create two payments with same customer and select Batch Deposit as a payment method
- In the view list, select the two payments, then click on Action/Create batch payment (do not validate the batch)
- Create a bank statement, add a line with a label, the partner of the payments, the total amount of the payments.
- Save and post the bank statement, and click on Reconcile
- Remove the partner, the batch payment is proposed
- Select the batch payment and validate

Even though the batch payment is reconciled, it is still in the "New" stage.
The behavior changed after
32e8b07
The widget should not propose to reconcile a draft batch payment


opw-2674851

Forward-Port-Of: odoo/enterprise#23165