Steps to reproduce the bug:
- Enable “package” option in the settings
- Create a storable product “P1”
- update the stock to 100
- Create a picking:
    - product : P1
    - Qty: 1
    - operation type: delivery
    - go to additional info > add a carrier
    - Mark as todo
    - update the qty done to 1
- Create a second picking with the same steps

- Create a batch picking:
    - Add the picking 1 and 2
    - Confirm
    - Go to “Detailed operation” tab
    - Click on “Put in pack”
    - add a “Delivery packaging”
    - Save
    - Click a second time on “Put in pack”
    - Select the same “Delivery packaging”
    - Save

Problem:
Traceback is triggered: “tuple index out of range”

When the “Put in pack” button is clicked, the “action_put_in_pack”
function is called, the move_line_ids which has no package or with
a 0 quantity done are filtered, in this case the 2nd move_line with
the product “P2” will be used, but the `_pre_put_in_pack_hook` function
is not called with its picking:

https://github.com/odoo/odoo/blob/14.0/addons/stock_picking_batch/models/stock_picking_batch.py#L229

But rather with the first picking, it will have no move_line because the
first move_line already has a quantity done at 1 and a package.
So we try to get a record in an empty array:
https://github.com/odoo/odoo/blob/14.0/addons/stock/models/stock_picking.py#L1312



opw-3067921

closes odoo/odoo#106937

X-original-commit: 1b6208a2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

The tooling has been introduce in later version of odoo.
It is a problem when somebody switches to older branches without
disabling the tooling as it would then try to commit the tooling config
files.

We just add a few lines in the gitignore to prevent this issue.

closes odoo/odoo#106945

X-original-commit: b469295c
Related: odoo/enterprise#34551
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

This commit make percentage field width 25% so field and percentage
symbol look nearer.

task-3018123

closes odoo/odoo#103183

Related: odoo/enterprise#32797
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

This commit hide SOL field for project task form view and hide
it's value from tree view when task is not billable and give
correct xpath on SOL field attributes to display remaining hour
and price unit in name_search.

task-3018123

Part-of: odoo/odoo#103183

This commit make chatter width same as form sheet in project
sharing form view.

task-3018123

Part-of: odoo/odoo#103183

This commit hides create invoice button for project form view.

task-3018123

Part-of: odoo/odoo#103183

Since [1] when the search bar was refactored, images can be displayed in
the autocomplete results, and fallback icons are displayed instead of
images for records that have no images.
However, if no module that participates in the results provides actual
images, then the fallback icons are not displayed at all.

This commit makes the fallback icons displayed only based on the "Image"
toggle option of the search bar.
It also disables the hidden display options and enables the visible
ones.

Steps to reproduce:
- Do NOT install website_sale (which is currently the only module that
provides autocomplete results with images).
- Drop a "Search" block.
- Save.
- Type a single letter in the search box. (e.g. "a")
=> Autocomplete results were displayed without their icons.

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



task-2951026

closes odoo/odoo#106870

X-original-commit: 4e292519
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

The comment became outdated:
- For 14.0 and above: mentioned the "Customize dialog" which does not
  exist anymore.
- For 16.0 and above: mentioned "Bootstrap 4" instead of "Bootstrap 5".

Related to opw-3056683

closes odoo/odoo#106902

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

In the 2022 Tax report, box 16: 'Total de la TVA brute due (lignes 08 à 5B)'.
The formula is missing tags P1, P2, I1 to I6.

opw-3036679

closes odoo/odoo#106831

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

Previously, it was only possible to upload a bill, so the partner_id was read
from the vendor in the imported file. Now, it is also possible to upload a
file to create an invoice, so we need to be able to decode the customer in
the imported file.

opw-3072989

closes odoo/odoo#106909

X-original-commit: 1c73b6a0
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>

Release notes: https://github.com/odoo/owl/releases/tag/v2.0.2



- fix: compiler: do not look up ComponentNode in the context
- fix: t-model takes precedence over t-on-input
- fix: reactivity: fix issues with reactive objects in proto chain

closes odoo/odoo#106893

X-original-commit: a86a8544883aaaf5d530320c84706dde35d17ef6
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

With this commit datetime of stock move are correctly converted with the current timezone.

closes odoo/odoo#106849

X-original-commit: 242da76b2763d5add36da6e23d4b1f7e640c72aa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Add an ACL to allow read-only access for basic users to the workcenter
capacities. This avoids an error in the bom overview opening with a
simple MRP "user".

closes odoo/odoo#104893

Related: odoo/enterprise#33613
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Take the following BoM :
Final_product
    Semi_final_1 (Subcontracted)
        Component_1 (Dropshipped to subcontractor)
    Semi_final_2 (Manufactured by us)
        Component_1 (Bought then put in stock)

Component_1 is used in both semi_finals, but in different contexts. For
Semi_final_1, it's directly dropshipped to the subcontractor, while for
Semi_final_2 we resupply our stock and then use it from there.

Problem is, since both components are the same, there was no distinction
made when fetching the data for the resupply methods. So if the first
case encountered was the dropship (like here), then for Semi_final_2 the
dropship would be used as well, while we're not in a subcontracting
context anymore.

Now we consider the parent_bom when fetching and storing the resupply
data, as different boms can have different contexts.

Part of task-2985735

Part-of: odoo/odoo#104893

Before this commit, the rules were checked related to the currently
selected warehouse. Doing this didn't allow to check the subcontracted
locations for their related rules (like Drophip subcontractor on order).

The point here is that when no rules are found within the warehouse, it
checks the subcontracted location of the parent if the parent is
subcontracted itself.

Part of task-2985735

Part-of: odoo/odoo#104893

Before this, when working on a bom with variants, when checking the
parent from the component / child_bom, it would always take the first
variant since it used the bom's product_template.

This could lead to incorrect data when working with subcontracting, as
when another variant from the first would be selected, when fetching
quantities no parent info would be found as it would seek info from the
first variant of the bom instead of the correct one.

By doing this, we can now have the right variant and fetch the right
informations.

Part of task-2985735

Part-of: odoo/odoo#104893

Since the pager div doesn't appear anymore in the DOM when it would be
empty, the filters buttons (warehouse and display) would be pushed back
to the end of the flex div.

Part of task-2985735

Part-of: odoo/odoo#104893

Before this PR, posting a message containing an attachment with a long
name in the chatter would result in the chatter overflowing the main
window. This is due to the fact that flex items cannot be smaller than
their content.

This PR fixes the issue by adding the `overflow-auto` class to the
chatter container in order to override the default `min-width: auto`
of flex items thus allowing them to be smaller.

closes odoo/odoo#106892

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

## Steps to reproduce
1. navigate to Settings -> CRM -> Lead Enrichment section
2. change the Lead Enrichment option to "Enrich leads on demand only"
3. click Save button
4. wait for system to save and refresh.

You should see that the change you made was not saved.

opw-3063639

closes odoo/odoo#106851

X-original-commit: 0803775e4a156aa6988453edbbaf799730c996b2
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

- Settings > manage languages > english > Set time format to `%H:%M:%S %p`
> Save
- Install Planning app > go to list view > Try modifying a time manually
(without using the widget which pops up).

Issue:
When trying to save the new time, an error pops up: `Can't include meridiem
when specifying 24-hour format`.

While parsing the new date, the `luxon` library throws this error to
prevent wrong hour values, such as `17 AM`.

Fix:
Prevent the user from inputting both `%H` and `%p` in the same time format
and display a warning notification.

opw-3038797

closes odoo/odoo#106846

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

The group `“base.group_user”` is added in the view for the field
`standard_price` while it is already set on the python side:
https://github.com/odoo/odoo/blob/16.0/addons/product/models/product_template.py#L76


this causes an issue in the case of a product with variants,
the invisible attrs is ignored, the `standard_price` and
`uom_name` field are hidden, but the label will still be displayed

opw-3076827

closes odoo/odoo#106842

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

Current behaviour:
Changing the package quantity may change the package type,
leading to an incoherent product quantities in the SOL.
(For ex: 20 uom in 2 packages of 20)

Expected behaviour:
When setting the package quantity, don't change the
package type. If the user wants to change the package type
they can do it by manually setting it or changing the product_uom.

Steps to reproduce:
- Install Sale and Inventory
- Activate Packages in settings
- Create 2 package types for a product of choice, one of 10, another of 20
- Create a new SO with that product
- Set the quantity to 10 (a new package_qty=1 and packaging type of 10 should appear)
- Save
- Edit package_qty to 2
- Observe that we have 20 units of the product, 2 packages of 20,
  instead of 2 packages of 10

Reason for the problem:
When setting the `product_packaging_qty`, the `product_uom_qty` compute is triggered.
When `product_uom_qty` changes, it triggers `product_packaging_id`'s compute.
When `product_packaging_id` is computed, it doesn't trigger `product_package_qty`,
because it is protected, since we are writing to it.

Fix:
When we are writing the `product_packaging_qty` and the `product_uom_qty`
we remove the compute for `product_packaging_id`.

Affected versions:
- saas-15.2
- saas-15.3
- 16.0
- master

opw-3010703

closes odoo/odoo#106811

X-original-commit: 42c9f7fb2287e4653999d5a5ce010547e9c3712f
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>

closes odoo/odoo#106645

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

Previously, _intervals_duration (called by _compute_duration)
sometimes loose the last mrp.workcenter.productivity.
A fix has been made.
First, mrp.workcenter.productivity.loss _convert_to_duration
calculates according to the loss type, we have to take that in account.
Second, mrp.workcenter.productivity _close badly generates
performance timers.
For example, test_mrp_employee_analytic_account generated
- productive for 1st employee from 10:00 to 11:00
- performance for 2nd employee from 10:00 to 11:00
- performance for 2nd employee from 11:00 to 11:00 (! duration = 0)
Now, the timers are
- productive for 1st employee from 10:00 to 11:00
- productive for 2nd employee from 10:00 to 11:00
which is correct.

closes odoo/odoo#105410

Task: 2985735
Related: odoo/enterprise#33796
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Fix workorder times problems:
- sum in workorders list view
  (displays numeric value rather than mins:secs)
- timers sometimes starts at -00:01
- almost all tablet view actions reset the timer (click burger, ...)
- clicking pause stops the timer at the next second
- seconds are lost in employee timers

Task: 2985735
Part-of: odoo/odoo#105410

Steps to reproduce the bug:
- Install `delivery_dhl`
- Create a storable product “P1”:
    - make sure the weight of the product is equal to 0
- create a transfert:
    - Type: delivery orders
    - Add the product “P1”
    - Go to “Additional info” tab and select “DHL” in the carrier field
    - Mark as Todo
    - Validate

Problem:
A traceback is triggered, because in order to set the shipment details,
a package should be created, so the `_get_packages_from_picking`
function is called:
https://github.com/odoo/enterprise/blob/aed802ee17dba5ebe12b42594503732a2662be68/delivery_dhl/models/dhl_request.py#L166

But as the total weight of the products is equal to 0, the package is
not created:

https://github.com/odoo/odoo/blob/6b0ab28791f4a29254d294f8a116545d4c124e8b/addons/delivery/models/delivery_carrier.py#L324-L325

then, the result is used without checking if the package has been
created:
https://github.com/odoo/enterprise/blob/aed802ee17dba5ebe12b42594503732a2662be68/delivery_dhl/models/dhl_request.py#L185



Solution:
If the total products weight is equal to 0, raise a UserError

opw-3076826
opw-3075562

closes odoo/odoo#106809

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

Stpes to reproduce the bug:
- Install delivery_ups
- Go to shipping method > UPS BE > Package type
- Set the max weight to 10 kg
- Create a product “P1”:
    - Go to inventory tab > weight: 10 kg
- Create a SO:
    - Add the product “P1”
    - Add shipping
    - Select UPS Be
    - Click on get rate

 Problem:
Traceback is triggered, because we devise a number by an empty list:
https://github.com/odoo/odoo/blob/6b0ab28791f4a29254d294f8a116545d4c124e8b/addons/delivery/models/delivery_carrier.py#L301

The `last_package_weight` is the result of the modulo of the weight of
all the products by the maximum weight of a package, in this case it is:
0 -> 10% 10

We then use this result to calculate the weight of the package,
but parenthesis have been forgotten and therefore an empty list is
returned in the case where `last_package_weight` is 0

https://github.com/odoo/odoo/blob/6b0ab28791f4a29254d294f8a116545d4c124e8b/addons/delivery/models/delivery_carrier.py#L298-L300



opw-3075295

closes odoo/odoo#106780

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

closes odoo/odoo#106798

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Since odoo/odoo@69c3d5aa25655173ed66a52570559322c650c7df
the readonly and required modifiers were no longer passed
for non-editable views. Which means:
- kanban: never passed,
- tree: passed only when `editable="1"` or `multi_edit="1"`,
- form: always passed.

The rationale behind that is that a view which is considered
as readonly doesn't need to know if its field are readonly or required,
as by definition, if the view is readonly, the user shouldn't
be able to modify anything in the view.
This was to make the views sent to the web client more light-weight,
not sending unused information, and save KB of transfers.

However, some widgets, used in the kanban and non-editable tree,
allow to modify fields, even in readonly considered views,
and therefore need to know these readonly/required modifiers
from the field definition in the Python model.

e.g. the `widget="color"`, odoo/odoo#103478

Ideally, these readonly/required modifiers should be transferred
only when the widget requires it, to avoid transferring the
readonly/required modifiers
when they are not useful in kanban/tree views
(which is 99% of the time).
However, this would require a bigger refactoring,
which is considered too risky compared to the added value
for a stable release.

task-3013110

closes odoo/odoo#106766

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

Current behavior:
In the PoS if you apply a coupon on an order that contains 2 products
with different taxes, it will create 2 discount lines on the order.
If you change the pricelist, the discount lines won't have the correct
values.

Steps to reproduce:
- Create 2 different products with different taxes.
- Create a pricelist with a discount on the 2 products.
- Create a coupon that apply a 100% discount on the order.
- Start a PoS session
- Add the 2 products to the order and apply the coupon.
- The order total is now 0€.
- Change the pricelist to the one with the discount.
- The order total is different than 0€.

opw-3049098

closes odoo/odoo#106612

X-original-commit: 2f29ca9311bd5c63e9419069088ce1475a124005
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>

closes odoo/odoo#106779

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

closes odoo/odoo#106745

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

Issue:
At anypoint we should be able to call the method "_set_lot_ids" from stock.move on moves that are already done and the quantities should not change.
This is not the case for lots that get their quantity changes to 1 as if the product was tracked by serial number.

This commit should be seen a a complement to the commit: https://github.com/odoo/odoo/pull/79565



Fix:
Check the product is tracked by SN before trying to change the quantities to 1.

Related ticket: 2689724

closes odoo/odoo#100640

X-original-commit: e6fa1e24aaeaca543b9acae7f876d30def131a59
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Current behavior:
If you create an empty Db and just create one coupon program for the PoS
, the `enter_code` button is not displayed. This happens because the
condition to show the button was looking for program type `coupon`
instead of `coupons`.

Steps to reproduce:
- Create an empty Db (Important)
- Install PoS and PoS Loyalty
- Create a coupon program for the PoS
- Open the PoS, the `enter_code` button is not displayed

opw-3078726

closes odoo/odoo#106585

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Currently in Sale/Orders/Sales Teams menu , The Sales Analysis dashboard
have text overflow bug for large numbers in USD/EUR this bug might be
rare but in currency like Yuan or VND its common

closes odoo/odoo#106737

X-original-commit: 2e58bc2f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Purpose:
Make the command palette easier to discover - indeed, unless you
know about CTRL+K, it's difficult to know you can use that elsewhere
than the home screen.

Solution:
Add CTRL+K next to the Shortcut menu in the user menu.

closes odoo/odoo#106594

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

closes odoo/odoo#106742

X-original-commit: ad9dca99
Related: odoo/enterprise#34476
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

During the forward-port of odoo/odoo#106388 I changed the way the
popoverClass is taken into account in the `onPositioned` callback and
should have written a test. (from 16.0 branch up to current master)

This commit brings the same change (splitting and spreading the prop
value) and adds a test.

closes odoo/odoo#106724

X-original-commit: ddaffdb3bdfa823c2298fc011a9e848304b553cf
Signed-off-by: Luca Vitali <luvi@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

The user could make the mistake to put a large number in the `Guests`
input in the POS order and this is not validated, even an number more large
for the capacity of an integer, raising an uncontrolled error:

`psycopg2.errors.NumericValueOutOfRange: integer out of range`

this commit is adding a validation error in order to limit the number of `Guests`
with the maximum number for an integer:  2**31 - 1

closes odoo/odoo#106523

X-original-commit: 0ff14cc8
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

The Belgian tax report was only available in French.
Now the tax report is available in English by default and there are official translations in Dutch and French.

Resources:
NL: https://financien.belgium.be/sites/default/files/downloads/165-625-formulier-2022.pdf
FR: https://finances.belgium.be/sites/default/files/downloads/165-625-formulaire-2022.pdf

[task-3074748](https://www.odoo.com/web#id=3074748&cids=1&menu_id=4720&action=4043&model=project.task&view_type=form

)

closes odoo/odoo#106258

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