Only compute the lot values info on stockable or consu (kits) products
on the invoice lines

closes odoo/odoo#100663

X-original-commit: affc9abb
Signed-off-by: Adrien Widart <awt@odoo.com>

Backport of https://github.com/odoo/odoo/commit/c88f76cab7a1292e6fff3bd77441a9845b8173c8

 because it could lead to a traceback in the case a GET wasn't supposed to receive this kind of format as request answer.

closes odoo/odoo#100674

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

When creating a MO with some WO from a mobile, the quality checks are
not created

To reproduce the issue:
(Need quality_control)
1. Create two storable products P_compo, P_finished
2. Create a BoM:
    - Product: P_finished
    - Components: 1 x P_compo
    - Operations: create a new operation OP
3. Add a step to OP:
    - Type: Pass - Fail
4. Switch into mobile mode
5. Create a MO for 1 x P_finished
6. Confirm it
7. Open the WO

Error: the tablet view skipped the pass-fail step, the user can already
mark the MO as done and close it

When confirming the MO, it leads to the quality checks creation. To do
so, we iterate on the `quality_point_ids` of the WO to generate these
quality checks:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L406
But, the WO has not any quality point, which is incorrect: it should
have the one related to the step created on the operation P. This field
is a computed one and is based on the quality points defined on the
operation linked to the WO:
https://github.com/odoo/enterprise/blob/7ff0f43df777027bf8544be3ac95e76feb7da957/mrp_workorder/models/mrp_workorder.py#L70-L73


But again, there is an issue: the WO has not any defined operation
(which is incorrect, it should be linked to OP). And this is because of
the WO creation from the kanban view: the field `operation_id` is
missing so it is not defined during the WO creation.

OPW-2984037

closes odoo/odoo#100672

Signed-off-by: Adrien Widart <awt@odoo.com>

When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Go to Manufacturing > Master Data > Routings and edit routing
   'Primary Assembly' to last 120:00 minutes
4. Go to Manufacturing > Operations > Manufacturing Orders and create
   one with values:
   - Product: Table Top
   - Plan From: today's date at 11:00:00
5. Save, mark as todo and plan the manufacturing order
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
   the day view
7. Move the work order to 8 am
8. The work order still lasts for 3 hours (according to its start and
   finish time) even though its expected duration is 2 hours

Solution:
Recompute `date_planned_finished` when we move a work order in the
planning (`date_planned_start` and `date_planned_finished` are passed in
values), and recompute `expected_duration` when we extend it (only one
of them is passed depending on the way we extend the work order).
(`duration_expected` is never passed in values when we manipulate a work
order through the planning)

Problem:
`date_planned_finished` wasn't recomputed when moving the work order in
the planning

opw-2893622

closes odoo/odoo#100540

X-original-commit: 90f83914
Related: odoo/enterprise#31547
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

What is done in start should be undone in the destroy.

closes odoo/odoo#100420

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

To check if the state 'Reversed' should be set on an invoice. We checked that the full reconciliation moves
only contain the invoice, the reverse move and the potential exchange move. However, it's possible to have
also some CABA moves for the invoice and credit note when the tax used have a CABA transition account which
is reconcilable (eg. tax "IVA(16%) VENTAS"). So if this append the status 'Paid' will be set instead.

Now, we take into account those CABA moves and the status will be set to 'Reversed' accordingly.

opw-2976667

closes odoo/odoo#100380

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

Before this fix negative aml unit prices were systematically set to positive in the edi xml generating inconsistencies.

closes odoo/odoo#100598

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

Steps to reproduce:

  - Switch to debug mode
  - Go to calendar
  - Create an allday event in the future named test
  - Add an attendee with an email address
  - Save
  - Go to Settings > Technical > Email > Emails

  Two emails have been sent:
  * Invitation to test
  * test: Date updated

Cause of the issue:

  The method `_inverse_dates` is called when creating an event,
  triggering a write on the start field.
  This then causes an update email to be sent

Solution:

  Add a context key and don't send the update email if it is present

opw-2841276

closes odoo/odoo#100275

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

Steps to reproduce the bug:
- Install [l10n_it_ddt]
- Create a storable product “P1”
- Create a SO for “P1” with qty 3
- Deliver 1 unit and create a backorder
- Generate the invoice for the delivered qty: 1
- Post the invoice
- smart button with the link to DDT n°1 appears
- Deliver the remaining 2 units
- Create the second invoice
- Post the invoice

Problem:
The link to DDT appears but with the 2 pickings, whereas in this case
only the 2nd picking is linked to the invoice.

Before using the `account.move.line` records, we sorted them by date
in order to always use the first created one to link it with the first
picking created, however if two `account.move.line` were created in
the same days, they will be ordered randomly, so we also have to
sort them by id if the date is the same.

opw-2968401

closes odoo/odoo#100294

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

Manual action "click" was wrongly took off in
c650faaaf77fe99559a23a4d68fae56b498d8c89 and browser was sometimes
closed before the default click action ran. For clarity purpose, a step
is added to ensure the form is saved in place of the manual click.

closes odoo/odoo#100725

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Currently, When we create an invoice from a sale order containing some notes or sections.
The analytic account from the sale order is set on the invoice/move line.
During the creation of analytic lines, a line is created from the section/note line.

This commit makes no analytic line is created for section/notes.

closes odoo/odoo#100615

X-original-commit: 3293ffa0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

When the ACE editor was introduced in [1], it relied on the already
existing `_views_get` to obtain the list of views that could be edited.

When the `mode` of `ir.ui.view` was introduced in [2], no mechanism was
introduced in `_views_get` to avoid fetching primary views that have
nothing in common with the current view.

This commit adds a parameter to `_views_get` to request the
exclusion of unrelated primary views.
Since even before it appeared in [3], `_views_get` relies on the
following approach:
- consider the top-most parent of the `t-call`ed views
- consider the views that inherit it
I.e.: reach each node of each view hierarchy tree by starting from its
root.

Because this starts from the top-most parent, simply preventing the
call to each primary child view is wrong, because any child on the
parent path must be considered - be it primary or not.
We therefore introduced a `skipped` list that keeps track of those
"later to be processed" views - so that the filtering of primary
children does not remove them.

[1]: https://github.com/odoo/odoo/commit/7c45e5976e6caf3d7b9eb508f728062704232261
[2]: https://github.com/odoo/odoo/commit/434be479f97a32987d0817bf329183fc2bbe3bf5
[3]: https://github.com/odoo/odoo/commit/bff6e04e9536d7b80916987eb123de98b1b689b1



task-2898555

closes odoo/odoo#99838

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Suppose a product P with an available quantity equal to 1. Suppose a
user writes on an existing SML for that product and sets the reserved
quantity to 2. When writing on such a field, `StockMoveLine.write` tries
to reserve the same quantity on the quants. If it fails (which would be
the case here because there is only one P available), the reserved
quantity of the SML is reset to 0 (and so does the reserved quantity of
the quant).
https://github.com/odoo/odoo/blob/b8423ba218e0736593c3329d7438ca09112a735f/addons/stock/models/stock_move_line.py#L301-L313

However, there is an issue: the incorrect reserved quantity is still in
`vals`. As a result, later on in the method, this incorrect value is
written on the SML:
https://github.com/odoo/odoo/blob/b8423ba218e0736593c3329d7438ca09112a735f/addons/stock/models/stock_move_line.py#L362


This creates an inconsistency: a SML affirms that 2 x P are reserved
while the reserved quantity of the quant is 0. Moreover, when marking
the SML as done, it will lead to a "unreserve more than..." issue.

OPW-2936689

closes odoo/odoo#100136

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

After commit [1], attribute `t-value` was replaced to `value` by mistake

Steps to reproduce:
- Go to a forum post
- Click on the author image, logged in as admin
- On the profile page, unpublish the user
- As public visitor go to the previous forum post
- See the avatar image url -> `href` is now `href="#"` with this PR.

[1]: https://github.com/odoo/odoo/commit/c8c8eb3d5652e9834d0ecd5aad907ee359edb657#diff-2a4205ad15bf7b1ef0d1361b1baec87ef8a6429de19f9e0e8afce4ca16be839d



closes odoo/odoo#100484

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Before this commit: if an event's attendee didn't have a state, it couldn't
get synced with Google.

The solution is first to set a default value for it.

opw-2915661

closes odoo/odoo#97693

Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>

Before this commit, when an event was set to recurrent, all the recurrence
values were falsy. They were not equal to the default values.

opw-2886253

closes odoo/odoo#97012

Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>

Before this commit: syncing with google led to sending emails to
attendees of existing future events on Odoo.

Steps to reproduce the first issue:

- Install 'google_calendar' module
- Integrate with Google Calendar in setting
- Add an event to the Odoo calendar for future date
- Add one external attendee to the event
- Sync with Google

Invitation emails would be sent to the attendees of the events.
Solution

It's possible to not send emails to the attendees in api calls. So
the solution is to not send emails to the attendees for the syncing
time.
opw-2819046

Part-of: odoo/odoo#97012

Steps to reproduce:
- create and send a quotation
- make a failed payment (through cutomer preview)
- create and send a second quotation to the same customer
- make a succesful payment this time
- redirect takes to the wrong quotation (failed one)

Bug:
polling the processed payments initially returns both transaction
but the following polls only returns the rejected payment
(introduced in [1] processed transactions are filtered out)
since there's only a single transaction, redirect takes to it

Fix:
if there's only a single succesful transaction (regardless of the rest)
it means the current payment was successfull so we redirect to it

opw-2954162

[1]:https://github.com/odoo/odoo/pull/31741/commits/7612659565ee24f1c878b81e6c86b5780fbd5a3d



closes odoo/odoo#100406

X-original-commit: 0420a0b6
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Current behaviour:
In the context of a multilevel contact hierarchy, if a contact is creating an SO, only that contact and it's commercial partner (usually the first company when going up in hierarchy from that contact) can see the SO.
The other contacts that are in that hierarchy could see the number of related SO on the smart button, but once clicking on it, no SO were shown.

Expected behaviour:
Every direct or indirect parent of a contact should be able to see the SO, as shown in the smart button count.

Steps to reproduce:
- Create 3 contacts with the following hierarchy: Company -> Contact 1 -> Contact 2 (Company is the root)
- Create an SO with Contact 2 as a customer
- On each of the contacts, click on the SO smart button, all of them have 1 SO shown on the button, but only Constact 1 has none shown once clicked. (Regardless if Contact 1 is an Individual or Company)

Fix:
Simplify domain search to only take into account the children's ids.
There is no need to make a distinction between a contact that is a company or not, since all commercial_partners are also partners by default.

Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- master

opw-2961030

closes odoo/odoo#100377

Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>

Steps to reproduce:
1- install eComerce app and activate debug mode
2- go to Website > Configuration > Websites
3- on a website product page extra fields tab add an empty line and save
4- visit any product page on the website (500: internal server error)

Bug:
adding an empty field crashes the website server on the product page

Fix:
made the field required

opw-2945621

closes odoo/odoo#100318

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

`l10n_in_gstin_partner_id` should be hidden on the journal form for non-Indian companies. It's probably also a good idea to hide `l10n_in_tin`in the country state form whenever the state added is not in India.
vat field on `res.company` should be renamed to GSTIN only when the company country is India.

task-2765567

closes odoo/odoo#99124

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

HOW TO REPRODUCE

Go on a record (e.g. a lead), open the full composer and use the "File / Image"
button from the editor to insert an image. After sending the attachment is
displayed in chatter. However after a few days it disappears, being garbage
collected.

ISSUE

When adding an image inside a mail composer via the /image command or 'image'
button of the editor, the related attachment was never processed. This makes
sense as we do not want to attach it to the resulting message(s). However as
the attachment res_id and res_model were never updated from the compositor in
which they originated, they would become dangling attachments and be garbage
collected the next day (or the in the next pass of the GC) by
'_gc_lost_attachments'.

The attachment keeps 'mail.compose.message' as res_model and 0 as res_id.
It is therefore considered as a lost attachment and removed by the garbage
collect of attachments. As image are inlined in the content (using a link
towards /web/image) they are not part of 'attachment_ids' given to the
'message_post' method and therefore not linked to the document by
'_message_post_process_attachments' whose job is to correctly set the
model and res_id of attachments linked to the composer.

An event was not called on uploading files in a media dialog. This means the
parent of html field didn't know of the new attachments which resulted in
attachments being linked to no record at all and not being garbage collected
later. This fix makes that call.

The attachments newly uploaded in media dialog are uneditable to prevent users
from unlinking attachments that are still used in the body of the composer
(causing the same issue).

Task-2860761

closes odoo/odoo#95537

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

Currently the exception is not logged using the logger meaning that the
only indication of the failure is the "module not loaded" error message.

Catching the exception to log it the proper way will help identifying
the cause of the issue, mainly for uninstall tests.

closes odoo/odoo#100372

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

Steps to reproduce:

  - Install `l10n_ar_website_sale` module

  - Go to shop (Argentinian website) and add a product to cart
  - Open cart and click on checkout
  - Click on Customize and disable `Show b2b fields` feature

Issue:

  Fields are no more displayed.

Cause:

  Since the b2b fields template (`address_b2b`) have customize_show set
  to `True`, it is possible for all countries to display/hide
  the b2b fields, but it should not.

  For Argentinian companies (for example), the b2b fields should always
  be displayed.

Solution:

  For frontend (Website shop): in address form, if website company
  country is Argentina, check if the address_b2b view is active and if
  not, enable it.
  For frontend and backend: on write of a view `address_b2b`, do not
  allow to disable it if have a website and website company
  country is Argentina.

opw-2941199

closes odoo/odoo#98084

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

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>