When creating an invoice with 'Down payment' option for an SO, it should
first consider income account of the 'Deposit Product'. if it does not
have one then it should consider that product category's income account.

Fixes #23100
Task# 1819531

Since April 1, 2018, free versions of GeoLite Legac y databases are no
longer updated and free downloads not available [1].

[1] https://support.maxmind.com/geolite-legacy-discontinuation-notice/

If a user set a procurement to the day N, the procurement datetime field would
be set to day N at midnight. So any negative timezone make it appear that the
procurement is set to day N-1.

opw 1831272

Since July 1, 2007, the Sudanese pound is the only legal tender.

Closes #13802

- Go to Timesheets > Add a Line (grid view)
- The view opened is `view_timesheet_form`
- Add a description with several lines
- Go to Project, and display the timesheet entries.
- Print the report "Timesheet Entries"

The lines in the description are merged into one single line.

Since it is possible to write a description on several lines, the report
should keep the formatting.

opw-1830703

The former version of the tax adjustment wizard was copying the selected tax on both the credit and debit line of the created journal entry. Although it was fine for the belgian use case (since the report was taking only the sum.debit or sum.credit to gather data for grid 61/62), this was a stupid limitation as it was preventing to use that wizard to touch any grid using sum.balance (as both lines would be taken into account and cancelling each other).

To enhance/fix this, we introduce a fields.selection in the wizard to depict if the tax needs to be copied on the debit OR the credit line.

Inspired by ticket 1826242.

In arabic, with the version localization of bootstrap we use the week
starts on saturday. But the version of bootstrap-datetimepicker we use
in 10.0 and saas-14 is 3.0.3 which only fully supports week starting
on sunday and monday.

Thus in arabic, the column title in the date picker would be:

  Sunday <- Monday (ﻥ, ﺙ, ﺭ, ﺥ, ﺝ, ﺱ, ﺡ)

Instead of what the numbered days in the calendar are shown as:
  Friday <- Saturday (ﺱ, ﺡ, ﻥ, ﺙ, ﺭ, ﺥ, ﺝ)

This issue doesn't happen in saas-15, 11.0 and over since the library
has been updated with ad6fd5f8 and the as of version 4 supports any
starting day of week, with this change:
 https://github.com/Eonasdan/bootstrap-datetimepicker/commit/557b657

opw-1825640
closes #24200

In 93147fb4 the issue that only one page of barcode were printed was
solved.

But there is still an issue since the container element is itself a
page, we got an additonal page with all barcode on it.

To solve this we use a 'report.html_container' instead of
'report.basic_layout' which doesn't wrap the content with a
`<div class="article" />` element.

opw-1827673
closes #24201

Seems like this tour crash randomly due to default 10000 ms.

This button, in some case, seems to take more than 10000ms (slow server? slow
connection ?) to validate the order (cretae invoice, generate PDF, send mail, ...)

It is a test to see if increase the timeout could decrease the risk of false
positive on the runbot.

The sale_note field is translated according to the language of the customer in a SO.
This fix applies the same behavior on the customer invoice.
Inspired from this commit: 978b8f64

opw:1830838

Before this commit, an error was raised when you tried to create a
new bill of material on a new manufacturing order.
In fact, the name_create RPC returned 'false' and slow_create()
wasn't executed.

By adding _rec_name (as in 10.0) on the corresponding model, the RPC
call will raise an error that will be caught by quick_create and
forces slow_create().

Closes #9761

Inside the cell of a table, indenting had several behaviors:

- if the selection is contained in several nodes elements: indent the
  element child nodes of common ancestor

- if the selection is contained in one or more list items: indent these
  list items

- if the selection is contained in one 'content block': indent the whole
  cell content

The two first behaviors are expected, but the third one is a little odd
and unexpected next to other existing editors behaviors.

With this commit, the third behavior becomes:

- if the selection is contained in one `content block`: indent this
  content block

note: 'content block' is defined as p, pre, h1, h2, ..., blockquote, td

opw-1824647
closes #24182

Due to historical reasons the amount on a statement line is used to
find it again so the credit card information can be added to it.

Doing a search directly on 'amount' will fail in rare cases when
the currency rounding doesn't result in a float with the same amount
of decimals as the rounding specifies. E.g.:

>>> currency = env['res.currency'].browse(3)
>>> currency.rounding
0.01
>>> currency.round(74.85000000000001)
74.85000000000001

When that happens the credit card information is not saved in the
backend. To avoid this we do the float comparison properly with
float_compare afterwards.

PS. Ideally the logic in add_payment should be moved to an override of
_prepare_bank_statement_line_payment_values. This way we wouldn't have
to do these awkward things to find the statement line. But this
approach is not suited for a stable release.

opw-1832156

Before this patch, when a user was editing a website page containing a form
and he clicked "Send", for some reason, the form tried to be sent.

Now, the button behavior is disabled when entering editable mode.

Closes #23852

Urls like `/page/website.XXX` are redirected to `/page/XXX`.

Before this commit, the redirection would not keep query strings:
`/page/website.XXX?rde=1` would redirect to `/page/XXX`.

Now, we keep the query strings:
`/page/website.XXX?rde=1` will redirect to `/page/XXX?rde=1`

Closes #24140

Courtesy of @MTantin

- When validating an invoice, the create method of the model account.asset.asset is called.
  Accountant have the access rights to create account.asset.asset object, but they do not have the rights to write on them.
  The issue here is that the create of the account.asset.asset is done, but right after a right is done in the same object, which trigger an AccessError.
  To fix this issue, we make the write using the admin env. This doesn't cause security issues since the user needs the create accesses.

OPW-1832797

- When creating a Stripe charge, we have the possibility to send the customer email.
  This is then used by Stripe to send a payment notification (receipt) to the customer.
  This was never done by Odoo, this commit introduce this feature.

OPW-1829945

It used to be possible to run test transactions against mercurypay.com
using a regular swiper device, test credentials and test cards
provided by Mercury.

Mercury has recently disabled this saying this feature did not adhere
to certain PCI regulations.

It means that currently on the regular mercurypay.com network only
real cards (and thus real money) can be used.

Because we require a way to test without spending money this commit
allows to switch to the test network (mercurycert.net). It uses a
system parameter because we cannot introduce a Boolean on
pos_mercury.configuration in a stable release. It also changes the
test credentials to some that work on mercurycert.net.

Note that the regular 'production' swiper devices can not be used on
this test environment. This results in:

Error 004118: Failed to decrypt

The swiper contains embedded cryptographic keys specific to
mercury*pay*.net. Instead a specific 'development' swiper device with
embedded keys for mercurycert.net is required.

opw-1832156 (this is necessary to test that issue)

- Install stock_calendar
- Create a stockable product
- Add the route "Buy"
- Add a vendor with a delivery lead time of 30 days
- Create a reordering rule for x units
- Run the schedulers

A PO is created, but the scheduled date is set as today, not today + 30
days.

What happens is the following:
1. Since no `calendar_id` is defined on the orderpoint, `_get_group`
   returns `[(now, None)]`
2. `now` is used in the `procurement_values` of the `res_groups` by
   `_procurement_from_orderpoint_get_groups`
3. The `res_groups` values are used in `_procure_orderpoint_confirm`
   when calling `_prepare_procurement_values`.
4. `_prepare_procurement_values` is overridden by `stock_calendar` to
   set a value for `next_delivery_date`. At this point, the `now` value
   is used.
5. Finally, when creating the PO line, `_prepare_purchase_order_line` is
   overridden by `stock_calendar` to set the `next_delivery_date` as
   `date_planned`.

So, `date_planned` becomes `now`.

There should not be any date set when no `calendar_id` is defined.

opw-1828371

In order to improve the speed of landed cost validation, we defer the
creation of AML at the very end of the process. This way, we don't
suffer from various performance issues caused by:
- cache invalidation (use of `with_context`)
- recomputations

opw-1824661

When the user set a decimal accuracy on the product quantity, the point_of_sale
(POS) frontend would display the correct rounding of the quantity according to
both the decimal accuracy and the rounding set on the unit of measure.
However the quantity used to compute the price was only using the rouding on the
unit of measure. This led to an inconsistency in what is encoded in the backend,
and thus made it impossible to close the session as the price paid by customers
did not match what is encoded.

The problem comes from the fact that there is a variable this.quantity and
another one to display this.quantityStr. Unsurprisingly, this.quantityStr
was not computed directly from this.quantity, leading to the inconsistency.

opw 1826092

Steps to reproduce the bug:
-Let's consider a multicompany environment with company A and B
-Let's consider a shared product P for A and B
-P has a deferred revenue type D set on it
-D is defined in A
-Let's consider a user U in company B
-U creates a SO with P and try to generate the invoice

Bug:

A access error was raised because U is not allowed to see D and
D is needed to genrate the invoice.

opw:1825944

When validating a statement with old posted moves, the lock date
was checked by function, _check_lock_date and then it was impossible
to validate the statement even if all the moves were already posted.

Backport of this commit: 86a0d312

opw:1830804

Install a database in some other language than en_US
In debug mode and in the app list viewer,
   you'll see that the apps field are translated into your language
Then do an "Update App List"
Reload your page

Before this commit, the Apps' field lost their translation
This was because when checking for any updated data for known modules,
the ORM fetched the translation automatically, and compared the old (translated)
value with the new (English) value from the manifest

After this commit, This operation doesn't make the translations to be lost,
because only english values are compared

OPW 1832796
closes #23910
closes #24091

Since 3d04e448, several pages have to be denoted by:

  `<div class="article" />`

And not as previously:

  `<div class="page" />`

This was not taken into account in the "Location BarCode" report so we
had only one page of barcode (so 4 barcodes since there is 4 barcode by
page) displayed.

fixes #19698
opw-1817574
closes #24098

The id of the record may be a real database id or a string containing a virtual
id (e.g. "42-20380119031417").
The id is always stored as a string but must be converted to int when sent to
the ORM (to avoid self.browse('42'))

The calendar modules do handle correctly virtual ids in its unlink method but it
is not the case of the other modules that are expecting integers.

Convert to int if we are working with real ids

Replace and closes #22115

Closes #24079

Done at #24083

self is a rml_parse instance, not a BaseModel
create new environment to call ORM methods
prevent crash when calling formatLang on a RML report

Closes #24068