To reproduce
============
- on website add or edit **contact us** form to create a task on a project
- fill the form from Incognito
- on project -> the created task : try to send message on chatter
- you will find the email used when filling the form with possibilty
to check it as receiver
- check the box, a dialog will open to create a Partner for this email
- close the dialog without modifying anything

Problem
=======
the checkbox will remain checked, but when you send a message no email will be sent

Solution
========
as stated in this comment https://github.com/odoo/odoo/blob/de1f701e7bd7ebb6f7ebea5c097d980039c4f904/addons/mail/static/src/components/composer_suggested_recipient/composer_suggested_recipient.js#L128-L130


we will only send the message to partnenrs, so if no partner is
created we must uncheck the checkbox.

opw-3168779

closes odoo/odoo#112214

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

In the EAS list, the United Kingdom code is set to 'UK' while in Odoo,
it should be 'GB'. Because of that, the UBL Bis 3 format doesn't appear
in the journals for GB companies.

opw-3169038

closes odoo/odoo#113013

Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

Currently, it is possible to resequence account moves which are hashed.
This should not be the case. Therefore, we are adding the name of the
move into the list of hashed fields.

However, since we are changing the hashing algorithm by including a new
field in its computation, we must add a versioning system to make sure
we don't break the integrity (data inalterability) report.

In practice, this means that prior to this commit, all hashed moves used
the fields of v1, and moves after this commit will use v2 (which adds
the name into the list of hashed fields). Thus, whenever we generate
the integrity report, we will run the v1 algorithm, and if it a
potential corrupted move is found, we will switch to v2 and check again.
If it also fails, this means the hash is indeed corrupted.

task-id 3102481

closes odoo/odoo#112320

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

A DOM observer is initialized at the start of the table of content
(TOC) snippet options but is never disconnected. This could lead to
memory leak. The goal of this commit is to disconnect this observer and
stop intercepting the changes of the DOM at the destroy of the snippet
option.

Related PR: https://github.com/odoo/odoo/pull/110860



closes odoo/odoo#112960

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

product._get_rules_from_location, orderpoint._compute_lead_days
and orderpoint._compute_rules can all be performances
bottleneck. This is mostly because the rules are retrieve
one by one, i.e lots of 'SELECT ... LIMIT 1' queries
are executed.

Refactoring this in stable is difficult because
there are lots of methods involved and the rules have
some type of hierarchy based on the location_src_id field.
So there are recursive calls that are hard to refactor.

Instead of doing that, the idea of this commit is to speed up
these individual 'SELECt ... LIMIT 1' queries by adding
b-tree indexes on some of the stock.rule fields that are
used as conditions of these select queries.

opw-2773988

closes odoo/odoo#90531

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

Steps to reproduce the bug:
- Install FedEx delivery
- Go to the shipping method > FedEx:
    - Select Real cost and margin on rate 10%
- Create a storable Product “P1” and update its qty
- Create a SO:
    - Add the product “P1”
    - Click on add shipping
    - Select FedEx and get the rate
    - Imagine the price is $10 and with margin it's $11

- Confirm the SO and process the delivery

Probelm:
The shipping price will be $12 instead of $11 in the SO

Because the estimated price is calculated the first time with margin
and added in the picking when sending to the shipper:
https://github.com/odoo/odoo/blob/afed7db30042e2ea91cdae292dadb7b6f742e33d/addons/delivery/models/stock_picking.py#L226

Then, the delivery cost is added to the SO, but the margin is applied a
second time:

https://github.com/odoo/odoo/blob/afed7db30042e2ea91cdae292dadb7b6f742e33d/addons/delivery/models/stock_picking.py#L246

https://github.com/odoo/odoo/blob/afed7db30042e2ea91cdae292dadb7b6f742e33d/addons/delivery/models/stock_picking.py#L262

so this commit is useless:
https://github.com/odoo/odoo/commit/632767d83e0f42acc5b486bde02dd1d9c2533911


because the `_add_delivery_cost_to_so` function is called only when
sending to the shipper

opw-3184482

closes odoo/odoo#112910

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

Steps to reproduce the bug:
- Create a storable product “P1”
- Update the qty to 100
- Create a Transfer:
    - product: P1
    - type: Delivery order
    - qty: 1 unit
    - Mark as to do
    - Reserve the Qty

- Create a seconde transfer:
    - product: P1
    - type: Delivery order
    - qty: 5 unit
    - Mark as to do
    - Reserve the Qty
    - qty done: 2 unit

- Create a batch picking with the 2 transfer
- Try to validate the batch

Problem:
A traceback is triggered: “ValueError: min() arg is an empty sequence”:
https://github.com/odoo/odoo/blob/829369d3ca0530f1aad0599fbb1598810a928cc3/addons/mrp_subcontracting/models/stock_picking.py#L73

Because when validating the first picking, the `_action_done` function
is triggered, so moves that do not have qty done will be cancelled

https://github.com/odoo/odoo/blob/3073779762a106b4022bfb0a350758445d28ea15/addons/stock/models/stock_move.py#L1524-L1529

Therefore, the reserved qty will be unreserved, and the
`stock.move.line` will be unlinked

https://github.com/odoo/odoo/blob/3073779762a106b4022bfb0a350758445d28ea15/addons/stock/models/stock_move.py#L1442

https://github.com/odoo/odoo/blob/3073779762a106b4022bfb0a350758445d28ea15/addons/stock/models/stock_move.py#L724



Solution:
We get the `date` from the `stock.move.line` to use it only when we have
subcontracted production, we can therefore add a check before accessing
them

opw-3159876

closes odoo/odoo#112564

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

Steps to reproduce:
- install base_address_city and web_studio modules;
- go to Contacts app;
- click on a contact;
- active Studio;
- click on the "Contacts & Adresses" tab;
- click on "EDIT LIST VIEW".

Issue:
A traceback appears ("modifier "readonly": Unknown field type in domain").

Solution:
Add type field in the view.

opw-3107274

closes odoo/odoo#112519

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

Before this commit: if a different `web.base.url` is set with
`web.base.url.freeze`, during the first synchronization of Google
calendar it will show a mismatch URL error. The problem is that we
send the `redirect_uri` based on the `web.base.url` in the
`_get_authorize_uri` function.

The solution is to use the request root URL instead.

opw-3101741

closes odoo/odoo#111336

Signed-off-by: Arnaud Joset <arj@odoo.com>

When a `we-select` has no elements, it is drawn as a flat line.

This commit puts a "/" in its toggler content. This character is the
same one as the one that is displayed if the selected value is not one
of the available values.

Steps to reproduce:
- Delete all `website.snippet.filter`
- In debug mode, drop a "Dynamic Snippet" in a website page
- Select it
=> The "Filter" option was displayed as a flat line.

opw-3166634

closes odoo/odoo#112117

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

Steps to reproduce:
In Working Times, click on "SWITCH TO 2 WEEKS CALENDAR"
for the default calendar used by the company.

Issue:
A ValidationError appears: 'Attendances can't overlap.'

Cause:
To create a two-week schedule, by default,
we will use attendances provided for the company's default schedule.

When we want to switch from a one-week schedule to a two-week schedule,
we first delete the attendances from the schedule to be modified.
However, if this schedule is the company's default schedule,
it will no longer have the default attendances
that we must use to build the two-week schedule.

So we end up with the two "fictitious" attendances
that are used to delimit the two weeks.

With only these two attendances, the constraint of not having
two overlapping attendances is not respected
(because the two attendances created will be modified
to belong to the same week).

Solution:
Check that the calendar to be modified
is not the default calendar used by the company.

opw-3127337

closes odoo/odoo#111559

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

In case of the user have no access to all account.move, the hash result can be wrong.

Before this PR a user with limited access can print this report.

closes odoo/odoo#111185

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

Currently, the name's fields to send to Authorize when the partner is a company are:

* firstName
* lastName

if we consider following name `Company Duck Inc`:

the code is sending:

* firstName: ''
* lastName: 'Duck'

Only it sends the `lastName` with the second word found in the name,
due to the new validations in Authorize.Net, this kind of transactions
are marked as suspicious and it's not confirming the transactions, leave them
as pending, this commit is sending the full name in `lastName`
instead of only second word to meet with the validation in Authorize.Net

Also, we are sending the fields `firstName` and  `lastName`, with the
maximum length allowed by Authorize.

closes odoo/odoo#112363

Signed-off-by: Morgane Demesmaeker <edm@odoo.com>

When migrating, if a `Tax Mapping of Fiscal Position` already exists
(for example, when manually created), any update of the module would
raise a traceback trying to violate a uniqueness constraint.
This commits fixes that

opw-3166338

closes odoo/odoo#112505

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

before this commit the lot field is visible even without activating the lot and serial number feature from the settings.

after this commit the field will be visible only when the feature is activated in the settings.

closes odoo/odoo#109273

Related: odoo/enterprise#35500
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

An IndexError "list index out of range"  trace back that occurs in point_of_sale
/RecieptScreen :async _sendReceiptToCustomer was caught by sentry.
 order_server_id is undefined because it is  not properly sync with the server

step to reproduce:

1. First of all start the session in point_of_sale to produce error we have to
   be in offline mode and generate product order.
2. Add customer, select a payment method and validate.
3. After validation send email to customer(failed to send mail.
   because we are in offline mode and order_server_id is undefined )
4. Now get back to online mode and again send mail to customer
5. This time an IndexError 'list index out of range' is trace-backed.

So if order_server_id is null then we throw error to user.

sentry-3824163568

closes odoo/odoo#112394

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

1. Install [Accounting], [Spain - Accounting] on Apps
2. On [Settings],
- [Users & Companies]>[Companies]: add and set to a company in Spain
3. [Accounting]>[Configuration]>[Fiscal Positions]
- Select [REAGYP - Agricultura]
- Missing 0 % IVA soportado (bienes corrientes) (Compras)

Request: reflect the policy to protect the vulnerable groups
- https://www.boe.es/buscar/doc.php?id=BOE-A-2022-22685



Impacted versions: 14 - master

opw-3143902

closes odoo/odoo#112023

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

Before this commit if you would call phone_parse() but not pass along a
country code it would crash. This is reproducable by calling the phone_parse
function and not setting a country on the contact. In this case you would get
the following traceback:

  AttributeError: 'bool' object has no attribute 'upper'.

This happens because the phonenumbers library tries to upper() the region but
if Odoo doesn't have a country set it passes along False. By doing a fallback
to 'None' the phonenumbers library will natively handle this and the user in
the UI does not get a traceback.

Task-2852953

closes odoo/odoo#112619

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

closes odoo/odoo#112537

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

With this commit, we add the shipping address
to the invoice report when it is different from
the invoicing address.
We do the same way as in l10n_de_sale/models/sale.py
and l10n_de_purchase/models/purchase.py,
by adding the computed field l10n_de_addresses
in account_move.

Steps:

- Insltall l10n_de and sale
- Set Customer addresses in settings
- Ensure that DIN5008 is set as document layout
- Create and confirm an invoice with delivery
  address different than invoicing address
- Print or preview invoice
-> Shipping address does not appear on report

opw-3090418

closes odoo/odoo#108675

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

The test `test_anglo_saxo_return_and_create_invoice` added in commit
fcf8a515ba36c8f91f3fe0a63f42f97b20b432f0 does not fail without the fix.

Also added an extra step to `test_anglo_saxo_return_and_credit_note`.

opw-3077772

closes odoo/odoo#112418

Signed-off-by: Adrien Widart <awt@odoo.com>

The field email_from is a computed stored field. Let it compute for
the email_from instead of taking the one from the orginal task

closes odoo/odoo#112603

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

The employee should be subscribed to their own record in order to
receive communication send to them.

closes odoo/odoo#84772

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

Before this commit, when obtaining link URL suggestions, both the
specific and the matching generic page were suggested.

After this commit, only the most specific ones are kept in the suggested
list.
This commit also adapts the sitemap in the same way.
In stable, a condition on a dedicated context key is used in case those
methods were called with the goal of obtaining both generic and specific
pages.
In 16.0, those methods will always filter duplicates pages as it was
supposed at first.

Steps to reproduce:
- Edit Contact Us page (to create a specific view)
- Edit the Contact Us menu
- Type "/" in the URL
=> "/contactus" appeared twice.

task-2968292

closes odoo/odoo#111603

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

There is a check that prevent to set "internal" (meaning from the current company) partners on invoices/bills created via a journal alias.
When the "from" email is the email of the company, the check previously failed to recognize it as internal.
This could happen in this scenario :
If a customer/vendor sends a invoice/bill to the company email.
If then, someone forward this email to the journal alias. The "from" field is now the company email address.

closes odoo/odoo#112108

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

before this commit, on clicking the sales calendar view, it allows the quick adding from the calendar view and entered value is going to the name field of sale.order model.

after this commit, quick adding will be disable and on clicking form will be opened with selected date.

closes odoo/odoo#112523

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

Following the DateV SKR04 standard, we should not use the
automatically created codes for these accounts.
So we have to create them by hand to specify the code.
Backported https://github.com/odoo/odoo/commit/7015a45eba8507ab752adeb86494ff42fe9b5036

 for before 16.

closes odoo/odoo#112528

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

Step to reproduce issue:
- Go to sales settings, activate "Unit of Measure"
- Set user define default of field "uom_id" of model "product.template"
- install "loyalty" module.
   While loading file "addons/loyalty/data/loyalty_data.xml" file it will create product and gives traceback.
   Or
- It will also give error while upgrade database from 14.0 to 15.0 or more
Note : This error occurs while there is user-define value for uom_id is set and any module tries to
       create product from data file.

Current behavior:
- When product creates, uom_id and uom_po_id gets default uom value from
  "_get_default_uom_id" method which return "Unit" uom as default.
  But when user have default value for uom_id(let's suppose Days), it sets that default
  value and for uom_po_id we got uom value as "Unit".
- So now as uom category of Days and Unit are not same it violates "_check_uom" constraint.

Traceback: https://pad.odoo.com/p/utpr-set_default_uom



Soultion:
- When product creates, if there is default value for field uom_id in "ir.default" then
  "_get_default_uom_id" method sets same value for uom_po_id.

closes odoo/odoo#110503

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

closes odoo/odoo#103608

Signed-off-by: Nicolas Marcotte (nie) <nie@odoo.com>

Version:
- 14.0 only

The `test_confirmation_mail_free_signup` test
introduced with commit fe7cb4da
has to be patched for version 14.0.

Without the patch, the mails are deleted if they are sent without errors.
If we run the test on an instance which has a smtp server configured
the mail will be deleted and therefore the test will fail.

opw-3178901

closes odoo/odoo#112275

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

The regulation for the German tax report has changed.
We adapt it and its export to the regulation (that changed in Jan 2023)
The reference for this tax report comes from https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Steuerarten/Umsatzsteuer/2022-12-21-muster-der-vordrucke-im-umsatzsteuer-voranmeldungs-und-vorauszahlungsverfahren-fuer-das-kalenderjahr-2023.pdf?__blob=publicationFile&v=1


and from elster.de

We can see some lines are wrong.
Some categories are also not well-ordered.
Some indentation should be done better.
Some taxes had to change, as the report lines they were pointing to should not exist,
and the tax row had to be added
Some taxes should point to a tax report line when they were not.

opw-2767535
opw-2974560
task-3082233

closes odoo/odoo#108601

Related: odoo/enterprise#35210
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

before this commit, trying to cancel a picking with no move lines, will not move the picking to the cancel state.

* create a new picking
* keep move lines empty
* click on the cancel button
* picking will remain in the draft state

after this commit, on cancelling a picking with empty lines, will move the picking to the cancel state.

closes odoo/odoo#112247

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

There is a bit of a dance on the lambda function to filter the MOs
that should be autoconfirmed out of a procurement. To the point
that the logic is different in v14 and v15/16.

Refs:

- v14: https://github.com/odoo/odoo/commit/5fd6c7251331de2600eaee76114b76f535652fec
- v16: https://github.com/odoo/odoo/commit/2ab878aecb67930a9a7cd35901cb6c4b98c7e442
- v16 previous: https://github.com/odoo/odoo/commit/2b003b8d3917b45772b5f16edf21292446e96601



It would be great for partners to be able to extend it and be able
to control the logic used even if the default behavior gets changed
again.

closes odoo/odoo#111981

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

Before this commit, it was possible that a move was considered to not be merged in mrp_subcontracting action_confirm, but it was then selected as a candidate to be merged on stock _merge_moves. In that scenario, the move would be merged with another one and deleted.
As a consequence, we would end up returning a stock.move that no longer exists, raising an error message "Record does not exist or has been deleted.".

With this commit we return only the moves that still exist.

closes odoo/odoo#111969

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

This is a backward port of

* https://github.com/odoo/odoo/commit/71ef4b728ea0fd3848208f83a05915e84e862b9a



closes odoo/odoo#111668

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

What are the steps to reproduce your issue?
1/ Setup
* Create a survey with single select multi choice question
* Create a 2nd question which is also a single-select multi-choice
 question, which appears based on the answer selected for 1st question.
* Create a 3rd question which is a text question which is visible based
 on the answer to question 2.
* All 3 questions are mandatory

2/ Take the survey
* Answer 1st question in a way the 2nd question appears
* Answer 2nd question in a way 3rd one appears
* Change the answer the 1st question in a way 2nd question should not
 appear.

3/ Submit the survey

What is the current behavior that you observe?
Odoo will not allow to submit the survey as it will require an answer
for the 2nd question, even though it should not appear.

What would be your expected behavior in this case?
to be able to submit the survey.

A test tour is added to enforce this logic.

opw-3087514
Task-2987929

closes odoo/odoo#108419

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Florian Charlier <flch@odoo.com>

This commit fixes a bug where the spacing for the column
`random_questions_count` was off leading to it being way too small for edition.

Now, the column has enough space to be editable for versions 14.0 through 15.0.

task-3111647

Part of: #104135

closes odoo/odoo#108682

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

If the business is incorporated, both these fields must be present.
We don't have a field to know whether the business is incorporated,
but in any case the fields must be both present or not present.

opw-3127832

closes odoo/odoo#112052

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