Suppose a product with several suppliers, all with the same partner. On
the purchase order, the product description will always be based on the
last supplier
To reproduce the issue:
1. Create a vendor V
2. Create a product P:
- Type: Storable
- In Purchase, add a line L01:
- Vendor: V
- Vendor Product Name: Name01
- Vendor Product Code: C01
- Quantity: 1
- Price: 10
- In Purchase, add a second line L02:
- Vendor: V
- Vendor Product Name: Name02
- Vendor Product Code: C02
- Quantity: 20
- Price: 2
- Once P is saved, ensure the lines order in the purchase tab:
- L01
- L02
3. Add a reordering rule on P:
- Min: 1
4. Run the scheduler
5. Open the generated PO
Error: The description is incorrect ("[C02] Name02" instead of "[C01]
Name01")
When computing the display name of the product,
https://github.com/odoo/odoo/blob/7691567286869ca65e63fc79c2cee11e1f415fcb/odoo/models.py#L1728-L1730
`name_get` returns a tuples list: `[(37, '[C01] Name01'), (37, '[C02]
Name02')]` where `37` is the product identifier. This list is then
converted into a dictionary and here is the issue: it will use the last
tuple to define the value for key `37`, i.e. "[C02] Name02". Therefore,
`name_get` should return the correct name, and only this one.
Another issue could be highlighted: when the user changes the quantity
of the purchase order line, if another supplier info is selected, the
description won't be updated (for the same reason as above)
OPW-2702616
closesodoo/odoo#82321
X-original-commit: a42608214f2e9ef3f5e59b4b54cd7f72a6019e06
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
The stock convention on location name is always to name the destination
`location_dest_id`. It was not the
case on the stock rule model
Task: 2648449
Part-of: odoo/odoo#80434
Testing purchase order creation assumes the whole test is done the same
day. The assert could failed if the test is run right before midnight
and end the day after.
This commit ensure the time is frozen during all the tests about
purchase order creation.
closesodoo/odoo#80264
X-original-commit: 438e47cdc87fc0f13c61a1ede29a190120dea117
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Remove the Purchase Security Lead Time from the computing of the
purchase order's picking deadline to better reflect that the shipment is
actually meant to arrive earlier than date + security lead time.
Also makes sure that receipts and subsequent pickings (multi-step
reception) are planned the earliest possible, not taking the purchase
security lead time into account.
Task-2656397
Part-of: odoo/odoo#79523
Expected behavior : The log note sent when received quantity is updated should take into account the quantity already received.
Current behavior : The log note sent doesn't take into account the quantity already received for a 'stock_moves'. So it always displays `Received Quantity: 0.0 -> quantity in stock` instead of `Received Quantity: quantity already received -> quantity in stock`
Steps to reproduce the error :
- Create a RFQ with few units of a Storable Product (e.g. 5 units)
- Partially validate the receipt and create a backorder (e.g. 3 units)
- Validate the backorder (e.g. 2 units)
Log notes should be :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 3.0 -> 5.0`
But are :
`Received Quantity: 0.0 -> 3.0`
`Received Quantity: 0.0 -> 5.0`
The value is always equal to 0.0 because `qty_received_method == 'stock_moves'` so `line.qty_received` is overridden by 0.0 in parent `_compute_qty_received` even though its value is already set to 0.0 (default) or to the quantity already received
opw-2600221
opw-2613116
closesodoo/odoo#78858
X-original-commit: 0c8ea86fb8d706af139cd2d412d01487e5899df6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In a lot of test class, we use `setUp` instead of
`setUpClass`. `setUp` is execute for each test method and `setUpClass`
will be execute only once by Class (and use savepoint + rollback).
Then change setUp into setUpClass reduce the time to make all tests
and avoid to repeat this error for the future.
closesodoo/odoo#78082
Related: odoo/enterprise#21563
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Allow the quantity decrease of Sale Order line of a MTO product.
When increasing de quantities, the related pickings, RFQ / PO are
increased as well, but it wasn't the case if decreasing the quantity.
It should allow the cascade of the decrease in the related pickings as
it would work for the increase. Also modifies a related Purchase Order
if it wasn't yet validated (and thus still a RFQ).
merge_moves was modified so it would allow the merge of negative moves
with positive ones, while trying to "deplete" as much quantity as
possible for each mergeable move.
But negative moves don't always have all required properties to be
compared to the positive ones (some keys might be missing, such as
'created_production_id'). That means we will merge strictly the positive
moves at first as it was done before. But then we try to merge them "less
strictly", using less keys to compare.
Let's say we have those moves (and all other relevant keys matches) :
- move_1 : {qty : 5, created_production_id: 1}
- move_2 : {qty : 3, created_production_id: 2}
- move_3 : {qty : -6, created_production_id: False}
move_1 and move_2 cannot be merged as they don't share the same
created_production_id. But to merge move_3, we'll need to merge it into
move_1 and move_2. It will then deplete move_1 and decrease move_2.
Which will leave us with :
- move_1 : {qty : 0, created_production_id: 1}
- move_2 : {qty : 2, created_production_id: 2}
move_3 will be unliked as its purpose is done.
Task-2513592
Part-of: odoo/odoo#78070
Testing orderpoint generation assumes the whole test is done the same
day. The assert could failed if the test is run right before midnight
and end the day after.
This commit ensure the time is frozen during all the tests about
orderpoints generation
closesodoo/odoo#77307
X-original-commit: 079435eb8386554c475cd82d1f6fbb611bba0339
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The combination of a RR and a supplier that has a minimum quantity and a
lead time leads to incorrect results
To reproduce the issue:
1. Create a product P:
- Type: Storable
2. Add a reordering rule for P (min: 10, max: 50)
3. Add a vendor to P
- Quantity: 1
- Price: 1
- Delivery Lead Time: 7
4. Run the scheduler
5. Open the generated PO
Error: The order deadline is <today minus 7 days> instead of today. The
receipt date is today instead of <today plus 7 days>
When computing the quantity to order, the method needs the value of
`qty_forecast` (L254 in [1]) The computation of `qty_forecast` leads to
the computation of `lead_days_date`. To do so, it gets the lead days of
the associated stock rule `_get_lead_days`. In this method, a seller is
selected: [2] However, none of the parameter is defined: [3]
In the above case, the seller has a minimum quantity of 1. Therefore,
since this information is not given in [2], the vendor is not selected
and his lead time is therefore not taken into account. So,
`lead_days_date` will be equal to 0 and won't be recomputed. As a
result, the planned delivery date is today. Then, the quantity to order
is computed (L260 in [1]), so later, the module is able to select the
correct seller. However, this one has a lead time of 7 days -> the
generated PO will have the planned date to today and the order deadline
to <today minus 7 days>
Once an orderpoint has its quantity to order defined, its lead time
should be recomputed because it may be different depending to the
selected seller (and thus we should take this quantity into account when
searching for a seller)
[1]
https://github.com/odoo/odoo/blob/59ac8d891de6e20604494d6cfc6fc357a88d226c/addons/stock/models/stock_orderpoint.py#L254-L260
[2]
https://github.com/odoo/odoo/blob/1b03087524080f1a9751b1561cd8891466e72367/addons/purchase_stock/models/stock_rule.py#L153
[3]
https://github.com/odoo/odoo/blob/045c6ad3353bb0849d3f93d3488d8dcd8b8975b0/addons/product/models/product.py#L602
OPW-2614798
closesodoo/odoo#77110
X-original-commit: f2eb1dca99d16d70613c2f724d4b73f273a49ae7
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
The check added in 643e093a4bc9d46973705831697036b56a89b143 was too
strict in case a purchase order was created from an orderpoint
triggering multiple rules. The orderpoint's location could be below
another warehouse that the first rule's location and thus raising the
error.
closesodoo/odoo#77079
X-original-commit: df1f90673fc06f3d535833229d8af3ef6a51dd61
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Rounding in purchase order is 'UP' which is causing issue when doing
receipt in a different uom than the purchase. Rounding should be
'HALF-UP'
Added test in purchase and sales to ensure this issue is detected in the
future.
closesodoo/odoo#76006
X-original-commit: 9d3d1949d20834c92449c989299ac8e67f26d05d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Divide "Delivery"/"Incoming Shipment" smart button of "Sale"/"Purchase"
order form between normal "Delivery"/"Incoming Shipment" and a
"dropship" picking.
Also clean a little bit technically
task-2486811
Part-of: odoo/odoo#75041
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce the bug:
- create 2 warehouses A & B
- create a new product and add a seller
- Create an Automated replenishment order of the created product for warehouse A
- click on “Automate orders”
- open PO
- in “other information” tab > change the picking type to the “warehouse B” picking type
- confirm order
- click on the receipt
Problem:
The destination location is “Warehouse A” instead of “Warehouse B”
The problem also appears after the duplication.
Solution:
Use the parent_path to check if the location that the user wants to use is below the original warehouse.
opw-2588082
closesodoo/odoo#75501
X-original-commit: bed546486aa667d735df015de8153d42a9af9a41
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>
Co-authored-by: fmdl <florent.mirieu@gmail.com>
Automatically activate `group_multi_currency` if there is more than one active currency,
deactivate it if there is only one active currency
retain sale/pos feature of activating group_product_pricelist
adapt tests accordingly
Task 2610735
closesodoo/odoo#74396
Related: odoo/enterprise#20106
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Step to follow
Do not activate multiple companies, keep it standard to 1
Enable multi-locations and routes
Create a second location for raw materials and a new Receipt operation type with the new location as destination location
Go to routes -> edit the buy route -> add a second rule with "Buy" and save.
Cause of the issue
When a stock rule is created from a stock route, the default company
cannot be found as there is none assigned to the stock route.
Solution
Override the default_get method for stock rules in order to use the
current company
opw-2578984
closesodoo/odoo#74380
X-original-commit: 2b8d7d76adceeca16f97e394a6734bb5be633c3b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For data quality purposes and bug prevention, when I reverse an entry,
the reversal should always be postable on a journal having the same type
as the initial Journal Entry's journal.
closesodoo/odoo#72431
Task: 2497529
Related: odoo/enterprise#19543
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Resupplying a product with a purchase order ask to choose the suitable
supplier to put on the purchase order. Another search is perform on top
of that to compute de date to order in order to respect the lead days
promise by the supplier. The issue is that the first search is done with
the orderpoint company into account but not the second one.
This commit passes the company to _select_seller when computing the total
lead days required for an order.
opw : 2557125
closesodoo/odoo#72466
X-original-commit: c1bd985ef6a77c8848c4a2a8b92508511d9d8638
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
1. add packaging to PO lines
2. packaging on PO/SO lines can be propagate to MO
3. add package type to packaging
4. on picking types, we can choose to only reserve full packaging. That
means if you want 1 pallet(100 units) and you have 50 units in stock. It
won't be reserved.
5. suggest suitable packaging for PO/SO/MO line according to the product
qty
Task-2357259
PR #68654
UPG PR odoo/upgrade#2444
When changing the product price precision, this can lead to incorrect
stock valuations.
To reproduce the error:
(Enable debug mode)
1. Go to Settings > Technical > Database Strucutre > Decimal Accuracy
2. Edit Product Price:
- Digits: 4
3. Create a Product Category PC:
- Costing Method: FIFO
4. Create a Product P:
- Product Type: Storable Product
- Product Category: PC
5. Create a RfQ with product P:
- Quantity: 1000
- Unit Price: 0.035
6. Confirm Order, Receive Products, Validate
7. Click on Valuation
Error: The total value is equal to $40 instead of $35. The calculation
was done after rounding the unit price: $0.035 becomes $0.04, then
1000*0.04=$40.
When confirming the RfQ, a stock move is created. To do so, the method
`_get_stock_move_price_unit` is called. When validating the delivery, it
recomputes the unit price thanks to method `_get_price_unit`. In both
situation, and if the line has taxes, the method `compute_all` is called
like this:
```python
price_unit = line.taxes_id.with_context(round=False).compute_all(price_unit,
currency=line.order_id.currency_id, quantity=1.0)['total_void']
```
But here is the problem. In this method, total amount is computed with
this line:
```python
base = currency.round(price_unit * quantity)
```
However, `quantity` is equal to 1 and the multiplication is rounded
using the currency precision. As a result, `base` is equal to $0.04.
Then, all computations will use this value and will be incorrect.
This fix applies the real quantity so `base` will have the correct
value:
```
base = currency.round(price_unit * quantity)
= currency.round(0.035 * 1000)
= 35
```
OPW-2472192
closesodoo/odoo#70269
X-original-commit: 77b7a23c3c759b33e26bf91faf14a10f02449a91
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
For customer invoices:
* do not set default date because if you prepare an invoice (and it gets
a default date), then validate it the next day, the date will be wrong
* set the date when posting if it wasn't set, because why not?
For vendor bills:
* do not set default date because you rarely encode a bill at the bill
date. Forcing the user to enter it reduces risks of user error
(duplicated vendor bill)
* do not set it when posting, same reason.
opw-2492862
Related #68368Closes#68367closesodoo/odoo#69639
X-original-commit: 41041d8016d11f017d92d28f32ab2cf42f1349a9
Related: odoo/enterprise#17866
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
What are the steps to reproduce your issue ?
1. Create Product with Purchase Vendor(s) set
2. Create Units of Measure that are bigger than (10kg/50kg in tests)
What is currently happening ?
If you put a vendor that is listed in product form, when changing purchase unit from kg to 10/50kg price is updated
If you put a vendor not listed, it gives cost price which is correct, but does not update price according to unit of measure.
What are you expecting to happen ?
Update correctly the unit of measure when the vendor is not listed
opw-2494769
closesodoo/odoo#69196
X-original-commit: d531e8a5e4d84fe6daa9110d076b0fc601a0b4d9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
This reverts commit 170729ee58b199041d7545e7789ac9474e86f998, per
discussion with @thomasdeleval on linked ticket.
opw-2422438
closesodoo/odoo#68293
X-original-commit: 5c2db20a14701f165adfecb391073c3d957081e9
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
Because of the weird behavior of the ORM regarding
related field pointing to computed fields,
`on_time_rate` was taking account of all companies
when asking it through `purchase.order.on_time_rate`
but it was single-company when asked through `res.partner.on_time_rate`.
It was observed during an upgrade request issue analysis,
and in that case the problem was not even the fact
it was miscomputed, but the fact this computed field,
computed as sudo, leaded to fill the cache for
`purchase.order.line.move_ids` with `stock.move` belonging
to other companies than the user one,
and then when attempting to read values from these stock moves
a multi-company access error was raised.
upg-8106
closesodoo/odoo#66882
X-original-commit: 1b729171c5deac4fadebcff013aa061a96860b09
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Replenishment is great to replace MTO but misses the direct link between SO and PO (smart buttons on both SO and PO to link to the corresponding PO and SO).
The info is actually there in the forecasted report but it is not accessible directly from the PO and in the case of the SO does not highlight the corresponding line of the SO.
This adds a graph icon in the PO, MO and receipt form to directly access the forecasted report (it already exists for SO and delivery).
The information linked to the SO/PO/MO/receipt/delivery is also sent to the forecasted report to highlight the corresponding line.
Note that in the case of the SO, the information needs to go first through the qty_at_date widget (which contains the link to the forecast report).
The graph icon for the PO, receipts and MO turns red when the forecasted quantity at expected date is negative. This is done using the new 'forecasted_issue' field.
closesodoo/odoo#62264
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Behavior prior to this commit:
When a PO is generated (via reordering rule, mto rule, or manual replenish),
the description on the PO line includes the internal notes.
Behavior after this commit:
The description on the PO line does not include the internal notes.
Note:
Per c324526ad0, the description on the picking also does not include
the internal notes (anymore), and the test has been updated to reflect
that.
opw-24222438
closesodoo/odoo#64883
X-original-commit: 5db67fb2931517ae94fe0396ef80e9ad997e59cd
Signed-off-by: Nicolas Galler <ngaller@users.noreply.github.com>
In order to easily compare delivery slip from vendor and receipt, vendor
product name and reference should be visible on the receipt operations.
The receipt description was just the name of the product before, it is
now taking the same description as the PO line, using vendor product
name and reference if it exists.
Task ID-2411544
closesodoo/odoo#62967
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The picking_type and currency were taken from the current company, even if the
purchase order is created in another company.
Fixes#35026closesodoo/odoo#64481
X-original-commit: 75936208c6e76a012027952f43b598e9d20180f3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Currently stock moves are auto-assigned (i.e. reserve free stock) both
when the scheduler is run and when a corresponding stock move that can
assign a move is completed. This strictness was causing issues for
prioritization of moves to assign, for example a picking with a
scheduled_date far in the future could automatically reserve all stock
if it was created before another picking that an immediate
scheduled_date. To ease this, an extra setting has been added to
stock.picking.type to let users choose how reservations should occur for
moves assigned to that picking_type (or picking with that picking_type):
1. 'at_confirm' = automatically when:
- stock is available when the move's associated picking/MO is
confirmed,
- when new stock becomes available,
- when the scheduler is triggered (+ stock available).
2. 'manual' = user must always manually click "Check Availability"
button (scheduler will no longer reserve).
3. 'by_date' = automatically when within the move's reservation_date
and:
- stock is available when the move's associated picking/MO is
confirmed,
- new stock becomes available when move is already confirmed, or
- the scheduler is run (+ stock is available).
'by_date' has an extra option of # days before the move's scheduled
date that affects the move.reservation_date.
Task: 2359317
Upgrade PR: odoo/upgrade#1868
ENT PR: odoo/enterprise#15050
- Create a product P with a MTO Reordering Rule (Buy Route)
- Add a supplier to P with a specific vendor code
- Create a SO for 1 unit of P, validate
A PO is created for the supplier but without using the vendor code.
It happens because the vendor code is overridden by the product
description.
To avoid losing information and redundancy, we add the line description
only if different from the product name.
opw-2383418
closesodoo/odoo#62037
X-original-commit: 0b138ffa5a1b2b03f03fb5dc51994a3bfc4e5dea
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Behavior prior to this commit:
In a multi-lingual setup, when entering a SO for a customer set in
a non-default language with a product that has translation in both
languages and is set up to replenish on order, the description in the
generated RFQ is duplicated, for example: "Product test Test Product in Dutch"
The problem stems from the fact that the description on the generated
stock move is set to the translated name of the product. When
generating the PO, the stock move class removes the product name to
avoid duplicating the description, but it uses the non-translated name
in the comparison.
Behavior after this commit:
The description on the RFQ line is included only once (using the default
language for the database)
opw-2368562
closesodoo/odoo#61138
X-original-commit: d013f8641ae2ed8c12d30ba5650c8e6ff2f1d5fd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a Purchase Order is created by the replenishment report, doesn't
pass the origin ("Manual Replenishment" or "Replenishment Report").
task-2328830
closesodoo/odoo#59398
X-original-commit: 170729ee58b199041d7545e7789ac9474e86f998
Related: odoo/enterprise#13876
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- Create stockable product P: FIFO, Automated Valuation
- Set the price difference account
- Configure Decimal Accuracy for Product Price to 6 digits
- Create a PO
- Add a line with:
Product P
Quantity: 100,000
Price unit: 0.005
- Confirm the PO, receive the product and create the invoice
- Set a price unit of 0.006 on the invoice line
- Post the invoice
No price difference booking is generated, while a price difference of
100 should be created.
It happens because we compare the price units with the currency
precision.
Comparing the price units, even with the proper Product Price precision,
is not a good idea. Indeed, in case discounts are applied the price
unit computed ends up with a larger precision.
As a solution, we check if the subtotal of the journal entry is
different from zero.
opw-2341181
closesodoo/odoo#58364closesodoo/odoo#58888
X-original-commit: 654be58894c51d2c5384ead67a5a7c68fdebf0a7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create stockable product P: FIFO, Automated Valuation
- Set the price difference account
- Configure Decimal Accuracy for Discounts to 5.
- Create a PO
- Add a line with:
Product P
Quantity: 10,000
Price unit: 100
A tax
- Confirm the PO, receive the product and create the invoice
- Set a discount of 0.92431 on the invoice line
- Post the invoice
The journal entries for the invoices contains the price difference move,
the amount must be 9,243.10 but is 9,200.00.
In case taxes are defined on the the invoice line, we call `compute_all`
which will round the `price_unit`. In this case, we don't want to round
it.
Fixes#56832
opw-2329028
X-original-commit: 286ea6b681e9ba77357f91b546052449f6342f20
date_deadline of the stock move has been reviewed:
- Now, it represents the datetime when the operation must
be done to be in time for the uppest document (SO/PO/MO/RR).
- At the creation of stock move the date_deadline is computed in
the same way than the sheduled date expected that it is not include
security days (inverse the logic for PO).
- When we update the delivery date (or lead time) of SO (or PO).
The deadline of related stock move is updated and the delta is propagate
between origin and dest moves.
task-2324039
The test test_update_date_planned issued starting just before midnight.
a purchase was created at 23:59:59 then the variable `today` was
assigned to 00:00:01. When comparing the activity generated by the test,
taking 23:59:59.today() and 00:00:01.today() gave two different values.
This commit force the test time to 09:00:00.
Task : 2325270
closesodoo/odoo#56681
X-original-commit: 70c223eebe7edfa26564598c898cb9a8541e349b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Adrien Widart