The Debian package is replacing some fonts by a soft link to the Debian
packaged ones.

The glyphicons-halfings were for bootstrap 3.x which is not used anymore
in Odoo, resulting in harmless broken links in the Debian package.

Closes odoo/docker#453

closes odoo/odoo#125796

X-original-commit: bcc68143
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

opw-3266332

closes odoo/odoo#126991

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

closes odoo/odoo#126976

Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

Syntax Error generates when the user gives invalid python code in 'account_tax'
module and uses that tax while creating invoice.

Steps to produce:
 * Install 'account_tax_python' module
 * Go to configuration/taxes and create a new tax.
 * Select Tax Computation as 'python code' and give some special characters to
   python code field and save it.
 * Now create an invoice, add a  product and add the above created tax in taxes.
 * At this moment traceback raises.

By applying these changes will resolve this issue.

closes odoo/odoo#126940

Sentry: 4060222060
X-original-commit: 74642632
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

When having lock date for non advisor
set before all user lock date, reconiling
lines between the two lock dates leads
to a wrong calculation of the cash basis
move, even for user with advisor rights.

Steps:

- With a company having cash basis activated
- Set a period_lock_date to a specific date
- Set a fiscalyear_lock_date one month later
  than period_lock_date
- With user having Advisor rights, create
  an invoice between the two lock dates
- Register a payment in the same period
-> Cash Basis move is created with date == today,
   it should be the date of the payment.

opw-3245409

closes odoo/odoo#126873

X-original-commit: 15fec0b0
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Bug
---
Let's say you make an expense in a foreign currency on date A. Then
you include this expense in an expense report. You set the report's
accounting date to B and post the journal entries. The system will
calculate the expense amounts based on the exchange rate on Date B.
But really, it should be using the exchange rate from Date A, the day
when the expense was made.

Steps to reproduce
------------------
* Enable multicurrency and make sure that you have different exchange
  rates configured for two different dates, which we'll refer to as
  Date A and Date B.
* Create an expense with a foreign currency and set the expense date to
  Date A.
* Save and click `Create Report`
* Submit to manager, and approve the report
* Navigate to the 'Other Info' tab and set the report's accounting date
  to Date B.
* Save and post the journal entries

Now, review the generated journal entries. You might notice that the
expense values have been calculated using the exchange rate from Date B,
rather than Date A.

opw-3119959

closes odoo/odoo#126922

X-original-commit: b6408e0d
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>

Before this commit:
The channel name used to overflow in the channel suggestion section.

After this commit:
The name will not overflow in the channnel suggestion section.

Task id: 3366608

closes odoo/odoo#126867

X-original-commit: d629710f
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

closes odoo/odoo#126800

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

The error will occur when a user try to print POS inalterability check report
for pos orders when accounting is not unalterable for that company.
steps to produce:

1. install l10n_fr_pos_cert the  module
2. switch to company other than FR company
3. pos > reporting > POS inalterability check .

when the company's country is not in unalterable country :
https://github.com/odoo/odoo/blob/3b88958f5a07edf86d2fc9c8080ee46d16b872ef/addons/l10n_fr/models/res_company.py#L14-L24

1. so,`_check_pos_hash_integrity()` gets Nonetype which will lead to above
traceback, when trying to update the data dictionary.
2. Also, `_check_hash_pos_integrity()` is not defined in our standard code so ,
this commit optimize the `_get_report_values` method.
see : https://github.com/odoo/odoo/blob/3b88958f5a07edf86d2fc9c8080ee46d16b872ef/addons/l10n_fr_pos_cert/report/pos_hash_integrity.py#LL11C1-L22



sentry-4243853702

closes odoo/odoo#126798

X-original-commit: 131edcc1
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>

A TypeError is thrown when an AST node is passed to `literal_eval`
because a string is expected and the object has no len().

Check the type of the expression and make sure it's a string before
calling len() on it.

closes odoo/odoo#126551

Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

[FIX] account : fixes wrong domain of invoice and bill, uses 'in' operator to match move_type against a tuple instead of '=' operator.

closes odoo/odoo#126762

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

X-original-commit: 92248086
Part-of: odoo/odoo#126762

Before this commit, when going to /profile/ranks_badges on the website,
an error 500 happened when it had to show certification badges.
This is because the certification badges use the "state" field of their linked
survey to check if it is still open.
This field has been removed in 15.0, where the active state of the survey is
used to know if it is still used instead of a state.  When archiving a
certification survey, their linked badge is automatically archived as well,
so there is no need for that line anymore.

opw-3373973

closes odoo/odoo#125752

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

Before this commit, if you reset your microsoft callendar account and
set to remove events from Odoo, it won't remove them. The problem is
that the ('ms_universal_event_id', '!=', False) condition is not
implemented, and it can't remove the existing events.

opw-3382445

closes odoo/odoo#126674

X-original-commit: c4d8530c
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>

In Website, since the `#wrapwrap` element is being scrolled on the
pages, we added a function called `compensateScrollbar` (added by this
commit [1]) that adds space on the right side equal to the width of the
scrollbar when a modal is open or to adjust the position of the fixed
header when a page is scrolled.

However, this `compensateScrollbar` function did not handle RTL pages
correctly, where the scrollbar is on the left instead of the right. As a
result, on RTL language pages, this space was added on the wrong side.

This commit fixes the issue by placing the space on the left instead on
RTL pages.

Steps to reproduce the bug:
- Select Arabic as the primary language for a website.
- In edit mode, drag and drop a popup onto a page.
- Bug: When the popup is open, space is added on the right to compensate
for the scrollbar, but it should be on the left instead.

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



task-3102275

closes odoo/odoo#126663

X-original-commit: 9e126f7f
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Have an invoice in foreign currency
Open "Register Payment" wizard
Have wizard currency as company currency
Change wizard date

Issue: amount will not recompute

opw-3357669

closes odoo/odoo#125049

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

Before this commit, if you stopped sync with microsoft, and
refereshed the calendar, it would change the button back to
synced status.

opw-3382311

closes odoo/odoo#126077

Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>

The return tax should only be used through its parent tax,
we don't want it to be accessible directly on bills or invoices.

opw-3347425 (2nd issue)

closes odoo/odoo#126527

X-original-commit: 7b07df87
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>

When a user tries to access the URL directly, at that time the value of
dictionary `kw` is not available. The error will be generated.

Error : KeyError: 'state'

This commit will prevent the traceback.

sentry-3947033806

closes odoo/odoo#126346

X-original-commit: dfc1a188
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>

Before this commit, in other numbering systems than "latn", the time
pickers did not allow to select hours/minutes/seconds. This was because
the lib (TempusDominus) would use `parseInt` internally to retrieve the
selected value, which was not a latin number in other numbering systems.

This commit changes 2 things directly in the lib file:

- allow the internal `getMoment` function to accept a second 'format'
parameter;

- use that same `getMoment` function to parse the text of the selected
value, effectively using moment to both parse and format the values
displayed in the picker and ensuring consistency.

OPW-3258034

closes odoo/odoo#126528

X-original-commit: 3072cb56
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

closes odoo/odoo#125781

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

closes odoo/odoo#126439

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

Some account terms are mistranslated, this PR aims to fix these translations. The customer provided a table with the mistakes and suggestions. The customer’s suggestions are available in the ticket.

How to reproduce:
1. Ukrainian translation > chart of accounts > some terms are mistranslated

closes odoo/odoo#125986

Opw: 3247005
X-original-commit: c19472f1
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Matheus Leal Viana (malv) <malv@odoo.com>

Form fields can be prefilled since [1] and their visibility
conditionally linked to other fields since [2].
1. This commit ensures prepopulated fields trigger the conditional
visibility mechanism (A), including when said field is first hidden,
then conditionally displayed (B).
2. Until [3], with a chain of visibility conditions, when one of them
was "contains", "does not contain" or a date-related condition, a
traceback was raised (C). This commit corrects the fix from [3] to
prevent this behavior now that the reason has been identified.
3. Tests are also set up to enforce these fixes.

Steps to reproduce (A):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated from user mail
- Save and check the form: A won't be shown despite B being set
- Removing one letter or typing anything in the input B will trigger
the visibility of A.
- Expected result: B should immediately appear.

Steps to reproduce (B):
- Drop a form
- Make field A depend on field B being set
- Have field B be autopopulated and depend on field C being set
- Field C is empty by default
- Save: only field C is shown. Type a letter: field B appears, but not
field A.
- Expected result: both should appear.
Note: this bug only occurs when field A is before field B.

Steps to reproduce (C) (until [3]):
- Drop a form
- Field A depends on B containing "abc"
- Field B depends on C being set
- Save and type something in C: there is a traceback.

task-3335536

[1]: https://github.com/odoo/odoo/commit/54873d2
[2]: https://github.com/odoo/odoo/commit/2dcbfec
[3]: https://github.com/odoo/odoo/commit/2714469



closes odoo/odoo#122044

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

It is currently impossible to cancel a payment through edi

Steps to reproduce:
1. Install l10n_mx_edi and Accounting
2. Set company to 'Escuela Kemper Urgate'
3. Go to Accounting and create a new invoice for customer Deco Addict
   with due date: 2 months and product: Large Cabinet (edit it and
   specify any UNSPSC category to the product in the Accounting tab)
4. Save and confirm the invoice, then register a payment with payment
   way 'Transferencia electrónica de fondos'
5. Go to the payment (through the little "i" next to the total)

Solution:
Add buttons and methods to cancel and abandon the cancellation of a
payment

opw-2926261

closes odoo/odoo#108973

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

When parsing an email containing an xml attachment, the `email` python
module will decode the base64 attachment using the charset or ascii if
the charset is missing.

In some cases, the payload is in UTF-8 but the charset is omitted. This
results in replacement characters for the non ASCII characters.

The solution is to force the charset to UTF-8, since it is a superset of
ASCII that should not be a problem.

NB1: Omitting the charset for text/xml is not recommended. See the RFC
(section 6.4): https://www.ietf.org/rfc/rfc2376.txt



opw-3144519

closes odoo/odoo#126323

X-original-commit: b2aa5883
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

In the start_sync method, the logger is updated to use the 'warning' level
instead of the 'error' level. This change reflects a less severe logging level
for cases where sending a partner to sync fails.

The changes have been made to reduce the noise level in the sentry.

sentry-3955309841

closes odoo/odoo#126025

X-original-commit: c1b608c2
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>

Currently, it's not possible to check the 'Peppol Bis 3' option on the
journals of Italian companies, since Italy is not present in our mapping
`COUNTRY_EAS`.

The EAS for Italian companies may be the codice fiscal (code: 0210) or
the VAT number (code: 0211). See
https://peppol.agid.gov.it/en/news/expiration-validity-codes/



Use the VAT number by default, and add it in our mapping such that the
option now appears for Italian companies.

opw-3346572

closes odoo/odoo#126203

X-original-commit: 030b55b2
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

This commit ensures that the unsplash beacon calls home when an unsplash
image appears on a page.

To achieve this it patches the RPC call when the test URL contains the
test name as parameter. The patch cancels the actual beacon call to
avoid polluting data during the test, but marks the image as having had
its beacon message sent. The test then simply checks if this marker
appears on the image.

task-3360109

closes odoo/odoo#126026

X-original-commit: a5abc766
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

When a user creates a link that is tracked, an interface with graphs is
presented to him so that he can track the performance of his tracked
link. Unfortunately, these graphs did not work when the site was in a
foreign language. This was due to the fact that the code had not been
designed to handle this. This commit fixes the code so that it works in
all languages.

Note that the data is received via RPC and the python code format the
dates for the current language of the website. So we had to do a little
hack to make it work properly.

Steps to reproduce the issue:
- Install website_links module
- Go to the website app
- Click on Promote > Link Tracker
- Create a tracked link
- Visit the link
- Install Arabic (Syria) for your website
- Check the stats of your link in Arabic

=> There is a traceback and the data is not displayed.

task-3289167

closes odoo/odoo#126172

X-original-commit: e690da6e
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

If the user change a location type of the 'Production' from inventory locations
and installs the 'MRP' module, the traceback will appear.

Steps to produce:
- Install Stock module.
- Inventory > Configuration > Settings > enable the Storage Locations.
- Inventory > Configuration > Locations > Remove the filter 'Internal'.
- Open the 'Production' location and change the Location Type to 'View'.
- Now install the 'Manufacturing' module.
Error: A traceback appears: 'ParseError: while parsing
/home/odoo/src/odoo/saas-16.2/addons/mrp/data/mrp_data.xml:17, somewhere inside'

At the time of installing the MRP module, it will search for the production
location using the location type as the production here - https://github.com/odoo/odoo/blob/f65a9bffe2cbc03b2efc969dc205c9ba01ee9ab5/addons/mrp/models/stock_warehouse.py#L65


If the production location is not found it will raise an userError. In this
commit, the production location is created based on the company if not found. It
will lead to the above traceback.

sentry-4215564628

closes odoo/odoo#125885

X-original-commit: e8ce51dd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>

Steps to reproduce:
- Install the lux localization
- Configure Peppol for a customer: Select a customer > tab accounting > under "electronic invoicing":
format: Peppol BIS Billing 3.0
Peppol e-address: 0130 - Directorates of the European Commission
Peppol Endpont: testendpoint

- Create an invoice for the peppol customer
- Add a section or a note in the Invoice
- Confirm the Invoice

Issue:
Raise user error:  Odoo requires a tax for EACH LINE, instead of each product

Solution:
Exclude the section/note line

opw-3354757

closes odoo/odoo#126225

X-original-commit: fb716296
Signed-off-by: Laurent Smet (las) <las@odoo.com>

Revision odoo/odoo@cabb9e7e573b86cd523980588360d8514090d370 introduced a
regression: This is no longer possible to import a data module
using `<field file="..."/>` in their data file.

This revision targets to restore the feature as expected.
The unit tests added covers the feature, so that regression
no longer happens in the future.

It introduces a new concept of temporary directory `file_open`
can read from.
e.g.
```py
with odoo.tools.file_open_temporary_directory(self.env) as module_dir:
   with zipfile.ZipFile('foo.zip', "r") as z:
      z.extract('foo/__manifest__.py', module_dir)
   with odoo.tools.file_open('foo/__manifest__.py', env=self.env) as f:
      manifest = f.read()
```

Note that `file_open` will be allowed to read from that temporary
directory only if `env` is passed to `file_open`,
and if the `env` is part of the same transaction/request than the `env`
passed to `file_open_temporary_directory`.

This is to avoid having users, whether from other databases,
or even the same database,
trying to access these directories not belonging to them.
e.g. If an admin uploads sensitive data in this temporary directory,
no one than him must be allowed to read from these files, not even
another user from his database.

closes odoo/odoo#126278

Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

The code snippet removed by this commit had no useful effect, as
`selection.addRange(range)` a few line above triggers
`OdooEditor._onSelectionChange`, which repositions the toolbar
elsewhere.

The result was a "glitch": the toolbar would briefly be displayed over
the top left corner of the media before finally being displayed above
(or below) it.

This commit removes such undesirable effect.

task-3347942

closes odoo/odoo#123568

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

Before this commit the position of the arrow was incorrect when the
editor is inside an iframe.

For the calculation of `arrowLeftPos` we need the difference between
the selection rectangle border and the toolbar's left position.
While `correctedSelectionRect.right` is relative to the current iframe's
borders, `left` is relative to the top document's window, as it has been
offset with `parentContextRect.left`. We need both values to be relative
to the same referential in order to make this calculation make sense.

task-3347942

Part-of: odoo/odoo#123568

Before this commit, an error in the toolbar position happened when the
editor was inside an iframe and the iframe's window had scroll bars.

Steps to reproduce:
- go to the Market Automation app (enterprise edition)
- create new campaign
- add new activity
- create a new mail template by typing a name and selecting "create and
edit"
- select the "plain text" theme
- add a lot of content in order to have the scroll bars
- scroll down
- select something to display the toolbar

The `scrollX` and `scrollY` variables in `_positionToolbar` are ment to
correct the floating toolbar position in case the document in which the
toolbar is mounted has some scrolloffset.
As the floating toolbar is always mounted on the body of the top
document, this is the document to watch for scroll offsets, and not the
inner document when the editor is mounted inside an iframe.

task-3263463

Part-of: odoo/odoo#123568

Since [this other commit], initializing the color picker could trigger a
traceback. The traceback was due to the fact that for users to be able
to drag/move the color picker as they wished across different frames, we
needed access to the document of all the frames on the page.
Unfortunately, if one of these frames was not of the same origin, a
traceback was displayed. This commit corrects how we collect documents
from frames on the page, by only taking those whose document we have the
right to see (which do not raise a cross origin error). I didn't succeed
to reproduce the bug locally, but I got it on the runbot with theme
Nursery / Kiddo by dropping the block banner on the page, the error
appears because the block contains a vimeo video. In fact, you just need
to have embedded content (youtube / vimeo / ... video for example) start
edit mode, click on the block containing the video and the error is
displayed.

[this other commit]: https://github.com/odoo/odoo/commit/63bf363d302fe9f93a824fa6f1ff3bbe21f98088



runbot-22573

closes odoo/odoo#126240

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

JSONDecoderError occurs when users enters invalid JSON format data in
'Default Value' field inside 'User-defined Defaults' and wherever this field is
being accessed to get default value this traceback will be generated.

Steps to reproduce:
1) Install 'Contacts' module.
2) Open 'Settings' > 'Technical' > 'User-defined Defaults'.
3) Click on record 'Language' > 'EDIT' button > in 'Default Value' field enter
   any improper JSON format data (e.g 'Maa' : FI ) .
4) Now, open 'Contacts' module > click on 'CREATE' button and traceback would be
   generated.

By applying this, it will check for proper JSON format.

Sentry-4169062951

closes odoo/odoo#126202

X-original-commit: 0e6e322d
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>