*: 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>

To Reproduce
============
- create two Vendor Bills and attach to each one a PDF from the ones
provided by the client on the ticket.
- select these two bills and and try to print Original Bills an error will be raised

Problem
=======
while merging these PDFs, PyPDF2 throws a `TypeError` which is not caught by the server

Solution
========
catch `TypeError` to raise a UserError

opw-3285540

closes odoo/odoo#120756

Signed-off-by: abla001 <abla@odoo.com>

before this commit, in the mobile view, in the search bar
of the website users(forum) and events leader board,
the placeholder is shown as Search courses

after this commit, the wrong placeholder will be updated
to Search users in the placeholder as in the normal view.

closes odoo/odoo#115131

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

Purpose
=======

Avoid mismatch between contracts from different companies and clarify
error message.

closes odoo/odoo#75553

closes odoo/odoo#120650

Related: odoo/enterprise#19647
Related: odoo/upgrade#2777
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Steps to Reproduce Issue for single picking:
1. Install Sales, Inventory
2. Create an SO and confirm
3. Go to the transfer, assign the done value to be less than demanded
4. Validate the transfer and cancel the backorder

Current Behavior:
There is no exception error on the SO chatter

Expected Behavior:
An exception error should be logged on the SO chatter

Other Info: When cancelling a backorder for a single picking,
the exception error about less quantity than expected is not logged on the SO.
"process_cancel_backorder" does not call _log_less_quantities_than_expected.
As defined in "process", the exception is only logged when validating multiple pickings at once but
one is to backorder but the other is not.

opw-3222508

closes odoo/odoo#120043

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

Before this commit
==================
when SO is confirmed and Delivery is created then add the shipping method
in SO, in this case, the shipping carrier is not set in the existing undelivered
delivery of that SO.

After this commit
=================
So in this commit, we set the shipping carrier for undelivered delivery.

taskId - 2946360

closes odoo/odoo#116533

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

Steps to reproduce the bug:
- Connect with the company A
- Create a consumable product “P1”
- Create a receipt transfer with this product
- confirm the transfer
- Come back to the product form
- limiter le produit que a la “Company B”

Problem:
no user error triggered
Go to inventory > operation > transfer: a Traceback is triggered

Before this commit, there is no verification while changing a product's
company for consumable. That can lead to an issue where some operations
cannot be done because of access errors. To avoid that, this commit
prevents to change the product's company if some move lines for this
product exist in another company.

opw-3300559

closes odoo/odoo#120702

Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

Issue 1: before this patch it was impossible to create a manual model
marked as "Is blacklist". The reason is that a blacklist model
implicitly need an `email` field, but such field is impossible to add in
a manual model: the field must start with `x_`.

Solution: append `x_` to the implicit email field. Note, in principle
the user gets an error if `x_email` is not present. Solved by adding the
field when creating the custom model. Ideally we should show some hint
in the interface to make it more user friendly. That is out of the scope
of this patch.

Issue 2: when we have a manual model that is mail blacklist it's
impossible to create its model class. We get an error because the MRO is
not correct. The reason is that we are adding `mail.thread.blacklist`
_after_ `mail.thread` in the `_inherit` list. That list is used to
generated the `__bases__` of the model class[1]. According to Python's
MRO rules[2], since `mail.thread.blacklist` appears after `mail.thread`
as parents of the custom model class this order _must_ be respected. But
`mail.thread` must appear _before_ `mail.thread.blacklist` because the
latter inherits from the former. This is a contradiction and the MRO
algorithm cannot succeed. To put it in a simple example:
```py
class A: pass
class B(A): pass
 # This fails:
 # class C(A, B): pass
 # The right order is:
class C(B, A): pass
 # Equivalent to:
class D(B): pass
 # C and D have the same MRO linearization excluding themselves
assert D.mro()[1:] == C.mro()[1:]
```
Example traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 464, in load_modules
    registry.setup_models(cr)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 263, in setup_models
    env['ir.model']._add_manual_models()
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/ir_model.py", line 430, in _add_manual_models
    Model = model_class._build_model(self.pool, cr)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 585, in _build_model
    ModelClass.__bases__ = tuple(bases)
TypeError: Cannot create a consistent method resolution
order (MRO) for bases BaseModel, mail.thread, mail.thread.blacklist, base
```

Solution: check if a model inherits from `mail.thread.blacklist` first.
There is no need to add `mail.thread` if inheriting
`mail.thread.blacklist` because the inheritance is already implicit.

This issue was observed during upgrades. We convert custom models and
fields into manual to allow upgrading without custom code. This causes
issues because the MRO error appears when a custom model inherits mail
blacklist.

[1]: https://github.com/odoo/odoo/blob/02f820fb0eaddbb3a4269a0967184c8aaf52c363/odoo/models.py#L585
[2]: https://www.python.org/download/releases/2.3/mro/



closes odoo/odoo#119169

Signed-off-by: Christophe Simonis <chs@odoo.com>

This issue is generated when the user uploads an image of more than
50.0 million pixels, so error would be generated. But, currently it raises a
`ValueError` which results in traceback. So, we replace it with
`UserError` so the user has an idea about Image size or pixel being excessive.

closes odoo/odoo#118281

Sentry: - 4075426049
Signed-off-by: Rémy Voet <ryv@odoo.com>

When receiving an email on a mailbox with an alias that triggers the
creation of invoices, 4 bugs could occur.

1. If the xml received contains replacement characters (U+FFFD �), and
the charset of the part of the email is "US-ASCII" the encoding of the
string will fail, preventing the rest of the flow to be completed. Be
more resilient, encode the string and ignores these characters if this
case occurs.

NB: sometimes, the charset is omitted for a Content-type: text/xml. This
is valid but not recommended (see:
https://www.ietf.org/rfc/rfc2376.txt). In this case, the default used is
"US-ASCII". This means that any non-ascii char will be lost (they are
replaced by the replacement character: �, see:
https://github.com/python/cpython/blob/3.10/Lib/email/contentmanager.py#L67

)
when decoding the attachment.

2. When the xml attachment is created in Odoo, the mimetype is
'text/plain' (rather than 'application/xml'). Thus, the
`_decode_attachment` needs to be more flexible when guessing the type of
the attachment (to know which function to use to read the content of the
attachment and create the invoice).

3. When creating an invoice from an email with an xml attachment, the
xml is attached as the `message_main_attachment_id`. It's only later on
that the content of the xml is read and we possibly find the PDF in
base64 inside. When creating the PDF attachment, it was not set as the
`message_main_attachment_id`, so the PDF was not rendered on the right
part of the invoice form view. Add a clause to replace the
`message_main_attachment_id` in such a case.

4. When the xml attachment represents a credit note, the move_type of
the invoice created by the email alias needs to be changed. Indeed, the
invoice is created before decoding the attachment, so we can only change
the `move_type` later.

opw-3144519
opw-3149649

closes odoo/odoo#119602

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

task - 3293181

closes odoo/odoo#120064

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

closes odoo/odoo#116578

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

If applied, this commit will handle the KeyError: res_id when the user tries to
import the translation of .csv file in settings -> translations, and if .csv
file doesn't have the res_id column.

I handled the traceback by changing the logger level to warning.

sentry - 4049419481

closes odoo/odoo#119511

Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>

closes odoo/odoo#95123

Signed-off-by: Rémy Voet <ryv@odoo.com>

There is a historical code to return an error/404 when someone disable
the website info view, see [1].
There is also a feature introduced to add an option to disable the
content of this controller, see [2].
Commit [2] should probably have gotten rid of the view check in [1]
which was probably the way people used to stop this page leaking their
DB information.

From there, regardless if you deleted or disabled the view, the page
would still be referenced in the sitemap.xml, which would lead to a
traceback page (case 1) or a blank page (case 2).

This commit is simply conditionning the presence of this page in the
sitemap so it's removed from it if you disable/remove the website info
view.
It will help SEO wise to not have error page in it.

Note that we probably don't want to keep indexing this page, as it is
a technical link which doesn't bring any value to our clients to be
included in their sitemap.
It might have been useful for Odoo to perform some google search / stats
or something like that.
But since this is a stable fix, the behavior is kept as is as much as
possible.

Also note that it has always been in sitemap, even if marked
excplicitely since [3].

[1]: https://github.com/odoo/odoo/commit/8aca457e34bdec6257b9bfa917aebe4de053e2aa#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119R146-R149
[2]: https://github.com/odoo/odoo/commit/f025d3e17cbb3b1fd05152ca46af091b6e11ee20
[3]: https://github.com/odoo/odoo/commit/e19227d3ba9c9296bfc0c221ac70a863a571b9a6#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119L200



opw-3255831

closes odoo/odoo#120336

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

The website info page was introduced with [1] where the code was
apparently checking for the existence of the view (to be rendered) to be
able to handle a proper error if it did not exists.
It seems like it was to support the case where someone would delete this
view to not leak any info on the public controller. But it's uncertain
as this code is 10 years old.

It was a year later improved with [2] to have an option on the page to
be able to sort of disable it: it would simply show a blank page but it
would still be served.

As of now, the `try/except` with the `get_template()` call is crashing
and rendering traceback whenever this view is deleted, making this code
useless and not doing anything.
It's probably not needed anyway since the option introduced with [2] but
as we are in stable, this commit is making the controller return a
proper 404 page instead of a traceback.
Arguably, that part of the code could be removed. We will do it in the
master forward port.

[1]: https://github.com/odoo/odoo/commit/8aca457e34bdec6257b9bfa917aebe4de053e2aa#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119R145
[2]: https://github.com/odoo/odoo/commit/f025d3e17cbb3b1fd05152ca46af091b6e11ee20

opw-3255831

Part-of: odoo/odoo#120336