data creation is faster when done through a CSV file than an XML file, hence doing it through a CSV

was task# 1909961

closes odoo/odoo#28878

data creation is faster when done through a CSV file than an XML file, hence doing it through a CSV

was task# 1909961

closes odoo/odoo#28876

- data creation is faster when done through a CSV file than an XML file, hence doing it through a CSV
- also, created account_tax_template_data.xml file and moved account.account.tag and account.tax.template data in that file from l10n_syscohada_chart_data.xml file

was task# 1909961

closes odoo/odoo#28875

data creation is faster when done through a CSV file than an XML file. Hence doing it through a CSV.

was task# 1909961

closes odoo/odoo#28874

data creation is faster when done through a CSV file than an XML file. Hence doing it through a CSV

was task# 1909961

closes odoo/odoo#28873

data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV

was task# 1909961

closes odoo/odoo#28860

data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV

was task# 1909961

data creation is faster when done through a CSV file compared to an XML file. Hence doing it through a CSV

This commit is related to task_id : 1909961.

closes odoo/odoo#28871

The onchange on serial number aims to track any duplicates. The issue
comes from the fact that `.mapped()` removes the duplicates when it
returns a recordset. We use a list comprehension instead.

Opw : 1910963

closes odoo/odoo#30913

Before this commit, when creating a partner automatically when creating
a message with a template, the company on the partner was wrongly set

After this commit, we try to retrieve the company from the model on the template

OPW 1934392

closes odoo/odoo#30893

Make a return on a pos_order. A new pos_order is created.
On the latter, remove a pos_orde_line.

Before this commit, there was a traceback, due to a KeyError
It was introduced by 5f6a4912
which intended to optimize migration process

We keep the logic of that commit here, in a new helper method
while restoring the original onchange,
since it wasn't compliant with onchange specs

OPW 1934129

closes odoo/odoo#30897

The feature introduced with https://github.com/odoo/odoo/commit/67d1173bf381befc136d840e232514c2c9ef7e1b
was broken by https://github.com/odoo/odoo/commit/b78b9c87c95acdf6fcf4f4eb3a80efa0e90eae09#diff-2d8ecbf95567bb339109e9552cbc68a3
because a class was removed by mistake.

This commit does not reintroduce the class so that no view is modified
in stable versions but rather review the JS to target the same button
another way.

Bug revealed while working on https://github.com/odoo/odoo/pull/29442

closes odoo/odoo#30896

- When merging leads that creates a partner, an error could be thrown
  due to the `res.partner` `default_get` method that reads values from the
  lead that creates the partner.
  The issue is due to the fact that the `crm.lead` record is merged (and
  unlinked), trying to read it will cause an error since the records
  doesn't exists anymore.

  This fix checks that the `crm.lead` we are trying to read from exists.

closes odoo/odoo#30895

The library moment.js does not support custom date formats anymore.
The following warning is given:
Deprecation warning: value provided is not in a recognized ISO format.
As a result, the moment contains 'Invalid Date',
which would remove possibility to complete a survey containing a date
in any format different than the default.

opw 1930152

closes odoo/odoo#30894

For many2one fields, 'default_get' only returns the id, whereas
'onchange' (like 'read') returns an array with id and display_name.

Before this rev., when creating a new record, we always called
'name_get' for all many2ones, whether or not their value was
obtained by 'default_get' or 'onchange', i.e. even if their
display_name was already known.

It may just look like unnecessary RPCs, but those RPCs could
actually cause a crash when the user has access to the main model
(and thus can access the display_name of the many2one thanks to
related sudo), but doesn't have access to the many2one comodel.

closes odoo/odoo#30892

In the overrides of _name_search we should avoid creating domains with
huge lists of ids as it is inefficient.
We can also make sure that we optimize the empty search as in this case
the custom domain doesn't make sense, we can simply search on an empty
domain and, thanks to the limit argument, still keep a fast query.

Linked to task 1918906

Thanks to @odony and @nseinlet

closes odoo/odoo#30155

closes odoo/odoo#30887

Fine-tuning of commit 50217184
The selection of the cart recovery mail template would fail if there was more
than one sale order selected.

opw 1921714

closes odoo/odoo#30885

When editing a record, if it cannot be saved (b.e. due to required
fields) and the user clicks on save, then on discard

Before this fix, the window did nothing (seems like it is unresponsive)

After this fix, the user is able to discard the form.

task-id: 1937142

closes odoo/odoo#30871

When the edit mode is entered, some elements receive
data-editor-message attributes. These were not removed on save which
could in some cases make the attributes be saved in the database. For
this to happen it would require an `.oe_structure.oe_empty` element to
be put *inside* an editable element (instead of being the one which is
editable). In that case the `.oe_structure` content would be saved in an
inheriting view but the parent view would also be COW'd for no reason
because of that attribute.

Difficult to say if such a case exist in the current views but as it
technically possible and that some of our tests use that configuration,
it is worth fixing.
Note: this fix was in fact done in the new editor in master and allowed
to detect that one of our test was not testing a feature correctly
because of that. This will be adapted in a different commit of this PR.

closes odoo/odoo#30834

Commit https://github.com/odoo/odoo/commit/29075a8e2c734624cec4f6009185616634f70dea
was written while there was an incorrect behavior related to
multi-website, oe_structure_ID and edit mode in a rare specific case
(see the second commit from this PR for detailed explanation
https://github.com/odoo/odoo/pull/30834).

That rare case was detected in 12.0 since the tour did not work on
master with the new editor (that fixed the incorrect behavior).
Basically, it was COWing the edited view even if only an oe_structure_ID
was touched.

Indeed, when saving a specific view in the HTML editor, we should also
search for its possible new ID as it could change if we also edited its
generic parent. In that case, the view will be copied and then unlinked
to preserve inherit order on the new specific tree.

Previously, it was only possible to make a return in
- the location the move was coming
- a return location that is child of the parent_location, actually
  meaning a return location in the warehouse

This commit now allows making return in all return location, even one
located in another warehouses.

closes odoo/odoo#30836

Before this commit, the email aliases on hr.jobs did not take into
account the department.
Hence, when receiving an email for an applicant through an alias,
the object applicant was created in the wrong company

after this commit, the alias is created with the right values, and the
applicant is created in the right company and department

OPW 1920085

closes odoo/odoo#30818

Go on the crm activity view
Have your user operate in another language than en_US

Bafore this commit, the activity types were not translated
This was because the context was not passed to the function

After this commit, the terms are translated

OPW 1924232

closes odoo/odoo#30837

Before this commit, an empty block "email" was displayed when not in debug mode
Move the group to upper level

closes odoo/odoo#30761

This is a regression from: 10f0766b. In it the visual side was solved,
but unexpectedly the functional side still worked on unescaped content.

Thus visually a @partnèr could be seen as a link, but it was no anymore
added as follower.

Without change, modified test fails with:

 mentioned partners are sent to server (expected: [1], result: [])

note: change is partial backport of 12.2 e2f20ffa

opw-1931247
closes #30846

- Create a SO with 2 lines of the same product (set route as Drop Ship)
- At validation, both lines are merged into a single line in the PO

As a result, one SO line will be over-delivered, and the other
under-delivered.

Two lines should be kept in the PO.

opw-1928702

closes odoo/odoo#30800

Purpose
=======

A date field not marked as "mandatory" could not be left blank in the survey.

That was caused by the form returning "Invalid date" instead of an
empty value when submitting.

closes odoo/odoo#30788

The purpose is, prevent the linebreak in the phone when using the
document layouts 'background' in the footer.

opw-1920752

closes odoo/odoo#30812

When creating a leave, we usually check/create activities for the
concerned users, this is fine when creating one leave.
However it starts to become a problem when trying to create leaves in
batch using the by company or by department holiday_type as the number
of leaves created in batch can become quite big.

Now when we create leaves in batch, we do not check for the activities,
which will fasten a lot the creation.

Another problem is that when someone defined a leave on the very day you
want to create such a request, then it will crash, this can lead to
waste of time and resources.

Now we raise an error before trying to create the leaves in case of
conflict.

NB: Tested with +- 320 records, took 20 seconds instead of more than 10 minutes.

Task: 1934383

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#30625

going from 3X seconds for 320 leaves to 20 seconds for 320 leaves

When creating a leave, we usually check/create activities for the
concerned users, this is fine when creating one leave.
However it starts to become a problem when trying to create leaves in
batch using the by company or by department holiday_type as the number
of leaves created in batch can become quite big.

Now when we create leaves in batch, we do not check for the activities,
which will fasten a lot the creation.

Another problem is that when someone defined a leave on the very day you
want to create such a request, then it will crash, this can lead to
waste of time and resources.

Now we raise an error before trying to create the leaves in case of
conflict.

Task: 1934383

When uninstalling a module, the messages linked to the records
of that module are not deleted leading to ghost messages when
reinstalling the module.

This is due to the lack of foreign keys in the definition of the
chatter making it impossible to cascade delete.

opw-1928208

closes odoo/odoo#30798

Activate multi-company, deactivate the common contact book.
Create a PO P with user U1 in company A. Switch to company B.
User U2 in company A tries to send P by email.
Rendering of the template fails, because it tries to access object.create_uid,
which breaks multi-company record rules.

We add a sudo in the template so that it works as intended.

opw 1930521

closes odoo/odoo#30789

Was with a lowercase S while it should be uppercase

closes odoo/odoo#30814