When we were updating taxes from templates in a multilang localization,
newly created taxes were not translated in languages of the localization.
We also need l10n_lu migration script to be run in `end` instead of `post`
to have translations loaded.

Related: #108667
Part-of: odoo/odoo#113001

The tax with xmlid vat_0_import was missing its repartition
lines which caused validation errors.
This PR adds empty repartition lines to fix this problem.

Part-of: odoo/odoo#113001

If a tax is an aggregation of its sub-taxes it makes sense to have no
repartition line. This PR relaxes the validation in that case.

Part-of: odoo/odoo#113001

Switzerland changes its rates at the beginning of next year,
this change already has some implications on client's flow so
we add them to the localization so they can coexist with old rates till
the end of the year.
Changes:
- Added new taxes (2.5% -> 2.6%, 3.7% -> 3.8%, 7.7% -> 8.1%)
- Added tax fiscal positions to match those taxes
- Added tax groups
- Adds migration script to l10n_ch to apply those changes

Task: 3162286
Part-of: odoo/odoo#113001

When installing l10n_eu_service without a localization installed, a line fails
in the get_oss_tags function of res_company, thus halting the installation
and returning an error.

This fail is due to the function relying on the company in self having its
'chart_template_id' set, when this is not always the case.

Adding a failsafe to that function allows the installation of the module to
proceed in the event that the chart_template_id is not set.

opw-3291118
opw-3289913

closes odoo/odoo#120077

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

On Debian based systems, the `tzdata` package is maintained to reflect changes
in timezones and there is no need to upgrade the `python3-tz` package.
On the other hand, for those who are using `pip` and thus our `requirements.txt`,
the package needs to be up to date. By unpinning it in the requirements.txt:

- new installations based on pip will be up to date
- older installations based on pip can easily upgrade
- debian based installations have to maintain the tzdata package
- mixed installs like on runbot will rely on Debian tzdata

closes odoo/odoo#117527

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

Since this commit [1], the option to set the background color for
snippets in the footer has been removed. However, this should not affect
the snippets in the "All pages" popup, which is also located in the
footer.

This commit fixes that by showing the background color option for popup
snippets in the footer.

Steps to reproduce the bug:

- Drop a popup.
- Set the "Show On" option to "All pages".
- Drop a text block in the popup.
=> The text color is white over a white BG (because it is in the footer
and the footer text is white).

[1]: https://github.com/odoo/odoo/commit/00f70f7936d37ec1c7c26065b2126045337e2825



task-3102275

closes odoo/odoo#111681

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Before this commit, modifying the "bg_filter" of a snippet would also
affect its child snippets (for example, if a Carousel snippet had a
"bg_filter" that contained another snippet with its own "bg_filter").

To reproduce the bug:

- Drop a "Tabs" snippet on a page.
- Add a background image to the snippet and apply a background filter to
it.
- Drop a "Text" snippet in one of the tabs of the "Tabs" snippet.
- Add a background image to the "Text" snippet and apply a background
filter to it.
- Change the color of the background filter of the "Tabs" snippet.
- Bug: the background filter of the "Text" snippet is also changed.

task-3102275

Part-of: odoo/odoo#111681

Steps to reproduce:

- Go to a website page > Add a 'Form' block > Add a new 'Selection'
field.
- Go to the page (in 'edit_translations' mode) > The selection field
options are not translatable.

The goal of this commit is to make the select options translatable
by adding an intermediate `.o_translation_select` element.

This element will handle option's text translations from the linked
`<select/>`. The final values are copied to the original element
right before save.

opw-3233360

closes odoo/odoo#117519

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

Deleting a kit BoM will lead to an error if the kit is in the middle
of a sale process

To reproduce the issue:
1. In Settings, enable UoM
2. Create a product category PC:
   - AVCO
   - Auto
3. Create three storable products P_kit, P_01, P_02
   - UoM of P_01: `m`
   - UoM of P_02: `kg`
4. Create a BoM:
   - Product: P_kit
   - Type: kit
   - Components:
     - 1 x P_01
     - 1 x P_02
5. Create and confirm a SO with 1 x P_kit
6. Force the delivery
7. Delete the BoM
8. Create and confirm the SO's invoice

Error: a traceback appears "ValueError: Expected singleton: uom.uom..."

Because of the configuration, when posting the invoice, we compute
the COGS. During that process, we need the average price of P_kit
https://github.com/odoo/odoo/blob/640907ec1852c4e477957c865549a87d3ae840dd/addons/sale_stock/models/account_move.py#L133
We give to that method the components' SMs. In
`_compute_average_price`, since we don't find a BoM, we will bypass
the mrp override
https://github.com/odoo/odoo/blob/419e42132d9526e9d98c2126158d4f88716d17c4/addons/mrp_account/models/product.py#L48-L50
As a result, it leads to
https://github.com/odoo/odoo/blob/640907ec1852c4e477957c865549a87d3ae840dd/addons/stock_account/models/product.py#L680-L684
Where we will have the candidates of all components (i.e., several
different products). But that method is not designed for such a
situation. This is the reason why, when calling `_consume_all`, it
will fail:
https://github.com/odoo/odoo/blob/858d24a611c4c8af0dcae82a6eb4077e391398ed/addons/stock_account/models/stock_valuation_layer.py#L85


We try to get the rounding of the product, but there are actually
two of them (the two components) -> singleton error

OPW-3218141

closes odoo/odoo#119944

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

Before this commit, on a blog page with the "regular cover" and "read
next article" options enabled, the image in the "read next article"
block would shrink when the text was too long.

Steps to reproduce the bug:

- Go to a blog page (e.g. "Sierra Tarahumara").
- Enable the "regular cover" and "read next article" options.
- Enter edit mode.
- Scroll down the page.
- Enter a lot of text as the title of the "read next article" block.
- Bug: As the text increases, the width of the image decreases.

opw-3267842

closes odoo/odoo#119852

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

Before this fix the payment engine was ignoring the billing address
for sale orders in when processing payments.
After this fix the billing address will be used in the payment details.

opw - 3212748

closes odoo/odoo#118358

Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>

A previous commit[^1] added the shipping address in case the `sale`
module is installed. But it didn't manage the case where that module
is not installed.

opw-3199710

[^1]: bd5071ac

closes odoo/odoo#119557

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

Since commit [1], when we are in the `/shop/cart` page and if a language
selector is in the header, a cart popover also appears when hovering the
languages. This happens because the `websiteSaleCartLink` widget
selector also targets the cart links inside the language buttons.

This commit solves this issue by excluding the language selectors from
this widget selector.

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



opw-3288727

closes odoo/odoo#119685

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

This revision follows
- odoo/odoo@5e81850ea64b533f0576c919a427820554096284
- odoo/enterprise@e484b4da0c8b70225e91cc66b64ac1b3a0bcc685

Before this commit, links scrolling to an anchor with a special
character did not work and displayed a traceback. The issue was that to
check that the anchor is valid, we don't need to check that the anchor
is a valid url as we have been doing since these commits [1], [2]. But
we only need to check if the jQuery selector is valid to correctly
target the element to which the page must scroll.

Indeed, the anchor widget returns stuff like 'ok%C3%A9%25' when typing
'oké%' wich is not valid jQuery selector. It has to be encoded to
'#ok\\%C3\\%A9\\%25' to be valid and that's what this commit does.

We also changed the way to display a new anchor to the user in this
commit. Before, we showed the anchor unencoded in a notification and now
we show it encoded. That way, if the user copies the anchor from the
notification, it's the real anchor.

Also, this commit detect if the success URL of the redirect of a from is
the current page to perform a scroll to the anchor instead of a
redirect. To make this comparison, we needed to add the url code of the
language of the current page to the session info.

Also, before this commit, the page froze when we clicked on the "submit"
button of a form that redirected to an anchor that did not exist.

[1]: https://github.com/odoo/odoo/commit/0abfaeda96c2eaa868cc7fc5fa1926dfa90fc420
[2]: https://github.com/odoo/odoo/commit/b492bde6a121be1c15ed90ce0827fcfd72a12f5c



task-2172312

closes odoo/odoo#82059

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

Steps:
Say 3 existing tasks :
t0 (from which the recurrence has been created), t1, t2;
and t4 (not created yet).
When you change t0, t4 is updated as expected.

Issue:
But when you change t1, t4 doesn't take it into account.

Cause:
`ProjectTaskRecurrence._create_next_task` takes
`recurrence.task_ids[-1]` as template to create the next occurence.
Yet ProjectTask is ordered by "priority desc, sequence, id desc".
All occurrences being likely to have the same priority and sequence,
we the result ordered by id desc. So `recurrence.task_ids[-1]` has the
smallest id and so it is the oldest one.

Fix:
Take the task with the max id.

opw-3237168

closes odoo/odoo#118979

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

When converting a lead to an opportunity and merging with existing
opportunities, the list view showing opportunities is very tiny.

This is caused by the field not having the correct colspan, as its label is
hidden with the "nolabel" attribute.

This commit fixes it by assigning a colpan of 2.

Task-3179173

closes odoo/odoo#119215

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

[FIX] stock_account: prevent stock account update on product change when using manual stock valuation

If the category of a product is using manual stock valuation, when changing the product on an invoice line,
the account should not be set to the `property_stock_account_input_categ_id`. It should be the case only if
we use automatic/real-time stock valuation.

opw-3226536

closes odoo/odoo#119535

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

The tax 21% ISP actually behaves like a normal 21% tax
(it gets reported in the same lines, ...)

But the reason for its existence is that in case of the
fiscal position Revendedor ISP...  it gets mapped to the
0% ISP tax (which needs to be 0)

Before, if you would however send a 21% ISP tax to the SII,
it would be set as ISP and you would get an error telling
that the tax rate should be 0 in case of ISP.  (but now, it
will be reported as S1 and not trigger the error)

See also discussion in
https://github.com/odoo/odoo/pull/119339#issuecomment-1519720558



closes odoo/odoo#119603

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

## Bug

When sending an invoice to a recipient who is not the customer, they are
unable to view the invoice in the customer portal and are prompted to
log in.

## Steps to reproduce

1. Create and validate an invoice
2. Click on the Send & Print button, then add a recipient who is not the
   customer associated with the invoice.
3. Proceed to send the invoice.
4. Access the email that was sent to the added recipient (who is not the
   customer)
5. Using an incognito or private browsing window, open the link
   `View Invoice`

=> you should see that you are asked to log in, instead of being
directed to the customer portal.

opw-3114579

closes odoo/odoo#118766

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

Steps to reproduce:
- put the currency of the bill to eur
- change the partner with a partner with no purchase currency set

Issue:
The bill is re-set to usd

Note:
addendum to https://github.com/odoo/odoo/pull/116852



opw-3233527

closes odoo/odoo#118350

Signed-off-by: Cedric Snauwaert <csn@odoo.com>

Before this commit:
When uploading a file, if the transaction fails due to a serialization
failure, Odoo will retry the request. However, if a file upload is read
during the transaction, the file pointer will be at the end of the file,
and calling `.read()` again returns an empty bytes object.

After this commit:
Upon retrying the request, rewind uploads to the beginning of the file,
if the file supports it.

opw-3228200

closes odoo/odoo#117669

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

Steps to reproduce:

- Install `E-learning` module
- Create a user X with only "Officer" as rights for `E-learning`
- Login with user X
- Go to `E-learning` and open any course
- Ensure that the user X is not the responsible and that the course
  enroll policy is set to "On invitation"
- Invite any user not already a member

Issue:

  No user was invited (not added as member) and no warning message
  raised.

Cause:

  Due to the ir.rule "Channel: officer: create/write own only", the
  `Officer` user can only edit (and therefore invite members) on
  courses where he is responsible.

Solution:

  Add a context key to the 'Invite' buttons in the `Form` and `Kanban`
  views of `slide.channel` model so that we can raise an error only in
  these flows if the user does not have the rights to invite members.

opw-3133733

closes odoo/odoo#111642

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

There was an issue before this commit where some flags (basically all
the ones which are not tribands) would appear "broken".
This is the case for the China one where the symbol on the flag would be
squashed.
Using `object-fit` css property will keep the original flag ratio.

task-2929438

closes odoo/odoo#118903

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

Steps to reproduce:

- Install crm
- Go to settings and activate leads in crm.
- Go to leads list and select any lead, now mark it as lost.

Issue:

It will ask for lost reason. But if we do it from the Leads form view,
we don't get to set any reason. I discussed with the PO and we don't
want to add the lost reason in the leads.

Solution:

Modified action of lost so it takes leads into account.

opw-3119748

closes odoo/odoo#111226

Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>

Before this PR with a malformated pdf with factur-X, it raise.
It should not raise.

closes odoo/odoo#118496

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

Like here https://github.com/odoo/odoo/blob/14.0/addons/payment/views/payment_templates.xml#L69

, if the acquirer have display_as, it is more logical to shpw everywhere this field.

closes odoo/odoo#119295

Signed-off-by: Valentin Chevalier <vcr@odoo.com>

Some tags were not correct on taxes
IVA 0%.

closes odoo/odoo#118460

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

For now, the sale margin is incorrectly computed in group by in the sales order.

This was done in the sales order lines in abdb85fb

opw-3180556

closes odoo/odoo#119333

Signed-off-by: Morgane Demesmaeker <edm@odoo.com>

Use case: Create an import file for a picking with stock.move.line directly in
it and add some reserved quantity on the stock.move.line.

The import of stock.move.line is not possible directly via a
stock.move.line menu but it still possible on a picking or
mrp.production import. However the create does not expect that
and never reserve the quants. So it result with quant <-> sml
inconcistencies in the data and the error can not reserve more
than you have in stock.

opw-3277938

closes odoo/odoo#119201

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

When we compare majorless scripts we must ignore the Odoo version.
Otherwise a module upgrade without major Odoo upgrade would fail to run
local scripts majorless scripts. That's what happens for example when
users click the upgrade button of a module.

Example: upgrade from `11.0.1.0` to `11.0.2.0`, with a local `2.0` folder
for upgrades.
```
11.0.1.0 < 11.0.2.0 < 11.0.2.0 -> False (check before this patch)
     1.0 <      2.0 <=     2.0 -> True  (check with this patch)
```
While still: upgrade from `11.0.2.0` to `12.0.2.0`
```
11.0.2.0 < 12.0.2.0 < 12.0.2.0 -> False (before this patch)
     2.0 <      2.0 <=     2.0 -> False (with this patch)
```

closes odoo/odoo#119148

X-original-commit: 84ab74c62a19d08de8b6c7c4e3f3300d7e79bcf9
Signed-off-by: Christophe Simonis <chs@odoo.com>

Before this commit, when hovering the shopping cart in the "Boxed" and
"Centered Logo" header templates, the cart popover was not appearing.

This happened because the `websiteSaleCartLink` public widget was never
started with these templates and so, hovering the cart had no effect.
This is due to this widget selector which targeted a cart link located
inside an element with id `#top_menu`, which is not the case in these
templates where the cart link is located outside of it.

This commit fixes this widget selector, in order for the cart link to be
reachable in all header templates.

opw-3267114

closes odoo/odoo#118822

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

The current view replaces the existing groups attribute of the inventory
page in the product template form view with two specified groups (with
only one of these groups being newly introduced in stock).

This commit changes the product view to utilise an xpath that adds the
single new group (stock.group_stock_user), instead of replacing the
content of the attributes.

closes odoo/odoo#119200

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

If a partner has no VAT number (for instance: a public administration),
the xml tag `PartyTaxScheme` should not appear for UBL Bis 3.

opw-3263542

closes odoo/odoo#119094

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

When the navbar hamburger type option is set to 'off-canvas', the 'call
to action' button of the 'boxed' header is located "next to" the navbar
instead of "in" the navbar as it should be.

This commit puts the 'call to action' button in the navbar when the
'off-canvas' menu is opened.

task-3063878

closes odoo/odoo#105768

Signed-off-by: Bojabza Soukéina (sobo) <sobo@odoo.com>

- install Accounting
- in the settings, set `Rounding Method` to `Round Globally` and
  activate `Cash Rounding`
- create a cash rounding with the `half-up` method, a `Add a rounding
  line` strategy and a rounding precision of  `0.05`
- create a 7.7% sales tax
- create an invoice and in the `Other Info` tab, set `Cash Rounding
  Method` to the rounding you just created
- add an invoice line with a price of 295.00 and the 7.7% tax

You should see that the generated rounding line is not correct.
The total is 317.72; so we expect the rounding line to have a price of
`-0.02`, to respect the cash rounding.

The cash rounding computation is initiated here:
https://github.com/odoo/odoo/blob/1dcd071b27779e7d6d8f536c7dce7002d27212ba/addons/account/models/account_move.py#L944

However, `total_amount_currency` is not rounded. This introduces
floating imprecision that end up messing with the calculation here:
https://github.com/odoo/odoo/blob/563752358d233d4fc9cf1d7e7abd0b1656dc82c1/addons/account/models/account_cash_rounding.py#L53



If we take the example given in the reproduction steps, the values in
that line will be as follows:
- `amout = -317.71500000000003`
- `self.round(amount) = -317.70000000000005`
- `difference = self.round(amount) - amount = 0.014999999999986358`

`difference` is then rounded to 0.01 which not correct.

This issue does not happen starting v16.0, as `total_amount_currency`
is already rounded when `_compute_cash_rounding` is called.

opw-3133291

closes odoo/odoo#113500

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

On the bank reco widget, price_unit is following the sign of the statement line.
On the manual reco widget, the price_unit is following the accounting balance.
This leads to unconsistent tags in both widgets.

The issue has been fixed on the manual reco widget in:
https://github.com/odoo/odoo/commit/a70f804d7da68d5cc7cdd79b75d73359c41b9367



However, this breaks the bank reco widget because the tags are now reversed.
The crappy solution is to put a context key to distinguish both widgets.

closes odoo/odoo#118891

Related: odoo/enterprise#39930
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Problem: When the user installs Inventory and uninstalls it,
the Inventory Valuation journal still exists in the database.
The user is unable to re-install Inventory
if the database not in English.

Example: Client's db is in Spanish
In method "_configure_journals" ,
it searches for the Inventory Valuation journal based on the name translated in Spanish.
However, the journal "Inventory Valuation" is not translated to Spanish in the database.
Therefore, no journal would be found
and an error "Journal codes must be unique per company" will be thrown
because it will try to create another "Inventory Valuation" journal with code  'STJ'.

Solution:
Since journal codes have to be unique, it is more logical to search for an
existing journal based on its code instead of the name
since it is possible to have multiple journals with the same name but different codes.

opw-3277498

closes odoo/odoo#118982

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