Unnecessary call to _create_check_sequence because is called in create method and create is called in supper().copy()
TT35608

closes odoo/odoo#88159

X-original-commit: 2f83737b
Signed-off-by: Florian Gilbert <flg@odoo.com>

This fix prevents the `/Annot` key from a PDF PageObject
to cause errors during its handling by PyPDF2.

opw-2811793

closes odoo/odoo#88182

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

Manual forward port, commit was lost from 15.2 to master. Either it
seemed not needed after the httpocalypse refactoring, or was simply
lost during the rebase.

-----

We can remove an useless SQL Query for public user on every single page
serve, if we directly set the website's company_id in the available
company_ids of the public user.

Indeed, the public user from a website always have the same company_id
as the website.

We can then do that directly and bypass the next line which will
always be true in the case of the public user, making a read for
nothing.

task-2774979

closes #85419

X-original-commit: c95ab6f2

[1]: https://github.com/odoo/odoo/commit/728ade674cb12c64718efda56b0d5d542e319cba



closes odoo/odoo#87856

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

*: test_website, website_blog (test perfs)

An error regarding tests was not catch during httpocalypse [1] review.
The test query counts were lowered in website by 2 everywhere, but it
shouldn't have as there were no SQL perf improvement from this
refactoring regarding website.
The query count actually decreased because the test-only SQL Savepoints
got divided by 2, probably thanks to a low level test improvement in
the PR.
But outside of tests, there were no SQL Query gained.
This should have been reflected in the `EXTRA_REQUEST` variable
instead.

Before:
Savepoint > Rollback > Savepoint > [Actual SQL Queries] > Rollback
After:
Savepoint > [Actual SQL Queries] > Rollback

It is important to fix it because:
1. (Minor) There is a de-sync between the query count in the test and
   the actual query count (in the logs outside of tests), making it
   hard to figure.
2. (Major) Some controller got then wrongly lowered to 0 query counts
   instead of 2. An incoming PR in master would then make those tests
   expects negative query counts, which doesn't make any sense.

[1]: https://github.com/odoo/odoo/pull/78857
Note that the exact commit can't be found by bisect as those don't work
on their own, DB can't be started due to circular import.

Part-of: odoo/odoo#87856

Step to reproduce:
	- install sale, accounting and l10n_de
	- activate proforma in sale settings
	- set the template to external_layout_din5008 in the settings (use developer mod)
	- create sales order or quotation
	- print it as a proforma

Current behavior:
	- the proforma is missing from the title in the document

Behaviour after PR:
	- the proforma is in the document title

The l10n_de_sale module was missing the case scenario of a proforma sales report and the sale module only
gives the information of a proforma report in the xml context. Then we add the case scenario and propagate
the proforma info from the sale module also in the python context using the proforma variable.

opw-2796603

closes odoo/odoo#88153

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

closes odoo/odoo#88139

X-original-commit: 1d46b388
Signed-off-by: Raphael Collet <rco@odoo.com>

Most of the extensions of `_name_get` are very similar and only want to
search for the given string in multiple fields.
A lot of extensions also don't take into account the negative operators.
Some implementations were also really outdated and needlessly
complicated.

closes odoo/odoo#86588

Related: odoo/enterprise#25608
Signed-off-by: Raphael Collet <rco@odoo.com>

Enable discounts
Have a price included tax 10%
Have a product with sales price 100$
Make a SO adding the product, the price incl. tax and a 1% discount
Open the portal page of the quotation

In the left recap sidebar the price before discount is reported to be
100.10 while it should be 100.0

opw-2759804

closes odoo/odoo#87418

X-original-commit: db6994c2
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Step to reproduce (Traceback):
- Be in multi-company
- Create a time off type with duration in hour and no company_id
- Create an instance of this type on company A with a user linked
 to company A (need access to both)
- Switch to company B

Current Behaviour:
- Traceback
- Cannot fetch user's calendar if content of company A is not checked
 for convertion from Days to Hour

Behaviour after PR:
- We only fetch if the user related to the leave is in allowed_companies
 -> only fetch if the user data is available
- This is also true if duration is in Days/Half-Days (GMF Approved)

opw-2749258

closes odoo/odoo#88104

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

This commit applies the correct primary colors to maintain consistency
with the overall design.

task-2817682

closes odoo/odoo#88088

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

Part of the overall v16 SCSS optimization/restyle, task-2704984

task-2817682

Part-of: odoo/odoo#88088

task-2792108

closes odoo/odoo#88083

Related: odoo/enterprise#25928
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

``get`` default is a dict that gets evaluated to be sent as parameter,
causing an unnecessary read on the component's computed fields.

The read should only happen only if we don't have a value in ``res``.

closes odoo/odoo#88050

X-original-commit: 4d16869e
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Before this commit:

For guests and portal users, a separator(differentiates channel name and
description) in the thread view topbar is displayed even if there is no description.
And when portal users are trying to write/edit channel description at that time
access error is generated.

After this commit:

A separator will only be displayed when there is a description and portal users
will not be able to write/edit channel description as they don't have rights.

Task-2664843

closes odoo/odoo#87999

X-original-commit: 84604910af931131fd10ad37787a803c8905d55c
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

* Previously, when reconciling  journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.

==== RATIONALE ====

This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:

Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)

..leads to a partial of 120 EUR and min(80, 60) = 60 USD

After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.

2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.

In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.

In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.

==== REFERENCES ====

Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.

github issue: https://github.com/odoo/odoo/issues/37469



closes odoo/odoo#84201

Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

New module to send invoice to Indian Government using IAP service

Task 2179664

closes odoo/odoo#79995

Related: odoo/enterprise#25899
Signed-off-by: Josse Colpaert <jco@odoo.com>

add get warehouse address method
needed in Indian EDI to pass value of dispatched address

improve demo data and bypass one GST number from validation because that GST number use to test EDI

Add Non GST Supplies and State CESS tax report line
Non-GST Supplies and State CESS is required to get related value from the invoice for send EDI

Part-of: odoo/odoo#79995

This follows up e045e76e.

Change the heuristics for ordering columns, as padding is not determined
by column size, but by column alignment inside a row.  Because in Odoo a
row always starts with a column of size 4, the following columns should
be the ones aligned on 4 bytes, then the ones aligned on 1 byte, then
the ones aligned on 8 bytes.

The analysis in the commit message of e045e76e was not correct, as it
did not take into account the fact that rows themselves are aligned on 8
bytes.  So we have: before each row used 40 bytes (+24b header)

       attname   |  typname  | typlen
    -------------+-----------+--------
     id          | int4      |      4
     create_uid  | int4      |      4
     create_date | timestamp |      8
     write_uid   | int4      |      4    -> 4 bytes padding
     write_date  | timestamp |      8
     active      | bool      |      1    -> 7 bytes padding

After each row uses 32 bytes (8 bytes saved per row):

       attname   |  typname  | typlen
    -------------+-----------+--------
     id          | int4      |      4
     create_uid  | int4      |      4
     write_uid   | int4      |      4
     active      | bool      |      1    -> 3 bytes padding
     create_date | timestamp |      8
     write_date  | timestamp |      8

Of course, when more columns are present, the space savings depend on
the alignment of the other columns.

closes odoo/odoo#88084

Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Since commit [1], we should use domain instead of _get_http_domain().
However _get_http_domain() checks if the domain exists which is not the
case in commit [2]. It only impacts databases having multiple websites.

[1]: https://github.com/odoo/odoo/commit/7d8a8ddea0b363732f2177ad589a3e0e10e2fb6c
[2]: https://github.com/odoo/odoo/commit/ee71cdff0786d5c41fbcc50894cd06811d3d8d5b



Steps to reproduce:
  1. Install the eCommerce app
  2. Add a second website
  3. Keep the domain field of the website empty
  4. Set the website field of a product to the website.
  4. Click 'Go to Website'

Current behavior before PR:
  - RPC_ERROR: Odoo Server Error

Desired behavior after PR is merged:
  - Redirected to the product's page

closes odoo/odoo#88067

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

This patch solves memory problem on exporting `account.move.line` records:
while export method invalidate cache for `account.move.line`, it keeps cache for
`account.move`, which may lead to memory error.

opw-2764457

closes odoo/odoo#88060

X-original-commit: 80c65498
Signed-off-by: Raphael Collet <rco@odoo.com>

closes odoo/odoo#88046

X-original-commit: 889e25147ce49ff9169c6a9ba85ebe151807db88
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Reproduce:
* Create default analytic rules
* Create a quotation/sale order.

Before:
Default analytic rules were not added on sales orders, like they are on
invoices and purchase orders.

After:
Same behavior on all documents.

This behavior was mistakenly removed during a refactoring:
https://github.com/odoo/odoo/commit/3c67bb20feb42f16799b7491411e213b818c4f83



opw-2800936

closes odoo/odoo#87980

X-original-commit: 0598eb70c13310d79202607e3bf46f82a85d6935
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>

This commit replaces raw SCSS with default Bootstrap classes, in
order to reduce code lines and to increase performance.

Task-2812497
Part of the overall v16 SCSS optimization/restyle, task-2704984

closes odoo/odoo#87796

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

Task-2579306

closes odoo/odoo#87776

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

Before this commit
On mobile, clicking on a powerbox item called the first command.

After this commit
On mobile, clicking on a powerbox item call the clicked item command.

task-2751059

closes odoo/odoo#88059

X-original-commit: 03638e4d46941bb4751ac2d6df8c08cb4cc2208e
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

task-2751059

X-original-commit: 86b22141b9653bfad8d135af7f66ff9bc36084ba
Part-of: odoo/odoo#88059

2nd parameter of `_mockWrite` must necessarily be an array.

closes odoo/odoo#88057

X-original-commit: a0b4f77f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

`this.root.el` can become undefined, so it should always be guarded.

closes odoo/odoo#88053

X-original-commit: 2e634bb431642fbe21b61d61354c85282c365d40
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

When using an internal transfer to move some products between two
warehouses, the forecasted inventory becomes incorrect

To reproduce the issue:
(Let WH01 be the existing warehouse)
1. In Settings, enable "Multi-Warehouses"
2. Create a second warehouse WH02
3. Create a storable product P
4. Update its quantity: 1 x P at WH01/Stock
5. Create a planned internal transfer (the warehouse does not matter):
    - Source: WH01/Stock
    - Destination: WH02/Stock
    - Operations:
        - 1 x P
6. Mark the transfer as Todo
7. Consult the Forecasted Inventory report:
    - Filters:
        - Forecasted Stock
        - Product: P
    - Group By:
        - Warehouse

Error: The line for WH02 is missing and the line for WH01 is incorrect
(qty is 1 for next days while it should be 0)

The report used (`report_stock_quantity`) does not handle this transfer.
Because both locations (source and destination) are defined, the SM is
not considered as an in-move or out-move:
https://github.com/odoo/odoo/blob/07f0ffad6ecc08f4165902db45ae96e4b41199e8/addons/stock/report/report_stock_quantity.py#L38-L43


Moreover, it would be hard to change the SQL view to generate two lines
(one 'in' and one 'out') from the same SM (the internal move).

The graph on the forecasted report of product P is also incorrect (it
uses `report_stock_quantity` to get the data, so if the user selects a
specific warehouse in the filters, the result will be incorrect)

So, the user should only avoid to transfer some products between two
warehouses if the internal transfer is a planned one.

OPW-2752017

closes odoo/odoo#87965

X-original-commit: 7f56063f6fe63a70d3e23b9c5fb486cc0958dd3e
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Steps to follow

  - Use a browser timezone of GMT +2
  - Create a pricelist ending in an hour with a matching product
  - Add the pricelist to advanced pricelists in the POS settings
  - Open a POS session
  - Add the aforementioned product
  - Apply the pricelist
  -> The custom price is not applied

Cause of the issue

  `date_start` and `date_end` are stored in utc
  They are then off by the amount of the offset in the browser timezone

opw-2794490

closes odoo/odoo#88056

X-original-commit: 2fcecef4
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

Fix errors when adding attachment to records with read only permission:

Current behavior:
1. Error adding attachment to records with read only permission.
2. The message is not as clear as version 13.0

closes odoo/odoo#88036

Expect: Only display the message "You are not allowed to upload an attachment here." if you do not have permission to upload files.
X-original-commit: 8385f192
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

If a warehouse is set to a route like default 3-steps, updating the MO's
quantity to produce won't update the outgoing picking from
post-production to stock.
Since the quantity is now changed in the following pickings, no need to
put a warning in those pickings for the quantity change as their moves
quantity were automatically updated.

Task-2797359

closes odoo/odoo#86572

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

During the merge process of a negative move, it can deplete the quantity
of several existing moves (with positive quantities).
This is change is to make sure that a picking that would be depleted
this way becomes then cancelled, since no moves within would still be
relevant, as all moves would be set to 0.

Task-2797359

Part-of: odoo/odoo#86572

When updating the quantity of a manufacturing order,if multiple steps
were related to to its components, the changes would not be propagated
to them as no procurements were made.

So if updating the quantity of a two-step MO, the quantities from its
components within the MO would be updated, but not the ones from the
related picking.

Task-2797359

Part-of: odoo/odoo#86572

no need to select * in a query that looks like
select ...
from A
where exists(select * from B where ...)

we can instead use
select ...
from A
where exists(select 1 from B where ...)

closes odoo/odoo#88013

Signed-off-by: Raphael Collet <rco@odoo.com>

When the user create a button in the website builder through the
powerbox command "/button":
- call the editor fix for the link
- select the link

task-2704540

closes odoo/odoo#88010

X-original-commit: 92fcd5e1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Postgres is aligning columns to 4 or 8 bytes, depending on their type.
So, consecutive fixed-length columns of differing size will be padded
with empty bytes due to the alignment requirements.

Before this patch, columns where created in their definition order. Now,
they are ordered based on their size, in order to minimize the padding.

As an example, before each row uses 36 bytes (+24b header):

       attname   |  typname  | typlen
    -------------+-----------+--------
     id          | int4      |      4
     create_uid  | int4      |      4
     create_date | timestamp |      8
     write_uid   | int4      |      4    -> 4 bytes padding
     write_date  | timestamp |      8
     active      | bool      |      1    -> 3 bytes padding

After each row uses 32 bytes (4 bytes saved per row):

       attname   |  typname  | typlen
    -------------+-----------+--------
     id          | int4      |      4
     create_uid  | int4      |      4
     write_uid   | int4      |      4
     active      | bool      |      1    -> 3 bytes padding
     create_date | timestamp |      8
     write_date  | timestamp |      8

This saving scheme applies to all rows in all tables. We save between 4
and 8 bytes per row just on the usual create_uid, create_date,
write_uid, write_date.

closes odoo/odoo#87896

Signed-off-by: Raphael Collet <rco@odoo.com>

Before this commit, since https://github.com/odoo/odoo/pull/83574

,
attempting to join a call through the channel guest page while being
logged as a portal user would give an acess error.

This commit fixes this issue

closes odoo/odoo#87995

X-original-commit: e6a637dc
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Before this commit
Calling a command of the powerbox created a step that delete the input
content of the powerbox. That input content came back upon undo.

After this commit
The input content that select a command from the powerbox should
never come back upon undo.

task-2806849

closes odoo/odoo#87994

X-original-commit: 2da3d928
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Task-2816679

closes odoo/odoo#87992

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