This commit fixes the malformed comment that would sometimes comment out
the rest of the html resulting in an improper display.

this is due to the new html5 notation --!> not behing understood by
our parser.

this commit replaces any --!> into -->.

this commit also remove  <!--> or <!--->

opw-2812488

closes odoo/odoo#123041

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

Before this commit:

Duplicating the contact that is linked to an attendee of a course also
creates a copy of an attendee as well.

After this commit:

It does not create duplicate attendee in course.

Task-3253983

closes odoo/odoo#118015

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

The triangle pointing towards an option in the editor is pointing
right. In a RTL setting, this does not make sense and should be
mirrored.

task-3284274

closes odoo/odoo#120134

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

When the browser is zoomed, the value of the `border-width` CSS
properties obtained through `getComputedStyle` are impacted by the
zoom. Because of this, entering a "10px" border in a Chrome zoomed at
125% turns it into "9.6px" when leaving the input field.

This commit neutralizes the zoom effect by rounding the value up.
The rounding operation was empirically determined by observing values,
see table below.

When zoomed out this does not always work: e.g. at 50% zoom, a value
of 11px becomes 10px. But zooming out is an unxpected use case, that
situation is therefore not handled by this fix.

Observed values of the border-width property:
Set value => `getComputedStyle`
```
Value  Chrome 125%  Firefox 120%
  1px        0.8px     0.83333px
  2px        1.6px     1.66667px
  3px        2.4px     2.50000px
  4px        4.0px     3.33333px
  5px        4.8px     5.00000px
  6px        5.6px     5.83333px
  7px        6.4px     6.66667px
  8px        8.0px     7.50000px
  9px        8.8px     8.33333px
 10px        9.6px    10.00000px
 11px       10.4px    10.83333px
 12px       12.0px    11.66667px
```

Steps to reproduce:
- Drop a "Text - Image" block.
- Select the text column.
- Zoom with ctrl+mouse wheel or ctrl-plus.
- Set a 10px border.
- Leave input field.

=> Border option field displayed a different size.

task-3172235

closes odoo/odoo#119084

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

 This takes into account the option that allows to disable/enable the QR file generation

 Closes #85283

closes odoo/odoo#124995

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

Steps to reproduce the bug:
- Add a "Cover" snippet on the website.
- Add a "Custom" filter on the image.
- Put the "Blur" setting to the maximum.
- Save and edit.
-> The "Blur" setting is not on maximum anymore.

Since [1], the dataset of background images is first filtered (by the
elements inside of the `BACKGROUND_IMAGE_ATTRIBUTES` set) before being
copied into the dataset of `this.img`. Because `filterOptions` was
missing in the set, the values of the custom filter were not displayed
correctly (see `_computeWidgetState()`).

[1]: https://github.com/odoo/odoo/commit/31ba9060723f365d16d51d3de0acf42c5e95f63b



task-3358051

closes odoo/odoo#124227

Signed-off-by: Dieleman Guillaume (gdi) <gdi@odoo.com>

After creating a sales order for a product with cost 0, automatic
inventory valuation and AVCO, and validating the delivery, no account
move is created for the stock move. If an invoice is then created from
the sales order, it will create 0 amount COGS lines. Automatic
reconciliation of the invoice with the corresponding stock account move
will fail because no such entry exists, resulting in unreconciled lines
remaining in the invoices.

This issue can be prevented by either creating a 0 amount journal entry
for the stock move, or preventing the creation of the 0 amount COGS
lines on the invoice. Not creating unnecessary COGS lines is preferable
and this was also the solution used for the same problem with purchase
order invoices: https://github.com/odoo/odoo/pull/106785

 .

So this fix does the same for sales order invoices.

opw-3000320

closes odoo/odoo#124125

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

Issue:
------
When we have the link to the form to apply for a job,
even if the job is not published, we can still apply.

Solution:
---------
Check that the job is published before the creation of the record
in the `website_form_input_filter`.

opw-3331717

closes odoo/odoo#124399

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

Steps to reproduce the bug:

- Install the Website Slides module.
- Got to the /slides page.
- Click on a course.
- Click on the "Add Content" button.
- Choose "Web Page" in the modal.
- Once in edit mode, drag and drop a "Table of Content" snippet onto the
page.
- Save the page.
- Scroll the page and observe that the navbar items are updated as you
scroll.
- Click on the "Fullscreen" button.
- Bug: When scrolling the page, the navbar items are no longer updated
as you scroll.

This commit fixes the issue by detecting the scrolling element by
traversing up the ancestors from the 'table of content' snippet, instead
of using the 'getScrollingElement' function, which always returned the
'#wrapwrap' when a Website Slides page is in fullscreen.

opw-3302118

closes odoo/odoo#124459

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

Steps to reproduce the issue:

Add a project and create a task with a timesheet in it
set the allocated hours to 00:03
add a line in the timesheet with hours spent 00:03
Current Behaviour:
The percentage calculated would be 96%, even though the time allocated and time spent are equal.

Desired Behaviour:
The percentage should be 100 as both values i.e. time spent and time allocated are equal.

This is happening because effective_hours value is being rounded off to 2 decimal places, and is not accurate enough to compute the progress_hours.

Here, I have used the same line, that is used to compute effective_hours, to compute the task_total_hours but without rounding off. This will make the calculate more precise and accurate.

OPW-3270858

closes odoo/odoo#121168

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

closes odoo/odoo#124688

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

Steps to reproduce:
1) Have Barcode Installed and have Barcode Nomenclature set
2) edit 1st rule(Price Barcodes 2 Decimals) to type Quantity
3) Create a product with barcode 2380201000008
4) Open POS and scan barcode 2380201010007

Bug:
error popup product not found because the callback for this rule
is not set

Fix:
apply same callback as weight (set product quantity)

opw-3213595

closes odoo/odoo#123924

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

To reproduce:
1. Create a Sales Order for a product whose product category is set to
   FIFO and automated. Use route "dropship".
2. Confirm the PO created.
3. Deliver the products (DS transfer)
4. Create the customer invoice
5. Return, for example, 1 unit of product
6. Add a credit note to the invoice for that 1 unit returned (reset to
   draft then change qty and post)
Issues:
The value on the valuation layers of the returned picking is 0, posted
entries for COGS and stock interim (delivered) account for credit note
is also 0.

Since #85751, When create valuation layer for return, we take all svls
of origin_returned_move_id into account to calculate the price unit.
However, then dropshiping, 2 svls are created for the original move, and
the sum of them is 0 since there is no impact of the stock when
dropshiping. So when return, the price unit will be calculated as 0.

To fix, when calculate price unit for return of dropshiping, we only
take non-negative svls into account. Note that we use non-negative ones
instead of positive ones because when subcontract dropshiping,
additional negative svls will be added for the cost of the components.

opw-3283436

closes odoo/odoo#123529

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

odoo/odoo#122354 added this test but didn't handle that other models
might trigger systray activities.

On June 12th, the test started failing because calendar has a "Pricing
Discussion" demo calendar event on the 12th of every month. It
probably would have also failed on the 3rd and 22nd which both have
demo meetings for the admin.

Fix by looking up specifically activities of the test model we're
concerned with.

closes odoo/odoo#124586

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

This commit permits to enlarge the answer textarea in the forum.

Steps to reproduce the "issue" resolved by this commit:
- Go to /forum
- Click on a thread
- Click on "Answer"

=> The textarea is too small to write a long answer.

task-2865782

closes odoo/odoo#118519

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

In the website forum, we checked that the post content is not empty
before posting a post or an answer. Before this commit, it was just a
verification that the content is not an empty string.
Users are also able to post an image and we want to allow them to create
a post or an answer with only an image. This commit changes the
verification to check if the content is empty or if it only contains
images.

Steps to reproduce the issue resolved by this commit:
- Go to the website forum
- Create a new post
- Set a title
- Add an image as description
- Click on "Post Your Question"

=> The post is not created because the content is considered as empty.

task-2865782

Part-of: odoo/odoo#118519

The cause of the issue is that `datetimepicker('viewDate')` will return
the datetime of today by default event if the user selects nothing, to
remedy this, we now check if the user has chosen something before
storing the content of the field in `form_values`.

opw-3333364

closes odoo/odoo#123704

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

TypeError: expected string or bytes-like object

This error occurs when the 'url_from' field is left empty during website rewrite
To reproduce this issue, follow these steps:
1. go to website ->  configuration -> redirects
2. create a new record -> select 308 redirect / rewrite in action
3.  keep 'url from' empty and put any value in 'url to' such as '/'
4.  Click on the save button, and this error message will be displayed.

After applying this commit will fix this issue.

task-3346588

sentry-4229658026

closes odoo/odoo#124056

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

Steps to reproduce:
- create an invoice with a certain number of items so that when printed there are multiple pages

Issue:
- the invoice name does not appear on each page
According to the French legislation it is mandatory

See https://entreprendre.service-public.fr/vosdroits/F31808



Solution:
- set a config parameter specifically for l10n_fr in stable
- set it in account directly for Master
To allow the footer of the invoice to contain the name (and therefore the number) of the invoice

opw-3199906

closes odoo/odoo#117043

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

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>