Python library currently holds a limitation when we use a formatted email
that is longer than 78 characters (e.g. "Long Company Name With Long Record
Name <email@domain.com>"). Python folds address if is longer than 78 chars
and a bad management of quotes breaks the reply-to. Even if anything should
technically be ok with the RFC python seems to incorrectly handle it (please
refer to [1] for more details and discussions).

Until this is finally sorted out we decided to avoid issues by shortening
reply-to. To avoid that issue when formataddr would return more than 78 chars
we return a simplified name/email to try to stay under 78 chars. If not
possible we return only the email and skip the formataddr which causes the
issue in python. We do not use hacks like crop the name part as encoding and
quoting would be error prone.

Task-2602862
OPW-2733513

[1] See https://bugs.python.org/issue44637



closes odoo/odoo#88912

X-original-commit: 5353ce3b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

If the user triggers several orderpoints one by one, some purchase order
lines may be merged while they shouldn't.

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a product P:
    - Type: Storable
    - With a vendor V
    - Route: Buy
3. Add two reordering rules to P:
    - Min=Max=1 at WH/Stock
    - Min=Max=2 at WH/Stock/Shelf 1
4. Inventory > Operations > Replenishment, trigger the orderpoints of P
(one by one)
5. Open the generated PO

Error: There is only one line with 3 x P, there should be two lines (1 x
P + 2 x P, one for each orderpoint). If the user confirms the PO and
receives the products, the destination location will be Stock or Shelf 1
(depending on the last orderpoint triggered)

Running the orderpoint leads to `_run_buy`, where we try to find an
existing PO line so we can update it (else we will create a new one):
https://github.com/odoo/odoo/blob/5b34adb51eda978aa9ef1a434ab77257d73b9594/addons/purchase_stock/models/stock_rule.py#L122-L129



Here is the issue: the filter in `_find_candidate` contains an `or True`
that makes a whole condition useless.

Considering [1], the condition on `move_dest_ids` is only relevant when
an orderpoint is defined. Therefore, we can remove the `or True` and
improve the condition

[1] 63fffa0b

OPW-2720868

closes odoo/odoo#88870

Signed-off-by: Arnold Moyaux <arm@odoo.com>

Have a purchase tax with cash basis payment enabled
Have a product with said tax
Create a bill with the product, save and confirm
Register a payment

Check CABA entries
There should be 4 entries, but only 2 have been generated

opw-2782561

closes odoo/odoo#88321

Signed-off-by: Olivier Colson <oco@odoo.com>
Co-authored-by: oco-odoo <oco@odoo.com>

When invoicing a tracked product, the lots/SN delivered (or the related
quantities) are not always the correct ones displayed on the printed
invoice

To reproduce the issues:
1. In Settings, enable "Display Lots & Serial Numbers on Invoices"
2. Create a product P:
    - Storable
    - Tracked by lot
3. Update its quantity > 5 with lot L

Use case 01:

4. Create and confirm a SO with 5 x P
5. Process the delivery
6. Create an invoice
7. Edit the invoice line:
    - Quantity: 1
8. Post and print the invoice
Error: The quantity related to lot L is 5, it should be 1

Use case 02:

4. Edit P:
    - Invoicing Policy: Ordered quantities
5. Create and confirm a SO with 1 x P
6. Create and post the invoice
7. Process the delivery
8. Print the invoice
Error: There isn't any information about delivered lot L

Use case 03:

4. Create and confirm a SO with 3 x P
5. Deliver 1 x P (with backorder)
6. Invoice 1 x P + Post the invoice (-> INV01)
7. Deliver 2 x P
8. Reset, post INV01 again and print it
Error: The quantity related to L is 3, it should be 1. Moreover, if the
user then invoices the 2 others P, posts and prints this second invoice,
it won't contain any information about L

OPW-2730270
closes #81444

closes odoo/odoo#88815

X-original-commit: 7a030f61
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>

Usecase to reproduce:
With BoM structure
- Product A (RR 1-20)
	|
	Product B (MTO)
		|
		Product C (RR 5-50)
			|
			Product D (Buy)

Launch the RR. The MO are:
Current Behavior
- Product A 20
- Product B 20
- Product C 50
- Product C 70

Expected Behavior
- Product A 20
- Product B 20
- Product C 50

It happens because the MO are created as draft during the
`_run_manufacture` and are confirm at the end of
`_procure_orderpoint_confirm` in '_post_process_scheduler`.

However at the first MO for product A, it creates a MO for product B
and since it consumes product c, it checks if the orderpoint should be
trigger. MO for product C still "draft" and the orderpoint forecast is
now -20, so it will create a new procurement for product C with 70 units

To fix it we take the MO draft linked to the orderpoint for the
forecasted quantity.

closes odoo/odoo#88590

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Revert commit 54cd73a4f4 as it prevents customers from closing
their pos sessions without timeouting.

closes odoo/odoo#88882

Signed-off-by: Julien Castiaux <juc@odoo.com>

Steps to reproduce the bug:
- Create the workcenter_1:
    - Time Efficiency: 100%
    - Capacity: 2
    - Setup Time: 1
    - Cleanup Time: 1

- Create the workcenter_2:
    - Time Efficiency: 100%
     - Capacity: 4
    - Setup Time: 10
    - Cleanup Time: 5
    - Alternative Work centers: workcenter_1

- Create a storable product “P1” with BOM:
    - Add any product as component
    - Add operation:
        - Duration: 60
        - Work center: Workcenter_2

- Create a MO:
    - select “P1” as Product
    - Qty to produce: 4
    - Confirm and Plan

Problem:
The workcenter_1 is chosen while work_center_2 is faster it can manufacture the 4 units at the same time
while workcenter_1 must do two cycles

As the Time Efficiency = 100%, so:
Total duration = (Setup Time + Cleanup Time) + duration_by_unit * nb_cycle
Work_center_1 = (1 + 1) + 60 * 2 = 122
Work_center_2 = (10 + 5) + 60 = 75

The calculation is bad because we use the number of cycles necessary for the work_center defined in the BOM
in the calculation for the alternative work center

opw-2821749

closes odoo/odoo#88808

Signed-off-by: Arnold Moyaux <arm@odoo.com>

This commit fixes the timer that was cropped out when taking a
survey having a time limit on mobile devices.

Task-2810299

closes odoo/odoo#88193

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Step to reproduce :
	-set your company country in Italy
	-install accounting
	-install contacts
	-create a new individual contact
	-set the country address of this contact to Italy

Expected Behavior:
No problem

Current behavior:
Error message in function _l10n_it_normalize_codice_fiscale

Explanation:
In this fix commit https://github.com/odoo/odoo/commit/702c01661f255fe9ebbfc04c90b2cd0fa194d1e8


the case where vat is unset but the country is Italy is not rejected
anymore and a unset value is passed in _l10n_it_normalize_codice_fiscale

opw-2822259

closes odoo/odoo#88790

Signed-off-by: Josse Colpaert <jco@odoo.com>

Before this commit: whenever we left the PaymentScreen when we were paying (either by reloading the page or by backing to the ProductScreen), the real payment status was not properly saved even tho the payment has been paid or cancelled.

With this commit: whenever we go to the PaymentScreen with a pending payment line with Adyen, we fetch the latest status from the back end. This way, the front end will always have the latest status of the payment.

opw-2802676

closes odoo/odoo#88309

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Following the fix in V15 for other payment aquirer
0885212a

This fix solve the issue for Authorize in V14

More info regarding the explanation of the bug and the solution
are available in the original commit msg.

opw-2785311

closes odoo/odoo#88092

Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>

This fix is a correction of the one made in this commit 782c43c1
which was not correct.

opw-2801012

closes odoo/odoo#88758

Signed-off-by: Florian Gilbert <flg@odoo.com>

Add a check in 'AccountTestInvoicingCommon' to ensure that all
tests using it are run in post_install.
These tests cannot be run at install, thus they would be ignored
and wouldn't run on the Runbot.

closes odoo/odoo#87677

Related: odoo/enterprise#25779
Signed-off-by: Florian Gilbert <flg@odoo.com>

Steps to reproduce:

• Create Record: Product Category
- Costing Method: Average
- Inventory Valuation: Automated
- Specify a price difference account (may create new account).
- Ensure Stock Interim (Received) account is reconcilable.

• Create Record: Product
- Product Type: Storable
- Cost Price: 1.01
- Product Category: New Product Category

• Create bill with this product, for a quantity of 10.5

-> The is price difference of 0.1

Issue comes from this commit 286ea6b6
which doesn't round if there is a discount.

With this commit we isolate the latter case in order to keep the
price unit rounded if there is no discount.

closes odoo/odoo#87666

Signed-off-by: Florian Gilbert <flg@odoo.com>

With l10n_nl, create a purchase journal -> traceback
Ids was appended to ORM command list, instead of the ids list.
Moreover, it was filled even if there were no missing value.

opw-2801012

closes odoo/odoo#87445

Signed-off-by: Florian Gilbert <flg@odoo.com>

Since [1] when the blog layout was refactored between 12.0 and 13.0, a
negative word spacing was introduced in the blog post snippet with the
big pictures layout.

This commit removes this negative word spacing.

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



task-2822436

closes odoo/odoo#88601

X-original-commit: 6c4e6137
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Supplier pricelists doesn't restrict the choice of the variant to the
variants of the current product template (in the view).

To reproduce the issue:
1. Create a product with different variant
2. Install 'purchase' and go to the 'purchase' page on a product form.
3. Create a new Supplier Pricelist (a new line).
4. In the 'product_variant' the user can select any product of the company.
We should only see the variants of the current product.

Solution: Since 14.0, the Supplier Pricelist can be edited directly from the
tree view (while in 13.0 a form was used). In this tree view, there are no filtering/domain
on the 'product_tmpl_id'. This filtering is however present in the form in 13.0
which is why the problem is present only as from 14.0. Similarly to the 13.0 form,
the 'product_variant' field doesn't allow the quick creation. A restriction has
also been created to illustrate what happens in the UI.

opw-2792060

closes odoo/odoo#87096

Signed-off-by: Tiffany Chang <tic@odoo.com>

This reverts https://github.com/odoo/odoo/pull/87375



`auth_signup_uninvited` is be set as required in the
settings view but a value is missing in the case where the current
company has no website.
This then prevents the settings from being saved.
This could also be an issue with other settings in custom code.
We should revert this fix in stable.

opw-2819061

closes odoo/odoo#88589

X-original-commit: 3fd991f6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Steps to reproduce:

Decimal Accuracy - Product Price = 2
- create a product `alc 50%` with BOM (10 unites = 1 unit Water [cost=0.14]; 1 unit Alc [cost=0.08])
- Set `quantity on hands` = 10,000
- Trigger `Compute Price from BoM`

-> In Reporting > Inventory Valuation; click on the layer; in Other Info: You will see "Product value manually modified (from 0.0 to 0.022000000000000002)"
=> It can cause computing mistakes as we changed the costs

Cause:

The value is calculated as the difference between the New Price (cost) and and the current Product Standard Price (cost).
But, on one hand the Product Standard Price is rounded to the number of digits defined in the Decimal Accuracy for the Product Price.
On the other hand, the New Price is used as is with no rounding.

If we add an extra step and modify the cost of the Water to 0.45 and trigger again the `Compute Price from BoM` we will have:
"Product value manually modified (from 0.02 to 0.053000000000000005)"

Solution:

Use for the New Price the same rounding precision as we use for the Standard Price.

Example:

Product		Price/unit
--------------------------
Water		0.14
Alc. 100%	0.08

BoM: Alc. 50%
Product		Quantity Needed
--------------------------
Water		0.1
Alc. 100%	0.1

Cost/unit of Alc. 50%: 0.022 => 0.02 (standard_price is rounded)
Set Quantity on Hand: 10,000

Stock Valuation: 200 = 10,000 * 0.02
=> The standard_price is rounded to the second digit when intialized

Product         Price/unit
--------------------------
Water           0.45
Alc. 100%       0.08

BoM: Alc. 50%
Product         Quantity Needed
--------------------------
Water           0.1
Alc. 100%       0.1

Cost/unit of Alc. 50%: 0.053
Set Quantity on Hand: 10,000

Stock Valuation WITHOUT FIX: 530 = 200 (first layer) + 330 (second layer) = 0.02 * 10,000 + (0.053-0.02) * 10,000
Stock Valuation WITH FIX: 500 = 200 (first layer) + 300 (second layer) = 0.02 * 10,000 + (0.05-0.02) * 10,000

=> Without fix, the value is computed with the rounded standard_price and the not rounded new_price.
=> With fix, the new_price is rounded the same way as the standard_price

opw-2724975

closes odoo/odoo#87600

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to follow

  - Go to Accounting > Accounting > Sales (account.move.line model)
  - Remove any existing group by
  - Group by Products
  - Select multiples lines of the same product
  - Try to modify the account of the select line
  -> `this.localData[value] is undefined

Cause of the issue

  When grouping by a field not in the view, `list.__data` contains the
  groupedBy field value because we fetched the group through a web_read_group

Solution

  Filter out absent fields before creating the group datapoint

opw-2784995

closes odoo/odoo#88569

X-original-commit: 36c17664
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

Before this commit:

Message from mailing channel make a notification in Odoo for users
with notification "Handled by Email" when user is not log-in. this is happening
because mailing channel is marked as seen from
"messaging_notification_handler.js" which is not executed when user is not
log-in and receive message so message counter is increase when user log-in.

After this commit:

Hide the counter for mailing channel when user handles notification with emails.

Task-2541660

closes odoo/odoo#82015

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

In some cases, due to rounding errors, the state of a MO is incorrect

OPW-2753598

closes odoo/odoo#88530

X-original-commit: 976eee1d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Steps:
Log in with admin.
Configure Stripe for direct payment (from Odoo).
Create an invoice for portal.
Click on Preview, then Pay Now.
Select Stripe, enter your credentials and pay.

Issue:
Error message: Invalid token found!

Cause:
Paying this way creates a token for admin.
Yet, later, we check that invoice's partner == token's.
Using acquirers with a token-based payment method
should not be allowed when the current user's partner
is not the invoice's customer.

Fix:
Clarify the error message to indicate how to resolve it :
log in as the good partner.

opw-2730967

closes odoo/odoo#88523

X-original-commit: f871483a
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>

Expected Behaviour

When buying multiple tickets for an event on the website, we should
have the correct number of tickets in our cart

Obeserved Behaviour

When buying multiple tickets from an event B where the associated product
has already been associated to another event A , the maximum number of
tickets from the event A is used instead of the correct one (from B),
leading the client not to be able to buy as much ticket as he want in
case the limit of A is lower than the limit of B.

Reproducibility

This issue can be reproduced using the following steps :
1. Create an event A with a maximum number of 1 tickets and a product P
2. Buy and confirm 1 ticket
3. Copy the event A to an event B
4. Set the maximum number of tickets to 3 (keeping product P)
5. Go to the website page of event B and try to buy 3 tickets
6. On the checkout page you should have only 1 ticket for event B

Fix Description

The issue was coming from the fact we use the associated product to get
the event's ticket ID in the _cart_update mathod. This fix propose to use
the event_ticket_id value, already set in the sale_order context, to find
the correct ticket.

Related Issue(s)/PR

opw-2761303

closes odoo/odoo#88481

X-original-commit: db674e33
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>

Steps to reproduce:

  - Install eCommerce module
  - Select company A and set only one pricelist with:
    - company = company A
    - website = website of company A
  - Select company B and set multiple pricelist.
  - Switch to company B
  - Archive a pricelist

Issue:

  Error: "With this action, "Website of company A" website would not
  have any pricelist available".

Solution:

  Use sudo() when searching websites to don't use multi-company
  compliant ir.rule `product_pricelist_comp_rule` (in website_sale) when
  getting pricelist_ids (and therefore allow checking all pricelists for
  all websites in all companies).

opw-2759069

closes odoo/odoo#88453

X-original-commit: 2e1c7599
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>

Before this PR, chat window scroll position was reset to top when it was
switched to the left.
This PR introduce a component hit that restore the position saved inside the
models when a chatwindow is switched.

task-2746500

closes odoo/odoo#87966

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Regression introduced here: fba9c9f3

closes odoo/odoo#88382

X-original-commit: 83c7017f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>

This commit is to prevent "AttributeError: 'NoneType' object has no
attribute '_name'"
When an xmlid does not exists, the _xmlid_to_obj returns None and the
condition was failing when trying to retrive the model name.

Closes odoo/odoo#88273

closes odoo/odoo#88392

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

When setting acc_holder_name on the bank account receiving the payment of a QR-bill, acc_holder_name was used instead of the company's name inside the QR-code, but not on the summary text displayed next to it. This fix replaces the company name there as well. The behavior is unchanged when acc_holder_name isn't set.

closes odoo/odoo#88174

X-original-commit: 76e6c808
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>

Instead of doing the difference between output tax and input tax, the tax report was doing the sum.
This commit fixes this computation without revamping the rest of the report

closes odoo/odoo#88120

X-original-commit: c5b9130c
Signed-off-by: Olivier Colson <oco@odoo.com>

The account used in the Repartition for Credit Notes is wrong for taxes
`IVA(8%) COMPRAS`, `IVA(16%) COMPRAS`, `IVA(8%) VENTAS`, `RETENCION IVA
ARRENDAMIENTO 10.67%`, `RETENCION IVA HONORARIOS 10.67%` and `IVA(0%)
COMPRAS`

Steps to reproduce:
1. Install Accounting app and l10n_mx module
2. Go to Accounting > Configuration > Invoicing > Taxes
3. Open any one of the taxes mentioned above
4. The account in Repartition for Invoices should be the same as the
account in Repartition for Credit Notes

Solution:
Change the default account used in Repartion for Credit Notes

opw-2806228

closes odoo/odoo#88338

X-original-commit: e8dbd07f
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

closes odoo/odoo#81259

Signed-off-by: Florian Gilbert <flg@odoo.com>

Part-of: odoo/odoo#81259

closes odoo/odoo#88301

Signed-off-by: Josse Colpaert <jco@odoo.com>

closes odoo/odoo#88292

Signed-off-by: William André (wan) <wan@odoo.com>

Install FR accounting and have a FR company setup with VAT
Create a bill with bill date different from accounting date
Export FEC under Accounting>Reporting>FEC

For the created bill the accounting date will be used, while it should
be taken first the bill date

opw-2680288

closes odoo/odoo#88281

X-original-commit: 2b1fc6a9
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

If applied, this commit will fix the following bug by using the correct
total based on whether the price is tax inc. or exc.

Steps to reproduce:
- Install sale
- Create a tax with "included in price" set on it
- Create a promotion program with any value higher than
  [100/(1+VAT/100)]% discount on total order
- Create a SO and add product with the created tax
- Add promotion program

Result:
- The discount applied is capped at [100/(1+VAT/100)]%
  Eg, for a 35% included tax, the max discount will be 74.07%,
  regardless if the discount % is higher like 90%.
Expected result:
- The correct discount should be applied

Bug:
The ```price_subtotal``` is used to calculate the order total amount
whether the price is tax inc. or tax exc.

Fix:
Use ```price_total``` when the price is tax inc.

opw-2765883

closes odoo/odoo#88066

X-original-commit: a99b4438
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Andrea Grazioso (agr-odoo) <agr@odoo.com>

This garbage adds no value and blocks some deployments. See https://github.com/Tecnativa/doodba/issues/485

.

@moduon MT-295

closes odoo/odoo#85823

Signed-off-by: Thibault Francois <tfr@odoo.com>

Steps :
Install modules hr_holidays and google_calendar;
Log into Odoo with two different users, one manager and one employee (subordinated): f.e. Admin e Demo;
Set Google Client ID and Google Secret with a OAuth2.0;
Check if in Odoo's Calendar the Synched with Google tag compares on the right (with manager);
From employee user, go to Time Off -> My Time Off -> My Time Off Requests and Create with a date;
From manager user, go to Time Off -> Managers -> Time Off and accept the time off created;
Go to manager's Google Calendar.

Current behavior:
Google event is created and visible for manager, employee has an event since is an attendee of the first.

Expected behavior:
Google event is created and visible for employee, manager is not involved.

Fix:
Group the leaves with user and create events with this user.
We could not modify easily the behavior of the calendar sync modules.
The following approach was tested: odoo/odoo#86385
But it has some side effects on recurring events, oultier events
(events not following the recurrence) and could bring performance issues.
The solution of this fix was chosen because it is less intrusive.

opw-2761158

closes odoo/odoo#88124

Signed-off-by: Arnaud Joset <arj@odoo.com>