PROBLEM 1:

Steps to reproduce:
- Create branch company
- Create a user for the branch company and assign the bookkeeper role
- Log in as the newly created user
- Inside accounting module navigate to Vendor menu -> Payment
- Create a payment and set the amount
- Attempt to edit the payment

Error:- Access Error: Access to unauthorized or invalid companies.

Cause:
Before this pr, the context passed during the accessible branches
calculation included 'journal_id.company_id' (i.e., the parent company_id). This
led to an error during validation in the companies method of the env class,
since the parent company_id is not valid for branch-specific operations/users.

Solution:
After this pr, remove the context modification introduced by the
'with_company()' method during the invocation of '_accessible_branches()',
ensuring that the correct branch context is used for access validation.

PROBLEM 2:

Steps to reproduce:
- First 3 steps are same as problem 1
- Inside accounting module navigate to bank reconciliation list view
- Create new bank statement line
- Attempt to edit the bank statement line

Error:- Access Error: because of company rule employee

Cause:
Before this pr, in the '_synchronize_to_moves' method the 'company_currency'
calculation   included 'journal.company_id.currency_id' in which
'journal.company_id' is the parent company_id to which the user does not have
access.

Solution:
After this pr, adding 'sudo()' method call at the time of accessing
'journal.comapny_id' (i.e., parent company_id) for bypassing the access rights.

Task - 4654866

Forward-Port-Of: odoo/odoo#205548

web push payloads currently get their body truncated when the payload comes out
to more than 4096 bytes. However this only keeps the plaintext payload under
that limit, not accounting for encryption.

As we need the payload to be 4096 bytes at most *after encryption*
the threshold for body truncation is reduced to around 3990 bytes to account for
the fixed overhead of encryption as laid out in the added constants and getters
so that they can be adjusted as needed.

Additionally there were some issues with the logic for truncation:
- Checking character length against byte length for the comparison, which led to
potentially a lot more truncated text than necessary.
- Truncation being done with the assumption the text would be encoded in utf-8
when it is actually transformed to json unicode escape sequences
(see ensure_ascii argument in json.dumps) again making the truncation inaccurate.
- The calculation of body_max_length was incorrect, as it allowed for negative
values which sometimes resulted in an empty body.

Steps to reproduce:

1. Activate desktop notifications.
2. Fastest way will be to send to an account A (with activated notis),
a message through discuss from an account B.
3. Additionally this affects the current flow too:
  3.1 When we try to notify a user following a heldesk team.
  3.2 We create an alias and set this to that current team.
  3.3 We simulate an email to that heldesk team, eg vip-support@test.com

opw-3939019

Forward-Port-Of: odoo/odoo#193641

Currently the reconciliation may create unnecessary exchange difference entries or have unnecessary residual amounts.
This can happen in case we try to reconcile lines with multiple currencies.

Consider e.g. the following case (c.f. the added test cases in the code):
company currency: EUR
foreign currency: USD
rate: 1 EUR = 18.8777 USD (1 USD = 0.052972554919 EUR)
rounding: Both EUR and USD are rounded to 2 decimal places (to 0.01)

Lines to reconicle:
line0 |   20000.00 USD |  377554.00 EUR
line1 | -372239.38 EUR | -372239.38 EUR

Perfect write-off line for a full reconciliation (w/o exchange difference or remaining residuals)
line2 |    -281.53 USD |   -5314.62 EUR

Since
EUR: 377554.00 + -372239.38 = 5314.62
USD: 200000.00 + USD.round(-372239.38 * 0.052972554919) = 200000.00 + USD.round(-19718.47100006451) = 281.53

Note the actually used exchange rates during the reconciliation are not necessarily the ones from the currencies.
They could also be (re)computed from the lines.

Note that the "reconciliation currency" may be choosen differently in the following cases
- the reconciled account is a payable (`liability_payable`) or receivable (`asset_receivable`) account
- the reconciled account has another type

In the code see
- `recon_currency` in `_prepare_reconciliation_single_partial`
- `is_rec_pay_account` in `_prepare_move_line_residual_amounts`

#### Problem (1); receivable / payable account & partial reconciliation
In this case we reconcile line0 and line1 and the account on the lines is either a payable or a receivable account.

The following happens
1. Due to the account type we try to match the foreign currency (USD) amounts.
   line1: 20000.00 USD
   line2: 19718.47 USD (= USD.round(-372239.38 * ≈0.052972554919) = USD.round(-19718.47100006451))
   USD: 19718.47 (= min(20000.00, 19718.47))
2. Use the exchange rate (from line0) to compute the value in EUR (company currency)
   EUR: 372239.36 (= EUR.round(19718.47 * ≈18.8777) = EUR.round(372239.36111900007))
3. We still have a residual of 0.02 EUR on line1.
   But since line2 was fully matched in step 1 we create an exchange difference entry
   (to cover for the residual in company currency)

Issue:
We could have matched 372239.38 EUR on both lines since the difference (0.02 EUR) is just a rounding error.
Here 372239.38 EUR represents the full remaining amount in company currency on line1.
Then there would have been no residual (and thus no need for an exchange difference entry)

#### Problem (2); other account type & try full reconciliation with correct write-off line
In this case we reconcile line0 and line1 and line2 and the account on the lines is neither payable nor receivable.

First the reconciliation will reconcile line0 and line2 (roughly speaking since they have the same foreign currency).
1. Since both are in foreign currency we try to match these amounts first:
   USD: 281.53 (= min(20000.00, 281.53))
2. We then use the exchange rate to compute the value in EUR (company currency)
   line0, EUR: 5314.64 (= EUR.round(281.53 * ≈18.8777) = EUR.round(5314.638881))
   line2, EUR: 5314.62 (281.53 converted via the "custom" rate on line2)
3. We now have the following residuals
   line0 (residuals) |   19718.47 USD |  372239.36 EUR
   line2 (residuals) |       0.00 USD |       0.00 EUR
   We substracted 5314.64 EUR from line0 but only 5314.62 EUR from line2.
4. To account for the difference we create an exchange difference entry

We could have matched 5314.62 EUR on both lines (since the difference is just a rounding error)
This way we could void the exchange difference entry.
And we would also have a "correct" residual on line0.
The residuals on line0 will cause the full reconciliation to fail (see below).

Next the reconciliation will match line1 with the residuals of line0
The following happens.
1. We try to match company currency amounts first (due to the account type)
   line0, EUR: 372239.36
   line1, EUR: 372239.38
   EUR: 372239.36 = min(372239.38, 372239.36)
2. Compute the amounts in currency
   line0, USD:  19718.47 (= USD.round(372239.36 * ≈0.052972554919))
   line1, EUR: 372239.36 (= 372239.36 * 1)
3. We now have the following residuals
   line0 (residuals) |       0.00 USD |       0.02 EUR
   line1 (residuals) |       0.00 USD |       0.00 EUR
4. The reconciliation ends without creating an exchange difference entry

#### Solution

Problem (1)
In case the remaining amount (in company currency) could be fully matched if not for rounding issues
we will just match the full remaining amount.

Problem (2)
We match the company currency amounts of the individual lines to a common value if they are the same up to exchange rounding issues.

#### References

opw-4438542

Forward-Port-Of: odoo/odoo#204746

#### [FIX] account_accountant: reco wizard: exchange rate rounding
In the related community commit we improved the reconciliation
behavior with regards to exchange rate and rounding issues.
See there for more details.

For one of the tests there we manually created the write-off line with the
correct amount.
Here we add a test to check that the wizard computes the right amounts
for the write-off line / entry.

opw-4438542

#### [FIX] account_accountant: reco wizard: show company amount
The reconciliation wizard may create a write-off line / entry.
Roughly speaking this happens in case
- the amount of the input lines does not sum to 0
- and the "Allow partials" option is not ticked

The write-off line can be in foreign currency.
Currently the wizard only displays the amount in foreign currency but
not the amount in company currency.
So currently the company currency amount can not be checked before reconciling.

After this commit the wizard also displays the amount in company currency.

opw-4623933

Forward-Port-Of: odoo/enterprise#82865