PURPOSE
Questions asked to attendees are usually attendee specific according to
"statistics". It makes therefore sense to have a field activating the global
question mode that is False by default.
SPECIFICATIONS
Inverse behavior of boolean 'is_individual' and rename it to 'once_per_order'.
By default it is set to False, meaning all questions are individual.
LINKS
TaskID 2162438
Community PR odoo/odoo#44476
Upgrade PR odoo/upgrade#771
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Quentin Mourier <qmo@odoo.com>
Before this commit, in the "customize" menu on /event, custom views enabling
filters by "category, country" and the "show sidebar" were activated by
default. This commit deactivates them by default.
Reason behind this change is that most people don't have enough events to
justify having those filters on by default.
LINKS
TaskID 2162438
Community PR odoo/odoo#44476
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Quentin Mourier <qmo@odoo.com>
Create an invoice, validate it, sending the data to the SDI.
Now reset to draft the invoice and re-validate it.
Action will be blocked because "You can't regenerate an E-Invoice when
the first one is sent and there are no errors".
This add the possibility to modify the invoice without re-sending it as
long as the first one is still in a sent-with-no-answer state
opw-2196956
closesodoo/odoo#45580
X-original-commit: a315d7dde7ab4c1283c999c336284aeac86dbbbc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- install sales
- go into debug mode
- dev tools > start tour > sale_tour
Previous behavior:
tour would fail to see that the product has been selected
and time out if you do it multiple time
Current behavior:
the tour finishes properly (even if it runs multiple times)
opw-2187218
closesodoo/odoo#45461
X-original-commit: e7a78fd76e48fbaa895d786f699d22b2278c9301
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Create a new mass mailing, add a video via youtube embed link, save.
Send email.
Embedding a video can't work because it embeds an iframe, which is not
supported by most email clients for security reasons.
Extending the noVideo flag also to mass_mailing
opw-2179665
closesodoo/odoo#45104
X-original-commit: f9f8c9cc4075fdc5fd4556aa49c914054469198a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to reproduce:
- install accounting
- go to accounting > accounting > reconciliation (you need at least
one unpaid invoice and one unreconciled payment for the proper screen
to show)
- manual operations > click the cog icon > create model
- create a model with a long name and duplicate it 5-10 times
- go back to the reconciliation tool > manual operations
Previous behavior:
the model buttons leak out of the right of the screen
Current behavior:
An horizontal scrollbar appears if necessary
opw-2185355
closesodoo/odoo#45431
X-original-commit: e24d971ad8d1bfdef8fc55710d99fc29c29a9c31
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
During a forward port, a regression was introduced that broke the
multi-company invoicing flow in Sales.
Create a SO in company 1, use the web client with company 2 as the main
one. The invoice should be in company 1.
This commit fixes that by providing the journal_id in the invoice values
(the company of the account move comes from the journal).
While making this fix (and adding a test for it), I stumbled upon
another multi-company issue when fetching the accounts of the product
where the property field was not accessed with the correct company. I
fixed it as well.
closesodoo/odoo#45551
X-original-commit: 07dbc197007c78633decccef2200a628b7d4a363
Related: odoo/enterprise#8498
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
If the record with the external id 'auth_oauth.provider_google' does
not exist in the database, 'google_provider' variable will contains
None.
Before this commit, calling get and set methods produced an error.
After this commit, trying to set a token for Google Authentication
will do nothing.
While this is not ideal, one can assume somebody that deleted an OAuth
provider rarely wants to configure it and can still upgrade the module
to get it back.
closesodoo/odoo#45566
X-original-commit: eca90a31d0d3667cf63994d34c5d2bb81bfd45c4
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Set the following product configuration:
Storable finished product with a flexible BOM made of storable
components in manufacture + MTO:
Component choice 1 Quantity = 0
with BOM made of component 1, quantity 1 with purchase mto route
Component choice 2 Quantity = 0
with BOM made of component 2, quantity 1 with purchase mto route
Create a MO for finished product, set the "to consume" quantity of
"Component choice 1" to 1, and try to mark it as to do. The following
issue is raised: The quantity to produce must be positive!
This is because a procurement with 0 quantity will be solved in a MO
producing 0 quantity. We fix this issue by ignoring procurements with 0
quantities.
Also, this MO without initial demand is not considered assigned. We fix
this issue by considering 0 move as assigned.
task-2159374
closesodoo/odoo#45552
X-original-commit: dffb3a1f2762d6e1517eb9b7d225521f99d874d5
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In order to prevent `CacheMiss` errors.
Closes#45242closesodoo/odoo#45550
X-original-commit: 6b5c5124c34245ca93716131c6496d1d4dea72a2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
0. Create 2 Products A & B
1. Open Inventory > Configuration > Settings and flag the following
checkboxes:
Delivery Packages
Product Packagings
Storage Locations
Multi-Step Routes
2. Go to Inventory > Configuration > Warehouses and open YourCompany WH
3. Set 'Incoming shipments' to 'Receive goods in input and then stock
(2 steps)'
4. Go to Inventory > Configuration > Operations types.
5. For 'YourCompany: Delivery Orders' and 'YourCompany: Internal
Transfers”, flag the following checkboxes:
Show Detailed Operations
Move Entire Packages
6. Go to Inventory > Configuration > Locations and open 'WH/Stock'
7. Edit and create a new 'Put Away Strategy' called 'Stock'
8. Add a new rule:
Product A, with Location 'WH/Stock/Shelf 1'
Product B, with Location 'WH/Stock/Shelf 2'
9. Go to Inventory > Operations > Transfers to create a new picking.
10. Select 'YourCompany: Receipts' as 'Operation Type'
11. Under Operations, add a new line with product A and an 'Initial
demand' of 20
12. Save and 'Mark as to do'
13. Enter in edit mode and under 'Detailed Operations', set a quantity
of 11.0 on 'Done' and click on 'Put in Pack'
=> A new pack is created
14. Repeat 13 with a quantity of 9 to create a new pack
15. Save and click on 'Validate'
16. An existing 'Internal Transfers' with the two created Packages
having following properties:
From: 'WH/Input
To: 'WH/Stock/Shelf 1'
At this point, the behavior is expected.
17. Cancel the picking created
18. Create a new picking:
Operation type: 'YourCompany: Internal Transfers'
Source Location: 'WH/Input'
Destination location: 'WH/Stock'
19. Under Operations, add two new lines using the packages os step 16.
20. Save and 'Mark As To Do'. The two packages have the following
properties:
From: 'WH/Input
To: 'WH/Stock'
We can see a difference in behavior. The picking created from a 'Pull'
mechanism applies the putaway strategy to the package, while the picking
created from the 'Push' mechanism doesn't apply it.
We make the behavior consistent. Moreover, in case the package contains
products having different destination locations, the destination of the
picking is kept.
opw-2146583
task-2148494
closesodoo/odoo#45549
X-original-commit: 705bdaa4ae5251b05bc2bbba02f2ca561ca00bbc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
You might think that if the debit note is like the inverse
of a credit note, that it is just a regular invoice.
Well, it is, except that we had several localizations
adding a link with the original invoice for the debit note.
This way, we can share that many2one and add a wizard that is
similar as the one for the credit once and for all.
In order to keep things simple, we always create a
draft debit note. The only option we give, is to copy
the original invoice lines or not.
You can also create a debit note from a credit note,
in which case the type needs to change, but we don't
copy the lines in that case (for now).
opw-2181586
closesodoo/odoo#45542
X-original-commit: f1af011d0966fa6e436168879b7f18fabb955934
Signed-off-by: Josse Colpaert <jco@openerp.com>
Create a purchase order, confirm it and create the vendor bill. The
source document will be not filled.
Fixing the related variable and changing also the missing reference to
the partner
opw-2197272
closesodoo/odoo#45534
X-original-commit: 8498dbe10db87f718b9287f69188c627e36f98a3
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When making a payment for multiple vendor bills at once, it is possible that payments will be generated without any recipient bank account for payment methods normally requiring one. In such cases, the user needs to be able to correct the payments by cancelling them. It was not possible.
closesodoo/odoo#45082
X-original-commit: 9aec95dccef48a9ec89691f5721619ffc0e4da56
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
VAT, NIF in Spanish, is translated NIT in Spanish from Bolivia
Clean and translate the files with the correct translation.
opw-2197155
closesodoo/odoo#45533
X-original-commit: 641c14f08435b1df1d89184cc00855416bf40bc5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Not setting a value for paperformat_id on 'Company Document Layout'
will also make paperformat_id False on the company but it is required
in the settings.
Without this commit, you can get in the weird situation of being able
to set a value on the document layout but having an error in the
general settings as a required field is missing.
Apply the same logic as in the other views
closesodoo/odoo#45527
X-original-commit: e518063e48936a3f8f9f921950cdae209e67ab47
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Create an immediate transfer for a receipt, add a move, set a quantity
done and due to rev[0], an initial demand is set, then
_autoconfirm_picking is called and action_confirm of picking calls
_action_assign if the location source bypasses the reservation. Set
again an inferior qty_done, the initial demand is also updated due to
rev[0] and somehow the system tries to write on a now unlinked move
line.
fixes
- never reserve an immediate transfer
- never update the initial demand if the move is reserved to fix the
existing databases.
- adapt _compute_state so that immediate transfer moves considered
reserved so that they're always "ready"
- adapt the test that was working on an immediate transfer picking and
setting the initial demand while it's not possible through the
interface, the user can only set the done quantity.
[0] 8303b1aclosesodoo/odoo#45317
X-original-commit: 357e0a862744f1bc23a9643a1822d2ee4a2eb7a2
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- In debug mode, create a SO
- Confirm the SO
- Click on "Create invoice"
- In the wizard, click on the debug logo
- Set a User default value V for Downpayment amount
- Close the wizard
- Re-click on "Create invoice"
Bug:
The default value V was not suggested.
Fine tuning of c258b8a0427bd5aface891ed1f4420174f4afde4
opw:2184367
closesodoo/odoo#45512
X-original-commit: f95550d59ddeb8a77cb7b72592cc4aafb210aa25
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
=======
PURPOSE
=======
Avoid communication being lost on transfers due to the fact that nobody is following.
=============
SPECIFICATION
=============
When setting a delivery address, add the contact in question as a follower of the transfer.
When a user validates a transfer, he should be automatically added as a follower of this transfer.
===========
LINKS
===========
task 2172675
pr #44350closesodoo/odoo#45498
X-original-commit: d6a981039005080e4803cb9c75287dfa4ada712b
Related: odoo/enterprise#8483
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When creating a payment, we are expecting only one destination account.
However, when grouping payment by customer, it can happen that there are
more than one receivable or payable accounts, which can create
reconciliation issues afterward.
opw-2188632
opw-2166551
closesodoo/odoo#45396
X-original-commit: 779699297b9767438797ae3678eb9da1db0ce609
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
When requesting multiple tracked content at the same time with the same
visitor concurrent updates happen.
The best way I got to consistently reproduce the issue is to open 2
tracked pages with chrome command line:
google-chrome http://pcodoo:8069/contactushttp://pcodoo:8069/
The first tracked page will update the visitor and lock it.
When the second will try to create a track which has a FK referencing
the visitor PSQL will try to SELECT FOR KEY SHARE the visitor but it is
locked => Concurrent Update Error. Using FOR NO KEY UPDATE instead of
FOR UPDATE performs a weaker lock that will not block
SELECT FOR KEY SHARE. By doing that we garantee that we will not
Update/Delete the PK while we lock the record.
closesodoo/odoo#45491
Fixes: https://github.com/odoo/odoo/pull/38372
X-original-commit: 33d0f0bc6b4c84de61ad876311690f26476c32f9
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Open any product kanban view with missing images
A 404 status code is returned for missing images, while they are
replaced by a placeholder.
This can cause issues when configuring a specific 404 page in a reverse
proxy: the proxy will serve the custom page instead of the placeholder.
opw-2192663
opw-2192340
closesodoo/odoo#45157
X-original-commit: 2719c8a0e40f318787b4d7a46626de46a8fd33f0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Missing context key in case of reverse of a vendor bill
it was then adding the anglo-saxon move lines.
opw-2172562
closesodoo/odoo#45432
X-original-commit: 48809f0c1b848142441063371d762a435836b6ec
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Do not use an inactive mail server to send the requests.
opw-2197011
closesodoo/odoo#45375
X-original-commit: ecc4759c03534ccb37ebf9eea202abdf387adca9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
Having a char field referring to an Integer could lead
to unwanted behavior if not managed correctly.
closesodoo/odoo#45393
X-original-commit: d73a86fd682495c034dfde678442f37689ecb759
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, There was no Instrustion to Setup this feature like other Integrations.
Now we display message when we enable this feature for the First time from settings.
closesodoo/odoo#44439
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
The icon of the json popover become a warning icon
when there is a issue. Also, create a
field show_json_popover in mrp_production
to avoid using d-none to put in invisible the popover.
task-2178494
closesodoo/odoo#45420
X-original-commit: 270e8d34b2adec07e8ae3b8952514184d2a00b59
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In this commit, added a restriction on "json_popover" field so,
Alert should disappear when picking is done or cancelled state on
list, kanban and form views.
task-2178494
X-original-commit: 12ada1bfa3e85c636f5ea85af675dedad3e7e0e4
The recently added group "Show Full Accounting Features - Readonly" was
shown in the selection of groups of accounting, but the "Show Full
Accounting Feature" wasn't. It was inconsistent and allowed to see the
features too easily (not debug mode needed)
closesodoo/odoo#45419
X-original-commit: ed3adb320c6680bb213965c84b6b7fd5654c8121
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
We don't want a next activity for an invoice to be created for OdooBot
if he is the Salesperson. We also don't want a traceback if the
salesperson and the next activity user are not set.
closesodoo/odoo#45417
X-original-commit: 8bf1b72e2b2bdf026b8eff28a554301a598012be
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This information is necessary for tours going from the backend to
the frontend (or the other way around) to run properly:
Some tour steps may be flagged with 'community' or 'enterprise',
meaning they must only be executed in the corresponding edition.
The TourManager filters the steps according to the edition. When
a tour is executed (either in test mode, automatically, or in an
onboarding situation, manually), the index of the current step is
stored in the local storage. So, the list of filtered steps must
be the same in the backend and in the frontend, which couldn't be
guaranteed as the frontend didn't have the information (thus always
considered being in community).
Part of task 2180175
closesodoo/odoo#45398
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When you read a record with the document viewer on the right side
that you don't have write access to this record
and the message_main_attachment_id was not yet set on the record
the document viewer try to set a value for message_main_attachment_id
that raise an access error
Set the value is not important but the popup
Access error can be really annoying
closesodoo/odoo#45378
X-original-commit: 74c36e6bc59af241ea162f042015f637880f1911
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
2 lasts steps are:
- Click on go to checkout
- Ensure checkout total is correct
But the last condition was already true before landing to the checkout, thus
the last step would succeed while the page is transitionning to the checkout.
The following would happen every time:
- Click on go to checkout
- Last step succeed directly after the previous step click on Go to checkout
Then, the following would happen rarely:
- The tour is considered successful
- The checkout page is loaded
- Some GET requests are performed
- The tour is killed (cookies & local storage)
- Some other GET requests are crashing, such as:
`Error loading file http://127.0.0.1:8069/web/webclient/locale/en_US`
The fix simply wait for the checkout page to be loaded as it was supposed to at
first, before checking the last step.
Forward-port of https://github.com/odoo/enterprise/pull/8322
X-original-commit: https://github.com/odoo/enterprise/commit/67686b697c866a5e5ad141a85b3589f1f1598d73
(coupon was moved from enterprise to community in Odoo saas-12.3)
Closes#45097closesodoo/odoo#45395
X-original-commit: 6768d87969f30e40b2e13a32c15330832afb780e
Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>
Issue
- Remove ~/.odoorc
- Launch a server
- Try to dump the db in db manager
Ok
- Restart the server
- Retry
pg_dump not found
Cause
When the .odoorc file is not there,
the pg_path option is not present so
the normalize method set it to None
When the server is restarted, it re-checks
the options (which are strings) and in the
normalize method we check "if not pg_path"
but 'None' is truthy so it thinks this is
a real path.
Solution
Check if not pg_path or if pg_path string
is None
OPW-2189789
closesodoo/odoo#45369
X-original-commit: f080964694c01a79c52e05c0ceb42c18d4c77df5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since wizards shall not be unlinked by anyone, but as we want to get rid
of this specific one immediately to get rid of eventual credentials,
do it with elevated privileges.
Before this commit, the behavior was an authorization error when trying
to applying the payment method, in a fresh invoicing configuration.
closesodoo/odoo#45363
X-original-commit: c8ee9c73d4ac9989d05843a32abc535b20d761b4
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
We cannot assume reading the value of a monetary field has the
decimals specified by the currency in decimal_places.
Right after creating a record with a monetary field it may have a
different amount of decimals.
To reproduce this:
>>> tx = env['payment.transaction'].create({
'amount': 10.87,
'acquirer_id': env['payment.acquirer'].search([], limit=1).id,
'currency_id': env.ref('base.USD').id,
'reference': 'test'
})
>>> tx.id
130
>>> tx.amount
10.870000000000001
<Restart odoo>
>>> env['payment.transaction'].browse(130).amount
10.87
Authorize requires us to send a correctly rounded amount. The
following response is returned when sending 10.870000000000001:
{'messages': {'message': [{'code': 'E00027',
'text': 'The transaction was unsuccessful.'}],
'resultCode': 'Error'},
'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
'accountNumber': '',
'accountType': '',
'authCode': '',
'avsResultCode': 'P',
'cavvResultCode': '',
'cvvResultCode': '',
'errors': [{'errorCode': '5',
'errorText': 'A valid amount is '
'required.'}],
'refTransID': '',
'responseCode': '3',
'testRequest': '0',
'transHash': '',
'transHashSha2': '',
'transId': '0'}}
To work around the issue always round when we read amount.
Lower level solutions were considered in #45248 but for now we'll
stick with this higher level and lower risk patch.
opw-2188889
closesodoo/odoo#45362
X-original-commit: 7485927f0eb152086efcaaf4a30260e503267c41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Stock introduces the option 'product' for the field `type` of the
`product.template` model.
If there exists records for this model with the aforementioned option
selected when the stock module is uninstalled, the records will remain
in the database for an indefinite amount of time, all while pointing to
an option that does no longer exist (except if the record was created by
the stock module itself), making the registry inconsistent and
eventually leading to a crash.
This is a known limitation of the ORM regarding Selection fields and
more specifically the `selection_add` mechanism, no "generic" solution
has been chosen thus far because it is not always clear which approach
should be taken:
1) Delete the record?
2) Set the option to a fallback, base option?
3) Something else handled by the module itself?
...
In this case the second approach has been chosen and whenever the module
stock is uninstalled, all remaining product.template records of `type`
'product' will be reset to the default option defined by the field,
which as of this commit is 'consu'.
See opw#2193814
closesodoo/odoo#45341
X-original-commit: a84b2829c5fac9e2b0d8cb49a4e7aa73f7e0e2b2
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
We recently transitioned to async option methods, this allows us to have
better control on the order of execution in the edition workflow, and
among other things, keep the editor's UI in sync with the current state
of the DOM.
However, some snippet options (such as the number of columns option)
need to remove or clone portions of the DOM, and as such, trigger the
onClone or onRemove methods of the snippets contained in that portion if
applicable. Because these methods are defined on other options, we first
need to make sure all the snippetEditors for this portion are created,
which is asynchronous.
This commit adds support for an onSuccess callback to the
'clone_snippet' and 'remove_snippet' event handlers, such that options
can choose to be notified when the work has been done, allowing them to
wait for it before proceeding.
This commit also adapts the layout_column snippet option to make use of
that new feature, and remove code that was used as a workaround before,
ie: precomputing the expected number of columns after the clone/remove,
and using that number to adjust the width of the columns and update the
UI. We can now just wait for the clone/remove, and use the real number
of columns currently in the DOM.
closesodoo/odoo#45343
X-original-commit: c159d58ce9cfca4a44f159b18eb10d1138977e23
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
- install accounting
- go to the accounting main view and hover some of the graphs
Previous behavior:
rounding was inconsistent and would lead to weird js floats
like 65.00000000000001
Current behavior:
floats are rounded to 2 digits after
opw-2172686
closesodoo/odoo#45336
X-original-commit: c00f4962eb790787fffef99595ac14dbef026055
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since 94a3919, the report_location_barcode.scss asset is never loaded.
The report_stock_rule has the same template id than the report_location_barcode
one. This later is so always overridden.
This commit delete the barcode location css as it was not really usefull
closesodoo/odoo#45340
X-original-commit: 9b610d066d25007561ac469f7caf5919c0aa4092
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
The many2one_reference is not a field that makes sense with the
form builder.
part of: https://github.com/odoo/odoo/pull/45280
task-2196797
closesodoo/odoo#45339
X-original-commit: 3e61ca5008e19c36aacedf57836dbd4369607e45
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The original existing fields could be altered once retrieved from the
database. Now we make a copy once we use them to prevent any alteration.
part of: https://github.com/odoo/odoo/pull/45280
task-2196797
X-original-commit: 2951c288ff839ccdf1740cac84dece96823eed8f
UniqueId was not set correctly on multipleInputs
part of: https://github.com/odoo/odoo/pull/45280
task-2196797
X-original-commit: 387b8d698ffd599693fe9feaa9be87e19e3549ab
When some existing taxes are defined with amount_type = "code",
the module uninstallation will leave the current data inconsistent.
Add an uninstall hook archiving the given taxes, logging the problematic records ids.
Fixes#45240closesodoo/odoo#45338
X-original-commit: 16e000b5dcc93a3c90a7d1b6d9d9a6097d5a9849
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
`action_explode` unlinks the kit move and create the stock moves for the components.
As the `create_multi` is not used, it results in lots of delays. Use the `create_multi`.
closesodoo/odoo#45326
X-original-commit: 4818ee61b4f23ab7b388acd2bdd452c27e25fc0d
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
`action_explode` is called when confirming the moves of a picking. It
calls unlink() when the move contains a kit. As this method is not
multi, when confirming 50 kit moves, unlink is called 50 times resulting in
a lot of cache invalidation, prefetching and so on.
We make `action_explode` multi in order to call one time `unlink` per
kit levels.
X-original-commit: 096c682e748f7e581e48f0070ec8a3284d8a2fe7
The purpose is to force developers to explicitly manage the removal of
field via migration scripts.
closesodoo/odoo#45269
Related: odoo/upgrade#777
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
