The method get_resource_path is redundant with file_path but without
all the checks.
The method will be deprecated in master but make it use file_path in
stable.

closes odoo/odoo#136206

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

closes odoo/odoo#136246

Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

On Database having a postgresql server version superior or
equals than 14.0, a feature called memoization is caching
result of the lateral join made in this query.
This cache creates an issue that results that customers
have the same result for their bank journals.

By adding a LIMIT 1 at the end of the lateral join query,
the memoization is not enabled (according to query plan).
Another solution could be to change the condition of this
lateral join (currently ON True) for a condition on the
journal id but it was less efficient.

opw-3422495

closes odoo/odoo#136161

Signed-off-by: William André (wan) <wan@odoo.com>

Problem
---------
When you go in the settings -> layout (debug mode) -> select external
layout --> preview document a traceback appears due to infinite looping
in the view definitions.

Solution
---------
This field is highly technical and should not be fiddled with by users.
For such reason, we set it as `readonly`.

task-3479152

closes odoo/odoo#133790

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

This commit updates the web.pot file following changes in https://github.com/odoo/odoo/pull/135294

.

closes odoo/odoo#135523

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/229c5635 [REL] 16.0.19
https://github.com/odoo/o-spreadsheet/commit/c02066a3 [FIX] header_size: decouple added row from base row Task: 3510863
https://github.com/odoo/o-spreadsheet/commit/ee39dbb7 [REF] drag&drop: stop using CUT/PASTE commands Task: 3502194
https://github.com/odoo/o-spreadsheet/commit/d7806c0a [FIX] deepEquals: fix simple type comparison Task: 3479451
https://github.com/odoo/o-spreadsheet/commit/5a2ee636 [FIX] clipboard: copy/paste of CF in another sheet Task: 3479451
https://github.com/odoo/o-spreadsheet/commit/def91b6c

 [FIX] GridOverlay: Hovering over a figure should not open popovers Task: 3475001

closes odoo/odoo#136237

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

Before this commit:
In the survey, when you start a live session and click on the URL the `copied`
popover appears but doesn't go away.

After this commit:
Now that popover will close automatically.

Reason:
There was already a `tooltip` instance on the element and we try to add the
`popover` on that element which causes an issue.

Task- 3458901

closes odoo/odoo#132956

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

Current behavior:
When refunding an order, the lot_id of the original order was not set
on the refund order.

Steps to reproduce:
- Create a product with tracking by lot
- Open the POS and add the product to the order
- Set a lot on the product
- Pay the order
- Refund the order
- Check the lot on the refund order, there is no lot set

opw-3485740

closes odoo/odoo#136162

X-original-commit: 218c8d519e1a78cf2e15b556a4f298cf1ef0231d
Signed-off-by: Robin Heinz (rhe) <rhe@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>

When you are using a different currency in a PoS config, invoicing
a POS order that was created in a previous session, causes an
unbalanced entry error. Because the amount_currency and balance of
the payment moves are incorrect.

Steps to reproduce:

- Create POS config with currency other than company currency
- Create order in a session
- Close the session
- Open a new session
- Load paid orders
- Try to invoice the created order

opw-3479292

closes odoo/odoo#135280

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

If the currency_id and cost_currency_id is different for a product, the cost in the purchase order is wrong. The purchase order should use cost_currency_id instead of currency_id.

Steps to reproduce on runbot:
-Set the currency of main company as Dollars (USD).
-Choose in runbot the company "My Belgian Company" as its currency is Euro.
- Add the currency rate of today between EUR and USD
- Take a product and edit the cost to 100 EUR - as the cost field is linked with the currency of the company
make sure on the tab purchase there is no information - so the vendor pricelist is not present.
- Go inside the purchase module and start a request for a quotation
leave the currency as EUR
- Select the product to purchase

Current Behavior:
The unit price will be (100*currency rate). If you do the same but take the currency as USD the product unit price on the purchase order line will be 100

Expected Behavior:
The unit price should have been 100 Euros. And when dollar is chosen as currency, the exchange should have been applied.

OPW-3460551

closes odoo/odoo#133024

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

Use the same method and date used to compute the rate on aml field currency_rate

closes odoo/odoo#134709

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

Steps to reproduce
==================

- Use a mobile viewport
- Create a quotation
- Add an order line
- Set a packaging
-> The Packaging Quantity field is missing

The same happens on purchase orders

---

opw-3504829

closes odoo/odoo#136163

X-original-commit: c5d665cc2b43a0040c3f5644265e74048c3d5ded
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>

Steps to reproduce:
1. Have 2 companies, and select the one w/ the highest ID
2. Create a new product tracked by lot + expiration date
3. Receive product
4. Set the received lot's expiration and alert dates in the past
5. Inventory > Operations > Run scheduler

Before this commit:
An activity is created on the lot for OdooBot,
despite the product's responsible set to the current user.
It happens because the default value for `responsible_id` is the current
user, but the value is only set for the current company. When the
scheduler runs, it doesn't set the company; therefore, it takes the
product's responsible user for the company with the lowest ID, which is
not set.

After this commit:
The activity is created for the product's responsible user using
the lot's company.

opw-3489340

closes odoo/odoo#136125

X-original-commit: dacfa844
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>

closes odoo/odoo#103864

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

Commit f693d9b5 broke ODOO.CURRENCY.RATE when no date is provided.
The text 'Invalid date' is sent to the server, which obvious can't
parse it to a date.

opw-3498115

closes odoo/odoo#136148

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

Some tests are updated to lessen diff in future tests, especially about
aliases. Some tests are fixed as they are somehow incorrect (notably
in gateway testing) but currently passing as mail gateway is quite
permissive.

Add some tests preparing MC / alias domains configuration notably about
company / alias synchronization, which is currently only based on config
parameters.

Also update some tests by using fstrings which are generally more readable.

Finally move some tests to their right file / main testing class to keep
them ordered by main topic.

Prepares Task-36879 (Mail: Support MultiCompany Aliases)

closes odoo/odoo#136102

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

Cleanup some code bits in common classes, add some docstrings. Improve
notifications related helpers, notably to ease checking content of mail.mail
or outgoing emails when posting messages.

Update 'test_message_post' with those new helpers, to ease inclusion of
additional specific values test with alias domains in mind in next commits.

Prepares Task-36879 (Mail: Support MultiCompany Aliases)

Part-of: odoo/odoo#136102

Steps to reproduce:
-------------------
- add an allocation for an employee;
- add a leave with this allocation;
- validate the leave;
- refuse the leave;
- in action menu, click on "Time off Analysis by Employee and Time Off Type".

Issue:
------
The report does not take into account refused allocations and leaves.

Solution:
---------
Add a condition to take a number of days equal to zero
if the allocation or leave is in a refused state.

Handled the case where no record is found for leave
(with `COALESCE` because `value - NULL = NULL`).

opw-3503617

closes odoo/odoo#135882

X-original-commit: 2b3cc596
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>

When changing the value of a DateField outside of the datepicker, the dates
kept by the datepicker instance and the DateField component will get out of
sync. This can happen, for example, when clicking the new button when in a form
view containing such a field. The component is kept, but the date is changed
(generally set to false in this case) while the state of the datepicker stays
the same.

As a result, when clicking the selected date in the datepicker, no change event
is triggered making it impossible to select. This can be frustrating when
manually inputting a series of documents with the same dates.

opw-3459123

closes odoo/odoo#134911

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

In the case where we have multiple projects, we also want to filter on
tasks linked to the SO. In the current implmementation, the default sale
order passed in the context is used to filter by name which results in
including tasks where name of the SO contains the name of the SO instead
of being equal.

opw-3499181

closes odoo/odoo#135771

Signed-off-by: Audric Onockx (auon) <auon@odoo.com>

closes odoo/odoo#126222

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

there is a loophole that allows the same third-party check to be used
for multiple outbound payments. This issue causes data inconsistencies
and disrupts the expected behavior of the financial workflow, thereby
undermining the integrity of the accounting processes.

In order to address it a  constraint was introduced on the
l10n_latam_check_id field. This constraint is triggered whenever
a payment transaction involves the use of 'out_third_party_checks' as
the payment method. The system now conducts a search to identify any
pre-existing payments that might be using the same third-party check.
If a duplicate use of a check is detected, a ValidationError is promptly
raised, effectively blocking the transaction.

Task-3503556

closes odoo/odoo#135815

Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>

When an order's associated table is deleted, the POS tries to load the
table name to display in the order list. This results in an error if
the table no longer exists.

To prevent this, only display the table name if the table still exists
for the order. This avoids the error when trying to load a deleted
table.

opw-3509678

closes odoo/odoo#135970

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Since 16.4, the number of file made pylint reach the default memory
limit from time to time. This commit will remove the limit for this test
as it was done for chrome. The next step would be to split the test
per set of module or maybe analyze the memory consuption of some custom
check.

closes odoo/odoo#136107

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

Before this commit:
- Select a course from the website, and click 'Add Content'.
  From the 'Add Content' window, click 'Video'.
- The description with the title 'On Vimeo' is not up to date with
  Vimeo privacy management.

After this commit:
The description is now up to date.

task-3458724

closes odoo/odoo#136023

X-original-commit: 4a1d2a2726ce83edbf28dd478c60a3e6f67d4470
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Handle payment terms for UBL as described by the Belgian Peppol
Authority and documented by VBO-FEB.

In case of early payment discount (for instance 2% if payment within 7
days):

* add one document level allowance per VAT rate (this allows to reduce
the tax base amount to take the discount into account)

* add one document level charge exempt from VAT (the amount of this
charge is the amount of the discount the customer can get by paying
early)

* Recompute the document level TaxTotal accordingly

Hence, nothing changes for the invoice lines. Importing the xml is then
convenient since each document level AllowanceCharge will create an
invoice line on top of the existing invoice lines. The total amount of
the invoice will be the amount to pay in case of no early payment
discount. To get the total amount to pay in case of early payment
discount, simply remove the document level charge.

References:
https://openpeppol.atlassian.net/wiki/spaces/Belgium/overview
https://efactuur.belgium.be/sites/default/files/3.%20Cash%20discount.docx



opw-3235769
task-3326963

closes odoo/odoo#132625

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

Issue:
Search on website has a big performance issue because the database has
too many product_template.

Analyze :
The website search mechanism has hardcoded sql query. And the generic
query don't have any filtering. Which lead to make a expensive search
(similarity) on the whole product_template even if the products are
not published and then displayed to the user.

Fix :
Filter the is_published field in the generic website method when the
model has a 'is_published' field and the request is not done by a user
(thus for customers or portal users).

Note:
The internal user is still able to search on unpublished product.Thus
have no performance improvement.

Benchmark:
| SQL Query | # Input data | Before PR | After PR |
|:---------:|:------------:|:---------:|:--------:|
|General best_similarity |700000 products (161 published) | 12.65 s | 0.12 s |
|FROM ir_translation|2,796,000 ir_translation | 6.338 s (586k hit) | 0.091 s (185 hit) |

Related task:
task-3473786

Related ticket:
opw-3418457

closes odoo/odoo#135814

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

Before this commit:
The `mailing_filter` widget used to take the 2nd occurrence of a
many2one(selection) field and hide it in certain conditions, as it was assumed
that it is the field having the widget. Thus when there is more than 1
occurrence of a many2one field in the form view (before the field with the
widget), it used to hide random fields instead of targeted field.

After this commit:
The `mailing_filter` widget will only target the field with the widget, hence
solving the issue at hand.

Task-3430510

closes odoo/odoo#135610

Related: odoo/enterprise#47453
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

When the blacklist table is filled with multiple thousands of records
searching the `is_blacklisted` field leads to a domain like
`[('id', 'in', [thousands_of_ids])]`. This can create a multiple megabytes
sql query.

Using inselect allows to avoid that issue.

Task-3328210

closes odoo/odoo#135458

Related: odoo/enterprise#47393
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

purchase_stock, point_of_sale

What are the steps to reproduce your issue?
When Odoo.sh runs unit tests on a development branch,
it tests the code in the MRP module for rounding errors.

What is the current behavior that you observe?
I had a customization that introduced a rounding error in the standard MRP module.
When the unit tests ran on the development branch, I got a traceback.

What would be your expected behavior in this case?
The rounding error should be reported as a failed test with a message. No traceback.

opw-3454998

closes odoo/odoo#135929

X-original-commit: 05e38f11
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Gaetan Vanden Bergh (gavb) <gavb@odoo.com>

having PO

Step to reproduct:
-User A with Admin Project Access Right and no Pucharse Acesss Right
-PO and Project have same analytic_account_id, with PO analytic_account
will place in 'analytic_distribution'
-User A then go to Project Update -> Access Error happen
=> Expected behaviour is to let Project Admin access it

Solutions is to let he/she see it by adding sudo() only

closes odoo/odoo#135429

Signed-off-by: Audric Onockx (auon) <auon@odoo.com>

Set the default sale and purchase taxes for the mexican CoA.

Before introducing the IEPS taxes in commit
734e18eb, the default taxes were the 16%
IVA taxes (when loading the CoA, the default is simply the first
possible match with the lowest sequence). As the IEPS taxes now have the
lowest sequence, they are incorrectly selected as the defaults. This
commit fixes this.

task-3507155

closes odoo/odoo#135877

X-original-commit: 5d98384e
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

The condition for which the Fiscal Position's Note is shown only in Customer Invoices is removed because unnecessary.
A check has been added on the company's country to be 'IT'.

Task link: https://www.odoo.com/web#id=3420752&model=project.task


task-3420752

closes odoo/odoo#135960

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

adress both use cases in :
https://github.com/odoo/odoo/commit/ed2849a55c1463689cbc201a782b0200207bfd37
and
https://github.com/odoo/odoo/commit/4248aac2d224363a6ac4a59881bdb7c321623e4b



button should be red if there's no qty in stock but still be green if
the qty was reserved for the move

closes odoo/odoo#135881

X-original-commit: e243ba49137c5a6151c6da74ef4ed253f81754d9
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Previously, when a view contained an x2m field that had a few thousand
records, the view would take ages to load. This was caused by a few
things in the basic model where we would linearly scan lists of records
in a tight loop, and doing so for every single other record, causing
quadratic increase runtime with regards to the number of records. For
example, creating a new batch picking in stock with 4000 existing
pickings would take up to ~20 seconds to load the view.

This commit creates a few objects to use as lookup tables in such
places, which speeds up the loading of the view to less than a second.

It also makes the context of the DataPoint into a property that's
initialized lazily on first read, as creating a context and the
corresponding evalContext can be expensive, which becomes a problem when
creating thousands of DataPoints whose context will never be read.

opw-3465073

closes odoo/odoo#135860

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Steps to reproduce:

- Install Accounting
- Accounting > Accounting > Journal Items
- Select all items using the checkbox
- Change account to another value
- Click "OK" on the confirmation dialog

Issue:

The system fails to change the account field on the records. This issue occurs because the JavaScript code catches an RPCError when attempting
to write the values to the database but ignores it. Although this
behavior is intended, it leaves the user without any feedback
throughout the process.

Solution:

Add a danger notification with the error message when the write
operation fails.

opw-3354646

closes odoo/odoo#128736

Signed-off-by: Francois Georis (fge) <fge@odoo.com>

In stock_production_lot model, there is a field last_delivery_partner_id which is displayed in a Tree View. This fields require to compute ALL the delivery_ids of each LOT, only to display the last_delivery_partner.

This implies a big performance issue for big lots with huge tracability needs in it. The idea is simple, dissociate the computation for delivery_ids, which is only used in Form View and the last_delivery_partner_id which is only used in the Tree View.

I do agree that if both are used in the same view, it would double the computation time. But currently there is a lot of useless computation. Currently the only way to mitigate is by removing the field last_delivery_partner_id in the Tree View, but if client needs that field, it doesn't works.

Benchmark

|Lots/Serial |# Lots | # Delivery | Before PR | After PR |
|:------------:|:---------:|:--------:|
|Lots| 3 | 3  | 0.2723 s |0.0091 s |
|Lots| 4 | 6699 | 307.98 s | 0.0059 s |
|Lots | 13 | 9575 | 569.85 | 0.0036 s |
|Serial | 80  | 80  | 0.30 s | 0.42 s |
|Serial | 150 | 150 |0.39 s | 0.51 s |
|Serial | 7000 | 2000 | 0.50 s/Batch of 1000 | 0.60 s/Batch of 1000|

closes odoo/odoo#133540

X-original-commit: 6852152e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

To reproduce the issue:
1. In Settings, enable "Multi Routes"
2. Edit the warehouse:
   - Manufacture: 2 steps
3. Create three storable products P1, P2, P3
4. Create and confirm a MO for 1 x P1 with 1 x P2
   - It should create the PBM picking
5. Add a component line for P3
6. (Because the MO is locked, the user can not edit the 'to consume'
   quantity, so) Unlock the MO
7. Set the 'to consume' qty to 1
8. Save the MO

Error: P3 is not added to PBM picking. Worst: suppose the user does
the internal transfer and then checks the availability of P3, the
line will still be unreserved

Step 6, when unlocking the MO, it also triggers a save. As a result,
the SM for P3 is created with its demand defined to 0. When adding
such SM, we do several things through this method call:
https://github.com/odoo/odoo/blob/be0b61cbaf3d3b7082aca8f96dcf8a6ee7885fea/addons/mrp/models/mrp_production.py#L776


- We will adapt its procure method (here, because of 2-steps
  manufacturing, it will be MTO)
- We will confirm the new SM -> we will run a procurement for a zero
  quantity -> it will not generate any new SM

Then, when updating the SM quantity (step 7), nothing will run a new
procurement.

Moreover, this also explains why trying to reserve the SM does not
work: it's an MTO one, but it does not have any `move_orig_ids`, so
it is not possible to assign it.

Solutions:
- It should be possible to edit the 'to consume' qty of a new SM,
  even on a locked and confirmed MO
- A procurement should be executed when updating the demand of an SM
  from 0 to >0. From 16.1, a procurement will always be executed
  each time the quantity changed (see [1]). Here, we want to limit
  the impact/risk of the fix

[1] 1f4fb64a

OPW-3253204

closes odoo/odoo#135859

X-original-commit: dfd7986b1c4c685dc6a91345c86775e279f59d55
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

closes odoo/odoo#135812

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

In enterprise, when doing a comparison between multiple periods with values carried over to them, auditing the carryover values (through the dedicated button in the popup, in debug mode) always opened the latest period.

This was due to the fact the main options of the report were directly used, instead of the ones corresponding to the column group owning the value.

closes odoo/odoo#135658

Related: odoo/enterprise#47476
Signed-off-by: John Laterre (jol) <jol@odoo.com>