closes odoo/odoo#64656

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

If we're to change the invoice policy of a product we'd provoke a
chained computation of every sale line and sale order containing such
product. This change goes along with the policy of applying such changes
only to future orders, as stated here: https://github.com/odoo/odoo/pull/61135



closes odoo/odoo#64506

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

This reverts commit c071f0255fba3b8340182607fe4ef70321691341
(See PR https://github.com/odoo/odoo/pull/64201)

Reason: the fix is incorrect, it creates another issue:
https://github.com/odoo/odoo/issues/64548



closes odoo/odoo#64597

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

Before this commit, if the user had a fiscal position for his current country,
it wouldn't be used to compute the price of the products on the eshop.
Note that:
  - the price would be correct on the cart, as those prices are coming from a
    sale order which correctly retrieves the fiscal position.
  - if the fiscal position is directly set on the partner, prices are correct
    on the eshop

Step to reproduce:
  - Set Belgium as country on Portal user's partner
  - Create a 0% tax and a 15% tax
  - Create a fiscal position mapping 15% tax to 0% tax for Belgium country
    automatically detected
  - Create a product with 1000$ price and 15% tax set on it
  - Enable pricelist and select tax included in settings
  - Create a pricelist for Belgium and add a rule for the product you created
    to set a fixed price of 500$
  - Now visit eshop with Portal user

The test product show 575$ instead of 500$ in eshop, while it will correctly
show 500$ in cart.

opw-2423215

closes odoo/odoo#64477

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

If an email was sent with empty "To:" and a proper alias in "CC:" (or any of the similar valid headers that conform the `rpc_tos_localparts` array), before 40ae36b7 the email wouldn't get rejected. After that commit it would get bounced.

This comes from the not-so-obvious new python idiom used, `all()`. Check this out:

```python
>>> all([False])
False
>>> all([])
True
```

So, apart from the fix introduced in that commit, which seems valid, we have to make sure `email_to_localparts` actually has contents. Otherwise we are producing false bounces here.

@Tecnativa TT23437

closes odoo/odoo#49656

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

Before this commit:

-when moving a snippet using the drag and drop button, two drop zones
instead of one was added at the initial location of the dragged
snippet.

-when moving a snippet using the drag and drop button, no drop zone
was added at the initial location of the dragged snippet if the snippet
was alone in its parent. For example, the left jumbotron in the banner
snippet.

-the drop zones handled by the "children rules" were never vertical
when it was necessary.

This commit also refactors the code to avoid some duplicated lines.

task-2312878

closes odoo/odoo#61336

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

This is mandatory for PA customers, and required by several enterprise customers as well.

Related Ticket: 2425845

closes odoo/odoo#64056

Signed-off-by: Josse Colpaert <jco@openerp.com>

If we change ``active_model`` in context, we have to reset active_id(s),
otherwise we read a random records which may not exist.

STEPS:
1. Activate Developer mode
2. Go to Settings > Technical > Automation > Automated Actions
3. Define a new Automated Action with the following settings:
- Model: Lead/Opportunity
- Action To Do: Execute Python Code
- Trigger: Based on Form Modification
- Trigger Fields: Customer (crm.lead)
- Python Code:
```
raise Warning(records)
```
4. Go to Contacts, create a new contact and save it.
5. Click on the "Opportunities" Smart Button on the top left of the contact record.
6. Click "Create".

BEFORE: ``records`` in context read crm.lead, while id is for res.partner
record

AFTER: ``records`` is None

---

opw-2424392

closes odoo/odoo#64223

Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

This fix partly reverts the commit db691dbe
The latter is fully reverted in v13: 6a5271b7

When having an invoice with total equals to 0, it still adds a line to
the follow-up report.

To reproduce the error:
1. Go to Accounting > Customers > Invoices
2. Create an invoice without Payment Terms and product at 0$ to have a total of 0$
3. Go to Accounting > Customers > Follow-up Reports > [Select the partner]
4. The invoice is present with a total due of 0$

Err: the invoice shouldn't be in the follow-up report.

OPW-2419268

closes odoo/odoo#64214

Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Issues
- In a database with a lot of locations (more than 10K)
- Search by location in the product tree view with the complete name of
the most "parent" location
- We get a memorry error due to a giant SQL request:
`psycopg2.ProgrammingError: memory exausted at near "(" ...`
It is due to the `_get_domain_locations_new` which return a giant domain
with a tons of `(location_id.parent_path', '=like', ...)` for location.
Because the `_get_domain_locations` makes a ilike on the complete name,
it will match parent but also all child of this parent (because of the
complete works expected if there are loc of type 'view' between).
If there are 10K child location of `WH/Stock`, it will
match all child and the `_get_domain_locations_new` will return
a extremely huge domain with a lot of useless condition.

To Solve
Minimize the domain created by the
`_get_domain_locations_new`, avoid duplicate `parent_path` condition:
e.g. `'|', ('location_id.parent_path', '=like', 'WH/Stock/%')
('location_id.parent_path', '=like', 'WH/Stock/Shell/%')`
can be represented only by the first condition.
We can also search all childs and add condition on ids before
but it removes the optimization done in this method.

opw-2379464

closes odoo/odoo#64133

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

backport of 58456523

closes odoo/odoo#64308

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Issue

	- Init an instances of Odoo v12.0 'A' (or saas-12.3 or 13.0) and v14.0 'B'.
	- Install "Accounting" app on instance A & B.
	- Set your email server on instance A & B.
	- Activate 'External email server' in settings of instance A.
	- Set an email alias for "Vendor Bills" on instance A.
	- Send a "Customer Invoice" from instance B to alias of instance A.
	- Fetch for new mail (in case new vendor bill don't appear) on instance A.
	- Open the new Vendor bill on instance A.

	Data are not parsed from pdf attachment.

Cause

	Filename formating has changed in v14.0 :
	- X < v14.0 : 'factur-x.xml'
	- X >= v14.0 : 'INV_2020_12_0001_facturx.xml'

Solution

	Don't check filename anymore since can be changed or can come
	from other services than Odoo.
	Instead, ensure there is a specific tag in the xml tree.

opw-2411002

closes odoo/odoo#64155

Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

Issue

	- add a new language with locale code KUR (for Kurdish)
	- print any report with a datetime on it (RFQ for example)

Cause

	Babel (version < 2.7.0) does not handle locale "KUR".

Solution

	If wrong locale or not managed by Babel, try to fallback
	on server default locale.
	If still wrong locale or not managed, then fallback on "en_US" as locale.

opw-2416482

closes odoo/odoo#64169

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

Steps:
- Install Invoicing and load French
- Go to Invoicing
- Click an invoice due in the future
- Click Preview
- Switch the preview to French by modifying the URL like this: example.com/my/invoices/6 -> example.com/fr_FR/my/invoices/6

Bug:
"Due in %d days" is still displayed in English. The rest of the page is in French.

Explanation:
This is due to two things:
1. `mail` and `portal` are both installed and we cannot have more than one `code` translation of a source [1]. Since `mail` is loaded before, alphabetically, `portal` doesn't add the duplicated translations with its own module name. When loading a web page, only the modules returned by `_get_translation_frontend_modules_domain()` are sent to the frontend. `mail` is not one of them and the duplicated translations are not sent. Since sending all the `mail` translations is overkill, this commit is modifying the format string. This won't change the text outcome, but will make the new sources unique and make the backend send these translations to the frontend.
2. Translations in `portal_sidebar.js` are queried before the translation DB [2] is made. This results in an empty array and `_t()` returns the source. `session.is_bound` will wait until the app is fully loaded before querying.

[1] https://github.com/odoo/odoo/blob/ad2d96db8ad3e1fd7af2edda218fc34c0c1d259a/odoo/addons/base/models/ir_translation.py#L290
[2] https://github.com/odoo/odoo/blob/0de069b8ca9fb005ba5b076984f5677de25889ee/addons/web/static/src/js/core/translation.js#L51



opw:2421501

closes odoo/odoo#64160

Signed-off-by: backspac <backspac@users.noreply.github.com>

The picking_type, sequence and currency were taken from the user company, even if the
purchase order is created in another company.

Fixes #35026

closes odoo/odoo#42980

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

In a multi-company configuration, when checking the documents that have
one activity (e.g., a TODO activity), it shows all companies' documents

To reproduce the error:
(Install Documents. Let C1 be the current company)
1. Create a second company C2
2. Go to Documents > Configuration > Folders
3. Create a folder F
	- Company must be C1
4. Go to folder F and upload a document D
5. Schedule an activity on D:
	- a To Do activity, with Due Date set to today
6. Switch to company C2
7. On top bar, check your activities
8. Click on "1 Today"

Err: The system displays all documents that have an activity scheduled for
today. In our case, you see document D. Since you switched to company
C2, you should not see this document. This error can even lead to a more
problematic situation: in step 4, create a "Request Document" instead of
uploading a file. In step 8, an AccessError will be raised and you will
no longer be able to consult the documents that have a scheduled activity.

When clicking on "1 Today", the server searches for documents that have
an activity scheduled for today. However, this search does not contain
any filters on companies. In most cases, the search domain will be
improved on server-side, thanks to the access rules. But in some cases
(e.g., using the Documents module), there isn't any rule about companies.

This fix only concerns version 12 (from version 13 onwards, the user can
see several companies' data at the same time).

OPW-2416152

closes odoo/odoo#64201

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

Some modules may be removed by the upgrade scripts with the help of the
ORM and are done in `end` scripts.
This is the case for uninstalling the themes which use the `_theme_remove`
method [1].

[1] in 12.0: https://github.com/odoo/odoo/blob/e2084a4356f63249920d8c777e92f1710be8b5a6/addons/website_theme_install/models/ir_module_module.py#L337



closes odoo/odoo#64199

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

This reverts commit 82f236d9.

The fix is actually not solving all the issues, and also introduce
a behavior change. Actually, the expected result for filters like

<filter string="My Pipeline" name="my" domain="[('user_id', '=', uid)]"/>

will result into a evaluated filters, but invalid as the uid is set to
the person configuring the google configuration, not the user who will
use it.

As it is tricky (or even impossible) to solve the issue properly in all
the cases, we prefer to warn the user that the filter is invalid instead.

closes odoo/odoo#64079

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

- At invoice creation, the stored fields that depends on `invoice_lines`
    are computed to be stored.
    This can slow down the invoice creation for a database with a lot of
    records on `account_move`.

    This commit speed-up the invoice creation by using SQL Joins to
    speed-up the searches.
    We cannot use `auto_join` on the `invoice_lines` field since it is
    not supported on many2many, thus we do it in SQL.

opw-2390604
backport of 67988972989e74443b6deb4d9a8e0c08a196ad4d

closes odoo/odoo#63588

Signed-off-by: Adrien Horgnies <AdrienHorgnies@users.noreply.github.com>

some fields may depend on invoice_ids, which lead to a perf issue when
field is not searchable.

opw-2390604
BACKPORT of afb927076ea22f80c62fe4ea4165e18c7f946fe1

In `run_scheduler`, we are running certain functions as super user to
avoid inter company and access rights issues.  This commit adds a
`sudo()` call to the `action_assign()` call, in case some objects
related to the retrieved moves are not accessible.

In addition a commit call is moved up to apply after the
`procure_orderpoint_confirm` call (as it was, it was applied after the
`_action_assign` loop, but there is in fact already a commit in that
loop, this lead to a somewhat random behavior where the replenish rules
were sometimes rolled back and sometimes not, depending on whether the
first iteration of the loop errored out or not)

opw-2394706

closes odoo/odoo#63935

Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>

What are the steps to reproduce your issue ?

    1. Install eSign
    2. Upload attached PDF (links below) as template

What is currently happening ?

    The font is broken

What are you expecting to happen ?

    Display PDF correctly

Patch: mozilla/pdf.js@977397e
See: https://github.com/mozilla/pdf.js/pull/6270/files

Corrupted pdf:

https://github.com/mozilla/pdf.js/blob/977397ebfd1757706906694d49c3db9d3266583e/test/pdfs/issue215.pdf
https://github.com/mozilla/pdf.js/blob/977397ebfd1757706906694d49c3db9d3266583e/test/pdfs/bug1186827.pdf



opw-2410011

closes odoo/odoo#63943

Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>

Themes define records which are used as templates for the creation of
base model records on theme installation on a website.
E.g. a "theme.ir.attachment" record's purpose is to be a template for an
"ir.attachment" record creation on theme installation on a website.

Those final records have extra fields to indicate from which theme
template they come from. If those records are ever to be duplicated,
they should not duplicate those links to the theme templates otherwise
it may cause issues when uninstalling/updating a theme (you want the
records linked to the theme to be deleted/updated but not the duplicated
ones, which do not act differently from user created ones).

Duplicate ones will be linked to the website anyway (just like "normal"
user created ones) and should only be automatically removed if that
website is deleted.

The issue is more visible from 14.0 where applying some modifications to
images via the editor (crop / filter / optimization / ...) will
duplicate the original image before modifying it.

closes odoo/odoo#63940

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>

those field sizes were deleted from orm definition in 2014 https://github.com/odoo/odoo/commit/026e38b48f3963aed08bba4e76a0a796d662f6a4



STEPS:
* set manifest's summary attribute to a long string
* create empty database

BEFORE: error

```
2020-12-28 10:44:51,325 1 ERROR ? odoo.sql_db: bad query: UPDATE ir_module_module SET state='installed' WHERE state IN ('to remove', 'to upgrade')
ERROR: relation "ir_module_module" does not exist
LINE 1: UPDATE ir_module_module SET state='installed' WHERE state IN...
               ^

2020-12-28 10:44:51,325 1 ERROR ? odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
  File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 86, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 338, in load_modules
    odoo.modules.db.initialize(cr)
  File "/opt/odoo/custom/src/odoo/odoo/modules/db.py", line 63, in initialize
    info['sequence'], info['summary']))
  File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 173, in wrapper
    return f(self, *args, **kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 250, in execute
    res = self._obj.execute(query, params)
psycopg2.DataError: value too long for type character varying(256)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/odoo/custom/src/odoo/odoo/modules/registry.py", line 88, in new
    odoo.modules.reset_modules_state(db_name)
  File "/opt/odoo/custom/src/odoo/odoo/modules/loading.py", line 558, in reset_modules_state
    "UPDATE ir_module_module SET state='installed' WHERE state IN ('to remove', 'to upgrade')"
  File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 173, in wrapper
    return f(self, *args, **kwargs)
  File "/opt/odoo/custom/src/odoo/odoo/sql_db.py", line 250, in execute
    res = self._obj.execute(query, params)
psycopg2.ProgrammingError: relation "ir_module_module" does not exist
LINE 1: UPDATE ir_module_module SET state='installed' WHERE state IN...
```

AFTER: database successfully created

---

opw-2415057

closes odoo/odoo#63820

Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

`product_tmpl_id` of BoM line should be readonly,
there is no sense to change the product template from
the BoM line model. Also it avoids useless write on product
and inverse recomputation.

opw-2420830

closes odoo/odoo#63865

Issue: odoo/odoo#63631
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

Steps:
- Install "Belgium - Accounting" and "Accounting"
- Add the Dutch language in settings
- Select a Belgian company
- Go to Accounting > Configuration > Chart of Account
- Select an account like "755000 Financial income - Foreign currency translation differences"
- Change the translation of the account name in English and Dutch
- Create a new company in Settings > Companies
- Select this new company
- Go to Accounting > Configuration > Settings, set the Fiscal Localization to Belgian PCMN and save
- Return in the first company
- Go to Accounting > Configuration > Chart of Account and check the translations you previously set

Bug:
The Dutch translation has been reset and the English one remains the same.

Explanation:
`process_coa_translations()` uses `spoken_languages` as seen here:
https://github.com/odoo/odoo/blob/bb31ce3bc6c0c7e1e101d93924eccea995206733/addons/l10n_multilang/models/l10n_multilang.py#L67
The spoken languages are defined here: https://github.com/odoo/odoo/blob/f4e7e06a1ff9756471d55138575c758f456b5905/addons/l10n_be/data/account_chart_template_data.xml#L10
This is why English is not affected.

The bug appeared with https://github.com/odoo/odoo/commit/c346e7af3314ce504fe3add9e9f6a4839bcad64a
It was meant to apply Chart of Account translations on the current company but applied it on all the companies. This reset edited translations on the other companies.

This commit refactors `process_coa_translations()` so that we can use the same logic on a single company while keeping the definition of the original function intact.

Backport of #63575
Current company copied from the `super` method: https://github.com/odoo/odoo/blob/d9097c2b6244154ea64142b5e8fd31cfdd34e66e/addons/account/models/chart_template.py#L189-L196



opw:2376334

closes odoo/odoo#63839

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

What are the steps to reproduce your issue ?

    1. Install website_blog
    2. Go to website and add a new blog post
    3. Remove the block content
    4. Save and go to Blog page

What is currently happening ?

    Crash:
    Template fallback
    An error occured while rendering the template website_blog.post_teaser

opw-241937

closes odoo/odoo#63786

Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>

The doc for client actions is currently too minimalistic to be of much
use. This commit adds a seealso linking to the related tutorial.

task-2423824

closes odoo/odoo#63818

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

STEPS:

1. Activate multi-currency in Settings

2. Set a currency in POS that differs from company's currency. To do it change
following values in pos.config to ones with another currency

  * Journal
  * Default and Available Pricelist
  * Payment methods

3. Reproduce imbalancing

3.1. Create a new tax (not yet linked to any journal line).
3.2. Assign the tax to a product.
3.3. Sell the product thru pos.
3.4. Go back to backend and delete the tax.
3.5. Close the session.

BEFORE: error "You cannot create journal items with a secondary currency without
filling both 'currency' and 'amount currency' fields"

https://github.com/odoo/odoo/blob/cb951baa8e289ba0bcb4269e3c52d0dcd721c0d0/addons/account/models/account_move.py#L764-L768



AFTER: no error, currency is specified

---

opw-2412764

closes odoo/odoo#63732

Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

pos.session doesn't have field company_id in v12. But there is one in v13:

https://github.com/odoo/odoo/blob/aa00d8d010f14e9f801bdd9e957280eaba18ff22/addons/point_of_sale/models/pos_session.py#L26

Related PR: #61837

Apply fix from pdfjs project, because we cannot upgrade the lib in stable branch

STEPS:
* install documents app
* upload this pdf:
https://github.com/mozilla/pdf.js/blob/edf8ccc1d8b2202aef5832a85a7352ee07c69ad9/test/pdfs/issue5946.pdf


* click on pdf icon to preview

BEFORE: text is disappeared

AFTER: text is rendered correctly

---

opw-2392099

closes odoo/odoo#63774

Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

This fix corrects the anglosaxon lines generated by PoS.

\## The issue:
The anglosaxon line calculation assumes that all the account move lines
are grouped by product for the entire PoS session.
(and thus not split by pos_order)

As a result, when the variable "have_to_group_by" is False, the anglosaxon
lines are generated only once by product and only for ONE pos_order instead
of the whole session.

\## The fix:
The fix solves this issue by using a loop and generating all the anglosaxon
lines for each product in each order. The lines are then regrouped later on
if required.

\# Ticket \\#2333580

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#63624

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

When attempting to resize or crop an attachment through the '/web/image'
route, if the attachment isn't actually an image (even if the record's
mimetype says so) or doesn't match one of the format supported by PIL
(Python Imaging Library) - like Apple's HEIF -  the request crashes with
a "500 Internal Error".

Although it makes sense to return a response with an HTTP error code, a
more sensible approach would be to return a "404 Not Found" response
instead.

The point by handling the Exception thrown by PIL and returning a 404
status code is to more closely match the semantic of this HTTP status
code. Getting a resized version of a non-image doesn't really make sense
as this resource doesn't exist at all ; hence the "404 Not Found"
response. On the other hand returning a "500 Internal Error" would
denote that a legitimate request failed on the server side, which is not
the case here.

Note: this difference of semantic, even if only visible in a regular
browser, has its importance in the mobile apps because we use it to
given a meaningful feedback to the user in case if failed HTTP requests.

Note: the mimetype detection could be improved to ease the handling of
this kind of errors but would require too much changes to be done in
stable branch.

Steps to reproduce in Documents:
- rename an HEIF file with a ".jpeg" extension
- upload it in documents
- select the document in kanban view
=> the thumbnail in the document inspector (right panel) throws an HTTP
error 500

Steps to reproduce in Discuss:
- rename an HEIF file with a ".jpeg" extension
- upload it in a chat window
=> the thumbnail in the chat window throws an HTTP error 500

opw-2417172

closes odoo/odoo#63739

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

When inviting people to a group-based channel an error may be raised if
invite target users not having the right group. Indeed they do not have
access to the channel as read access it not given if not belonging to
the channel group.

We add an UserError so that wrong invites are now pompted to the user
instead of crashing.

Task ID-2411038

closes odoo/odoo#63676

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

1. Create a shipping address
2. Place a SO through backend, and choose that specific delivery
address.
3. Archive that address
4. Place an Order through the website

It is defaulting to the previously archived address, and not to the active one.

opw-2411438

closes odoo/odoo#63576

Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>