The revision dd3f918c
introduced a regression:
it was no longer possible to set an icon in the import module,
and if no icon is provided,
the icon should fall back to the base module icon,
which wasn't the case either.

In this last case, it even leaded to a crash:
```
File "/home/odoo/src/14.0/odoo/odoo/addons/base/models/ir_module.py", line 251, in _get_icon_image
    with tools.file_open(path, 'rb') as image_file:
  File "/home/odoo/src/14.0/odoo/odoo/tools/misc.py", line 176, in file_open
    return _fileopen(name, mode=mode, basedir=base, pathinfo=pathinfo, basename=basename, filter_ext=filter_ext)
  File "/home/odoo/src/14.0/odoo/odoo/tools/misc.py", line 211, in _fileopen
    raise ValueError("Unknown path: %s" % name)
Exception
ValueError: Unknown path: /base/static/description/icon.png
```

opw-3340652

closes odoo/odoo#124307

Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

There is already a currency rates created in the demo data
(base/data/res_currency_rate_demo.xml). Tests that create new rate may
produce duplicates.

This commit removes all currency rate before the test to make sure we
avoid duplicates.

This is a backport of 08c43ebf

closes odoo/odoo#123837

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

Description of the issue/feature this PR addresses:
Before SII resolution 46 from 2022, the only documents for foreign vendors were 110 111, and 112.
After that, SII and accountants are indicated as a practice to issue purchase invoices (Factura
de compra 46) to foreign vendors in order to pay the vat taxes, mainly for digital services.

Current behavior before PR:
It is not allowed by validation restrictions to issue this document type to foreign vendors

Desired behavior after PR is merged:
the validation release the restriction for document type 46

closes odoo/odoo#121591

Signed-off-by: Josse Colpaert <jco@odoo.com>
Co-authored-by: Daniel Blanco <daniel@blancomartin.cl>
Co-authored-by: José Moreno Hanshing <jose@blancomartin.cl>

closes odoo/odoo#123996

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

*: web_editor

During the masonry layout calculation of the images wall snippet, the
image height is used to determine into which column each image is
inserted. Their height is zero until they are actually loaded. Because
of this, the column into which an image is inserted can be wrong.

This becomes more obvious in 16.0 because since [1] the image selection
is lost when moving it within an Image Wall because it is replaced by a
clone when using masonry mode.

This commit makes sure that the images are loaded before taking their
height into account when building the masonry layout.

This involves two changes:

1. By awaiting `wUtils.onceAllImagesLoaded(this.$target)` after the
insertion of each cloned image, we are sure that the reached height of
each column is available before deciding where to insert the next image.

2. Before re-selecting the previously selected image, we need to be
sure that it is loaded. Therefore we keep track of the last masonry
layout operation and await for it. This way, we rely on the await of
the last image as described in point 1.

Additionally, as of 16.0, there is a race condition with
`snippet_option_update`: in some situations, `notify` is called before
`snippet_option_update` is completed, and before the masonry layout is
applied.  To make sure it is completed, the whole notify is run within
the mutex through a `snippet_edition_request` event.

To uphold the stable policy, making `mode` async will only be done in
master.
In stable, a new `_modeWithImageWait` is added which is called only
for the situations that causing an issue, and which enables the fix
of the masonry layout.
In 14.0, it is used when computing the layout from `start` and
`addImages`.
In 16.0, it is also used in `notify` when images are removed or moved
around - because masonry clones the images.
In master, it is always applied.

Additionally, this commit also rounds the computed size of images inside
the masonry layout calculations.

Steps to reproduce:
- Drop an Images Wall.
- Add four images, the first one being taller than the others.

=> The fourth image sometimes appeared below the tall image.

[1]: https://github.com/odoo/odoo/commit/0d43aec24baad6420e0fe150a9c19d33c0b74198



task-2990053

closes odoo/odoo#120523

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

Inside the Images Wall snippet, images are dispatched to columns
depending on the height already reached by each column. This computation
relies on a sub-pixel height which leads to a confusing behavior.

This commit rounds the sub-pixel height to a visible pixel height to
avoid the confusion.

Steps to reproduce:
In the default images of the Images Wall snippet, the third image (sign)
is one pixel taller than the other ones.
- Drop an Images Wall snippet.
- In 14.0, upload the default images from v15.0.
- Select the "sign" image.
- Move it to the previous position.

=> The sixth image (wine glass) moved as well.

task-2990053

Part-of: odoo/odoo#120523

When using the previous button in an image wall, the image wraps around
but skips the last position.
When using the next button in an image wall, the image does not wrap
around.

This commit fixes this inconsistency by using the same behavior as the
one in 15.0 since [1]: wrap through all positions in both directions.

Steps to reproduce:
- Drop an "Images Wall" snippet.
- Add 6 images.
- Select an image.
- Click repeatedly on "Move to previous".

=> The image wraps around all positions except the last one.

- Click repeatedly on "Move to next".

=> The image does not move anymore once it reached the last position.

[1]: https://github.com/odoo/odoo/commit/3931f0a67f904daea6c891a3a80aa984760a7682

task-2990053

Part-of: odoo/odoo#120523

A rate of 17.5 is wrong for standard rate purchases in Ireland.
The standard Sale and purchase VAT have an amount of 23.

closes odoo/odoo#124078

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

When there are too many (millions) of POS order lines associated to
opened POS sessions we get too many taxes, most are duplicated. This
causes a MemorryError.

Example queries from a real DB:
```
> select count(distinct r.account_tax_id) from pos_order_line l join pos_order o on o.id = l.order_id join pos_session s on s.id = o.session_id join account_tax_pos_order_line_rel r on r.pos_order_
 line_id = l.id where s.state != 'closed'
+-------+
| count |
|-------|
| 24    |
+-------+
> select count(r.account_tax_id) from pos_order_line l join pos_order o on o.id = l.order_id join pos_session s on s.id = o.session_id join account_tax_pos_order_line_rel r on r.pos_order_line_id =
  l.id where s.state != 'closed'
+---------+
| count   |
|---------|
| 2504539 |
+---------+
```

opw-3295467

closes odoo/odoo#124180

X-original-commit: 45d19b265033aa626e110e51d8b1d01408717a3e
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>

We have many issues with this log, except that with a `logger.error` we
do not have exception information (exc_info).

As mentionned in the documentation above, we cannot use `logger.exception`
in this case because we are not within an exception handler.
However, we can still retrieve the exception information using `sys`
module and the `exc_info()` method.

https://docs.python.org/3/library/logging.html#logging.Logger.exception
```
exception(msg, *args, **kwargs)
  ...
  This method should only be called from an exception handler.
```

https://docs.python.org/3/library/sys.html#sys.exc_info


```
sys.exc_info()
This function returns the old-style representation of the handled exception.
...
If no exception is being handled anywhere on the stack, this function
return a tuple containing three None values.
...
```

closes odoo/odoo#120573

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

Before this commit:
In MCQ-type questions, the answers on the 'Review my answers' page were
displayed with a green background if their score was above 0, regardless of
whether they were correct. Otherwise, answers were displayed with a red
background.

After this commit:
The answers will be shown based on whether they are correct or not, regardless
of their score. I.e. correct answers will be displayed with a green background,
and all other answers will be displayed with a red background.

Task-3252605

closes odoo/odoo#123878

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

When user uninstalls a module it doesn't unlinks custom crons
which are created by user and it will keep running in the background
and will generate traceback.

So, to fix this we unlink all the custom crons which are related to the
module being uninstalled.

sentry-3929309220

closes odoo/odoo#122830

Signed-off-by: Fabien Pinckaers <fp@odoo.com>

Before this commit, on a dashboard having a multi-column layout, the
user couldn't see all those columns' actions when the layout fallback to
the "1 column" on a small screen.

This commit fixes it by, not only keeping the fallback to "1 column" to
optimize the screen's real-estate, but also properly bringing the hidden
columns' actions in the single column, so they become accessible by the
user.

Steps to reproduce:

- Create My dashboard on PC with two views set one next to the other
- Open My dashboard on mobile devices, and you see only the action
inside the column on the left and not the action inside the columns on
the right => bug

opw-3145706

closes odoo/odoo#123890

Signed-off-by: Pierre Paridans (app) <app@odoo.com>

Entering a value greater than that allowed by a 32-bit integer raises an
error

Steps to reproduce:
1. Install eCommerce
2. Open the website and go to the 'Shop' page
3. Open the editor and click on any product in the grid
4. Set the value of the 'Number Of Products' to an integer greater than
   2147483647
5. An error is raised

Solution:
Limit the number of product per page to 10000. This will have the effect
of avoiding the `NumericValueOutOfRange` error but will also prevent the
user to load too much products at once to avoid a timeout.

opw-3226154

closes odoo/odoo#123124

Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

When a sub-menu needs to be opened in the navbar, it sometimes gets
nested within the navbar itself, making a vertical scrollbar appear
instead of floating outside the navbar, above the top of the page.
This happens if the navbar was opened in small screen sizes using the
hamburger icon, then, after a rotation, the navbar is turned into its
fully expanded version.

This commit hides the hamburger menu if the collapse toggler becomes
`display: none`.

Steps to reproduce:
- Add a sub-menu nested under the "Home" menu.
- Open the developer tools, enable mobile view.
- Select "Surface Pro 7" (Vertical 912x1368 - use "Rotate" if needed).
- Open the menu with the hamburger icon.
- Click on the "Rotate" button.
- Open the sub-menu by clicking on "Home".

=> The menu was displayed within the navbar causing a vertical scrollbar
to appear.

task-3247552

closes odoo/odoo#117899

Signed-off-by: Colin Louis (loco) <loco@odoo.com>

Based on the government documentation, NumeroDDT should be alphanumeric format
and max length 20 characters. Currently it's possible to NumeroDDT larger
than 20 characters which will fail if sent to the authorities.

Now this value will be trimmed to the last 20 characters to respect the
specifications.

opw-3343345

closes odoo/odoo#123904

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

This commit modifies the label of the alignment option for the
"magazine" and "hamburger-full" header. It changes the label from
"Mobile Alignment" to "Alignment" when the "hamburger type" option is
set to "off-canvas." This is because in this case, the alignment also
affects desktops.

The bug was introduced by this commit [1].

[1]: https://github.com/odoo/odoo/commit/3eaab4e81ea2598788c9d6757ef38bbbd6454f65



task-3254619

closes odoo/odoo#119640

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

In case the journal currency is set on the company currency, we should
compute the 'Bills to Pay' sum on amount_residual_signed as it is
the residual amount in the company currency.
In the current state, you can have differences between the sum in the
dashboard and the sum showed in the list view from the 'Bills To Pay'
button.

Steps to reproduce (clean db with accounting):
-Set a foreign currency with 2 different rates (significant if you want
 to see the issue clearly).
-Create an invoice in a sale/purchase journal which has no currency set
 (like Vendor Bills), with the foreign currency and with an invoice_date
  corresponding to one of the rate.
-Register a payment for that invoice, with a date corresponding to the
 other rate and having an amount lower (like half) than the invoice, so
 the invoice is partially reconciled.
-> Go to the accounting dashboard, the amount next to 'Bills to Pay' is
different than the amount (the sum of the column 'Amount Due') in the
list view generated after clicking that button.

These two values should be the same.  They are currently different
because the dashboard takes the amount_residual, which is expressed in
the invoice currency, and apply the exchange rate to get the residual in
the journal currency.
But if the target currency is the company currency, the field
amount_residual_signed is already the residual amount in the company
currency. Unfortunately, in case of partial reconciliation, it is not
always equal to amount_residual expressed in the company currency
anymore. Because amount_residual and amount_residual_signed are
substracted by the payment amount, expressed in each currency, using the
payment date exchange rate.

opw-3184567

closes odoo/odoo#114603

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

Sharing content by email as portal is not working and raises an AccessRecord
because we are trying to access the "email_formatted" field of the company.

This is solved by adding 'compute_sudo' to the computed field.

Indeed, we want portal users to be able to read the email address of the
company while they cannot access res.partner records.

A tour has been adapted to ensure this behavior.

Task-3349132

closes odoo/odoo#123647

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

The translation of input "default values" is allowed only when
`type="text"`. However, email field values are translatable because of
strange behaviour:

- Go to website (Edit mode) > Add a form block.
- Select the existing email field > Change label position > The input
is transformed into a `type="text"`.

Each time a "non-custom" field is re-rendered, The `_getActiveField()`
method is obtaining field related data from the database, including its
type, which changes it back to the original value ("char").

The goal of this commit is to fix this behaviour using `_getFieldType()`
to set the right field type instead of the default one.

task-3247520

closes odoo/odoo#119293

Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

when the user removes the company_id and add a line in the purchase order
then the issue is generated.

Steps to reproduce:

- Create a new purchase order.
- Remove the company_id in the Purchase order.
- Now add a line in PO. Select a product with the consumable product type.
- Traceback will be generated.

Applying these changes will resolve this issue.

Sentry-4215579151

closes odoo/odoo#123061

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

before this commit, if user search with full group
name in the search view of res.groups, currently
it returns no results.

* open groups menu
* search for Sales / Administrator
* will return no result

after this commit, searching a user group with
full name with return the corresponding user
group.

closes odoo/odoo#122788

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

Incorporate Luis Manuel (LuisMzz) as Vauxoo's contributor.

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#123622

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

Some Facebook pages have a different URL pattern than what we currently
accept for the snippet. Namely:
- /profile.php?id=<id>
- /people/<name>/<id>
- /p/<name>-<id>

This commit adds these to the accepted patterns and adjusts the call to
the Facebook page plugins with the right format.

task-3147321

closes odoo/odoo#120325

Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

This commit includes the exception
details when logging an error in the registry module.
By importing the sys module and using the exc_info() method,
the commit ensures that the complete exception information is captured
by Sentry.

This modification improves the error reporting functionality
by providing more comprehensive information about the encountered
exceptions. This will aid in debugging and diagnosing issues,
enabling faster resolution of potential problems.

closes odoo/odoo#122432

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

This method was supposed to work in multi (see history) but that
behavior was lost somewhere.

Voting for several posts at the same time doesn't mean much in the end
and the function wouldn't work anyway because:

1. Return values wouldn't work in multi
2. It would try to vote n times for each of the n posts in self and
  violate unique constraint.
3. If the last existing vote had opposed value to the new vote,
  the method would create only '0'-valued votes for all the new
  records.

We here then clean it make sure it is not called on several posts.

A test is extended to check votes and records counts.

Task-3267872

closes odoo/odoo#118065

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

In a 3-steps delivery with backorders, when removing the package in the 2nd step, it should be absent from the last step (OUT picking).
However, assigning a package on the backorder of the 1st picking and creating a new backorder reassigns the package to the OUT picking.
Settings: 3-steps delivery, packaging
Steps:
- create a SO of product A for 10 units
- on PICK_1 picking: put 2 units in Done and put in a package, validate, create a backorder
- on PACK_1 picking: remove the destination package for the 2 units, validate, create a backorder
- on OUT picking: the stock.move.line does not have a package
- on PICK_2 picking: put 2 units in Done and put in a package, validate, create a backorder
- on PACK_1 picking: the package was reassigned to the destination package
- on OUT picking: the stock.move.line has the original package that was removed before

This fix ensures that a package can't be assigned on 'done' stock.move.line

closes odoo/odoo#123130

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

While creating redirects/rewrite if the user does not enter any url in the
'Url to' field of the website module under 'Configuartion/Redirects' then during
redirection, the error  'NotFound: 404 Not Found: The requested URL was not
found on  the server' will be produced.

Applying this commit will solve the issue.

sentry-4206504892

closes odoo/odoo#122878

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

Steps to reproduce:
- Activate two languages
- Go to any multi-edit list view (not editable)
- Select a record
- Select a translatable column
- Change the value of the **current** language
- Click on save
=> Traceback

OPW-3225186

closes odoo/odoo#123232

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

Before this commit:

`id` cannot be set as the dependency for a field's compute method.
So, when a user configures `id` as a dependency for a studio field's compute,
there is no error shown to the user and
the field is saved with `id` as a dependency.

After this commit:

It will throw a `UserError` to the user.

sentry-3979435039

closes odoo/odoo#121745

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

This query count is failing randomly in 14.0 and 15.0

Disabling the test waiting for a proper investigation or branch eol.

runbot_error-14447

closes odoo/odoo#123056

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

The method `_get_unece_code` is called in the module `account_edi` and `account_edi_facturx`.
The latter depends on the former but the opposite is not true. So this method should be defined in the module `account_edi` otherwise a traceback appears when we confirm an invoice and `account_edi_facturx` is not installed.

opw-3171405

closes odoo/odoo#122912

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

When _get_rule does not find any rule, it returns False. This
could create some tracebacks as we mostly expect a stock.rule.

It will give:
if False in <recordset>:
Hence a traceback:
TypeError: unsupported operand types in: False in stock.rule()

By applying these changes will resolve this issue.

Sentry-4206998573

closes odoo/odoo#122636

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

before this commit, if the translation import is failed,
 in the log it shows "unsuccessfully imported"

after this commit, the logger message is improved and
 show file import failed

closes odoo/odoo#113307

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

When generating a new page key, it was only made sure to not match
existing page keys. This leads to COW happening on existing views if the
key already existed in a view.

This commit ensures that new page keys are not existing view keys
either.

Steps to reproduce:
- Create a page named "snippets".

=> Notification was shown indicating that `website.snippets` is private.

task-3328827

closes odoo/odoo#122669

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

When the name given when creating a new page starts with a slash, the
werkzeug route `/website/add/<path:path>` cannot be matched. This leads
to wrong navigation situations.

This commit removes any leading slash from the entered page name.

Steps to reproduce:
- Create a page.
- Enter "/abc" as name.

=> A 404 error page was reached.

task-3328827

Part-of: odoo/odoo#122669

On Firefox only: some SVG shapes either disappear when flipped or are
not properly flipped.
This is due to the way Firefox parses SVGs and the way Odoo applies
transformations on them. It happens when the main `<svg>` contains other
nested `<svg>`, and the flip transformation is applied to each of them,
causing unexpected behaviors.
When the parent contains a direct `<svg>` child and both of them are
then applied a transformation, the whole shape disappears. When the
parent contains some `<svg>` inside a `<defs>`, and the children are
then included with `<use>`, each element is flipped individually, which
means the flip is not processed as we would expect.
This commit makes sure the flip is only applied to the main `<svg>`.

Steps to reproduce:
(A) >= 14.0:
- On Firefox, drag & drop the image-text snippet
- Add a background shape and choose "Origins 07"
- Flip it: it isn't flipped

(B) >= 15.2:
- On Firefox, drag & drop any block snippet
- Add a background shape and choose "Float 13"
- Flip it: the shape is hidden

task-3264851

closes odoo/odoo#120516

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

Depending on the modules installed, the action of the form on the
`/contactus` page changes. For example, if you have `website_crm`
installed, the action will be set to "Create an Opportunity" but if you
only have `website_form` installed, the action will be "Send an Email".
For each action, there are mandatory fields that cannot be deleted by
the user. Unfortunately, the templates for the `/contactus` forms didn't
have the right fields marked as mandatory. This led to the following bug
(with only `website_form` installed):
- Go to `/contactus`
- Edit the page

=> The Email and Subject fields can be deleted. However, when you drop a
form and set the action to "Send an Email", these fields are mandatory
and cannot be deleted. This commit fixes this bug by ensuring that these
fields are marked as mandatory on `/contactus`. This commit fixes the
same issue with the `website_crm` module.

task-3302433

closes odoo/odoo#122858

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

The report_stock_quantity model defines a view in its init method
to compute quantity information related to stock. This view
is made of two CTEs and a three-part query separated by UNION ALL.
The first CTE, existing_sm, retrieves the stock_move data
from the database that are later used by the remaining of the query.

One of the where conditions of existing_sm is (m.state != 'done' or
m.date >= ((now() at time zone 'utc')::date - interval '3month')).
m.state != 'done' is translated to m.state <> 'done' by the query planner.
This type of operator has the side-effect of turning off index scan.
Therefore, the scanning of the existing_sm CTE performs a Seq Scan
and applies the where conditions in a Filter node. This can be quite
ineffecient if the stock_move table is big, and if the selectivity
of the m.state != 'done' condition is high enough to theoretically
justify an IndexScan.

To fix that, we take the inverse of m.state != 'done', i.e. an IN cond.
This allows postgres to use Bitmap Scan, which
is usually better under these specific conditions.

E.g. speedup: db with 7M stock_moves, select from report_stock_quantity
with conds for state, date, product_id, warehouse_id, company_id
4.5s -> 2.5s

opw-3288364

closes odoo/odoo#120820

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