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>

How to reproduce the bug
=========================.
1. Open e-Learning.
2. Create a section.
3. Add a content in the created section and change the default duration .
-> New duration is not set and it is taking the default duration only

Technical
=========
https://github.com/odoo/odoo/commit/7b7fdf8f2771840797e1d416a8275ba3666ab542


This commit introduce the feature to set default time for the content in the
backend if user put the Duration field empty for that content but because of
the extra 'not' in the condition it was always getting true so every time
default value is stored and if completion_time is not there then it is set
to 0.

After this Commit
==================
Now whatever duration user will put, it will be set and if completion_time is
not given then it will give us the default time.

Task-3340462

closes odoo/odoo#135334

X-original-commit: 1c470b65bca48c2ac660fda919be7b8fc6e3990f
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

The SII module adds some fields on the taxes, so after installing
the module, those fields need to be set on the already installed CoAs.

We forgot to set the l10n_es_bien_inversion field, which is used in
l10n_es_edi_sii to send the right information about the taxes to the gov.

closes odoo/odoo#135484

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

Example: Copy the Belgian P&L, try to open the copied report => error message saying some aggregation terms cannot be expanded. If you open the its form view, you can see that line BE_PL_14's balance formula has been translated from this

BE_9906.balance + BE_791.balance - BE_691_2.balance + BE_794.balance - BE_694_6.balance

to this on the copy:

BE_9906_COPY.balance + BE_791_COPY.balance - BE_691_2_COPY.balance + BE_794.balance - BE_694_6.balance

This is buggy ; BE_794.balance and BE_694_6.balance should be BE_794_COPY.balance - BE_694_6_COPY.balance, in order for them to match the other lines of the copied report properly.

This bug touches other reports more generally. It was due to the fact we replaced the codes in aggregations while we were copying the lines, and not after copying all the lines. Because of that, lines that were referrenced by an aggregation expression belonging to a line coming before them in sequence were not taken into account, as they were not part of the code_mapping dict yet.

OPW-3505592

closes odoo/odoo#135467

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

closes odoo/odoo#135245

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

If leads are created using live chat, users without CRM rights cannot
access the visitors list anymore because the lead/opportunity
information is not available to them.

This commit limits the display of `lead_count` to the
`sales_team.group_sale_salesman` group.

Then, the visitor's form cannot be accessed because the "Lead" smart
button fails to load.
This commit therefore limits the display of the button to that same
`sales_team.group_sale_salesman` group.

In 14.0, the column still appeared without the `lead_count` value
displayed, but clicking on it raised a traceback.

Steps to reproduce:
- Install `website_crm_livechat`
- Login as Mitchell Admin
- Send a message in the live chat
- Go to Discuss
- Answer the livechat message with `/lead New`
- Go to Settings / Users / Marc Demo
- Remove the Sales rights
- Logout
- Login as Marc Demo
- Go to the Website / Reporting / Visitors page

=> The page could not be reached and an access right error message was
generated.

opw-3475301

closes odoo/odoo#135399

X-original-commit: 7de453477d7c23e607a15e0d60613080857e3371
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Robin Lejeune (role) <role@odoo.com>

This replaces the former domain operator '?=' which is not allowed, This domain property, new to Odoo 16 does not permit the edition of the field with Studio, this change will enhance the configuration and will prevent future issues.

owp-3484144

closes odoo/odoo#135243

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

A previous commit made to add a new (triangular) tax introduced
a bug where the tag 3b (omzet) was archived, leading to journal items
not being picked up by the modified tax report.
This commit should add the new tag 3bl (omzet) on the items containing
the previous 3b (omzet) tag when upgrading the module.

closes odoo/odoo#134158

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Current behavior:
If a PoS had a different currency than the company currency, the total
due was not converted in the PoS currency. So when you paid the total
due it was not the correct amount.

Fix:
The total due is now converted in the PoS currency when the PoS is
loading the data. We also had to change the refreshTotalDueOfPartner to
retrieve the total due in the PoS currency.

Steps to reproduce:
- Create a PoS that uses a different currency than the company currency
  (change the journal, pricelist and payment method)
- Make some payments with this PoS using the customer account
- Check the total due of the customer account in the PoS, it's not the
  correct value.
- Try to pay the total due, it's not the correct value either.

opw-3469682

closes odoo/odoo#133061

Related: odoo/enterprise#46718
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>

Fix a corner case when the expense currency doesn't update when a cost is added to the product

Steps to reproduce:
- Create an expense in a foreign currency
- Add a cost to the expense product

Before fix:
Unit amount currency stays in foreign currency

After fix:
Forces expense currency to
 company currency

task-3455446

closes odoo/odoo#131043

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

Before this commit, the fiscal position is not used to determine account.

closes odoo/odoo#135289

X-original-commit: 4a447759
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Co-authored-by: Miquel Raïch <miquel.raich@forgeflow.com>

Current behavior:
When invoicing an order that was made in a closed PoS session, the wrong
partner was used for the invoice. And so the total due was assigned to
the wrong partner if you used the "Customer Account" payment method.

Steps to reproduce:
- Open PoS and make an order for a customer using the Customer Account
  payment method.
- Close the PoS session.
- Open the PoS session again, and invoice the order you made in the
  previous session.

Fix:
Use the commercial_partner_id of the order's partner instead of the
partner_id directly.

opw-3478670

closes odoo/odoo#135007

Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>

Before this commit:

-Font size does not get applied to selected cells.
-Font style buttons were active when cells are selected.

After this commit:

-Font size can be applied.
-The font styles should not all be toggle by default.

task-3477490

closes odoo/odoo#133188

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

Description:
The commit 05855b6b introduced a
fast-path for the name_search on tags from the form view of tasks.
But the implementation was too complex and wasn't handling correctly
all possible operators (it just had a fallback on the default
parent name_search implementation).
The aim is to simplify the code for better robustness and
maintainability long term.

Fix:
Convert the query to it's equivalent python code. It has a slight
performance regression than the previous implementation (we are
making 3 queries worse-case instead of 1), but the regression is
non-significant and not critical.

Affected versions:
16.0 up to master

Reference:
task-3503721

closes odoo/odoo#135323

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

We must wait for an additional tick to be sure that the error
dialog is displayed, because the "unhandledrejection" event is
triggered asynchronously.

Runbot issue-24690
Runbot issue-24691
Runbot issue-24744
Runbot issue-24733
Runbot issue-24742

closes odoo/odoo#135426

Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>