The selection function get_selection_class for the field classname has
obviously been thought to be overridable by subclasses in order to add
new selection classes if need be.

However, before this commit the method was passed directly to the
Selection constructor, which used the callable object directly. If it
was overridden by a subclass, the Selection object would still use the
same non-overridden callable instance.

With this commit, we give the name of the method instead of the
callable, which makes that the method is resolved after all overrides,
and therefore the resulting selection will be the overridden one.

closes odoo/odoo#122299

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

When duplicating the reco model, we want to counterpart entry lines to be copied as well.

closes odoo/odoo#122309

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

After commit 9bf54f09, we assumed that
the date field of a move was never empty. On the form view, it can be
(temporarily) empty though (before save), causing an error when trying
to read it.

We now don't try to recompute the name when the date is empty, thus
preventing the date field to be read in that method.

task-3326834

closes odoo/odoo#122260

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

Before this commit, the widget value was updated (based on the current
state) prior to updating the snippet UI. As a result, the widget value
reflected used the non-updated UI labels.

task-3112890

closes odoo/odoo#120569

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

If applied, this commit will solve the min-max issues for efaktur.

- invalid literal for int() with base 10: when we enter all characters
string in the min or max it will raise an error like this.

- Error is also raised when the min or max is blank and try to save the
record.

So, I have update the value as 0 if the min value or max value not
generated.

see - https://tinyurl.com/2lx9j2kr



Sentry - 3936020226

closes odoo/odoo#112850

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

Steps to reproduce:
Without being logged in,
complete the purchase flow on the ecommerce,
taking care to have a different billing
and shipping address.
If you change the delivery address,
you will get an access error.

Cause:
In some cases, we do not have access to
the `name` field of the `partner` record.

Solution:
Add `sudo` to be able to read the fields.

opw-3276877

closes odoo/odoo#122121

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

Steps to reproduce the bug:
- Install mrp and purchase
- Create a new user “U1” > give him only the “purchase” user access
- Log in as “U1”
- Go to purchase app > create a new PO
- Try to select any product

Problem:
A user error is triggered because we check if the product has a BOM
but since the user does not have access to MRP, an error is raised

opw-2885982

closes odoo/odoo#94183

closes odoo/odoo#121371

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

closes odoo/odoo#122220

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

Turn the call to filtered after the search on purchase.order.line
into a call to _search. This allows to remove filtered by adding
an additional leaf in the search domain.

Add read calls to fetch fields from db and store them in cache
on recordset batches.

Example speedup: partner with 136555 POL 6.33s -> 3.42s

opw-3277299

closes odoo/odoo#120658

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

qty_received_method is not recomputed if the product type change, and can lead to issues on existing purchases when trying to generate a Vendor Bill.

# HOW TO REPRODUCE:
- Create product P, type: Service, Control Policy: 'On Received Qty'
- Create PO for 1 unit of P (do not confirm)
- Update type of P to Storable
- Confirm PO, Receive Products
=> Qty Received is 0, not able to generate Bill

closes odoo/odoo#119622

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

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>