To Reproduce
============
- on Accounting, create customer invoice with a section and a notes and a product
- go to studio, and edit list view
- the quantities of the section and the note are set to 1
- this behavior lead to some errors like having wrong value in total if we aggregate the quantity column

Problem
=======
`account.move.line` is initialized by quantity = 1

Solution
========
when creating lines of invoice, set quantity of section/note to 0

opw-3010889

closes odoo/odoo#103377

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

The current implementation of the many2one file upload in website form
will lead to a traceback in case of m2o fields.
It is currently only working with x2many fields. Note that it was
introduced as such with [1].

Step to reproduce:
- install website_sale
- drag & drop form snippet and click on it
- select "create customer" as action option
- add new existing field
- select "Main attachment" and save
- try to submit the form with a file uploaded in that new field
-> Traceback `ValueError: Wrong value for..`

This commit makes it work for all type of relational field.

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



closes odoo/odoo#102704

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

This commit fixes wrong usage of t-attf of [1].
It would output in the DOM `rel="len(active_tag_ids) and 'nofollow'"`

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



closes odoo/odoo#104165

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

*: web_editor

Since [1], it was not possible to edit a company team snippet image
anymore as soon as the page was saved once. Indeed that commit added
o_not_editable/contenteditable="false" on the parent column to make sure
no text can be added in that column and contenteditable="true" on the
images so that they are still editable (even though HTML-specs-wise
adding contenteditable="true" on images probably does not mean much as
images are self-closing tags, our editor understand that as the ability
to edit the image anyway). That contenteditable="true" part is however
removed when leaving edit mode... and was not restored upon entering
edit mode again.

This fixes the problems with an ugly patch. We'll review what to do in
master.

Funny enough, that bug was actually gone in 15.0... by mistake. A recent
bug fix actually reintroduced that isolated bug at [2] (by reintroducing
the fact that images in a non-editable environment are not possible to
edit). The 3 opened tickets this commit mentions were actually reported
for 15.0 immediately after that, while the 14.0 being broken about this
since the beginning apparently did not bother anyone.

[1]: https://github.com/odoo/odoo/commit/656cac1bf21c7c5a56aa569008aac58436c747fb
[2]: https://github.com/odoo/odoo/commit/e113bae04a64a8bd341a80736086ab7c25079dd3



opw-3031217
opw-3032482
opw-3035289

closes odoo/odoo#104156

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

This is a follow-up of [1] which was a backport of [2].
The backport was missing the new terms in the translation file.

Also, it was probably better to keep the hint about the page being
reloaded when adding a font.
It was removed in 16.0 because since frontend > backend revamp the
options are not warning you about changes before reload anyway, so it
was adapted to fit the new "automatic" style. But it's not the case in
lower version, so we might as well keep it.
Note that this commit will be directly squashed in 15.0 in the forward
port chain of [1].

[1]: https://github.com/odoo/odoo/commit/fa362f721ba5d83e17fcdc3a87bdf638d464359d
[2]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd



closes odoo/odoo#104137

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

Steps to reproduce:
- set time effeciency of a workcenter to less than 100
- on a product page with a BoM using that workcenter
- for the cost click on compute price from BoM

Bug:
workcenter effeciency is not taken into consideration

Fix:
included time_effeciency in computing the expected duration
addepted tests to take it into consideration aswell

opw-3033672

closes odoo/odoo#103705

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

Backport of #83422

closes odoo/odoo#104101

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

This is a backport of [1] from Odoo 16

-----------------

Before this commit, the only possibility when adding a google font was
to use google servers to serve the font.

This was not ideal as some people really want to serve it themselves
without the need of their visitors to reach google servers.
That's especially true since recently where it seems like German clients
are receiving letters about that to tell them it's illegal and this
should be changed, as it wouldn't respect the GDPR.
Somehow, it seems related to the fact that google knows you visited a
website by just downloading the font, because they very well know with
just your IP who you are exactly.

It's yet unsure if that issue is well-founded or not, but since German
courts seem to be sanctioning people about this, there is no reason to
not at least provide a workaround.

What is sure is that it makes a lot of noise and more and more people
seem to be impacted by this as many opw are getting opened, as well as
github messages.

Whether it is well-founded or not is thus not really our problem
anymore, we should just provide a way for our users to protect
themselves against this "German law problem" (or at least think they are
protecting, if Odoo thinks that's a non issue or the German court is
wrong or ambiguous).

Note that a cookies banner to inform users would not be enough for that
"problem", as the user would already have accessed your website and thus
the related problematic fonts.
Another solution which is not something we want (at all) would be to
serve local system fonts while the user did not consent about google
fonts, or having a blocking screen page telling people visiting the
website will fetch google fonts. Obviously those 2 possibilities are a
no go as it leads to terrible UX.

Finally, note that:
- in Odoo 16, the default fonts will be the system fonts, meaning there
  won't be any call to google by default, regardless of this pr
- there is a work in progress to improve the current cookies bar to
  differentiate essential and non essential cookies and to allow user
  to accept only one or both (task-2800976).

Useful links:
- https://github.com/odoo/odoo/issues/83638#issuecomment-1054470699
  ODO detailed point of view about this
- https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
  The German law about this

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



Closes #83638
task-2756486
opw-2970167
opw-2960466
opw-2960555
opw-2952427
opw-2800976
opw-2748647
(possibly many more)

Courtesy of @bso-odoo for the regex part which was inspired by another
of his google font fix attempt

closes odoo/odoo#103389

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

Have the following taxes:
- Tax A: 15%, included in price
- Tax B: 21%, included in price

Create a product P with list price 115 and tax A

Have a fiscal positions FPOS configured with:
- Detect Automatically checked
- Country: Belgium
- Map tax on product: A -> B

Open a web shop session as guest, add P to cart
Go to checkout: Price total will be 115
Fill address details with Belgium address
Go to confirmation page

Error:
Price total will be 100. In the application of fiscal position the wrong
unit price is used

opw-2973879

closes odoo/odoo#103932

X-original-commit: 17aa4051
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

when you open course ratings view, it may show also
some project ratings, if project id is same as course id.
This commit solves the mentioned problem.

Task-2997847

closes odoo/odoo#101244

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

On recursive BoM with more than 3 nested levels, the cost of the child
bom is wrong resulting in a wrong total

Steps to reproduce:
1. Install Manufacturing
2. Create products C1 (with cost 5€), P1, P2, P3
3. Create BoM for 2 units of P1 with 1 unit of C1 as component
4. Create BoM for 1 unit of P2 with 1 unit of P1 as component
5. Create BoM for 1 unit of P3 with 1 unit of P2 as component
6. Go to the BoM of P3 and open 'BoM Structure & Cost'
7. BoM cost of P3 is 1.25€, it should be 2.5€

Solution:
The quantity used to compute the price of a child bom should not be
divided by the child bom quantity

Problem:
When `_get_price` calls itself (with a child bom), the factor passed is
wrongly divided by `line.child_bom_id.product_uom_qty` because the
quantity used to compute the price of a component is already divided by
`bom.product_qty`
https://github.com/odoo/odoo/blob/eaf5618dc416a4565e084316595da4a0d8377acc/addons/mrp/report/mrp_report_bom_structure.py#L207



opw-3007792
opw-2990445

closes odoo/odoo#103796

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

It is not possible for a user to add a carrier directly on a picking if
the invoicing policy of that carrier is set to "Real Cost"

To reproduce the issue:
1. Enable a carrier C
2. Setup a shipping method SM:
    - Carrier: C
    - Invoicing Policy: Real Cost
3. Create and confirm a SO with a product
4. Edit the related picking P:
    - Carrier: SM
5. Validate P

Error: a Validation error is raised "The operation cannot be completed
[...] Model: Sales Order Line (sale.order.line), Field: Description
(name)"

When validating the delivery, we try to create a new SOL with the
shipping cost. We then update its description with the carrier name.
However, since the carrier has been directly added on the picking, the
sale order does not have that information. We should rather get this
information from the delivery.

OPW-2862306

closes odoo/odoo#103764

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

When creating a recipient from composer_suggested_recipient the user
is free to modify the partner form however they want.

This can lead to them inputing data which will create a partner
that does not match the suggested partner data.
In that case the box acts as if the partner was not created.

This aims to remove the partner in such cases and warn the user.

task #3016112

closes odoo/odoo#103596

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Before this commit: if you use the lot/serial number for the products, it
won't load correctly through the UI.

closes odoo/odoo#103815

Issue: https://github.com/odoo/odoo/issues/100888


Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Necessary improvement to the snailmail invoice layout for snailmail to work since Pingen has deprecated their v1 API with the plan to shut it down at the end of 2022 + their v2 API's validation is stricter.

closes odoo/odoo#103379

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Pingen's v2 API does not offer an endpoint to generate a Cover Page automatically with an API call anymore, thus the need to generate it and append it to the invoice from the client-side beforehand.

Part-of: odoo/odoo#103379

When writing a workorder start or end date from its manufacturing order
(and if the MO is unplanned), an error is thrown

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Open an MO with Work Orders
4. Unplan the MO
5. Add a Scheduled End Date to one of the Work Orders
6. Save
7. An error is thrown

Solution:
Compute the new duration only if both `start_date` and `end_date` are
set (and one of `date_planned_start` and `date_planned_finished` is
passed in values)

Problem:
When only one of `date_planned_start` or `date_planned_finished` is
written on an `mrp_workorder` (and the other is not set), the method
`_calculate_duration_expected` is called but it fails because it passes
a False value instead of a datetime which will raise the error `'bool'
object has no attribute 'tzinfo'`

opw-3004280

closes odoo/odoo#101961

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

New phones go up to 48MP (Samsung Galaxy A22).
Also the error message was saying 4.5 instead of 45.

opw-3020614, opw-3020502

closes odoo/odoo#103603

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

This commit restores the possibility to control the height of the
image gallery snippet. This was indeed possible in <= 11.0 for all
snippets but it was removed in 12.0 as controlling the height via inner
paddings seemed enough and better (as responsive). For the image gallery
snippet however, this was a big regression as the height is forced to
70% of the current screen height on drop and the images inside are
displayed depending on that forced height. Trying to control via
paddings was not leading to the wanted effect.

This restores the possibility in 14.0 as 12.0 and 13.0 are now
deprecated. This is following a customer issue where not having the
ability to control the height is actually confusing as the user edits
its website across different screens and the height is forced to 70%
height of the screen used at the time of edition. With an height input
in the panel, the confusion is gone.

Note: this also introduces a `forceStyle` parameter for the
`selectStyle` option to be able to force the inline style a widget
controls. Indeed, without it, the system is "smart" and tries not to
force inline style when it is not needed (if you try to force red on
something that is naturally red (thanks to a CSS rule for example), it
won't be forced). Here, this was leading to an issue when trying to set
the height:

- Current height is 700px
- There is some code that forces a min-height on all carousel items so
  that they are the same height. As the gallery image dimensions depend
  on the block forced height (this is how the snippet work), the forced
  min-height are related to that forced height (something like 680px).
- You focus the height input and type 800px
- The same code forces new min-height on all carousel item (something
  like 780px).
- You un-focus the height input, the system tries to re-set 800px (which
  is already set)... it ends up removing it as it thinks that setting
  that height is not needed as the snippet is now "naturally" 800px tall
  thanks to the carousel items' min-heights.

opw-2838774

closes odoo/odoo#103694

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

This join is a leftover from https://github.com/odoo/odoo/pull/28248


and is not needed anymore since currency_rate is now stored on purchase.order.
Removing it allows to greatly speedup purchase.report queries.

On a database with 7000 purchase order and 1100 res_currency_rate:

From:
Planning Time: 4.411 ms
Execution Time: 19815.754 ms

To:
Planning Time: 16.914 ms
Execution Time: 77.433 ms

opw-2973044

closes odoo/odoo#101002

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

Current behavior:
If you try to edit the form view of pos.order in studio, you get a
traceback.

Steps to reproduce:
- Install point_of_sale
- Go to PoS order
- Click on studio
- Click on the button to edit the form view
- You get a traceback

opw-3008565

closes odoo/odoo#103403

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Method `consume` is called at the end of a tour. Tour can be started via debug
menu by any admin with "Access rights", however the method requires `Settings`
access level.

Fix it by adding `sudo()`. This issue could be reviewed in master.

STEPS:

* change Administration access level to "Access rights"
* start tour `sale_quote_tour`
* follow the tour steps

opw-2965772

closes odoo/odoo#99378

Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>

The liquidity line of a statement line is always expressed in journal currency.
The counterpart lines (invoice lines most of the time) are expressed in the transaction currency.
When reconciling the statement line with an invoice line, the current code sums the amounts in foreign currency to detect if there is a rounding issue or not.
However, the considered amount for the liquidity line is not expressed in the right currency (journal currency instead of the transaction one).

Note: The current test is working even without the fix in 14.0 but is failing on the next version because the code has changed.

co-author: ushyme (sesn) <sesn@odoo.com>
opw-2991183

closes odoo/odoo#103676

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

Steps to reproduce:
- Edit
- Add a snippet with columns
- Save
- HTML editor
- Set up a border on one column of the snippet with different colors for
  the top/right/bottom/left sides
- Edit
- Click on the column => crash

This is only an example, but if a colorpicker widget is linked to a
SnippetOption instance's `selectStyle` method designed to handle the
"border-color" property of an element, the value received can be split
if the item uses different colors for its top/right/bottom/left borders.
For instance, you could receive "red blue" if the item has red top and
bottom borders and blue left and right borders. In that case, the
colorpicker widget code would try to add the class "bg-red blue" on its
preview item which would crash because of the space inside).

After this commit, we simply do not show any color for this case.

opw-2803311

closes odoo/odoo#103654

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

We are spammed by some accounts that don't have credits anymore.

With this commit, when we try to send letters from the cron, whenever we
meet the CREDIT_ERROR error_code, we stop trying to send the letter.

task-2930455

closes odoo/odoo#103489

X-original-commit: f1fed40e
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Steps to reproduce:

 - Install Sales,Inventory
 - Set delivery methods
 - Set customer language in French have the user in English
 - Create sale order with at least one item
 - Add a delivery Method, Free Delivery Method

Issue:

  Sale order line related to delivery product is in both
  the customer language and user language.
  If you print and invoice, the delivery method line
  will be in two different languages

Cause:

  Partner language wasn't being applied to context
  and therefore translations were not in partner's
  language.

Solution:

  A local variable context was defined and assigned
  the partner language to in the local scope. This induces translations
  to occur in partner's language.

https://github.com/odoo/odoo/blob/cff91c6acbb7ef6a884d4dc4170574b83ff6e4cb/odoo/tools/translate.py#L416-L417



Backport of 863537b9

opw-3000159

closes odoo/odoo#103663

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Pedro <peso@odoo.com>

Before this commit there was an issue with the header effects (except
the 'Scroll') if the page did not have much scroll height when the
header decreases in height when scrolling down. When this issue appeared
it was impossible to reach the bottom of the page.

This was due to the fact that when the header size is smaller when
scrolled (e.g. height scrolled logo option), the padding-top of the
`main` is decreased and therefore the scroll height of the page too..
Which meant that, during the transition that changes the height of the
header, this decrease in scroll height immediately increase the height
of the header, then decrease, etc. in an endless loop.

This commit fixes that by no longer triggering an animation that changes
the height of the header if the scroll height is too short.

This commit also fixes an issue with the standard effect which was not
properly destroyed and left a 'translate transform -100%' on the header
when changing the "standard" effect to a "scroll" effect and the page
was scrolled.

opw-2812482

closes odoo/odoo#87757

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

- Steps to reproduce:
- Install Stock/MRP
- Create a custom view where you use move_finished_ids, for ex:

<data>
<xpath expr='//form[1]/sheet[1]/group[1]' position='inside'>
<field name='move_finished_ids'/>
</xpath>
</data>

- Create a new MO
- Traceback with keyerror byproduct_id

To solve the problem we use get() instead of accessing the key directly

- Task id: #3008264

closes odoo/odoo#102302

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

To reproduce:
1. Create a (incorrect) view manually. For example, inherit from
`res.config.settings.view.form` and do add the following view architecture:
```xml
<data>
  <xpath expr="//div[hasclass('settings')]" position="inside">
    <field name="field-dont-exist" widget="upgrade_boolean"/>
  </xpath>
</data>
```
( In practice, Odoo will refuse to let us save the view if it is incorrect
(we can bypass that by pushing directly in the database for testing) )

-> When trying to open the settings app, you will have a cryptic JS error:
`TypeError: field_utils.format[(formatType || this.formatType)] is not a function`
The goal of this PR is to improve the error to ease its correction.

Note: This issue can happen in practice after an upgrade or a failed
uninstallation of a module.

OPW-2952309

closes odoo/odoo#98189

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

Because of an issue with converting bool values, read_progress_bar didn't work
on grouping by bool fields (e.g. Active).

Related tests worked fine because mocked server responses were different from
real server responsed. So, we need to adjust mocked server too.

opw-2870937

closes odoo/odoo#103617

X-original-commit: 73a7f4e4
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

Before this commit: the "no-store" was overridden in developer mode.

'no-cache' does not require that the response must not be stored in the
cache. It only specifies that the cached response must not be reused to
serve a subsequent request without re-validating.
It is up to the browser what to qualify as a subsequent request. In
Chrome, using the back button and duplicating the tab does not. So I
agree that it's better to use 'no-store' in dev mode.

The solution is to prevent changing the "Cache-Control" if it's "no-store".

opw-2855802

closes odoo/odoo#103608

X-original-commit: 397e9179
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Before this fix, when reconciling an invoice with a refund (both using cash basis taxes) in a multicurrency setup, the two cash basis entries that got created were made so that the invoice's used the refund's rate, and the refund's used the invoice's one.

This caused confustion, and forced Odoo to always add cash basis adjustment journal items in the exchange difference move, in order to balance the accounts properly.

By not swapping the rates anymore, we avoid the creation of these journal items.

OPW 2888592

closes odoo/odoo#103554

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

When reconciling an invoice using cash basis taxes with multiple payments, it is possible that some base or tax amount falls victim of rounding errors (for example, a tax amount of 9.99 would become 4,49 when paying the invoice with two payments of half its amount, hence loosing one cent).

In this case, when the invoice gets fully paid, we fix that by using adjustment lines in an exchange difference entry (even in monocurrency).

The bug we fix here is that the lines added into this exchange difference entry were never considered as tax exigible, and hence never appeared in the tax report, even though they should. This was due to the fact tax exigibility is recomputed automatically when creating the entry, so the value needs to be set afterwards.

OPW 2888592

Part-of: odoo/odoo#103554

Steps to reproduce the bug:
- Create a storable product “P1” with BOM:
    - Type: Kit
    - Quantity: 3
    - Components:
        - product “C1”, QTY: 5

- Update the quantity of “C1” to have 10 in stock
- Go to “P1” product form

Problem:
- The on-hand quantity is 2 instead of 6 →
  10 (available qty of c1) / (5 / 3) = 6

In the `_compute_quantities_dict` function, the `explode` function is
called to have the qty of the component necessary:
https://github.com/odoo/odoo/blob/ef4ae7f62d6b690b4745b4145ce25ff02b6b29f6/addons/mrp/models/product.py#L151
but it is the qty necessary for 3 kit according to what is indicated
in the BOM, so we will have 5 qty needed of “C1” as a result:
https://github.com/odoo/odoo/blob/49234be3418169c8f3c928493b86a1a67ab55914/addons/mrp/models/mrp_bom.py#L289
Then the quantity available in stock of the “C1” (10) is reduced by
the quantity needed (5), so 2:
https://github.com/odoo/odoo/blob/ef4ae7f62d6b690b4745b4145ce25ff02b6b29f6/addons/mrp/models/product.py#L188


But this result must be multiplied at
the end by the quantity set in the BOM (3), to get the quantity per kit
→ (10/5)* 3 = 6

opw-3010175

closes odoo/odoo#103325

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

If the credential of Adyen are not correct and refresh POS after a payment
The cashier are unable to cancel or remove the payment line
Because the longpollong continue to reach Adyen to try to get a response.
This issue come from the last on POS_adyen commit:
262e50e2

With this commit we stop the polling if we can't reach Adyen server
So the correct status is setted at the payment line and the cashier
can delete it.

closes odoo/odoo#103281

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Current behavior:
When the product name is too long and the language is a right to left
language, the background gradients is flipped.

Steps to reproduce:
- Create a PoS product with a long name in Arabic (عر باب
الحرم المدني الفاخر عليقة باب الحرم ريال شاملا الضريبة)
- Set DB language to Arabic
- Open PoS session
- The background gradient is flipped.

opw-3011393

closes odoo/odoo#103310

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Take a (py.extras) datetime representing the moment "2022-10-17 00:00:00"
in the timezone of Brussels. Trying to get the related utc moment through
to_utc gives wrongly "2022-10-16 23:00:00". This happens because the
months are not numbered in the same way in Date or datetime, so that in
October for example, the offset applied was that of November which is
-60 instead of -120 (summer/winter change). We fix that problem.

closes odoo/odoo#103367

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

Issue:
The stripe idempotency keys do not allow the same key for
different endpoints hence we modify the key for refunds.

opw-2662964

closes odoo/odoo#103482

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Current behaviour:
When installing Sales, then PoS, we get an error when loading the modules.

Expected behaviour:
No error should be present when installing PoS just after the Sales app.

Steps to reproduce:
(With demo data)
- Install Sales
- Install PoS
- Get Error

Reason for the problem:
When installing Sales, there is the Product dependency that creates a product variant,
named product_product_4d.
Then in the Sales demo data there is the addition of an "exclude_for"
record (basically an exclusivity rule for variant attributes, for ex: A AND B cannot be together).
In our case it happens to be the attributes which product_product_4d was based of. Therefor the ORM
deletes said record (from the database).
Then when installing PoS, it installs Stock as a dependency, which demo data references product_product_4d,
which is not present anymore in the database.

Fix:
Remove the creation of product_product_4d and all the records that reference it.

Affected versions:
- 14.0 (separate PR)
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master

opw-2999180

closes odoo/odoo#101920

Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>