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>

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.

closes odoo/odoo#113001

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

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