The error message now shows that a VAT tax must be added to that line
and that if it is already added, it may be misconfigured. This improves
the functionality since previously it showed that there should only be
one VAT tax and that could generate confusion in some cases

[CLA] add new members to Adhoc CLA

closes odoo/odoo#95905

X-original-commit: 806961fa
Signed-off-by: Josse Colpaert <jco@odoo.com>

Before this commit if Identify Customer option was enabled for a
payment method in point of sale but no customer was set for an order,
we get a SQL constraint error that has no hints on where the problem
comes from.

This process can be improved by a better error message that directly
points out the problem.

opw-2907152

closes odoo/odoo#95754

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

Prior this fix, creating an action with (e.g.)
additional_context : {create: 0} wouldn't have any effect
on calendar view.

Now, if this context key is added, the user won't be able to create.
Also true for delete and write.

closes odoo/odoo#97522

X-original-commit: 8d108f32
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

Steps to reproduce:

  - Switch odoo language to french
  - Create a client bill for Azure Interior of $1 000 000
  - Confirm it
  - Go to the accounting dashboard
  - On the bank, click on reconcile
  - Select Azure interior
  - Click on the correct bill
  - Switch to Manual operations
  -> $1 000 000 is not a correct monetary field

Cause of the issue:

  Recently in https://github.com/odoo/odoo/pull/94126

 , `formatMonetary`
  switched from joining the currency and symbol from ` ` to a non
  breaking space, NBSP.
  To parse monetary values, the behavior was to split around NBSP to
  get the symbol on one side and the value on the other which is then
  passed to `parseFloat`.

  For the following examples, NBSP is replaced with an underscore.
  So `$_1000` becomes `$, 1000`
  But some languages such as french uses the same char as thousands
  separator.

  In that case, `$_1_000` becomes `$, 1, 000` and then the parse fails.

opw-2937403

closes odoo/odoo#97475

X-original-commit: 9d367227
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

This commit adapts the agenda template to avoid displaying a complete column
for a location if that location is unused for this specific day.

This allows having multiple different locations for your different event days
without cluttering the display by showing empty columns for unused locations.

Task-2942630

closes odoo/odoo#97373

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

2-steps receipt. A reordering rule created a picking from Input to Stock
and a purchase order to fulfill the need from Input. The user now
decreases the quantity of the purchase order and then confirms it: an
unexpected picking is created.

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
    - Incoming Shipments: 2 steps
3. Create a product P:
    - Type: Storable
    - With a vendor
    - Routes: Buy
4. Add a reordering rule to P:
    - Min = Max = 0
5. Create and confirm a planned delivery order with 3 x P
6. Run the scheduler, it should create:
    - An internal transfer IT (Input -> Stock) with one stock move SM
    - A purchase order PO
7. Edit PO:
    - 2 x P (instead of 3)
8. Confirm PO
9. List all transfers related to P

Error: There is a transfer from Stock to Input with 1 x P. It should not
exist and its stock move should be merged with SM

As explained, when running the scheduler, a stock move from Input to
Stock is created. Let SM01 be that stock move.
When confirming the PO, two stock moves SM02 and SM03 are created, both
from Vendors to Input. The first one has a quantity equal to 5 and the
second one to -1. When confirming these stock moves, we apply the 'push
rules'
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1233
Since SM02 already has one `move_dest_ids` (i.e., SM01), we skip it.
However, we can apply a push rule on SM03. It creates an new stock move
SM04 with -1 x P from Input to Stock:
https://github.com/odoo/odoo/blob/7e8a038e3a08e32a9a32ac66ef0dc67800af95cb/addons/stock/models/stock_rule.py#L192-L196
And, as shown in the above code, we then define this new SM04 as a
`move_dest_ids` of SM03. So, at that point, here is the situation:
| Name | Qty | From    | To    | Dest |
|------|-----|---------|-------|------|
| SM01 | 5   | Input   | Stock | /    |
| SM02 | 5   | Vendors | Input | SM01 |
| SM03 | -1  | Vendors | Input | SM04 |
| SM04 | -1  | Input   | Stock | /    |

Back to the confirmation of SM2 and SM3, we eventually try to confirm
the moves created from push rules (i.e., SM04):
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1268-L1269
As shown, we don't define any `merge_into`. During the confirmation of
SM04, we try to assign it to a picking. However, because of its negative
qty, we skip it:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1077-L1081
Then, still in the confirmation of SM04, we try to merge it with some
other SMs. Because there isn't any `merge_into`, we try to find some
candidates:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L839-L840
And because SM04 does not have any picking, we don't find any candidate:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L826-L828
As a result, we don't merge it and we will create the unexpected
picking.
=> In such situation (when confirming a negative push move), we should
suggest some candidates.

Last but not least: suppose the above issue as fixed and reproduce the
same steps, but this time the product P has a description. Again, when
confirming the PO, the same unexpected picking will be created.

When running the scheduler, SM01 is created and its field
`description_picking` is defined thanks to the description of P:
https://github.com/odoo/odoo/blob/f11d9c3ea08fc98e62459602d9bce004e83898db/addons/stock/models/product.py#L237-L243
However, when creating SM03, we use the name of the purchase line (i.e.,
the product's name) as description because, in our case, the product
does not have any `description_pickingin`:
https://github.com/odoo/odoo/blob/c18b2ce767dd5a5b4dbe766b849b56243dffb723/addons/purchase_stock/models/purchase.py#L523


And, as shown before, SM04 is partially a copy of SM03: it has the same
`description_picking`. As a result, SM01 and SM04 doesn't have the same
value for that field and we can not merge them.

OPW-2861605

closes odoo/odoo#97344

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

- Add translations for fr, de
task-2928312

closes odoo/odoo#97121

X-original-commit: 1feabb78
Related: odoo/enterprise#29978
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

Before this commit, the lang entries in the language switcher's dropdown
would overflow the dropdown (which was way too small).

There were no issue in 13.0 as the issue seems to have appeared since
commit [1] which was merged in 14.0 (13.5 at the time).
That commit added a `min-width: 0;` on the `.dropdown-menu` making the
dropdown visually broken in rtl languages.

There is no issue in saas-15.5 (current master) as it was converted to
BS5 where the issue do not appear.

There is probably a cleaner solution to be found to have a full
understanding of the real issue and probably make a generic solution
instead of only fixing footer language selector, but this would need to
spend more time investigating the issue.
As the error seems gone with BS5 anyway, and only this dropdown seems to
be impacted, this is a reasonable fix.

[1]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2a



Fixes #64774, fixes #63764
opw-2904798

closes odoo/odoo#97448

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

It's expected that the personal stage is in the lang of the user_id. This commit assures it happens.

closes odoo/odoo#97471

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

A test introduced with https://github.com/odoo/odoo/pull/96432


revealed an issue with the level limits for the accrual plans.

The only applied limit was the one of the current level at the end of
the run, however if for whatever reason multiple levels had to be
processed at once (if the database was shut down for a long period of
time for example), the individual levels would not apply any limit logic
to their behaviour which meant that you could have a different behaviour
between running the cron each day and running it after a long period.

This commit aims to fix that issue by applying the said limit.

OPW-2868297

closes odoo/odoo#97463

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

Commit [1] prevented edition of dynamic snippet content. Commit [2]
introduced new templates which use the class .stretched-link.
This class allows for links to spread on the card. The stretched-link
class adds a pointer-event property on its ::after that is not covered
by the rule introduced at [1].

Therefore, it was possible for a user to trigger the creation of snippet
editors on content that is not editable.

This commit improves the rule introduced at [1] to consider
`.stretched-link::after`.

Steps to reproduce:
- Install website_sale
- Drop a "Products" snippet
- Select the "Horizontal Card" template
- Click on the image
- "Column" Snippet Editors are started

[1]: https://github.com/odoo/odoo/commit/64b663fb42ddca67a06cb067c897abb5a3c4dd70
[2]: https://github.com/odoo/odoo/commit/49bd79b0bdca76415780bdfa199195371c2692e5



Related to task-2677203

closes odoo/odoo#82222

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

Prior to this commit, if an user chose to fetch 16 elements, the snippet
would bug out and display 16 elements per row.

Steps to reproduce:
- Install website_sale
- Drop a product snippet
- Select 16 fetched elements
- Layout is broken

Some legacy code introduced in [1] could result in an infinite loading
animation locking the editor out. This commit removes the code as a
fix made at [2] makes it unneeded.

Steps to reproduce:
- Install website_sale
- Enable debug mode
- Drop a "Dynamic Snippet Carousel"
- Click on the Dynamic Snippet for edit
- Sometimes the editor hangs and the page needs to be refreshed

[1]: https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5
[2]: https://github.com/odoo/odoo/commit/ac8d83cc124a6175a263e11795fda35eebe69324

Related to task-2677203

Part-of: odoo/odoo#82222

Before this commit when the header scroll effect was happening, the
related DOM updates were recorded in the editor's history.

This commit deactivates the history during the updates of the header.

Steps to reproduce:
- Drop a "Text" block in the page.
- Drop 4 "Banner" blocks below the "Text" block to make the page
scrollable.
- Save.
- Edit page.
- DO NOT SCROLL until the last step.
- Select the Text block.
- Delete the Text block.
- Click undo => Text block reappears as expected.
- Click redo => Text block disappears as expected.
- Click undo.
- Scroll down until header vanishes and reappears.
=> Redo step is lost, undo tries to undo the header animation.

task-2930568

closes odoo/odoo#97372

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

Add chart of accounts, taxes and tax report for Bulgarian localization

closes odoo/odoo#87969

Task-id: 2694779
Related: odoo/enterprise#25895
Signed-off-by: Ruben Gomes <rugo@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

Before this commit, If "Show public price & discount to the customer"
discount display policy is selected, taxed prices in the pricelist with
discounts are compared with untaxed prices in the public pricelist,
which leads to not showing the discounted values when the pricelist
value is less than untaxed list price, but the taxed value is more than
untaxed list price.

Steps to reproduce:

1. Create a product, add it to a pricelist with a lower price in a way
 that if the tax is added the price is more than its sale price, add a
 tax option to the product
2. Set the pricelist discount display policy as `Show public price &
discount to the customer`
3. Set the PoS to use tax-included prices, and to use the discounted
pricelist
4. start the PoS session, add the product, you will see that the
public price isn't shown (with a strike-through)

To fix, we can use a different function that computes the taxed public
price, so it could be compared with the pricelist price.

opw-2919734

closes odoo/odoo#97307

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

This is a backport of [1].

Since [2] whenever the image of a `product.template` is updated, the
write date of all its related `product.product` is updated.  This was
done to force a change of the unique parameter on image fields, which is
based on the last update field.

After this commit the `product.product`'s last update is instead
computed by also taking the `product.template`'s last update into
account.  This avoids the need for updating the write date when the
image is changed, but on the other hand it also forces product images to
be reloaded whenever any other field of the `product.template` is
changed.

[1]: https://github.com/odoo/odoo/commit/620b0222506a91e73eac6e08f5d17d20e3a23230
[2]: https://github.com/odoo/odoo/pull/71139

Related to https://github.com/odoo/odoo/pull/76309



task-2477438

closes odoo/odoo#96902

X-original-commit: 800d6ed0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

closes odoo/odoo#90922

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Picking a shape for an image in mass_mailing (when in developer mode)
would result in a sudden error due to a None
being passed to _getCSSColorValue

The shape picker is completely hidden in  the mass_mailing
templates editor as essentially no mail
client supports it in this version up to 15.3

Feature properly reintroduced in:
https://github.com/odoo/odoo/pull/84926



Task-2937490

closes odoo/odoo#97042

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

Before this commit, when the autofocus is used on an input with
`type="number", the `selectionEnd` is not available because the input
element's type ('number') does not support selection.

This commit checks the input type is not a number:
- if it is the case then the selection is used to place the cursor at
  the end of the input content,
- otherwise the selection properties are not used and the input is
  simply focused.

closes odoo/odoo#97312

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

As a stable fix, to not touch XML templates and break existing
translations, the ⌙ character is automatically replaced by └ which makes
more sense for the usecase and should work properly in all browsers. The
⌙ character is actually rendered mirrored on Windows 11 Chrome (and
others) as the font used for those unicode characters is left to the
browser. We could force a font of our own but it's probably not worth it.

A better solution with a SVG or CSS solution has to be done in master.
That would unify the look of the symbol across all browsers and
also prevent special characters to be placed in translations.

closes odoo/odoo#97349

X-original-commit: bc19050d
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit, when trying to paste into the Odoo editor, if file
and html was in the clipboard, the file got precedence and were added
instead of html.

task-2941679

closes odoo/odoo#97327

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

Install Documents
Open Settings > Documents, enable 'Accounting' files centralization
Configure 'Journals' with a single line
- Journal -> Vendor Bills
- Workspace -> Finance / Supplier Invoices
Now in go to Accounting>Vendor>Bills
Upload an xml representing a vendor bill, including an attachment
encoded in the <Allegati> tag
Open created bill

Traceback. The error is caused by the attachment included in the xml
registered without res_id/res_model.
In the document flow the attachment will receive a res_id, but not the
res_model, causing the traceback when retrieving the attachment

opw-2919610

closes odoo/odoo#97261

X-original-commit: 377e8eed
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Steps to reproduce the bug:
- Let's consider a company c and a user in this company u.
- Delete the logo of c
- Go to mass mailing > Create

Bug:
Traceback is raised

opw-2927807

closes odoo/odoo#96835

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

Browsers don't render html entity in the "title" attribute and we cannot use
them. Otherwise we may get values like "$ 100".

Fix it by using special character and not html entity. It works both in html
strings and attributues

The problem was reported here:
https://github.com/odoo/odoo/pull/90191#issuecomment-1156034355

STEPS: open invoice and put pointer over monetary field in the list.

Note, that to reproduce the problem, the widget should not be specifed
explicitly. See
https://github.com/odoo/odoo/blob/5b9fada39913cd456a3659faef1160f84ae19860/addons/web/static/src/js/views/list/list_renderer.js#L436-L439
https://github.com/odoo/odoo/blob/5b9fada39913cd456a3659faef1160f84ae19860/addons/web/static/src/js/views/list/list_renderer.js#L452-L456



closes odoo/odoo#96673

X-original-commit: a7424484
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>

Sometimes, no picking type match the domain, but picking_type_id is a required field.

closes odoo/odoo#97262

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

The below line raises a KeyError when `warehouse` refers to an archived
warehouse.
https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/models/stock_orderpoint.py#L396

The reason is that the SQL view created on
https://github.com/odoo/odoo/blob/01cc43b0578ecc9d1fed37a12b2468ffc9d4aedd/addons/stock/report/report_stock_quantity.py#L28-L37


doesn't take into account whether the warehouses are archived or not.

The solution proposed here is to fetch all warehouses to ensure the
lookup doesn't fail. Alternatively the view could be updated but that
will be a bigger change.

This issue was detected during the upgrade 226754

closes odoo/odoo#97222

X-original-commit: aaa7fb8f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>

Open Accounting>Journal Items
Select 1+ items with 0 credit/debit
Hit Actions>Automatic Entries
In the wizard choose 'Change Period', select an Accrued Account with
'reconcile' flag and confirm

Error will raise 'You are trying to reconcile some entries that are
already reconciled.'
This occurs because new entries, with 0 balance, will be created to match
the selected one. The flow include a reconciliation step in which the 0
balance will raise the error.

With this patch the problematic lines will be created but not reconciled

opw-2909058

closes odoo/odoo#97185

X-original-commit: 2433d5da
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. In the Routes, unarchive the route R called "Replenish on Order
(MTO)"
3. Create a storable product P
4. Update its quantity: 10
5. Create and confirm a sale order with one line:
    - Product: P
    - Quantity: 10
    - Route: R
6. Update the SO line:
    - Quantity: 8

Error: Once the SO is saved, 2 new deliveries are created:
- One from Customers to Stock with 2 x P (this one should be merged with
the existing one)
- One from Stock to Vendors with 2 x P (his one should not exist)

The route R only contains one rule, which is a MTSO one. On step 5, when
confirming the SO, `_run_pull` will be called and will create a stock
move SM01 based on that rule. In case of a MTSO rule and because there
are already some available P, the procure method of SM01 will be MTS
(see [1]). Then, once SM01 is created, we will confirm it and we won't
do anything more.

The process is not the same on step 6. When saving the SO, `_run_pull`
is called again but this time, because the needed quantity is negative
(-2), the procurement method is set to MTO (see [1]). Therefore, when
confirming such a stock move, two undesirable consequences occur:
- Because its procure method is not the same than SM01, we won't merge
the stock moves (this explains why a picking is created from Customers
to Stock)
- Because its procure method is MTO, we will create and run a
procurement to get -2 x P at Stock. It will find a rule thanks to the
route "Receive in 1 step". The rule creates a receipt from Vendors to
fulfill the need. This explains why an unexpected picking is created.

When processing a procurement with a MTSO rule and a negative quantity,
if we want to know the procurement method of the new SM, we should try
to find and copy the decision we took for the positive move (if it
exists). That way, we ensure that the 'returning phase' (the quantity
decreasing) will follow the same behavior as the initial one (when we
confirmed the SO).

[1]
https://github.com/odoo/odoo/blob/20e0ad13afa2a0ff85d555ab57a6800d3db30341/addons/stock/models/stock_rule.py#L244-L254



OPW-2885751

closes odoo/odoo#96671

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

The button should only be shown if a tokenization-capable acquirer is
enabled (or if a token already exists), but a typo made the button being
shown regardless of that (first) condition.

closes odoo/odoo#97237

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

Previous fix: https://github.com/odoo/odoo/pull/84631 missed the case
when raw_move_ids have already done move_orig_ids (i.e. when 2/3 step
MOs or subcontracting w/ resupply contractor). This made it so when
MOs are backordered, these moves would not be reserved even though they
were in the original MO.

We fix this so now we always assign backorder MOs when the reservation
method is 'at_confirm' so we follow the previously existing (expected)
behavior.

Note that this fix is very similar to other fix
https://github.com/odoo/odoo/pull/79873



Part of Task: 2777571

closes odoo/odoo#91460

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

Steps to reproduce:
- create a subcontracted product (i.e. create subcontract BoM)
- create and confirm PO for subcontracted product (qty > 1)
- try to decrease PO qty for subcontracted product

Expected Result:
Since receipt is not yet validated, the qty in the receipt should
decrease (it will in the subcontract MO as well, but this doesn't matter
since no one should work directly with the MO)

Actual Result:
A validation error occurs saying the qty to produce must be non-negative

We allow neg demand qtys to be proprogated from SOs and POs since
https://github.com/odoo/odoo/pull/76752 . While we added in a check to
make sure MOs are not created when a neg qty change is proprogated, we
forgot to add a check for subcontracted created MOs, hence the
validation error (i.e. the neg qty change is trying to create a
subcontracted MO of a neg amount.)

Task: 2777571 (issue 2 of additional issues)
Part-of: odoo/odoo#91460

Fixes a few incorrect subcontracting UX behaviors:
- When subcontract BOM is flexible, the record burger should always show
  so user can more easily record varying quantities
- When `show_operations=True` then `action_assign_serial` button in
  Operations tab should only show if subcontract BOM is NOT strict AND
  has no tracked components (instead of always showing regardless of BoM
  consumption and its components)
- When a subcontract receipt is backordered, the Done moves should no
  longer return `_action_record_components`.
- When 'show_operations=True' for receipts, we shouldn't display the
  subcontracting component lines in the Detailed Operations tab

Task: 2777571
Part-of: odoo/odoo#91460

It is currently impossible to modify the _cart_update behavoiur from website_sale_stock

The sale.order method _cart_update() updates the lines on the e-commerce shop
cart, some modules override the method adding new features, the module
website_sale_stock is one of them.

The specific behavior of _cart_update() in the module website_sale_stock allows
to delete from the sale order the products whose demand is greater than the stock.

If the specific behavior of the module website_sale_stock is needed to be
expanded or totally changed, that is not possible because the method _cart_update()
should be always super called, even if the website_sale_stock code for
_cart_update will be totally changed.

To allow inheriting just the specific behavior of website_sale_stock without
affecting other modules. This commit creates a new method _cart_lines_stock_update()
which have the important behavior for this module and will allow to be
easier to inherit it.

Based on: https://github.com/odoo/enterprise/commit/f5d92e70aaa472324cc1f0374ddb108d100bec59



OPW#2500355

closes odoo/odoo#97204

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

Before this commit:

When the page is expanded and try to add any block with an image, try to change
the image using replace button. It lands the user at the top of the page instead
of staying image place.

After this commit:

The user will stay at the image place after clicking on replace button.

Task-2753302

closes odoo/odoo#96578

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

* Broaden the valid URL pool by including some URL without subdomain
 if they have a white listed TLD.

* Change a link 'href' when we change the link label,
 if the new label is a valid URL.

* Ensure the domain extension cannot be only digit.

task-2858621
task-2901795

closes odoo/odoo#94512

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

Change the unit test to reflect new spec:

* Some TLD are white listed to not required a subdomain to be considered a valid URL.
 => .com, .net, .org + all ccTLD

* URL of a link need to be changed to equal the label, is the label is a new valid URL.

* Domain Extention cannot be only digit

task-2858621

Part-of: odoo/odoo#94512

task-2858621

Part-of: odoo/odoo#94512

When getting the on hand quantity of a product in a specific location,
the result may be incorrect.

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update its quantity:
    - 5 x P at WH/Stock/Shelf 1
4. Inventory > Reporting > Inventory Report
5. Apply the following filters:
    - Product: P
    - Location: WH/Stock/Shelf 1
    - => There is a line with 5 x P at WH/Stock/Shelf 1, which is
correct
6. Click on Inventory at Date, set <Today>, confirm
7. Apply the following filters:
    - Product: P
    - Location: WH/Stock/Shelf 1

Error: There is a line for P but its on hand quantity is 0, which is
incorrect (should be 5)

In the first search, we let the ORM handle the domain conversion. When
searching for `('location_id', 'ilike', 'WH/Stock/Shelf 1')`, it will
use the `_rec_name` of the model to find the record. In case of a stock
location, its `_rec_name` is the field `complete_name`:
https://github.com/odoo/odoo/blob/94a8ad3fae914b046064bb7ce17572be8280f6e0/addons/stock/models/stock_location.py#L19



However, for the second search, when getting the on-hand quantity of the
product, we force the use of the field `name` to find the location.
Because the `name` of the searched location is "Shelf 1", using
"WH/Stock/Shelf 1" as key search will not work.

OPW-2920904

closes odoo/odoo#97104

X-original-commit: 9a651e13
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Steps to reproduce:
- Install eCommerce with product comparator
- Open the product in </shop>
- Change the product quantity
- Click on the <Enter> key

Current behavior:
En error message appears.

Expected behavior:
No error message appears.

Explanation:
The productComparison widget overrided the submit with a selector
that was not specific to the comparison so its _onFormSubmit function
could be called from other pages creating errors. To solve the issue
we add a specific class to the form and to the selector.

opw-2936994

closes odoo/odoo#97074

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Steps to reproduce:

1- install sale, accounting
2- create a fiscal position fp that maps
tax inc t1 to any other tax t2
3- create a delivery product dp with t1 and mark it "can be sold"
4- create a new delivery method with dp
5- in a new sales order, choose fp, click on add delivery
6- the unit_price is wrong, it hasn't mapped t1 to t2
7- try adding the delivery as a product in a new sales order line
8- the unit_price is correct and the taxes are correctly calculated

Bug:

 `_create_delivery_line` is not using the same logic used
 when normally adding a sales order line although technically
 delivery product is still a product

Fix:

use `_get_tax_included_unit_price` to get the correct unit_price

OPW-2806965

closes odoo/odoo#96834

X-original-commit: 03bb18d1
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>