[FIX] html_editor: replace <div> with baseContainer on paste

Before this commit:

- Visually empty <div> elements could be inserted during paste.
- These empty blocks created invisible spacing in the editor.
- External styles inside pasted <div> elements were not removed.
- The placeholder (`Type '/' for commands`) could not render correctly
  in those areas.

This regression was introduced in commit `odoo#196481`, which stopped replacing
blacklisted tags like <div> with <p>. As a result, cleanForPaste no longer
stripped inline styles from <div> elements.

After this commit:

- Non-empty <div> elements are now replaced with a valid baseContainer element.
- Empty <div> elements are automatically removed from pasted content.
- This restores the expected cleaning behavior and removes unwanted styles.

task-4805536

closes odoo#210797

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

[FIX] web_editor: prevent direct writing to history

This commit prevent direct write to history, also,
removes it from copy_data as it would fail anyway when trying to
write the history

closes odoo#217167

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

[FIX] stock_account: get singletone value within loop

I'm not sure how to reproduce right now. Clue: these modules are installed:
- sale_stock_margin
- stock_account

Other clue: user is going to an mrp.production order and clicking on "Set as done".

Some unknown combination of facts under this situation make multiple `sale.order.line` have to recompute their `purchase_price`. It happens that some product involved is measured in Units, while some other is measured in Kg.

At the end of the rabbit hole, the code ends up here, where there's a pretty obvious bug: a singleton value being extracted from a multi-record variable.

So, yes, this is probably the worse fix description ever. 😅 However, the bug is so obvious that I'm not sure I really need something more elaborate in this case. So, here's the fix!

@moduon MT-7556

closes odoo#211504

X-original-commit: 9ec7acf
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>

[FIX] stock_landed_costs: preserve sign for vendor refunds in landed …

…cost

Before this commit, creating a landed cost from a vendor refund (move_type = 'in_refund')
incorrectly treated the refund amounts as positive, leading to an unintended increase
in stock valuation.

After this commit, the landed cost line amounts preserve the correct sign based on
the invoice type. If the source document is a refund (in_refund), the price_unit is
negated to properly reduce the stock valuation instead of increasing it.

closes odoo#216378

X-original-commit: 6aa19a9
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>

[FIX] website: allow defaut value for data-for form field

Scenario:
- go to the /contactus page
- edit the subject field and set a default value then save

Result: the default value is not saved.

Reason: in 13.0, field default value had priority over data-for so an
issue was solved by b637a5e that if you
saved a form, the data-for would become the default for all the uses of
that form (so eg. a job position would be set for all job positions).

In 8d0a63f the priority was changed so
data-for has higher priority than the default value, that made the
prior fix unnecessary (just a nice to have, to not save the data-for as
default that would be overridden by another data-for).

The fix was reintroduced by ca433f3 but
it removes default value if there is a data-for.

Fix: remove the filling and removing of data-for value in edition: the
data-for is not shown in the editor (allowing us to set default) but has
the priority when rendering the field in non-editable mode. This is
mirroring what is already done for data-fill-with.

The added test steps, verify that the default value that is overridden
by a data-for is kept for type/email/text shown inputs.

Side note: this commit also remove useless data-fill-with="undefined"
attributes that are added when editing field. They shouldn't cause any
issue unless someone add a "undefined" field in the prefilled fields.

opw-4794903

closes odoo#211083

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

[IMP] hw_drivers: allow saving db_name to conf

See odoo#214960 (master)

The PR mentioned above adds fixes to connect to a DB that is part of a
multi-DB instance. This includes saving a new configuration key,
`db_name`, to keep track of the current database name.

This commit backports just this functionality, making older versions
compatible with the new pairing token that includes to DB name. This
prevents a potential traceback if using this new token format.

task-4815521

closes odoo#215286

X-original-commit: a24aca2
Signed-off-by: Louis Travaux (lotr) <lotr@odoo.com>
Signed-off-by: Max Whale (mawh) <mawh@odoo.com>

[FIX] l10n_jo_edi: Credit notes lines matching by discount

When generating a credit note for an invoice with multiple lines of the same product
(same product_id, name, and price_unit) but different discounts,
the system incorrectly matches both credit note lines to the same invoice line.
This commit solves this issue by adding line discount to
the criteria used to match credit notes lines with invoices lines.

task-4876849

closes odoo#214779

Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>

[FIX] tools: facade, support isinstance of the wrapped class

Oversight of c6eb8bb

opw-4838986

[FIX] website: fix body color below if page bigger than viewport

This reverts the fix of commit 2597d6f
and flatten the background color of the body element instead.

Scenario:
- set a color to the body different than white
- add snippets to have a height higher than the viewport
- go down in the page

Result: the background color is only set up to the viewport height.

Cause:

Before 18.0, the body takes 100% of the page height because we are scrolling
over the #wrapwrap element.

In 18.0 with 189a7c9, we are scrolling
over the body element, that combined with the body having a height of
100%  makes the body element being positionned from 0 to viewport height,
and it's not present below that.

Also to set background of the whole page, the browser uses the body
background if there is no background on the html element, so even if the
body didn't cover the whole page, we were getting the body color on the
whole page.

So the change in 2597d6f that set the
html element to white, causes the background color to only be applied to
up to the viewport height, with the background being blank below that.

Fix: set the body background color to the flattened rgb color.

opw-4863179
opw-4863724

closes odoo#213858

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

[FIX] purchase: show purchased quantity in smart button if product is…

… archived

Steps to reproduce :

1) Install the Purchase module
2) Create and confirm a Purchase Order with a product and quantity
3) From the Purchase Order, open the product and archive it

Issue:
Before archiving the product, the "Purchased" smart button correctly
displays the total purchased quantity.
However, after archiving the product template, this smart button
displays 0.0, even though purchases exist.
Additionally, clicking the button opens a blank purchase order
line view instead of showing related records.

Cause:-
Archiving a product template sets active=False on the template and its variants.
The computed field purchased_product_qty relies on the variants to
calculate the total. Because the variants are inactive post-archival,
the compute method sees no records, resulting in a displayed value of 0.0.

Similarly, the smart button action uses the active variants in its domain,
so it fails to find any related purchase order lines.

Solution:

The context is now explicitly set with active_test=False when computing
the purchased_product_qty and when generating the domain for the
smart button action.

This ensures that even inactive variants are included in the calculation
and the view logic, preserving the correct purchased quantity and showing
 the relevant purchase lines after archival.

opw-4781578

closes odoo#212901

X-original-commit: 939de53
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Altaf Shaik (alsh) <alsh@odoo.com>