In v17.0, the test TestUiPublisher.test_course_publisher_elearning_manager of website_slides fails randomly at the step: "eLearning: check uploaded pdf presence and perform comparison" with the error: "Cannot read properties of null (reading 'getAttribute')"

How to reproduce it ?
Locally, TestUiPublisher.test_course_publisher_elearning_manager of website_slides runs without errors but when executing it in the browser we get the same error as the runbot systematically:
–	Install website_slides
–	Go to shell mode and execute the setup of the test –	(Backup DB if you want to run the test multiple time) –	Launch in normal mode and connect with demo user –	Go to URL: /web?debug=assets%2Ctests
–	Type “odoo.startTour('course_publisher_standard');” in the console –	An error happens at step “eLearning: check uploaded pdf presence and perform comparison”: Cannot read properties of null (reading 'getAttribute') (to avoid to wait too long, you can shorten the test by keeping mostly “addPdfToSection”)

The problem occurs because the rendering of the iframe o_wslides_iframe_viewer is not always completed when the check is triggered. We solve this problem by waiting for the rendering to finish before performing the test (using "await contains"). For safety, we do the same for another check as this might cause a similar problem in the future.

Although the test has been introduced in 16.2 (see odoo/odoo#117293) but the error happens only in 17.0 (tested only in 16.4 the way described above), we publish only the correction in 17.0 and further to avoid different correction in various version.

Task-3623736

**Before this commit:**
If you select more than one trigger field on base.automation:
```

File "/home/odoo/src/odoo/17.0/addons/base_automation/models/base_automation.py", line 302, in _compute_trg_field_ref__model_and_display_names relation = automation.trigger_field_ids.relation
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1146, in __get__ record.ensure_one()
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 5819, in ensure_one raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: ir.model.fields(<NewId origin=3241>, <NewId origin=3238>)
```

**After this commit:**
`trg_field_ref_model_name` and `trg_field_ref_display_name` are only used for the `base_automation_trigger_reference` widget, which is only used when `trigger in ['on_stage_set', 'on_tag_set']`. We only need to compute them in this case, which will be OK since they use only one trigger field.

opw-3607314

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

When a user creates a journal entry in accounting and the company is empty or
 not selected in that journal entry, an error is generated.

step to reproduce -
-  install the `Invoicing` & `Inventory`.
- open the `Invoicing`.
- create New.
- open  `other info` note page > company (compnay_id) must be empty.
- the error will be generated.

sentry traceback-
```KeyError: <NewId origin=15>
  File "odoo/api.py", line 965, in get
    cache_value = field_cache[record._ids[0]]
CacheMiss: 'account.move(<NewId origin=15>,).tax_lock_date_message'
  File "odoo/fields.py", line 1160, in __get__
    value = env.cache.get(record, self)
  File "odoo/api.py", line 972, in get
    raise CacheMiss(record, field)
ValueError: not enough values to unpack (expected 1, got 0)
  File "odoo/models.py", line 5457, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: res.company()
  File "odoo/http.py", line 2139, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1715, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1742, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1943, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 717, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 30, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 26, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 466, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 453, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "addons/account/models/account_move.py", line 2564, in onchange
    return super().onchange(values, field_name, field_onchange)
  File "odoo/models.py", line 6781, in onchange
    todo = [
  File "odoo/models.py", line 6784, in <listcomp>
    if name not in done and snapshot0.has_changed(name)
  File "odoo/models.py", line 6584, in has_changed
    return self[name] != record[name]
  File "odoo/models.py", line 6211, in __getitem__
    return self._fields[key].__get__(self, type(self))
  File "odoo/fields.py", line 1211, in __get__
    self.compute_value(recs)
  File "odoo/fields.py", line 1389, in compute_value
    records._compute_field_value(self)
  File "addons/mail/models/mail_thread.py", line 395, in _compute_field_value
    return super()._compute_field_value(field)
  File "odoo/models.py", line 4553, in _compute_field_value
    fields.determine(field.compute, self)
  File "odoo/fields.py", line 101, in determine
    return needle(*args)
  File "addons/account/models/account_move.py", line 1421, in _compute_tax_lock_date_message
    move.tax_lock_date_message = move._get_lock_date_message(accounting_date, affects_tax_report)
  File "addons/account/models/account_move.py", line 4307, in _get_lock_date_message
    lock_dates = self._get_violated_lock_dates(invoice_date, has_tax)
  File "addons/account/models/account_move.py", line 4298, in _get_violated_lock_dates
    return self.company_id._get_violated_lock_dates(invoice_date, has_tax)
  File "addons/account/models/company.py", line 358, in _get_violated_lock_dates
    self.ensure_one()
  File "odoo/models.py", line 5460, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

If the user attempts to remove the company after this commit, they get a 
validation error.

sentry-4558397052

Forward-Port-Of: odoo/odoo#144775
Forward-Port-Of: odoo/odoo#139328

## Issue
When using the command palette to assign an user to a task, a "spinning wheel" animation may show up even when everything seems to have been loaded.

## Steps to reproduce
- Install Project
- For testing, add a `time.sleep(5)` in the `_name_search` of `'res.users'` to simulate a slow `name_search` (instead of populating).
- Open your browser's networking tab.
- Open a form view of a task, press Ctrl+K, Alt+I
- Start typing an user name
- Notice that all `name_search` requests are being processed, even if only the results of the last one are used. You may also notice the loading animation on the client.

## Cause
When using the cmd palette, when typing an user name, we are sending RPC requests to the `name_search` of the `'res.users'` model. The issue is that the requests are not aborted when it is superseded by a new search value. This can lead to issues in a large database where short search strings matches too many records, therefor is generally slow. This can confuse the end user, as a "spinning wheel" can show up, but the result are already present (because a subsequent request gave back results faster than the previous request, which is often the case because a more elaborate search value matches less records, therefor is faster for the DB to process). This use case also hogs workers uselessly for results that are going to be ignored.

## Fix
Store the last running RPC and abort it when making a subsequent call to it with new search values and the request hadn't complete.

## Affected versions
16.0 up to master = saas-17.1

## Reference
task-3532458

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

Forward-Port-Of: odoo/odoo#144798
Forward-Port-Of: odoo/odoo#144617

The `noCheck` param of the `_computeSelectorFunctions` function should
permit to ignore the (not)editable environment. However, since
[this first commit] the `o_editable_media` class alter the behavior
despite the `noCheck` param which is not what we want. Even worse,
[this second commit] check the `o_not_editable` class and the
contenteditable attribute despite the `noCheck` param. This commit fixes
that by restoring the original behavior of the `noCheck` param.

---

In the past, it was possible to drop elements in non-editable areas.
Commit [1] fixed the issue but then commit [2] added a solution to be
able to edit a media element that is in a `o_not_editable` environment.
Unfortunately, the solution makes it possible to drop elements next to
the `o_editable_media` elements ignoring the editable context (ignoring
the first fix).

Steps to reproduce the issue:
- Enter website edit mode
- Drop a Team block in a page

=> The user is able to drop a "Text highlight" block next to the team
member pictures.

This commit
- reverts the commit [1] because in the meantime, the commit [3] fixed
the issue.
- fixes the Team block issue.
- fixes the filterFunc for the drop-in.
- adds a test to ensure the issue doesn't come back.

opw-3536227

[1]: https://github.com/odoo/odoo/commit/67924648676b37898aedd86bc32868299aee542c
[2]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[3]: https://github.com/odoo/odoo/commit/ae7452f18dbd6ed56dbf883ae8495382b336aa78
[this first commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904
[this second commit]: https://github.com/odoo/odoo/commit/56e75ed063b0ae98b9824c0ba00633e529701242

Forward-Port-Of: odoo/odoo#144025
Forward-Port-Of: odoo/odoo#141962

Steps to reproduce:
-------------------
- create a promotion program with the type "Discount code";
- add a rule to trigger the promotion with the code "12345";
- add two rewards;
- go to ecommerce and create a cart;
- apply the promo code.

Issue:
------
It is not possible to claim a reward.

Cause:
------
When we apply the code "12345", we call the `pricelist` method, which will try to apply the code.
If it's not a coupon and it's not nominative, we create a loyalty card (a coupon) with a default code (for example: "044d-3364-42d0"). This previously created loyalty card is linked to the current sale order, which is only fair since we don't want to be able to apply it a second time.

The two rewards are linked to the same coupon and therefore have the same code (which is right because we can apply only one of these rewards).

This problem doesn't occur with a single reward, because when only one reward is detected, we automatically apply it when we call the `pricelist` method.

In the case of two rewards, it is possible to select the reward. This will trigger the `claim_reward` method.
In this method, if we use a coupon with a code (which is the case here, "044d-3364-42d0"), we call the `pricelist` method with this code.
This will trigger an error, as the code is already in use with the loyalty card linked to the sale order.

Solution:
---------
When claiming a reward generated by a program of the `promo_code` type, i.e. in the case of more than a rewards,
don't call the `pricelist` method (which triggers an error due to the code) but `_apply_reward`. This will apply the reward to the sale order.
A redirect will be use which will remove all "claimable and showable rewards" from this program. If we want to re-trigger it via code "12345", this will no longer be possible.

Note:
-----
Modification of the view to distinguish between coupons and "Discount Code" programs. The current display suggests that rewards are coupons (with the same code) that we use, whereas they are rewards that we can claim.
Furthermore, there's no description of the rewards.

opw-3520137

Forward-Port-Of: odoo/odoo#143925
Forward-Port-Of: odoo/odoo#138906