For performance reason, we avoided computing goals for the set of users
that didn't log in recently (See ec0c0f29).
However, users can stay logged in for a while without having a new "log
in event" (password asked), such that active internal users can keep
old values in their challenges when reports are sent, which is not good.

Until an improvement can be implemented in master, we drop this time
constraint for active internal users.

A test is added, checking the behavior of the method called by the cron.

Task-3226408

closes odoo/odoo#121301

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

product variable used in the rounding precision come from the upper
loop and won't work for all the quantites.

opw-3229080

closes odoo/odoo#121247

X-original-commit: ea923a08
Signed-off-by: Tiffany Chang <tic@odoo.com>

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

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

Allow extending tests for any modules, regardless of existing ones
in another entry of the `upgrade-path`.

Bonus point: tests no longer need to be imported in the `__init__.py`
file.

closes odoo/odoo#121218

X-original-commit: e4d1a9e0
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@odoo.com>

To Reproduce
============
- create two Vendor Bills and attach to each one a PDF from the ones
provided by the client on the ticket.
- select these two bills and and try to print Original Bills an error will be raised

Problem
=======
while merging these PDFs, PyPDF2 throws a `TypeError` which is not caught by the server

Solution
========
catch `TypeError` to raise a UserError

opw-3285540

closes odoo/odoo#121212

X-original-commit: d2b97524
Signed-off-by: abla001 <abla@odoo.com>

Steps to reproduce the bug:
- Enable “subcontracting” in the mrp settings
- Create a storable product “P1”:
    - Add a vendor:
    - supplier: “Azure interior”
    - currency: euro
    - price: 20
    - Add a BoM:
        - Type: subcontracting
        - add any product as component
        - Save
- Check that the currency of the company is in dollars
- Click on Compute Price from BoM button in the product form

Problem:
The seller's price is not converted into dollars

opw-3321346

closes odoo/odoo#121063

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

Steps to Reproduce Issue for single picking:
1. Install Sales, Inventory
2. Create an SO and confirm
3. Go to the transfer, assign the done value to be less than demanded
4. Validate the transfer and cancel the backorder

Current Behavior:
There is no exception error on the SO chatter

Expected Behavior:
An exception error should be logged on the SO chatter

Other Info: When cancelling a backorder for a single picking,
the exception error about less quantity than expected is not logged on the SO.
"process_cancel_backorder" does not call _log_less_quantities_than_expected.
As defined in "process", the exception is only logged when validating multiple pickings at once but
one is to backorder but the other is not.

opw-3222508

closes odoo/odoo#120994

X-original-commit: 92cd7d08
Signed-off-by: Tiffany Chang <tic@odoo.com>

When no new template are created in the update of taxes migration method
the execution lead to an an error in the `_process_taxes_translations` method.
Fixed a similar issue in l10n_ch migration that enables the taxes afterward
and could possibly cash in the same way if no taxes are created.

opw-3305302

closes odoo/odoo#121213

X-original-commit: 039206ec
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>

mimic what is done for `odoo.addons` __path__.

closes odoo/odoo#121147

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

Steps to reproduce the problem:
- Drop a popup snippet in a page.
- On another language, click on translate.
- Problem -> It is impossible to translate the popup.

To resolve this problem, the function `_updateInvisibleDOM` is called
even in translation mode. Thanks to this function, the invisible
snippets are now filled in the edit bar and the user has the opportunity
to display them or to hide them.

task-3098517
opw-3268592

closes odoo/odoo#112011

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

Steps to reproduce the bug:

- Let's consider an analytic account AA linked to customer invoices
- Open AA and click on the smart button Customer Invoies

Bug:

The field customer was not displayed in the account.move list view (same for Vendor Bills)

opw:3179200

closes odoo/odoo#113471

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

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

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

closes odoo/odoo#121113

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

The taxes update migration method didn't handle properly the creation
of taxes with `children_tax_ids`. Such taxes caused an infinite loop
when entering the `_generate_tax` method.
To fix this we have batched the creation of taxes.

We also fixed the comparison method that checks whether an existing tax
is close enough to the template we are evaluating to handle properly
taxes with an `amount_type='group'`. If we are evaluation such a tax
we ignore the usual checks on repartition lines.

closes odoo/odoo#120115

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

Swiss taxes retrieved by module update (and the update of taxes it triggers)
need to be active, even if the template data was set to inactive.

Part-of: odoo/odoo#120115

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

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

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

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

There is a historical code to return an error/404 when someone disable
the website info view, see [1].
There is also a feature introduced to add an option to disable the
content of this controller, see [2].
Commit [2] should probably have gotten rid of the view check in [1]
which was probably the way people used to stop this page leaking their
DB information.

From there, regardless if you deleted or disabled the view, the page
would still be referenced in the sitemap.xml, which would lead to a
traceback page (case 1) or a blank page (case 2).

This commit is simply conditionning the presence of this page in the
sitemap so it's removed from it if you disable/remove the website info
view.
It will help SEO wise to not have error page in it.

Note that we probably don't want to keep indexing this page, as it is
a technical link which doesn't bring any value to our clients to be
included in their sitemap.
It might have been useful for Odoo to perform some google search / stats
or something like that.
But since this is a stable fix, the behavior is kept as is as much as
possible.

Also note that it has always been in sitemap, even if marked
excplicitely since [3].

[1]: https://github.com/odoo/odoo/commit/8aca457e34bdec6257b9bfa917aebe4de053e2aa#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119R146-R149
[2]: https://github.com/odoo/odoo/commit/f025d3e17cbb3b1fd05152ca46af091b6e11ee20
[3]: https://github.com/odoo/odoo/commit/e19227d3ba9c9296bfc0c221ac70a863a571b9a6#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119L200



opw-3255831

closes odoo/odoo#120734

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

The website info page was introduced with [1] where the code was
apparently checking for the existence of the view (to be rendered) to be
able to handle a proper error if it did not exists.
It seems like it was to support the case where someone would delete this
view to not leak any info on the public controller. But it's uncertain
as this code is 10 years old.

It was a year later improved with [2] to have an option on the page to
be able to sort of disable it: it would simply show a blank page but it
would still be served.

As of now, the `try/except` with the `get_template()` call is crashing
and rendering traceback whenever this view is deleted, making this code
useless and not doing anything.
It's probably not needed anyway since the option introduced with [2] but
as we are in stable, this commit is making the controller return a
proper 404 page instead of a traceback.
Arguably, that part of the code could be removed. We will do it in the
master forward port.

[1]: https://github.com/odoo/odoo/commit/8aca457e34bdec6257b9bfa917aebe4de053e2aa#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119R145
[2]: https://github.com/odoo/odoo/commit/f025d3e17cbb3b1fd05152ca46af091b6e11ee20

opw-3255831

X-original-commit: e787fef0
Part-of: odoo/odoo#120734

In 14.0 the menu items in the navbar sections menu could have any level.
Since the webclient refactoring landed in 15.0 0573acae this feature has
been unintentionnally limited to two levels.
More sub menus would simply not be displayed.

**Before this commit**
- Have a menu item with the following path:
  `App/Menu/Group/Sub-group/Item`
- The `Sub-group` is displayed as an item. It is clickable but nothing happens.
- The `Item` is not displayed.

**After this commit**
Works properly as it should. See screenshots on the PR description.

closes odoo/odoo#121039

Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>

When receiving an email on a mailbox with an alias that triggers the
creation of invoices, 4 bugs could occur.

1. If the xml received contains replacement characters (U+FFFD �), and
the charset of the part of the email is "US-ASCII" the encoding of the
string will fail, preventing the rest of the flow to be completed. Be
more resilient, encode the string and ignores these characters if this
case occurs.

NB: sometimes, the charset is omitted for a Content-type: text/xml. This
is valid but not recommended (see:
https://www.ietf.org/rfc/rfc2376.txt). In this case, the default used is
"US-ASCII". This means that any non-ascii char will be lost (they are
replaced by the replacement character: �, see:
https://github.com/python/cpython/blob/3.10/Lib/email/contentmanager.py#L67

)
when decoding the attachment.

2. When the xml attachment is created in Odoo, the mimetype is
'text/plain' (rather than 'application/xml'). Thus, the
`_decode_attachment` needs to be more flexible when guessing the type of
the attachment (to know which function to use to read the content of the
attachment and create the invoice).

3. When creating an invoice from an email with an xml attachment, the
xml is attached as the `message_main_attachment_id`. It's only later on
that the content of the xml is read and we possibly find the PDF in
base64 inside. When creating the PDF attachment, it was not set as the
`message_main_attachment_id`, so the PDF was not rendered on the right
part of the invoice form view. Add a clause to replace the
`message_main_attachment_id` in such a case.

4. When the xml attachment represents a credit note, the move_type of
the invoice created by the email alias needs to be changed. Indeed, the
invoice is created before decoding the attachment, so we can only change
the `move_type` later.

opw-3144519
opw-3149649

closes odoo/odoo#120873

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

Steps to reproduce the bug:
- Connect with the company A
- Create a consumable product “P1”
- Create a receipt transfer with this product
- confirm the transfer
- Come back to the product form
- limiter le produit que a la “Company B”

Problem:
no user error triggered
Go to inventory > operation > transfer: a Traceback is triggered

Before this commit, there is no verification while changing a product's
company for consumable. That can lead to an issue where some operations
cannot be done because of access errors. To avoid that, this commit
prevents to change the product's company if some move lines for this
product exist in another company.

opw-3300559

closes odoo/odoo#120947

X-original-commit: a6666de7
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

__Current behavior before PR:__
When someone joins a call in the discuss public view and receives a message in the chatter, the part of the screen supposed to display the video streams of the participants goes black.

This happens because it is trying to open a chat window in the bottom right as it is done usually. However since we are in the public view it removes it instantly together with the participants cards.

__Description of the fix:__
If we are in the discuss public view, it is useless to make chat windows. This will prevent opening of chat windows.

__Steps to reproduce the issue:__
1. Open the discuss app and start a meeting.
2. Copy the Invitation Link
3. Open a new private window to join the call with a guest user.
4. Then go back to the non-guest user page and send a message in the chatter.
5. Notice that the participants cards vanished on the private window page.

opw-3229747

closes odoo/odoo#119359

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Previously, when conducting a refund on a table, the system would
switch the active table to the table associated with the refunded
order. This was not the desired behavior, as it resulted in the details
of the order disappearing, requiring the user to navigate back to
the refund process.

Steps to reproduce the issue:

 - install PoS restaurant
 - pick a table, do an order and pay it
 - pick another table, refund
 - choose the previous order and refund
-> the order details disappear directly. You have to go back to refund.

opw-3301603

closes odoo/odoo#121012

Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>

When l10n_mx_edi is installed and a payment is posted, the move_name field on account.move.line
being a related to move_id.name is not well computed.
That is because posting a move trigger the computed field in a protected mode due to `flush_recorset`.
This mode prevents any computed field to be recomputed twice.
This flush triggers `_compute_name` calling `sequence_mixin`, itself doing another `flush_recorset`.
This extra flush triggers `_compute_l10n_mx_edi_cfdi_uuid` that access to `move.payment_id.reconciled_bill_ids`.
This access to this field triggers its recomputation and then, `_compute_stat_buttons_from_reconciliation` is called.
This method does `self.env['account.move.line'].flush_model()` that force the computation of `move_name` to `/`.
`sequence_mixin` assigns the new `name` to the journal entry but `move_name` is not recomputed due to the
protected environment.

closes odoo/odoo#120630

X-original-commit: 29d6101c
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>

Before this commit
==================
when SO is confirmed and Delivery is created then add the shipping method
in SO, in this case, the shipping carrier is not set in the existing undelivered
delivery of that SO.

After this commit
=================
So in this commit, we set the shipping carrier for undelivered delivery.

taskId - 2946360

closes odoo/odoo#120966

X-original-commit: 58f9139f
Signed-off-by: Tiffany Chang <tic@odoo.com>

Issue 1: before this patch it was impossible to create a manual model
marked as "Is blacklist". The reason is that a blacklist model
implicitly need an `email` field, but such field is impossible to add in
a manual model: the field must start with `x_`.

Solution: append `x_` to the implicit email field. Note, in principle
the user gets an error if `x_email` is not present. Solved by adding the
field when creating the custom model. Ideally we should show some hint
in the interface to make it more user friendly. That is out of the scope
of this patch.

Issue 2: when we have a manual model that is mail blacklist it's
impossible to create its model class. We get an error because the MRO is
not correct. The reason is that we are adding `mail.thread.blacklist`
_after_ `mail.thread` in the `_inherit` list. That list is used to
generated the `__bases__` of the model class[1]. According to Python's
MRO rules[2], since `mail.thread.blacklist` appears after `mail.thread`
as parents of the custom model class this order _must_ be respected. But
`mail.thread` must appear _before_ `mail.thread.blacklist` because the
latter inherits from the former. This is a contradiction and the MRO
algorithm cannot succeed. To put it in a simple example:
```py
class A: pass
class B(A): pass
 # This fails:
 # class C(A, B): pass
 # The right order is:
class C(B, A): pass
 # Equivalent to:
class D(B): pass
 # C and D have the same MRO linearization excluding themselves
assert D.mro()[1:] == C.mro()[1:]
```
Example traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 464, in load_modules
    registry.setup_models(cr)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 263, in setup_models
    env['ir.model']._add_manual_models()
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/ir_model.py", line 430, in _add_manual_models
    Model = model_class._build_model(self.pool, cr)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 585, in _build_model
    ModelClass.__bases__ = tuple(bases)
TypeError: Cannot create a consistent method resolution
order (MRO) for bases BaseModel, mail.thread, mail.thread.blacklist, base
```

Solution: check if a model inherits from `mail.thread.blacklist` first.
There is no need to add `mail.thread` if inheriting
`mail.thread.blacklist` because the inheritance is already implicit.

This issue was observed during upgrades. We convert custom models and
fields into manual to allow upgrading without custom code. This causes
issues because the MRO error appears when a custom model inherits mail
blacklist.

[1]: https://github.com/odoo/odoo/blob/02f820fb0eaddbb3a4269a0967184c8aaf52c363/odoo/models.py#L585
[2]: https://www.python.org/download/releases/2.3/mro/



closes odoo/odoo#120922

X-original-commit: 8848bb57
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@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#119238

X-original-commit: 1a264d7d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Before this commit: if you add a custom one2many field to the
'res.partner', like x_related_commercial_partner_ids, that is related to the
`commercial_partner_id` in the`res.partner` model, it won't update the
display name of a contact in case of changing its parent_id name.

Here are the steps to reproduce the problem:
 1. Create a new custom field with these values:
   a. Field Type = one2many
   b. Model = Contact
   c. Related Model = res.partner
   d. Relation Field = commercial_partner_id
 2. Create a new Contact that is the "Company" (e.g. "My Company")
 3. Create a new Contact that is the "Individual" (e.g. "My Name"), and
    put the "My Company" as its parent_id.
 4. Now the display_name is "My Company, My Name" which is correct
 5. Change the company name to "My new Company"
  -> display_name won't change, and is "My Company, My Name"

The solution is to add the 'commercial_company_name' to the
`display_name` depends.

opw-3202894

closes odoo/odoo#120669

X-original-commit: 6bd2bdf0
Signed-off-by: Rémy Voet <ryv@odoo.com>

Since [1] when the fuzzy search was introduced on website pages, the
filtering on most specific pages only happens at the end of the search
operation. Because of this, the search happens on pages that would be
excluded anyway, the limit might be wrongly applied and the count might
be wrong.

This commit makes the page search begin by keeping only the most
specific pages, then performing the actual search within those pages.

Steps to reproduce:
- Install `website` only and drop a search snippet.
- Search "ax".

=> No results found, but the "All results" link is displayed.

[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986



task-3203794

closes odoo/odoo#117627

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

task - 3293181

closes odoo/odoo#120811

X-original-commit: 4424e901
Signed-off-by: Kevin Baptiste <kba@odoo.com>

closes odoo/odoo#120763

X-original-commit: 94247ed0
Signed-off-by: William André (wan) <wan@odoo.com>

As of this commit, only confirmed leaves will be considered when computing the
current leave or absence of an employee. Additionally, a bug in the is_absent
search implementation was fixed: before this commit, the same results were
returned for absent and non-absent searches.

opw-2877328

closes odoo/odoo#118475

X-original-commit: 37f2fc5c
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: De Caluwé Tom (tdc) <tdc@odoo.com>

If applied, this commit will handle the KeyError: res_id when the user tries to
import the translation of .csv file in settings -> translations, and if .csv
file doesn't have the res_id column.

I handled the traceback by changing the logger level to warning.

sentry - 4049419481

closes odoo/odoo#120757

X-original-commit: dd0ec40c
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>

Handled error for if e-waybill is already generated and we send request for
e-way bill generation it will give error -
[4026] Duplicate e-waybill for the given document.

Fix - It will fetch the ewaybill details and shows the ewaybill has been already
      generated

task-3262244

closes odoo/odoo#117609

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

When using a different invoicing address for a partner on a sale order,
an error is thrown up. This is caused by checking the wrong partner in
the access token.

opw-3298228

closes odoo/odoo#120751

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

Steps to reproduce:

Step 1: Create new MO
Step 2: In page by-products click three dots to show column cost_share
in tree by-products
Step 3: Create new Byproduct and input cost share >100% or <0% or input
two byproducts
        where their cost share adds up to more than 100%

Expected result:
Validation error: total byproduct cost_share cannot exceed 100
or Validation error: cost_share values must be positive

Actual result:
Values saves without issue

Issue is due to `move_byproduct_ids` being removed in the mrp_production
overrides of
`write()` or `create()` and having the `_compute_move_byproduct_ids`
populate its values.
This removal is causing the constrains to not be enforced, therefore we
set the constrains
field to `move_finished_ids` since changing of this value will ensure
that the values are
correctly checked.
Note: There will be a decrease in performance since this means the
constrains will be
called whenever the MO's product to produce is changed, but hopefully it
will be
minimal since there is no simple fix for this issue.

closes odoo/odoo#119009

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

closes odoo/odoo#95123

Signed-off-by: Rémy Voet <ryv@odoo.com>