Before this commit, the numbering system used by luxon was the default
one set by the browser (in most cases: 'latn'). This caused issues when
translating luxon dates with moment dates, as moment supports some
locales differently (e.g.: ar_001 uses the 'arab' numbering system
while Intl uses 'latn').

To have proper consistency, this commit assigns (as much as possible)
the same numbering systems as luxon for each supported locale.

Warning: since the numbering system is now set according to the user
'lang' parameter, it's now unsafe to use `DateTime.fromFormat(...)` with
static date strings, as they might not be parsable with the current
numbering system.

closes odoo/odoo#83944

Signed-off-by: Géry Debongnie <ged@odoo.com>

Before this commit, an empty line would be shown in the payment forms on
the card of each payment acquirer whose `pre_msg` field was not empty.
This is because displaying this HTML field in a form view and saving it
causes the value `<p><br></p>` to be written on the field, even if it
was left empty. The same issue occurred with the `pending_msg`,
`auth_msg`, `done_msg`, and `cancel_msg` fields that are shown on the
portal of some apps (Sales, Accounting...).

With this commit, the value of these fields is tested before displaying
them. If the value is `<p><br></p>`, the field is not displayed, hence
avoiding to display a blank line.

closes odoo/odoo#84715

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Before, if you would put Peru Street 23, it would put Peru in House number.
This is because the editable field was the street field, so behind the scenes,
Odoo will split it and according to the standard format without country,
this means Peru will go into House.

We tried first with a change inversing it, but as we are doing the change,
the best thing is to remove the split all together.  We added also onchange
logic that if you put a district it would automatically put the right city.

City or city_id should depend on the country and is correctly inherited by a
fields_view_get.

Task 2724531

closes odoo/odoo#84710

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

decimal places while we compute stock_quants.

closes odoo/odoo#84697

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

When performing a picking with a package, the source location of the
package level may become incorrect

To reproduce the issue:
(Use demo data)
1. In Settings, enable:
    - Packages
    - Storage Locations
2. In Operations Types, edit "Internal Transfers":
    - Enable "Move Entire Packages"
3. Create a storable product P
4. Create a receipt R with for P
5. Put 10 P in pack and validate R
    - Let be PK the package generated/used
6. Process an internal transfer with PK
    - The destination location of the package level is WH/Stock/Shelf 1

Error: Once the picking is validated, the source location of the package
level is "WH/Stock/Shelf 1". This is not true, it should still be
"WH/Stock"

The compute method is incorrect. It uses the package location to define
the source location of the package level. However, once the picking is
processed, this package has moved so using its location to define the
source location doesn't make sense anymore.

OPW-2754179

closes odoo/odoo#84696

X-original-commit: 239898ed
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Commit b6ae8a0a introduced the generic behavior of blocking the UI as
soon as a submit button is pressed in a payment form. The 3DS2 flow of
Adyen was not taken into account, resulting in the impossibility to
enter the additional details required by Adyen.

With this commit, the UI is unblocked at the right time to allow the
user to submit the additional details. Moreover, the submit button is
now hidden as soon as we don't want to show it anymore, rather than
after having submitted the additional payment details.

closes odoo/odoo#84695

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Currently all latam localizations except Chile use country_id in _localization_use_documents().
account_fiscal_country_id should be used instead in all modules.

closes odoo/odoo#84369

Task: 2761248
Signed-off-by: Olivier Colson <oco@odoo.com>

Steps :
Install Field Service and Contacts.
Create a FSM task > Customer : Demo.
Note that the displayed address is his Demo's current one.
Click Navigate To : it points this same address.
Go to Contacts > Demo > change the address and return to task.
Note that the displayed address is his Demo's new one. (Or else refresh)

Issue :
Click Navigate To : it points the OLD address.

Cause :
action_fsm_navigate calls partner.geo_localize
only if partner has no geocoordinates.
Yet he still have the old coordinates.

Fix :
Call when the address changes and not in action_fsm_navigate.

closes odoo/odoo#84266

Opw: 2743926
Related: odoo/enterprise#24198
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Before this commit, during edit mode, the user was able to interact with
form elements. In 13.0, it was somehow prevented by some JS code by
losing the focus immediatly but it was not enough: if typing quickly the
user was able to type text. But the real problem was the user seeing the
input focused for half a second then not anymore, making him think a bug
occured. Worse, the datepickers of the form snippet were able to be used
entirely during edit mode, making the user think it is possible to
configure a default value (which was not true in 13.0). In following
versions, the bug is indeed worse as it messes up with the default
values configuration. In 14.0, it is apparently possible to type
normally in all of those inputs... although still ignored on save. In
15.0... the 13.0 behavior of losing the focus immediatly is back though.

This commit fixes that via CSS, still allowing a click on the elements
to be considered as a click on the parent, but preventing to focus our
snippet inputs (this fix is limited to our own snippets as stable fix).
Note: the 13.0/15.0 JS code which prevents the focus right now was not
found (if it even exists...) but it would not be ok to remove it in
stable anyway. More investigation and review will be done once this
reaches master.

task-2523496

closes odoo/odoo#84589

X-original-commit: 3e598a80
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Based on the po/pot files generated from odoo,
reorder the translations + remove the unused one.

closes odoo/odoo#84658

X-original-commit: 08c7503c
Signed-off-by: William André (wan) <wan@odoo.com>

When printing a delivery slip, if the delivered product is a kit
composed with a subkit, the products of this subkit won't be listed

To reproduced the issue:
1. Create 5 consumable products: 'Compo 01', 'Compo 02', 'Compo 03',
'Sub Kit', 'Super Kit'
2. Create two phantom-type boms:
    - Sub kit:
        - 1 x Compo 02
        - 1 x Compo 03
    - Super Kit:
        - 1 x Compo 01
        - 1 x Sub Kit
3. Process a delivery with 1 x Super Kit (the picking must be done)
4. Print the delivery slip

Error: The report only contains two lines, i.e. the name of the kit
('Super Kit') and the name of the 'direct' component ('Compo 01)

The issue comes from the SML used to define `kit_move_lines` (XML side).
It uses `has_kits` which only contains the top level kits' SML:
https://github.com/odoo/odoo/blob/1b1067b0cf2a3de2773915ff8205084492b1bbe3/addons/mrp/report/report_deliveryslip.xml#L6-L9


This is the reason why the SML for Compo 02 and Compo 03 are not listed

OPW-2740247

closes odoo/odoo#84634

X-original-commit: a21e946e
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

When the snailmail API-call timed out, the SnailmailLetter.state and SnailmailLetter.error_code were not changed, which resulted in an infinite loop of retries  via the "Snailmail: process letters queue" cron job.
This commit changes this behavior: On a timeout the SnailmailLetter.error_code is changed such that no retry happens. Following stable policy, no timeout error is added, but 'unknown error' will be used. Preventing retries on timeout is mandatory as timed-out request are indeed processed by IAP and customer credited.

closes odoo/odoo#84243

X-original-commit: b3c46e80
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Zians Dominik (dozi) <dozi@odoo.com>

To reproduce the issue:
(Need purchase,sale_management)
1. Create a product category PC:
    - Costing Method: FIFO
2. Create a product P
    - Type: Storable
    - Category: PC
3. Create a PO with 1 x P @ 10 + Receive P
4. Create a PO with 1 x P @ 0 + Receive P
5. Create a SO with 1 x P + Deliver P
6. Create a SO with 1 x P + Deliver P
7. Process a return for sold P at step 6
8. Open the valuation of the return

Error: The value is 10, should be 0

In `_get_price_unit`, `price_unit` is defined with the correct value
(i.e., `0`), but the if-condition of the `return` is not respected, so
another value is used

OPW-2735502

closes odoo/odoo#84629

X-original-commit: 3ad98f7d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Commit [1] had been reverted at [2] because it broke the database
manager. It had been done in emergency but a simple fix existed (see
discussion at [3]). This restores commit [1], thereby restoring the
preserve_comments option in 15.0 (which is already implemented
differently in subsequent versions). Since commit [4], there is no need
for the fix anymore since the renderer has an `env` object even in the
context of the database manager. We can thus just apply commit [1] as it
was originally.

[1] https://github.com/odoo/odoo/commit/d17d8523c039ef574062ec20e74d872258e6487f
[2] https://github.com/odoo/odoo/commit/a82c23aeb64669d58f8a47cfe01e81cfe33ef99e
[3] https://github.com/odoo/odoo/pull/80666
[4] https://github.com/odoo/odoo/commit/3014e922b48696fb9aba4b477ebe1878dd01bb69



closes odoo/odoo#84624

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Current behaviour:
- Time in pivot view of report in attendance is in decimal hours
(e.g. 90 minutes is noted as 1.5 instead of 1:30)

Behaviour after PR:
- Time is noted in proper time manner

opw-2752651

closes odoo/odoo#84554

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Since [1] the product search from website did not match the content of
the product internal note anymore.

After this commit the product search from website also matches products
if the terms appear in the product's internal note.

[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986



opw-2715647

closes odoo/odoo#84615

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps to repoduce:
- Go to Sales - products
- Create a product
- Add variants (3 attributes and 2 values each) Total is 8 variants.
- onfigure variants: Select 1 attribute and exclude it for 1 variant (for example: exclude for size 12x12)
-> the number of variants remains at 8. The one that is excluded is still visible in the Product variants tab.

Solution:
When an exclusion is created, archive all the not-possible-combination.

OPW-2729329

closes odoo/odoo#84521

X-original-commit: 5ff4eb02
Related: odoo/enterprise#24311
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

closes odoo/odoo#84148

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Steps to reproduce:

- Set a language which use ',' (comma) as
  decimal separator (eg French)
- Make a Vendor Bill for any product at any price.

If the partner's language use '.' (period) as
decimal separator (eg English), the field
amount_by_group is formated whit period, while others
are formated with comma. They should all be formated
with comma.

- Now print the Vendor Bill

The same issue is occuring.

With Customer Invoices, the issue is the same on
the form view, but not on the printing, where all
the fields are formated with period, as set in the
partner's language.

After this commit, we format all the fields
regarding the environment's language on the view form,
either in Vendor Bills and Customer Invoices,
and we formating the printed bill/invoice regarding
the partner's language

opw-2735698

closes odoo/odoo#84622

X-original-commit: 60e1bdde
Signed-off-by: Florian Gilbert <flg@odoo.com>

When a quant is creating, for instance thanks to an internal transfer,
some of these computed fields will have an incorrect value

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create a storable product P
3. Update P's quantity: 100 P in WH/Stock
4. Process an internal transfer
    - From: WH/Stock
    - To: WH/Stock/Shelf 1
    - Operations: 10 x P
5. Consult the on hand quantities of P

Error: There is a new line with 10 x P in WH/Stock/Shelf 1, which is
correct. However, the Counted Quantity field is defined and equal to 0,
and so does the Difference field with a value of -10. These two fields
should not be shown.

When validating the internal transfer, a new quant is created for the
location "Shelf 1". However, there isn't any value for the field
`inventory_quantity_set`. Therefore, at the end of the transfer
validation process, when the `flush` method is called, since
`inventory_quantity_set` is a computed field, its  `compute` method is
called and define the value to `True`:
https://github.com/odoo/odoo/blob/8b155b695823dfa954464ad0d5dd07445ece2471/addons/stock/models/stock_quant.py#L134-L136


This explains why, on front-end, the Counted Quantity and Difference
fields are displayed.

OPW-2733937

closes odoo/odoo#83942

Signed-off-by: Arnold Moyaux <arm@odoo.com>

export_icon_to_png sometimes failed because PIL's getbbox returned None.
This fixes it by not using a default color of (0, 0, 0, 0) when creating
the image but using the actual color of the image instead.
Also, the size of the image was wrong because of using the default size
when width and height are defined.

task-2761098

closes odoo/odoo#84565

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

closes odoo/odoo#84489

X-original-commit: 2df9503f
Signed-off-by: Josse Colpaert <jco@odoo.com>

Documentation structure were modified to point out to a new subtree:
    content/applications/general/email_communication/email_server

Related task:2619564
Documentation PR:1092

closes odoo/odoo#84548

X-original-commit: 8e57b42f
Signed-off-by: Vergote Baptiste (bve) <bve@odoo.com>

Bug
===
If we
1. Open a lead with an email but without partner
2. Set a partner without email on the lead
3. The warning "The email will be propagated" is visible
4. When saving the form, the email is not propagated even if the
   warning message was visible

Solution
========
The reason is that, as the email was not changed, the inverse method
of this field was not called and so the email was not propagated.

The best solution would be to use "force_save" on those fields. But
this feature only works on readonly fields.

So, we simulate a real "force_save" on the email / phone, directly in
JS. That way the inverse will be called, and if necessary, the email /
phone will be propagated.

Task-2704904

closes odoo/odoo#84426

X-original-commit: 72718877
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: flch-odoo <flch@odoo.com>

For the moment we cannot groupby an inherited field (which is therefore related) in a graph view, so it is counted as being non-stored.
Because in the `_normalize` function we do not process fields that are not stored, whereas like here

https://github.com/odoo/odoo/blob/d679cd0d8ba9a2420e81a42a698763e9be2327e1/addons/web/static/src/legacy/js

 /control_panel/groupby_menu.js#L45-L49.

Typically when a field has store=False but sortable=True it is inherited from a stored field, so it can be sortable
So we have to use `sortable` instead of `sort` to make it consistent.

opw-2733133

closes odoo/odoo#83390

Related: odoo/enterprise#24315
Signed-off-by: Achraf <abz@odoo.com>

While calling `_stock_account_prepare_anglo_saxon_out_lines_vals`, the line
`credit_expense_account = accounts['expense'] or self.journal_id.default_account_id`
can cause a 'Expected singleton' error. During upgrades from v13 and earlier,
the value used for `accounts['expense']` is always `None`.
If the recordset in `self` contains more than one record, the error will happen.

By replacing `self` with the iteration object `move`, this error is averted.

The error happened during an upgrade from v13. Since the value assigned to
`accounts['expense']` doesn't exist in that version, it goes to
`self.journal_id.default_account_id` to grab it.
If `self` has more than one record, the error happens.

Traceback:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1199, 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 475, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
    migrate(self.cr, installed_version)
  File "/tmp/tmpae3wx5o6/migrations/account/saas~13.4.1.1/end-09-payment-refactoring.py", line 618, in migrate
    util.iter_browse(env["account.move"].with_context(**ctx), ids, chunk_size=1024).action_post()
  File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in caller
    return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
  File "/tmp/tmpae3wx5o6/migrations/util/orm.py", line 197, in <listcomp>
    return [getattr(chnk, attr)(*args, **kwargs) for chnk in chain(it, self._end())]
  File "/home/odoo/src/odoo/14.0/addons/sale/models/account_move.py", line 14, in action_post
    res = super(AccountMove, self).action_post()
  File "/home/odoo/src/odoo/14.0/addons/account/models/account_move.py", line 2715, in action_post
    self._post(soft=False)
  File "/home/odoo/src/enterprise/14.0/l10n_mx_edi_landing/models/account_move.py", line 26, in _post
    return super()._post(soft)
  File "/home/odoo/src/enterprise/14.0/l10n_mx_edi/models/account_move.py", line 456, in _post
    return super()._post(soft=soft)
  File "/home/odoo/src/odoo/14.0/addons/sale/models/account_invoice.py", line 75, in _post
    posted = super()._post(soft)
  File "/home/odoo/src/odoo/14.0/addons/purchase_stock/models/account_invoice.py", line 171, in _post
    return super()._post(soft)
  File "/home/odoo/src/enterprise/14.0/account_reports/models/account_activity.py", line 75, in _post
    return super()._post(soft)
  File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 49, in _post
    self.env['account.move.line'].create(self._stock_account_prepare_anglo_saxon_out_lines_vals())
  File "/home/odoo/src/odoo/14.0/addons/stock_account/models/account_move.py", line 158, in _stock_account_prepare_anglo_saxon_out_lines_vals
    'account_id': credit_expense_account.id,
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 3821, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: account.account(1383, 38, 30)
```

closes odoo/odoo#84100

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

The function `arrayToString` did not properly support domains containing
arrays of booleans, for instance `[["val", "in", [true, false]]]`. The
array containing the boolean was directly JSON stringified without being
converted to its python equivalent.

closes odoo/odoo#84425

X-original-commit: 9b63ec35
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Lucas Lefèvre <lul@odoo.com>

Only show the leaves taken by the current employee when using the Leaves
stat button on an employee's form.

closes odoo/odoo#84553

Taskid: 2764912
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Prior to this commit, when a user searches with an upper case search
term of more than 3 characters, the search was considered as a fuzzy
search even if the result was an exact match.

Since the search is always lowered when there are more than 3
characters, the search is considered as fuzzy only when the search and
fuzzy term are case insensitively distinct.

closes odoo/odoo#84433

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

closes odoo/odoo#84300

Signed-off-by: Raphael Collet <rco@odoo.com>

Part-of: odoo/odoo#84300

When a pos launched by a user having no access rights on sales order
lines is launched. It cannot have access to the coupon program because
it tries to get the computed field order_count that needs to read the
sale order lines.

closes odoo/odoo#84544

Task-id: 2742528
Signed-off-by: Masereel Pierre <pim@odoo.com>

When a coupon is generated from POS order, you get a traceback saying
you don't have access rights on "coupon.coupon" when you are only a pos
user.

So when we need to create the coupons and write on it, we are doing it
in sudo, to let the pos process generate the coupon.

Task-id: 2742528
Part-of: odoo/odoo#84544

The aim of this commit is to set partner on anglosaxon
aml in order to help our client in their stock
reconciliation process in case it hasn't been done automatically.

Before this commit:
anglosaxon line were created without partner

After this commit:
A partner is set when anglosaxon line are created

closes odoo/odoo#84525

Ticket: 2692308
Community-pr: https://github.com/odoo/odoo/pull/84468


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

Steps to reproduce the bug:
- Go to inventory > configuration > Products > Attributes
- Create a new Dynamic Attributes > add two attribute values
- Create a storable Product “Test”:
    - Add the two attributes
    - Save
    - Create a BOM related to this product
- Create a new manufacturing order:
    - Do not choose a product
    - Select the BOM related to the product “test”

Problem:
Traceback is triggered because as the product template only has dynamic variants, there is not a `product.product` record created yet.
but we try to access it in the onchange: https://github.com/odoo/odoo/blob/14.0/addons/mrp/models/mrp_production.py#L598



Solution:
do not set the product when a BOM of a product_tmpl without a variant was chosen
opw-2732254

closes odoo/odoo#84522

X-original-commit: 50b538e7
Signed-off-by: Arnold Moyaux <arm@odoo.com>

Current behavior:
When trying to open the gift card list you get an access error if one of the cards has been used in another company.
This error appears because you cannot access SO from another company and the used gift cards were linked to a SO.
So shouldn't be able to use a gift card that was created in another company.

Steps to reproduce:
-Create a gift card in company A
-Use it in company B
-Try to access it from company A
opw-2732973

closes odoo/odoo#83901

Signed-off-by: Masereel Pierre <pim@odoo.com>

closes odoo/odoo#84509

Related: odoo/enterprise#24302
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Steps to reproduce:

 - Activate Debug mode
 - Go to Settings -> Companies
 - Create company A and B and set a different favicon for each company
 - Refresh the page or switch company

Issue:

  The favicon is not the right one.

Cause:

  Code (that update favicon) removed when refractoring of owl.
  Related commit: https://github.com/odoo/odoo/commit/0573acae2306bf5da2005852da9323ddc59e5431



Solution:

  When web client start, update in JS the favicons (desktop and mobiles)
  with current company favicon.

opw-2664525

closes odoo/odoo#80113

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

The configurator introduced at [1] uses a frontend controller to
display its content. However this results in inconsistent language
translation as the python code uses the users's language but the
localization services uses the frontend's language when on a frontend
page.

Steps to reproduce:
- Create a database with the only language being french
- Install website
- In the configurator, all the pages will be in french except
  "Pages and Features"

With this commit, the language for the configurator will always be
the language of the website it's configuring. A test also make sure
that this is the current behavior.

[1]: https://github.com/odoo/odoo/commit/e8a5af2e28a4724f86783746706cb59175f086bf



task-2687416

closes odoo/odoo#80055

Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: JKE-be <jke@odoo.com>