Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
If a stock picking wave is created from move lines. It may happen no
picking type is set on the wave. If an entire stock move or an entire
picking represented by the move lines 'to wave'. a picking type is
correctly set.
This commit ensure a picking type is set directly from the move lines
closesodoo/odoo#103348
X-original-commit: 86a1f2219904a19166155555da873b1772efa620
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Hides the empty label the same way as the group-by field if it doesn't
need to be shown (no default_location_dest_id/default_location_src_id).
Part of task-2985735
closesodoo/odoo#102759
X-original-commit: 6030147e12b628e8759700058b8ac3c3889007a8
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When selecting the "Add to batch" wizard, if a user selected "Add to an
existing batch transfer", the only batches appearing there would be only
draft batches, while it could be added to in_progress batches as well.
It also displayed waves transfers with the batches, so it now only shows
batches.
Also restricted the creation of a batch in the related field since there
is an explicit option to create a new batch transfer.
Somewhat the same for the "Add to wave" wizard as it would display
cancelled waves as well.
Part of task-2985735
closesodoo/odoo#102715
X-original-commit: a8db2c5fe4b2ea1f28c6ea788ac1976678da11aa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
When a backorder was created and the auto_batch was activated for this
picking_type, no batch was assigned to the created backorder, even if it
matched the auto-batch criterias.
Now when a picking is done, we check if backorders were created. If they
are eligible for auto-batchs (given their picking_type, etc.), they also
get the auto_batch done for them.
We can't simply use the previous picking's batch, because if this batch
is now done, then introducing a non-done picking into the batch would
raise an inconsistency between the pickings' states and raise an error.
Removes the old override of backorder confirmation as now batch
dissociation is done in the picking's 'action_done()' override.
Allows the validation of a batch that has pickings 'waiting for another
operation', as they now will get removed from the batch in the process,
no longer blocking the batch's validation.
Finally, makes that pickings that had no quantities done when validating
a batch aren't cancelled when selecting 'No backorder' in the
confirmation wizard, but are instead removed from the batch.
Task-2971346
X-original-commit: 1720840b7bd9b3e3e90f7cf860f60f1d0746ce63
Part-of: odoo/odoo#102382
the choose line widget is never used and can be safely removed.
closesodoo/odoo#101484
X-original-commit: 96462cec054d05955839a4a24d1c6aa9a3c7d7e2
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Currently cannot see assigned user working on picking/batch in kanban view.
Added user_id in picking kanban view, and related user_id
from batch
TaskId: 2871679
ENT PR: odoo/enterprise#28886closesodoo/odoo#101026
X-original-commit: 943e5b9761b43257ec968c12f15723c618c3b5ad
Related: odoo/enterprise#31740
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
Note this includes the view shown when clicking on:
- "History" button in inventory adjustments
- "Product Moves" button in scrap/product forms
- "Reporting" > "Moves History"
At time of this commit being written. Other move line views not changed
since they are specific to inputting data rather than readonly data.
Minor UX updates to stock move lines report:
- rename "Units of Measure" column to "Unit"
- add color to quantity field (green = incoming qty into stock, red =
outgoing, black = all others [i.e. internal transfers/external
locations only, etc]
- search filter order updated + src/dest location filters replaced with
generic filter that checks if either meets condition
- add src/dest package to list view
- add status, lot, and from/to dest to kanban view and replace picking
with reference so inventory adjustments are visible as well
- order by date desc so most recent ones are first
- always display location src/dest to help understanding of moves
Specific to "History" button in Inventory Adjustments / Reporting >
Locations (i.e. inventory report), moved product_id from domain to
default_search for more user analysis flexibility/ease.
"product moves" part of b2b task: 2882539
Part-of: odoo/odoo#97109
- reorder/rename/remove menu contents for "Inventory" and "Reporting",
including:
- removed "Forecasted Inventory" menuitem since this view is no longer
considered useful (code for view to be removed in separate commit)
- removed "Stock Moves" (moves report) menuitem
- renamed "Product Move" (move lines report) menuitem => "Moves
History", this will also be reflected in any "History" buttons that
open this view from other views.
- made "Inventory Report" menuitem visible only when applicable (i.e.
multi-location or consignment is active/debug mpde)
- made "Run Scheduler" menuitem only available in debug mode (
main_flow_tour updated to skip scheduler click since general flow is
expected to still the same/work)
Goal of renaming/ordering of menuitems is to clean them up and make them
more intuitive for users.
- "Run Scheduler" in mrp menus has also been made debug only viewable as
well to mirror the inventory change.
"menu" part of b2b task: 2882539
ENT PR: odoo/enterprise#29974
Part-of: odoo/odoo#97109
Purpose
=======
Confirm batch when `Draft` checkbox is unchecked.
So in this commit, we have added one `Draft` checkbox in the batch wizard.
While creating a new batch, if this `Draft` checkbox is checked then batch will be
create in draft state and if it's not then the batch will be create in confirm state.
TaskID - 2925593
closesodoo/odoo#97084
Signed-off-by: Tiffany Chang <tic@odoo.com>
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When adding list of transfers to batch from transfer tree view,
if transfers belong to two or more batches an error traceback pops.
To reproduce:
1-Create Transfer 1, go to Transfer list view and add it to batch under Action, choose
add to a new batch transfer and confirm.
2-Create Transfer 2 and do the same.
3-Now that we have two transfer belonging to two different batches,
Under Inventory->Operations->Transfers, select the two transfers
in the tree view and choose add to batch under Action, choose add to new batch
and confirm, error popsup
Bug originated from: #89815
Discovered while working on TaskId:2871679
closesodoo/odoo#97998
X-original-commit: 82580b0ba9dbbfb244ede233a251b059e2c233ba
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Ahmed Khalaf <ahkh@odoo.com>
This commit removes a needless `ensure_one` in batch `action_cancel`
X-original-commit: cf6013fff67441f67800df56349877c820873110
Part-of: odoo/odoo#97998
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
As done with the "done" state, if a single picking in a batch is
cancelled while the other pickings aren't, this picking is removed from
the batch, as it would create inconsistencies between the states of the
pickings in a single batch.
closesodoo/odoo#90449
X-original-commit: 1f2813e59970cd2eb078b514cd7d563837f175a1
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce the bug:
- Create a batch transfer with several pickings
- Confirm it
- Delete all the pickings > save
Problem:
The batch does not cancel as it should’ve been
A batch without transfers cannot be confirmed, so it makes no sense to leave a confirmed batch without transfers
opw-2792471
closesodoo/odoo#90104
X-original-commit: dcbf08edbb3a1ec49e84f0828b8f49ac4f836c25
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Current behavior:
All batch transfers are shown in the tree view. But only the one for the allowed companies should be in the list
Steps to reproduce:
- Be in a multicompany environnement
- Activate batch picking
- Go in Inventory/Batch transfers
opw-2752617
closesodoo/odoo#86531
X-original-commit: 8415b48cae06124911f08fe6c01b029ed80e6286
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Steps to reproduce the bug:
- Create a batch transfer with moves from the same warehouse to several locations, e.g:
- Product A from `WH/stock` → `customer/stock1`
- Product B from `WH/stock` → `customer/stock2`
- Try to print the batch transfers
Problem:
Traceback is triggered because we do a loop only on location_from
Solution:
- We need to loop over location_from and location destination
- Remove useless use of mapped
opw-2768518
closesodoo/odoo#86082
X-original-commit: 6721d1dfe53fb8d301188f2fb4c21baa70c27b92
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
If a picking is in a batch, the point is to process it as a whole. Yet,
it is possible to validate a single picking (putting it in a 'done'
state), inside of an 'in_progress' batch. This raises inconsistencies
between the state of the batch as a whole and the state of some of it
pickings.
Therefore, when a single batched picking is validated in a batch that
still contains other non-done pickings, the picking is removed from the
batch.
closesodoo/odoo#85324
X-original-commit: e9602d6b28331f68a83b5ce8a06a2ffc8ac3453d
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Usecase to reproduce:
- Product A 0 unit in stock
- Product B 10 unit in stock
- Create planned delivery with product A and B
- Do a wave transfer and selected reserved `stock.move.line` from
product B
Current behavior:
The whole picking is move into the batch
Desired behavior:
The picking is splitted and only the move for product B is in a new
batch
It happens because the add_to_wave function check if all the picking
`stock.move.line` are in the `stock.move.line` to batch. If it's the
case, it moves the picking in the new batch. However in our case,
some `stock.move` are not reserve and should not be move in the new
batch. Also check if all the quantity is reserve on the `stock.move`
if it's not the case split the move to only put the reserve quantity
in the wave picking
closesodoo/odoo#85038
X-original-commit: afe2a3a7f913459d88ef197e63bc897fda5f90f8
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usecase to reproduce:
- Create an immediate transfer and enable detailed opeations on the
picking type
- Create 2 `stock.move.line` with qty_done = 5
- Add the picking to a new wave and select only one of the sml
Traceback
It happens because the move split is base on the reserved quantity.
However in the case of an immediate transfer, the reserved quantity is
zero and the split fail
X-original-commit: 709372b0160a93cb9c30d391c4b3fc6c07ea2f9a
Part-of: odoo/odoo#85038
Usecase to reproduce:
Create a transfer with 3 moves for 3 products:
A - qty 60 (2 move lines, each move line has a quantity of 30)
B - qty 40 (2 move lines, each move line has a quantity of 20)
C - qty 40 (2 move lines, each move line has a quantity of 20)
Create a new wave picking containing the first move lines of each product (3 move lines)
Traceback
The error is due since it take all the `stock.move.line` from the
picking instead of the `stock.move` that is browsed
Fix#83450
X-original-commit: 788d08bb64204a0cb1c696f89228f6b4ae8d9620
Part-of: odoo/odoo#85038
Usecase to reproduce:
- Create a batch picking from a new location to customer
- Put some `stock.move.line` in a wave
- Validate the remaining of the initial `stock.picking`
- Create a new `stock.move` with the same data and without `picking_id`
Current behavior
The stock.move is added to the existing wave. However the
stock.move.line created could not match the current wave specification
Expected behavior
A new picking is created and it could be merge in the wave picking if
wanted
closesodoo/odoo#84875
X-original-commit: 4ea418ed1cceff4aee916cf791011a1dc67c77a1
Signed-off-by: Arnold Moyaux <arm@odoo.com>
While the batch is currently visible on the tree view, there was no
current link to a picking's batch while in the form view.
Task-2670580
closesodoo/odoo#81533
Related: odoo/upgrade#3205
Related: odoo/enterprise#23484
Signed-off-by: Arnold Moyaux <arm@odoo.com>
When adding a selection of pickings from the list, select the 'create a
new batch' over 'add to existing batch' as it better reflects user's
usual flow.
Task-2670580
Part-of: odoo/odoo#81533
Allow confirmed pickings to be automatically put into batches that match the
group criterias defined in their picking_type.
The pickings can be grouped by :
- Contact
- Destination Country
- Source location
- Destination location
To avoid having batches too big then, some restrictions can be put over
the auto-batcher to restrict the size of a batch :
- Max moves per batch
- Max pickings per batch
Task-2670580
Part-of: odoo/odoo#81533
Before this commit we could print the product labels of a picking from a
picking, but we couldn't print only the lots/sns. This commit adds in
this ability. Because we want to be flexible with this label printing
(i.e. have the option to choose between printing zpl or pdf + 1 per
unit or per lot/sn), we include it in the general "Print Labels" button
with additional wizards.
Note that we assume:
1. If there are no lot_ids in the picking => default to only product
labels wizard (i.e. this also means if a picking that only creates
New Lots/SN, lots/sns will not be printable until picking is
validated.)
2. Lots/SN PDF labels will only be in the 4x12 label format
3. Batch pickings can also print lot/sn labels
Part of task: 2494740
Related ENT PR: odoo/enterprise#23323closesodoo/odoo#82389
Related: odoo/upgrade#3202
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Steps to reproduce the bug:
- Create two batches, one with picking and one without
- Try to compute their state together with an RPC call
Problem:
If the first has no picking, the second batch does not compute state because we use `”return”` instead of `”continue”`
opw-2725988
closesodoo/odoo#82671
X-original-commit: 0242fcee2618425bd87846d818cffcd368c25121
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
This commit rename product_uom_qty into reserved_uom_qty and product_qty
into reserved_qty on stock move line to stop mistake them with the stock
move quantities fields.
Task: 2648449
Part-of: odoo/odoo#80434
Add a "clear qty" button to revert the change by "set qty" button in
(batch) picking.
On the move, Whenever the qty_done != reserved, we consider it a
manual change from the user. "set/clear qty" buttons won't change the
line with manual change.
Show "set qty" button when there are moves with 0 qty_done and non-zero
reserved. Show "clear qty" button when we don't show "set qty" button
and there are moves with qty done == reserved but the number is not 0.
Task-2659233
closesodoo/odoo#78737
Signed-off-by: Steve Van Essche <svs@odoo.com>
Currently, the order of transfer lines makes no sense for a picker
(it's in the order of the creation of the line). We want to have the
lines of the detailed operation in the same order as the picker will be
picking the products, so we order by source location, destination
location, sequence, and then by id (i.e. creation time) respectively
instead.
Also the printing report of the batch transfer is on too many pages,
it's one page by location, but we always group on 'from location'.
So it would be better not to split by location and keep the report
on the least number of pages possible.
task-2496324
odoo/enterprise#21921closesodoo/odoo#79446
X-original-commit: 9b120caa2a5cd5e2487d663a180b486b5bdb201b
Related: odoo/enterprise#22144
Signed-off-by: Tiffany Chang <tic@odoo.com>
Simplify user workflow by not showing the "Allocation" button in the
(batch) picking form view if there is nothing to allocate (i.e. when
reception report is enabled).
Also:
- fix the location search condition for the outgoing moves that can
be allocated to (i.e. the same logic used in show_allocation field
compute logic is also used in reception report generation/auto-opening)
- replace ['stock.location'].search() with ._search() for better
performance.
Part of Task: 2632884
ENT PR (for barcode equivalent): odoo/enterprise#20805
X-original-commit: 11ffb85fe7398854e4aefa4f9d0cfbc3b88aad8a
Part-of: odoo/odoo#79408
FrancoisGe