If you have some leads which are nearly always won or lost, you may
end with a probability which is either 0% or 100%.
These values indicate that the lead is lost or won, therefore we must
check the limit values.

opw-3413206

closes odoo/odoo#128237

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

Expense - Steps to reproduce the bug:
1. Create an employee whose private address is linked to the current company's partner_id
2. Create an Expense and expense report with the employee(1) with mode paid by employee
3. Confirm the Expense report and post the journal entries
4. Click "Register Payment" --> User Error occurs
5. A User Error like the following should appear (with different journal entry names):
       "Journal Entry Draft Entry PBNK1/2023/00001 (INV/2023/00005) is not valid. In order to proceed, the journal items must include one and only one receivable/payable account (with an exception of internal transfers)."

The User Error also occurs for a different scenario mentioned in https://github.com/odoo/odoo/pull/127412



According to SVFU on how the bug is fixed:
The condition that classifies the extra lines as "counterpart lines" was only intended for internal transfers.
Each company has a related "transfer account" that is used as an intermediary account for internal transfers.
Thus the old condition (c.f. commit diff) when checking whether a line is a "counterpart line"
can be replaced by checking whether the account associated with the line is the "transfer account" of our company.

closes odoo/odoo#128645

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

task-3433465

closes odoo/odoo#129140

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

Fix various issues that appeared when working with registrations. When converting
registrations to leads using rules some convert flows have issues or can crash. This
PR fixes several issues, see sub commits for more explanations.

Improve test suite to cover more use cases.

Task-3431124

closes odoo/odoo#128823

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

Partial backport of odoo/odoo@94fa8d962535a754c9fb26997a38cc8b51b8974e keeping only event_crm part as
other changes were done only for Odoo16.

In this commit we try to compare formatted phones of registration and
partner, before checking the actual phone numbers. If only formatting
differs then it is not a different number.

Task-3431124

Part-of: odoo/odoo#128823

When checking updated values of a registration to propagate to its linked lead
we may compare a recordset to IDs. This commit fixes that by always comparing
IDs.

Task-3431124

Part-of: odoo/odoo#128823
Co-authored-by: Jeremy Hennecart <jeh@odoo.com>

When checking if partner and registration have the same email, better compare
normalized versions if possible as it filters out formatting differences
e.g. if one input has a formatted email with another name.

Task-3431124

Part-of: odoo/odoo#128823

When having rules creating leads from registrations, email and phone are
copied from the registration if the linked partner has no value for those
fields. However an error in the code lead to setting phone into email which
is not really correct.

This commit also add tests for event_crm who allowed to spot other issues
which are fixed in the next commits.

Task-3431124

Part-of: odoo/odoo#128823

This patch aims to fix multiple issues with the removal of table
constraints at module uninstall.

1. We cannot remove `ir.model.constraint` records before calling
   `_module_data_uninstall` on them. Otherwise we either won't find them
   when performing the search
   `self.env['ir.model.constraint'].search([('module', 'in',
   modules.ids)]` or, if we somehow keep the ids and use `browse`
   instead, would get an error because `_module_data_uninstall` tries to
   access field values of records already removed. Note, although not an
   issue, the removal is redundant for non FK constraints since
   `_model_data_uninstall` already unlinks the record.
2. When a constraint has a name longer than 63 characters (Postgres
   default) we would fail the check for the existence of the constraint
   since the names are truncated.
3. When checking for the presence of a constraint we assumed its type
   would be `u` in `pg_constraint` because for us that means non FK
   (i.e. not `f` type). That's incorrect since there are many more
   types. Here we propose to handle `c,u,x` types.

For bullet 2 there is no simple way to ensure compliance of the name
length limit for constraints. We perform checks for table names in
standard code. There is no such alternative for constraints since their
names are enlarged by the table name, plus the `copy` method on
`ir.model.constraints` makes the name even longer. Hence we opt here to
check truncated names.

[IMP] code: improve uninstall tests

Perform extra checks for removal of SQL constraints. Note the test is
commented out in `__init__.py`. It can be uncommented locally for
testing. It's kept commented out to avoid random errors in runbot.

closes odoo/odoo#128050

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

Steps to reproduce the bug:
- Create a storable product “P1” with BoM
    - Operation: OP1
    - Component: C1, consumed in: OP1

- Navigate to Mrp > Configuration > Operations
- Select OP1 and select another BoM
- return to the BoM of “P1”

Problem:
The BoM line for component "P1" is still linked to OP1,
And a traceback when attempting to duplicate the BoM.

Solution:
Remove the operation from the initial BOM

opw-3429980

closes odoo/odoo#128821

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

If model A has a selection field, and is inherited by 2 modules
B and C, B adds selection values to the field, and C inherits model
A under a different module and model names.
Based on the order of installation of B and C, we may end up with
different xmlids.
If B is installed before C, then B will add xmlids for the new
selection values added for model C. But if C is installed before
B, then C will have the selection values from B without xmlids.
The change here ensures that the selection values introduced by B
will always have correct xmlids.

closes odoo/odoo#127251

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

Currently, changing the french default_tax_sale's name or account will make the
`test_generate_fec_sanitize_pieceref` fail (for instance: with task-3087037).
Make the l10n_fr_fec test independent from any account.tax.template change by creating a
new tax in the setup of this test.

backport of https://github.com/odoo/odoo/commit/5128c8dfe75aa943a47e939776804dd878c0e378



Fixes runbot error 21804

closes odoo/odoo#128547

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

An error occurs when the user attempts to delete the 'database.secret' record,
either by following these steps:
- Enable developer mode.
- Go to Settings > Technical > System Parameters.
- Select the 'database.secret' record and attempt to delete it.

Or when the user tries to update the key for the 'database.secret' record using
the following steps:
- Open the 'database.secret' record.
- Update the value of the key field.
-  Save the record.
- The server will stop running and not be accessible.

Error: ValueError: CSRF protection requires a configured database secret

sentry - 4291267997

closes odoo/odoo#127103

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

Steps to reproduce:
1- install swiss localization
2- create a QR bill

Bug:
the addresses contain the field `o.company_id.country_id.code` which is
not the standard of the swiss QR bill

fix:
remove the field

opw-3395089

closes odoo/odoo#127215

Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>

Customer reported an XML file with an UBL_version 2.2
reported <cbc:UBLVersionID>2.2</cbc:UBLVersionID>
at the beginning of the XML file.

As reported on the wikipedia page of the
'Universal Business Language' (UBL):
- the version 2.2 has been approved&published on July 2018.
- the version 2.3 has been approved&published on June 2021.

opw-3316684

closes odoo/odoo#128681

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

before this commit, on clicking the purchase kanban view,
it allows to quick create from the kanban view,
and the value entered is going to name of purchase order

after this commit, quick create is disabled

closes odoo/odoo#127905

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

Issue:
Expenses linked to an SO are counted as 1 hour of timesheet linked
to the SO.

Steps to reproduce:
- Install Sales, Timesheets, Expense
- Create an SO and sell a service that creates a Task > Confirm
- Log some timesheet on the task (3h for ex.)
- Create an expense related to the SO, approve it and generate the
  journal entries.
- On the SO, the smart button shows 4h clocked, and when you click
  on it, the expense line is showed, which shouldn't be the case.

Cause:
Incorrect domain taking the `order_line` without filtering on the
fact that they may be expenses or not.

Fix:
Specify the domain on the action to exclude expense lines.

Affected versions:
- 14.0 - count is correct, only action is showing more lines
- 15.0 - same as described in the commit msg
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master

opw-3302460

closes odoo/odoo#128432

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

closes odoo/odoo#128498

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

Despite being an uncommon need, it is a possible one and should be available

Part-of: odoo/odoo#128498

before this commit, in the mrp.production form view,
along with a button definition there is an extra
closing: />

after this commit, the extra /> will be removed from
the button.

closes odoo/odoo#127369

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

The field company id on stock lot is required but there is not a default value.
The default value should be the current company id

closes odoo/odoo#127271

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

Before this commit:
When returning a transfer in AVCO/FIFO, the return's value is not always
the same as the original delivery. The unit cost for the return was
rounded, which introduced rounding errors.

After this commit:
When returning a transfer in AVCO/FIFO, the return's unit cost is not
rounded, allowing the correct value to be set.

Steps to reproduce:
1. Create a product and change its category costing method to AVCO
2. Purchase the product qty: 1 price: 13.13
3. Purchase the product qty: 1 price: 12.20
4. Sell the 2 product and deliver it
5. Create a return for the delivery
6. The value on the delivery is 25.33, but 25.34 on the return

opw-3358531

closes odoo/odoo#126546

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

When user not seleted 'work center' and only selecting 'Scheduled Start Date'
and 'Scheduled End Date' while creating  'work_order' in 'mrp_production',
this traceback raises.

To reproduce the issue:
1. Install 'mrp'
2. Activate 'Work Orders' in configuration/settings
3. Go to menuitem/operation and create 'Manufacturing Orders'
4. Select any product and add a line in Work Orders
5. Give values to 'Scheduled Start Date' and 'Scheduled End Date' only.

Error: A traceback appears:"ValueError: Expected singleton: resource.calendar()"

On '_calculate_duration_expected' method resource_calendar_id value
is getting from 'workcenter_id'.
https://github.com/odoo/odoo/blob/36459d26f1adb92f92d52ce05329e8ad3e95dd91/addons/mrp/models/mrp_workorder.py#L399-L404


Therefore in the above use case, when triggering the onchnage method,
because of resource_calender is dependend on 'workcenter' and when workcenter
is not selected it will lead to the above traceback.

Sentry-4244804815

closes odoo/odoo#124813

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

Current behaviour:
If you disable the recurrence for 1 task in a suite of recurrence,
if you had other tasks belonging to the same recurrence suite, they
would still be with recurrence activated.

Expected behaviour:
It doesn't make sense for some of the tasks in a suite of tasks in a
recurrence to enabled and others disabled. If we disable the
recurrence on 1 such tasks, all tasks should linked to that
recurrence should be set as non-recurrent, regardless if the
edit-mode is set on "This task".

Steps to reproduce:
- For 14.0 -> saas-16.1:
  - Install Project, Studio
  - Turn on in Settings the "Recurrent Tasks"
  - Create a new project and a task in it
  - With studio, in debug mode, add a related field to the task form
    that relates to `next_recurrence_date`. Make sure it's not "read
    only"
  - On the task, turn on the recurrence, set the frequency to each
    day, set the `next_recurrence_date` as a day in the past
  - Run the Scheduled Action "Project : Create Recurring Tasks"
  - On one of the task, disable the recurrence
  - Go to the other task, see that their recurrence is still active,
    and the frequency changed to the defaults values of once a week.
- For saas-16.2 -> master:
  - Install Project
  - Turn on in Settings the "Recurrent Tasks"
  - Create a new project and a task in it
  - Activate the recurrence on the task, set a planned date in the past
  - Set the task as "Done", this should create an new instance of the
    recurrence.
  - Disable the recurrence option in one of the task, observe that
    is doesn't change for the other task, and the recurrence
    frequency is reset to default values.

Reason for the problem:
When disabling the recurrence on 1 task, with the edit-mode set as
"This task", the recurrence is being deleted, but we don't disable
the recurrence of the other tasks linked to that recurrence.

Fix:
When we are writing `False` on `recurring_task` on a task, we
explicitely write `False` on `recurring_task` on all tasks that belong
to the recurrence after the deletion of the recurrence itself.

Affected versions:
- 14.0
- 15.0
- saas-15.2
- 16.0
- saas-16.1
- saas-16.2
- saas-16.3
- master

opw-3265212

closes odoo/odoo#124992

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Sometimes, the net price and the gross price are not present in the
invoice line, but the line subtotal is (for instance, with some xml from
Billit). In this case, it is still possible to infer the Odoo unit price
and parse the xml correctly.

opw-3384704

closes odoo/odoo#127747

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

Only tests tagged as external should actually call external sites. `TestMailRenderMixin` not only does that but it calls URLs which literally don't exist either.

Patch `requests.Session.request` (via a utility added to odoo tests common) to disable that in the class.

closes odoo/odoo#128249

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

The method '_create_taxes_from_template' is expected to return ids
of templates and taxes instead of the records.
The return of this method is used for translations of taxes which
also expects ids, and in the migration scripts of specific modules
that expect ids.

closes odoo/odoo#127537

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

# HOW to reproduce:
- Create product P, storable
- Create product C, storable, 100 unit in stock
- Create Bom for P, with component C, and
- Create MO for 100 units of P, Confirm
- Go to Work Order tab, open work order, set qty to 120, Mark as Done
- On the MO, edit qty_produced to 50
- Validate -> Create Backorder
=>> You can not enter negative quantities

OPW-3281427

closes odoo/odoo#120017

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

An error is thrown when trying to edit fields in the address of a
partner when an address_view_id is set on the company country

Steps to reproduce:
1. Install Contacts, Studio and module l10n_mx_edi_extended
2. Go to Contacts and open any contact
3. Toggle Studio
4. Click on the Zip field in the address
5. Try to edit the label of the field, an error is thrown

Solution:
Render the original view by using the no_adress_format context key

opw-3374394

closes odoo/odoo#126727

Related: odoo/enterprise#43316
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

Steps:
- Go to portal and select tasks and search anything in search bar.
- Showing  no tasks available
- choose group by none and search anything it will show table labels.

Fix:
shows warning when there is no record when groupby by none.

task-3183771

closes odoo/odoo#114406

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Adapt to the new 2023 VAT report.

task-3262513

closes odoo/odoo#118648

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

On-time-rate is a non-stored computed fields that can take
some time to load because some partners may have lots of
related purchase_orders. The compute function in itself
is relatively difficult to optimize further. This commit
introduces a new system parameter to reduce the timerange of
orders to consider when computing On-Time Delivery Rate.

That way, if for some customers the on_time_rate computation takes too
much time (leading to a slow FormView loading), they can reduce
the accuracy of the estimation to speedup the field's computation.

closes odoo/odoo#127607

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

When a RR updates the qty of a POL, the qty to order of that RR will
be incorrect

To reproduce the issue:
1. Create a product
   - Storable
   - With a vendor
2. Create a RR:
   - Min 0
   - Max 0
   - Factor 1
3. Confirm a delivery with 1 x P
   - It should create a PO
4. Confirm a second delivery with 1 x P
    - The POL of the PO should be updated
5. Open the Replenishment page

Error: The qty to order of the product is 1 while it should be 0

`qty_to_order` is a computed field and one of the `depends` is the POL
related to the product. This explains why, after step 3, everything
is ok: the compute is triggered (because of the new POL) and the qty
to order becomes 0. However, step 4, the POL qty is updated -> it
does not concern any `depends` -> the compute is not triggered,
hence the error

OPW-3292297

closes odoo/odoo#127554

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

Steps to reproduce:
- set shipping methods country to mexico (empty states)
- fill an order on website on check out select seprate shipping/billing
- on billing set country as US
- on shipping the only country avialable is mexico
- avialable states are the ones from the US not mexico

Bug:
the states are set from the country of the customer even though it isn't
an option on any carrier.
bug was introduced by this commit[1]

Fix:
revert the mentioned commit(1) since a new commit[2] was introduced that
correctly handles that use case too

[1]:https://github.com/odoo/odoo/commit/d59fe9c58c2dcc2bf6613adb7ac3662597b50496
[2]:https://github.com/odoo/odoo/commit/297641da69982d6c76bd591296636b479cabf657



opw-3230361

closes odoo/odoo#126054

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

Steps to reproduce:

  - Install CRM and Helpdesk modules (for test purposes)
  - Set a custom alias domain (e.g. "mydomain.com")
  - Go to CRM > Configuration > Sales Teams
  - Check that a team has en email Alias (e.g. "info@mydomain.com")
  - Go to Helpdesk > Configuration > Helpdesk Teams
  - Check that a team has en email Alias (e.g. "support@mydomain.com")
  - Email your instance with the following `to` value:
    info@mydomain.com, support@test.com
    (notice second email does not match the DB alias domain)
  - Go to CRM : A task has been created
  - Go to Helpdesk : A ticket has been created

Issue:

  The ticket in Helpdesk should not have been created.

Cause:

  The message_route method does not check the domain of the email
  address before creating the routes.

Solution:

  If `mail.catchall.domain.allowed` system parameter is set, filter to
  only keep the emails address that match the allowed domains (including
  domain set in `mail.catchall.domain` system parameter).

  The value of `mail.catchall.domain.allowed` system parameter should
  be a comma separated list of domains. e.g. `example.com,example.org`

opw-3150972

closes odoo/odoo#115213

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

Description of the issue/feature this PR addresses:
In the project task view, add initially planned hours 0.05 and assigned a
complete value to the the task then the progress bar shows the wrong value

Current behavior before PR:
when adding the  00:05 planned hours and assigning the complete duration the
The progress bar value is not right

Desired behavior after PR is merged:
progress bar value should be right

task-3280609

closes odoo/odoo#119020

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

When user archive a slide from a course and try to access route
'/slides/embed/<int:slide_id>' of that particular slide, user get the error.

steps to reproduce:
    1. Go to Website and click on courses menu.
    2. Open a course and archive a slide in it.
    3. Then go to '/slides/embed/<int:slide_id>' route.
    4. Access that particular slide that you have archived in route.
    5. The error will occur.

Applying this commit will fix this issue.

sentry-4025579653

closes odoo/odoo#120280

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

Current behaviour:
Next contracts searching will search incorrect state.

Expected behaviour:
Next contracts should not contain draft state contract.

Explanation:
Contracts state field new state should use the value draft.

closes odoo/odoo#121335

Signed-off-by: Kevin Baptiste <kba@odoo.com>