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

closes odoo/odoo#121861

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

An UBL Bis 3 xml can only contain one tax per invoice line. However,
there might be one or more ecotaxes on invoice lines in Belgium. Do not
block the user from generating the attachment in this case.

Note that PR https://github.com/odoo/odoo/pull/121494

 will properly
handle the fixed taxes upon generating UBL attachments.

opw-3318969

closes odoo/odoo#121854

X-original-commit: 68814f52
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>

When passing a very large expression to `literal_eval`, the odoo server crashes.
To avoid this behavior, a limit needs to be set by using the env varaible `ODOO_LIMIT_LITEVAL_BUFFER`.
If the variable is not set, it defaults to 100Kib.

closes odoo/odoo#121719

X-original-commit: 0e4f3ac4
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Signed-off-by: Dalcq Jordan (joda) <joda@odoo.com>

Two issues solved in 1 commit; as their solutions depend on one another.

** ISSUE 1 **

To reproduce the issue, on a l10n with a tax report:
- Create a misc operation with a tax on it in the same form as a sales invoice ; post it.
- Reverse that move, and post the reverse.

=> Open the tax report: the amounts of the original move (for both tax lines and base lines) are doubled.
That's not what we want ; instead, the reverse should have entirely canceled the original move.

This is due to the fact the is_refund field of account.move.line is badly computed on the reverse: both tax and base lines are considered refund. Because of that, tax_tag_invert gets inverted, and ends up doubling the amount in the report instead of cancelling it. While made on a reverse move, those lines should not be considered as refunds, since they must both use the original repartition of the reversed move , unlike invoices, which would make use of the refund repartition in this case.

** ISSUE 2 **

To reproduce, on a l10n with a tax report:
- Create a cash basis tax, and set tags on its repartition lines so that it should be taken into account by the report. Make sure the refund repartition cancels the invoice repartition.
- Create an invoice using that tax, post it
- Click the "Add Credit Note" button, select "partial refund", and post the generated refund (which will cover the full amount of the original invoice)
- Reconcile the refund with the invoice

=> Because it's a partial refund, cash basis entries will still be generated. Open the tax report to ensure they sum up to 0... And the tax lines don't !

This happens because the computation of tax_tag_invert field inverts the sign of tag on cash basis entry tax lines when they have a negative tax_base_amount. In our case, when going through the "reverse" button and making a partial refund, we actually do get a negative amount in the credit note's tax_base_amount. This is inconsistent with what a refund generated from scratch does (then, you'll get a positive tax_base_amount in our case), and should only be legit when the document contains a negative line explicitly (so, a line with a negative quantity, hence inverting the meaning of debit/credit).

The root of the issue is that the tax_base_amount of the tax line uses the tax_tag_invert of the base line to define its sign. And tax_tag_invert was omitting to set copy=False. When reversing a move, the first step is to copy it. Because of the missing copy=False, tax_tag_invert was copied, and never recomputed (since it's a computed editable field) on the base line, giving it an inconsistent value, and ending up inverting the sign of tax_base_amount on the tax line. In turn, the tax line got a wrong tax_tag_invert because of that, and would propagate that to the cash basis entry when generating it.

This commit adds the missing copy=False to tax_tag_invert, but also fixes the computation of tax_tag_invert so that in does not rely on tax_base_amount anymore. This way, existing data will also benefit from the fix without having to recompute the field. Additionnally, there are currently plans to remove tax_base_amount in master, so this would have had to be done eventually anyway.

OPW 3255511

closes odoo/odoo#121605

Related: odoo/enterprise#41162
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

When we have automatic invoicing enabled , the email sent to the user
when he confirms his payment online will contain a button 'View Journal
Entry'

To reproduce the error :
1- Install accounting, website, ecommerce, sales apps
2- Go to website settings and activate automatic invoice
3- Install test payment method and activate it
4- Log out of the current account
5- Make a purchase of any item and confirm the payment
6- You will receive 2 emails , the second one will have the invoice and
it will contain a button View journal entry

The origin of the problem is not providing model_description when
sending the invoice so it will take the display_name of the model
'account.move' by default which is Journal entry.

opw-3271345

closes odoo/odoo#121525

X-original-commit: 8d791167
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>

When we input some string in many2many field under Coins/Bills in configuration
setting of point of sale module . it will give an error with the message -

'could not convert string to float'

Steps to Produce:-

1. Go to Point of Sale then configuration
2. click on 'Settings'
3. Under 'Payment' input some string in Coins/Bills

Trace-back will be generated.

Reason -
The 'name_create' method of the 'pos_bill' model generates an error when a
string is provided as input for the 'name' field, since the expression
'float(name)' is unable to convert a string to a float.

Applying these changes will resolve this issue.

Sentry - 4122478677

closes odoo/odoo#120207

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

Steps to reproduce:
In an account move, if the partner_id is changed to one that does not have a value assigned in the property_purchase_currency_id field and with a value in the context for default_currency_id,
when passing through the _onchange_partner_id function of the purchase module,

Cause:
the variable currency_id will take the value in the context as second option causing an error when trying to get the value in currency_id.id because currency_id will be an integer and not a record.

issue-121232

note fw 16:
The record must be saved in order to trigger the compute in
https://github.com/odoo/odoo/blob/5a256af35e5d612efed9ed8af1cf23fd62bd83f4/addons/account/models/account_move_line.py#L449-L457


in order to recompute the currency of the lines

closes odoo/odoo#121957

X-original-commit: e04d4a0b
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>

Initialize a DB. Install website when it is initialized.
Launch tests of the class TestBaseDocumentLayout

Before this commit, there was a crash because those tests render the report_layout and its
assets.

The full explanation is that, the module website adds an ir.asset `website.s_badge_000_variables_scss`
that the report wants to fetch. But, the class of tests is executed at_install. Given the topological order
and the order of the modules installation, website is not in the registry at that point, but the ir.asset is retrieved
from the database.
The ir.asset algorithm determines at that point that `/website/` is not an admissible path and raise an exception.

This commit solves the problem by tagging this class of test "post_install" and not "at_install".

runbot-error-21203
runbot-error-21204
runbot-error-21205
runbot-error-21206
runbot-error-21207
runbot-error-21208
runbot-error-21352
runbot-error-21353
runbot-error-21354
runbot-error-21355
runbot-error-21356
runbot-error-21357

closes odoo/odoo#121970

X-original-commit: 48b83351
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Steps to reproduce:

- Go to a website page > Add a 'Form' block > Set an input "Placeholder"
value.
- Go to the page (in 'edit_translations' mode) > The translation of the
input "Placeholder" attribute doesn't mark the input as translated and
even after saving the translation, the input is still marked as
"to_translate".

The goal of this commit is to fix this issue by extending the same
behaviour on the translated `<select/>` options (using `.oe_translated`
class) and setting the right translation state on the input from the
linked attribute translation `<span/>`.

task-3323245

closes odoo/odoo#121843

X-original-commit: 9276afdc
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

Before this commit:
when en_US is not activated and the user changes terms slightly for
ir.ui.view.arch, the new term will be treated as a typo fix or style change, and
won't be populated to other languages. As a result, in the form view, arch_base
field which displays the en_US translation of the arch_db will still be the
content before the change(wrong and strange).

After this commit:
when write a model_terms field when en_US is not activated, its en_US value will
always be overwritten.

opw-3265418

closes odoo/odoo#121253

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

before this commit
When users open the translation dialog for an empty field, and directly update
and save all translations in the translation dialog, nothing will be saved for
backend

after this commit:
these translations will be saved.

opw-3297748

closes odoo/odoo#121139

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

It takes 70s to generate a receipt with 2000 serial numbers.

It happens because during the first part of the loop
(model `stock.move.line` in the `create` method).
It will update the initial demand of the move based on the new
stock.move.line and their qty_done.
Writing the initial demand of the `stock.move` will try to reassign
it (useless in our case) and rewrite the same value on its state's field.
The consequence is the invalidatation of the field on
the `stock.move.line` because it's a related to the `stock.move`.
In the second part of the loop, it check the sml state. Since it
was invalidate upper, it recompute it. That prevent a correct prefetch
and cause a performance issue.

We fix it by writing only once the information by move. And it
prevent the recompute later since the state is not write during the
loop.

closes odoo/odoo#121919

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

The json fields are not supported in lists at the moment because they
require additional RPC to fetch the display value as long as its
formatting.

closes odoo/odoo#121532

Task: 3324679
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>

Current behaviour:
When activating "Prevent Sale of Zero Priced Product",
zero priced products could still be added to cart,
using the wishlist.

Expected behaviour:
Zero priced products should not be added to cart

Steps to reproduce:
1. Activate the setting "Prevent Sale of Zero Priced Product"
2. Create a product with a sales price of zero
3. Go on the product selling page, cannot be added to cart
4. Add the product to your wishlist
5. Go in the wishlist
6. The product can be added to the cart

Cause of the issue:
add_to_cart_button was overriden

Fix:
Added condition on override

opw-3283057

closes odoo/odoo#121531

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Before this PR when a demo data error occurred (and the errors is too big). You could click on the error and a form view appeared. But if the error was too big, the text for module_id and wizard_id were impacted and were way too small to be readable (like a missing colspan). By adding a form view form this specific model it seems to solve the issues.

closes odoo/odoo#117002

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

Before this commit:

When a new list is created and any list item is applied a style
like h1, bold ,itallic etc.. and when when toggle that list, the list
style breaks

After this commit:

Toggling through the list does not break the style.

closes odoo/odoo#121892

Task-id: 3269908
X-original-commit: d06e043c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

The method _assign_and_convert_leads() gets called when the CRM: Assign Leads cron is called.
The values in the list `weights` gets caluclated in a way that memebers with a lower
`lead_month`count` value gets a higher weight when randomizing assignement of a new lead. Assuming that the
max assignment per member is consistent (or default = 30).
Assume that each sale member belonging to any team has around 500 leads assigned to them the previous
month(`lead_month_count`) and `work_days` is set to `0.2`. The return value of the method
`_get_assignement_quota()` in this case would be 0 for every member, which causes the list `weights`
to get populated with just zeros. This raises a `ValueError: Total of weights must be greater than zero`.

Fix:

Make sure the minimum weight for each member is at least 1 and not 0.

opw-3171085

closes odoo/odoo#121877

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

Previously, when conducting a refund on a table, the system would
switch the active table to the table associated with the refunded
order. This was not the desired behavior, as it resulted in the details
of the order disappearing, requiring the user to navigate back to
the refund process.

Steps to reproduce the issue:

 - install PoS restaurant
 - pick a table, do an order and pay it
 - pick another table, refund
 - choose the previous order and refund
-> the order details disappear directly. You have to go back to refund.

opw-3301603

closes odoo/odoo#121351

X-original-commit: 1b28952d42c4c0830a1e9a73c6d1dd7f334e122b
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>

Before this commit: it was possible to create an event for another user as
its organizer. But even if that user has a synchronized Google calendar, it
will be sent by the current user token, and it causes several issues.

The solution is to use the event's organizer token if it exists.

opw-3076595

closes odoo/odoo#120352

X-original-commit: 96694316
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>

in 28740b11da37239953185478de9f391265db543f
we add an option for a sanboxed iframe.

This mistakenly uses `null` instead of `false` in a `t-att`.
Which sets the sandbox attribute, breaking `mass_mail`.

We replace `null` with `false`, which correctly does not add the attribute
 at all.

 task-3255777

closes odoo/odoo#121869

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

The 'insertLineBreak' case in `onInput` is dead code because any event
that might cause it (pressing Shift+Enter) first triggers `onKeydown`,
which calls `ev.preventDefault()` and thus prevents it from reaching
`onInput`.

Task-3301232

closes odoo/odoo#121827

X-original-commit: c63cd2f0
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Have a record with a field displayed with the aceField.
That field should have a value of false (ie: unset).
Display that record on a form view.

With the pager, go on to the next record.

Before this commit, a write was triggered because the aceField considered itself as changed
even though we did not do anything.
This was because the value of false was compared to the ace value (empty string) when leaving the record.
Being different, this triggered the current record to be updated and saved.

After this commit, a false value is locally transformed to the empty string when checking if the field has
some changes. Hence, there is no write triggered.

opw-3326914

closes odoo/odoo#121634

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

`tocompute` in the `Transaction` contains store field on records to
be recomputed. No-store compute fields are directly invalidated from
the cache when a dependency changes (see `BaseModel.modified`).

In fact, `_recompute_field` was actually doing too much for nothing.
Also, it may invalidate caches of compute no-store fields for no reason
(e.g., if they are searchable). Remove the part for field compute
no-store field. And prevent `_recompute_field` callers from calling it
with no-store fields.

closes odoo/odoo#121355

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

In specific situation, unlink can lead to raise a `RecursionError`:
- The model `A` has a many2one `b_id` field toward a model `B`.
This field is set with `ondelete='cascade'`.
- The model `A` has one **store** related field **no-sudo** named
`a_related` (`related='b_id.b_other_field`).
- With `ir.rule` on model `A` with a domain containing `a_related`

You have one record B `b_1` with 20 records A linked to it
(`a_1, ..., a_20`). When you try to unlink `b_1`:

Stack:

  File "...", line 543, in ...
    b_1.unlink()
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3594, in unlink
    self.env.flush_all()

=> At this point, `a_1, ..., a_20` have already been deleted from the
database because of the 'cascade' deletion. But the ORM doesn't have
any information about this, and `a_related` (for `a_1, ..., a_20`) are
flagged to be recomputed (because it depends on `b_id.b_other_field`)

  File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 732, in flush_all
    self._recompute_all()
  File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 728, in _recompute_all
    self[field.model_name]._recompute_field(field)
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6165, in _recompute_field
    field.recompute(records)
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
    self.compute_value(record)

=> `self.compute_value(recs)` raised a `MissingError` before recalling
`compute_value` with only the first `record` (but others are still in
the prefetch)

  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
    records._compute_field_value(self)

=> `a_related` of `record` is removed from to_compute, but only the
first record, not the rest of the records present in the prefetch set.

  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4194, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
    return needle(records, *args)
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
    values = [first(value[name]) for value in values]
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
    values = [first(value[name]) for value in values]
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5860, in __getitem__
    return self._fields[key].__get__(self, type(self))
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2772, in __get__
    return super().__get__(records, owner)
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
    recs._fetch_field(self)
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
    self._read(fnames)

=> `_read` tries to read the first record + others from the prefetch set

  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3215, in _read
    self.with_context(active_test=False)._flush_search([], order='id')
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4607, in _flush_search
    self.env[model_name].flush_model(field_names)
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5560, in flush_model
    self._recompute_model(fnames)
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6134, in _recompute_model
    self._recompute_field(field)

=> This is where the recursion starts, record compute will move forward
one by one. But sadly, the stack grows very fast, and with only a few
(already deleted) records to recompute, the issue will be generated.

  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6165, in _recompute_field
    field.recompute(records)
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
    self.compute_value(record)
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4194, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
    return needle(records, *args)
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
    values = [first(value[name]) for value in values]
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
    values = [first(value[name]) for value in values]
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5860, in __getitem__
    return self._fields[key].__get__(self, type(self))
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2772, in __get__
    return super().__get__(records, owner)
  File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
    recs._fetch_field(self)
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
    self._read(fnames)
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3215, in _read
    self.with_context(active_test=False)._flush_search([], order='id')
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4607, in _flush_search
    self.env[model_name].flush_model(field_names)
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5560, in flush_model
    self._recompute_model(fnames)
  File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6134, in _recompute_model
    self._recompute_field(field)

How to fix it:
Move the logic of the MissingError of `_recompute_field` inside the
`recompute` directly.

Part-of: odoo/odoo#121355

This reverts commit 9e710945.

Why?
- It is useless in 16.0, the bug it claims to fix should not exist. In the
commit explanation the sentence 'this calls `_read`, which flushes the
field we're trying to read' is wrong, since
https://github.com/odoo/odoo/pull/66938 (merged in 15.5). (It is still true
for fields that are in an ir.rule, but it sounds very unlikely to have
a recursive field in ir.rule that causes trigger the problem)
- It creates worst errors (infinite loop for recursive field computation on
missing record - Next commit).
- Also, it looks like a dangerous fix that can hide or trigger new
issues.

Part-of: odoo/odoo#121355

Current behavior:
When a product had a too long name, the name was truncated and couldn't
be completely seen.

Steps to reproduce:
- Change the name of a product to a very long name with spaces
- Open the POS
- The product name is truncated

Note:
To fix this we stop showing placeholders when a product doesn't have an
image set.

opw-3245538

closes odoo/odoo#121041

Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>

Since commit [1], the state of the editor in the html field is only set
to dirty when the user triggers an input event. This means that if the
user uses the mouse to change the content of the field (eg, drag and
dropping snippets), the editor is not marked as dirty so the save button
will not appear and autosave will not work.

This commit fixes this by checking the editor's dirty state whenever a
history step event is triggered. Since this reverts commit [1], we need
to ensure the bug it fixed does not reappear. This is done by ensuring
we don't check the saved value against the modified editing value when
it's empty (namely, the editor doesn't allow an empty string as a value
and replaces it with `<p><br></p>`, which we need to undo in
`_isDirty`).

task-3263653
task-3288416
opw-3274329

[1]: https://github.com/odoo/odoo/pull/113088/commits/095bbb93d6c3b9b0b099b7ed1a6a15e8ad914e9f



closes odoo/odoo#120593

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Before this commit:

Previously, when opening a command bar below an image such that the command bar
was on the image, clicking on the command bar would select both the command bar
option and the image.

After this commit:

Clicking on the command bar no longer selects the image when it is beneath the
command bar.

Task - 3126311

closes odoo/odoo#118593

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

For performance reasons, instead of extracting the whole
zip, extract only the files which are actually used
during in the `_import_module`, in case people
put additional crap in the archive which are ignored
during the import. That way, we avoid useless I/O.

Also, adding the temporary directory in the addons
path wasn't thread-safe.
This revision changes this to make the module
import feature thread-safe.

closes odoo/odoo#80120

Signed-off-by: Pierre Masereel <pim@odoo.com>

The function `drop_view_if_exists` only works when the view in question is a regular view, [materialized views](https://www.postgresql.org/docs/current/rules-materializedviews.html

) need a special syntax to be dropped (with an additional `MATERIALIZED` flag).

This is an issue when e.g. needing to replace standard views with materialized views for performance reasons, as dropping the views now fails.

Check the table kind beforehand and dispatch to the correct query.

closes odoo/odoo#121675

Forward-port-of: odoo/odoo#117424
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Steps to reproduce:
-------------------
We google calendar, create a recurring event with
three occurrences.
We obtain 3 events in chronological order:
- A
- B
- C
Change the title of the event B and apply the changes
to the following events.
We get:
- A: First title
- B: Second title
- C: Second title
Modify the schedule of event C and apply the changes
only to this event.
We get:
- A: First title + First schedule
- B: Second title + First schedule
- C: Second title + Second schedule
Synchronize Google calendar with Odoo.

Issue:
------
Event C is "duplicated".
Event C will exist with the first schedule
and the second schedule.

Cause:
------
A recurrent event with `google_id` is equal to
`ID_RANGE_TIMESTAMP` can be rescheduled.
If this is the case, its `google_id`
will be equal to `ID_TIMESTAMP`.

We do not manage the deletion of the event
that belongs to the old `google id`.

Solution:
---------
When we detect a recurring event with
a modified schedule, we have to delete the event
from the old `google_id`
(which is the event with the old schedule).

For this, it is necessary to find
the old `google_id` based on the elements contained
in the `id` and the `recurringEventId` of the event.

opw-3143680

closes odoo/odoo#121677

X-original-commit: 3f145af0
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>

The analytic_distribution component used an extension of the AutoComplete component for 2 reasons.
1. to get access to the focus event
2. to stop propogation of the autocomplete input click (which prevented the analytic popup from functioning well)

The need for the focus event was removed, and it doesn't make sense to maintain an extension to simply stop event propogation. For this reason, the extension was removed, and the `.stop` is added directly to the AutoComplete

Part of task-3180055

closes odoo/odoo#115504

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

Allow users to find analytic accounts in the analytic widget if there are more than 7 results for their search criteria, by providing a Search More option.

Additional Enhancements include:
- remove the 'Add a Line' button. replace with an empty tag (no analytic account, remainder of distribution)
- remove the custom AutoComplete. this was used to set the active group on autoComplete focus, and to prevent propogation of click events.
- no longer keep track of the active group (editing plan). Instead pass the group (plan id) to the relevant functions.
- rename variables, for example request > searchTerm
- keep the header of the popup in place (no scroll when there are many tags)
- test the widget in list view (with the search more feature)
- add a new analytic account list view, as users should not multi-edit in the search more dialog

Current behavior before PR:
Users were forced to type the entire analytic account name if they had many analytic accounts with similar names.

Desired behavior after PR is merged:
A "Search More" option is added to the Autocomplete options when there are more than 6 analytic accounts found. The Search More option provides a SelectCreate Dialog where users are able to find the required analytic account easily. Users are able to select multiple accounts by checking the items in the list.

Task-3180055

Part-of: odoo/odoo#115504

Current behaviour:
When the language is not set on the user date_format value
is False so when opening project tasks we get the following traceback

Error:
Odoo Server Error

Traceback (most recent call last):
  File '/Users/nea/src/odoo/odoo/addons/base/models/ir_http.py', line 237, in _dispatch
    result = request.dispatch()
        ....
  File '/Users/nea/src/odoo/addons/project/models/project.py', line 798, in _compute_recurrence_message
    task.recurrence_message += '<li>%s</li>' % date.strftime(date_format)
Exception

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File '/Users/nea/src/odoo/odoo/http.py', line 650, in _handle_exception
    return super(JsonRequest, self)._handle_exception(exception)
  File '/Users/nea/src/odoo/odoo/http.py', line 317, in _handle_exception
    raise exception.with_traceback(None) from new_cause
TypeError: strftime() argument 1 must be str, not bool

Expected behaviour:
- Open projects tasks with no problem

Fix:
- to fix the problem we use get_lang() to retrieve the language object for the current use

Affected versions:
- 14.0
- 15.0
- 16.0
- master

opw-3301081

closes odoo/odoo#121774

X-original-commit: 6d1b4bd96ffbb43c0e2397f89d5594c0bcd4e1e7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: nea@odoo.com <nea@odoo.com>

[FIX] stock: _log_less_quantities_than_expected call _log_activity_get_documents with empty dict and raises error

closes odoo/odoo#121691

X-original-commit: c62bd8b3
Signed-off-by: Tiffany Chang <tic@odoo.com>

Steps to Reproduce Issue for single picking:
1. Install Sales, Inventory
2. Create an SO and confirm
3. Go to the transfer, assign the done value to be less than demanded
4. Validate the transfer and cancel the backorder

Current Behavior:
There is no exception error on the SO chatter

Expected Behavior:
An exception error should be logged on the SO chatter

Other Info: When cancelling a backorder for a single picking,
the exception error about less quantity than expected is not logged on the SO.
"process_cancel_backorder" does not call _log_less_quantities_than_expected.
As defined in "process", the exception is only logged when validating multiple pickings at once but
one is to backorder but the other is not.

opw-3222508

X-original-commit: a1dfc58eebd1badc3eea501b23861748b3762d75
Part-of: odoo/odoo#121691

When a new user is created from the website, the company id was always
set to the first company of the database even if the website was the one
of another company. This flow has been already fixed if there is the
"Specific User Account" setting activated (see [this other commit]).
This commit fixes the same issue but for every case.

Steps to reproduce the issue:
- Create 2 companies A & B
- For each company, create a website linked to a different URL
- Activate 'Free sign up' for company B
- As a public user, go to website of company B
- Go to 'Sign in > Don't have an account?' and create an account

=> If as an admin you check the company of the created user, it is
company A instead of company B.

[this other commit]: https://github.com/odoo/odoo/commit/77c708c516beb322df37220634e178ba82e894c9



task-3277317

closes odoo/odoo#121558

X-original-commit: eda9ad14
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Bug:
Currently, trying to import a fatturapa XML that has a document discount
doesn't do anything.

Setup:
- install l10n_it_edi and account_accountant
- have a fatturapa XML that has a document discount

Steps to reproduce:
- switch to the Italian company ()
- make sure that the VAT number on the document matches the one on the
  company
- attempt to upload the XML bill

You should be met with an empty vendor bill page.

Cause:
The issue comes from here: https://github.com/odoo/odoo/blob/43c9820b1d3020d89b1b7ca016754e29d1fc6b58/addons/l10n_it_edi/models/account_edi_format.py#LL725C21-L729C83


in 16.0, `invoice_form` is not an instance of `Form`, but a record.

opw-3193634

closes odoo/odoo#121010

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

As it holds full HTML documents, mail.mail often encounters issues with
the html editor.

We piggy-back off the intoduction of the switching
behavior between code-view and readonly-view behavior introduced in
a5c0085ce91570c6c961e3293dfe50f4faba6043

The 'sandboxed preview' mode can now be enabled with an option
and will ensure all content can only be viewed in a sandboxed iframe
or in the code editor.

This re-introduces editing, which was mistakenly fully disabled in the
usability fix that introduced body_content here:
5055b374

Some tests are added to ensure the key points of this commit remain
the same. Tests are re-ordered alphabetically to match the order
of execution, making debugging easier.

task-3255777

closes odoo/odoo#118423

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>