Infinite number of records cannot be exported, so after some limit we will get a
timeout error. If you need to export more records than that limit, you should be
able to filter records into batches. The easiest way to do it is making a
filter by ID:

```
[Y| ID Greater than 100000] [Y| ID less than or equal to 200000]
```

---

opw-2517946

closes odoo/odoo#71345

X-original-commit: 2e0127af
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

Fine tuning of
https://github.com/odoo/odoo/commit/bdd36f7ce68999576dfc30298f4ddf2572b4c7ec


to perform the assignment and related operation only when 'consignment' is
enabled

opw-2508371

closes odoo/odoo#71396

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

On a delivery, when changing the initial demand of a stock move, if its
value was 0 and becomes > 0, its state will be 'Partially Available' but
the reserved quantity will still be 0.

To reproduce the error:
1. Create 2 products P01, P02
    - Product Type: Storable
    - Qty On Hand: 1
2. Create + Confirm a SO with 1xP01 and 1xP02
3. Open SO's delivery
4. Unlock, set P01's initial demand to 0, Save, Lock
5. Unreserve, Check Availability
6. Unlock, set P01's initial demand to 1, Save
7. Click on PO1 line

Error: The stock move state is "Partially Available", but the initial
demand is 1 and the reserved quantity is 0. It should be "Waiting
Availability"

On step 5, since the wanted quantity of P01 is 0, the state of the stock
move becomes "Available". Then, when increasing the requested quantity,
the state automatically becomes "Partially Available" because the module
does not consider the case where the state is "Available" with a
reserved quantity equal to 0.

OPW-2488580

closes odoo/odoo#71371

X-original-commit: 5773a1e0
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Steps:
- Install sale
- Go to Settings / Translations / Languages
- Activate Dutch
- Go to Settings / Users & Companies / Users
- Edit demo
  - Language: Dutch
- Go to Sales
- Create a quotation:
  - Customer: demo
- Go to Settings / Technical / Automation / Scheduled Actions
- Create a new action:
  - Model: Sales Order
  - Python code:
  ```python
  last_id = model.search([], order='id desc', limit=1)[0].id
  env.ref('sale.email_template_edi_sale').send_mail(last_id, notif_layout='mail.mail_notification_paynow')
  ```
- Click "Run Manually"
- Go to Settings / Technical / Email / Emails
- Open the last email you just sent

Bug:
Parts of the email are not in Dutch

Explanation:
This commit makes a template pass the rendering language to the layout
and the display name when calling `template.send_mail()`.

opw:2467640

closes odoo/odoo#68656

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

The container size of a text block snippet (and every snippet without
rows) was not correct when an image was displayed with right or left
alignment.

The css property clear was added at the end of the containers so that
floating elements from the section do not float over the next section.

task-2469516

closes odoo/odoo#69621

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

closes odoo/odoo#71393

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

When trying to filter links by a tracked URL code, the following warning
is shown:

    WARNING dbname odoo.models: Cannot execute name_search, no _rec_name
	defined on link.tracker.code

and the applied filter gives all records.

closes odoo/odoo#71376

X-original-commit: 3687dabbc373e57e24ca4596c18ef1dacfde8273
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>

Steps to reproduce the bug:
- Install Accounting
- Connect with a user who has a default company (e.g: Company A) and allowed companies (e.g: “Company A” and “Company B”)
- Choose in the company selector “Company B”
- Make sure that the onboarding panel in the default company has not been closed
- Go to accounting and close the onboarding panel
- Refresh the page

Problem:
The onboarding panel is still open because in the `account/account_dashboard_onboarding` method we check the`account_dashboard_onboarding_state` field of the default company instead of the current company because "allowed_company_ids" is not in the context
This problem is also present in all the other views where an onboarding panel is present

Solution:
Add the context in the parameters of the rpc in the _renderBanner

opw-2477148

closes odoo/odoo#71384

X-original-commit: 90295054
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>

When an invoice is created from pos having a cash rounding method, the
value of the rounding can depend on the payment methods.

When no rounding has been applied because of the order has been
partially paid by cash and bank, the rounding line should be deleted
from the invoice. We should also adapt the terms lines.

closes odoo/odoo#71375

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

Because the `receiptHtml` was taken from a component which was mounted outside of the DOM, it was hardly ever destroyed for some unknown reasons and the `el.outerHTML` could not be taken to create the receipt.

closes odoo/odoo#71087

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

To reproduce the error:
Create a survey (title must contain ") and send it

Error:
The mail subject is incorrect: the character " is replaced with "

OPW-2536206

closes odoo/odoo#71363

X-original-commit: a2d46c2d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

closes odoo/odoo#71188

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

To reproduce:

1. Sell an anglo product (inventory valuation = automated) in the pos app.
2. Go back to the backend, find the pos.order and invoice it.
3. Close the session.
4. Open the journal items related to the session (click the Journal Items
button in the session form).
5. You will see COGS (Expenses) Account and Stock Interim (Delivered) are
debited in two journal entries - one from the invoice and one from the
created picking after the closing of session.

This is because we are not properly skipping the invoiced order when
generating the global picking for the session. This commit fixes the
described issue.

closes odoo/odoo#70374

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

`./odoo-bin -h` prints unnecessary spaces between sentences.

---

task-2431630
Finetuning of #71130

closes odoo/odoo#71331

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Issue:

> Set bg color combination for a snippet... > Save
> Edit mode > Select the snippet
> Open color palette in bg option
> Hover a color option
> When a color button is left, the preview is cancelled
  but the color combination class is not applied anymore.

In '_computeWidgetState' (for 'selectStyle' method), the right
value ('o_cci') is not returned because we get empty "colorNames"
(the "colorPalette" is not rendered on start).

The goal of this commit is to fix this behaviour by rendering the
colorPalette in start for snippet options, this way, the new code
won't affect the speed fix added in [1] for 'OPTIONS' tab.

[1]: https://github.com/odoo/odoo/pull/65223/commits/ce54c3f21293513673cb1fc6073ada5f0a2b5641



task-2538326

closes odoo/odoo#71174

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

It was introduced in https://github.com/odoo/odoo/commit/3bd345597fa932abdaf780f72bacf331690f549b



closes odoo/odoo#71338

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

This legacy package was supposed to be an alias to `odoo.upgrade`.
However, depending on how your import its sub-packages (and in which
order), we were ending with the module being loaded multiple times,
breaking the expectation of a singleton.

```python
In [1]: from odoo.addons.base.maintenance.migrations import util as m1

In [2]: import odoo.addons.base.maintenance.migrations.util as m2

In [3]: m1
Out[3]: <module 'odoo.upgrade.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>

In [4]: m2
Out[4]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>

In [5]: from odoo.addons.base.maintenance.migrations import util as m3

In [6]: m3
Out[6]: <module 'odoo.addons.base.maintenance.migrations.util' from '/Users/chs/devel/odoo/odoo/stable/odoo/addons/base/maintenance/migrations/util.py'>

In [7]: m2 == m3
Out[7]: True

In [8]: m1 == m3
Out[8]: False

In [9]:
```

Now, with this import hook, we ensure that the modules imported from
`odoo.addons.base.maintenance.migrations` are aliases to ones imported
from `odoo.upgrade`.

```python
In [1]: import odoo.addons.base.maintenance.migrations.util as m2

In [2]: m2.__name__
Out[2]: 'odoo.upgrade.util'
```

closes odoo/odoo#71323

X-original-commit: b2ea37f1
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>

- Create a product with Category configured with:
  * Costing Method: First In First Out (FIFO)
  * Inventory Valuation: Automated
- Create a PO to buy 2 units at $100 (PO1) and receive the products
- Create a SO to sell 2 units (SO1) and deliver the products
  => COGS of SO1 should be $200 ($100 * 2)
- Return 1 unit from previous delivery
  => COGS of SO1 should be $100
- Create a SO to sell 1 unit (SO2) and deliver product
  => COGS of SO2 is $100
- Create a PO to buy 1 unit at $200 (PO2) and receive the product
- Re-deliver the returned unit from SO1
  => COGS of SO1 should be $300 ($100 + $200)
- Create invoice for SO1 and post it
The journal items (account.move.line) corresponding to the COGS have an incorrect
value: $200 ($100 + $100), instead of $300 ($100 + $200)

The issue comes from the method computing the anglo saxon price unit.
It does not take into account quantities from stock moves that have been returned.

This commit computes the number of units that have been returned for each stock
moves used to compute the anglo saxon price unit and to take the result into account
during the computation (of the anglo saxon price unit).

opw-2501260

closes odoo/odoo#71317

X-original-commit: 4d3147a0
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

Before this commit, when you create a lead from livechat with the command /lead, the public user is used inside the lead.
Because the public user is archived, and self.env.ref('base.public_partner').user_ids return an empty recordset.

closes odoo/odoo#70655

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

Steps:
- Go to Website
- Click "Go to Website"

Bug:
The default phone number on the website is not fictional and may cause
unwanted spam.

Explanation:
In North America, only 555-0100 through 555-0199 are specifically
reserved for fictional use.
> The industry also reserved a block of 100 numbers as fictitious,
> non-working numbers (555-0100 through 0199) for use by the
> entertainment and advertising industries.

Source: https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf



opw:2530388

closes odoo/odoo#71311

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

Technical name is not added to test_tags since https://github.com/odoo/odoo/commit/95b4f2ab4b5698ab3a28c9c35ac8da6fb6def983

at_install tag is added by default since introducing @tagged decorator: https://github.com/odoo/odoo/commit/b356b190338e3ee032b9e3a7f670f76468965006



Clarify how special tags at_install/post_install work.

Also, add dots for @tagged doc, because otherwise we have a mess in sphinx docs.

---

task-2431630

closes odoo/odoo#71130

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Before this commit the PyInotify filesystem watcher used by the code
autoreload feature (`--dev=reload`) would not get a chance to free
it's inotify watches before the reexec, hence at each reexec triggered
by a code reload the inotify watches where accumulated until potentially
reaching the kernel limit `fs.inotify.max_user_watches`.

This patch ensures that inotify properly closes it's file descriptor
before we reexec:
https://github.com/dsoprea/PyInotify/blob/f77596a/inotify/adapters.py#L79



closes odoo/odoo#71284

X-original-commit: 8703ff1e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Steps:
- Install Website
- Go to Website
- Click "Go to Website"

Bug:
The default phone number on the website is not fictional and may cause
unwanted spam.

Explanation:
In North America, only 555-0100 through 555-0199 are specifically
reserved for fictional use.
> The industry also reserved a block of 100 numbers as fictitious,
> non-working numbers (555-0100 through 0199) for use by the
> entertainment and advertising industries.

Source: https://www.nationalnanpa.com/pdf/NRUF/ATIS-0300115.pdf



opw:2530388

closes odoo/odoo#71281

X-original-commit: 5a047574dde6b207697244c866749d3cd439922c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.com>

When planning a Manufacturing Order, if an operation takes place in work
center with a different time zone, the computed date may be incorrect
(the start date may be outside the working hours)

To reproduce the error:
(Use demo data. Current timezone: Europe/Brussels)
1. In Settings, enable "Work Orders"
2. Open an existing Work Center
3. Click on "Standard 40 hours/week"
4. Set Timezone to "Asia/Bangkok"
    - Note that all slots are between 8:00-12:00 and 13:00-17:00
5. Create two storable products P_compo and P_finished
6. Create a Bill of Materials BM:
    - Product: P_finished
    - BoM Type: Manufacture this product
    - Components: 1 x P_compo
    - Operations: 3 x Operation with existing work centers
7. Create a Manufacturing Order:
    - Bill of Material: BM
    - Quantity: 100
8. Save, Confirm, Plan

Error: (it depends on the time the test is done) The 'Scheduled Start
Date' of the second operation is incorrect. Adding the time zone
difference gives a time that is outside the work center's timetable
(i.e., outside 8:00-12:00 and 13:00-17:00).

The computations do not consider the time zone of the work center.

OPW-2393330

closes odoo/odoo#70841

Related: odoo/enterprise#18524
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Change “default_partner_id” from “commercial_partner_id” to “bank_partner_id”
for “partner_bank_id” field in from view. If not, on an invoice, a newly created
partner bank (via “Recipient Bank” field) would be created for the partner
instead of the current company.

closes odoo/odoo#71213

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

While using the cash rounding, there were issues when rounding up and down.
The pre filled amount was correct but the rest of the transaction was wrong. (Wrong due, wrong change,...)
This commit re calculate the rounding applied when using up or down payment.

closes odoo/odoo#71219

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

Before this commit, for default colors, the text-muted class color was
set as !important from the portal and could not be overriden by the
website, leading to inconsistent display between the website and the
portal for the copyright.

As a fix for stable, we do not change the text-muted color from the
portal when using default colors.

task-2468472

closes odoo/odoo#70538

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

Before, when using the manage order, if a payment method was used and then removed from the pos.config,
we couldn't load the old order anymore because of unknow reference.
To fix this, we load all methods at the opening of the pos but when we display the payment methods we only show those in the pos.config.

closes odoo/odoo#71263

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

In a Manufacturing Order, the components' quantities are rounded using
the rounding precision of the produced product's UoM. This leads to
incorrect values.

To reproduce the error:
1. In Settings, enable "Units of Measure"
2. In UoM, edit Units:
    - Rounding Precision: 1
3. Create two products P_finished and P_compo
    - P_compo's Product Type: Consumable
    - P_compo's UoM: L
    - P_finished's UoM: Units
4. Create a Bill of Materials
    - Product: P_finished
    - 1 Component:
        - Product: P_compo
        - Quantity: 0.2
        - UoM: L
5. Create a Manufacturing Order:
    - Product: P_finished
6. Confirm, Mark as Done

Error: Qty to consumes became 0 and consumed qty is 0. Both values
should be 0.2L, but they have been rounded using the rounding precision
of Units

OPW-2529462

closes odoo/odoo#71146

Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>

When scanned product is tracked by lot or SN, the popup that asks
for lot should be shown, just like as when a tracked product is clicked
from the product list.

We accomplish this by introducing a new method that can be used both
by `_clickProduct` and `_barcodeProductAction`, and by making the
`_barcodeProductAction` be independent from `scan_product` method
from `PosModel`. So instead of calling directly `scan_product`, we
indentify the product first based on the barcode, then we call the
newly introduced method to ask for the lot inputs, then we call
`add_product` with proper options including the type of the parsed
barcode.

closes odoo/odoo#71209

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

When identifying whether to show the decrease quantity popup or not,
the current quantity of the selected orderline is compared to the
new input quantity. This fix properly compares the current quantity
to the new input quantity in number format.

Language such as FR recognizes `,` as the decimal separator. However, it is
possible that the keyboard setting is American so the decimal point in the
numpad will send `.` when pressing it. POS should be able to recognize both.
This fix allows `.` sent from keyboard to be interpreted as decimal separator
even at language where the decimal separator is `,`. This is okay because
number inputs in POS doesn't take into account the thousand separator.

The optimization 2ccf0bd0 does not take into account that to
"unblacklist" a user, you have the archive the mail.blacklist record so
only mail.blacklist active records need to be taken into account.

Added test without the fix fails with:

    AssertionError: False is not true : MailTrace: email
    test.record.02@test.example.com (recipient res.partner(), state:
    sent, record: mailing.test.blacklist(166,)): found 0 records (1 expected)

opw-2536304

closes odoo/odoo#71239

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

The `groupby` function is used to builds groups of(product, lot) keys
and their corresponding move lines / quants. `groupby` groups
*consecutive* keys, which is why the input is sorted by the keys.

`sorted` on recordsets keys will not sort as we would expect in this
particular situation, as the comparison operators on records act as
Set Comparison operators on the record ids, i.e. to compare the sets
superset/subset relationships:

```
>>> env["product.product"].browse(1) < env["product.product"].browse(2)
False
>>> env["product.product"].browse(1) < env["product.product"].browse([1, 2])
True
```

Example of sorted on stock.move.line records, where the product id 7313
is both in the slots 4 and 12 instead of being consecutive:

```
>>> [l.product_id.id for l in sorted(lines, key=itemgetter('product_id'))]
[7436, 7437, 7352, 7423, 7313, 7351, 7423, 7424, 7320, 7398, 7312, 7352, 7313, 7436, 7437, 7442, 7443, 7320, 7423, 7424, 7318, 7396, 7368, 7355, 7316]
```

Now when we group by id the 2 ids 7313 are correctly placed together in
slots 1 and 2:

```
>>> [l.product_id.id for l in sorted(lines, key=attrgetter('product_id.id'))]
[7312, 7313, 7313, 7316, 7318, 7320, 7320, 7351, 7352, 7352, 7355, 7368, 7396, 7398, 7423, 7423, 7423, 7424, 7424, 7436, 7436, 7437, 7437, 7442, 7443]
```

This commit aims to sort by "id" of the related records, to ensure the
same (product, lot) couples are consecutive.

closes odoo/odoo#71126

X-original-commit: 3317249d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Localization modules need to be `Accounting/Localizations/Account Charts`
Because this will install `l10n_generic_coa` otherwise
https://github.com/odoo/odoo/blob/36a9e761c8d6c1c6e9611cc410ecca82ff2b1659/addons/account/__init__.py#L28



closes odoo/odoo#71202

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

Bug
===
Since 4da64b3f , if multiple users of
different companies are in the same channel, and if the type of the
channel is "email", a traceback is raised when sending a message.

Technical
=========
"with_user" drop the SU flag and is not enough to bypass the multi
company ACLs. Moreover, we do not want to send a "channel_seen" bus
notifications and we can mark the message as seen on the JS side
directly.

Changes
=======
So now, the traceback is not raised anymore in that case, and the
message is marked as seen if the receiver has the web client open.

But, if the receiver has not the web client open, when he will login,
the message will not be marked as seen. This can be improved but at the
moment we just want to revert the fix that cause the traceback and fix
the issue in most cases.

Task 2427790

closes odoo/odoo#65185

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

The method filtered_domain() is broken for domains with hierarchical
terms ('child_of'/'parent_of').

To see *one* of the ways the implementation is broken, let `A` be a
model with `parent_id` pointing to `A`, and `a1` a record of model `A`
without parent (`a1.parent_id` is `False`), then this fails:

    assert a1 in a1.filtered_domain([("parent_id", "child_of", a1.id)])

The reason it fails is that on
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5377-L5380
`data` is empty since `a1` has no parent, thus
https://github.com/odoo/odoo/blob/f5519586d214a9b34ad24683a7f97c47802a3bad/odoo/models.py#L5403-L5404


fails, therefore the result of `filtered_domain` is empty.

Note: the implementation of the hierarchical operators is full of quirks
that are hard to emulate otherwise than by reusing the original code.
As a consequence, the current implementation may be broken in more than
one way.

Let's see another way the implementation is broken: let `B` be a model
without a `parent_id` field and with a `friend_id` field pointing
to `B`, and let `b1` be a record of model `B`.  Then

    b1.filtered_domain([("friend_id", "child_of", b1.id)])

throws an exception of the form shown below:

    ValueError: Invalid field 'parent_id' in leaf "<osv.ExtendedLeaf: ('parent_id', 'child_of', 1) ...

Meanwhile the following code is still valid and returs b1:

    B.search([("friend_id", "child_of", b1.id)])

closes odoo/odoo#71233

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

If the chat window was initially folded and when a new message is received
the chat window automatically unfolds. it is annoying having a window that
pops up each time a new message is coming while having folded it once.
So, It should remain folded when a new message is received if the chat
window is already folded.

Task : 2522141

closes odoo/odoo#70737

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

Issue

	- Install 'Survey' & 'website' module
	- Enable "es_VE" language and activate on main website
	- Go to Website Homepage
	- Switch to "Spanish (VE)" language (footer)
	- Go to "Survey" module
	- Create a survey:
	- Add a question of type 'Date' then save
	- Click on "TEST" button
	- Start survey and add a date with the datepicker
	- Submit survey

	Error message : 'This is not a date'

Cause

	When submit survey, not using the database date format.

Solution

	When validating form (on submit), check if date is formated
	with database format and (not the moment locale since user can
	alter date and datetime format).

opw-2452237

closes odoo/odoo#70273

X-original-commit: ddfcecc6
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>