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

X-original-commit: 8ff33c75
Signed-off-by: Quentin Smetz (qsm) <qsm@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#126238

X-original-commit: 030b55b2
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@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#126195

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

X-original-commit: e8ce51dd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@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#126320

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

It was possible to create inconstancies in accounting entries by forcing to sum apples and pears.

Steps to reproduce
1. create a journal entry using at least one account with a secondary currency set
2. balance and save that move
3. change the secondary currency on the line and force it to a different value than the one on the account
4. save. You'd expect an error pop up but the constraint doesn't trigger and you're allowed to save/post

opw-3340697

closes odoo/odoo#126231

Signed-off-by: William André (wan) <wan@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#126269

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

Allow expenses reports to generate foreign currency
payments and use foreign currency accounts when all
expense lines are of the same currency.
If the report is multi-currency the company currency
is used instead (previous behaviour)

Task-3346458

closes odoo/odoo#123535

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

Since [this commit] when a user opens a dropup menu, a traceback is
raised.

Steps to reproduce the bug:
- Go to website
- Enter in edit mode
- Change the header template to "Sidebar"
- Save
- Open the "Mitchell Admin" menu (a dropup menu)

=> A traceback is displayed.

The problem was that we have code to handle the orientation of the
opening of dropdowns menu but this code is also called when we open a
dropup menu and it has not been designed for this case. This commit
fixes the issue by adapting the code to be able to handle dropup menus.

[this commit]: https://github.com/odoo/odoo/commit/b6963dc21bad4b012aace16b9ea9264c33a0d618



opw-3371946

closes odoo/odoo#126085

Signed-off-by: Romain Derie (rde) <rde@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#126164

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

This reverts commit [1]. It broke all snippet button colors, making
them invisible. Besides that, the fix seems not obvious to make properly
and would thus require some more testing, thus the need of reverting
this urgently.

There is probably more things to consider when remaking that fix:
- mass_mailing scss code in web_editor should not be a thing. Even if
  the comment about variables not being accessible is true, there are
  definitely other ways to do it (make them accessible, add those rules
  generically with a custom selector and fill that custom selector when
  mass_mailing is installed, etc etc)
- More than scss code, we really do not want mass_mailing *CSS* rules
  in website pages, especially in that code that generates *many* CSS
  rules. Of course web_editor.common.scss contains many things that
  should not be there and mass_mailing has probably already a lot of
  useless code in the frontend assets... but the goal is to fix those
  inconsistencies in the future.
- The fix impacts buttons which are not hovered while the goal seemed to
  be to have their hover style disabled...
- The fix impacts buttons which are in o_ccX environments only (?) but
  seemed to be about disabling all hover styles.
- Much doubt on the need of an at-root instruction, especially since
  it creates a bug in frontend pages without o_mail_wrapper containers
  so it probably does not work as intended.
- The fix should probably not be about overriding/duplicating the CSS
  rules but rather post-processing the mass_mailing assets to remove all
  hover rules. I guess it is even possible to do in JS removing the
  :hover CSS rules, at worst by moving all CSS rules to inline <style>
  rules or something like that.

Note: the main bug about button text being invisible is apparently from
16.0 and up only. This still reverts the code at its root (15.2) for all
mentioned reasons above.

[1]: https://github.com/odoo/odoo/commit/55aff2dcdf5537e16bdaf01ee68d776510572171



task-3376724

closes odoo/odoo#126082

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

As the leave is deducted from the needed time to work
in case for example Home Office which is configured as
working time (other) is handled like a real leave (absence)
which will lead to an extensive overtime instead the difference
to the work entry defining the work time.

A domain clearing out this missing link and variation
cleans up this misalignment and therefore overtime will
be computed correctly.

closes odoo/odoo#126188

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

This commit simply makes the account tax groups tour compatible with
odoo enterprise even without the accounting app installed.

closes odoo/odoo#125937

Related: odoo/enterprise#43061
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>

Currently the to do filter in inventory transfers doesn't really filter anything.

Steps to reproduce the error :

1- go to inventory/operations/transfers

2- Select to do filter from the sections filters

The reason of the issue is that the domain in the xml file is missing some conditions.

I added the same conditions from the saas-16.2 since it works correctly there.

opw-3376083

closes odoo/odoo#125888

Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>

The issue happens when we have a really small percentage of tasks with a certain state and it’s very difficult to filter them clicking on the respective color in the progress bar. To fix this issue there was defined a minimum of 5% for each color and make sure that in the end the sum of values is exactly 100%.

To solve this issue, it was necessary to set a minimum of 5% for the width for every non-empty bar, also it was defined a max-width of 100 - (# non-empty bars -1)*5 % because we also have to ensure the sum of 100% at the end.

How to reproduce:
1. Go to Project -> tasks -> create a huge number of tasks in the same project (you can do it using interactive shell)
2. Change one of these tasks to another state (eg: done)

OPW - 3299363

closes odoo/odoo#124677

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Current behavior:
When using the QRCode on ticket to create an invoice, it was always
creating a new partner, even if a partner was already set on the order.

Steps to reproduce:
- Activate the QRCode on receipt feature
- Create a PoS order and create a new customer for it
- Pay the order and print the receipt
- Scan the QRCode on the receipt to create an invoice
- On the new window enter the customer informations and see the invoice
- Now go check the customers list in the backend, you will see 2
  customers have been created.

opw-3275938

closes odoo/odoo#122514

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

closes odoo/odoo#126122

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

Part-of: odoo/odoo#126122

When '_seek_for_lines' returns multiple suspense_line for
transaction_amount calculation, then the user will face this
issue 'Expected singleton: account.move.line(516, 517)'.

Steps to reproduce:
- Create a new transaction in Journal (Bank) by Accounting Journal
> Bank Reconcilation > Add a Transaction.
-  While creating a transaction add a partner, amount (amount > 0),
Foreign Currency, Amount in currency and then save it.
- Go to Journal Entries by Accounting > Journal Entries
and then open your  recently created journal entry.
- Click on reset to draft and then in 'Journal Items'
add a line with some credit amount such that total credit and debit should be
equal. (Under Account it should be Bank Suspense Account).
- Now click on 'Bank Transaction' button in the form view.

By following above steps you will be able to reproduce the error.

Applying the changes will resolve the issue.

sentry-4217912848

closes odoo/odoo#123405

Signed-off-by: Laurent Smet (las) <las@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#126160

X-original-commit: 42f29831
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@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

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

X-original-commit: 077544f7cfdcc423e0f8e23799ef79402ba1590c
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>

When we have a long course name or we update the font size to something
big (24 px) for example the course name and the progress bar will overflow
outside its container.

Steps to reproduce the error :
1- go to one of the courses and update it's name to make it a bit long
2- click on one of it's content and got website preview
3- you can see that the progress bar is outside the container
4- if not : click edit -> theme -> change font size to 24 px
5- You can see now clearly that there is overflow from the container

The origin of the problem was because the container has fixed height
equals 80px

opw-3191888

closes odoo/odoo#122859

Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@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#125884

X-original-commit: e4f538ef
Related: odoo/enterprise#42904
Signed-off-by: Xavier Bol (xbo) <xbo@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#125945

X-original-commit: 7639ab557bfc547312206220543a40ef0d034c81
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

If a cart has multiple lines with the same product (custom/no_variant attributes),
opening the reordering wizard on the portal would fail, because the key used in
foreach would be the same for multiple iterations.

closes odoo/odoo#123555

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

New "Re-order from portal" feature for e-commerce orders was not
considering specified no_variant & custom information on the order at all.

This commit makes sure the information is correctly forwarded to the cart,
ensuring the reordered products are the same as the ones previously ordered.

opw-3380312

Part-of: odoo/odoo#123555
Co-authored-by: Florent de Labarre <florent.mirieu@gmail.com>

Part-of: odoo/odoo#123555

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

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

task-3337932

closes odoo/odoo#122444

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

product variable used in the rounding precision come from the upper
loop and won't work for all the quantites.

opw-3229080

closes odoo/odoo#121262

X-original-commit: ea923a08
Signed-off-by: Tiffany Chang <tic@odoo.com>

Steps to reproduce:
- Install CRM module and go to any lead view.
- Make sure we are in mobile mode, and the page was loaded in mobile
mode.
- Go to Extra Information, and try to change the sales team field.

Issue:
We got an error since we didn't have a proper view for this field in
mobile.

Solution:
Adding the proper `kanban_view_ref` as in similar fields will fix the
issue and let us change the field without error.

opw-3323976

closes odoo/odoo#126044

Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@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#126017

X-original-commit: 9232093d
Signed-off-by: Xavier Bol (xbo) <xbo@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#126001

Opw: 3247005
X-original-commit: c19472f1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@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#125993

X-original-commit: 63bf363d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

opw-3316448

closes odoo/odoo#125892

Related: odoo/enterprise#42932
Signed-off-by: Francois Georis (fge) <fge@odoo.com>

Since [0], a currency field is required to be in the view in order to
compute the aggregate values in a list view. As it turns out, many views
in odoo ([1], [2], ...) didn't meet this requirement. In stable, views
are not updated automatically and it requires a manual intervention.

Even though the views should still be fixed, this commits allows falling
back on the default number of digits in case the currency is missing.

[0]: https://github.com/odoo/odoo/commit/f112e923ff18679b4bf546677f240f6bf83f3bb2
[1]: https://github.com/odoo/odoo/commit/eaec9f7c3c28e2ee9d42597052a21e6b2695cd60
[2]: https://github.com/odoo/enterprise/commit/5ca99702e44ef09aed504e93a302bfe43997193e

opw-3316448

Part-of: odoo/odoo#125892

*: account, event_booth, gamification, hr, project,
   website_event_track, website_hr_recruitment, website_slides

HTML fields that appear in the front-end can be modified using the
website editor. Some of them are sanitized in a way that breaks the
behavior of snippets that can be dropped within them.

This commit adapts the sanitization of those HTML fields so that the
snippets behave as expected.

opw-3267589

closes odoo/odoo#125650

X-original-commit: 477cd32c7924ce79e8f29cf567fbbc625f24534f
Related: odoo/enterprise#42802
Signed-off-by: Romain Derie (rde) <rde@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#125914

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

In the course fullscreen view, a black overlay is
hovering the content on medium screen size and lower
when the sidebar is active.

Fix the black overlay which is still showing after
closing the sidebar. When the sidebar is close the
overlay shouldn't be displayed.

As the content is translated to the right and still
fully visible on medium screen size, a black overlay
isn't needed. Only show the black overlay for small
screen size and lower.

Task-3371743

closes odoo/odoo#125036

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