Steps to reproduce:
- Create a component C (automated/FIFO)
- Create and confirm two PO for C
    qty: 1, price: 10
    qty: 1, price: 20
- Make an MO with C as a component
- Unbuild that MO

Bug:
The valuation of the new component C is wrong,
the new move in is valued at the current product cost instead
of its original value.

Fix:
create moves as a return to get the correct value

opw-3379457

closes odoo/odoo#137400

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

Current behaviour:
When creating a nameless contact,
while selecting delivery address type
for an existing company, there is a traceback

Steps to reproduce:
1. Install contacts,sale_management,crm
2. Settings > Sales > Quotations & Orders
3. Check "Customer Addresses"
4. Go to Contacts
5. Create a new contact
6. Check "individual"
7. Select a company
8. Select "Delivery" in Address type
9. Save => traceback

Cause of the issue:
Introduced by https://github.com/odoo/odoo/commit/9ef715fb994564af9e933ba31933a09eca97c24f


partner.name can be False

opw-3495748

closes odoo/odoo#137317

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>

- Before fix:
  only select activities done today or in the future so
  it does not reflect the expected behavior of the filter.

- After fix:
  have an expected data with suitable filter name

- OPW: 3504670

closes odoo/odoo#137363

Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>

Description of the issue/feature this commit addresses:

As of the first October 2023, some Japanese companies will start using "T" as
country code in their Tax ID. The current vat check only allows the country
code to be used in the Tax ID which means that "T" is refused.

Desired behavior after the commit is merged :

This commit makes it possible for Japanese companies to use "T" as a
country code in their Tax ID.

task-3515786

closes odoo/odoo#136146

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

On update/upgrade we should keep current password policy if its
already set

closes odoo/odoo#137228

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Fixed the string en passant.

closes odoo/odoo#137142

Signed-off-by: Carmen Bianca BAKKER <carmen@coopiteasy.be>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>

Decorator 5 changed the default decoration method from a transparent
exec-ing to wrapper functions. This makes the decorators visible to
the profiler, and breaks one of the profiler tests as the stack traces
now differ between using decorator 4 and decorator 5. Amongst other
concerns, this is an issue because debian bookworm has updated
decorator to 5 (.1.1), and the next ubuntu LTS (which should be 24.04
hopefully codenamed Nefarious Nematode) will do the same (Ubuntu has
been providing decorator 5 since 23.04).

5.1 added a `decoratorx` function which corresponds to the old
exec-based `decorator`, however it doesn't have a `decorate`
version. So we have to flag the wrappers, instead of decorate-ing the
original method with them. This seems to have the same semantics so
why we were using `decorate` is not entirely clear why we were not
doing that previously (neither
b1e83fd7 nor #25383 really provide
explanations). Possibly because pylint is a dum-dum and requires
ignoring one of its rules?

Implement in 14 since it doesn't hurt even though the test in question
does not exist yet.

closes odoo/odoo#137096

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

When the user tries to find the 'qty_available' of a product but gives
a string value instead of a float value in domain then the user will face error.

Steps to produce:
- Install `stocks`.
- Create a record rule for model `product.template`. In the domain of record
  rule keep [('qty_available', '<', '10')] as a domain,
  you can give any integral value in the domain but that value should be
  enterred as strings (with quotes).
- Inventory > Products > Products

Error: `TypeError: '<' not supported between instances of 'str' and 'float' `

After applying our commit, if the domain is Invalid then the user will face
`UserError`. There is a function named `_search_product_quantity`  which
initially checks if the domain is valid or not :
https://github.com/odoo/odoo/blob/5f1ad0c1e4c1e8ed41337ccd4c12e70c9c760c85/addons/stock/models/product.py#L342-L350


It will filter out all the invalid domain and clear search methods.
So now whenever `_search_qty_available` is called first the validity of domain
and operands of the expression will be checked.

sentry-4399815131

closes odoo/odoo#133155

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

Not very useful to the average user, and can fill up logs during
tests (mostly 16.1 onwards for some reason but might as well square
up everything).

closes odoo/odoo#136944

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Summary
-------
Currently, floats are not always properly rounded when they are used in
computes or onchanges.

Steps to reproduce
------------------
1. Set Product Price decimal accuracy to 2.
2. Create an invoice.
3. Add a line: quantity 2, price 1.205.
Expected Result: Subtotal of 2.42 (using `2 * round(1.205)`).
Actual Result: Subtotal of 2.41 (using `2 * 1.205`).

Fix
---
Always round floats when they are put in cache.

Partial backport of 4c5cdf5f
opw-3333449

closes odoo/odoo#131906

Related: odoo/enterprise#47980
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>

To reproduce
============
- create sms template and apply it to a module different than `res.partner`
for example Tasks
- add context action
- create a task and select a customer that has a phone number
- from action try to send the sms, an error is displayed

Problem
=======
when computing the receipient info, the partner on the record is not taken
into account.

opw-3475456

closes odoo/odoo#134682

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

backport of https://github.com/odoo/odoo/pull/131206



closes odoo/odoo#136779

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

__Current behavior before commit:__
The page crashes when we try to merge two partners and the
`mail.activity.mixin` model has a field with `ttype = "reference"`.

This is because a `search()` on a `mixin` model will always crash as
they are abstract class that don't represent real records.

__Description of the fix:__
Add a check to skip the iteration if `Model` is an abstract class (like
a mixin).

__To reproduce:__
1. Go to Settings > Technical > Fields
1. Create a new field
1. Set **Model** as `Activity Mixin`
1. Set **Field Type** as `reference`
1. Go to the Contacts app
1. Select two contacts
1. Click on Action > Merge > MERGE CONTACTS

opw-3458640

closes odoo/odoo#132016

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

 This issue occurs when a customer imports or uploads a file, and that file
 contains an image that is attached to the URL as text or HTML. then,
 The error would be generated.

  Step to Produce:-
 - import CSV file (Ex.'product.product' model)
    > that CSV file must have one URL Image(In that URL has content of text or
      Html form)
 - Click On the 'Test' Button.

  Applying these changes will resolve this issue.

  sentry:-4046190590

closes odoo/odoo#119499

Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>

The return type of _do_request is inconsistent when an error is
encountered. This causes issues when the callers expect the return
type to be a dictionary consistently.

We fix this by always returning an empty dictionary for the request
response when encountering an error

sentry-4339147124

closes odoo/odoo#129872

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

On a neutralized database, all the IAP accounts should be disabled,
including new ones.

closes odoo/odoo#136347

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Since odoo/odoo#122569, we now try to import the `migrations`
sub-package of each module to find upgrade tests.
However, this badly written regex match the OCA module `base_maintenance`,
which generate a RecursionError.

closes odoo/odoo#136398

X-original-commit: abd9e668
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>

This commit fixes the overflow of content title on without fullscreen view(Exit-
Fullscreen) of content page by cropping the title and adding  '...' at end.

Task-3384661

closes odoo/odoo#128727

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

This commit resolves the issue of content title overflow in both fullscreen
and non-fullscreen views by cropping the title and adding '...' at the end.

Task-3384661

closes odoo/odoo#128713

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

When creating a new company with the italian fiscal localization, the
tax "0% EU" is not instanciated properly

Steps to reproduce:
1. Install Accounting and module l10n_it_edi
2. Create a new company and select it
3. Go to Settings > Accounting > Fiscal Localization, set it to `Italy -
   Generic Chart of Accounts` and save
4. Go to Accounting > Configuration > Taxes and open tax "0% EU"
5. The fields for the italian exoneration are not properly set, they
   should have the same values as the same tax for company "IT Company"
   of the demo data

Solution:
When we set the company chart template, update tax "0% EU" with the
correct values

opw-3414593

closes odoo/odoo#131996

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

closes odoo/odoo#33682

Signed-off-by: bve-odoo <bve@odoo.com>

In the din5008, there has been problem in the display of the paper format either
in the pdf or the preview.

In the preview we had a part of the page on the right that wasn't used caused by
the negative margin and the width of 180mm. But by removing that the pdf is
broken, the header is hiding some information.

To deal with that, we will add the width and negative margin only for the pdf
by adding a conditional css classes.

Also,it seems the footer with the company details can go out of page, by adding
a text-wrap on it, it solves this issue.

(In this commit, we override part of those commit:
https://github.com/odoo/odoo/commit/481f442f4ef176072edf3261415dbb06f8a3bc6f
https://github.com/odoo/odoo/commit/f7812ae848e0a79adcd11f936f6cd7890da00112

)

closes odoo/odoo#136257

Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

This traceback arises when the user selects multi
company records and click on the 'create report' button.

To reproduce this issue:

1) Install 'hr_expense'
2) Create a new company for example 'test'
3) Enable the 'test' company on the right corner
4) Now open 'employees' and change the company of the current user(Mitchel Admin)
   to the 'test'.
5) Open 'Expenses', create a new record, and change the company to 'test'.
6) Fill the required field values and save the record.
7) Now click 'My Expenses/My Expenses to report' and select all the records (Make sure
   'My Expenses' filter is applied)
8) Click on the 'Create Record' button

Error:- "ValueError: Expected singleton: res.company(2, 1)"

On the '_create_sheet_from_expenses' method, the value of 'company_id' is getting
through 'self.company_id.id'.
See:-
https://github.com/odoo/odoo/blob/f910987cb4af84c1e7afabf67f05d4eebc31e765/addons/hr_expense/models/hr_expense.py#L324-L335



But when user selects multi company recordsets
'self.company_id' has multi recordsets.

When 'company_id' is getting value through 'self.company_id.id', because of
'self.company_id' has multiple records, which leads
to the above traceback.

By applying this commit will resolve the issue by raising an exception,
when user selected multi company records to create report.

sentry-4465422743

closes odoo/odoo#135035

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

Prior this commit:
The mail scheduler of the event notifies the attendees even when the event is
no longer active.

After this commit:
Inactive events no longer notify attendees.

Task-3381876

closes odoo/odoo#130237

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

1. Backport of [1].
2. Steps to reproduce:
- Install website_crm
- Connect as Admin and remove the sales rights for Demo
- Check the website on a private window (to create an anonymous visit)
- Connect as Demo on the normal window
- Go to Website > Reporting > Visitors
=> It triggers an access error due to lead_ids being restricted to
sales_team.group_sale_salesman.
(Note: the error sometimes isn't triggered at that point. In that case,
click on the visitor: the same error will trigger.)

Considering the computed field doesn't do anything critical as it just
retrieves the email and phone number, the restriction is overridden on
the field.

[1]: https://github.com/odoo/odoo/commit/7de453477d7c23e607a15e0d60613080857e3371



opw-3475301

closes odoo/odoo#135991

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

Upgrade (aka migration) scripts are a core part of Odoo, allowing
database manipulations for modules during version changes.

Any module, including custom ones can run upgrade scripts, even if the
`--upgrade-path` flag (and with it, the `odoo.upgrade` sub-module) is
not present. Currently only the "standard" modules benefit of easy
upgrade script testing. Any custom modules that want to run tests of
their upgrades have to import the tests in the usual `tests` folder,
which is not ideal.

Therefore, to allow TDD and programmatic testing of upgrade scripts in
custom modules, the test discovery is here modified to also parse the
module's `migrations` and `upgrades` sub-modules for tests.

closes odoo/odoo#136130

X-original-commit: 483cc20b
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

When the number of mail.activities for a user was getting too big, the whole database is getting slowed down as the activities are recomputed each time a page is loaded.

The issue was mostly brought by commit [03c3d440](https://github.com/odoo/odoo/commit/03c3d440ae31baa0400b7adba7f6373556ff5c38

).

The time was recorded when refreshing the home page of the site.

|     |     |     |
| --- | --- | --- |
| #activities | before PR | after PR |
| 100 000 on 1 model | 22.66s (single test) | 0.408s (worst of few runs) |
| 40 on 40 models | 0.06s worst, 0.037s best | 0.053s (worst of few) (0.038s best) |

closes odoo/odoo#134126

Signed-off-by: Sébastien Theys (seb) <seb@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#135361

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

- Create a move
- Add a line and set a custom tax tag on it
- Add a new line to balance the move
=> The tax tag is gone.

This is because the code is recomputing taxes when adding a new line.

closes odoo/odoo#135756

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

Before this commit:
When returning a dropshipping, the valuation layers created do not have
the correct accounts on it:
 - Valuation -> Input   for the first SVL
 - Output -> Valuation  for the second SVL

After this commit:
For a dropshipped move, valuation layers have the following chain
of accounts:
 - Input -> Valuation   for the first SVL
 - Valuation -> Output  for the second SVL
Therefore, the return should have it reversed:
 - Output -> Valuation  for the first SVL
 - Valuation -> Input   for the second SVL

Steps to reproduce:
1. Create a dropship product with automated inventory valuation
2. Create a Sales Order, go on the PO and confirm it
3. Set quantities and validate dropshipping
4. Return delivered product (dropship return)

opw-3391174

closes odoo/odoo#132864

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

After commit [1], the check that the target url is different from
the current page's url has been removed thus leading to error that anchor
link always scroll down to element that have data-anchor enabled.

Steps to reproduce (the easiest way):
- Install Website Blog
- Turn on customize comment on post
- Go incognito then access any blog post, scroll down and click the
`Sign in to leave a comment` button
- Holy, the page scrolls down to the discussion section but doesn't go
to the login page

[1]: https://github.com/odoo/odoo/commit/fb087dbec96f5e533d1fdd9c2b0c2e00296c83de



closes odoo/odoo#135620

Signed-off-by: Benjamin Vray (bvr) <bvr@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#130042

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

Steps to reproduce the bug:
- Create a storable “P1”:
   - tracking= serial
   - save
- Change the type of product to service

Problem:
some fields for tracked products are not hidden, because the product
tracking is not updated.

Solution:
Convert _onchange_type into compute methods.
The tracking is updated even if the change type is applied from the
"product.product" form.

opw-3499976

closes odoo/odoo#135852

Signed-off-by: William Henrotin (whe) <whe@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#135810

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

purchase_stock, point_of_sale, sale_mrp

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

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

This patch provides the possibility to implement a custom security layer on top
of Odoo's bus notification system which uses postgresql's NOTIFY command.

The key addition is the `ODOO_NOTIFY_FUNCTION` environment variable (opt-in),
which can now define a postgresql function to be called instead of the NOTIFY
command. This allows for greater flexibility and control over the notification
and triggering mechanisms within Odoo.

closes odoo/odoo#130368

Signed-off-by: Fabien Meghazi (fme) <fme@odoo.com>

closes odoo/odoo#135679

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