When resuming a POS session, if the latter has been opened in the past
and if its state is 'Opening Control', a incorrect UserError is raised
and prevents the session to be started.

To reproduce the error:
1. Use a French company
2. Create a POS
    - Enable "Advanced Cash Control"
3. Start a new session
4. Close it
5. Set the computer's date in the future
5. Open the POS session > Continue Selling

Error: A UserError is raised ("This session has been opened another day.
To comply with the French law, [...]"), but the user does not have the
possibility to close the session. Moreover, since its state is "Opening
Control", no sales have been made yet.

This fix suggests to reset the start date in such a situation.

OPW-2488952

closes odoo/odoo#69253

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

Steps to follow to reproduce the bug:
- Create a new “Internal User”
- Add him a “default company”
- Add in the “allowed companies” a different company than his default company
- In the “Technical” section, check that the “multi companies” box is checked
- Log in with the new user
- At the top right select a company other than his “default company”
- In the “Calendar” app/ create a new meeting with a future date
- Add another user as a participant
- Confirm the meeting
- Access rights error is triggered

Problem:
When participant are added, an invitation by email must be sent to all participants.
The problem is in the template of the email that is sent, precisely in the "body", we add the name of the user's default company which we do not have access.

Opw-2494399

closes odoo/odoo#69935

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:

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

closes odoo/odoo#69927

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

This revision solves two things:
 - On installation of `l10n_latam_base`,
   `l10n_latam_base` is set as default as `l10n_latam_identification_type_id`
   for all partners in the database.
   The ORM method `write` was used to do so.
   With a database having a large number of partners,
   such as multiple hundred of thousands,
   this leaded to performance issues when `l10n_latam_base`
   got installed.
   I checked compute methods that could depends on this field,
   and the only one I found is `_compute_l10n_ar_vat`,
   which is not yet `installed/loaded` when this posthook takes place,
   as it's in the module `l10n_ar` which depends on `l10n_latam_base`
   and therefore is loaded after. So, it was already not executed/computed
   when using the ORM `write` method before this revision.
   Therefore, the use of plain SQL can be used to speed up the performance.
 - Also, the ORM `write` triggered unexpected compute fields
   which could raise exceptions, because of the `commercial_partner_id`
   synchronization.
   For instance:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1198, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 455, in load_modules
    loaded_modules, update_module, models_to_check)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 348, in load_marked_modules
    perform_checks=perform_checks, models_to_check=models_to_check
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 239, in load_module_graph
    getattr(py_module, post_init)(cr, registry)
  File "/home/odoo/src/odoo/14.0/addons/l10n_latam_base/__init__.py", line 8, in _set_default_identification_type
    env['res.partner'].search([]).write({'l10n_latam_identification_type_id': env.ref('l10n_latam_base.it_vat').id})
  File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
    return super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
    return super(ResPartner, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
    res = super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 550, in write
    partner._fields_sync(vals)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 469, in _fields_sync
    self._children_sync(values)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 478, in _children_sync
    self._commercial_sync_to_children()
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 452, in _commercial_sync_to_children
    sync_children._compute_commercial_partner()
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 297, in _compute_commercial_partner
    partner.commercial_partner_id = partner.parent_id.commercial_partner_id
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1127, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
    return super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
    return super(ResPartner, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
    res = super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 546, in write
    result = result and super(Partner, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_activity.py", line 766, in write
    return super(MailActivityMixin, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 322, in write
    result = super(MailThread, self).write(values)
  File "/home/odoo/src/odoo/14.0/addons/website/models/mixins.py", line 182, in write
    return super(WebsitePublishedMixin, self).write(values)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3640, in write
    self.modified(relational_names, before=True)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5786, in modified
    tocompute = list(tocompute)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5862, in _modified_triggers
    yield from records._modified_triggers(val)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5858, in _modified_triggers
    records |= model.search([(key.name, 'in', real_records.ids)], order='id')
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1708, in search
    res = self._search(args, offset=offset, limit=limit, order=order, count=count)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4492, in _search
    self._flush_search(args, order=order)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4470, in _flush_search
    self.env[model_name].flush(field_names)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5442, in flush
    self.recompute(fnames, records=records)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5908, in recompute
    process(field)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5879, in process
    field.recompute(recs)
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1145, in recompute
    self.compute_value(record)
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1175, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4068, in _compute_field_value
    self.filtered('id')._validate_fields(fnames)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1260, in _validate_fields
    check(self)
  File "/home/odoo/src/odoo/14.0/addons/sale_project/models/project.py", line 70, in _check_sale_line_type
    product_id=task.sale_line_id.product_id.display_name,
odoo.exceptions.ValidationError: You cannot link the order item SO/2019/11374 - [COMOD2H] Servicio de Correctivo dos Horas to this task because it is a re-invoiced expense.
```
upg-11324

closes odoo/odoo#69954

X-original-commit: 680bd481
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

Have a Fiscal position FPOS which map tax A to tax B
Have products DEMO with tax A and DEMO2
Allow FPOS in POS, Open a session, activate FPOS, sell DEMO and DEMO2
Close POS
Go to Orders, select the last one, hit return, edit, delete DEMO2 line

Tax will be wrong.
This occcur because the fiscal position mapping fail an equivalence
check with a virtual record, so the tax is calculated as A and not B

opw-2485399

closes odoo/odoo#69936

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

This tasks allow to see serial numbers or lot numbers for each products on the order.
It also add the same information on an invoice generated by the POS if the option is ticked in the pos config.

closes odoo/odoo#42410

closes odoo/odoo#69932

Task-id: 2154835
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

When a product is sold from POS, the lot is not present in the invoice.
As in 14.0, this feature is only in sale, we need to have POS and sale
to make it work.

This merge is a backport of tests done in master (14.4) to try to keep coherent
tests through 14+ versions. It is also useful for bug fixes as it increases coverage.
In this commit we add test related to mass mailing :

  * test deletion / archives management, especially with reply-to mode that
    has some effect on mail.message unlink;
  * test reply-to mode new and thread in specific tests to ensure thread update
    or new based on aliases work as intended;
  * clean some existing tests;

closes odoo/odoo#69889

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Before this commit, we would compare a lang `code` (used in context) and a lang
`url_code`. For languages where those 2 are differents, the `if` condition
would always be falsy, making the canonical URL impossible to be reached.

Technically, this condition is used to get the translated name of records to
later construct the canonical URL.

Since the canonical URL will be incorrect and unreachable, the whole system to
tell search engine/crawler about translation won't work since no
`alternate/hreflang`[1] will be set in the DOM.

[1] see https://developers.google.com/search/docs/advanced/crawling/localized-versions



--------

Technical explanation:
- italian language `code` = `it_IT`, `url_code` = `it`
- belgian french language `code` = `fr_BE`, `url_code` = `fr_BE`
Install those languages on website as secondary languages.
Translate blog `Travel` to `Voyager` in french and `Viaggi` in italian.
Visiting `/fr_BE/blog/travel-1/post/post-1` will redirect to
`/fr_BE/blog/voyager-1/post/post-1` as it should, and the canonical URL will be
set to that same URL.
Visiting `/it/blog/travel-1/post/post-1` will redirect to
`/it/blog/voyager-1/post/post-1` as it should, but the canonical URL will be
set to `/it/blog/travel-1/post/post-1`.

opw-2486918

closes odoo/odoo#69867

X-original-commit: 413357e0
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

Steps to reproduce the bug:

- Try to export mail.message records

Bug:

A traceback was raised

Wrong forward-port of 69b27ac3

opw:2514584

closes odoo/odoo#69895

X-original-commit: 9cf49ba3
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Purpose of this commit is to add tests related to answers through mail gateway
when having reply-to mode of mailing set to either updating existing threads
(aka replying on mailed records), either creating new threads (aka using the
reply-to alias configuration).

Backport of odoo/odoo@4ef24369c813ec6a6ce997369aa454d9d67a992b done in master (14.4)

LINKS

Task ID-2117639
COM PR odoo/odoo#40931

Purpose of this commit is to add tests for current behavior of ``keep archives``
field on mailing, used in combination of ``reply-to`` target (either new thread
or update existing threads).

Backport of odoo/odoo@b36b74fa570937795c598a9f08086b13ff7773c6 done in master (14.4).

LINKS

Task ID-2117639
COM PR odoo/odoo#40931

In this commit we try to simplify tests organization by

  * merging mailing_internals and mass_mailing tests, as they globally handle
    mailing-related tests (blacklist, opt-out, gateway update through replies
    and clicks);
  * move wizard (mailing.test) tests in their own file as they target a
    specific model;
  * add some loggers to reduce noise;
  * add some users wrappers to test using real users;

Backport of odoo/odoo@230b8258a551010080dd582923afe5a2f91d644b done in master (14.4)

LINKS

Task ID-2117639
COM PR odoo/odoo#40931

When running an automated action on record creation, if the action
raises a UserError/ValidationError, the record will still be created.

To reproduce the error:
(Need website_crm,base_automation. Enable debug mode)
1. Create an Automated Action
    - Model: Lead/Opportunity
    - Trigger: On Creation & Update
    - Trigger Fields: Phone (crm.lead)
    - Action To Do: Execute Python Code
    - Python Code:
    ```python
    if record.phone:
        raise UserError("Lorem ipsum")
    ```
2. On website, add a website form WF
    - Action: "Create an Opportunity"
3. Complete and submit WF including a phone number

Error: An error message is displayed ("Lorem ispum"). However, the lead
has been created and is present in CRM Pipeline.

An on-creation automated action is executed once the record is executed,
but nothing will cancel this records creation if the action raises a
UserError/ValidationError.

OPW-2423948

closes odoo/odoo#69477

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

In this commit, we add all the data related to the Argentinean
perceptions for each jurisdiction.

For each jurisdiction (xx) we have a new:
 * Tax: Percepción IIBB xx Sufrida
 * Tax: Percepción IIBB Catamarca Aplicada
 * Tax group: Perc IIBB xx
 * Account: Saldo a favor IIBB xx
 * Account: Retención IIBB xx sufrida
 * Account: Percepción IIBB xx sufrida
 * Account: Retención IIBB xx aplicada
 * Account: Percepción IIBB xx aplicada
 * Account: IIBB xx

Also, we activate some perceptions to work with demo data

closes odoo/odoo#69757

X-original-commit: 51d49054
Signed-off-by: Josse Colpaert <jco@openerp.com>

closes odoo/odoo#69844

X-original-commit: 16c09f39
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Task 2352493

When the user is asked to fill in the label on the invoice, the tooltip
tells him that the label can be auto-filled by configuring its products.
This leads the user to configure products. But then, as he doesn't fill
in the label, the tour is "broken".

closes odoo/odoo#62272

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

closes odoo/odoo#69234

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

What are the steps to reproduce your issue ?

    1. Install 'purchase_product_matrix'
    2. try to edit a PO with more than one line
    3. try to change the order of a product line

What is currently happening ?

    Traceback: TypeError: Cannot read property 'data' of undefined

What are you expecting to happen ?

    Change order lines without traceback

Why is this happening ?

    There is a function 'reset' that checkes if 'ev' exists:
    https://github.com/odoo/odoo/blob/e0af10ccc92cb3b07f0eea6fa44ebf5a1bdc86aa/addons/sale/static/src/js/product_configurator_widget.js#L119



    And in 'purchase_product_matrix' there is a override of this same function that calls it
    and then tries to use an 'ev' attribute without checking it before

How to fix the bug ?

    Check 'ev' before accessing it

opw-2513061

closes odoo/odoo#69666

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Create a company whoose name ends with a dot like "Bidule Inc.", change
the company of the user to that new company, head to the Accouning
module and create a new journal of type purchase. Traceback because the
generated mail alias for that journal uses the company name and that the
local-part of an email cannot ends with a dot.

From the RFC standpoint, the local-part of an email address (the part
before the @, `john` in `"John Doe" <john@example.com>`, cannot begins
with, ends with or contain following dots.

The email sanitizing function have been updated so it takes care of the
above requirement.

See also #61811
opw-2448692

closes odoo/odoo#69816

Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>

This commit is fixing two issues:
1: make ribbon translatable
2: display ribbon below smart button

closes #68438

closes odoo/odoo#69815

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Steps to reproduce the bug:

- Let's consider two companies C1, C2 and a partner P in C2
- Let's consider an customner invoice I in C1 with P as customer
- Go to Accounting > Accounting > Partner Ledger and select I
- Click on Reconcie

Bug:

An access error was raised due to the ir.rule res.partner company

opw:2446242

closes odoo/odoo#69190

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

*: account_payment, payment, sale

Steps:
- Install eCommerce
- Go to Website / Configuration / eCommerce / Payment Acquirers
- Configure Stripe:
  - Save Cards: Always
  - Payment Flow: Redirection to the acquirer website
- Go to /shop
- Add a product to the cart
- Process Checkout
- Select Stripe
- Pay Now
- Enter test data in Stripe Checkout form (https://stripe.com/docs/testing#cards)
- Pay
- Go to /shop
- Add a product to the cart
- Process Checkout
- Select your saved card
- Pay Now

Bug:
Stripe Error:
The provided PaymentMethod was previously used with a PaymentIntent
without Customer attachment, shared with a connected account without
Customer attachment, or was detached from a Customer. It may not be used
again. To use a PaymentMethod multiple times, you must attach it to a
Customer first.

Explanation:
https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-payment_intent_data-setup_future_usage


> Indicates that you intend to make future payments with the payment
> method collected by this Checkout Session.

According to this doc, `setup_future_usage` must be set in order to use
the saved card afterwards.

opw:2452452
opw:2498571
opw:2509897

closes odoo/odoo#69772

X-original-commit: 43e666f2
Signed-off-by: backspac <backspac@users.noreply.github.com>

Before this commit, There would be Traceback (AttributeError: 'bool' object has no attribute 'date')
on Confirm Receipt Date If order has no Receipt Date.

Now, Button Confirm Receipt Date will be hidden if there is not Receipt Date to confirm.

Original behavior was fixed on #60659 but attribute was replaced
here which misses this condition.

closes odoo/odoo#69437

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

When the user searches a phone number, the search function will generate
a pattern by removing the "+" sign as well as well as the prefix "00" from
the input string.

Problem:

If the input string starts with "+", it means that the phone number will
be prefixed by something different than "00". As the function will
systematically remove the first occurrence of "00" from the input string,
the function can remove part of the input string that does not correspond
to a prefix. The search results can hence be incorrect.

Example:

If the user types "+32485001122", the function will remove the "+" sign
and the first occurrence of "00" from the input string. In the provided
example, the function will search phone numbers matching with the pattern
"324851122" which is incorrect.

Solution:

The function should remove the first occurrence of "00" iff the phone
starts with "00".

Task id: 2479277
COM PR: odoo/odoo#69729

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

If a partner have two delivery address, one full filled, an other with missing fields. During the shopping (the first delivery address is auto selected), if the partner go back in shop/address to select the second address. Then go to /shop/confirm_order, there no checks.

closes odoo/odoo#69615

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

To display an aggregate in a list view, the field format method is used.

But since mrp_time_counter that extend float_time has no format method,
you would see eg. 2.07 as aggregate and 2:04 on the line which is a
little confusing.

opw-2514634

closes odoo/odoo#69770

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

- Create an invoice for a portal user
- Add a credit note for that invoice
- Connect with portal user
- On Invoices & Bills menu, the correct count is displayed (i.e. 2)
- Open Invoices & Bills page
The "All" filter only displays out_invoice and in_invoice, making impossible to view
the other types (out_refund, in_refund, out_receipt, in_receipt).

opw-2486471

closes odoo/odoo#69693

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

- report line should be in alphabetical order

task- 2502322

closes odoo/odoo#69032

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

Before this commit

When someone tries to send a mail to a restricted alias (which can be
anywhere in 'To', 'CC' or 'BCC') and if the sender is not allowed to do
so, the mail bounces. However bounced mail shows info as if it bounced due
to address provided in 'To', even though it is not always the case.

Example you send a message to

  * 'To': 'valid@gmail.com' (okay)
  * 'Cc': 'myalias@odoo.com' (not allowed for you)

Mail bounces because you are not allowed to send a mail to alias provided
in 'Cc', but it shows the message that: `The following email sent to
valid@gmail.com cannot be accepted because [...]`.

After this commit

Boucing alias is shown in message body. Above example becomes `The following
email sent to myalias@odoo.com cannot be accepted [...].`

Note: Because the alias can be present in `Bcc` too (which will not available
in the message values we get in `message_route_verify` method), we simply use
display name of the alias instead of finding mail address matching with alias
from the message values.

Task ID-2390310

closes odoo/odoo#69752

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

When l10n_latam_invoice_document is installed and the current company
does not have a custom header (in stable, only Chile and Argentina with
their localization installed use custom header), printing multiple
invoice at once, one out of two had no header or footer.

This is because `<div class="header"/>` and `<div class="footer"/>`
should be unique per record being printed, and when a custom header was
not used they were duplicated with the duplicate empty.

As an example, if we had 3 documents:

- record 1 : good header
- record 1 : empty header
- record 1 : body
- record 1 : good footer
- record 1 : empty footer

- record 2 : good header
- record 2 : empty header
- record 2 : body
- record 2 : good footer
- record 2 : empty footer

- record 3 : good header
- record 3 : empty header
- record 3 : body
- record 3 : good footer
- record 3 : empty footer

When we give them to wkhtmltopdf, it would be mismatched:

- headers:
  - record 1 : good header
  - record 1 : empty header
  - record 2 : good header

- bodies:
  - record 1 : body
  - record 2 : body
  - record 3 : body

- footers:
  - record 1 : good footer
  - record 1 : empty footer
  - record 2 : good footer

so record 2 will have empty header/footer, and record 3 will get those
of record 2.

opw-2507137

closes odoo/odoo#69703

X-original-commit: 90bdb5c7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Before this commit, it might happen that, in some situations,
with several tabs opened, the CrossTabBus called the longpolling
route repeatedly, thus slowing down the server, and freezing the
webclient.

The issue was tricky to reproduce. It was a race-condition that
could occur when several tabs performed simultanous calls to
addChannel, while being unloaded or becoming mastertab in the
meantime (e.g. when opening/closing/refreshing several tabs
simultaneously).

This issue has been introduced by [1] which by mistake (probably)
made each tab calling itself the localStorage to update the list
of channels when it was notified that the list of channels in
the localStorage just changed. So if several tabs had a slightly
different list of channels at a given moment (e.g. at startup),
it might happen that they in turn, undo what another tab just
put in the localStorage, and thus produced an infinite loop of
localStorage writes and longpolling request aborts/calls.

The issue could be reproduced with the OCA module [2], which
performs several addChannel at webclient startup.

This commit restores this part of the code as it was initially
written in [3].

Closes #69067

opw~2502799
maybe opw~2451865 as well

[1] https://github.com/odoo/odoo/commit/6448420
[2] https://odoo-community.org/shop/product/web-notify-2670#attr=10773
[3] https://github.com/odoo/odoo/commit/38581f67236377daa767ca2216529a26b8708b00#diff-f6eccad21ae3543606ab8f97b8b097d015412caeaee2bf8cc928eb3ccabac9f5R149



closes odoo/odoo#69756

X-original-commit: 93439c75fee5280fbca451b4aa2fcd8c86f8b325
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Mail holds a "Pay Now" notification template holding notably customized
links to portal for records like sale orders or invoices. It allow to
give a more personalized button than a plain simple "View document" link.

Currently frontend / backend links are not always correctly computed in this
template. This commit fixes that behavior.

Task ID-2513724
COM PR #69607
ENT PR odoo/enterprise#17849

closes odoo/odoo#69714

X-original-commit: odoo/odoo@a55f125f5420797a9378925da5626e43d002b9b0
Related: odoo/enterprise#17889
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Purpose of this commit is to fix computation of access link. In some cases
msg_vals modification leads to invalid URL computation, notably for frontend
or backend differentiation for target recipients.

Followup of odoo/odoo#63292 .

Task ID-2513724
COM PR odoo/odoo#69607
ENT PR odoo/enterprise#17849

X-Original-Commit: odoo/odoo@2015ef463c9ac7c7f89d543745c02a2d1528acf2

- Create Tax Exempt fiscal position
- Create Customer with Tax Exempt in fiscal position
- Enable Tax Exempt fiscal position in POS settings
- In POS, set customer to one with Tax Exempt
- Create a sale, apply, payment, validate, and click New Order
- Click magnifying glass to reprint receipt
- Default tax is automatically applied to all past orders/receipts

This occur because:
- in Pos OrderList the total is based on the amount total, and not the
actual amount paid
- the fiscal position object is not present when retrieving the order
via `selectedOrder`

opw-2485178

closes odoo/odoo#69475

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

In the chatter, the attachment preview image size is fixed with 160*160
but the actual preview area is 200*200px so the image is not filling correctly.
It appears padding around the image, especially visible when hovering it.

So with this commit, We should make sure to use a properly sized image in the
preview. we have to also provide the perfect resolution and preview for
the small images without upscaling incorrectly. For large images, it should be
display based on the aspect ratio.

Task : 2483885

closes odoo/odoo#68696

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Steps to reproduce the bug:

- Let's consider a company in $
- Let's consider two sales taxes T1 (10% included) and T2 (0%)
- Define a fiscal position FP that maps T1 to T2
- Define a product P with T1, price = 11$ and available in the shop
- Define a pricelist PL in € such as 1€ = 2$, show discount to customer and discount P with 50%
- Define a portal user PU with FP and PL
- Log with PU
- Add P in the cart

Bug:

The unit price of P was 2,75€ instead of 2,5€ and the discounted price was 10€ instead of 5€

PS: Before adding P in the cart, the correct unit price and discounted price were displayed.

opw:2472528

closes odoo/odoo#69715

X-original-commit: ea259218
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>