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

X-original-commit: 15aefa56
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>

Commit 1e82e273 adds cogs account move lines for 'ship later'
config at the picking validation. The issue appears if the delivery flow
is in multiple steps. The account move lines will be created for each
pickings.

This commit ensure the last one actually create the aml only

closes odoo/odoo#125358

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

Commit 1e82e273 makes ship later option create additionnal account
move line for Cogs at delivery validation. The issue is the accounts was
not correct. The desire result should be the following for a product of
cost 10, sale price 11 and 15% taxes.

 At PoS Closing                             | Debit | Credit
-------------------------------------------------------------
215000 Taxes 15%                            |  0.00 |   1.50
200000 Pos account                          |  0.00 |  11.00
600000 Expenses                             |  0.00 |   0.00
101200 Account Receivable                   | 11.50 |   0.00
110300 Stock interim (delivered)            |  0.00 |   0.00
-------------------------------------------------------------
                                            |       |
 At delivery validation (manually created)  |       |
-------------------------------------------------------------
110300 Stock interim (delivered)            |  0.00 |  10.00
600000 Expenses                             | 10.00 |   0.00
-------------------------------------------------------------
                                            |       |
 At delivery validation (from stock layers) |       |
-------------------------------------------------------------
110100 Stock valuation                      |  0.00 |  10.00
110300 Stock interim (delivered)            | 10.00 |   0.00

Opw: 3324972
X-original-commit: b7e3db6f16e0ce42b226fecce05dfa5b586190fd
Part-of: odoo/odoo#125358

If there are some dependencies between BoM's operations, a traceback
will appear when the user removes one WO.

Steps to produce:
- From Manufacturing > Configuration: Enable Work Orders.
- Open any Bills of Material.
- In 'Miscellaneous' tab tick the 'Operation Dependencies' boolean.
- Set 3 or more operations in the 'Operations' tab.
- After saving the BOM add 'Blocked By' in the operations.
- Now Create Manufacturing Order for that BOM.
- Delete the one or more workorder(s) from mrp order.
- Now click on the 'Confirm' button, and the error will be raised.

The loop is incorrect because we iterate on the BoM's operations but
the keys of the dict `workorder_per_operation` are based on the MO's
work orders. Therefore, if we remove one WO, the dict will not have
any key for the related operation, hence the traceback.

sentry-4146643254

closes odoo/odoo#120745

Related: odoo/enterprise#41956
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

This commit improves the performance of `_is_applicable_for`, by:

1) Leveraging the `product.category.parent_path` field.
2) Use `applied_on` for the `if` conditions, which is ~100% faster than using
   the many2one fields due to the related record initialization.

These micro-optimizations are important because of the way `_is_applicable_for`
is used.

See: https://github.com/odoo/odoo/blob/0a5d84289/addons/product/models/product_pricelist.py#L169-L193



Which, for demostration purposes, could be simplified to:

```
for product, qty, partner in products_qty_partner:
    for rule in items:
        if not rule._is_applicable_for(product, qty_in_product_uom):
            continue
```

On a database with 470 products, and about the same number of pricelist items,
these optimization result in a ~30% speedup when computing prices for all
products at once. It may be even better depending on how many nested product
categories are used in the database and in the pricelist rules.

closes odoo/odoo#125553

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

`_lt` must be used instead of `_t` for `gettext`s that are called when
the file is loaded.

closes odoo/odoo#125538

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

Commit 91d0e9c6 made sure that excluded
combination did not appear in /shop search results, but it significantly
slowed down searches, even in databases without exclusions.

Since the excluded combinations cannot be added to the cart (and the
original feedback did not come from an effective ticket), we believe
the gain is not worth the cost.

This commit reverts that change.

Task-3326948

closes odoo/odoo#125187

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

Because if a tag is still linked to a tax or an account, then it's probably also still referenced in a report line, and it makes no sense allowing to delete such a tag.

closes odoo/odoo#124789

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

This commit separates the test that was added together with the "not
move images twice within image wall" fix because it requires additional
fixes for working in 16.0.

task-2990053

closes odoo/odoo#124608

X-original-commit: fa233f80
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

*: web_editor

During the masonry layout calculation of the images wall snippet, the
image height is used to determine into which column each image is
inserted. Their height is zero until they are actually loaded. Because
of this, the column into which an image is inserted can be wrong.

This becomes more obvious in 16.0 because since [1] the image selection
is lost when moving it within an Image Wall because it is replaced by a
clone when using masonry mode.

This commit makes sure that the images are loaded before taking their
height into account when building the masonry layout.

This involves two changes:

1. By awaiting `wUtils.onceAllImagesLoaded(this.$target)` after the
insertion of each cloned image, we are sure that the reached height of
each column is available before deciding where to insert the next image.

2. Before re-selecting the previously selected image, we need to be
sure that it is loaded. Therefore we keep track of the last masonry
layout operation and await for it. This way, we rely on the await of
the last image as described in point 1.

Additionally, as of 16.0, there is a race condition with
`snippet_option_update`: in some situations, `notify` is called before
`snippet_option_update` is completed, and before the masonry layout is
applied.  To make sure it is completed, the whole notify is run within
the mutex through a `snippet_edition_request` event.

To uphold the stable policy, making `mode` async will only be done in
master.
In stable, a new `_modeWithImageWait` is added which is called only
for the situations that causing an issue, and which enables the fix
of the masonry layout.
In 14.0, it is used when computing the layout from `start` and
`addImages`.
In 16.0, it is also used in `notify` when images are removed or moved
around - because masonry clones the images.
In master, it is always applied.

Additionally, this commit also rounds the computed size of images inside
the masonry layout calculations.

Steps to reproduce:
- Drop an Images Wall.
- Add four images, the first one being taller than the others.

=> The fourth image sometimes appeared below the tall image.

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

task-2990053

Part-of: odoo/odoo#124608

Since [1] the "Images Add/Remove All" buttons are on top of the
background options in order to appear as the first option for the
"Image Wall" snippet.
This makes the JS related to the handling of the options of that
snippet created twice: once for the buttons above and once for the
options below.
Because of this, events are registered by both instances and they both
get notified on option update. Therefore, when an image is moved, it is
moved twice instead of once.

This commit differentiates both instances, and makes the one that
handles the "Add" and "Remove All" buttons be the only one that works on
the images.
In stable the differentiation is done with conditional statements.
In master the instances should be of distinct classes.

Steps to reproduce:
- Drop an "Images Wall" block.
- Switch the "Mode" option to "Grid" instead of "Masonry".
- Select the wine glass image in the third column.
- Click on "Move to previous".

=> The wine glass image ended up in the first column because it was
moved twice.

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

task-2990053

X-original-commit: fa233f80
Part-of: odoo/odoo#124608

Inside the Images Wall snippet, images are dispatched to columns
depending on the height already reached by each column. This computation
relies on a sub-pixel height which leads to a confusing behavior.

This commit rounds the sub-pixel height to a visible pixel height to
avoid the confusion.

Steps to reproduce:
In the default images of the Images Wall snippet, the third image (sign)
is one pixel taller than the other ones.
- Drop an Images Wall snippet.
- Select the "sign" image.
- Move it to the first position.
(Because of another bug involving a race condition with the loading of
images, you might observe a different behavior. Move to first position
again to recompute the layout several times.)

=> The compass image moved to the first column.

task-2990053

X-original-commit: 1fc45be924e904dc595af61e0845b91cc5d24a49
Part-of: odoo/odoo#124608

When using the previous button in an image wall, the image wraps around
but skips the last position.
When using the next button in an image wall, the image does not wrap
around.

This commit fixes this inconsistency by using the same behavior as the
one in 15.0 since [1]: wrap through all positions in both directions.

Steps to reproduce:
- Drop an "Images Wall" snippet.
- Add 6 images.
- Select an image.
- Click repeatedly on "Move to previous".

=> The image wraps around all positions except the last one.

- Click repeatedly on "Move to next".

=> The image does not move anymore once it reached the last position.

[1]: https://github.com/odoo/odoo/commit/3931f0a67f904daea6c891a3a80aa984760a7682

task-2990053

Part-of: odoo/odoo#124608

If applied, this commit will solve the issue of unsupported operand type in
journal item(s) when currency is not set.

Steps to produce:
- Accounting > Journal Entries > Create new entry.
- Add a line in Journal Items and remove the currency from that line.
- Save > Error will be generated.

Fix this issue by calling the compute of the currency when the currency is not
available.

sentry - 4069681536

closes odoo/odoo#122462

Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

Steps to reproduce
==================

- Go to Accounting > Accounting > Journal Entries

The total at the bottom is not displayed and there is a `-` instead.

Cause of the issue
==================

The `amount_total_signed` field uses the currency_field
`company_currency_id`.
It should be present in the view for the web client to be aware of it's
value.

opw-3316448

closes odoo/odoo#125360

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

In JavaScript, createTextNode() escapes it's contents, so instead of
appending ' ' as text, we should append the character corresponding
to a non-breaking space. Alternative would be to use innerHTML.

odoo-helpdesk ticket 3372476

closes odoo/odoo#125089

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

To reproduce (V16):
 0. Install Accounting (can also be reproduced with just Invoicing, but
 there is no "journal item" menu that will ease the process to show the
 issue)
 1. (In debug), change the dollar currency rounding to 0.0001
 (instead of 0.01)
 2. Go to Accounting > Customers > Invoices
 3. Create a first invoice with:
  - a partner P1
  - set an invoice date
  - make sure that there is a payment term set (for example "30 days")
  - at least one invoiced line (the product does not matter) with the
  tax 15 % and the price to 12.36
 DO NOT confirm the invoice
 4. Create another invoice with
  - ANOTHER partner P2
  - set an invoice date
  - make sure that there is a payment term set (for example "30 days")
  - at least one invoiced line (the product and the price does not
  matter)
 5. Go back to the Invoices list view and select the 2 new (unposted)
 invoices then Action > Post entries.
 6. Check Force and "Post Journal Entries"
 7. Go to Accounting > Reporting > Journal Items
 8. Group by "Journal Entry" and unfold the 2 last invoices (that should
 be the one validated in 6.)
=> The "Partner" set on the Debit Line is the one of the other invoice
(and vice versa)

Analyse:
 This issue is a mix of different sub-issues. Solving any of this
 sub-issue would solve the issue but as other sub-issues may exists we
 will fix each of them individually.

 Sub-issue 1:
  The account.move.line (=AML) partner is set correctly before the post
  (6.), this is during the "mass posting" process that the issue happens.
  The partner is changed because of this line:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2094-L2096
  The value written to AML of id `line_id` include `move_id` which
  overwrite the account.move that was originally set on the AML.
  As the `partner` is computed only in certain circumstances, if the
  `move_id` written differ from the one of the AML, most of the values
  will be updated with the write values, but the `partner_id` will keep
  its value (this is why the swap of partner happen).

  In other words, this issue happen as `line_id.move_id` order is
  different from `key["move_id"]`. So we write on the "wrong" AML.

 Sub-issue 2:
  In theory, this issue should not have happened in the first place.
  The line:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2061
  should have prevent the re-edition of the AML (as actually no relevant
  datas are written). But the equality between the dictionaries fail due to some rounding errors.
  Here:
   - needed_after[<key Invoice 1>]["balance"] --> 14.214000000000002
   - needed_before[<key Invoice 1>]["balance"] -> 14.213999999999999
  N.B: if we don't set an "invoice date" on the invoice, a rewrite is
  done before which would prevent our issue to reproduce.

 Sub-issue 3:
  If we try to reproduce the issue without setting a "payment term", the
   issue would not reproduce.
  By setting a "payment term" the `to_delete` computation change at:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2067


  This happens as the `existing_before` keys and `needed_after` keys are
   different:
  - existing_before[<key Invoice 1>]["discount_date"] -> False
  - needed_after[<key Invoice 1>]["discount_date"] ----> None
  As the values are different, Odoo all the AML to the `to_delete` which
   then trigger their overwrite.

  In other words, if no "payment terms" were set on the invoices, the
  issue would not happen either

opw-3270471,3292931,3333799

closes odoo/odoo#124517

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

before this commit, in the mobile view, in the search bar
of the website users(forum) and events leader board,
the placeholder is shown as Search courses

after this commit, the wrong placeholder will be updated
to Search users in the placeholder as in the normal view.

closes odoo/odoo#123016

X-original-commit: 7e94e8a147cc1344b87d9800db7428384aa4b8e2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Hennecart Jérémy (jeh) <jeh@odoo.com>

At the moment, there is no test that checks that normal credit notes
(i.e. of type TD04, not reverse-charge refunds) are correctly exported
in FatturaPA.

So we're adding one. We're making it a complicated credit note (it
contains some negative amounts) in order to improve the test coverage.

closes odoo/odoo#122930

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

When we go into customer preview of a quotation for example and change the language different than English (to fr_BE for example)
we see that some of the content isn't translated  and still displaying in english.

Steps to reproduce the error :
1-Install sales and website app
2-Create a quotation for a customer and just save it don't confirm it.
3-Go to customer preview
4-Change the language to fr_BE
5-Click on "signer & payer"
6-You can see that it still display 'Full Name' in english and also some other terms

The origin of the problem is that all the parts that were rendered via a t-call gets rendered in english.
I investigated the problem and it turns out that the language code for the _t is alwyas english(https://github.com/odoo/odoo/blob/06719a84c52c7a97487b7ee0bef3bbe166d5b502/addons/portal/static/src/js/portal_signature.js#L45)
The problem is that the user_context.lang is always undefined here (https://github.com/odoo/odoo/blob/06719a84c52c7a97487b7ee0bef3bbe166d5b502/addons/web/static/src/legacy/js/core/session.js#L201)
As a solution I copied the code from 15.0 which was working fine (https://github.com/odoo/odoo/blob/4fa2dbcaf777c23758519ab0feb9707a7592cd6b/addons/web/static/src/legacy/js/core/session.js#L199-L209

).

opw-3192666
.

closes odoo/odoo#122447

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

By RPC an other user in other company can access to an other fec.

closes odoo/odoo#125391

X-original-commit: 857f2e02
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

In this commit we have made the following changes.
- Add new refuse reasons:
       - Languages issues
       - Role already fulfilled
       - Duplicate
       - Spam
       - Refused by Applicant
- Modify refuse reasons:
       - Refused by Applicant: don't like job
       - Refused by Applicant: better offer
- Clickable job position breadcrumb in website.
- Set default applicant when we create new email template
- Use the `selection_badge` widget in Refuse Reason wizard

task-3336247

closes odoo/odoo#122434

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

This commit will have nested components making use of
the usePosition hook to synchronize their repositioning.

**Before this commit**
Each component handles its own repositioning logic.
If it is mounted somehow inside another component using that
same logic, conflicts occur in some circumstances.

**After this commit**
It is now ensured that, in case of nested positioned components,
the whole chain of repositioning computations is called in the
proper order: from the parent to the children.

**Example**
- Before
  ![before]
- After
  ![after]

[before]: https://github.com/odoo/odoo/assets/1159815/3c9cfae7-db68-4707-a73c-ad7e2e71d4bf
[after]: https://github.com/odoo/odoo/assets/1159815/a21f56e0-d8e3-48c1-9509-8e6ee5040d4b



closes odoo/odoo#125359

X-original-commit: 7ceba441cc44ba6e6c7ee85008ab4b233e7f2d86
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

This reverts commit 38b689bb.

The IntersectionObserver strategy it implements do not
fullfil properly its purpose.
It was a mistake trying to use this kind of observer as
it is specifically meant for a different use case than
the one we tried to solve in the first place.

Another fix should follow directly this revert commit.

X-original-commit: 690f7b94
Part-of: odoo/odoo#125359

Issue: the xml declaration "<?xml version='1.0' encoding='UTF-8'?>" is
lost when opening the send & print wizard with existing xml attachments.

Explanation: When opening the send and print wizard, the PDF are
generated and postprocessed by `_postprocess_pdf_report`. In the
`_postprocess_pdf_report` override in `account_edi_ubl_cii`, the xml
attachments are parsed through `tree = etree.fromstring(xml)`, then the
base64 PDF is inserted, and the etree is converted to a bytes through
`etree.tostring(cleanup_xml_node(tree))` and the resulting bytes is
written back on the attachment, but the xml declaration disappeared.

Solution: include the arguments `xml_declaration=True, encoding='UTF-8'`
in the `tostring` function when converting the etree to a bytes.

opw-3144519

closes odoo/odoo#125285

X-original-commit: d89f5cb2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>

create a vendor Bill
attach the PDF
go back to list view, select the bill > print Original Bills

Issue: a traceback is raised
Similar to f814c607
In some malformed PDF files zlib is unable to extract the data properly.

opw-3368907

closes odoo/odoo#125426

X-original-commit: 41f659e0
Signed-off-by: John Laterre (jol) <jol@odoo.com>

When updating taxes, all taxes are correctly created but the link
between children taxes and their parent was not correctly set.

opw-3347425 (1st issue)

closes odoo/odoo#125406

X-original-commit: 2fd0d2bb
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>

Due to a change between Chrome 101 and 114, the CSS Custom Property
containing custom string are now always serialized using the type of
quotes used in their declaration (ie. single quotes will be kept ;
double quotes also) which wasn't the case in previous versions of Chrome
(and still not the case in WebKitGTK 2.40.0 at least).

This doesn't impact the value itself but only comparison between the
computed value and an arbitrary one (like we do in the design-themes
test).

This commit fixes it by removing the single/double quotes in the
`assertCssVariable` test helper.

The impacted precondition was introduced in odoo/odoo@b29e17765f4e912b2dd472493b5be500b3a32c87 and
odoo/design-themes@8b377af3a71b875dfc452a14206a9a1679371000 .

closes odoo/odoo#125404

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

Since d88409e8, taxes from different companies
are forbidden on sale.order.line records (which is the expected behavior).

Nonetheless, this highlighted some flows where the taxes were not properly
set/recomputed, especially re-invoicing, which is fixed by the current commit.

Fixes #123675

closes odoo/odoo#125394

X-original-commit: 6ce4019968bd0a1a11475910d35aa2ccfc2c6a9a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

It turns out `instanceof` is wonky in Firefox when multiple
documents are involved (e.g. iframe) since [1] has been fixed
and [2] has not yet been addressed accordingly.
Because of that, the check at [3] will return false and
therefore `getReference` will be a Node rather than a Function,
thus triggering the traceback.

**Solution**
Check if `reference` is typeof 'function' instead, which will not fall into the Firefox trap.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1360715
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1821790
[3]: https://github.com/odoo/odoo/pull/73130/commits/a9614e0babd6dc517287d547708a8be758c14e12#diff-86a5774240db76cdc93cb570596564cc6816ef4144a7c960f10cd347b7564e44R220



opw-3348172

closes odoo/odoo#125380

X-original-commit: 4ac33b76
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

port of this fix
https://github.com/odoo/odoo/pull/70454



Steps to reproduce the bug:

- Let's consider a delivery carrier DC with invoice policy = 'real'
- Let's consider a consumable product P with a weight = 1kg and sales price = 10€
- Create a sale order SO with 2 P and add DC as shipping cost
- Process the shipment for 1 P and create a backorder
- Process the second shipment with the last P

Bug:

Two lines L1, L2 with DC were created on SO but only L1 as a price unit and a description.
L2 had a price unit = 0€ and no description.

opw-3219711

closes odoo/odoo#125379

X-original-commit: 4ce4f9444e5050ae30e4468ff24aecb573045dc7
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Since may 2020, M$ stopped to ship their 32 bits OS.
So, there is no need to distribute a 32 bit version anymore.

This will reduce the package size by 2.

The new package will use Python 3.10 by default, that's why the
local requirements were changed (a wheel package was missing for windows
in the previous version of PyKCS11).

closes odoo/odoo#125361

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

The modified test failed non deterministically on runbot since [1].
The test simulates an action that throws an error in its setup, and
assets that a dialog error is displayed. However, the thrown error
was incomplete (no "data" key), and it crashed in the error handler,
producing a second error, which was the one actually displayed when
the test passed. We rely on the "unhandledrejection" event to handle
errors, and an animation frame may occur between the moment the error
is thrown and the moment the event is triggered.

We fix this issue by actually fixing the root cause, which then
avoids the problem: the thrown error is now complete and the handler
doesn't crash anymore, so we are sure that the error dialog is in
the DOM when we check, and it is the dialog for the error we thrown
in the test, not for a crash in the code.

[1] https://github.com/odoo/odoo/commit/38b689bbfc2b



Runbot error~21956

closes odoo/odoo#125353

Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>

Before this commit:

Duplicating the contact that is linked to an attendee of a course also
creates a copy of an attendee as well.

After this commit:

It does not create duplicate attendee in course.

Task-3253983

closes odoo/odoo#125324

X-original-commit: e6c4937437bdf5e55c48fc80faf65b5094c96879
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

before this commit, on neutralizing the database the
mollie token is not cleared from the payment provider.

after this commit, on neutralizing a database, the
token from mollie payment provider is cleared.

closes odoo/odoo#125296

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

The bills upload widget uses a custom attr "linkText". translate.py will only generate terms that are in the TRANSLATED_ATTRS constant, thereby not including these in the po template file.

To fix this, the attribute is changed to a recognised attr "title".
The JS widget will still recognize linkText, for databases that have not updated the module.

Task-3335585

closes odoo/odoo#125276

Related: odoo/enterprise#42651
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

The bank recon custom view relies on the noContentHelper. (When there are no records, a custom noContentHelper is  displayed including buttons to clear filters)

When the view is activated from a RedirectWarning, the action's help text is not marked up
therefore displaying raw html in the UI.

With this fix, the actions help key is marked up (very similar to the doActionButton)

To reproduce:
- On a DB with demo data
- Accounting -> Actions -> Lock Dates
- Set a lock date for all users (after the last unreconciled date, ensure there are no unposted moved before this date)
- You will be presented with a Redirect Warning Dialog
- Click Show Unreconiled Bank Statement Lines
- If there are lines, use the filter to search for "SomethingThatWontReturnRecords"
- You will see raw html

Task-3366470

closes odoo/odoo#125254

Related: odoo/enterprise#42641
Signed-off-by: Laurent Smet <las@odoo.com>

Plans with no company defined were not showing in the list when
launching a plan on an employee.

task-3366394

closes odoo/odoo#124853

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

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

X-original-commit: 1c128224dfcc85905671c3d9c01b3393bac15eb5
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>