To reproduce the issue:
(Need `stock_barcode` and a real barcode scanner)
1. Create two products P01 and P02, each one with a barcode
2. Barcode > Operations > Receipts, Create
3. Scan P01
4. Scan P02
5. Click on the `+1` button on the line of P01
6. Scan P02

Error: Both lines are incremented. Scanning P01 should not impact the
quantity of P01

Because of step 5, the focus is still on that button when scanning
again P02 (step 6). Moreover, the scanner ends the barcode transmission
of P02 with an `enter` -> it will generate an event on the `+1` button,
which explains why the quantity of P01 is also incremented.

OPW-3232437

closes odoo/odoo#122125

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

Numbers should be alinged on the right in rtl langauge same as ltr langs

Steps to reproduce the isse :
1- Change the language to arabic
2- To to the list of invoices in accounting and you can see that the numbers are aligned to the left

The origin of the problem is that rtlcss reverse the alignment from right to left

opw-3295573

closes odoo/odoo#121689

Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

The discuss app uses an url regex in order to find links and
transform them to html before posting a message.

Before this commit, some unsafe url characters  were missing
from this regex, resulting in incorrectly parsed url.

This commit adds missing characters in order to match RFC1738
[1].

[1]: https://www.ietf.org/rfc/rfc1738.txt



closes odoo/odoo#122093

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

closes odoo/odoo#122042

Related: odoo/enterprise#41329
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Before this commit, trying to access "My Time Off" was
not possible if connected on a company while some leaves
were created from another company.
This commit restricts that view to the leave created from
the companies the user is logged into.

closes odoo/odoo#122039

Signed-off-by: Gvaladze Sopiko (sgv) <sgv@odoo.com>

Before this PR:
The only way to neutralize the database is running cli command neutralize

After this PR:
There is a new checkbox "neutralize database" in Duplicate database and Restore database dialog that neutralize the database after duplication/restore.
I also moved the neutralization code to the external module so it can be called also outside the cli .

closes odoo/odoo#121569

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

Currently, if you use the automatic entry wizard to change the period of
a journal item dated prior to the lock date, you'll just get blocked
with a UserError, with no workaround.

This commit changes the date of the adjustment entry to be the first end
of month after the lock date. As a result, the adjustment entry can be
created.

Based on PR #92439

closes odoo/odoo#121566

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

At the moment, the lock date message is generated in
_compute_tax_lock_date_message. We delegate it to a separate function
in order to use this message elsewhere as well.

Note: this refactor introduces minor changes in behaviour:
- we remove the second part of the lock date message (that mentions
  other lock dates than the most blocking one), because it is too much
  information.

- we calculate the new accounting date from the existing accounting date
  rather than from the existing invoice date. This should not change
  anything in practice, since the new accounting date will be the last
  day of the period after the lock date.

task-2823170

Part-of: odoo/odoo#121566

Current behaviour:
If we add a blockquote in the `website_description` of a product on
the e-shop, we cannot checkout the product. Silent HTTP 400 error
code, due to an exception raised by
https://github.com/odoo/odoo/blob/bf772181933ce5334da35c8368455963b2478399/odoo/fields.py#L1987-L1993



Expected behaviour:
You should be able to checkout products even if they have blockquote
in their `website_description`.

Steps to reproduce:
- Install eCommerce, sale_quotation_builder (issue is present only
  after installing sale_quotation_builder)
- On a product, with the website editor, add a `blockquote` to the
  description of the product > Save
- In a private browser window, as public user, visit the product on
  the e-shop and try to checkout with it.
- Observe there is no visible error, and we do not proceed in the
  checkout process.

Reason for the problem:
The exception mentioned above is triggered when there is a
difference between the html content that is saved in the DB and after
sanitization, meaning that someone with escalated privilege saved
the HTML content by overriding the sanitization with
`sanitize_overridable`. In our use case the only diff is the
presence of the attribute `data-o-mail-quote-node` which is removed
after the sanitization.

Fix:
This issue can be resolved two ways:
1) Adding `data-o-mail-quote-node` to the list of save attributes,
   meaning it will not be removed during the sanitization process.
   Since this is an attribute that we add on `<blockquote>` nodes,
   it can be considered safe, just like `data-o-mail-quote`.
2) Remove the attribute sanitization of the `website_description`,
   just like it is done in the website_sale module.
   Since the `website_description` and `quotation_description` are both
   computed from one-another, they should have the same sanitization
   level.
I am implementing both solutions, 1) because adding the attribute to
the safe list seems safe in general, and may prevent future
issues of this sort. 2) because it is the root cause of the issue,
since the bug is present only after installation of the
`sale_quotation_builder` module.

Affected versions:
- 16.0
- saas-16.1
- saas-16.2
- master

opw-3297237

closes odoo/odoo#120764

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

In Knowledge, the scrollParent for the `Y` axis of an embedded ungrouped Kanban
view is the article body, which contains the draggable `container` (which is
itself contained in the scrollParent for the `X` axis).

This commit introduce 2 fixes related to the `draggable_hook_builder`:
- In `draggable_hook_builder`, `updateRects` was modifying values of the
  `containerRect` from values of the `scrollParent`. Then, the `containerRect`
  was used in `handleEdgeScrolling` to compute a scroll value to apply on the
  `scrollParent`, and when updating the dragged element position, to compute the
  boundaries for the dragged element. This commit stores values for
  `scrollParent` in `scrollParentRect` alongside the modified `containerRect`.
  `scrollParentRect` will be used to compute the scroll value based only on the
  dimensions of the scrollParent, and the modified `containerRect` will be used
  to compute the boundaries.
- The `scrollParent` in the `X` axis can be different from the `scrollParent` in
  the `Y` axis. This commit stores both of them individually so that one is not
  neglected when higher in the DOM than the other.

Task-3291771

closes odoo/odoo#121089

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

Some tests use methods that have two different implementations (one for
desktop and one for mobile). So far, the only example is deleteBackward
and its mobile counterpart deleteBackwardMobile.

This commit introduces a mechanism in the web_editor tests to avoid
duplicating such tests. When a test calls a method that has two
implementations, it uses the desktop one by default and a flag is set
that indicates the test should be re-run with its mobile implementation
next.

When errors are raised while the mobile version is in use, we prefix
their message with '[MOBILE VERSION]' to ease debugging.

Note that this mechanism relies on proper flag management by the
aforementioned methods.

Task-3054808

closes odoo/odoo#121977

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

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>