The condition for which the Fiscal Position's Note is shown only in Customer Invoices is removed because unnecessary.
A check has been added on the company's country to be 'IT'.

Task link: https://www.odoo.com/web#id=3420752&model=project.task


task-3420752

closes odoo/odoo#135960

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

adress both use cases in :
https://github.com/odoo/odoo/commit/ed2849a55c1463689cbc201a782b0200207bfd37
and
https://github.com/odoo/odoo/commit/4248aac2d224363a6ac4a59881bdb7c321623e4b



button should be red if there's no qty in stock but still be green if
the qty was reserved for the move

closes odoo/odoo#135881

X-original-commit: e243ba49137c5a6151c6da74ef4ed253f81754d9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Previously, when a view contained an x2m field that had a few thousand
records, the view would take ages to load. This was caused by a few
things in the basic model where we would linearly scan lists of records
in a tight loop, and doing so for every single other record, causing
quadratic increase runtime with regards to the number of records. For
example, creating a new batch picking in stock with 4000 existing
pickings would take up to ~20 seconds to load the view.

This commit creates a few objects to use as lookup tables in such
places, which speeds up the loading of the view to less than a second.

It also makes the context of the DataPoint into a property that's
initialized lazily on first read, as creating a context and the
corresponding evalContext can be expensive, which becomes a problem when
creating thousands of DataPoints whose context will never be read.

opw-3465073

closes odoo/odoo#135860

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

Steps to reproduce:

- Install Accounting
- Accounting > Accounting > Journal Items
- Select all items using the checkbox
- Change account to another value
- Click "OK" on the confirmation dialog

Issue:

The system fails to change the account field on the records. This issue occurs because the JavaScript code catches an RPCError when attempting
to write the values to the database but ignores it. Although this
behavior is intended, it leaves the user without any feedback
throughout the process.

Solution:

Add a danger notification with the error message when the write
operation fails.

opw-3354646

closes odoo/odoo#128736

Signed-off-by: Francois Georis (fge) <fge@odoo.com>

In stock_production_lot model, there is a field last_delivery_partner_id which is displayed in a Tree View. This fields require to compute ALL the delivery_ids of each LOT, only to display the last_delivery_partner.

This implies a big performance issue for big lots with huge tracability needs in it. The idea is simple, dissociate the computation for delivery_ids, which is only used in Form View and the last_delivery_partner_id which is only used in the Tree View.

I do agree that if both are used in the same view, it would double the computation time. But currently there is a lot of useless computation. Currently the only way to mitigate is by removing the field last_delivery_partner_id in the Tree View, but if client needs that field, it doesn't works.

Benchmark

|Lots/Serial |# Lots | # Delivery | Before PR | After PR |
|:------------:|:---------:|:--------:|
|Lots| 3 | 3  | 0.2723 s |0.0091 s |
|Lots| 4 | 6699 | 307.98 s | 0.0059 s |
|Lots | 13 | 9575 | 569.85 | 0.0036 s |
|Serial | 80  | 80  | 0.30 s | 0.42 s |
|Serial | 150 | 150 |0.39 s | 0.51 s |
|Serial | 7000 | 2000 | 0.50 s/Batch of 1000 | 0.60 s/Batch of 1000|

closes odoo/odoo#133540

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

To reproduce the issue:
1. In Settings, enable "Multi Routes"
2. Edit the warehouse:
   - Manufacture: 2 steps
3. Create three storable products P1, P2, P3
4. Create and confirm a MO for 1 x P1 with 1 x P2
   - It should create the PBM picking
5. Add a component line for P3
6. (Because the MO is locked, the user can not edit the 'to consume'
   quantity, so) Unlock the MO
7. Set the 'to consume' qty to 1
8. Save the MO

Error: P3 is not added to PBM picking. Worst: suppose the user does
the internal transfer and then checks the availability of P3, the
line will still be unreserved

Step 6, when unlocking the MO, it also triggers a save. As a result,
the SM for P3 is created with its demand defined to 0. When adding
such SM, we do several things through this method call:
https://github.com/odoo/odoo/blob/be0b61cbaf3d3b7082aca8f96dcf8a6ee7885fea/addons/mrp/models/mrp_production.py#L776


- We will adapt its procure method (here, because of 2-steps
  manufacturing, it will be MTO)
- We will confirm the new SM -> we will run a procurement for a zero
  quantity -> it will not generate any new SM

Then, when updating the SM quantity (step 7), nothing will run a new
procurement.

Moreover, this also explains why trying to reserve the SM does not
work: it's an MTO one, but it does not have any `move_orig_ids`, so
it is not possible to assign it.

Solutions:
- It should be possible to edit the 'to consume' qty of a new SM,
  even on a locked and confirmed MO
- A procurement should be executed when updating the demand of an SM
  from 0 to >0. From 16.1, a procurement will always be executed
  each time the quantity changed (see [1]). Here, we want to limit
  the impact/risk of the fix

[1] 1f4fb64a

OPW-3253204

closes odoo/odoo#135859

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

closes odoo/odoo#135812

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

In enterprise, when doing a comparison between multiple periods with values carried over to them, auditing the carryover values (through the dedicated button in the popup, in debug mode) always opened the latest period.

This was due to the fact the main options of the report were directly used, instead of the ones corresponding to the column group owning the value.

closes odoo/odoo#135658

Related: odoo/enterprise#47476
Signed-off-by: John Laterre (jol) <jol@odoo.com>

This commit fixes two issues with the ´date´ argument for
the ODOO.CURRENCY.RATE function.

First, the helper to cast the date is `toJsDate`, not `toJSDate`. Using
the wrong function name obviously crashes.

Second, the date was actually given to the server as a full ISO datetime
string, including timezone (UTC).

For function `ODOO.CURRENCY.RATE("EUR","USD", "11-30-2020 00:00:00")`, we
actually sent to the server "2020-12-30T23:00:00.000Z" (Brussels local time)
Notice that it's the previous day!

The field of `res.currency.date` is a date field, so it doesn't make sense
to send a datetime.

Now, only the date is sent ("2020-12-31")

opw-3498115

closes odoo/odoo#135847

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

Fine tuning of https://github.com/odoo/odoo/pull/133719/commits/1fd8a050dacaacc96aba1338f7fa5f73cadcb358



In company where analytic is not used, it increase the size of DB.

closes odoo/odoo#135747

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

Issue:
After 213b6885, some custom filters
on tags can throw a stacktrace.

Steps to reproduce:
- Install Project
- Project > Custom Filter > Tags contains 'Internal'
- Stacktrace

Cause:
When `limit=None`, which is explicitly set when creating custom
filters, the `name_search` crashes when comparing an `int` (the len
(ids)) with the limit which is `None`.

Fix:
Elaborate the condition to handle the case when `limit=None`.

Affected versions:
16.0 up to master

Reference:
opw-3510309

closes odoo/odoo#135761

Signed-off-by: Audric Onockx (auon) <auon@odoo.com>

Current behavior:
If you had 2 products with different expense account and using real-time
inventory valuation, there was an error when validating the picking.
This was happening because move_vals we were trying to assign multiple
moves to one pos_order here https://github.com/odoo/odoo/blob/95cec6ea3daebce6491cc2a8a69d9688322989ba/addons/point_of_sale/models/stock_picking.py#L155



The account move is actually reserved for the invoicing of the order.
So we just need to remove that line.

Steps to reproduce:
- Create a product with expense account A
- Create a product with expense account B
- Make sure both products are set to real-time inventory valuation
- Activate ship later in the PoS
- Open the PoS and add both products to the order
- Validate the order with ship later and no invoice
- Close the PoS and try to validate the picking of the order.

opw-3428033

closes odoo/odoo#135757

X-original-commit: 8eb30e410fd66f78620f5af7b9e141da3d5ccb72
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>

On the backorders, the consumed quantities are incorrect.

To reproduce the issue:
1. Create two products:
   - C01: consumable
   - P01: storable
2. Create a BoM
   - Product: P01
   - Type: Subcontracting
   - Subcontractor: S
   - Components: 1 x C01
3. Create and confirm a planned receipt:
   - From: S
   - 10 x P01
4. Set the done quantity (directly on the tree view) to 1
5. Validate + Backorder
6. On this first backorder, set the qty to 2
7. Validate + Backorder
8. Validate the second backorder
9. Inventory > Reporting > Moves History, filter on C01

Error: There are three SMs, and here are the done quantities: 1, 9
and 7. The second one is incorrect, it should be 2 (see step 6).

Since [1] the done quantity is always editable on the picking's
operations, but the feature is not implemented in subcontracting,
therefore the communication between the MO and the picking does not
work well. For instance, step 4: save the done quantity and open the
MO: nothing changed on it, its producing qty is still zero. Another
example: step 4, instead of setting the done quantity directly on
the picking, open the wizard (the MO), record 3 produced products and
close the wizard. The done quantity of the stock move is 3 but the
user can still edit it. However, if he tries to update the line,
nothing will change on MO side.

On top of these "little" bugs, it may lead to a more important one
as shown in the above use case. Step 5: at some point, we split the
MO to generate a backorder for 9 x P01:
https://github.com/odoo/odoo/blob/c47e4ac7cb5fdd690f40ab2e0f8d022ba565145e/addons/mrp_subcontracting/models/stock_picking.py#L72-L76
And, as shown, the flag `set_consumed_qty` is set to `True`. As
explained in the method description:
https://github.com/odoo/odoo/blob/a2574b45aef1ff6ff3a221b996d0bb0dda2a8c74/addons/mrp/models/mrp_production.py#L1602-L1603


So, because of this flag, the method will create a SML for C01 on
the backorder, with its done quantity set to the reserved one: 9.
However, back to the first block code: `move.move_line_ids` only
contains the SML created at step 4 (i.e., the SML of the inital
SM, with a done quantity equal to 1). As a result, in the for loop,
we only define the producing quantity of the initial MO.

This is a first issue: step 6, suppose the user rather opens the
detailed operations of the line: it displays the new MO, the
producing qty is 0 but the consumed quantity of the component is 9.
This is not perfect, but let's ignore this and continue with the
above steps. The user sets the done quantity to 2 and validates with
backorder. It runs the productions split again, we use the done
quantity as producing one on the MO, but we don't edit the consumed
quantities, hence the error.

For all these reasons, the safer solution is probably to prevent the
feature 'qty done always editable' in case of subcontracting.

[1] cacc677a

OPW-3441197

closes odoo/odoo#135120

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

The Expense dashboard[^1] is displaying values with the €
currency, no matter the real record's currency.

It should use the automatic currency formatting of LIST functions
to use the record's currency.

This commits removes the hardcoded currency formats.
Note that the automatic format displays the decimal values while
the hardcoded format did not.
This is a functional change.

This fix does not affect existing databases. Delete the dashboard
then update module 'spreadsheet_dashboard_hr_expense' if you
want the fix on your database. (or remove the format manually by
editing the spreadsheet).

Note: a previous commit (54c99ede) already fixed similar issues
for several dashboards. This one was missed.

fixes #135250

closes odoo/odoo#135799

Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>

closes odoo/odoo#135769

X-original-commit: 0d19b9e9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Steps to reproduce:
1) Create product P for $1000, with 15% Tax, publish to website.
1-bis) make sure the 15% tax is "included"
2) Settings -> search 'price' -> Tax Excluded.
3) Go to website /shop page, and edit to place the Products block, and search for

Issue:
The price displayed on the product in "86.96" (correct) but the price on the product in the carousel displays "100.00"

Cause:
The price for the carousel is not fetched the same way
https://github.com/odoo/odoo/blob/e829b345f0f5e5346be416b8354c29fa9acb74a7/addons/website_sale/data/product_snippet_template_data.xml#L388



And the method does not take into account this fourth scenario. That is:
- a tax with price_include set to True
- a show_line_subtotals_tax_selection config parameter set to "tax_excluded"

Note:
There is an issue with the case of a mapping from a tax included to a tax included:
```
param_main_product_tax_included = True
param_fpos = 'to_tax_included' # mapping from 15% to 10%
```
As if the product price is 100, the tax set on the product is 15%.
```
>>> self.env['account.tax']._fix_tax_included_price_company( price, product_taxes, taxes, self.env.company.id)
86.96
```
The price would be 100/1.15 = 86.96

And when calling `taxes.compute_all(price, product=self, partner=self.env['res.partner'])` it would return
```
included = 86.96 ; excluded = 79.05
```
The base is computed by taking the initial base such as
```
100/1.15/1.1 = 79.05
```
Instead of keeping the initial base and applying the new tax percentage to compute the total included
```
base = 100/1.15 = 86.96
total_included = 86.96 * 1.10 = 95.656
amount_tax = 8.696
```
After some discussion, it turns out this problem is a known issue. To make the mapping from 'tax_included' to 'tax_included' more sensible, we'd need to make some additional changes beyond what we're addressing in this fix.

opw-3370999

closes odoo/odoo#133501

Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>

This commit excludes off-balance accounts from appearing in tax
repartition lines.
Previously, off-balance accounts were included in the selection, which
was causing confusion and unnecessary clutter in the interface.

The need for this change was raised due to the observation
that off-balance accounts are never actually used in tax repartition
scenarios.
Including them only complicates the account selection process without
adding any functional value

closes odoo/odoo#135763

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

Intent of checking `group_no_one` was always to query the advanced
info / debug mode, however when the semantics of group_no_one got
changed in 31518bc0 this site was
missed, and now always displays "advanced" errors for internal
users. Which was not the intent.

Also since we're printing `display_name` and some of them annoyingly
hook onto context variables to show extended information, reset the
context to the user's default in order to avoid such
extended-formatting `display_name`.

Also fix "debug mode" in `TestIRRuleFeedback`, which has been broken
since time immemorial (likely as long as the group_no_one semantics
changed).

closes odoo/odoo#135741

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

Issue:
------
Since the commit [^1], it was no longer possible to apply for a job
via the website if it is unpublished.
This made it impossible to apply for internal job offers.

Solution:
---------
Since the commit [^2], it is possible to distinguish
between unpublished and archived job offers.

The behavior after this commit is as follows:

- if the job is published --> everybody can apply;
- if the job is not published --> everybody can apply but the job page is hidden;
    We need to know it, i.e. for internal use only.
- if the job is archived --> nobody can apply;
    There is an error message "the job offer has been closed".

[^1]: https://github.com/odoo/odoo/commit/72072263ae01a8bea01c7fead000159ae9d060d2
[^2]: https://github.com/odoo/odoo/commit/6c5f38ae37e9c1014bfa93dd82ffc6a3b31f0bd5



opw-3508043

closes odoo/odoo#135654

Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

The fr_CH date format has been broken for years, with unnecessary spaces
after the period. This has been removed.

The de_CH thousands separator prematurely ends after the millions
because it does not loop indefinitely. This has been fixed as well.

closes odoo/odoo#135290

X-original-commit: 287a0322
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>

Before this commit:
Negative discounts could be applied to products, which is not allowed
in Indian EDI.

After this commit:
Applied conditions to check for negative discounts and raise an error in case of
such discounts.

task_id: 3293247

closes odoo/odoo#120218

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

Before this commit it is impossible to find the qweb error when you preview an email template.

closes odoo/odoo#123557

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

The user has the option to remove the last block from the Table of
Content snippet prior to this commit, but doing so breaks the Add Item
feature because there is no reference to adding a new item in the
snippet area, and doing so is also not a good idea.

If the block is the final one in the Table of Content after this commit,
removing the last Content will remove the ToC snippet.

task-3081442

closes odoo/odoo#130584

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

When trying to customize Swiss invoice report with QR-Bill
through Studio an error was thrown because it tries to _compute_name()
on a dummy 'account.move' record with self.id=0.

This is part of a more general task in master around report customization
but it make sense to backport the fix in all stable versions.

task-id:3492033

closes odoo/odoo#135681

X-original-commit: d95aae51
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>

The following method:
 - https://github.com/odoo/odoo/blob/2091994c/addons/pos_restaurant/models/pos_config.py#L40

Gets the following query:

    SELECT min("pos_order".id) AS id,
    count("pos_order".id) AS "table_id_count",
    "pos_order"."table_id" as "table_id"
    FROM "pos_order"
    LEFT JOIN "restaurant_table" AS "pos_order__table_id" ON (
        "pos_order"."table_id" = "pos_order__table_id"."id")
    WHERE (("pos_order"."state" = 'draft')
        AND ("pos_order"."table_id" in (TOO MANY IDS HERE)))  -- for this case 178 restaurant_table records ids
    GROUP BY  "pos_order"."table_id", "pos_order__table_id"."id"
    ORDER BY "pos_order__table_id"."id"

It spends 24ms without index

After creating index it spends 0.57

It is not the unique side filtering by pos_order.state column

Check the following lines of code:
 - https://github.com/odoo/odoo/blob/f5553c550/addons/point_of_sale/models/pos_order.py#L678
 - https://github.com/odoo/odoo/blob/f5553c550/addons/point_of_sale/models/pos_order.py#L690
 - https://github.com/odoo/odoo/blob/f5553c550/addons/website_sale_coupon/models/sale_order.py#L91



closes odoo/odoo#135452

X-original-commit: a658dfcd
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>

Steps to reproduce:
1. install account_accountant
2. rename the Customer invoice journal to anything
3. print any invoice
4. the title doesn't change
5. install l10n_in
6. print any invoice
7. the title changes to the changed journal name

Issue:
the xpath replacing the title is not restricted to indian companies

Fix:
restrict it to only apply if the company is indian

opw-3473956

closes odoo/odoo#134149

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

closes odoo/odoo#133719

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

before this commit, in resume we are able to put end date less than start date
which is not possible in real life.
make change in constraint to check selected end date is greater than start date.
make changes in demo data of end date which are according to new changes.

task-3397726

closes odoo/odoo#135628

X-original-commit: 1e10907a2e493280a8c7d95656639bde425f914a
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

In Odoo 15 it was not possible to export a stock.quant, change the location_id and import it. A check was made in _load_records_write.
On the commit https://github.com/odoo/odoo/commit/778043b6ba5fd245918be77b9eaef4236ce45600

 this was removed as it was considered redundant.
Now, in Odoo 16, if we try to import fields that are allowed and fields that are not allowed, there is an error.
However, if we try to import only fields that are not allowed, no error message is raised.
This generates unreserve issues. Moreover, the quants will no longer match the move lines, which leads to inconsistencies in the traceability and mismatches between the stock and the valuation.

Steps to reproduce:
- Create a product and add some quantities in Shelf1
- Create a SO and get some of those quantities reserved
- Export the quant, change the location to Shelf2 (on the .xlsx) and import it again

This commit blocks this by slightly changing the write method.

OPW-3484329

closes odoo/odoo#133474

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

If a subassembly was used as component in a finished good and both the
subassembly and finished good were unbuilt, the subassembly could not be
produced again with the same serial (specific use case: medical hardware
refurbishment, medical device is produced/packaged (subassembly), put as
a component into a procedure pack (finished good), both are returned and
unbuilt so the medical device can be refurbished and produced/packaged
again into a subassembly with the same serial).

The _is_finished_sn_already_produced function duplicates domain was
wrongly picking up stock move lines related to the unbuild of the
finished good, making the function wrongly returning True. This fixes
the search domain and adds a test to prevent regression.

closes odoo/odoo#132723

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

current behavior:
When a product with tax included is sold with a fiscal position that
match the tax to a tax of 0%, then when you refund this order the
fiscal is applied a second time. This result in the 15% tax removed 2
times and the price of the product is incorrect.

steps to reproduce:
- Create a product with 15% tax included
- Create a fiscal position that match the tax to a tax of 0%
- Create a POS with this fiscal position
- Open PoS, and make an order with the product
- Applyy the fiscal position
- Refund the order
- The price of the product is not the same as the one of the original
  order.

opw-3371028

closes odoo/odoo#135513

X-original-commit: b1665575
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>

Before this commit, updating the color previews in the editor panel was
only done if the user remained in the "Theme" tab.

This means that those steps worked:

- Add a snippet in your page
- Go to the theme "tab"
- Change a theme color: validate the color you chose by closing the
  dropdown by clicking inside the theme panel, staying in the theme tab
- Click on the snippet
- Open the background option colorpicker -> theme colors are right

But those apparently same steps did not work:

- Add a snippet in your page
- Go to the theme "tab"
- Change a theme color: validate the color you chose by indirectly
  closing the dropdown by directly clicking on the snippet you added
- Open the background option colorpicker -> theme colors are wrong

task-3419142

closes odoo/odoo#128260

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

Steps to reproduce:
* create an invoice with a line
* change the receivable account
* duplicate the invoice

Result: the receivable account is recomputed to the default one.
Expected: we should keep it.

task-3504443

closes odoo/odoo#135366

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

Previous fix odoo/odoo#121602 did not correctly handle the case when not
all of the qty to manufacture is manufactured (the qtys to change to
were miscalculated in this case).

Additionally, it missed fixing a few more use cases when setting the
qtys to match the wizard's lines/qtys:
- if the UoM of a MO's component line is changed => the correct qty was
  not correctly converted into the move.product_uom's qty (now it is)
- if a component's move is deleted before the MO is confirmed => the
  move (i.e. the missing component) was not correctly added back into
  the MO (now it is)
- if there are 2 MO component moves with the same product => both were
  set to the same "correct qty" value (now we only set the first move to
  that qty, others are set to 0 since we have no way of knowing how to
  distribute the qtys otherwise)

Also, since an UserError needed to be added in case of a missing comp
move for a tracked product, existing error logic has been updated to
list all applicable products and the message has been improved to be
more helpful.

closes odoo/odoo#131279

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

When it is unset, the domain of an action can be either false or
the empty string, which in both cases means []. Before this commit,
we didn't process the domain in thoses cases (i.e. we kept the
false or empty string value). However, having an empty string as
domain could cause issues if it is manipulated by Domain/pyutils.
In particular, in stock.picking, clicking on "Insert menu in
spreadsheet" crashed before this commit.

To prevent those issues from happening, this commit sanitizes the
domain of the action at the first entry point, such that it's
always an array (the empty array in our case).

This commit comes with a test in enterprise, which reproduces the
scenario given above, as we couldn't find framework and blackbox
scenario to highlight it.

closes odoo/odoo#135369

X-original-commit: 0fde590b
Related: odoo/enterprise#47363
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

*website

Steps to reproduce the bug:
- Drop the "Form" snippet on the website.
- Add a new field.
- Replace the field label by "test\".
- Save.
=> Traceback of type "Cannot read properties of null (reading
'dataset')" appears.

In the `start()` function of the `s_website_form` public widget, the
field names of the form are extracted thanks to the `serializeArray()`
function. The field elements are then found by doing a `querySelector()`
on the field names. In our case, the field name of the new field
extracted by `serializeArray()` is `test\\` (there are two backslashes
because the field name is a string so the first backslash has to be
escaped by a second backslash). The problem is that this string has to
be escaped one more time in order to be used in a `querySelector()`. As
it is not the case, the result of the `querySelector()` is `null`
leading to a traceback when the code tries to access its dataset. To
solve the problem, the character `\` is encoded before being stored in
the `name`, `data-name` or `data-visibility-dependency` attribute of the
field element. Thanks to the encoding, the `querySelector()` operation
can perform correctly on those attributes.

opw-3470291

closes odoo/odoo#135567

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

When parsed, if the attachment has a basis quantity of zero,
it creates an error, because it is used in a division.
The condition that checks whether is computed
should be done only if this variable is none.

The code does not handle if `attachement_name.text` is None,
which can be caused by an orphan ID tag (e.i. "<cbc:ID />") ,
in the xml of the pdf.

opw-3470969

closes odoo/odoo#135504

X-original-commit: bfc83df7
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>

Steps to reproduce:
-------------------
- Without going to the shop first, login with a user
   who triggers a different fiscal position and pricelist than the public user.
- In another browser tab (incognito or separate tab),
    go to the shop with the public user.
- Select the pricelist previously used
   by the user in the other session.

Issue:
------
We obtain the prices for the other user's fiscal position.

Cause:
------
When we login with a user who triggers a fiscal position mapping
and go to the `/shop` page, `products_prices`  will be frozen with values
calculated with the fiscal position (via `_get_sales_prices`).

If we change our fiscal position, but use a template that contains
the same `t-cache` key, we won't re-evaluate the template.

As a result, it is possible to obtain values calculated
for another fiscal position.

Solution:
---------
As the template values take into account the fiscal position,
we need to add a `t-cache` key to identify this fiscal position.

opw-3316153

closes odoo/odoo#133949

Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>

Before this commit:

When pasting text from outside odoo, it often includes additional tags
such as <b> and <P>, along with unwanted styles.

After this commit:

When pasting text from outside odoo, those extra tags and styles are now
removed.

task-3378093

closes odoo/odoo#127393

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