Define "Bootstrap v5 ready" utility-class to handle gaps.
This class definition can be safely removed after migrating to v5.
task-2733437
Part-of: odoo/odoo#82866
task-2767820
This move is done to prepare the use of server side model definitions during tests.
Indeed, a model having all type of tracked fields will be needed to ease tracking
value testing. This model will be added to the test_mail module so the tracking
value tests need to be there as well.
closesodoo/odoo#85819
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Small changes in the layout of the hr_leave form view,
mainly for the manager's view point
Task : #2734842 [Time Off] ux changes
closesodoo/odoo#82976
Related: odoo/enterprise#23896
Signed-off-by: Kevin Baptiste <kba@odoo.com>
One key has two different types. Fix one and
let the other one as is to use it in the report
clean commit a038607bfdbe764fd436a94ce8149720fdca87ff
closesodoo/odoo#85813
X-original-commit: 4ca4dbc6707f26d69a4116b1ad90c1d9082119a1
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps :
Install Sale / E-commerce.
Create product P (price = 100).
Create price list L.
Create price rule R (product = P, price = 50).
Go to product P > Price Rules > archive R.
Create a quotation. / Website > click 'Go to website' > Shop.
Select price list L.
Create a SOL with product P. / Search for product P.
Issue :
Price is 50.
Cause :
Archived price rules are included in the 'search' of
_compute_price_rule_get_items().
Fix :
Exclude them.
opw-2752184
closesodoo/odoo#85811
X-original-commit: d5e8308492ac8955ad76fd8d9f3781266dee76f6
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* Studio generate computed field "count" when the user add a button
in the button box. Since those lines are written by studio with drag and drop
it should not be counted for the maintenance subscription.
We can detect them because field created by the user in studio start with x_studio
and fields created outside studio does not have studio_customization
xml_id
* Add test to make no standard module introduce customization in the
database during the install the will be counted by cloc
see https://github.com/odoo/enterprise/pull/22664closesodoo/odoo#85763
X-original-commit: 47ae24081fe5c0c86ce8507229dfb550ec585633
Signed-off-by: Christophe Simonis <chs@odoo.com>
Signed-off-by: Thibault Francois <tfr@odoo.com>
Since Odoo now accepts ES2019 code anyway, I think that this polyfill
can safely be removed, to reduce assets size.
closesodoo/odoo#85800
Signed-off-by: Samuel Degueldre <sad@odoo.com>
When a user cancels a six payment method, he won't be able to select
another six payment method
To reproduce the issue:
(Use demo data. Install l10n_be so your company is in EUR)
1. Create two Payment Methods PM01, PM02 that use the same payment
terminal (a Six one)
2. Add the methods to the POS
3. Start a POS session
4. Select a product and go to payment page
5. Select PM01, send it then remove the line
6. Select PM02, send
Error: Nothing happens (the terminal doesn't receive the instructions).
After several seconds, an error message is displayed "Transaction was
not processed correctly: apiConnectionLostTerminal"
When starting the POS, because there are two payments methods, both are
instanced, each one with its own instance of `PaymentSix`. However, in
the above case, both payment methods use the same terminal. Therefore,
when sending the transaction with the second method (step 6), the API
creates a second WebSocket (for the second instance of `PaymentSix`)
between the POS and the terminal while such a `WebSocket` already exists
(first instance of `PaymentSix`)
OPW-2679181
closesodoo/odoo#85791
X-original-commit: 2912e0d116ceece51bb1274633cbd22e09735232
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
As in 13.0, the default terms and conditions must be translated in the lang of the partner
PS: In the first computation, narration will be equal to the narration in the lang of the user.
So it was not changed when setting a partner.
The narration must be computed in the lang of the partner.
Writing on payment_ref triggers function _synchronize_to_moves and a write on partner_id was made.
In the write function, function modified was called
https://github.com/odoo/odoo/blob/15.0/odoo/models.py#L3850
And it lead to add the field narration in self.all.tocompute
https://github.com/odoo/odoo/blob/15.0/odoo/api.py#L758
Meaning that the next time it read the field narration, the function _compute_narration was called.
So it reset narration to False
opw:2726012
closesodoo/odoo#85775
X-original-commit: 6d9745e63fec20a7e967f00a428db9109c992bcf
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This commit introduces the "useWowlService" hook. This hook allows
Owl components that use the legacy env (not the one of the
webclient for instance, typically called the "wowl" env) to access
services from the wowl env. Its API is the same as the classical
"useService" hook.
closesodoo/odoo#85769
Signed-off-by: Géry Debongnie <ged@odoo.com>
The signature of the _load_module_terms was changed at ac63556e23 to
pass explicit parameters instead of values hidden in the context
The previous code used working on a copy of the context when modifing
the 'overwrite' key. This was no longer the case after ac63556e23.
In case multiple languages are updated at the same time (as when a
module is updated), the 'overwrite' value is set to True after the
first loop.
To reproduce:
1. Create empty db with language English and without demo data
2. Activate languages fr_FR, fr_BE and fr_CH
3. Install module "note"
4. Now change in the fr.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante FR"
and in the fr_BE.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante BE"
5. Now update the module note without overwriting translations
(--i18n-overwrite option not set)
Observed behaviour:
The translations are overriden
opw-2760359
closesodoo/odoo#85768
X-original-commit: 37b98d413debabcd966718b2834d34f349e3cfbc
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Retroactive fix for an issue in 15.0+
In 15.0+, importing an invoice with an inactive currency will raise
a traceback. Before this it was handled by not setting the correct
currency on the invoice if not active.
With this change, we'll raise an error instead of creating an invoice
with the wrong currency.
closesodoo/odoo#85678
X-original-commit: 14c61c2563efeed1ca14294da32e2eb6d1855c5b
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
- enterprise: https://github.com/odoo/enterprise/pull/24914
Following new policies in terms of product design-language, this commit
will partially revert 546477d reducing the number of `oi` icons.
It will also improve rendering when icons are rendered at our default
font-size (13px), avoiding blur effects when icons use thin lines.
Since fontAwesome will coexists with `oi` longer than expected, the
commit will also review size utility-classes in order to get consistent
result when used in conjunction with fa's ones (notably `fa-lg`).
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#85651
Related: odoo/enterprise#24914
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit will adapt website's topmenu icons in order to be a
consistent with the backend.
It also solves a minor layout issue for '.o_menu_brand' that was
rendered incorrectly in enterprise.
Part-of: odoo/odoo#85651
Following new policies in terms of product design-language, this commit
will partially revert 546477d reducing the number of `oi` icons.
It will also improve rendering when icons are rendered at our default
font-size (13px), avoiding blur effects when icons use thin lines.
Since fontAwesome will coexists with `oi` longer than expected, the
commit will also review size utility-classes in order to get consistent
result when used in conjunction with fa's ones (notably `fa-lg`).
Part-of: odoo/odoo#85651
The accounting date and the related warnings were in some cases not
being set properly. This change aims to improve that by displaying
warnings in the view and updating the date on post instead of raising
user errors.
This will mostly affect sell documents.
Task id #2778958closesodoo/odoo#85744
X-original-commit: 51ddb870d346ff61a6ae36c8c3b545eaca9736cb
Signed-off-by: William André (wan) <wan@odoo.com>
As of now, the discount field is either only shown in
debug mode or if the sale module is installed and a
setting is set in sale.
This field should be shown in the view, and not depend
on a setting from another app.
This is especially true as it could be filled by the ocr
or when uploading from an edi, and it would be inconsistent
if the user couldn't display it.
Task id #2758965closesodoo/odoo#85737
X-original-commit: eb1a77753debdb034ad00ce10d908f4b9ee264ad
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
whith France localization, deleting a journal created by POS
leads to two errors.
first one is just a typing error.
second one is an infinite loop caused by calling super().unlink()
from methods marked with the api.ondelete
opw-2750852
closesodoo/odoo#85719
X-original-commit: 4961dd251211776a9661f27acda3c3e4dfedc50a
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
According to the spec, the PrezzoUnitario should be the unit price
without the taxes. If we use taxes included, this can be problematic.
That is because there is another rule that says that the PrezzoUnitario
* Quantita - Sconto should be within 0.01 precision of the PrezzoTotale.
So, with taxes included and a price unit only rounded to 2 decimals, you
easily go out of that limit.
The solution is to increase the precision on the price_unit (6 decimals
should not cause side effects and precise enough for most cases)
and to do the calculation differently by calculating it again from the
price_subtotal on the invoice line.
Task id: 2764978
closesodoo/odoo#85718
X-original-commit: 82f2794a2aee8492cbd36d8ab4d8a62c9665789d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
When users have same groups, implied_ids can be done in batches,
reducing write operations considerably.
Testing done:
800 users groups_id (all have same groups_id in the end) updated using
old code: took ~10s to complete.
With this improvement, it takes ~1.5s
closesodoo/odoo#85712
X-original-commit: 81994ea628cb492fef4e62c496d4ea1ab55d9a7e
Signed-off-by: Raphael Collet <rco@odoo.com>
If an installed module is only present in the dependency graph through a new,
uninstalled dependency, it was not be selected for upgrade when updating the
`base` module (c.q. `--update all`)
closesodoo/odoo#85704
X-original-commit: 6c80e7cfeafaaa4fb7c0d93cbe94c66068fc3170
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Since 4911a26d2c, `_check_barcode_uniqueness`
flush the default `_order` of `product.product` models (via many2one in the `_order`
of `product.packaging`). It creates a bottleneck (take > 10 minutes ) when we populate
(medium size) the `product.template` during `set_barcode_variant`.
Force the order to be trivial and simplify the domain with a 'in' instead of
multiple OR.
closesodoo/odoo#85687
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
1. Create a PO from Indian vendor [DEMO], confirm it, receive the products.
2. Go to Accounting app, manually create the vendor bill:
- select the Vendor [DEMO]
- in auto-complete field select the one created at 1.
Traceback will raise because the field l10n_in_company_country_code
was removed from account.move in
17610e8ca9
opw-2745052
closesodoo/odoo#85501
X-original-commit: ffbfdde4b5b4cd791e866341a31cdf5e8aeb27e3
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, if we have both customer and assigned partner names,
they are displayed in a single line separated by an arrow icon.
However, if we have long customer name, arrow icon and assigned
partner name are not visible on card.
This commit improves the display of names by making a few changes
- breaking the line before the arrow icon
- displaying both customer and assigned partner name with text overflow
- adding a tooltip on customer and partner names
- improving tooltip on the arrow icon
taskID-2763930
closesodoo/odoo#85264
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The field prefetching mechanism was poorly customizable. Before this,
we could only tell if a field was prefetched with other fields or not at
all. We have no way to inform the framework, like: "When I need data of
that field, prefetch these other fields, which are likely be used in the
same transaction".
From now on, the `prefetch` attribute is used as a grouping key for
prefetching fields. When a field is fetched, all the fields with the
same value for `prefetch` are taken for prefetching.
For example, consider a small set of fields that are rarely used, except
for one flow A using them. You want to prefetch those fields only in
the flow A, and you want to fetch them in a single query. With the new
feature, simply set `prefetch=A` for some string `A` on those fields,
and they will be grouped for prefetching.
closesodoo/odoo#85220
Signed-off-by: Rémy Voet <ryv@odoo.com>
Issue
-----
When website is installed, the rendering of template uses a side effect
of the ORM cache (cache shared between sudoed env vs non-sudoed env) and
the fields prefetching feature to work correctly.
The `self.visibility` in (`_handle_visibility`, website/ir_ui_view.py)
is done in sudo mode, then it will fetch all prefetchable fields and put
them in the cache (that will be read in non-sudo mode in the render of
the template). Another example of issue related to this:
https://github.com/odoo/odoo/pull/83341.
Because of this, the fields of mixin `website.seo.metadata` were forced
to be prefetchable (the default for translate is to be not prefetchable
since https://github.com/odoo/odoo/pull/82896), which causes a useless
LEFT JOIN on "ir_translation" in most of business flow.
Fix
---
Remove the `prefetch=True` on mixin fields, and add a extra read to fill
the cache in case of website rendering. It also allows to read these
fields at the same time.
Part-of: odoo/odoo#85220
When we read data of one record, the method `recompute` (`_fetch_field`
-> `_read` -> `flush` -> `recompute`) can take more than 40 % of the
time of the `_read`, due to a huge number of recordset creation (from
`records_to_compute` and `records & recs`). Avoid that waste of time by
postponing the test on records.
For example, on a database with modules crm, mrp, purchase, website,
sale_management, reading the prefetchable fields of the current company
took 1.45 ms ± 60.3 µs, and now takes 1.17 ms ± 110 µs (more than 20%
speedup).
closesodoo/odoo#83818
Related: odoo/enterprise#24645
Signed-off-by: Raphael Collet <rco@odoo.com>
Part-of: odoo/odoo#85220
Notifications have now a new look and SCSS has been cleaned up
accordingly. This commit is part of v16 overall restyle (task-2704984).
task#2719037
closesodoo/odoo#82524
Related: odoo/enterprise#23580
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Currently, we lint and auto-format non-legacy files in web. The tool
that we use for this linting and formatting unfortunately does not
propagate any linting errors except for parsing errors. This means that
it's possible to commit files of which we know in advance that they will
break CI. This commit simply relints the files in a standalone manner
after they've been formatted, so that if there is a linting error, the
commit will be aborted.
It is still possible to commit non-conforming code (eg to save work in
progress before switching branches) by committing with the --no-verify
git flag
closesodoo/odoo#85727
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before, it would give a traceback when we would have a product.supplier_info
with the same code and partner used for multiple products. This way, we
avoid this traceback.
opw-2703669
closesodoo/odoo#85725
X-original-commit: d7b35bb60d84eb587d82a3d9da24e39e8a42af9d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
With owl2, the `el` of components if no longer available. One must
use a t-ref instead. However, higher order components don't have
their own html element. This was the case of the View component.
However, it makes sense for this component to be the owner of the
view root element, which was previously owned by the Layout.
This commit refactors the View/Layout architecture s.t. the root
element is now owned by the View, and simplifies/generalizes the
Layout in the process. The Layout is no longer tied to the notion
of views, and can thus be used in client actions as well.
closesodoo/odoo#85639
Related: odoo/enterprise#24903
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Michael (mcm) <mcm@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
Part-of: odoo/odoo#85639
DateTimeString should have an attribute format="102" (date is of the form: AAAAMMJJ)
as specified in the factur-x documentation.
opw-2767359
closesodoo/odoo#85604
X-original-commit: c367ae0df23ce6a826cdb487b92d25dff3e78963
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
closesodoo/odoo#85631
Related: odoo/enterprise#24902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when we need to get all SOL linked to the project.
That is the SOL linked to the project and also the SOL linked to all
tasks of this project.
Technically, a fetch is made to get the SOL of the project, a fetch to
get all tasks of the project and then a fetch to get the SOL linked to
all tasks fetched, finally the union is made to avoid having duplicate
sale order items in the recordset
(`self.sale_line_id | self.tasks.sale_line_id`).
This way could be a performance issue if the project contained many
active tasks and so the project update could take more and more time to
compute the sold items shown in the right side panel of project update
view.
This commit does a query builder to fetch the SOLs linked to the project
and its active tasks to avoid doing the prefetchs.
part of task-2710808
closesodoo/odoo#85660
X-original-commit: 0734f4e
Related: odoo/enterprise#24918
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the translation is not done in lazy, so for each
stat button shown in the right side panel of the project update, a query
is done to find the correct translation based on the language of the
user. It means, the translation is costly and need to be done in lazy to
reduce the time for the translation of those stat buttons.
This commit uses the `_lt` to translate in lazy mode those stat
buttons. By doing that, the execution time is reduced from 750 ms to 250 ms.
X-original-commit: 95fe018
Part-of: odoo/odoo#85660
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
To generate an e-faktur
1. Settings > Users & Companies/Compagnies:
- Create a new company ‘ID Indonesia’:
- Set the state (e.g Yogyakarta (ID))
- Set the country ‘Indonesia’
Accounting:
2. > Customers > e-Faktur
- Set a range of numbers (which are supposed to be assigned by the
Indonesian government);
3. > Configuration > Settings
- Fiscal Localization: select the Indonesian package
4. > Customers > Customers
- Create a new res.partner:
- Set the country ‘Indonesia’
- Check ‘ID PKP’ field
- Under ‘Accounting tab’: set both accounting entries (Receivable +
Payable)
5. > Customers > Invoices
- Create a random invoice with the res.partner set in point 5. as the
Customer
- Confirm the invoice
- Action > Download e-Faktur
---
When validating the e-faktur users will see the error
Import Faktur Error ETAX-30005 : Error Objek Mapping
This occur because E-Faktur standard update from 3.0 to 3.1
A column 'KODE_DOKUMEN_PENDUKUNG' is now mandatory
opw-2753810
closesodoo/odoo#85696
X-original-commit: 3f0db73ef7c51c7365afbc7604ea66fa6765e6e7
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Currently, when someone adds a quiz on the slide content from front-end
and clicks on the 'Set Done' button, `werkzeug.exceptions.Forbidden`
error is raised which shows the full stack trace to the end user.
This commit improves the behavior by raising UserError instead and
thus displaying nice error instead of the full stack trace.
taskID-2380233
closesodoo/odoo#85694
X-original-commit: 5dfd5dd50fa8cd3f023ba7fa0c2fc4b52f9c5650
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Previously when going to a contract from the contract history, studio
was disabled, because it could not find a action xml id attached.
TaskId-
closesodoo/odoo#85690
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When using the odoo app,
`request.httprequest.user_agent.browser` is `False`,
instead of a string expected.
Therefore, `capitalize` cannot be called
```
2022-03-02 09:44:01,267 1321846 ERROR dle-test1 odoo.addons.saas_trial.models.res_users: 2fa by email failed
Traceback (most recent call last):
File "/home/odoo/src/custom/trial/saas_trial/models/res_users.py", line 267, in _send_totp_mail_code
return super()._send_totp_mail_code()
File "/home/odoo/src/odoo/saas-15.1/addons/auth_totp_mail_enforce/models/res_users.py", line 95, in _send_totp_mail_code
'browser': request.httprequest.user_agent.browser.capitalize(),
AttributeError: 'NoneType' object has no attribute 'capitalize'
```
closesodoo/odoo#85684
X-original-commit: 5a87db453fcfd750934d1a1d62c00d93ad01c0e1
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
To reproduce the issue:
1. Storable product with MTO and manufacture route
2. On your warehouse set 3 steps manufacture
3. Create and Confirm a SO for this product
Error: The smart button linking the Manufacturing order does not appear
on the MO.
Problem was introduced by [1] and fixed by [2,3]. Moreover, [1] wasn't
deployed on versions >14.0 so there was no need for [2] on these
versions ([3] has been merged on all versions). However, [1] have
recently been deployed on next versions ([4]) so we need to FW [2] too
without disturbing the improvements from [3].
[1] 7ab0ac3e56949e5015bb2dcfd2af34b56dee92c8
[2] 96b56ea350c283d824468c591d42e4aeeada0d69
[3] 475e6b3cb027b3127b8e46fd8c9f90abc35162d7
[4] 7d7976a61d0af41ebb4df2e24ba222f6570f689c
OPW-2778883
closesodoo/odoo#85676
X-original-commit: 8ce61133af600ffec4c43033e64c2460366856ce
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Grazioso Andrea (agr) <agr@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
ISSUE 01
When adding a product to a sale delivery, another picking is generated
to return the additional product
To reproduce the issue:
1. Create two consumable products P01 and P02
2. Create and confirm a SO with 1 x P01
3. Add 1 x P02 to the delivery and validate it
4. Go back to the SO
Error: Another picking has been generated, it's a return for P02. This
picking should not exist.
When validating the picking, because of the new line, a sale order line
is created with a quantity equal to 0. During the SOL creation,
`_action_launch_stock_rule` is called and checks if a procurement must
be created and processed. To do so, it checks if the SOL quantity (0 in
our case) is the same than the procurement quantity (1 in our case):
https://github.com/odoo/odoo/blob/6a0cbff92141961655a5f3e33abc23a2c5b1045d/addons/sale_stock/models/sale_order.py#L543-L549
Since the values are not the same, a procurement is created and
processed.
The feature that updates the SO when adding some products to the picking
has been introduced by 1f0835a9d01b46b5cc617756f854c25541b644a7 and is
correctly working in 14.0 because the condition (in
`_action_launch_stock_rule`) is not the same:
https://github.com/odoo/odoo/blob/ec5475ee881c5ca2bcc992592bfa4edf12f492df/addons/sale_stock/models/sale_order.py#L572-L574
In 14.0, we check if the SOL quantity is greater than the procurement
quantity. The condition has changed in 15.0 due to a new feature
(bda3225c6cc27bb2c2933eda3cc68c6f9708daf3).
ISSUE 02
When delivering more than sold, a useless SM is generated.
To reproduce the issue:
1. Create a consumable product P
2. Create and Confirm a SO with 3 x P
3. Deliver 5 x P
Error: A new line appears (Demand: 2, Done: 0)
Because the delivered quantity is more than expected, an extra move is
created. Then, the extra_move is merged into the initial one a condition
is respected:
https://github.com/odoo/odoo/blob/6f2ba1e1b40a458e23c8ed712927c44d75d86614/addons/stock/models/stock_move.py#L1603-L1610
Here is the issue: the field `date_dealine` is not copied anymore (see
[1]). Therefore, the condition will never be respected
[1] fb781dcf57
OPW-2716309
closesodoo/odoo#85649
X-original-commit: fabc32c4733bb404e74dc111d80aa1fe1edd4bfb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Brieuc-brd