JSONDecoderError occurs when users enters invalid JSON format data in
'Default Value' field inside 'User-defined Defaults' and wherever this field is
being accessed to get default value this traceback will be generated.

Steps to reproduce:
1) Install 'Contacts' module.
2) Open 'Settings' > 'Technical' > 'User-defined Defaults'.
3) Click on record 'Language' > 'EDIT' button > in 'Default Value' field enter
   any improper JSON format data (e.g 'Maa' : FI ) .
4) Now, open 'Contacts' module > click on 'CREATE' button and traceback would be
   generated.

By applying this, it will check for proper JSON format.

Sentry-4169062951

closes odoo/odoo#126202

X-original-commit: 0e6e322d
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>

closes odoo/odoo#126184

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

When we include the author in the recipients of the quotation email of a repair order he doesn't receive the email.

Steps to reproduce the error :
1- create a repiar order
2- add the author in the list of recipients
3- send the email

The origin of the problem is that mail_notify_author=False , se we need to add it as True when we have the author in the recipients.

Similar old fix : https://github.com/odoo/odoo/commit/f49dbf595c870b682f36c11443c9cf1a9a027474



opw-3295744

closes odoo/odoo#123036

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

The index is being added because when processing a large PoS session, the method consume_specific_qty is called a large number of times if the product categories are set to automatic valuations. This method has the line:
tmp_value += qty_taken_on_candidate * ((candidate.value + sum(candidate.stock_valuation_layer_ids.mapped('value'))) / candidate.quantity)

This line, when running upwards of 20,000 times, can cause large performance issues, due to the stock_valuation_layer_ids being a related field on stock_valuation_layer_id.
This causes a doubling of the number of sql queries which causes slowdowns in performance. Adding this index drastically improves the performance of the queries generated by this line of code.

opw-3295560

closes odoo/odoo#123818

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

Current behavior:
When scanning the barcode of a product that is not saleable, the product
was added to the order.

Steps to reproduce:
- Create a product that is not saleable and not available in PoS
- Set a barcode for this product
- Open the PoS, and scan the barcode of the product
- The product is added to the order even if it is not saleable

opw-3325238

closes odoo/odoo#124804

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

Description of the issue/feature this PR addresses:
In sale, when threshold value of product is not exceed than upsell activity is
created while creating invoice. upsell activity is only create when threshold
value exceed otherwise not.

Current behavior before PR:
When creating an invoice, an 'upsell' activity is created on the sales order and
assigned to the salesperson even if the threshold has not been exceeded.

Desired behavior after PR is merged:
Do not create a 'upsell' activity unless threshold is exceeded.

Fix:
super class is invoke before checking the upsell and create activity. so
now, we prevent super method from creating upsell activity via passing
`mail_activity_automation_skip` context.

task- 3330815

closes odoo/odoo#121740

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

With [1] and [2], the colorpicker / colorpalette were implemented. In
both cases, for the custom colors hue / saturation / lightness selection
we listened to mousemove/mouseup events on the whole body / document.
That is to be able to start dragging the color cursors from inside the
colorpicker to anywhere on the screen (the cursor being confined into
their own box of course).

Problems occur when iframes come into the equation. Indeed, from that
moment, listening to mousemove events on an unique document is not the
way to go as mousemove over inner iframes will be ignored. This should
not be the case anywhere in 15.0 (that this original commit targets).
The only iframe there should be the mass_mailing one and in that case,
the colorpicker is inside the iframe so it should not be a problem.
However, [3] (then fixed by [4]) were meant to tackle a similar problem
(although [3] seems to say the goal was to ignore mousemove outside the
iframe which is the opposite of what this current commit tries to do:
listening on the whole screen). However, by doing so, a memory leak was
created as the document on which the events were bound was not properly
cleaned as the `destroy` which unbinds the events was not adapted. That
is the main reason why this commit targets 15.0 (although, the solution
here still makes sense generically in 15.0 and should make the code
simpler and easier to understand).

In 16.0, however, the iframe situation is a problem: the website builder
colorpickers are now in the main document but the edited content is
inside an inner iframe. In that case, listening to the main document's
mousemove/mouseup events makes the colorpicker only work when not
hovering the edited content (which could be acceptable but not perfect).
Note that during that website builder refactoring, [5] worsened the code
of [3] and [4] to do exactly that. Later, [6] was made to solve an
unrelated problem and actually woke up that worsened code, not
understanding what the new undocumented `ownerDocument` option was for
(it will stay like this in stable from now on, as it will be not used
anywhere anymore... hopefully). Because of that, the situation became
the opposite: dragging inside the colorpicker did not work until the
edited content was hovered. And because of that functional fact, an even
more visible problem was created:

- Click on a snippet
- Select a custom background color using the hsl selection
- Hover a non custom color (like nearly always the case "by mistake"
  after configuring a custom color, your mouse just moves over the non
  custom colors) => your custom color is lost

This was because the chain of events that were listened inside the
colorpicker were gone (because of the combination of [5] and [6]). In
the end, this only revealed the shortcomings of the implementation in
[1], [2], [3] and [4]: we should not try to search which frame we have
to listen to: we should listen to the whole screen. This commit solves
the issue by listening to the top window document and all its inner
iframes, also fixing the memory leak mentioned earlier.

task-3332711

[1]: https://github.com/odoo/odoo/commit/29f0c0a186a9a60d6e5b7f026c305d689b6fc807
[2]: https://github.com/odoo/odoo/commit/99910b526ed792235a778863b993d10cf4e77cd7
[3]: https://github.com/odoo/odoo/commit/4fb33f7f8d6955a44fbb7c94c7d204e9baa09707
[4]: https://github.com/odoo/odoo/commit/f1b26335a286a47f685b7830db97c21e6fefd68b
[5]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af
[6]: https://github.com/odoo/odoo/commit/418c1178301e28b4bd1412da6d0558e219060830



closes odoo/odoo#125956

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

Reproduction:
1. Install Event, Sales, Webiste
2. Login as Admin, go to Website -> Go to website -> Events
3. Click the Open wood event, Register, buy one VIP ticket
4. In Address step, Edit the billing address, change the name to “Test
Name”, click next
5. The user name “Mitchell Admin” is changed to  “Test Name”, we
shouldn’t be able to change the info

Reason: In the fix to block name change here: https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644
we use the can_edit_vat to check if we have existing invoice(s) or
SO(s). However, we should block the route that an employee changes the
billing address when placing an order. If they are placing an order for
external people, it should be done from the back end.

Fix: add an extra error case when it's an employee trying to change the
name or email address when editing billing address. This is the case
when an employee tries to order for external people. They should do it
from the back end. They can still buy for themselves without changing
the billing address. Also added translation in pot. Edited the test for
editing address of log in user, added tests for portal user. Reformat
the invoice exsits check for name change to have better readability

In website, add render on MockRequest that return a supported type
(string e.g.)

The adding of can_edit_vat:
https://github.com/odoo/odoo/commit/f8b05f52f5ea7f31135f700b0e240ff563204085

Related fix to block the name change:
https://github.com/odoo/odoo/commit/d823033ad67702b1b92d27a3f66c7a4ec304c644

A patch to not block the checkout process when name is not set:
https://github.com/odoo/odoo/commit/781dbeaccac76a6ec4f4b8cac1b607810697e394



opw-3126325

closes odoo/odoo#125935

X-original-commit: ff0cc7fe
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Jinjiu Liu (jili) <jili@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Co-authored-by: Antoine Vandevenne (anv) <anv@odoo.com>

This commit fixes a simple SyntaxError on `website_ribbon_id` options attribute on view `product_template_form_view` of `website_sale` module.
It doesn't seem to cause issues on module update, but it's a common syntax mistake which should be fixed.

closes odoo/odoo#125901

X-original-commit: 82425f57
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Issue:
------
The "Launch Plan" button appears for an archived employee.
It causes a traceback.

Solution:
---------
Do not display the button for an archived employee.

opw-3366815

closes odoo/odoo#125876

X-original-commit: 6536a88b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>

Post counts were not updated when a post was created or deleted
because of missing dependencies in the _compute.

Note that while "active_test" is included when counting without
specifying it, the field must be explicitly added to the `_compute`'s
dependency list to trigger it.

Task-3358143

closes odoo/odoo#125860

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

The issue:
a traceback raised because of float * NoneType

The fix:
parenthesis should be added to the expression

opw-3366260

closes odoo/odoo#125794

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

When the user will not get an HTTP response as 200 while retrieving the location
using OpenStreetMap Nominatim service, the logger error will occur.

The logger is updated to use the 'warning' level instead of the 'error' level.
This change reflects a less severe logging level for cases where a request to
OpenStreetMap fails.

sentry-4151622143

closes odoo/odoo#125785

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

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#125162

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

Steps to reproduce:
- Add a form.
- Setup a conditional visibility on one field, using the "contains" or
  "does not contain" operator.
- Save.
- Open the HTML editor and voluntarily break the form by changing the
  "data-visibility-dependency" attribute to a random text (non existing
  field used as a dependency).
- Save => Crash on page load.

One customer apparently reached that case of receiving a `null` value
(actually possible when retrieving a form data which is an unchecked
checkbox for example) but combined with an operator which really
requires the received value to be a string... but not sure how this is
possible. In any case, it should not make the form crash: it's just a
problematic *visibility* dependency, it should not prevent using the
form. For now, let's prevent this case to crash and add an error in the
console so we may investigate the issue if it ever shows up in a test.

opw-3243345

closes odoo/odoo#125040

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

closes odoo/odoo#124878

X-original-commit: 39f23ac5
Signed-off-by: Josse Colpaert <jco@odoo.com>

When we create a project stage (project task type),
it is essential that we link it to a project.

Otherwise, the record created will never be accessible.

opw-3322992

closes odoo/odoo#122614

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

Steps to reproduce:
-------------------
- create a stage without selecting a project.

Issue:
------
The new stage is inaccessible.

Cause:
------
When the project is not defined, the following ORM command is used:
`[6, False, []]` for the `project_ids` field.

Solution:
---------
When we create a project stage (project task type),
it is essential that we link it to a project.
Add the possibility to override `_get_default_project_ids`.
Set default project as first fsm project if not project in
the context.

opw-3322992

closes odoo/odoo#125318

Related: odoo/enterprise#42529
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

We have introduced a new tag `website_nightly` which is linked to a
custom build on the nightly.
It has been introduced with this commit [1].

The goal is to extract the `external` tagged tests linked to the website
app to another special build linked to the website team.
Otherwise, we would not see when the test fail, as the `external` build
of the nightly is always red and we don't check why all the time.

Encapsulating this in a new build and linking to our team means that
whenever the test fail in a nightly, we will be visually warned on the
runbot homepage by a red warning, see screenshot on the PR of this
commit.

Sadly, before 16.4, as there is not yet `website_nightly` tours, the
build is considered failed, showing the error.
Another solution would have been to somehow disable this tour on Odoo
versions < 16.4 but it we opted for this solution as:
- It's simpler, no need to add yet another custom stuff in runbot
- It will work out of the box should be introduce such a test in those
  versions: we won't need to ask runbot to activate the test in another
  version, should we even think about it..

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



closes odoo/odoo#125676

X-original-commit: 231a7d63
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Before this commit:
When importing `stock.quant` with two lines with the same product and
different counted quantities, only the last line is taken.

After this commit:
Each line creates a `stock.quant`, even if a similar Quant exists.
The records will be merged at a later time by `_merge_quants`.

Steps to reproduce:
1. Create a storable product
2. Go to Inventory > Operations > Inventory Adjustments
3. Create a file with two lines with the same product,
    and different counted quantities
5. Favourites > Import Records & upload the file

OPW-3340017

closes odoo/odoo#124185

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

Prior to this commit, when using the "Slide Hover" reveal effect on the
footer, Safari would glitch it scrolls and could result in unreadable
content.

This commit fixes this by a weird hack that seems to work. Adding an
element with a background-image and a background-attachment set to
fixed seems to resolve the issue.

task-3302302

closes odoo/odoo#125229

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

In width and height attributes, the "px" unit is implicit. In some cases
we introduced it explicitly, which is unexpected.

closes odoo/odoo#125146

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Since Bootstrap responsive behavior can't be guaranteed, we have to make
sure that images that didn't keep their original dimensions preserve
their aspect ratio. This can be achieved with the `object-fit: cover`
CSS property. We apply this on images that are not responsive and that
are alone in a div because these are the ones at risk.

opw-3244705
task-3334591

Part-of: odoo/odoo#125146

This addresses a series of issues regarding images, their responsive
behavior and their alignment.

This is a partial backport of commit [1] from 16.0.

[1]: https://github.com/odoo/odoo/commit/25f63ecdc89cfabe07f0348c1dc5c830aeed7cca

Part-of: odoo/odoo#125146

Since flexbox is not well supported in e-mails, the Bootstrap grids
don't stack. This means that the .img-fluid images have to adapt to
columns that are smaller than what they were designed for. We remove the
dimensions on the images to let .img-fluid images resize percentually.

Part-of: odoo/odoo#125146

Outlook needs explicit dimensions for images, which .img-fluid - by
design - doesn't provide. This puts them in mso conditionals with said
dimensions for Outlook.

This is a backport of commit [1] from 16.0.

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

Part-of: odoo/odoo#125146

The `_wrap` util function of `convert_inline` was not checking if
`className` and `style` were defined before adding them to the wrapper
element, leading to things like `<div class="undefined">element</div>`.

This is a backport of commit [1] from 16.0.

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

Part-of: odoo/odoo#125146

Firefox doesn't seem to do well with sibling tables, so we need to
wrap them each in separate rows.

This is a backport of commit [1] from 16.0.

[1]: https://github.com/odoo/odoo/commit/3759a83773ac7a3d7ff004cbe54823ab90c56b64

Part-of: odoo/odoo#125146

Bootstrap rows have negative left and right margins, which are not
supported by GMail and Outlook. Sometimes we use padding on columns to
undo the negative margins of their child rows. This corrects these.

This is a backport of commit [1] from 16.0.

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

Part-of: odoo/odoo#125146

This addresses a series of alignment issues in the conversion of html.
This is a backport of commit [1] from 16.0.

[1]: https://github.com/odoo/odoo/commit/54fa22007094e13f2d229c42195191d224517617

Part-of: odoo/odoo#125146

Bootstrap grid media queries were only inlined from the xl breakpoint
and up, but the snippets typically use the lg breakpoint.

Part-of: odoo/odoo#125146

A call to `setProperty` failed silently, making it so the height was
never set on certain rows.

Part-of: odoo/odoo#125146

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#124655

X-original-commit: 3b88958f
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

After preventing "async" code on link tools update in [1], the
`'link_tools'` test is still failing because of another race condition
issue:

The click on "save" after setting the link style to secondary triggers
an event handler that destroys the link tools widget (see `Wysiwyg` >
`destroyLinkTools()`), leading to calling the `_removeHintClasses()`
method first (both `_addHintClasses()` and `_removeHintClasses()` will
disable the editor observer while adding / removing the link hint
class to prevent their mutations to be recorded...).

Since the observer is inactive, the changes made to the link using the
link tools will not be processed, and the block will not be set as
`.o_dirty`.

As mentioned previously, (and starting from [2]) the editor observer is
inactive (while handling the `.oe_edited_link` class) in order to
prevent recording the mutations... But since [3], the editor had the
ability to prevent some classes (including `.oe_edited_link`) from being
taken into consideration in the `filterMutationRecords()` method...

The goal of this commit is to fix this race condition issue by simply
keeping the observer activated while handling the link hint class...

Remarks:

- These changes are supposed to fix the `link_tools` test that fails on
16.0+, but 15.0 was targeted here since the `.oe_edited_link` class is
ignored by the editor starting from 15.0 and also to prevent any future
issue linked to disabling the observer...

- Adding and removing the `active` class should not affect the history,
since it targets the `linktTools` toolbar button...

[1]: https://github.com/odoo/odoo/pull/109250/commits/f42715fdc89a6a88446c5f88ecec29e6a9c96fe1
[2]: https://github.com/odoo/odoo/pull/90064/commits/26377710a6e3ad61a8c266e9f7c0b8ade98f657d
[3]: https://github.com/odoo/odoo/commit/1c25ddb42393b136cac2a0ee0b9b7280fd803e7d



runbot-18747

closes odoo/odoo#121622

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Use case:
It happens that a product is consumed in different operations.
So it needs two distinct BoM lines. Since commit [1] the stock.move
in pbm are not merged. However [1] was design for kit.
In our case we would like to have only one stock.move for all the
quantities.

The fix is not perfect because it won't work if we confirm at the
same time a move with a kit and without it. But at least it will let
people using MO without kit has the correct behavior

+ remove a duplicate of the function

[1] commit 741d2fe9

closes odoo/odoo#122682

X-original-commit: 07b192b8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

'replace() argument 1 must be str, not bool' is generated if the user edit a
float or monetary section in the website view.

Steps to Reproduce

- Make debugger mode ON.
- Go to Settings > Translations > Languages.
- Remove the value of the 'Thousands Separator' field from the current user
language.
- Install the 'eCommerce' module.
- Go to the website.
- Go to the shop menu, and click any product from the product list.
- Click on the Edit button and try to edit any float or
monetary section like a product price (eg. change a product price from 750 to
70) and click on the Save button.

And traceback will be generated.

Applying this commit will resolve this issue.

sentry-4148693017

closes odoo/odoo#125634

X-original-commit: b895175c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

The values for the key "async" found in some services is used to declare
async methods that should be "protected". The hook "useService" makes sure
that no code used to process results of those protected methods is
executed by a destroyed component. The orm method "webSearchRead" was
not protected due to a "typo".

closes odoo/odoo#125621

Signed-off-by: Géry Debongnie <ged@odoo.com>

When you add items in the cart it always show the number of available left in stock of the previous state for example :
1- cart is empty it shows 20 items
2- add one into cart - it shows 20 items left in stock (should be 19)
3- add another one into cart - it show 19 items left in stock (should be 18)

Steps to reproduce the error :
1 - Go to one of the product and make sure that it has some available quantity
2 - Go to sale configuration on the product and remove "out-of-stock : continue selling" and add show available qty only if below 5000 for example
3 - Go the web page of the product and try to add some items into the cart you will see that the stock message is wrong

The origin of the problem is that when we have optional products activated , it will launch a product configurator modal. After posting the update in the database there is no call to the function that updates the stock message.

opw-3341377

closes odoo/odoo#124164

Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>

With the introduction of our l10n_sa_edi module we are able to send invoices to ZATCA,
in this commit we are forcing the invoicing of every PoS order in order to send a simplified
invoice for each PoS order.
add a fallback for l10n_sa_edi for invoice_payment_means
This commit is to add a fallback ('unknown') incase _l10n_sa_get_payment_means_code
returns value not considered

closes odoo/odoo#124300

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

Let us consider the search arch

    <search>
        <field name="foo"/>
        <searchpanel>
            <field name="bar"/>
        </searchpanel>
    </search>

The two tags "field" are supposed to generate different objects:
 - the first one should generate an entry in the search bar autocompletion
 - the second one should generate a search panel section.

It turns out that the second field did also generate an entry in the
search bar. This is of course wrong. We fix that problem and add a test.

closes odoo/odoo#125541

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>