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>

Before this commit, when remaining hours is negative then it the
label was displayed as muted instead of danger.

So in this commit, display the label danger when remaning hours
are negative.

task-3014420

closes odoo/odoo#104601

Related: odoo/enterprise#33447
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Before this commit, the progress bar was missing since the progress bar CSS
wasn't loaded to the project sharing webclient.

So in this commit, the progress bar CSS path has been added to the manifest file
for the project web client.

task-3014420

Part-of: odoo/odoo#104601

Before this commit, missing borders of remaining hours in project sharing
kanban view.

So in this commit, added border and respected color boder classes  like
'border-success','border-warning' and 'border-danger' on remaining hours.

task-3014420

Part-of: odoo/odoo#104601

Before this commit, there was a trash icon button in the project sharing view
to delete record.

In this commit, removed trash icon by adding 'delete=0' in  timesheet tree biew.

task-3014420x

Part-of: odoo/odoo#104601

Current behavior:
When splitting the order in a pos_restaurant session, the order was not
correctly saved in the backend. It resulted in an order that still had
all the product of the original order and another order with the
correctly splitted products.

Steps to reproduce:
- Start a pos_restaurant session.
- Go to table A and add 3 products to the table.
- Go back to the floor screen
- Go back to the table A
- Split the order in 2
- Click on payment, and go back to the product screen without paying
- Click on the ticket button, and click on the order that was splitted,
  it still contains all the products from the original order.

opw-3061569

closes odoo/odoo#106716

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

1/ When approving / refusing a leave spanning multiple days, the
   overtimes were only recomputed for the starting date and not the
   whole period.

2/ Overtimes should be computed whatever the kind of time off that's
   been taken (Absence or Other).

task-3073155

closes odoo/odoo#106736

X-original-commit: 116d7cb4
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Commit [1] introduced a website tour util to assert the value of a CSS
variable. This was used at the start of theme tours to check we are in
fact on the right theme before starting the tour.

While it's great for those tours when they are started as a test, it was
not meant to be shown to users following that tour. This commit fixes
that. Notice that theme tours are currently broken so the issue was
probably hidden. Those will be fixed at [2].

[1]: https://github.com/odoo/odoo/commit/b29e17765f4e912b2dd472493b5be500b3a32c87
[2]: https://github.com/odoo/odoo/pull/106703



Related to task-3084175

closes odoo/odoo#106725

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

Commit [1] and [2] introduced test tours but did not mark them as test
tours properly, thus showing them to users (who are in debug=tests mode)
by mistake.

Note that [2] was silently fixed in the 16.0 forward-ported version...
that is why nothing shows up in this diff starting from 16.0.

[1]: https://github.com/odoo/odoo/commit/7655bface7f9e9bae8579e14e9a87b4f4801cc33
[2]: https://github.com/odoo/odoo/commit/a0c33c5f896718d1c03a6a50c981d6d75ce0d169



closes odoo/odoo#106689

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

Address widget has `o_force_ltr` class [1] since Odoo 14 [2]. Somehow, it didn't
work in Sale Order report and everything was RTL. But since Odoo 16 address part
actually became LTR. It mixes things up, because partner name and phone number
in the billing/delivery sections is still RTL [0].

This commit fix it by forcing whole address block to LTR. Alternative solution
could be removing `o_force_ltr` class, but this approach looks more risky and
should be done in master instead.

[0]: opw-3053457

[1]: https://github.com/odoo/odoo/blob/1666ee5515996fab8a843b36b4fd93b776172f75/odoo/addons/base/views/ir_qweb_widget_templates.xml#L26

[2]: https://github.com/odoo/odoo/commit/5b7c3805a045d8824dd1b4fa0de07d90b17392c1



closes odoo/odoo#106695

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

In Odoo 16, we redesigned the `Accounting > Miscellaneous` menu to
provide a convenient interface for inspecting any journal entry or
journal item.

As such, it no longer makes sense to call it 'Miscellaneous'.

This commit aligns the name with the new functionality.

We also remove the default filter of the 'Journal Entries' view, which
restricted it to miscellaneous entries, and replace it with a filter
on posted entries, consistent with the purpose of conveniently
inspecting the accounting journals.

closes odoo/odoo#106687

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

closes odoo/odoo#106644

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