In Website, since the `#wrapwrap` element is being scrolled on the
pages, we added a function called `compensateScrollbar` (added by this
commit [1]) that adds space on the right side equal to the width of the
scrollbar when a modal is open or to adjust the position of the fixed
header when a page is scrolled.

However, this `compensateScrollbar` function did not handle RTL pages
correctly, where the scrollbar is on the left instead of the right. As a
result, on RTL language pages, this space was added on the wrong side.

This commit fixes the issue by placing the space on the left instead on
RTL pages.

Steps to reproduce the bug:
- Select Arabic as the primary language for a website.
- In edit mode, drag and drop a popup onto a page.
- Bug: When the popup is open, space is added on the right to compensate
for the scrollbar, but it should be on the left instead.

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



task-3102275

closes odoo/odoo#126663

X-original-commit: 9e126f7f
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Have an invoice in foreign currency
Open "Register Payment" wizard
Have wizard currency as company currency
Change wizard date

Issue: amount will not recompute

opw-3357669

closes odoo/odoo#125049

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

Before this commit, if you stopped sync with microsoft, and
refereshed the calendar, it would change the button back to
synced status.

opw-3382311

closes odoo/odoo#126077

Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>

The return tax should only be used through its parent tax,
we don't want it to be accessible directly on bills or invoices.

opw-3347425 (2nd issue)

closes odoo/odoo#126527

X-original-commit: 7b07df87
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>

When a user tries to access the URL directly, at that time the value of
dictionary `kw` is not available. The error will be generated.

Error : KeyError: 'state'

This commit will prevent the traceback.

sentry-3947033806

closes odoo/odoo#126346

X-original-commit: dfc1a188
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>

Before this commit, in other numbering systems than "latn", the time
pickers did not allow to select hours/minutes/seconds. This was because
the lib (TempusDominus) would use `parseInt` internally to retrieve the
selected value, which was not a latin number in other numbering systems.

This commit changes 2 things directly in the lib file:

- allow the internal `getMoment` function to accept a second 'format'
parameter;

- use that same `getMoment` function to parse the text of the selected
value, effectively using moment to both parse and format the values
displayed in the picker and ensuring consistency.

OPW-3258034

closes odoo/odoo#126528

X-original-commit: 3072cb56
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

closes odoo/odoo#125781

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

closes odoo/odoo#126439

X-original-commit: 842f2292
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Some account terms are mistranslated, this PR aims to fix these translations. The customer provided a table with the mistakes and suggestions. The customer’s suggestions are available in the ticket.

How to reproduce:
1. Ukrainian translation > chart of accounts > some terms are mistranslated

closes odoo/odoo#125986

Opw: 3247005
X-original-commit: c19472f1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>

Form fields can be prefilled since [1] and their visibility
conditionally linked to other fields since [2].
1. This commit ensures prepopulated fields trigger the conditional
visibility mechanism (A), including when said field is first hidden,
then conditionally displayed (B).
2. Until [3], with a chain of visibility conditions, when one of them
was "contains", "does not contain" or a date-related condition, a
traceback was raised (C). This commit corrects the fix from [3] to
prevent this behavior now that the reason has been identified.
3. Tests are also set up to enforce these fixes.

Steps to reproduce (A):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated from user mail
- Save and check the form: A won't be shown despite B being set
- Removing one letter or typing anything in the input B will trigger
the visibility of A.
- Expected result: B should immediately appear.

Steps to reproduce (B):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated and depend on field C being set
- Field C is empty by default
- Save: only field C is shown. Type a letter: field B appears, but not
field A.
- Expected result: both should appear.
Note: this bug only occurs when field A is before field B.

Steps to reproduce (C) (until [3]):
- Drop a form
- Field A depends on B containing "abc"
- Field B depends on C being set
- Save and type something in C: there is a traceback.

task-3335536

[1]: https://github.com/odoo/odoo/commit/54873d2
[2]: https://github.com/odoo/odoo/commit/2dcbfec
[3]: https://github.com/odoo/odoo/commit/2714469



closes odoo/odoo#122044

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

It is currently impossible to cancel a payment through edi

Steps to reproduce:
1. Install l10n_mx_edi and Accounting
2. Set company to 'Escuela Kemper Urgate'
3. Go to Accounting and create a new invoice for customer Deco Addict
   with due date: 2 months and product: Large Cabinet (edit it and
   specify any UNSPSC category to the product in the Accounting tab)
4. Save and confirm the invoice, then register a payment with payment
   way 'Transferencia electrónica de fondos'
5. Go to the payment (through the little "i" next to the total)

Solution:
Add buttons and methods to cancel and abandon the cancellation of a
payment

opw-2926261

closes odoo/odoo#108973

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

When parsing an email containing an xml attachment, the `email` python
module will decode the base64 attachment using the charset or ascii if
the charset is missing.

In some cases, the payload is in UTF-8 but the charset is omitted. This
results in replacement characters for the non ASCII characters.

The solution is to force the charset to UTF-8, since it is a superset of
ASCII that should not be a problem.

NB1: Omitting the charset for text/xml is not recommended. See the RFC
(section 6.4): https://www.ietf.org/rfc/rfc2376.txt



opw-3144519

closes odoo/odoo#126323

X-original-commit: b2aa5883
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

In the start_sync method, 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 sending a partner to sync fails.

The changes have been made to reduce the noise level in the sentry.

sentry-3955309841

closes odoo/odoo#126025

X-original-commit: c1b608c2
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>

Currently, it's not possible to check the 'Peppol Bis 3' option on the
journals of Italian companies, since Italy is not present in our mapping
`COUNTRY_EAS`.

The EAS for Italian companies may be the codice fiscal (code: 0210) or
the VAT number (code: 0211). See
https://peppol.agid.gov.it/en/news/expiration-validity-codes/



Use the VAT number by default, and add it in our mapping such that the
option now appears for Italian companies.

opw-3346572

closes odoo/odoo#126203

X-original-commit: 030b55b2
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

This commit ensures that the unsplash beacon calls home when an unsplash
image appears on a page.

To achieve this it patches the RPC call when the test URL contains the
test name as parameter. The patch cancels the actual beacon call to
avoid polluting data during the test, but marks the image as having had
its beacon message sent. The test then simply checks if this marker
appears on the image.

task-3360109

closes odoo/odoo#126026

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

When a user creates a link that is tracked, an interface with graphs is
presented to him so that he can track the performance of his tracked
link. Unfortunately, these graphs did not work when the site was in a
foreign language. This was due to the fact that the code had not been
designed to handle this. This commit fixes the code so that it works in
all languages.

Note that the data is received via RPC and the python code format the
dates for the current language of the website. So we had to do a little
hack to make it work properly.

Steps to reproduce the issue:
- Install website_links module
- Go to the website app
- Click on Promote > Link Tracker
- Create a tracked link
- Visit the link
- Install Arabic (Syria) for your website
- Check the stats of your link in Arabic

=> There is a traceback and the data is not displayed.

task-3289167

closes odoo/odoo#126172

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

If the user change a location type of the 'Production' from inventory locations
and installs the 'MRP' module, the traceback will appear.

Steps to produce:
- Install Stock module.
- Inventory > Configuration > Settings > enable the Storage Locations.
- Inventory > Configuration > Locations > Remove the filter 'Internal'.
- Open the 'Production' location and change the Location Type to 'View'.
- Now install the 'Manufacturing' module.
Error: A traceback appears: 'ParseError: while parsing
/home/odoo/src/odoo/saas-16.2/addons/mrp/data/mrp_data.xml:17, somewhere inside'

At the time of installing the MRP module, it will search for the production
location using the location type as the production here - https://github.com/odoo/odoo/blob/f65a9bffe2cbc03b2efc969dc205c9ba01ee9ab5/addons/mrp/models/stock_warehouse.py#L65


If the production location is not found it will raise an userError. In this
commit, the production location is created based on the company if not found. It
will lead to the above traceback.

sentry-4215564628

closes odoo/odoo#125885

X-original-commit: e8ce51dd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>

Steps to reproduce:
- Install the lux localization
- Configure Peppol for a customer: Select a customer > tab accounting > under "electronic invoicing":
format: Peppol BIS Billing 3.0
Peppol e-address: 0130 - Directorates of the European Commission
Peppol Endpont: testendpoint

- Create an invoice for the peppol customer
- Add a section or a note in the Invoice
- Confirm the Invoice

Issue:
Raise user error:  Odoo requires a tax for EACH LINE, instead of each product

Solution:
Exclude the section/note line

opw-3354757

closes odoo/odoo#126225

X-original-commit: fb716296
Signed-off-by: Laurent Smet (las) <las@odoo.com>

Revision odoo/odoo@cabb9e7e573b86cd523980588360d8514090d370 introduced a
regression: This is no longer possible to import a data module
using `<field file="..."/>` in their data file.

This revision targets to restore the feature as expected.
The unit tests added covers the feature, so that regression
no longer happens in the future.

It introduces a new concept of temporary directory `file_open`
can read from.
e.g.
```py
with odoo.tools.file_open_temporary_directory(self.env) as module_dir:
   with zipfile.ZipFile('foo.zip', "r") as z:
      z.extract('foo/__manifest__.py', module_dir)
   with odoo.tools.file_open('foo/__manifest__.py', env=self.env) as f:
      manifest = f.read()
```

Note that `file_open` will be allowed to read from that temporary
directory only if `env` is passed to `file_open`,
and if the `env` is part of the same transaction/request than the `env`
passed to `file_open_temporary_directory`.

This is to avoid having users, whether from other databases,
or even the same database,
trying to access these directories not belonging to them.
e.g. If an admin uploads sensitive data in this temporary directory,
no one than him must be allowed to read from these files, not even
another user from his database.

closes odoo/odoo#126278

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

The code snippet removed by this commit had no useful effect, as
`selection.addRange(range)` a few line above triggers
`OdooEditor._onSelectionChange`, which repositions the toolbar
elsewhere.

The result was a "glitch": the toolbar would briefly be displayed over
the top left corner of the media before finally being displayed above
(or below) it.

This commit removes such undesirable effect.

task-3347942

closes odoo/odoo#123568

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

Before this commit the position of the arrow was incorrect when the
editor is inside an iframe.

For the calculation of `arrowLeftPos` we need the difference between
the selection rectangle border and the toolbar's left position.
While `correctedSelectionRect.right` is relative to the current iframe's
borders, `left` is relative to the top document's window, as it has been
offset with `parentContextRect.left`. We need both values to be relative
to the same referential in order to make this calculation make sense.

task-3347942

Part-of: odoo/odoo#123568

Before this commit, an error in the toolbar position happened when the
editor was inside an iframe and the iframe's window had scroll bars.

Steps to reproduce:
- go to the Market Automation app (enterprise edition)
- create new campaign
- add new activity
- create a new mail template by typing a name and selecting "create and
edit"
- select the "plain text" theme
- add a lot of content in order to have the scroll bars
- scroll down
- select something to display the toolbar

The `scrollX` and `scrollY` variables in `_positionToolbar` are ment to
correct the floating toolbar position in case the document in which the
toolbar is mounted has some scrolloffset.
As the floating toolbar is always mounted on the body of the top
document, this is the document to watch for scroll offsets, and not the
inner document when the editor is mounted inside an iframe.

task-3263463

Part-of: odoo/odoo#123568

Since [this other commit], initializing the color picker could trigger a
traceback. The traceback was due to the fact that for users to be able
to drag/move the color picker as they wished across different frames, we
needed access to the document of all the frames on the page.
Unfortunately, if one of these frames was not of the same origin, a
traceback was displayed. This commit corrects how we collect documents
from frames on the page, by only taking those whose document we have the
right to see (which do not raise a cross origin error). I didn't succeed
to reproduce the bug locally, but I got it on the runbot with theme
Nursery / Kiddo by dropping the block banner on the page, the error
appears because the block contains a vimeo video. In fact, you just need
to have embedded content (youtube / vimeo / ... video for example) start
edit mode, click on the block containing the video and the error is
displayed.

[this other commit]: https://github.com/odoo/odoo/commit/63bf363d302fe9f93a824fa6f1ff3bbe21f98088



runbot-22573

closes odoo/odoo#126240

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

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>