Problem: The error "There is no chart of accounts installed for this company..." appears for POS shop configurations
if they don't have a chart template configured for the company. It doesn't take into account if the company has its
own set of accounts so it will always show the error unless the chart template is set.

Solution: Include an additional condition to check if the company has accounting entries which is used to check
if the company has used its own set of chart of accounts for accounting.

Purpose: The error will only appear if the company has no chart template set or no accounting entries.

opw-3291399

closes odoo/odoo#119901

Signed-off-by: Laurent Smet <las@odoo.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#120680

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

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

closes odoo/odoo#121136

X-original-commit: 2a981e6a
Signed-off-by: Christophe Simonis <chs@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#121207

X-original-commit: 4ab8b28b
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Co-authored-by: Alvaro Fuentes <afu@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#121184

Signed-off-by: John Laterre (jol) <jol@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#120756

Signed-off-by: abla001 <abla@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#115131

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

Purpose
=======

Avoid mismatch between contracts from different companies and clarify
error message.

closes odoo/odoo#75553

closes odoo/odoo#120650

Related: odoo/enterprise#19647
Related: odoo/upgrade#2777
Signed-off-by: Yannick Tivisse (yti) <yti@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#120043

Signed-off-by: Tiffany Chang <tic@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#116533

Signed-off-by: Tiffany Chang <tic@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#120702

Signed-off-by: Djamel Touati (otd) <otd@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#119169

Signed-off-by: Christophe Simonis <chs@odoo.com>

This issue is generated when the user uploads an image of more than
50.0 million pixels, so error would be generated. But, currently it raises a
`ValueError` which results in traceback. So, we replace it with
`UserError` so the user has an idea about Image size or pixel being excessive.

closes odoo/odoo#118281

Sentry: - 4075426049
Signed-off-by: Rémy Voet <ryv@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#119602

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

task - 3293181

closes odoo/odoo#120064

Signed-off-by: Kevin Baptiste <kba@odoo.com>

closes odoo/odoo#116578

Signed-off-by: William André (wan) <wan@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#119511

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

closes odoo/odoo#95123

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

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

Signed-off-by: Quentin Smetz (qsm) <qsm@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

Part-of: odoo/odoo#120336

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

Signed-off-by: Brice Bartoletti (bib) <bib@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#114344

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

Adapt the tests after commit
https://github.com/odoo/odoo/commit/47905d21ab65f985291d78cb7ecb78f2f7cdcf67


A down payment is no longer created when a prepaid amount is detected in
a UBL/CII attachment.

closes odoo/odoo#120653

Signed-off-by: Laurent Smet <las@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#120411

Signed-off-by: Olivier Colson (oco) <oco@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#120008

Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

closes odoo/odoo#119586

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

Introduced in 51fd5d3c

closes odoo/odoo#120536

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

Before this commit, it was possible for one to post
multiple reviews when all the already posted reviews
had the 'Employee Only' state. A traceback was also
thrown when trying to update an 'Employee Only'
comment. It was also possible to edit a log note.
This commit fixes all these issues.

Task-2810085

closes odoo/odoo#107956

Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

Override the button_draft method, in order to
reset the expense and expense_sheet state
when resetting a move to draft.

Steps:

- Create an expense
- Submit and approve the report
- Post journal entry and register payment
- Reset the JE to draft
-> The expense and expense sheet states
   remain the same as before resetting
   to draft. They should be respectively
   'approved' and 'post'

opw-3279364

closes odoo/odoo#120286

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

Portal shows all Sale Orders available for current user. For example, salesman
can see his sales. If such a user can download digital files via product form in
backend, it makes sense to let user download them via SO page on portal.
However, it wasn't the case because /my/download requires product be purchased
by current user [1]. Fix it by checking read access first.

STEPS

* in backend create SO with digital product (customer must be different from
current user)
* create invoice and register a payment
* navigate to portal  (without using customer's token),
* open SO, click download on digital product

[1]: https://github.com/odoo/odoo/blob/1a24477fab4dd323cf94c010321d8942fb2c1a01/addons/website_sale_digital/models/account_invoice.py#L14-L22



opw-3144600

closes odoo/odoo#112639

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

In the website menu editor and in the studio menu editor, the user can
drag & drop the elements that constitute the menu of his website/app.
Users can also put a menu into another menu to create a sub-menu. For
the website, we allow two levels of menu but not more. For studio we
allow 5 levels of menu. When the user starts to drag an item, dropzones
can be drawn on the prohibited level (3 in website, 6 in studio) while
he can't create this level of menu. This commit adds a css rule to hide
those forbidden dropzones.

task-3251032

closes odoo/odoo#117300

Signed-off-by: loco-odoo <loco@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#120048

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

"ValueError: External ID not found in the system: payment.payment_acquirer_
stripe" is generated because the user deleted the Stripe payment acquirer
record and its corresponding model tried to access the record of it.

Steps to produce the error:
1. Install e-commerce
2. Install install 'Stripe Payment Acquirer ' module
2. delete the Stripe payment from payment acquirer
3. Go to the e-commerce dashoboard
4. Click Set Payment
5. select Credit card (via Stripe)
6. enter any secret and Publishable key
7. click apply

This commit solves the above issue by preventing the deletion
of the payment acquirer if it has a external reference.

sentry-4041178833

closes odoo/odoo#119140

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

Purpose:
The purpose of this commit is to change the current behavior of days to close
graph generating from customizable desk demo data.

Specification:
For the opportunities, the day_close field is a compute field depending upon the
date_closed field. For the customizable desk demo data, the date_closed field
pre-existed, due to that customizable desk opportunity was not won or lost but
the graph report was generated.
so, this commit fixes the current behavior for customizable desk opportunity.

Task-3278039

closes odoo/odoo#119292

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

The pdf viewer sometimes displays the sidebar when we open the pdf

Solution:
Add `pagemode=none` to the url when opening a pdf in attachments

opw-3193516

closes odoo/odoo#120330

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

Wrong date, the tax change happens between 31.12.2023 and 01.01.2024.
Translation files were already correct.

closes odoo/odoo#120312

Related: https://github.com/odoo/odoo/pull/113001


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

The edi attachment (for every format in `account_edi_ubl_cii`) contains
a tag indicating whether the invoice is fully/partially paid.

Before this fix, when this tag was filled, a down payment section was
created on the invoice. For a fully paid invoice, the resulting amount
was then 0, so the invoice was marked as "Paid".

This was wrong. The correct amounts need to be kept on the invoices.
This fix no longer creates a down payment, instead a message is logged
in the chatter.

task-3264843
opw-3248200

closes odoo/odoo#118610

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

Before this commit:
Files that should be ignored in the manifest but aren't (js library for example)
it can happen that files have huge lines, the regex to substract the
comments will overuse memory.
For example, a file of 13M with a line of more that 8M characters, the
memory consumptions peak at 1.7G

The results might be different, but it's an acceptable compromise

closes odoo/odoo#120120

X-original-commit: 0e56e4a7
Signed-off-by: Thibault Francois <tfr@odoo.com>

closes odoo/odoo#120015

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