Following the steps that changed every quantity in a matrix, the next
step was triggered after at least one sale order line's quantity was
changed. Due to the number of lines created, one of the so lines was
sometimes not updated before the next step, which produces an error in
the final sale_count.

In order to check the total and ensure every line was updated, we set
the partner sooner in the tour, which in turn sets the pricelist used to
get the price of each line. Thus allowing a check on the subtotal.

Backport of commit-af1e67aa2c6c676479ee4ea73106bcabd20c621e

closes odoo/odoo#100301

X-original-commit: e0461e1d
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>

When sending a mass mailing with a pdf attachment, the ir.attachment
is copied in the mail.composer for each email. Spending time and
resources in the indexing of the pdf. On copy that value is already in
the vals. This is especially true when attachment_indexation is
installed, processing the pdf documents can be costly with pdfminer.

It could also be done by overwriting the copu from ir_attachment but it
could happen a misuse of mass create of ir.attachment with the same file
has the same issue

closes odoo/odoo#99856

Signed-off-by: Raphael Collet <rco@odoo.com>

Steps to reproduce:
- Create a transfer and choose whatever operation
- Enable detailed operations option for the operation
- Check availability and set quantities
- Cancel the transfer then Go to Product Moves

Current behavior:
- todo filter is broken, it shows canceled moves

Desired behavior:
- Show only moves that are assigned or waiting

- Task id: #2981249

closes odoo/odoo#100292

X-original-commit: 49c8351f
Signed-off-by: Tiffany Chang <tic@odoo.com>

Fields param is actually not a kwargs. This cause a stack trace when opening a chat window (other than a chat with yourself) from a Kanban user avatar icon.

closes odoo/odoo#100259

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

To Reporduce
=============
- Install inventory, purchase and product_expiry
- Create a new storable product that is tracked by lots or serial numbers and expiration date and set expiration days to a value
- Go to inventory > configuration > Warehouse Management > Operations Types
- In “San Francisco: Receipts” > Enable "Create New Lots/Serial Numbers"
- Create a new RFQ > select the created product > Confirm the order
- Click on “Receipt”
- Click on the icon with 3 bars (last thing on line) to open Detailed Operations view
- add a line and set a `lot/serial Number`
- from the same view open the `lot/serial number` wizard and edit the expiration the date
- save/confirm

Problem
=======
The expiration date on Detailed Operations doesn't change

Solution
=========
to solve the issue a condition in compute method was corrected

opw-2937438

closes odoo/odoo#97898

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

When a module extends model 'base', the database schemas of all models are
checked, including indexes.  And a log message appears for "unexpected index
mail_message_subtype_id_index on table mail_message_subtype".  The index indeed
exists, but not for the table mentioned in the message.  The ORM actually makes
a confusion between:
 - the index mail_message_subtype_id_index for subtype_id on table mail_message
 - the index mail_message_subtype_id_index for id on table mail_message_subtype

The fix consists in logging the message about the unexpected index only if the
index is on the expected table.

closes odoo/odoo#100217

Signed-off-by: Raphael Collet <rco@odoo.com>

The RappresentanteFiscale and CessionarioCommittente nodes must be in this order in the invoice xml. The RappresentanteFiscale node is only added if the company has a tax representative configured. In that case, before this fix, submitting an invoice to the SDI (Italian tax agency) would not go through and generate an error :
The invoice has been refused by the Exchange System
File non conforme al formato : Invalid content was found starting with element 'RappresentanteFiscale'. One of '{TerzoIntermediarioOSoggettoEmittente, SoggettoEmittente}' is expected.

How to reproduce :
- Install l10n_it_edi_sdicoop
- Configure a tax representative on the company
- Go to accounting settings > Electronic Document Invoicing and choose the test mode + check the “Allow odoo…” checkbox.
- Create a new invoice and confirm
- Click on “Send now”
- Click again on “Send now” until there is an update and the error is displayed.

closes odoo/odoo#100129

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

Steps to reproduce:
- enable multi currency in settings
- set different rates for multiple days
- create a vendor bill in a different currency
- create a second vendor bill
- fill the second bill using auto complete from the first one

Bug:
the correct currency rate isn't applied unless date is changed when
the source is a vendor bill not a purchase order

Fix:
update currency rate after adding a line with a different currency

opw-2890210

closes odoo/odoo#99934

X-original-commit: fd4a8d98
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Cookies should be used internally by the web UI. The server-side is not supposed to be aware of it at all.

Reverts:
https://github.com/odoo/odoo/pull/88745

Based on https://github.com/odoo/odoo/pull/93812


discussion. It has been decided to revert the fix to avoid further unattended behaviours.

closes odoo/odoo#100139

X-original-commit: d27e3607
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>

Following https://github.com/odoo/odoo/pull/64911, components that are added in the
simplified view of an MO are not transferred to the backorder, which is not aligned
with the behavior of the tablet view.

Task: 2566749

backport of: https://github.com/odoo/odoo/commit/4692e33d24fda47631fb6c39432882fef72ae28b

Related PR: https://github.com/odoo/enterprise/pull/31119



opw-2957834

closes odoo/odoo#99739

Related: odoo/enterprise#31119
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The problem arises when a user creates a backorder for a MO after
registering overconsumption of some components through the simplified view.
The quantities of the components of the new backordered MO are then wrong.
Components that were over consumed in the first MO will have smaller
quantities in the new MO, the difference being the amount over consumed.
This problem does not appear in the case of the Tablet View where a proper
recalculation of quantities is done.

backport of: https://github.com/odoo/odoo/commit/8883c06ada8a7c1debabce39e8f7fea321c70b23

Related PR: https://github.com/odoo/enterprise/pull/31119

opw-2957834

Part-of: odoo/odoo#99739

On October 3rd 2022 the Google OOB authentication flow will stop working.

From that date on, this module will stop working since it uses the
access_token obtained in the `google_drive` module to create the requested
spreadsheet inside the user's own Google Drive account.

Instead we will display instructions to the users to allow them to
manually create the requested document.

task-2977578

closes odoo/odoo#99999

Signed-off-by: Kevin Baptiste <kba@odoo.com>

savepoint do a flush that throw the current context and then recompute
the stored field (with a random matching context from the transaction).
In the case of qty_to_order, it will call qty_forecast and then
_compute_quantities on product.product.

Currently it will call _compute_quantities with a mix of self.env.context
(from the transaction) and a context generated from the orderpoint (with
deterministic data). But sometimes in the context took from the
transaction it could remain some other key used by _compute_quantities
(e.g. warehouse_id). Since qty_to_order doens't depends from context
it should not use self.env.context and only use the deterministic
context from the stock.orderpoint

closes odoo/odoo#100108

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

Currently, in a 2 step incoming shipments scenario, if we create a purchase order and duplicate the transfer that goes from Input to Stock, it will get the procure_method make_to_order.
This is a problem because an unwanted purchase order will be generated. 
As a solution, on the procure_method field of the stock.move, the copy is set to False. This is already the case in v15.

OPW-2952181

closes odoo/odoo#100012

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

To reproduce the issue:
(Need delivery)
1. In Settings, enable "Packages"
2. Create a product P:
    - Type: Consumable
    - Weight: 1kg
3. Create and confirm a SO with 1 x P
4. Open the related Delivery Order
5. Put in pack
5. Open the detailed operations of P
6. Edit the destination package

Error: on the package form, the computed weight is 0kg, it should be 1kg

We should provide the `picking_id` in the context so that the compute
method can do its job:
https://github.com/odoo/odoo/blob/5a8690b35a2fa9c5ed81d858ac0d170beaabaaf9/addons/delivery/models/stock_picking.py#L14-L18



OPW-2972868

closes odoo/odoo#100062

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

If `_merge_moves_fields` is called with a recordset of several SM, and
if there are more than one `self.picking_id`, the method will trigger a
`ValueError` (Expected singleton)

OPW-2861605

closes odoo/odoo#99916

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

To reproduce the issue:
(Need mrp_workorder. Use demo data)
1. Select an existing MO that has some WO
2. Action > Export:
    - Import-compatible export
    - Add "Bill of Material"
3. Import the exported file (remove the external id)
4. Open the new MO

Error: The WO are not created

OPW-2964632

closes odoo/odoo#99803

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

[IMP] account: harmonize the invoice creation in Documents and Accounting when importing a PDF with embedded Factur-X data

Before this commit we had two different behaviour for the same functionnality depending on the App used.
In the Documents App:
- Upload a PDF document with embedded Factur-X in the Documents app
- Click on Create Bill in the actions of the document
- The OCR is triggered.

In the Accounting App:
- Upload a PDF document with embedded Factur-X via the "Upload Bills" button in the Accounting Dashboard
- The invoice is created using the information contained in the Factur-X XML embedded in the PDF without using the OCR.

We should have the same behaviour in both apps. Furthermore, if the invoice information can be retrieved from the XML, it is useless and more error-prone to use the OCR.

This commit fixes this by calling the Accounting importing function instead which also simplifies greatly the code

task-id 2961932

closes odoo/odoo#99247

Related: odoo/enterprise#30879
Signed-off-by: William André (wan) <wan@odoo.com>

Before this commit:
- Go to Accounting / Customer Invoices
- Upload a PDF with Factur-X XML embedded
- The document is uploaded as a Vendor Bill

This should not be the case anymore since we want to allow the import of customer invoices (that can be generated elsewhere)

This commit makes sure that we check from where we import the PDF (Upload button of Customer Invoices or Vendor Bills) to determine in which journal the generated invoice should go via the context.

task-id 2961932

Part-of: odoo/odoo#99247

The default value for ``test_mode`` on ``_post_invoice_edi`` is False,
so, if any of this modules is installed, the test_mode is overwrite to
False.

Now added missing parameter to avoid error on some tests.

closes odoo/odoo#99881

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

The comment was introduced alongside its related line with [1].
The line was removed with [2] but its comment was not, leading to
confusion now.
Instead of removing it in master, might as well remove the confusion in
lower version..

[1]: https://github.com/odoo/odoo/commit/3542a27f9c4c44472184bbedc348ad646d46f20a
[2]: https://github.com/odoo/odoo/commit/0effbe3ca628460b9a0c257ea0bd6060c3eeb253



closes odoo/odoo#99974

X-original-commit: 7258c82a
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit if you would call get_interval() with a wrong interval type'
the function would crash and cause a traceback.
This was due to the result being returned while it is only initialized in the if statements.
If you would for example do get_interval('year') or another option/typo the 'result' was never initialized.
This was especially an issue and annoying to figure out on mail templates as the render would fail with a message saying
'Failed to render template: local variable 'result' referenced before assignment'.
The only way to find/debug this is by looking in the logs and then figuring out it came from this function.

This commit solves this by preventing a crash if you provide a non-supported interval (by returning '')

closes odoo/odoo#99908

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

Before this commit: if more than one user work on a PoS restaurant, the
synced validated orders wouldn't remove from other user devices.

Steps to reproduce the issue:
	1. Create a PoS resturant
	2. Login to the PoS with two different browser
	3. Create some orders with some products in one of the browsers
	4. Complete the orders in another browser
	=> Orders will not remove from the first browser

The solution is to retrieve the latest orders of every table when going to
the TicketScreen

opw-2925193

closes odoo/odoo#98928

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Before this commit: it was possible to use the pos reference of a validated
order for another order. It causes the order to miss because the server
wouldn't save a new order if there is an existing order with the same pos
reference.

Steps to reproduce the issue on the runbot:

	Open a PoS session
	Throttling the network
	Create an order by selecting some items
	Pay the order
	Validate the order and just before it finishes the job, go back
	Now it's not possible to add an item or change the quantity
	Now click on one of the order lines

	The order will save to unpaid order, and if you reload the page, it will
be possible to modify the order and use it for a new PoS order.

Solution

	The solution is to prevent it from saving it again.

opw-2951938

closes odoo/odoo#99472

Signed-off-by: Masereel Pierre <pim@odoo.com>

Small fixup of recent commit [1].

A regular user do not have delete right on iap.account model, hence
creating an access right error. We should allow him to delete accounts
without token so they will be re-created afterwards.

[1]:https://github.com/odoo/odoo/commit/974caef934b7a116b7375f05e047aea15ea960aa



closes odoo/odoo#99833

X-original-commit: 0993e279
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>

In a form view, have a o2m field (A), with a nested o2m field (B).
The A field should have multiple pages, with each record having at least one record
in their B field.

Have a (C) field that will modify a record in the nested o2m when changed.

Change the C field, and save.

Before this commit, the record's nested o2m from the other page had a wrong value
(a mere 4 command).

After this commit, their value is a command 4 and a command 1, with the right values.

closes odoo/odoo#78707

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Before this commit, when content of dialog was long, content
overflow but was not scrollable, which makes bottom unreachable,
which is especially a problem when buttons are at the bottom.

This problem solves the issue by adding classname `modal` to
dialog. This classname puts proper handling of overflow of
dialog and its content.

Also remove `align-items-center` so that top doesn't overflow
in isolation from the rest of content, which made top unreachable.

Task-2973866

closes odoo/odoo#99620

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

Before, when using a cash basis tax in the bank reconciliation widget, the account chosen for the tax line corresponded to the tax transition account. This was wrong: since the entry is already reconciled, we want to use the actual repartition account, as nothing will move this amount from the transition account afterwards.

Indirectly linked to OPW 2865789

closes odoo/odoo#99465

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

Steps to reproduce:
- Accounting > journal entries > misc
- add entries (draft) with empty journal name
- resquence those entries with entries that have names

Bug:
calling min or sort on the names fails when some are strings and others
are bools (False for empty strings)

Fix:
replace names that aren't set with an empty strings

opw-2957750

closes odoo/odoo#99502

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Currently, in the survey, if the survey/section/question title, description,
survey breadcrumb and multiple choice question options have a very long
link in the label, then on mobile the card is too long, which makes browsers
display a horizontal scroll.

This commit solves the above problem by adding the `text-break` class to the
label.

task-2925648

closes odoo/odoo#97330

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

Steps to reproduce:
- create two products
- create two analytic accounts
- create two new analytic rules by assigning an account to a product
- Create a new PO and select on of the product
- On the same line, change the product to the other one

Issue:
- The analytic account won't be updated

Cause:
Bypass of the `account_analytic_id` whenever there is already on defined

Solution:
For the `Sale` fix, I added the `line.state == 'draft'`.
The reason? Because the compute is triggered after confirmation of the order due to:
https://github.com/odoo/odoo/blob/14.0/addons/sale/models/sale.py#L931-L935


Therefore, the compute won't also be triggered after confirmation of the SO.

opw-2948950

closes odoo/odoo#98151

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

When creating records with default keys in context those are currently
propagated through the whole call chain until message creation. However
default keys are meant to be used for the record creation, not its logs
or messages.

A protection against default_child_ids already exists. However better
remove all context keys by using a clean context.

Closes odoo/odoo#93797

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

Observed Behaviour

When opening a pivot view with the catalan language activated
and grouping rows/cols by months, everything works fine. But if
we try to import this pivot view in a spreadsheet, all months
are converted to gener, which means 'January' in catalan

Expected Behaviour

When importing the pivot view in a spreadsheet, we should get
the correct date grouping

Reproducibility

This issue can be reproduced with the following steps
1. Activate the catalan language and set it
2. Got to Sales App
3. Select the pivot view
4. Group the rows/cols by order date > months
5. Try to import the pivot view in a spreadsheet

Fix Description

The isse was coming from the fact babel (the package used to
generate date as text in python) write the month as 'de gener',
'de febrer', 'de març', 'd'abril', while moment (the lib used
to handle date in JS) is looking for months as 'gener', 'febrer',
... (ie without "de" or "d'" prefix), causing it not to
recognize the date proposed by Babel. We then added a preparse
method to the catalan language, automatically used by moment when
present in the language definition.

Related Issues/PR
-opw-2817041

closes odoo/odoo#90466

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

closes odoo/odoo#99633

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Steps to reproduce:
  - change the location of the company in Switzerland;
  - create a customer located in Switzerland and whose language is
    French (CH);
  - create an invoice with a QR code for this customer.

Issue:
  Some words are not translated.

Cause:
  The report content had some XML structure change (in 6e380d06) after
  14.0 release and they have not been applied in translation .pot or .po
  files since.

Solution:
  Edit the ".pot" file.
  Edit the ".po" file (i18n are not on Transifex)

Remark:
  The modification (addition of elements) in the ".pot" file was done
  by hand because the file is in the i18n_extra folder (not exported).

opw-2959226

closes odoo/odoo#99081

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Steps to reproduce:

- Go to Projects and find one having field "sale_line_id" set
  (example "AGR - S00048" with
  "S00048 - Senior Architect (Invoice on Timesheets)")
- Go to Sales -> Quotations and :
  1/ cancel
  2/ set in draft
  3/ edit Project to "AGR - SO00048"
  4/ confirm again (see attached)
- Alter Marc Demo access right to have:
  Sales -> Administrator
  Project -> User
- With Marc Demo, go to Sales -> Quotations and open S00048
- Try to cancel it

Issue:

  Access right error.

Cause:

  When canceling a SO, we remove the related SO line on the project
  however the current user have access to edit SO but not the project.

Solution:

  Use sudo().

opw-2959627

closes odoo/odoo#98956

Signed-off-by: Xavier <xbo@odoo.com>

closes odoo/odoo#99575

X-original-commit: 9e86d160
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Steps to reproduce:
- create a contact with a phone number
- enable IAP-sms
- take off the number of the admin-contact
- create an event in the calendar with a "text-sms reminder" with the new created user

Issue:
No sms will be sent

Cause:
The IAP server-side does not accept request with `number` set to False such as in:
```{'messages': [{'res_id': 23, 'number': False, 'content': 'Event reminder: test-local, 07/11/2022 at (15:46:00 To 16:46:00) (Europe/Brussels)'}, {'res_id': 24, 'number': '+32487253270', 'content': 'Event reminder: test-local, 07/1>

Solution:
Filter partners with a valid phone number in `_sms_get_default_partner`

opw-2867763

closes odoo/odoo#95784

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