Avoid unwanted update of product_tmpl_id on product.product

Somehow, the field product_tmpl_id on product.product could be updated
to an unrelated product template, if the context key `default_product_tmpl_id`
is set when an inventory move is created through an update of
stock.quant.inventory_quantity.

Setting readonly to True on both stock.quant and stock.move product_tmpl_id
field prevents this unwanted update.

closes odoo/odoo#104602

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

The code was assuming there would be only one `<footer/>` element in the
dom but it's not always true.
Our `Blockquote` snippet also contains a `<footer/>` element.

While this has no impact on Odoo 14 and Odoo 15, it will crash in Odoo
16 when trying to select "On all pages" on a popup option when there is
a blockquote snippet on a page.
The reason it breaks in 16 is because it uses javascript instead of
jquery, finding only one element (the footer of the blockquote) and not
all. The jQuery usage was then filtering out to only keep the correct
footer due to some extra selector looked for in the elements
(`.oe_structure:o_editable`).

Still, the fix is made in Odoo 14 because it's likely that we will have
another fix later in the snippet options, and it's also likely that
someone will replace the jQuery usage by javascript while doing so,
which would reveal the bug.

opw-3283140

closes odoo/odoo#121848

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

Before this commit, the reversal of a passed exchange
move was not created on the correct date:

- If sequence is reset by month, the reversal should
  be created at the end of the month of the exchange
  move, and if sequence is reset by year, at the end
  of the year.

Steps:

- With a foreign currency X activated and two different
  rates few months in the past.
- Create and confirm an invoice with currency X at the
  date of the first rate.
- Register a payment at the date of the second rate
  (an exchange move is created).
- Unreconcile the payment from the invoice.
-> A reversal of the exchange move is created, but the
   date is wrong (set to today's date).

opw-2856385

closes odoo/odoo#121279

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

1.

Infinite loop may happen on using `parent_of`\`child_of` when there is a
recursion in the tree (e.g. a record is marked as a parent of itself). Fix it by
excluding seen records from the next iteration.

2.

Another problem with `child_of` is `parent_id` that references to another model.
For example, the `parent_id` may come from inherited model. It's the case with
`res.users` and `res.partner` models. It may lead to a random search results.
Avoid that by raising exception in case of wrong usage of the `child_of`
operator.

STEPS:

In demo data, there is a partner called "Wood Corner" that is `res.partner(9,)`
that has 3 sub-contacts. If we give Portal access to two of them, we end up with
a database, where we have a `res.users(9,)` record that has a partner, which has a
`parent_id` to "Wood corner". So this way, the user id is the same as the user's
partner's parent contact id.

After that open a shell and type:

```
env['res.partner'].search([["user_ids", "child_of", 9]])
```

BEFORE: infinite loop (without change n.1) or random search results (when change
n.1 is applied)
AFTER: ValueError exception

---

opw-2729740

closes odoo/odoo#89316

Related: odoo/enterprise#41330
Signed-off-by: Raphael Collet <rco@odoo.com>

A float division by zero error is generated on the log, and nothing
is imported from the file when the user uploads an XML file like
https://drive.google.com/file/d/1_eZYfqMk2kLtPsEjv-13DRHnmoXkWYeE

.
This is because here in LineID 1, there is a value billed quantity is 0.0,
a charge amount is 0.0, and a total amount is 100.0. This is wrong;
the total amount is always 0.0 when the billed quantity is 0.0
(billed quantity * charge amount).

This commit solves the above issue by dividing a price subtotal
by one when the billed quantity is zero.

sentry-4157357719

closes odoo/odoo#121027

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

It takes 70s to generate a receipt with 2000 serial numbers.

It happens because during the first part of the loop
(model `stock.move.line` in the `create` method).
It will update the initial demand of the move based on the new
stock.move.line and their qty_done.
Writing the initial demand of the `stock.move` will try to reassign
it (useless in our case) and rewrite the same value on its state's field.
The consequence is the invalidatation of the field on
the `stock.move.line` because it's a related to the `stock.move`.
In the second part of the loop, it check the sml state. Since it
was invalidate upper, it recompute it. That prevent a correct prefetch
and cause a performance issue.

We fix it by writing only once the information by move. And it
prevent the recompute later since the state is not write during the
loop.

closes odoo/odoo#121966

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

With the name calculation change in
9bf54f09, we missed the case to
recompute the name of a move on a journal change. It seems a test case
for this was missing an assert.

This commit fixes the behavior, so the move name is now correctly
recomputed again when changing the journal. The test has also been
amended.

task-3326834

closes odoo/odoo#121920

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

Steps to reproduce:
In an account move, if the partner_id is changed to one that does not have a value assigned in the property_purchase_currency_id field and with a value in the context for default_currency_id,
when passing through the _onchange_partner_id function of the purchase module,

Cause:
the variable currency_id will take the value in the context as second option causing an error when trying to get the value in currency_id.id because currency_id will be an integer and not a record.

issue-121232

closes odoo/odoo#121620

Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>

For performance reasons, instead of extracting the whole
zip, extract only the files which are actually used
during in the `_import_module`, in case people
put additional crap in the archive which are ignored
during the import. That way, we avoid useless I/O.

Also, adding the temporary directory in the addons
path wasn't thread-safe.
This revision changes this to make the module
import feature thread-safe.

closes odoo/odoo#80120

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

An UBL Bis 3 xml can only contain one tax per invoice line. However,
there might be one or more ecotaxes on invoice lines in Belgium. Do not
block the user from generating the attachment in this case.

Note that PR https://github.com/odoo/odoo/pull/121494

 will properly
handle the fixed taxes upon generating UBL attachments.

opw-3318969

closes odoo/odoo#121833

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

When performing the picking action in the context of savepoint, the env
inside the action can randomly change causing an AccessError which is
caught as UserError (in the current point_of_sale code). Flushing before
calling a method in a savepoint will deterministically avoid this issue.

Note that the weakset used to store environments was modified in #121604
to avoid this kind of issue.

When using a cr.savepoint, the transaction must be flushed but in we
don't have any reference to the env that should be used on the cursor,
meaning that the env is chosen in the list of existing env. This choice
is random because Transaction.envs is using a Weakset.

In some case, the chosen env does not have the correct access right
because the context allowed_company_ids is corresponding to a company
coming from another test, leading to an access error, hidden by the try
except.
Flushing the environment before creating the savepoint will help to
prevent this issue by flushing on a well defined environment.

Note that the weakset used to store environments was modified in #121604
(master)

closes odoo/odoo#121659

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

Currently, when we create a draft move in an empty period, a sequence
number (name) gets generated and set on the move. This is fine.

When subsequently we change the date of that move to a period that
already has entries in it, the sequence number (name) for our draft move
is recalculated according to the new period.

When we post a new move in this same period afterwards, and then
delete our previous draft move, we are left with a gap in the sequence.

Example: We already have a move on 2023-01-01 with name `2023/01/0001`.
We add two new moves `A` and `B` as follows.

| Step | Move | Action      | Date       | Name           |
| ---- | ---- | ----------- | ---------- | -------------- |
| 1    | `A`  | Add         | 2023-02-01 | `2023/02/0001` |
| 2    | `A`  | Change date | 2023-01-10 | `2023/01/0002` |
| 3    | `B`  | Add         | 2023-01-15 | `/`            |
| 4    | `B`  | Post        | 2023-01-15 | `2023/01/0003` |
| 5    | `A`  | Delete      |            |                |

A gap is now created, since we have `2023/01/0001` and `2023/01/0003`,
but `2023/01/0002` was deleted (possible since it was in draft).

To solve this issue, we now make sure that when a draft entry is moved
to a period that already has entries in it, we reset the name to `/`,
to not consume a sequence number and prevent possible gaps in the
sequence later on.

task-3326834

closes odoo/odoo#121565

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

The visibility of the "Print" DDT button wasn't taking into
consideration the dropshipping case.

closes odoo/odoo#110398

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

Have an IT company configured
Activate Dropship
Create a Product P with dropship enabled and vendor configured
Create a quotation to an IT customer, add P to a line, confirm.
Purchase will be created automatically, confirm it.
Go to dropship picking, confirm, print

The DDT report does not show up correctly:
- Warehouse address is the company address
- Customer address is the vendor address

opw-3128812

Part-of: odoo/odoo#110398

Steps to reproduce the bug (before the commits of this PR):
- Drop a Cover snippet on the website.
- Change the parallax to "None".
- Save and edit.
- Modify an option (for example, add a filter) to add the
`o_modified_image_to_save` class to the image.
- Change the parallax to "Fixed".
- Save.
- Inspect the Cover snippet.
=> The `span` element has the attributes `data-snippet="s_cover"` and
`data-name="Cover"`. Note that this could lead to problem during the
migration process.

Let's analyze the process  in order to better understand the problem:
- At the change of the parallax to "None", there is a change of the
target thanks to the call to `setTarget()`. The new target is now the
`section` element.
- At the save and edit, there is a call to `_loadImageInfo()`. All the
dataset (including `data-snippet` and `data-name`) of the new target is
copied in `this.img`.
- At the modify of an option, the `o_modified_image_to_save` class is
added to `this.img`.
- At the change of the parallax to "Fixed", there is a change of the
target thanks to the call to `setTarget()`. The new target is now the
`span` element.
- At the save, `cleanForSave()` is called and because there is the
`o_modified_image_to_save` on `this.img`, all the dataset of `this.img`
(including `data-snippet` and `data-name`) is copied on the new target
(the `span` element).

Note that this problem is resolved by the second commit of this PR.
Indeed, the dataset of the target is first filtered by
`_whiteListAttributes` before being copied into `this.img`. However,
databases that already have the problem will not be fixed by. The goal
of this commit is to remove the `data-snippet="s_cover"` and the
`data-name="Cover"` from the `span` elements in those existing
databases.

task-3287330

closes odoo/odoo#119596

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

*: web_editor, website

Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Put a "Blur" filter on the background image.
- Save.
- Change the parallax from "Fixed" to "None".
- Save and edit.
=> The "Filter" option displays "None" but should display "Blur".

When changing the parallax, `setTarget()` is called. The goal of this
function is to transfer the `background-image` from the old target to
the new one. The commit modifies this function by adding the transfer of
the dataset information relative to the background image from the old
target to the new one. It also transfers the `o_modified_image_to_save`
class from the old target to the new one if needed.

task-3287330

Part-of: odoo/odoo#119596

For background images, modifying options such as "Filter" does not
directly lead to the modification of their corresponding data attributes
in the DOM as those modifications are done at the save request. This
should not be the case. The goal of this commit is to, as for regular
images, modify their corresponding DOM data attributes at the option
update.

Steps to reproduce the bug:
- Add a Cover snippet on the website.
- Replace the background image by one of your own.
- Add a filter to the background image.
- Inspect the Cover snippet.
=> The `data-gl-filter` attribute has not been added in the DOM and you
have to click on "Save" for it to be actually added.

task-3287330

Part-of: odoo/odoo#119596

Steps to reproduce the bug:
- Add a cover snippet on the website.
- Change the background image with one of your own.
- Save and edit again.
=> Options such as "Filter", "Width" and "Quality" do not appear
anymore.

The problem is that the `src` attribute of the background image is not
correctly updated when initializing the image. This is because the
target used to recover the URL of the background image is the snippet
and not the image itself. This problem is resolved by ensuring that the
argument of the function `getBgImageURL` is the background image. Now
that the `src` attribute is correctly updated, the `computeVisibility`
function of the the `BackgroundOptimize` option works properly and the
options "Filter", "Width" and "Quality" are displayed as wanted.

Note that now, the dataset of the target is filtered with a "white list"
(BACKGROUND_IMAGE_ATTRIBUTES) before being copied in the dataset of
`this.img`. Indeed, if the parallax is set to "None" for example, we do
not want data attributes such as `data-snippet` to be copied in the
dataset of `this.img`.

task-3287330

Part-of: odoo/odoo#119596

On this situation:
* P1 consumable product, kit, with components P2 and P3 in its BoM using
  1 of each
* P2 comsumable product, kit, with component P3 using 1 in the BoM
* P3 storable product, 10 units in stock

Before:
The qyt_available for P1 is 10. That's incorrect: to assemble one P1 we
need precisely two of P3s, one for P2 BoM then an extra for P1 BoM.

After:
The qyt_available for P1 is 5.

closes odoo/odoo#120752

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

[IMP] stock: unreserve only quantity required if available quantity is less than quantity required when action_done on stock move.

Example:
Now there is this behaviour
Inventory quantity 4
Reserved quantity 3
Available quantity 1
If i do a stock move of 2 pieces, it will unreserve ALL the stock move of the product.

With this PR it will unreserve only the pieces that are required minus the available quantity not reserved , in this case 2 (new stock move) - 1 (available quantity) = 1

closes odoo/odoo#119999

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

closes odoo/odoo#120501

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

[FIX] stock: _log_less_quantities_than_expected call _log_activity_get_documents with empty dict and raises error

closes odoo/odoo#121570

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

Current behaviour:
When the language is not set on the user date_format value
is False so when opening project tasks we get the following traceback

Error:
Odoo Server Error

Traceback (most recent call last):
  File '/Users/nea/src/odoo/odoo/addons/base/models/ir_http.py', line 237, in _dispatch
    result = request.dispatch()
        ....
  File '/Users/nea/src/odoo/addons/project/models/project.py', line 798, in _compute_recurrence_message
    task.recurrence_message += '<li>%s</li>' % date.strftime(date_format)
Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File '/Users/nea/src/odoo/odoo/http.py', line 650, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File '/Users/nea/src/odoo/odoo/http.py', line 317, in _handle_exception
    raise exception.with_traceback(None) from new_cause
TypeError: strftime() argument 1 must be str, not bool

Expected behaviour:
- Open projects tasks with no problem

Fix:
- to fix the problem we use get_lang() to retrieve the language object for the current use

Affected versions:
- 14.0
- 15.0
- 16.0
- master

opw-3301081

closes odoo/odoo#120555

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

When passing a very large expression to `literal_eval`, the odoo server crashes.
To avoid this behavior, a limit needs to be set by using the env varaible `ODOO_LIMIT_LITEVAL_BUFFER`.
If the variable is not set, it defaults to 100Kib.

closes odoo/odoo#121530

Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

When a new user is created from the website, the company id was always
set to the first company of the database even if the website was the one
of another company. This flow has been already fixed if there is the
"Specific User Account" setting activated (see [this other commit]).
This commit fixes the same issue but for every case.

Steps to reproduce the issue:
- Create 2 companies A & B
- For each company, create a website linked to a different URL
- Activate 'Free sign up' for company B
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account

=> If as an admin you check the company of the created user, it is
company A instead of company B.

[this other commit]: https://github.com/odoo/odoo/commit/77c708c516beb322df37220634e178ba82e894c9



task-3277317

closes odoo/odoo#120475

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Current behavior:

Connections for outgoing email servers using Outlook/Office365 or
Gmail accounts will establish an OAuth2 authentication for the smtp server.
Through the `ir_mail_server` form view, one can fetch the necessary
tokens by logging in into their Microsoft/Gmail account.
Not specifying an username (`smtp_user`) on the `ir_mail_server` record
will not produce an error while fetching those tokens.
But when trying to test the connection or use that server to send an email,
even if the FROM header is correctly set (i.e. the account email address
authorized to sent emails), the smtp connection will fail. This is due
to the fact that when `smtp_user == False`, the respective method
`_generate_outlook_oauth2_string` or respectively `_generate_oauth2_string`
will not be called and send the necessary OAuth2 string when sending
an email through the smtp connection.
This will lead to a `5.7.57 Client not authenticated to send mail.` error.

After this change:

Add specific UserErrors that get called if `smpt_user == False` before
the actions in `open_google_gmail_uri` and `open_microsoft_outlook_uri`
get called. This forces the user to input a `smpt_user` (field Username)
before the login page for OAuth2 gets called to fetch the tokens.
Note: there is no check if the user inputs the right username, only
that the field is not empty. So it is still possible to input an
invalid username.

opw-3268246

closes odoo/odoo#121048

Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

The note "Quotation viewed by customer" posted when a public/portal user
access an order came with the order's partner name instead of the actual
user's partner name

This made confused for internal users to see something in internal note
like **Colleen Diaz** with a message **Quotation viewed by customer
Nicole Ford**

This commit makes sure to use the right partner name except the
quotation is viewed anonymously (with access token)

closes odoo/odoo#121490

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

- Create a Deferred Revenue Model on a Current Liability account
- Create a Sale Order yourself (User 1), with Salesperson User 2
- Create the invoice from it
- Remove the salesperson from the invoice and add User 3 instead
- Change the account to the Revenue Model's one
- Post the invoice
- Post the deferred revenue created
=> User 2 is follower of the entries generated

The problem is that the context comes from the sales order, and
contains a `default_user_id` in the context.
The solution provided is to remove it from the context given, as
it serves no purpose (the invoices are already created).

opw-3141495

closes odoo/odoo#120419

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

When unit prices have more than 2 digits, it is currently not reflected
in the UBL formats. Consequently, the line amounts are not equal to the
unit price * quantity (assume there is no discount, charges or
allowance) and it raises validation errors: "Invoice line net amount
MUST equal (Invoiced quantity * (Item net price/item price base
quantity) + Sum of invoice line charge amount - sum of invoice line
allowance amount".

To fix this, we no longer round the unit prices.

NB: the decimal accuracy should be set in the settings (otherwise, the
default is 2 digits for unit prices).

See https://docs.peppol.eu/poacc/billing/3.0/bis/#_rounding



opw-3290035
task-3302904

closes odoo/odoo#120821

Signed-off-by: Laurent Smet <las@odoo.com>

Steps to reproduce:

- Go to a website page > Add a 'Form' block > Set an input "Placeholder"
value.
- Go to the page (in 'edit_translations' mode) > The translation of the
input "Placeholder" attribute doesn't mark the input as translated and
even after saving the translation, the input is still marked as
"to_translate".

The goal of this commit is to fix this issue by extending the same
behaviour on the translated `<select/>` options (using `.oe_translated`
class) and setting the right translation state on the input from the
linked attribute translation `<span/>`.

task-3323245

closes odoo/odoo#121128

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

This commit fixes a bug with the navbar links in the header of a website
on mobile. When the text of a link is long enough to be wider than the
screen, the text does not wrap to the next line as intended, but instead
overflows to the right outside of the screen, causing part of the text
to be hidden.

Steps to reproduce the bug:

- Edit the text of one of the menu links on a website to make it longer
than the width of the mobile screen.
- Bug: In mobile view, part of the link text is hidden.

This bug occurs with both the "default" hamburger type and the
"off-canvas" hamburger type.

opw-3233684

closes odoo/odoo#119998

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

The commit [1] was recently merged with a bug, and this commit fixes it.

The bug is due to the fact that when comparing the current page to a
redirection with an anchor, we added a trailing slash if it was missing
for the current page but not for the redirection. In some cases, this
resulted in unintended behavior where the user was redirected to the
same page instead of just scrolling to the anchor on the current page.

Steps to reproduce the bug:

- Open the "contact us" page in edit mode
- Drag and drop a snippet below the form and create a link to that
snippet by clicking on the "anchor" option button of the snippet.
- Change the form redirection option to redirect to this newly created
anchor upon form submission by copying the contents of the clipboard
into the input of the option.
- Save the page.
- Fill out the form and click the submit button.
- Bug: The page is reloaded instead of smoothly scrolling down to the
bottom snippet without reloading the page.

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



task-2172312

closes odoo/odoo#120907

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

For performance reason, we avoided computing goals for the set of users
that didn't log in recently (See ec0c0f29).
However, users can stay logged in for a while without having a new "log
in event" (password asked), such that active internal users can keep
old values in their challenges when reports are sent, which is not good.

Until an improvement can be implemented in master, we drop this time
constraint for active internal users.

A test is added, checking the behavior of the method called by the cron.

Task-3226408

closes odoo/odoo#119271

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

Problem: The error "There is no chart of accounts installed for this company..." appears for POS shop configurations
if they don't have a chart template configured for the company. It doesn't take into account if the company has its
own set of accounts so it will always show the error unless the chart template is set.

Solution: Include an additional condition to check if the company has accounting entries which is used to check
if the company has used its own set of chart of accounts for accounting.

Purpose: The error will only appear if the company has no chart template set or no accounting entries.

opw-3291399

closes odoo/odoo#119901

Signed-off-by: Laurent Smet <las@odoo.com>

product variable used in the rounding precision come from the upper
loop and won't work for all the quantites.

opw-3229080

closes odoo/odoo#120680

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

mimic what is done for `odoo.addons` __path__.

closes odoo/odoo#121136

X-original-commit: 2a981e6a
Signed-off-by: Christophe Simonis <chs@odoo.com>

Allow extending tests for any modules, regardless of existing ones
in another entry of the `upgrade-path`.

Bonus point: tests no longer need to be imported in the `__init__.py`
file.

closes odoo/odoo#121207

X-original-commit: 4ab8b28b
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>

When no new template are created in the update of taxes migration method
the execution lead to an an error in the `_process_taxes_translations` method.
Fixed a similar issue in l10n_ch migration that enables the taxes afterward
and could possibly cash in the same way if no taxes are created.

opw-3305302

closes odoo/odoo#121184

Signed-off-by: John Laterre (jol) <jol@odoo.com>