followup of rev [0]
If these wizards are called on multiple pickings, display the list of
the pickings that could be impacted and allow to select which one should
be impacted.
We also adapt the sanity checks at the start of `button_validte` in
order to specify the concerned pickings if needed. We do not enable the
multi behavior for batch at the moment, so it's only enabled for the
validate multi in the list view.
[0] 6ab4b0d496
task-2069646
closesodoo/odoo#41497
X-original-commit: ff276c6484b138982f185ec9c832f2dbf25baaef
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- we would have to set this domain on every actions directing to
products
-we can't set a proper depends_context since the new orm doesn't support
it
closesodoo/odoo#41322
Related: odoo/enterprise#7033
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This context key was used to get the valued quantities. We now have a
`quantity_svl` computed field that does this job. The test is removed,
it was showing that intercompany quants are visible thanks to a context
key but with the introduction of the on_hand filter, it is now useless
(just remove the filter)
Instead of hardcoding a domain in the action, we add a field that will
be used to apply the domain. The goal is to be able to define a static
domain in the xml so we'll be able to default on the filter while still
being able to remove it.
Let's consider this usecase:
Physical
| \
WH Subcontracting
| |
Stock 5 units
|
10 units
With the hardcoded domain, we have two problems
- the right part of the tree isn't visible
- the user can add a quant in subcontracting but it will disappear at
the creation since it isn't part of the hardcoded domain.
The complicated part of the domain is the `_get_domain_locations` call.
It will use multiple context keys, the current company and get the
hierarchy of internal locations below warehouses to see what it should
include or not.
To be able to remove a domain, it should be declared in the xml and not
hardcoded in the action. Since the domain is complex, we can't express
it. So we add a computed field "on_hand" and its search method is
overiden to call `_get_domain_locations`.
task-2061825
closesodoo/odoo#40403
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
On a quotation, the forecast report is opened with a default filter on
the warehouse of the quotation. If you remove this filter, quantities
not below warehouses (eg in subcontracting or in a repair location) are
displayed. From the product form, it's not the case, you never see these
quantities. We now add a "warehouse is set" filter that is enabled by
default (so you have the same value in the stat button forecast and in
opening the report) but you can remove it to see all quantities.
task-2061825
- the oderpoint_id field on the purchase order line wasn't used to not
merge the po lines
- if the orderpoint_id field is set, use the orderpoint location to
create the move
- if multiple stock moves with different source locations go through
`_merge_moves`, they should obviously NOT be merged
- `virtual_available` computed field was not being invalidated when the
context keys "warehouse" and "location" changed
task-2001462
closesodoo/odoo#40573
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Changing a product type from consumable to storable and and vice versa can
make the quantity in stock confusing. As only storable product update the
stock quants, the amount on stock moves could be diffenrent that the one
on stock quant if the product type has been changed in the past.
This commit will make those changes saved in the chatter history in order
to easily track inconsistencies
closesodoo/odoo#40997
Opw: 2125124
X-original-commit: 7c330b4443043dede13f76c034e2a2c5e53cbdee
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In case of a picking type where stock move lines are not shown, clicking
on 'Put in Pack' without 'Done' quantitites set shows a confusing error
message.
closesodoo/odoo#40928
X-original-commit: 76b72ab5953c1fc72e3c06464fd1c65e6420a4b3
Related: odoo/enterprise#6906
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate product packing
- Create a PO for a stockable product, validate
- In the barcode interface, go to the created picking
- Set the product quantity
- Click on 'Put in Pack'
An error is raised: 'All the products currently reserved in the picking
are already in a pack...'
In the regular interface, the procedure is to create the move lines
manually, therefore setting a quantity done. However, this is not
possible in the barcode, and `move_line_nosuggest_ids` is always empty.
We introduce a special use case to bypass this in the case of the
barcode view.
opw-2127637
X-original-commit: d3a7b0e1b1dffd73b9ff31f1ec9fa4f6bbf478d2
Those cases are already checked in models._check_company() but not considered
when defining the default domain on `check_company=True` fields.
* Consider res_users relational field
Companies allowed for user = user.company_ids
* Consider company-dependent fields
Companies allowed = self.env.company
closesodoo/odoo#40906
X-original-commit: a8de9509823c213dad2f5e8ff44ceb670f81ea70
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current activity types master data cannot be unlinked through a quite harsh
override of unlink using xml id existence, introduced at 2602642a78.
Some of them are real master data, other could be unlinked if users want it.
Finally custom activity types may cause errors when removed if used in some
side models like server actions or automated actions.
To allow more flexibility we remove the removal constraint and implement
a fallback mechanism. It is implemented in mail.activity.mixin when calling
activity_schedule(xmlid, ...). If the given xmlid is not found
_default_activity_type() specifies the default activity to use. It can
be overridden in modules if some specific behavior is wanted.
e.g.
def _default_activity_type(self):
"""Define a default fallback activity type when xml id not found
only used in in activity_schedule() for now.
"""
try:
return self.env.ref('mail.mail_activity_data_todo')
except Exception:
return False
In this commit we also
* restrict deletion of activity type (hr.plan and ir.actions.server);
* fallback on default activity type if xmlid ref not found in
activity_schedule;
* correct calls to activity_schedule and replace some manual creation calls
by activity_schedule;
Task ID 1961156
PR #39013
Related: odoo/enterprise#6238
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Before this commit, the field `next_serial_count` in stock.move, used to
know how many SN the user wants to generate, wasn't correctly set and
was always equals to 0.
closesodoo/odoo#40714
X-original-commit: 9a20896eddb6b98b569f4f83192ac876696baaa6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit, when user creates a receipt for a product tracked by
serial number, using immediate transfer, the fields to generate and
assign SN was hidden.
The reason was the move is confirmed in this case, and those fields was
displayed only for partially available and assigned moves.
task-2123761
X-original-commit: 4f9b170e857509cf34e072051086a7e9590c330d
In this commit,
-Modify the message shown when we try to delete a done picking.
-In transfers, in detailed operations, set default hide on on
"Reserved" and "Lot/Serial Number".
task-id : 2124115
closesodoo/odoo#40309
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In this commit,
- Prevent the product type 'Services' to be selectable from detailed
operations of a picking.
- Change the place of 'product_uom_id' field on the internal transfers.
closesodoo/odoo#40551
Task-id: 2124093
X-original-commit: 9209e7f2b842161eb1704cebc02675a0b5248750
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Steps to reproduce the bug:
- Install Inventory, Sales
- In General Settings/Inventory/Traceability tick "Lots & Serial Numbers"
- Create a stockable product A (e.g. duplicate Apple E-COM08) tracked by lots
- Update Qty on Hand: put the quantity inside a lot
- Change Demo User's settings: remove Inventory access
- Connect as Demo, create a quotation with A, try to confirm sale
Bug:
An access error was raised.
opw:2092809
closesodoo/odoo#40499
X-original-commit: 1da97d4b842444dd69a54692de0d6edfc20d1123
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
If a warehouse is created without code (eg. when created as a new group
from a kanban view grouped by warehouse) we would get a traceback
instead of an error:
```
The operation cannot be completed:
- Create/update: a mandatory field is not set.
- Delete: another model requires the record being deleted. If possible, archive it instead.
Model: Warehouse (stock.warehouse), Field: Short Name (code)
```
opw-2124162
fix#40233closes#40267closesodoo/odoo#40382
X-original-commit: b6caa179e17199b29a9ca4009c53acb378423926
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Issue: create an immediate transfer, add a move and a done quantity, the
picking is in waiting state instead of ready.
Due to rev[0], the moves added in an immediate transfer have an initial
demand. After auto-confirming them, their state were 'confirmed' and not
'assigned'.
Solution: we force the state to assigned
[0] 8303b1a69eclosesodoo/odoo#39492
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this patch, move added in a planned transfer once it is ready are
directly marked as assigned and the reservation is disabled on them.
People found it hard to understand why the check availability button did
not appear, plus the push rules were not applied.
Now we chose to use the autoconfirm mechanism on the added move and we
don't reserve them, so the check availability button reappear.
task-2081844
_action_done() creates extra stock move when quantity_done is superior
to initial demand. This extra move should be, after confirmation, either
merge into the original stock_move, either stay extra but the move lines
still linked to the first one should be shared accordingly to the quantity
done. The fix 561b3461a0 adapted the code
for MRP to split the move lines but neither those cases are applied in
MRP because the extra move has no picking_id field.
condition :
```if merge_into_self and extra_move.picking_id:```
will therefore be false as well as
```if not merge_into_self:```
To be sure the two extra move management cases are complementary, this
Commit keeps make sure the conditions are mutualy exclusive.
closesodoo/odoo#40230
Opw: 2087864
X-original-commit: 4e8ac38a6d67bcd5040af0b580bfa43da7841548
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Install stock and sale. Create a sale with 2+ products, save and
confirm.
Look for the created picking.
There will be no source doument, because of
cb618e9a99
the behavior has changed when there are multiple source
document, possibly to avoid displaying the wrong source if they
differ.
Adding the possibility to display multiple source documents, eventually
truncating the list
opw-2117886
closesodoo/odoo#40098
X-original-commit: baad02d01b86a8d036524b789f046a54a878a729
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Business cases should not prevent the unlink of module-related records
during an uninstall.
This commit allows the reinstallation of sale_stock with demo data and
also allows the proper removal of tables and records if a db has any
non-draft inventory adjustments.
closesodoo/odoo#39776
X-original-commit: cedafe00941b869d284cd511633d7da15868fc0a
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Usecase to reproduce:
- Set warehouse as 3 steps delivery
- On pack rule set the procure method as 'take from stock if enough or
trigger another rule'
- Do an inventory adjustement of a product and set 10 units in pack zone
- Do a delivery order for this product with only 1 unit.
It will create the delivery order from stock to pack even if the
quantity in pack was sufficient.
It's due to [1] that introduce a new function but if the force company
and location (with an integer) are both set in the domain it will
select the wrong ids. It will take all the location in the company + the
location in the context. However if a location is explicitly given to
the context, it should only consider the stock at this location.
[1] commit 330b99f60c
opw-2090384
closesodoo/odoo#39726
X-original-commit: e77d9fc735d845bbb0b5562c359fbf2354d72f0e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- Create a POS user for which the corresponding partner has no email
address.
- Connect to the POS with the created user
- Sell a product which creates a picking (e.g. Customizable Desk)
The picking is created in draft and not validated.
This is due to:
https://github.com/odoo/odoo/blob/6435b27c35faeafca452d26fa7fd50a7fe964029/addons/mail/models/mail_thread.py#L2199
We disable tracking and post the message as `sudo()`.
opw-2091808
closesodoo/odoo#39490
X-original-commit: 972b4bad55e76500847a525459865b81d6ad2ee0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On a delivery type picking, adds a button to able the partner to sign
the delivery on receipt.
task-1878607
closesodoo/odoo#39183
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: sle-odoo <sle@odoo.com>
So we have to adapt
- the sanity checks
- the immediate/backorder wizards
- split the call to _action_done with and without backorder
This is a preliminary work to remove all the override in
stock_picking_batch and to allow choosing the pickings to immediate or
backorder directly in the wizards.
Before this commit, both wizards were calling _action_done and one
another. We make them go back through `button_validate` so that it is
more sane to handle and allow future extensions to add pre-action done
wizards.
Also the first part of button_validate is some sanity check. We adapt
them to be multi (inside of a loop over self) without any other
changes.
Now the wizard can work on the records (immediate: write the done
quantities) or work with the context (backorder: picking ids to not
backorder in the context).
Also we adapt the stock sms weird wizard (a confirmation wizard but the
feature is auto installed? wth). Now there it isn't manually called in
the middle of button_validate but it uses the pre_action_done_hook.
task-2069646
`action_done`on pickings should be a private method,
and called only trough the picking validation process.
task-1938108
closesodoo/odoo#39174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The default `compute_sudo=True` makes sense for recomputing stored
fields that are indirectly related to a business operation. This
ensures that the recomputation of the field does not break an operation
that is not aware of the fields to recompute.
However, computing non-stored fields in superuser mode is usually not
necessary. It even leads to unexpected values: counting a partner's
sales orders does not give the same result in superuser mode as in
normal mode. That is why non-stored fields are not computed in
superuser mode by default.
[FIX] account, delivery, event, hr_recruitment, point_of_sale, stock:
adapt the model definition to make all fields with the same compute
method have the same value for `compute_sudo`.
[FIX] sale: split the computation of `invoice_ids`, `invoice_count`
(non-stored) and `invoice_status` (stored), as no code is actually
shared.
closesodoo/odoo#39195
X-original-commit: 843fd38a97f02b49dc09d7f55919072d272fd80e
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
As this wizard only shows the first product overprocessed and does nothing else,
we remove it completely for cleaning purposes.
task-1938108
closesodoo/odoo#39161
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
All transit locations were set as active by default, confusing some users.
There are now set as active only when when a ressuply route is created
between some warehouses
TaskID: 1873106
Immediate transfers only fill the quantity done of stock moves/stock move lines
Those transfer are thus not taken into account for the forecast computation if they
are not validated. Indeed, the stock quant are not yet updated and the initial demand
is left blank.
This commit duplicate the quantity done of immediate transfer on their initial demand
this quantity is still hidden in the view but can now enter in the forecast quantity.
closesodoo/odoo#38169
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Go to Inventory > Configuration > Warehouse Management > Routes >
Make To Order
- Edit
- Swap two rules with the handles
- Save
An access error is raised.
This is due to the recomputation of `route_sequence` which is performed
on all companies.
Setting it as `compute_sudo` solves the problem.
opw-2072159
closesodoo/odoo#38104
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Usecase:
- Create a route without company
- Create a push rule for company B from intercompany to stock
- Apply the push rule on product and set in on a product.
- Connect with a user in company A
- Create a move from stock(company A) to intercompany.
- Confirm the move
-> The receipt for company B is not created.
Multiple issues:
- The rule is not found because it belong to the other company and is
filtered by the record rules. -> Aplly the seach as sudo if the move
is going to a location without company.
- Record rule error because a move from intercompany to company B is
created with a user from company A that has no access to company A.
-> Search and read company values and create the move as super user.
Based on work from Simon Lejeune <sle@odoo.com>
closesodoo/odoo#38124
X-original-commit: a80262e8b97256cac4bc5c406bc74a05f7189a00
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Some companies may have several locations with usage == 'inventory' and they would like to choose each time which adjustment location to use.
closesodoo/odoo#37022
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This reverts commit 3431d7b1cd.
Due to recent changes in the orm, editing a draft move crashes. We
revert this commit while we find a proper fix.
closesodoo/odoo#37752
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Sets `date_done` and `state` fields as readonly in the model as they
must not be editable in the list view and they were already readonly
in form view.
Task #2078163
Makes the picking view list multi-editable, and some readonly conditions
was moved form the view to in the model (for the `backorder_id`, `name`,
`scheduled_date` fields).
Task #2078163
Simon Lejeune