Users now see the correct message when they do not have enough credits for Bill Digitalization, instead of a generic client error. This helps staff understand the issue immediately and take action, such as buying more credits, without unnecessary troubleshooting.

Before the fix:
When we don't have enough credits for Bill Digitalization,
try to scan expense from expense app (or upload bill from billing).
Instead of getting 'Not enough credits for Bill Digitalization',
we are getting 'Odoo Client Error'.

That is because messageIsHtml is no more prop to component 'Notification'.

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

Current behaviour: - Time in pivot view of report in attendance is in decimal hours (e.g. 90 minutes is noted as 1.5 instead of 1:30) Behaviour after PR: - Time is noted in proper time manner opw-2752651 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#84554

Current behaviour:
- Time in pivot view of report in attendance is in decimal hours
(e.g. 90 minutes is noted as 1.5 instead of 1:30)

Behaviour after PR:
- Time is noted in proper time manner

opw-2752651

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

Forward-Port-Of: odoo/odoo#84554

`ab_testing_schedule_datetime` is not a required field, hence it may not be set. There is a scenario where `ab_testing_winner_selection='manual'` and `ab_testing_schedule_datetime=False`, then the code will fail on trying to get the date: `<t t-out="mailing.ab_testing_schedule_datetime.strftime('%b %d, %Y')"/>` specifically, on trying to call `strftime('%b %d, %Y')` on a boolean (`False`) object. https://github.com/odoo/upgrade/pull/2993 https://github.com/odoo/upgrade/pull/3062 For

`ab_testing_schedule_datetime` is not a required field, hence it may not be set. 

There is a scenario where `ab_testing_winner_selection='manual'` and `ab_testing_schedule_datetime=False`, then the code will fail on trying to get the date:
`<t t-out="mailing.ab_testing_schedule_datetime.strftime('%b %d, %Y')"/>`

specifically, on trying to call `strftime('%b %d, %Y')` on a boolean (`False`) object.

https://github.com/odoo/upgrade/pull/2993
https://github.com/odoo/upgrade/pull/3062

Forward-Port-Of: odoo/odoo#84602
Forward-Port-Of: odoo/odoo#80764

The original task is task-2701097 at https://github.com/odoo/odoo/pull/80852 **Some small changes:** The `merchantId` field is added in order to pass the form validation checks The tx orm cache needs to be invalidated in order to pass the tests for some reason Other than that, the diff is as close as possible to the original v13 code opw-2627875 Forward-Port-Of: odoo/odoo#84117 Forward-Port-Of: odoo/odoo#83923

The original task is task-2701097 at https://github.com/odoo/odoo/pull/80852

**Some small changes:**
The `merchantId` field is added in order to pass the form validation checks
The tx orm cache needs to be invalidated in order to pass the tests for some reason
Other than that, the diff is as close as possible to the original v13 code

opw-2627875

Forward-Port-Of: odoo/odoo#84117
Forward-Port-Of: odoo/odoo#83923

Documentation structure was modified to point out to a new subtree: content/applications/general/email_communication/email_server Related task:2619564 Documentation PR:1092 Forward-Port-Of: odoo/odoo#84548 Forward-Port-Of: odoo/odoo#84516

Documentation structure was modified to point out to a new subtree:
    content/applications/general/email_communication/email_server

Related task:2619564
Documentation PR:1092

Forward-Port-Of: odoo/odoo#84548
Forward-Port-Of: odoo/odoo#84516

Sign the corporate CLA Forward-Port-Of: odoo/odoo#84148

Sign the corporate CLA

Forward-Port-Of: odoo/odoo#84148

I want to customize the value when creating the stock move but with the old code I can't do it. So, I add you a hook method. Look it will be more professional and good for developer -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#83490 Forward-Port-Of: odoo/odoo#83394

I want to customize the value when creating the stock move but with the old code I can't do it.
So, I add you a hook method. Look it will be more professional and good for developer




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

Forward-Port-Of: odoo/odoo#83490
Forward-Port-Of: odoo/odoo#83394

When a quant is creating, for instance thanks to an internal transfer, some of these computed fields will have an incorrect value To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Create a storable product P 3. Update P's quantity: 100 P in WH/Stock 4. Process an internal transfer - From: WH/Stock - To: WH/Stock/Shelf 1 - Operations: 10 x P 5. Consult the on hand quantities of P Error: There is a new line with 10 x P in WH/Stock/Shelf 1, which is c

When a quant is creating, for instance thanks to an internal transfer,
some of these computed fields will have an incorrect value

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update P's quantity: 100 P in WH/Stock
4. Process an internal transfer
    - From: WH/Stock
    - To: WH/Stock/Shelf 1
    - Operations: 10 x P
5. Consult the on hand quantities of P

Error: There is a new line with 10 x P in WH/Stock/Shelf 1, which is
correct. However, the Counted Quantity field is defined and equal to 0,
and so does the Difference field with a value of -10. These two fields
should not be shown.

When validating the internal transfer, a new quant is created for the
location "Shelf 1". However, there isn't any value for the field
`inventory_quantity_set`. Therefore, at the end of the transfer
validation process, when the `flush` method is called, since
`inventory_quantity_set` is a computed field, its  `compute` method is
called and define the value to `True`:
https://github.com/odoo/odoo/blob/8b155b695823dfa954464ad0d5dd07445ece2471/addons/stock/models/stock_quant.py#L134-L136
This explains why, on front-end, the Counted Quantity and Difference
fields are displayed.

OPW-2733937

Forward-Port-Of: odoo/odoo#84652
Forward-Port-Of: odoo/odoo#83942

…decimal places while we compute stock_quants. upg:- 6588 Description of the issue/feature this PR addresses: To avoid On hand negative quantity, since there was no proper methodology used to handle the case, it was rounding it up to the very next highest number. Hence, that was creating the discrepancy for the data of the database in order to bypass that I have used the proper function to resolve it. If there is no raw material set in MRP, then we can assign it to the kit. Thi

…decimal places while we compute stock_quants.

upg:- 6588

Description of the issue/feature this PR addresses:

To avoid On hand negative quantity, since there was no proper methodology used to handle the case, it was rounding it up to the very next highest number.

Hence, that was creating the discrepancy for the data of the database in order to bypass that I have used the proper function to resolve it.

If there is no raw material set in MRP, then we can assign it to the kit.

This results in negative quantity and if quantity comes in negative, then this issue can occur in standard script.

So here we are using the float_round method to make quantity with the same decimal places while we compute stock_quants.

Current behavior before PR:

When we have related inventory_quantity of stock_quants quantity like -384.00000000000006 then it will set its rounding in qty_available of product in floats like  -385.00000000000006. This is causing the problem. 

For example:-
Here for this product
min(-384.00000000000006, 5311) // 1
min(-384.00000000000006, 5311)  = -384.00000000000006
but when we do "// 1"
then
min(-384.00000000000006, 5311) // 1 =  -385.00000000000006

The same issue gets generated on runbot also:- https://drive.google.com/file/d/1-MOGHwWE-NuFVgOVK9BrANoT2Nh-sT_Z/view

When the decimal accuracy for the product UOM is set at 5, then only this issue gets generated.

Desired behavior after PR is merged:

The value of related inventory_quantity of stock_quants quantity and qty_available of the product will be equal.


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

Forward-Port-Of: odoo/odoo#84689
Forward-Port-Of: odoo/odoo#70261

When performing a picking with a package, the source location of the package level may become incorrect To reproduce the issue: (Use demo data) 1. In Settings, enable: - Packages - Storage Locations 2. In Operations Types, edit "Internal Transfers": - Enable "Move Entire Packages" 3. Create a storable product P 4. Create a receipt R with for P 5. Put 10 P in pack and validate R - Let be PK the package generated/used 6. Process an internal transfer with PK - Th

When performing a picking with a package, the source location of the
package level may become incorrect

To reproduce the issue:
(Use demo data)
1. In Settings, enable:
    - Packages
    - Storage Locations
2. In Operations Types, edit "Internal Transfers":
    - Enable "Move Entire Packages"
3. Create a storable product P
4. Create a receipt R with for P
5. Put 10 P in pack and validate R
    - Let be PK the package generated/used
6. Process an internal transfer with PK
    - The destination location of the package level is WH/Stock/Shelf 1

Error: Once the picking is validated, the source location of the package
level is "WH/Stock/Shelf 1". This is not true, it should still be
"WH/Stock"

The compute method is incorrect. It uses the package location to define
the source location of the package level. However, once the picking is
processed, this package has moved so using its location to define the
source location doesn't make sense anymore.

OPW-2754179

Forward-Port-Of: odoo/odoo#84637

[REV] account: commit d22cd5473326b3b5af4ae44b0d121349a1a90850 d22cd5473326b3b5af4ae44b0d121349a1a90850 introduced the fact that when doing a full refund of an invoice, the same account was used as on the original invoice, instead of the one on the tax refund repartition lines, though the tags were still the refund ones. This is wrong. Also, it restored an inconsistent data setup in a test, while the current version was actually correct. [FIX] account: don't map repartition lines on

[REV] account: commit d22cd5473326b3b5af4ae44b0d121349a1a90850 

d22cd5473326b3b5af4ae44b0d121349a1a90850 introduced the fact that when doing a full refund of an invoice, the same account was used as on the original invoice, instead of the one on the tax refund repartition lines, though the tags were still the refund ones. This is wrong.

Also, it restored an inconsistent data setup in a test, while the current version was actually correct.


[FIX] account: don't map repartition lines on cash basis reversal 

To reproduce the issue:
    - create a cash basis tax, with different account and tags for invoice and refund
    - make an customer invoice using this tax, post it, and register a full payment for it
    - unreconcile the payment

=> Two cash basis moves have been generated: one for the initial reconciliation, and another one reverting it when the reconciliation got cancelled.

=> Bug: the reverse move uses the refund repartition, while the original one is using the invoice's one, so they don't sum up to zero. It's wrong: since the reconciliation got cancelled, we want the impact of the invoice on our tax report to be 0 again, just as if it was brand new.

Forward-Port-Of: odoo/odoo#84448
Forward-Port-Of: odoo/odoo#83837

Before this commit, during edit mode, the user was able to interact with form elements. It was somehow prevented by some JS code by losing the focus immediatly but it was not enough: if typing quickly the user was able to type text. But the real problem was the user seeing the input focused for half a second then not anymore, making him think a bug occured. Worse, the datepickers of the form snippet were able to be used entirely during edit mode, making the user think it is possible to co

Before this commit, during edit mode, the user was able to interact with
form elements. It was somehow prevented by some JS code by losing the
focus immediatly but it was not enough: if typing quickly the user was
able to type text. But the real problem was the user seeing the input
focused for half a second then not anymore, making him think a bug
occured. Worse, the datepickers of the form snippet were able to be used
entirely during edit mode, making the user think it is possible to
configure a default value (which is not true in 13.0). In following
versions, the bug is indeed worse as it messes up with the default
values configuration.

This commit fixes that via CSS, still allowing a click on the elements
to be considered as a click on the parent, but preventing to focus our
snippet inputs (this fix is limited to our own snippets as stable fix).
Note: the JS code which prevents the focus right now was not found (if
it even exists...) but it would not be ok to remove it in stable anyway.
More investigation and review will be done once this reaches master.

task-2523496

Forward-Port-Of: odoo/odoo#84589
Forward-Port-Of: odoo/odoo#84237

[FIX] web_editor: name instead of "Snippet" as label for t-install apps Issue: Since the refactoring done on ir.qweb https://github.com/odoo/odoo/commit/e830953570d5f28aee9bdcdf97af18d3e3246030, directions are more autonomous, so `t-att`, `t-options`... are no longer evaluated by other directives. These directives are also ordered. Therefore, when directives such as ``t-snippet``, ``t-install``... are called, the attributes have already been consumed (``string`` attributes is removed, be

[FIX] web_editor: name instead of "Snippet" as label for t-install apps

Issue: Since the refactoring done on ir.qweb https://github.com/odoo/odoo/commit/e830953570d5f28aee9bdcdf97af18d3e3246030,
directions are more autonomous, so `t-att`, `t-options`... are no longer
evaluated by other directives. These directives are also ordered.
Therefore, when directives such as ``t-snippet``, ``t-install``... are
called, the attributes have already been consumed (``string`` attributes
is removed, because at the end of the compilation tags should no longer
have attributes, `t-att` remove all statics attributes).
There are then two solutions, the first is to change the order, the other
is to follow the generated code (using the generated values).

task-2762377

Forward-Port-Of: odoo/odoo#84549

Based on the feedback from a partner, there is a duplicate label in th annual tax report (the field itself is correct). In Appendix E there are two fields that have label 119 but one of them should be 117. Forward-Port-Of: odoo/enterprise#24333

Based on the feedback from a partner, there is a duplicate label in th annual tax report (the field itself is correct).
In Appendix E there are two fields that have label 119 but one of them should be 117.

Forward-Port-Of: odoo/enterprise#24333

[FIX] documents_spreadsheet: Avoid double cache creation at loading time The absence of the computedDomain on the pivot was resulting in an extra refresh of the cache at startup. [FIX] documents_spreadsheet: preserve domain on queries to order values When asking the server for ordered values on the model of the pivot, we would ignore the original domain of the pivot, which could make some queries explode (i.e. search every lead of type 'lead' or 'opportunity' on a database with millio

[FIX] documents_spreadsheet: Avoid double cache creation at loading time

The absence of the computedDomain on the pivot was resulting in an extra
refresh of the cache at startup.

[FIX] documents_spreadsheet: preserve domain on queries to order values
When asking the server for ordered values on the model of the pivot, we
would ignore the original domain of the pivot, which could make some
queries explode (i.e. search every lead of type 'lead' or 'opportunity'
on a database with millions of records) and fail over a MemoryError.

This commit ensures that we preserve the original domain of the pivot.

task 2752189

Co-authored-by: Lucas Lefèvre <lul@odoo.com>
Co-authored-by: Alexis lacroix <laa@odoo.com>

Forward-Port-Of: odoo/enterprise#24413
Forward-Port-Of: odoo/enterprise#23923

Snapshot revisions are saved as stringified python dict instead of json. Property names are enclosed with single quotes instead of double quotes: `{'type': 'SNAPSHOT_CREATED', 'version': 1}` It can't be parsed as json like every other revision See odoo/upgrade@d50888b This will only affect future snapshot revisions but it's not really a problem since existing ones are archived. Maybe we could "fix" those existing revisions with a future migration script. Forward-Port-Of: odoo/enter

Snapshot revisions are saved as stringified python dict instead of json.
Property names are enclosed with single quotes instead of
double quotes: `{'type': 'SNAPSHOT_CREATED', 'version': 1}`

It can't be parsed as json like every other revision

See odoo/upgrade@d50888b

This will only affect future snapshot revisions but it's not really a problem
since existing ones are archived. Maybe we could "fix" those existing revisions
with a future migration script.

Forward-Port-Of: odoo/enterprise#22270

Have an invoice with VAT Create a payment with a higher amount than the invoice total Open reconciliation widget Select first the payment, then the invoice and create a writeoff for the difference (with the same VAT) Reconcile The system will create two Journal entry created for each writeoff lines, while a single entry should be created, like in bank reconciliation opw-2658779 Forward-Port-Of: odoo/enterprise#24274 Forward-Port-Of: odoo/enterprise#23908

Have an invoice with VAT
Create a payment with a higher amount than the invoice total
Open reconciliation widget
Select first the payment, then the invoice and create a writeoff for the
difference (with the same VAT)
Reconcile

The system will create two Journal entry created for each writeoff lines,
while a single entry should be created, like in bank reconciliation

opw-2658779

Forward-Port-Of: odoo/enterprise#24274
Forward-Port-Of: odoo/enterprise#23908

This reverts commit 13599b3eab3f4e21b45e8f10f34941e1b1ef100b. The commit is reverted as it wasn't the correct way to fix the issue. The fact that the sequence was changed upon an OCR update shouldn't be problematic as one shouldn't use the same journal to import invoices from an external source and create them with Odoo. It should be mutually exclusive. The feature can be thus re-introduced. Forward-Port-Of: odoo/enterprise#24355

This reverts commit 13599b3eab3f4e21b45e8f10f34941e1b1ef100b.

The commit is reverted as it wasn't the correct way to fix the issue.
The fact that the sequence was changed upon an OCR update shouldn't
be problematic as one shouldn't use the same journal to import
invoices from an external source and create them with Odoo. It should
be mutually exclusive.
The feature can be thus re-introduced.

Forward-Port-Of: odoo/enterprise#24355

When the taxes needs to be adjusted to take rounding errors into account, the difference should be applied on the credit instead of the debit for an out invoice. Forward-Port-Of: odoo/enterprise#24381

When the taxes needs to be adjusted to take rounding errors into
account, the difference should be applied on the credit instead
of the debit for an out invoice.

Forward-Port-Of: odoo/enterprise#24381

**Steps to reproduce:** - Create three Bank&Cash accounts 1) 101402 named 'Bank' 2) 101501 named 'Cash' 3) 1014040 named 'A' - Create and post 1 journal entry for each account - Create two account groups: 1) A from code 101402 to 101501 2) A1 from code 1014040 to 1015010 - Go to Balance Sheet and select 'Unfold All' **Issue:** The accounts of group A1 are incorrectly sorted : ``` [ {'id': 1, 'name': '101402-101501 A', 'level': 3}, {'

**Steps to reproduce:**

  - Create three Bank&Cash accounts
    1) 101402 named 'Bank'
    2) 101501 named 'Cash'
    3) 1014040 named 'A'
  - Create and post 1 journal entry for each account
  - Create two account groups:
    1) A from code 101402 to 101501
    2) A1 from code 1014040 to 1015010
  - Go to Balance Sheet and select 'Unfold All'

**Issue:**

  The accounts of group A1 are incorrectly sorted :

```
  [
    {'id': 1, 'name': '101402-101501 A', 'level': 3},
    {'id': 2, 'name': '101402 Bank', 'level': 4, 'parent_id': 1},
    {'id': 4, 'name': '1014040 A', 'level': 5, 'parent_id': 3},
    {'id': 3, 'name': '1014040-1015010 A1', 'level': 4, 'parent_id': 1},
    {'id': 5, 'name': '101501 Cash', 'level': 5, 'parent_id': 3},
  ]
```

  It should be :

```
  [
    {'id': 1, 'name': '101402-101501 A', 'level': 3},
    {'id': 2, 'name': '101402 Bank', 'level': 4, 'parent_id': 1},
    {'id': 3, 'name': '1014040-1015010 A1', 'level': 4, 'parent_id': 1},
    {'id': 4, 'name': '1014040 A', 'level': 5, 'parent_id': 3},
    {'id': 5, 'name': '101501 Cash', 'level': 5, 'parent_id': 3},
  ]
```

**Solution:**

  Sort by level first then by name

opw-2734665

Forward-Port-Of: odoo/enterprise#24328
Forward-Port-Of: odoo/enterprise#23040

Setup to have a Miscellaneous Matching: - Have 2 bank accounts [BNK1] and [BNK2] - Create a bank statement line in [BNK1] with label "test", no partner, and an amount 450 - Create some customer payments from customers having 'test' in the name (i.e. A tester, A test,...), in journal of [BNK2] for a low amount (150) To reproduce the issue: - Go to the bank statement in [BNK1], and open reconciliation widget - Go into Miscellaneous Matching tab, add a filter to match exactly a sin

Setup to have a Miscellaneous Matching:
- Have 2 bank accounts [BNK1] and [BNK2]
- Create a bank statement line in [BNK1] with label "test", no partner, and
  an amount 450
- Create some customer payments from customers having 'test' in the name
(i.e. A tester, A test,...), in journal of [BNK2] for a low amount (150)

To reproduce the issue:

- Go to the bank statement in [BNK1], and open reconciliation widget
- Go into Miscellaneous Matching tab, add a filter to match
  exactly a single line (A tester)
- Add the resulting line
- Remove the partner selector, but not the filter
- Try to reach out the Miscellaneous matching tab again

Issue: Tab will immediatly switch back to Customer/Vendor Matching
because even if the mode will switch correclty to 'match_other', with the
active filter there no more proposition line to show, so the default
mode will fall back to 'match_rp'

opw-2751040

Forward-Port-Of: odoo/enterprise#24310

When the current app doesn't provides menu-items (or the user doesn't have the rights to access them), the mobile burger menu should fallback to the user menu instead of an empty one (like on the App Switcher). Steps to reproduce (on mobile): - on a newly database, install only "notes" app - connect as 'demo' user - open the notes app - open the burger menu => as there is no submenus, burger menu is empty. task-2345001 Forward-Port-Of: odoo/enterprise#21013

When the current app doesn't provides menu-items (or the user doesn't
have the rights to access them), the mobile burger menu should fallback
to the user menu instead of an empty one (like on the App Switcher).

Steps to reproduce (on mobile):
- on a newly database, install only "notes" app
- connect as 'demo' user
- open the notes app
- open the burger menu
=> as there is no submenus, burger menu is empty.

task-2345001

Forward-Port-Of: odoo/enterprise#21013

Currently when an action is invalid (for example if it does not contain a valid xml_id), the studio button in the systray is disabled to prevent the user from opening it. https://github.com/odoo/enterprise/blob/5b111f2cfb1a577e75ccd8562adde4756dd8228c/web_studio/static/src/systray_item/systray_item.xml#L5 But he can still open studio via the "Add custom field" button in the list view. And if it's an invalid view and the the user uses this button, a traceback `NotEditableActionError` is

Currently when an action is invalid (for example if it does not contain a valid xml_id), the studio button in the systray is disabled to prevent the user from opening it.

https://github.com/odoo/enterprise/blob/5b111f2cfb1a577e75ccd8562adde4756dd8228c/web_studio/static/src/systray_item/systray_item.xml#L5

But he can still open studio via the "Add custom field" button in the list view.

And if it's an invalid view and the the user uses this button, a traceback `NotEditableActionError` is raised

https://github.com/odoo/enterprise/blob/b9d192067d289681c55948687ab6d3bc3a267d75/web_studio/static/src/studio_service.js#L139

This commit prevents the addition of this button in the optional fields dropdown in case the view is not editable by studio

opw-2686977

Forward-Port-Of: odoo/enterprise#24234