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>

	Currently `report.stock.quantity` has a field defined in it called `move_ids`:
	`move_ids = fields.One2many('stock.move',readonly=True)`

	This virtual field has no corresponding inverse field so when performing a search_read on the model, it fails
	in fields.py when trying to do:	`inverse_field = comodel._fields[inverse]`

	In addition, this field is apparently not used anywhere in the source code and not queried in the SQL View.

	This means the model can never be search_read by default.

	Since this field is never used, it isn't stored, and the model is `_auto = False`, removing it won't break any database.

closes odoo/odoo#120416

X-original-commit: e3b1a887
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrew Gavgavian (andg) <andg@odoo.com>

Duplicate the default Account Payable (211000)
Set the default Account Payable to Deprecated
Create a Vendor Bill with a line
Save

Error will raise
The account Account Payable (211000) is deprecated.

opw-3199157
opw-3229350

closes odoo/odoo#120710

X-original-commit: 4305ea5a
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

Reproduction:
1. Open LibreOffice Calc (linux), create an empty xls file
2. In LibreOffice, input random things as a 4 (rows) by 2 (columns)
table
3. Create a new note in Odoo, copy the table to it
4. Hold Shift and click the place right before the first cell (out of
the table but still in the editable area)
5. Delete the selected table, a trace back popped up

Fix: add an extra condition to make sure parentFragmentTr is not null
before unpacking it

Note: as you probably noticed, the cleared table does not retain the
original dimensions, e.g. it turns to a 2-row, 4-column table. This is a
deeper issue of how we restore the table, and another task will be
created for this. This PR is a first-aid patch to solve the error
message as it confuses the client a lot

opw-3255144

closes odoo/odoo#119674

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

In this commit the resupply subcontractor source location is changed from
virtual production to WH/stock

Task id: 3263796

closes odoo/odoo#118316

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

Previous commit 1b840d06 tried to fix
the issue action_generate_serial may try to generate a existing lot.
But it made the lot number completely product specific. This change is
too big for stable, we revert the change in this commit.

Also to fix the issue, when action_generate_serial tries to generate a
lot, we always try the result from ir.sequence frist, only when the lot
already exists, we then try create one based on the product's lastest
lot number.

Task-3187003

closes odoo/odoo#120581

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

closes odoo/odoo#120583

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

Previously, a user could link his own expenses to a expense sheet
of someone else.

This would not be allowed upon creation but was allowed when updating
the values of the expense.

This commit add a simple check at the beginning of the write()

closes odoo/odoo#120592

X-original-commit: 7bcd64c5
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

Steps:
- In eCommerce activate Filter by prices and Attributes & variants filters
- select one attribute with >1 item (e.g. aluminum legs)
- put a price limit.
- the attribute filter is removed.

The commit will prevent the removal of the 'variants attribute filter'
when an attempt is made to apply a price range.

task-3101343

closes odoo/odoo#111478

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>