When a portal user is created (e.g. through the `auth_signup` module),
an unnecessary write is done on the `write_date` of the default digest.
This `write` is unnecessary since a portal user is never subscribed to
the default digest.
In case of a high signup frequency, it can cause concurrent transaction
errors.
We avoid writing if no internal user is being created.
closesodoo/odoo#162563
X-original-commit: bbc427e837b08187f351febfde4339262e660944
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There are various cases where we observe crons which systematically
face a CPU / memory limit. In a setup where a single worker cron is
launched, a failing cron will prevent subsequent crons to run.
This happens because the limits are evaluated at the worker level: the
worker is killed, then starts over with the same job list order.
If the vacuum cron cannot be run anymore, it leads to tables not
garbage collected anymore (e.g. `bus_bus`), causing performance issues.
To avoid this, we give a higher priority to the vacuum cron.
closesodoo/odoo#144210
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the connection pool works greedily regarding the
number of connections opened. Once a new connection is needed, it is
added to the pool and never closed unless the maximum number of
connections is reached.
We introduce 2 changes. First, we do not cycle on the available
connections anymore. We take the first one available and let it at its
position in the list. It opens the possibility to use
`idle_session_timeout` introduced in PostgreSQL 14.
Moreover, we introduce a garbage collection of the unused connections.
If the connection has been unused for more than `MAX_IDLE_TIMEOUT`
seconds, it is closed and removed from the pool.
This makes easier to overcommit `--db-maxconn` when running in worker
mode. We can set a value which is large enough for the websocket
requirements without the WorkerHttp having a large number of useless
opened connections.
closesodoo/odoo#113110
X-original-commit: 9fcf3de6a9f10d4171bb48feb65fd789db19d4c6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A typical Odoo worker is able to handle ~20 requests per second. With a
default limit to 8192, it means that the worker is recycled after
8192 / 20 = 409s ~ 7 minutes.
There is no reason to recycle a worker that often, since there are
other means of limiting the resources allocated to a worker such as the
memory limit.
We increase the default limit request to 65536, therefore the lifetime
of a worker should be extended to ~1 hour in peak times.
closesodoo/odoo#107970
X-original-commit: a24d32003af334d63f04d6892dbc2e4383a65301
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If the method `_auto_install_l10n` is called programmatically on a DB
where the localization has already been installed, useless processing is
performed by `button_install`.
Do not call this method if no module need to be installed.
closesodoo/odoo#106419
X-original-commit: 11e9d3f1a9e8c85fa85a86f0a63935250552a19f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When calling a `auth=none` route with a non-existing DB name, the server
redirects to `/web/database/selector`. Such a route can be called
without database, therefore it is expected to work if the database
doesn't exist as well.
Before the HTTP refactoring, the fallback was `_dispatch_nodb` [1]. We
roll back to the same behavior since there is no good reason to redirect
to `/web/database/selector`.
Commits 4b330f3173 and de4e67dcc529163 are reintroduced as well.
[1] https://github.com/odoo/odoo/blob/b3199e949ae70307e8181ba0d6237871d6d07af7/odoo/http.py#L1529closesodoo/odoo#104174
X-original-commit: 1565e85890f1d14e067edd1c198c7199ab536307
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Olivier Dony <odo@odoo.com>
When a login attempt is ignored, we add the user info for a better
understanding on the attack (brute force, credentials stuffing...).
closesodoo/odoo#91588
X-original-commit: 0f69448202244e808e1122a618be701806d606cf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When setting up the PG replication, the slave is considered in recovery
mode. However, `LISTEN / NOTIFY` is not supported in this mode, leading
to an endless loop of crashes.
In recovery mode, we simply deactivate the feature.
closesodoo/odoo#87619
X-original-commit: 6389a64953081130d62f2a1703a27ddfa751098b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set up a POP account
- On the POP account, receive emails addressed to various recipients,
e.g. `my_alias_1` and `my_alias_2`. Receive more than 50 emails to
`my_alias_2`.
- In Odoo, create a mail alias for `my_alias_1`
- Run the fetchmail cron
The cron runs endlessly until it is killed. In the logs, inconsistent
messages are shown:
```
...
Fetched 3507 email(s) on pop server xxx; -16493 succeeded, 20000 failed.
Fetched 3507 email(s) on pop server xxx; -16543 succeeded, 20050 failed.
...
```
First the message count is incorrect in the log. We fetched at most 50
emails, not the total number of emails. Then, the endless loop is due
to the fact that
- we do not delete failed messages (= messages addressed to
`my_alias_2`)
- we always fetch messages from `num=1`
If the first 50 messages fail, we fetch them endlessly until the cron is
killed.
To avoid this, we compare the number of failed messages with the number
of messages retrieved. If all messages retrieved have failed, we stop
the loop.
After the fix, consistent messages are show in the logs and the process
stops after the first complete failure:
```
start checking for new emails on pop server xxx
Fetched 50 email(s) on pop server xxx; 0 succeeded, 50 failed.
```
Note that it doesn't solve the core of the issue; we just fail faster. A
proper way would probably be to use an offset so we don't always start
at `num=1`. On the other hand, it is just a matter of time before the
cron times out: if the mailbox is full of messages which canot be
treated, we will just spend more and more time trying to find the ones
which can be treated.
closesodoo/odoo#81493
X-original-commit: 72cd8d0769097b21bbf94a34496888617058cb1b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Get a database with millions of files in the checklist (do not ask how
this happened)
- Set a cron timeout low enough so that `autovacuum_job` times out
The file GC will endlessly timeout without being able to delete any
file.
This is due to how the `_file_gc` method is built: we first build the
whole whitelist, then we perform the deletion. With millions of
checklist files, the loop which builds the `whitelist` takes ages. It
ultimately leads to a timeout of the scheduled action, and therefore no
file is deleted.
To avoid this, we delete the files progressively. The checklist is split
in chunks, and we check which files must be GC'd in a given checklist
chunk. This way the files are removed even in case of timeout, meaning
that there will be less files to check during the next run. Eventually
the GC won't timeout anymore.
closesodoo/odoo#79834
X-original-commit: dbae52479062ace9e2b2d376ec2d601d86482f86
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Stock Valuation Layers are used for the MRP Cost Analysis feature.
Therefore, they are useful for consumable.
opw-2412668
closesodoo/odoo#63404
X-original-commit: c68e572f7c6f5109f1bfc40f9a44fc051f315112
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set the Delivery in 2 steps in the warehouse
- Create a 'wave' route:
- Sequence: 5
- Apply on Product Categories
- Rules:
- Action: Pull From
- Operation Type: San Francisco: Pick
- Source Location: WH/Stock/Chairs
- Destination Location: WH/Output
- Supply Method: Take From Stock
- Propagation of Procurement Group: Fixed
- Fixed Procurement Group: Chairs
- Create a 'Chairs' product category, apply the wave route
- Create a 'Chair' product:
- Category: Chairs
- Storable
- Make some stock in WH/Stock/Chairs
- Create a SO for 1 Unit of Chair, confirm
=> a picking from WH/Stock/Chairs to WH/Output is created
- Create a SO for 2 Units of Chair, confirm
=> the 2 units are added to the previous picking
However, the 2 stock moves are not merged.
It happens because `date_deadline` prevents the grouping.
opw-2390630
closesodoo/odoo#62983
X-original-commit: c4505b704489db7ef47dd9a201def536a99d03f3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The creation of a Stock Valuation Layer is useless in case of a
Consumable product. At best it is useless, at worst it causes
inconsistencies when the user switch from a Consumable to a Storable
type.
closesodoo/odoo#62936
X-original-commit: 7e9d052beabe15d932e5d403f8ca2f4837c7d24f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Changing a product type from Consumable to Storable usually gives
unexpected results once some stock movements have been performed
(negative inventory, wrong valuation...).
While it should remain possible to do it (as long as the user knows what
he is doing), it is worth pointing the fact that unexpected results
are... to be expected.
To do so, we raise a non-blocking warning.
X-original-commit: 383b12977062cacc6ff0f553d7012029268be1ec
- Activate Multi-Currency, set a rate for a foreign currency
- Create a product with a cost of 10
- Create a PO
- Add the product
The price remains 10: it is not converted in the foreign currency.
Up to 13.0, a price of zero was set if no seller was found. This was
changed in 6b41dbf683 to set the standard price instead.
However, no currency conversion is performed.
opw-2394076
closesodoo/odoo#62831
X-original-commit: 315b7f822124fcd06c4c6ea7c8ecb8b7411338c5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate Anglo-Saxon accounting
- Set a foreign currency rate to 2.0
- Create a product A:
Inventory Valuation: 'Automated'
Costing Method: 'Standard Price'
Cost: 10.0
Public Price: 100.0
- Create an invoice in foreign currency
- Add 1 unit of A => the total amount is 200.0
- Confirm the invoice
The Amount Due is 100.0 instead of 200.0.
This happens because the Anglo-Saxon lines have the company currency,
while the other lines have the foreign currency. Because of this, the
`_compute_amount` method considers the move as multi-currency to compute
the various amount. However, the Anglo-Saxon lines should be neglected.
This happens from 14.0 because all lines have a currency. In previous
versions, lines in the company currency didn't have the `currency_id`
set.
opw-2390107
closesodoo/odoo#62657
X-original-commit: 9e1aec7873a935b287b4b3c5dbc2688acee5422a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The `name` field is not required on the `payment.icon` model. Therefore,
in case the payment icon name is not set, a traceback is raised due to a
`False.lower()` statement.
opw-2409755
closesodoo/odoo#62646
X-original-commit: 54434a4fdd71b1e344255fb6f3e42d731ba91f3b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Multi-warehouse + Multi-company setup
- Create Company A with warehouse and 1-step delivery
- Create Company B with warehouse and 1-step delivery
- Switch to Company A: Set Logistics route on product category
All/Saleable : 1-step delivery
- Switch to Company B: Set Logistics route on product category
All/Saleable : 1-step delivery
- Switch to Company A, make sure Company B is turned-off
- Create new product and set category to All/Saleable
- Save product
Multi-company error is coming.
This is due to the field `route_from_categ_ids` which is a related, and
therefore fetched as `sudo` by default:
https://github.com/odoo/odoo/blob/f0330d92b31bdae4637ae0c26f40ee07282ab449/odoo/fields.py#L368
Actually, the field doesn't seem to be useful since it is only used in a
view.
Fixes#58357
opw-2390983
closesodoo/odoo#62609
X-original-commit: b68b45d5105a4d797da12ee6a5df6162b52b2d61
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create Product A with UOM of type Unit
- Create Product B with UOM of type Unit
- Create BOM of type Kit on Product A with Product B as a component
with UOM of type Unit
- After saving BOM, change the UOM of Product B with UOM from another
categories (e.g. kg) and save the product
- Try to access product list
A warning appears and prevent showing the products in any way.
It is caused by the call to `_compute_quantities`.
In this case, it is ok to skip the error. Indeed, it will raise later on
when trying to use the kit. But at least, it gives the possibility to
the user to access the product list.
opw-2393711
closesodoo/odoo#62537
X-original-commit: 6de2537ac82d9dad3cb3f56a7b9b35856681a6ad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since commit https://github.com/odoo/odoo/commit/3ad4abe171e8e7e86ed0e7b7f000e734d8a2ad92
the default invoicing policy of a product is set to 'delivery'. This is
not ok for the delivery products: a delivery product is never delivered.
This is confusing to end users, because they do not realize that a
delivery line is not included in an invoice. This is especially true if
the delivery is free.
This commit sets the default policy to 'order' for master data and for
newly created products from the shipping form view.
opw-2387437
closesodoo/odoo#62357
X-original-commit: 4c2768846809f6687d03eb0d7f501e57c2c93a90
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Report
- Export as XLS
The header values have too many decimals: 60739.2000000007
The root cause is `convert_to_cache` returns this value:
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
In this case, `currency.round()` keeps the extra digits. Since the field
is not stored, the useless digits are kept.
A simple solution is to use `float_repr` on the non-stored float fields
to make sure that doesn't happen. Another solution could be to not
convert the floats to strings, but that doesn't seem intended.
opw-2378895
closesodoo/odoo#62265
X-original-commit: 2ebcbb16f113dee1416097b7a52f8068a40a34cf
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
1. Create a storable product
2. Set the category: Costing
- Method: First In First Out (FIFO)
- Inventory Valuation: Automated
- Price Difference Account: Price different accounts.
3. Create a vendor bill with the product and the quantity set as 0, and set a tax
4. Post the vendor Bill
A ZeroDivision error is raised.
opw-2375464
closesodoo/odoo#62120
X-original-commit: beeb83ca53c52dc189faaff4d76711bbcf24a08c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- 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>
- Create a product with price 2335.5, no tax
- Start a POS session
- Add the product, set a discount of 3% on the line => total is 2665.44
- Validate and close the session
- Got to Point of Sale / Reporting / Orders, open the pivot view
The Total Price of the order is 2665.43.
It happens because the server returns a value of 2665.435, which is
displayed in the pivot view as 2665.43.
We round the Total Price based on the company currency decimal
precision. Indeed, all amounts are converted in this currency in the
report.
opw-2369023
closesodoo/odoo#62023
X-original-commit: 178d5c879ccf7ed59e602f049377417ace353fa9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install accounting app
- Go to "Charts of Accounts" view by setup panel
- Create a new record
A traceback occurs because `self.ids` is empty in the context of the
creation of a new record.
opw-2379463
closesodoo/odoo#62014
X-original-commit: b325266bc9d3893e037b3fd8d734ac7d3d510c41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Some projects may not need the tags, while others use the state heavily.
This makes both fields available and optional.
closesodoo/odoo#61932
X-original-commit: 26e26181c9680e89f8c8e1eb3b4c9dc2fc063d87
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a POS session
- Sell some items
- Close the session, go to the closing page
- Duplicate the browser tab
- Close the session in tab 1
- Close the session in tab 2
The journal entries are created twice.
There should be a server check before closing the session.
opw-2379278
closesodoo/odoo#61860
X-original-commit: 0ba535c5123fecb410fa7546b5bb39a52884ca40
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a DB without demo data
- Install `account`
- Install l10n_bo
The tax report loading fails.
This is caused by the missing country.
opw-2378095
opw-2379117
closesodoo/odoo#61678
X-original-commit: f954687d3a78be5e6fb5b9270805ecfb1081d38d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Allow online payments for invoices
- Create an invoice and assign it to Joel Willis. Post the invoice.
- Connect as Joel Willis and pay the invoice
In the `/my/invoices` view, the invoice is set as 'Paid' and 'Reversed'.
It should not be labeled as reversed.
The issue is probably a wrong copy-paste of the line above:
https://github.com/odoo/odoo/blob/478ebc74554f6609a1414726ee1f35fe5dcd6a81/addons/account_payment/views/account_portal_templates.xml#L28
Indeed, the `last_tx.state` has no impact on the fact that the payment
is reversed.
opw-2373146
closesodoo/odoo#61627
X-original-commit: 2fd4e48cbb673175323fb866d87e654c5c9e05ac
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Hide the forecast widget in case of kits. Indeed:
- the forecast report doesn't support kits
- the semantic for a kit forecast is far from being obvious, especially
in case of partial deliveries, returns, returns of returns, etc.
Better hide it than displaying an incorrect information.
closesodoo/odoo#61522
X-original-commit: c1fccaee5dd676f2fe07bb5c17eb2967ee6b742e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A cash rounding precision must be strictly larger than zero to follow
the restriction introduced in e270e9e0cc.
opw-2341804
closesodoo/odoo#61382
X-original-commit: 563752358d233d4fc9cf1d7e7abd0b1656dc82c1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
We extract the `price_unit` and `tax_ids` recomputation logic from the
`_onchange_product_id` method. This way, it can be called
programmatically.
opw-2371934
closesodoo/odoo#61477
X-original-commit: ca6f25bef45137c032bc5cafd336c3f16a97a929
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In a 12-hour clock:
- 00:30 is 12:30 AM
- 12:30 is 12:30 PM
opw-2374394
closesodoo/odoo#61321
X-original-commit: c25805189ea221cbcf1ef81ed9e250d14a3c1a80
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set a customer language to a different language, e.g. French
- Create a SO, add a product and validate
- Create a down payment
The down payment invoice is partially translated in French.
This was first solved in fc659d3f78 but broken in
0e73eca1364c8e0df93cd.
opw-2365982
closesodoo/odoo#61207
X-original-commit: f10b98d1776659f291b2f7f8a4a2111e4f106667
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate UoM
- Create 3 products: AB, A & B
- Create a kit BoM for AB
- 1 units of A
- 1 kg of B
- Sell 1 unit of AB, confirm
The error "The unit of measure Units defined on the order line
doesn't belong to the same category...".
This happens because `_compute_quantity` is called on `stock.moves`
related to different products.
As a first step, we simply keep only the moves of the same product,
meaning that the `qty_available_today` and `free_qty_today` are not
supported for kits.
opw-2372676
closesodoo/odoo#61071
X-original-commit: 15368c6d1316d43b1591b88e4d5786d86403f8a1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate stock locations
- Go to Inventory > Configuration > Locations
- Click on the 'Products' stat button
The filters `real_stock_available` and `real_stock_negative` are not
applied although they are in `search_default_`.
This is due to c1f7987f49 which refactored the various search
views of products.
The solution is to add the `search_view_id` in the action. However:
- `<act_window>` doesn't support it
- `<act_window>` is deprecated in 14.0
Therefore, we convert the `act_window` element into a regular `record`
and add the appropriate `search_view_id`.
opw-2371962
closesodoo/odoo#60942
X-original-commit: 9677128c42761123e59fa8187a59864eb89f06e8
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 2 warehouses A & B
- In the website settings, set the `inventory_availability` as `always`,
but do not set a warehouse
- Create a Product P, make some stock in warehouse A
- Create a Product Q, make some stock in warehouse B
- Publish the products
- Go to `/shop` => both products have availability
- Add P in the cart => it works
- Add Q in the cart
Error: 'Some products became unavailable and your cart has been
updated...'.
This happens because the availability is checked on the warehouse of the
SO, not the warehouse of the website (not set in this case).
opw-2361768
closesodoo/odoo#60895
X-original-commit: 6b05fb2b21a3b58cfef3f280941d985eec158b78
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The 'Mark as lost' server action raises an AccessError when executed by
a non administrator.
Due to de4213b771
opw-2371490
closesodoo/odoo#60866
X-original-commit: b80e44bac5de3ccffad42917307bb5f049a7bec6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install account / purchase / sale
- Ceate an internal user without any access rights
- Go to `/my`
A 500 error is raised because of an AccessError.
When the user has no access rights to any of the mentioned applications,
the `search` call returns an AccessError.
We prevent the access error and return 0 as a fallback.
opw-2367559
closesodoo/odoo#60849
X-original-commit: 54ef98c613219aba3bda41817f7767261b8092d2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Prevent crash in case `base.default_user` has been deleted.
Note that the user shouldn't be deleted in a first place, but that's
another discussion...
opw-2360615
closesodoo/odoo#60821
X-original-commit: 7342cadcfe8d85edb8a53aef0ecc402dbbc7e935
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create SO 1:
- Section A, sequence 10
- Product A, sequence 11
- Create SO 2:
- Section B, sequence 10
- Product B, sequence 11
- Select both SO
- Create the invoice
The resulting invoice lines are organized as follow:
- Section A, sequence 10
- Section B, sequence 10
- Product A, sequence 11
- Product B, sequence 11
This is obviously not expected as it messes up the organization of the
lines.
This happens because the sequences of the SO lines are kept at invoice
creation, while it is necessary to resequence the invoice lines to keep
them organized.
To do so, we loop on the invoice lines before their creation in order to
assign a sequence corresponding to the order in which they have been
added in the list. Since the invoice lines are added one SO after the
other, this allows us to keep the appropriate ordering.
Note that we only resequence if there are less invoices to create than
SO, meaning that several SO have been merged. Indeed, in case a single
invoice is created from a single SO, there is no need to resequence.
This assumption is not completely true: if not all selected SO were
invoiceable, the number of invoices created is also smaller than the
number of SO. However, resequencing should be safe so in the worst case
we might resequence an invoice while it was not necessary.
We also leave the possibility for third-party addons to alter the
resequencing thanks to the `_get_invoice_line_sequence` method.
opw-2363443
closesodoo/odoo#60789
X-original-commit: 97c2f5ea51a669830b3e6d6d2d7d857742a41481
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a user A with access rights to Project set as 'User'
- As user A, add a follower to a task
An AccessError is raised.
It happens because `allowed_user_ids` has the group
`project.group_project_manager`.
Since a Project User is allowed to set followers on a task, it is
legitimate to set the appropriate portal user as allowed.
opw-2369674
closesodoo/odoo#60725
X-original-commit: 5ee045b2532ce97094dea2fe6b5e354585d67691
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create companies A & B
- Create a Dropship route for B
- Create a product P with route 'Dropship'
- Set the website under company A
- As a portal user, buy the product P on the website
- Do the payment
The SO is confirmed but the Dropship route for B is used despite the
fact that the website is under company A.
This happens because `_search_rule` is called as superuser: therefore,
routes from all companies are retrieved.
To prevent this, we add the company in the domain.
opw-2349094
closesodoo/odoo#60482
X-original-commit: 31a54b5e859ead7972cdccc956518e14038476ba
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a partner outside Europe
- Set a VAT number
- Create an invoice for the partner
- Post the invoice
The `IdPaese` and `IdCodice` is obtained from the VAT number, but it is
not correct for partners outside Europe: the VAT number should always be
`OO99999999999`.
A workaround is to set the VAT number of the partner to
`XXOO99999999999`, where `XX` is the country code. However, in case of
multi-company with shared partners, another company might need the
proper VAT number.
In case of a customer outside EU, we:
- get the `IdPaese` from the country of the partner
- set the `IdCodice` to `OO99999999999`
We also add the `IdPaese` to customers without VAT.
opw-2355842
closesodoo/odoo#60416
X-original-commit: 35267c59c32f747351e8741cfe6011749914e809
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The widget is intended for informative fields only, i.e. the
fields do not need to be editable. It is not the case for the
date_deadline.
closesodoo/odoo#60317
X-original-commit: a455999588053d528cc779b070cac31ab3b273df
Related: odoo/enterprise#14223
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The `remaining_days` widget is intended to be used for informative purpose,
hence it should not be editable.
opw-2362276
X-original-commit: 4c72b1536a19cd517046113a5ad93b5782774664
- Create a tax:
5%
Included in price
- Set the company currency to USD
- Set the currency rounding of CHF to 0.05
- Set the rate for CHF to 0.654065014
- Create the following invoice in CHF:
Set a payment term
Prod 1, 1 unit, 5.0 CHF, tax 5%
Prod 2, 1 unit, 10.0 CHF, tax 5%
Prod 3, 1 unit, 50.0 CHF, tax 5%
It is not possible to save the invoice because of an unbalanced journal
entry.
Indeed, the Receivable line is $99.30 while it should be $99.29. This
happens because we round the `total_balance` with the rounding precision
of the invoice currency while it is in the company currency.
closesodoo/odoo#58798closesodoo/odoo#60035
X-original-commit: dad5e2a575448b68cc1b59880fecfe48dbe30a4e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a tax:
5%
Included in price
- Set the currency rounding of the company to 0.05 (e.g. CHF)
- Create the following invoice
Prod 1, 1 unit, 5.0 CHF, tax 5%
Prod 2, 1 unit, 10.0 CHF, tax 5%
Prod 3, 1 unit, 50.0 CHF, tax 5%
The total amount of the invoice is 64.95 CHF instead of 65.00 CHF, even
in a 'Round per line' configuration.
It happens because `compute_all` rounds the amounts following the number
of digits of the currency instead of using the `rounding` field.
Note that there is a discrepancy between the POS computation and the
Account computation: the POS already uses the `rounding` field instead
of the number of digits:
https://github.com/odoo/odoo/blob/80073c5430f0ab562dfc27572c108114161ebb25/addons/point_of_sale/static/src/js/models.js#L1855-L1991
opw-2341566
X-original-commit: 94353ebd6b47a286157f0559b194ff03ea49ff68
- Create companies A & B
- Switch to company B
- Open a POS session in company B, but do not close it
- Switch to company A
- Set a Lock Date for Non-Advisers
The error message 'Please close all the point of sale sessions...' is
raised.
The message shouldn't be raised since the session is not in the company
we are setting a lock date.
We filter the session based on the company.
opw-2351930
closesodoo/odoo#59529
X-original-commit: a1445bf45fadf21a4af5dd2791efda4a4450a825
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The Duration Per Unit should be averaged, not summed.
opw-2353041
closesodoo/odoo#59446
X-original-commit: 54b40f1eb096ea9531f1f9b0478937536c8292fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to the Contacts app
- Click on the Azure Interior company, or any other company with multiple associated people
- Set the country to Mexico
- Edit the VAT field and enter the following string: UAC070620MB3
Traceback will happen after hitting save.
It happens because `self` is a recordset in this case. Moreover, while
the VAT number starts with `UA`, the country is Mexico so the check is
incorrct.
opw-2348045
closesodoo/odoo#59260
X-original-commit: 3dbdc62b3458e9af2e74d8552a17d629dc7e2393
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install accounting
- Create a company with a '.' as last character of the name, e.g. 'Test
Inc.'
- Set the Fiscal Localization for the company
An error occurs: "You cannot use anything else than unaccented latin
characters in the alias address."
This happens because we try to create the alias `test-inc..inv`: `..` is
not allowed by the RFC 3696.
We replace the `.` by `-` which is a supported character in the
localpart.
opw-2347965
closesodoo/odoo#58904
X-original-commit: 5053183ac7612d9cf2247b84ec6e0aac5974fd85
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 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
- Set the company country to India
- Open th POS, make a sale
- Print the receipt
The label for the VAT is 'VAT' while it should be 'GSTIN'.
The `VAT:` label is hardcoded in the receipt template. It is expected to
be adapted to the localization thanks to the translation. However, in
this case it doesn't work: since we keep the English language, there is
no translation applied.
We use the country `vat_label` and fall back on the `VAT` string.
opw-2343652
closesodoo/odoo#58864
X-original-commit: bfe3a127f5535e11cc87ebd0fff4a5cfe5039a23
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The field `invoice_partner_bank_id` was renamed `partner_bank_id`
closesodoo/odoo#58295
X-original-commit: c58684c07658ef7170f9696cc2fbb033ec46ba96
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Fine-tuning of 9d7d618220e27024321a75be0058db2289115af2
Although the mentioned commit delays the consumption of a sequence
number at creation, it has the drawback to not generate one if the user
modifies the name.
In practice, we still want to generate a RMA number even if there is a
custom name. A good balance is to generate the RMA number if the user
leaves the `/` at the beginning of the name. If the user removes the
`/`, we don't generate the RMA number.
opw-2301412
closesodoo/odoo#57932
X-original-commit: 2ad9b4b2b5780c20a0cd77c48b24dcb76d69f912
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a SO
- Add a line with a lead time != 0, e.g. 7 days
=> the Expected Date is today + 7 days
- Add a note or a section on the SO
The Expected Date is today
This happens because we do not filter out notes and sections when
computing the minimum date.
opw-2340419
closesodoo/odoo#57792
X-original-commit: d3a6afe51fc4b864368acbc40a86ac6974d328dd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Add back the default filters when opening the WO view from the work
center kanban views.
opw-2329401
closesodoo/odoo#57813
X-original-commit: 15ed2b92b83929becfd50334c7a31282c46d44d6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If there is no `date_end`, sorting will crash.
opw-2326262
closesodoo/odoo#56603
X-original-commit: e981c17dd93c756a5cf0384ab2dcc25ef58cb1b1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case `date_planned_finished` is `False`.
opw-2326088
closesodoo/odoo#56578
X-original-commit: 5c7c6b42cc0e0fa5bdd78aeca48cdf4ba9f78cad
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The printed status should not be kept when duplicating a picking.
opw-2320680
closesodoo/odoo#56449
X-original-commit: 6938e5bf106f95149bce50fac7ed3291bd1da812
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create Tax 0:
Percentage
Amount: 0
Tax Included
Tax Group 0
- Create Tax 8:
Percentage
Amount: 8
Tax Included
Tax Group 8
- Create a customer invoice with one line
Quantity: 8.0
Price Unit: 15.55
Taxes: Tax 8, Tax 0 (order is important)
The tax amounts are:
Tax 8: 9.22
Tax 0: -0.01
If the taxes are inverted, the tax amounts
Tax 8: 9.21
Tax 0: 0.00
The difference is due to the rounding of the 8% tax done differently. In
the second case, the computation of the 8% tax goes through:
https://github.com/odoo/odoo/blob/8c5cd335a57c20ed5faa6b7c7630c296c1f2a5cf/addons/account/models/account.py#L1480
In the first case, the amount is recomputed in:
https://github.com/odoo/odoo/blob/8c5cd335a57c20ed5faa6b7c7630c296c1f2a5cf/addons/account/models/account.py#L1483
The rounding is different in both cases, leading to an inconsistency.
When the tax amount is zero, there is no need to save the amount in
`total_included_checkpoints`.
opw-2306676
closesodoo/odoo#55812
X-original-commit: e2776e188070221ef465a864bd2cb8dcfc971e14
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
A POS payment method should be translatable.
opw-2314353
closesodoo/odoo#55623
X-original-commit: 84cb31f8632785caf9a313c8423550b5ca51ed11
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P which cannot be sold (purchase only)
- Create a customer invoice
The product can be select on the invoice.
The `sale_ok` (as well as the `purchase_ok`) field is not taken into
account in the domain.
The solution is a bit hacky but has the advantage to be safe in regards
to customizations.
opw-2308897
closesodoo/odoo#55442
X-original-commit: 88b0b664606bb42acf26165e2b7fdda44a15e0a7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit 987951a8d4 moved the CSS file from `point_of_sale` to
`pos_hr`. A file was forgotten.
opw-2293465
closesodoo/odoo#54771
X-original-commit: c0fd47d0993cdbf84cf4d13723e172399d119da5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Install `website_livechat`
- Publish the demo livechat
- Set an accent to the operator name, e.g. 'Bòb'
- Visit the website with Safari and start a chat session
- Close the window
- Refresh the page
Error in browser console that sometime appear as a traceback.
It happens because Safari refuses to send any cookie containing
non-ASCII characters [1]. Actually, Safari strips the value before the
first non-ASCII character, making the JSON string corrupted.
Having such special characters in cookies is uncommon, so we only clean
the necessary string. Moreover, it's better to avoid our tools modifying
all cookies set without being aware of it.
[1] https://stackoverflow.com/questions/1969232/what-are-allowed-characters-in-cookies/1969339#1969339
opw-2273293
closesodoo/odoo#55277
X-original-commit: df003873c20357343f8aa17a645acfb6b03ef68b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product with routes MTO + Buy.
- Create a vendor pricelist with a minimum quantity:
Min. Qty 1000 for 10 USD
- Create a SO, sell 1000 quantity
=> A PO is created automatically in draft.
- Go back to SO and update quantity to 1200.
The following message pops up: "There is no matching vendor price to
generate the purchase order for product..."
We select the supplier based on the procurement quantity, which is lower
than the minimum quantity of the supplier.
To avoid this situation, we fall back on any supplier like it was the
case in v12.
opw-2297001
closesodoo/odoo#54526
X-original-commit: 4d4913fc366dcd62740b91eda3aa3f81270affda
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set the following access rights to a user A:
Point of Sale: User
Invoicing: Billing
Inventory: User
- Create a product P, FIFO + Automated
- Add some stock for P
- As user A, open the POS
- Sell one unit of P
- Close the POS and validate entries
An access error is raised because the user doesn't have the right to
read the `stock.valuation.layer` object.
We can retreive the value as `sudo` in this case.
opw-2305446
closesodoo/odoo#55224
X-original-commit: d3147910e031253ddb172959e9016a0f326d7cdb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a vendor bill, post it
- Go to Accounting > Accounting > Journals > Purchases
- Select the items linked to the vendor bill, delete
Nothing prevents from deleting the items while a posted entry cannot be
modified.
opw-2305873
closesodoo/odoo#55187
X-original-commit: 14ef02f73e649b5f8c50f09213f0a0dbddf46217
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Configure a Product Category Automated + FIFO
- Create a product in this category
- Create a PO for 10 units, receive the units, bill the PO and pay
- Sell 1 unit of the product and deliver it
- Create an invoice for the order
- Without paying the invoice, create a credit note with the option
'Full refund and draft invoice'
- Post new invoice
The anglo-saxon lines are counted twice.
This happens because the lines already exist in the newly created draft
invoice.
For the sake of simplicity of the fix, we clean-up the invoice after
creation.
opw-2300536
closesodoo/odoo#55158
X-original-commit: 02d857b8aa75962f535ab4cd69ff8e2a6ef3fb48
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The currency of Slovakia is EUR (since 2009).
opw-2293328
closesodoo/odoo#54507
X-original-commit: 7a414dd666ae57285762f059e1c3e3cdb4801a1f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
1. Create a new location of type internal in WH/Test
2. Create a new product P with availability of 100.0 in WH/Stock
3. Create a new transfer from WH/Stock to WH/Test with 50.0 units of P,
Put in Pack and Validate
4. Create a new transfer from WH/Test to WH/Stock/Shelf 1 using the
previous package, Validate and Unpack
5. Repeat steps from 3 and 4
6. Create a new transfer from WH/Stock/Shelf 1 to Customer with 100.0 units of P
7. Review stock quant from the location WH/Stock/Shelf 1
2 quants of the same product in the location WH/Stock/Shelf 1: one
negative with -50.0 and another positive with 50.0
The step 4 creates 2 quants of 50.0 units, which are reserved at step 6.
However, when validating the transfer 100.0 units are taken from one of
the quants.
To prevent this situation, we run the quant vacuum process after
unpacking. This will merge the 2 quants of 50.0 and prevent any future
negative quant creation. We also clean zero quants, although this is not
mandatory to fix our use case.
Closes#53535
opw-2283707
closesodoo/odoo#54431
X-original-commit: f7168311f4333f7fc684e00e1c1c284981718335
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P, tracked by lot
- Add some stock with a lot
- Create an outgoing picking
- Set 10 units of P
- Set 2 done, Put in Pack
- Unreserve
An error occurs: 'It is not possible to unreserve more products of P
than you have in stock.'
It happens because the `lot_id` is removed from the copied
`stock.move.line`.
Commit eac8c06e2233d93e0b1a520e makes sense for incoming pickings, but
not for internal or outgoing transfers.
opw-2288208
closesodoo/odoo#54355
X-original-commit: ed738fb56ffe84f3af08b84e429db916a5e560b6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Seta a value for the `ir.config_parameter` `mail.catchall.domain`
- Enroll user A to a course
- Add new content to the course
- Publish it
=> an email is sent to the users enrolled
- Reply to the email
The reply is considered as a review of the course.
It is not intended that users reply to such email; they are 'one-way'
notifications.
A solution is to be able to set the `reply_to` field on the mail
template. This way, it's possible to set it to a `noreply` value.
opw-2290521
closesodoo/odoo#54281
X-original-commit: 7ffc300e7c857bf743d7ab25631f9ee02419dea1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In an app using rating (e.g. eLearning), get 3 ratings:
- A 5-star review
- A 3-star review
- A 0-star review
The average is 2.5 stars, while it should be 4 stars.
This happens because the 0-star review is taken into account in the
average computation, while it shouldn't. Indeed, zero star means no
review.
We apply the same login than:
https://github.com/odoo/odoo/blob/0028a602bea6a48aaa2747127ec075394732b324/addons/rating/models/rating_mixin.py#L205
opw-2290617
closesodoo/odoo#54279
X-original-commit: 4f7981f80fb55ab4bf8b30d137e45b4fda4013cd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate more than one language
- Install sale_quotation_builder
- Create a new quotation model without website description
- Create a SO using this model, Save
The 'Please update translations of' is displayed for the website
desctiption, although it is empty: when clicking on the link, no record
is shown.
This happens because an empty HTML field always contains at least
`<p><br></p>`.
We do not consider the latter string for translation.
opw-2274203
closesodoo/odoo#54025
X-original-commit: aad4d516b6fb4b286f24bc536e5ecb67558a0c4d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Ensure deterministic sorting for slides with the same sequence.
opw-2283154
closesodoo/odoo#54008
X-original-commit: 46bd51dc5f7b674409beac2557cbd19ec001944b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In case the COA is imported in the system, the `chart_template_id` of
the company remains empty while the accounting is usable. However, in
this case it's impossible to open a POS session.
We leave the warning in the POS config but avoid blocking the user.
opw-2286640
closesodoo/odoo#53999
X-original-commit: c73b241c5e8c269e1ebc4f517cc270d90b2e44ca
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product with a very long product description
- Add in a SO and print the quotation
The description overlaps with the table header on the second page.
This is a known issue of wkhtmltopdf (see issues 1770 and 1524 for
example), and there is no known workaround. It can be avoided by
preventing the repetition of the header.
closesodoo/odoo#53990
X-original-commit: f54c73f9a42476e1f0d2de1904644f317ee1dffb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a new POS session with User A
- Make an order
- Logout and connect as User B
- Resume the session
The session cannot be resumed and the user is redirected to the POS
Dashboard.
When searching for a session to resume, the search restricts the user to
the current user. Therefore, no session is found.
If no session is found, we search on sessions corresponding to the given
configuration. The configuration is mandatory to avoid being redirected
to a random session.
opw-2274973
X-original-commit: 2deb94aa9da821455374df5602e2d30c5befcdec
1. Install the demo data
2. Activate GeoIP and set your IP in Belgium [1]
3. As a non-connected user, go to '/partners'
=> No result found: expected since we want to filter the partners
available in the user's country
4. Click on 'All Countries'
=> All partners are displayed
5. Click on 'Platinum' or search for 'azure'
=> No result found
The last step is not expected, it should filter partners from the 'All
Countries' list.
It occurs because the 'All Countries' filter is not kept when chosing a
Level or searching.
We use `keep_query` for the level filtering and set the `country_all`
`input` field for searching.
[1] IP can be set manually in
https://github.com/odoo/odoo/blob/bbb45e3412a5653d78aacc92903e95d1353ed60a/addons/http_routing/geoipresolver.py#L42
opw-2277343
closesodoo/odoo#53761
X-original-commit: ece98773a18cf0f83a3d2e44397e7e08a3a538a9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Go to Inventory > Reporting > Inventory Report
- Filter the location with a negative operator, e.g. 'Location doesn't
contain "shelf"'
Locations containing 'shelf' are displayed anyway.
We are adding this condition: `'|', ('barcode', operator, name)`. Since
barcode is empty (or at least doesn't contain 'shelf'), the condition is
met and all records are retrieved.
In case of a negative operator, both `barcode` and `complete_name`
must not match.
opw-2281191
closesodoo/odoo#53717
X-original-commit: 8fedbcda6a89d99d42df3694390eac4cf7a987ed
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P with 2 variants A & B (e.g. 2 colors)
- Create the following BOM
Component 1
Component 2a, applies to variant A
Component 2b, applies to variant B
- Create a MO
- Set the product to variant A
=> 2 components are added: 1 and 2a
- Change the product to variant B
The component 2b is added but 2a is not removed.
The issue is coming from the result of the onchange, when comparing the
2 snapshots. The result contains the following commands:
- [(5,)]: clear the lines
- [(1, ...): ]: update component 1
- [(4, ...)]: keep component 2a
- [(0, ...)]: add component 2b
In case we are changing the product, we clear the lines.
opw-2270990
closesodoo/odoo#53689
X-original-commit: 89d9e759ae0cc31ad1fc398d41fa7a638056309e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a product P, valuation FIFO automated
- Receive some stock
- Create a SO with 1 unit, validate
- Validate the picking
- Create the invoice, validate
=> the Stock Interim Account (Delivered) entries from the invoice and
the stock move are reconciled
- Return the picking, choose to update the quantity on SO
- Validate
- From the SO, create the invoice (which is a credit note), validate
The Stock Interim Account (Delivered) entries from the credit note and
the returned stock move are not reconciled. Note that both entries are
properly reconciled if the refund is generated directly from the
original invoice.
When retrieving the stock moves linked to the invoice, we always go
through the `refund_invoice_id` field, which is not filled in this
specific case.
The solution is to search from moves directly from the credit note
itself.
opw-2274731
closesodoo/odoo#53610
X-original-commit: 6aa7e843f427df17bc0845c44ab2345cfa93fb77
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 3 products A, B & C
A is in Units
B is in kg
C is in m
- Create a BOM kit for A using 1 kg of B and 1 m of C
- Create a PO for A, validate
- Receive the picking
An error is raised: "Conversion from Product UoM ... to Default UoM ...
is not possible as they both belong to different Category!."
It happens because `_compute_qty_received` incorrectly converts
quantities.
The computation of the quantity received for kits is done in 2 steps:
first we compute the quantity the same way we do it for a regular
product, then we overwrite the quantity with the value computed for
kits.
We can compute the quantity correctly at once by calling `super` only on
lines which are not kits.
opw-2302807
closesodoo/odoo#55047
X-original-commit: b82f71dac9452de9c1e16cde552fe260fec3c262
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Nicolas Martinelli