When user tries to close chat window  when current channels/members
 are deleted.

Steps to reproduce error:
- Activate 'im_livechat' and 'website' module
- Open the 'website' module and clicked Contact us menu
- Open chat-bot and start conversation
- Duplicate the tab and Go to the Settings>Technical>Channels/Members in second tab
- Delete the current channels/members from second tab
- Go to the first tab and close chat window
- Error will be generated

sentry traceback-

```ValueError: not enough values to unpack (expected 1, got 0)
  File "odoo/models.py", line 5830, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: discuss.channel.member()
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, 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 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1960, 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 207, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 722, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/mail/models/discuss/mail_guest.py", line 40, in wrapper
    return func(self, *args, **kwargs)
  File "addons/im_livechat/controllers/main.py", line 286, in visitor_leave_session
    member.sudo()._rtc_leave_call()
  File "addons/mail/models/discuss/discuss_channel_member.py", line 297, in _rtc_leave_call
    self.ensure_one()
  File "odoo/models.py", line 5833, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
```

Here at [1] member got empty value when current channels/members  are deleted from  'discuss.channel.member' model by user.

This commit resolved the above issue by calling  '_rtc_leave_call()' method when a member is available.

[1]-https://github.com/odoo/odoo/blob/952ebac37dc65b3fd62ae211cee1fd45fa63cd47/addons/im_livechat/controllers/main.py#L284-L286

sentry-4719812967






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

On some DB, it is not possible to update some modules that depend on
`account`

To reproduce the issue:
1. Checkout before [1] and install `account_accountant`
2. Checkout after [1]
3. Update `account_accountant`

Error: a server error is displayed

> Field 'code' used in domain of field 'payment_acquirer_id' ([
> ('provider', '=', code)]) must be present in view but is missing."")

Commit [1] contains unstable changes: it adds a domain on the field
`payment_acquirer_id` of `account.payment.method.line` and, to make
it work, it also adds the needed field `code` on the view
`view_account_journal_form`. But, if the view is not updated on an
existing database, the domain can not work, hence the client error.

This explains why the above use case does not work:
The module `account_accountant` has a view that also inherits the
view of account `account.view_account_journal_form`. As a result,
when updating the module (and, therefore, the view of
`account_accountant`), we `:View._validate_view` the whole view, which
will lead to:
https://github.com/odoo/odoo/blob/2cbf9d840b79520854731fd6a23431c69e451775/odoo/addons/base/models/ir_ui_view.py#L2282-L2286

[1] https://github.com/odoo-dev/odoo/commit/88782d3a76fb3941b9ed7d998ec0610aa26ff611

opw-3993709
opw-3993707
sentry-5416409171

Forward-Port-Of: odoo/odoo#170212
Forward-Port-Of: odoo/odoo#169978

Currently when applying a coupon for 10% on the order on the current order, the points awarded are 100% of the points instead of 90%. The loyalty program rewarding x points per $ spent.

The same behavior is also observed in the sale worflow.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** App
* Open shop session
* Select a customer
* Add a product (ex. Office chair 70$)
* Select **Enter Code**
* Enter the code `10pc`
> Observation: The order will grant 700 points instead of 630. The amount paid is 63$ with the code for 10% on the order.

Settings of the **Discount & Loyalties**:
* **Code for 10% on orders**
  * Rule: 
    * `Among` -> no restriction set 
    * `Minimum quantity`: 1 
    * `Minimum Purchase`: 0
  * Reward:
    * `Discount`: 10% `on` order
* **Loyalty Program**
  * `Use points on`: Current & Future orders
  * Rule:
    * `Among` -> no restriction set
    * `Minimum quantity`: 1 
    * `Minimum Purchase`: 0 
    * `Grant` 10 loyalty poins per $ spent

Idea of the fix
---------------
As discussed with DALA, discount should count toward points awarded. Here is how it should apply:
* If program_rule has no domain, all lines should count (except ewallet & gift cards)
* If program_rule has a domain, we should use all the lines where the product matches the domain (except ewallet & gift cards)

This applies for the computation of points based on the money spent.

Why the fix:
------------
https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L917

Sale-wise, we replace `rule_products` with `so_products_per_rule.get(rule, [])`. We also replace `order_lines` by `lines_per_rule`.
* `rule_products` don't include discounts as they are computed on `order_lines` (all lines that are not reward lines). https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L834-L841 https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L889
* `so_products_per_rule` will include the discounts if they match with the program's domain.
https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L844
* We don't need to exclude the free product reward lines from `lines_for_points` as the price is 0 on the SO. Shipping lines and free shipping rewards are not counted.

In pos, the fix is a bit different.

https://github.com/odoo/odoo/blob/4b9dee8fbe9aefde798c8543fef89c661cc85c57/addons/pos_loyalty/static/src/js/Loyalty.js#L908-L914

We first notice that this piece of code is never triggered as the structure of `program.id` is a number and `reward.program_id` is the following thus the last if statement is never true. A `.id` is added.
```
Proxy(Object) {id: 1, name: 'Code for 10% on orders', trigger: 'with_code', applies_on: 'current', program_type: 'promo_code', …}
```

This now means that we only count reward lines if they are from the same program. 

With the following if statement, it means that only the lines that are not reward lines are counted (which excludes discounts).

https://github.com/odoo/odoo/blob/eadfa4ee290a8b62956097aa66989eacff230275/addons/pos_loyalty/static/src/js/Loyalty.js#L921-L924

We conclude that those two ifs must be changed as we want a similar behavior as the workflow in sales.

We remove `orderedProductPaid` out of the if statement since it can be impacted by reward lines. We change the first if to excludes the reward lines only from the current program or from ewallet and giftcards. With this, `orderedProductPaid` now counts the discount lines from other program. (Similar to sales, where `amount_paid` is computed with `lines_per_rule`)

`totalProductQty` still applies only on non reward lines. (Same as sales)

opw-3858286

Forward-Port-Of: odoo/odoo#169934
Forward-Port-Of: odoo/odoo#164723

This PR aims to fix an issue with the Facebook snippet not being dynamically responsive for mobile views.

Steps to reproduce
1. Drop inner content facebook (dynamic content) anywhere
2. Go to mobile view
3. Try to scroll horizontally.

As you can see, facebook iframe is overflowing

Before v16, the mechanism for mobile view was different. The switch between mobile and desktop views caused snippets/pages to be re-render because a new dialog for mobile was opened every time. Starting from version 16, we have removed the dialog and introduced a mobile frame. As a result, the rendering now occurs only when the start function is called. Consequently, the params width does not change when we switch to mobile view.

![2024-04-29_14-34](https://github.com/odoo/odoo/assets/157009134/75a5fb69-8a46-4908-8814-0673084ed1d0)

After this PR, the snippet will be re-render every time the window resizes, ensuring that the width adjustment is responsive. This enhancement also allows parameters to be provided at the time of rendering.

![2024-04-29_14-35](https://github.com/odoo/odoo/assets/157009134/30a5c2f9-1e47-4902-a7c1-89506a541a26)

Task-2736174

Forward-Port-Of: odoo/odoo#170127
Forward-Port-Of: odoo/odoo#163739

PR does 2 things:
- First round of .po file cleaning for es_xx.po files. Since v17 started using es_419 instead of the es_xx.po files, these languages are no longer accessible on Transifex for the translators to change. These files were mostly out of date/incorrect anyways though, so we delete them. The one exception to this is the es_CL.po because Chile has some specific words that differ from the rest of LATAM. This cleanup will occur in a followup PR to give translators time to double check if any of the translations in from these es_CL files should remain.
- Cleanup the en_AU/en_GB.po files. There were some non-sense "translations" in them and most of them didn't add much value. Some en_AU files had specific legitimate "translations" were left (e.g. tax "GST", check = cheque), so they were only modified to remove any erroneous translations

task: 3593077
ENT PR: https://github.com/odoo/enterprise/pull/65107

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

(note for reviewer: I reset my branch on 15.0)

The `werkzeug.proxy_fix.orig` is set when running in --proxy-mode, it holds the original value of various headers before the ProxyFix class changed them according to the `X-Forwarded-` headers.

It is a dictionnary with the following entries:

    orig_remote_addr = environ_get("REMOTE_ADDR")
    orig_wsgi_url_scheme = environ_get("wsgi.url_scheme")
    orig_http_host = environ_get("HTTP_HOST")
    "werkzeug.proxy_fix.orig": {
        "REMOTE_ADDR": orig_remote_addr,
        "wsgi.url_scheme": orig_wsgi_url_scheme,
        "HTTP_HOST": orig_http_host,
        "SERVER_NAME": environ_get("SERVER_NAME"),
        "SERVER_PORT": environ_get("SERVER_PORT"),
        "SCRIPT_NAME": environ_get("SCRIPT_NAME"),
    }

All those sub-entries are already allow-listed by the Odoo's HTTPRequest class.

Accessing those values is handy when debugging the --proxy-mode, it allows to see at a glance if the proxy-mode was effective for this request: the `werkzeug.proxy_fix.orig` entry is present; or not: the entry is absent.

Forward-Port-Of: odoo/odoo#169446
Forward-Port-Of: odoo/odoo#168841

Issue:
======
Clicking enter in a banner inside a list breaks the layout in chrome browser.

Steps to reproduce the issue:
=============================
- Open chrome browser
- Go to to-do
- Create a list  and add 1 item
- Click enter (Second element of the list) and add a banner in the item
- Click enter
- Doesn't work as expected

Origin of the issue:
====================
This is a browser issue, chrome in this specific case doesn't work properly, all the events until `textInput` are called when clicking `enter` but the last event is never triggerged which is the `input` event. The specific case can be reproduced with this:
```
<div contenteditable="true">
     <ul>
         <div contenteditable="false">
             <div contenteditable="true">
                 <p>
                     text[]
                 </p>
             </div>
         </div>
     </ul
</div>
```

Solution:
==========
We manually trigger the `input` event in this specific case.

Issue:
======
List inside a banner under a list doesn't align correctly

steps to reproduce the issue:
=============================
- Go to do
- Add a list and first item
- Add a banner
- Add a list inside the banner
- It's not correctly centered

Origin of the issue:
====================
Since the list inside the banner is considered nested list under the top
list, the `margin-bottom` is removed.

Solution:
=========
Reassign the style again when we are inside the banner.

task-3857296

Forward-Port-Of: odoo/odoo#162204