We added a model to work easily with packages, using the quant packages
was not a good solution to move entire package and plan package moves,
because we always had to give the picking in context, and create some
move lines, so it was only possible when state was assigned (when move
lines exists)
So we created a model package level, linked to picking, move and move
lines allowing to easily plan package transfer and put in pack.
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
After commit 996a817071
The portal report on picking only check if
the user has a 'read' access on picking.
If he can read it, sudo is called and thus
record rule/access right on component objects
are not necessary.
This commit removes useless rights for portal users.
This removes the procurement.order model. To fufill their needs SO, PO, MO and
stock moves now call the _run method of the relevant procurement.group.
This mecanism is now only used for stockable product, tasks now uses their own
independent mecanism.
The _run method will check all the applicable rules and create directly the
needed model to fufill the need.
The modules stock, purchase, mrp, extends the _run method to implement their
specific strategy relevant for the rule type they define.
If an exception happens the message will be logged as a mail messsage on the
source model, for example, if a sales order cannot be fufilled the salesperson
will now see directly the reason.
OLD commit messages:
[WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
fixup! [WIP] procurement: removing procurement.order in stock, sale, purchase, sale_stock. WIP
[IMP] Basic tests
[FIX] test not necessary anymore
[FIX] remove unnecessary print statement
[FIX] unnecessary test + why passing warehouse worked before?
[IMP] purchase: one move by purchase order line
[FIX] purchase: correct inventory tests and pass move_dest_ids among procurements
[FIX] because of bad cherry-pick merge
[IMP] make mrp pass by adding move_dest_ids there too
[IMP] tests of sale_mrp, no need for cancelpropagation then
[IMP] better to consistently use recordsets also for one2many
[FIX] purchase_requisition
[FIX] Exceptions should trigger errors, which should be caught in the tests
[FIX] sale_mrp: remove usage of procurement.order and use sale order name instead of sol
[FIX] stock_dropshipping: add sale_line_id on purchase_line_id
[FIX] Remove pdb
[IMP] add stock_dropshipping files
[IMP] stock: search carrier through sale line instead of procurement group
[IMP] add procrule test and preision needed when updating sol
[FIX] sale_order_dates + [IMP] procurement exceptions by scheduler
[FIX] No need to return task
[IMP] move file as name changes and add corrections
[FIX] Continue Run Schedulers wizard fix
[FIX] name issues of takss
[FIX] updating sale order line, but there is still a problem with the recompute
The big change is that we have now a many2many between the move and a
one2many between a move and its pack.operation (note: this model is
renamed as stock.move.line in a further commit).
Due to these changes, `action_done` had to be rewritten intierely, as it
depended and stock.pack.operation.lot and stock.move.operation.link,
that are now removed. This method was laregly inspired by the one in the
mrp module, and a further commit will make MRP uses all the core of
stock.
Due to the previous commit that refactored the stock.quant
implementation, the new concept is that the `product_qty` that will
always be in the uom of the quant (`product_qty` is a computed field in
the same style as the one of stock.move).
This commit also implements the logic that a manager is able to edit
done stock.pack.operation.
The stock.move has now a "partially_available" state (it was previously
a flag). The "split_from" field is removed now that we have a many2many
between moves (a sibling move is always a move that was splitted, or
with the backorder_id field).
The done quantity of a stock move is computed across the done quantity
of the move lines. There is an inverse method that allows user to fill
the done quantity directly on a stock move.
The reserve quantity of stock move is computed accross the
`product_qty` of the linked pack operations.
`do_unreserve` will simply unlink the associated pack operation.
Unlinking a pack operation will unreserve.
`force_assign` will mark the move as available, in order to allow the
user to create pack operations (none are created because nothing was
reserved).
`action_assign` is rewritten and splitted in two parts: if the move has
a parent (mto) or not (mts). In the mto, we'll check the available move
lines and only reserve accordingly. In the mts, we'll reserve directly
on the quants.
`action_cancel` has changd a lot: in case of a delivery, the first step
does not anymore propagate cancellation to following moves and SO. As a
result it does not propagate in the other side in case of MTO or production.
It does not delete them if we delete the related sale order for example. In
order to correct this next activities will be added in the future. Technically
action cancel on move is based on procurment rule, this commit will set
the propagate field to false on the rule if the picking_type is 'pick'
or if we are in one step delivery.
We use this commit to reimplement `action_assign` (wiped by the new
quant implentation). A move is reserved if its move lines exist, so we
introduce a one2many between stock.move and stock.pack.operation (note:
a further commit renamed this model into stock.move.line)
We use this commit to implement `action_done` (wiped by the removal of the
models making the link between stock.move and stock.pack.operations). We
can use the one2many to the pack operations.
blabla manymany au lieu de one2many
blabla mto mts
Remove get_ancestors, as orig_ids will be used instead
validation
when we are creating some packe operation with lot name, the
pack_operation are unlink and a new picking is craeted.
This is caused the function _create_lot_for_picking that unlink pack
operation having no quantity reserved instead of ones having no quantity
done.
To fix this we changed product_qty to qty_done and move the code from
action_done of picking to action_done of move
fixup! [IMP] Merge_moves functionality + many2many procurement and original moves instead of one2many
fixup! [REF] stock: basics of new model and stock.move reservation
edit reserved move line
This is the 1st commit message:
[REM] stock: stock.pack.operation.lot, stock.move.operation.link
These models will become useless once a one2many will be made between
stock.move and stock.pack.operation.
The `action_done` method on stock move has been wiped, as it depended
completely on the removed models.
Joint work with Josse Colpaert <jco@odoo.com>, amoyaux <arm@odoo.com>
and Pierre Masereel <pim@odoo.com>
If only Inventory is installed,
only the admin could create new product attributes
for products variants. Other managers couldn't.
This revision adds the ACL according to what is done in other modules,
such as in `sale`.
Mostlikely, we should create a product manager group, for which
this rights are given, and make the other groups (sales manager, inventory manager)
inherit from this one.
opw-745735
Before this, the stock user had readonly ACL on the scraping action. He
therefore could not scrap products during his normal operations. It is assumed,
that this was not an intended default, as not being otherwise documented.
Closes#15955
The goal is to prepare the removal of
'portal' module.
Since this module only provides access rules and
rights, those ones are moved directly into its
parent module (aka 'stock').
Since no module depends on it, we can remove it
without problem.
As picking types aren't always used in a picking context, and picking
aren't really meanigful for a lot of people, we rename this concept as
"operation type" in views and in the planner.
PURPOSE
=======
A lot of customer are struggling with the fact that from the SO lines their users sometimes type too fast the product name and end up by creating or selling products that are simply mistakes.
Only the sale/manager, subscription/manager, purchase/manager, mrp/manager, warehouse manager, event/manager, pos/manager and invoicing person should have access rights to create and update products.
SPECIFICATION
=============
Remove create and write rights on product_product, product_template and product_price_history for stock users and move these rights to the subcited apps managers
Add a link in the general settings to access easily the default_user form view in order to modify the default access rights
The default_user manager rights declarations in all the applications have been move in a noupdate="1" definition to avoid the manual configuration overwrittings
This commit contains the core of the new MRP. It contains a whole refactoring
of the MRP application, with improved and new features, written in new API.
Among other here are the main manufacturing workflow improvements :
- Picking type not only for pickings but also for manufacturing orders
- Properties replaced by picking type
- BoM can only be produced with its routing (no other)
- Either produce without routing with only production orders, or produce with
routing
- By default, there is an order in the work orders (serially), but you can
override it to be able to work in parallel
- Time clocking on work orders and block time on work centers with reporting
on OEE, performance, losses, ...
- Real-time adaptation of timings on operations
- Lots/serial numbers can be inputted like in the pickings on manufacturing
orders. It is also possible to input them in the work orders.
- Material availability independent of production order state (possibility to
start production when only part of it is there)
- Work sheets on work orders
- Put messages on work orders to make your workers pay attention to something
- Full traceability link to see for each produced piece of stock, the
consumed pieces, ...
- Separate scrap object (a scrap is not done based on an original move
anymore)
- Separate unbuild system (if you want to unbuild into its original
components)
Thanks to all people that helped during this development, notably but not
limited to Chirag A Dodiya (cod@odoo.com), Gaurav Panchal (gan@odoo.com),
Jignesh Rathod (jir@odoo.com), Mansi Trivedi (mtr@odoo.com), Pariket Trivedi
(ptr@odoo.com).
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
[FIX] account: move some ir.model.access to sale module
[FIX] payment: Move some ir.rule to website_sale
[FIX] stock: move some ir.model.access rule to sale_stock
[FIX] project: Move some ir.model.access rules to crm_project_issue
[FIX] mrp: Move some ir.model.access rules to sale_mrp
[FIX] calendar: move some ir.model.access rules to crm
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
[ADD] sales_team: See own documents => See only his sales team
Moved the "User: Own Leads Only", "User: All Leads" and "Manager" groups from sale and crm
into sales_team module. Add the record rules so that user can see only his Own Sales Team
if "See Own Leads" is sales right and can see all sales teams if he is having sales rights
of "See All Leads" or manager.
This branch need more testing instead of doing 10 fixes. A lot of issues are occuring
when installing modules in different orders.
This reverts commit fa6e415cdb.
Purpose:
Having the res_group defined in base and sales_team auto installed
with mail doens't make sense.
- Move the empty res_config class and the related view from
base_setup to sales_team (base_setup only contains the 'General Settings'
model and views
- Move the 'sale' related content from product to sale module (Access rights,
menuitems,...)
- Set sales_team at autoinstall False. The module is installed when needed by
crm or sale for example
- Set sales_team as a dependency of voip. (Access rights defined for configuration
purpose)
- Set sales_team ad a dependency of subscription (Access rights issue too)
Rename xmlids accordingly. Example: 'base.group_sale_manager' becomes
sales_team.group_sale_manager.
- Separate group_stock_multiple_locations into 2 groups:
o group_stock_multi_locations
o group_stock_multi_warehouses
- Add a selection fields to manage the 3 levels of warehouses management complexity:
o Manage 1 WH with 1 location
o Manage 1 WH with multi locations
o Manage multi WHs with multi locations
- Display the menuitems and fields accordingly
- On a company creation : Create a related Warehouse
- stock.location : Add a helper on the parent location
- stock.warehouse : Add a helper on the company_id field
In "stock.move" model the fields location_id and location_dest_id
are required. But when disabling "Manage Multiple Locations and Warehouses"
in Technical Settings, these fields became hidden in stock.move.form and
then it was impossible to add an new product to consume in mrp.production.form.
In 8.0, to be in group_stock_user implies to be in stock.group_locations.
Introduced by e58b16a
opw:660032
`stock.move` & `stock.product` have multi-company rules.
There is therefore no reason why `stock.quant` could not have one.
Besides, this could lead to access rights issues,
when a user went to the `Quants` list,
in Warehouse > Traceability > Quants,
while there were quants for products in a company different
than the user company.
opw-653188
Coming from a bug in web_settings_dashboard. Invited user didn't have any rights
when created from the dashboard, which was leading to an error.
This bug leaded to a new discussion. Better to have basic employee having user
rights for all main applications. For bigger entreprises there is an admin that
will carefully remove extra rights, if necessary. The target is small businesses,
it makes sense that every way to create a user gives the same result.
In conclusion, each new user has a full access to the applications by default
How is it implemented ?
We added an inactive default user which original access right to the groups
'base.group_user' and 'base.group_partner_manager' in base. Each
application will extend the default user's access right by adding the maximal
access right for this application.
On user creation, we will use by default the 'group_id' field from the default
user. We will in the same time remove the ugly 'default_groups_ref' key which
was passed sometimes in the context for some fields in some views, and sometimes
nothing.
So, the user can modify the access rights for the default user, but he should be
aware that removing project user access rights for a default user will prevent
a *created on the fly in a task* user will not be able to access the task.
Stock user should be able to create products. Indeed when targetting small
businesses, restricting the right to create products limitates the use of
the inventory app. It is possible to further restrict access to the product
model using record rules for big companies that have a lot of users and
managers, and where creating product should be limited.
Instead of using 2 security groups to make sure
internal pickings are not shown in the dashboard
when not in multiple locations,
picking types are deactivated when the warehouse
is one step in/out and not in multiple locations.
That way it will work the same for other kanban views.
The colors of the kanban view are also changed.
When scanning multiple serial numbers e.g., the list of pack operations
can become quite long. In order to avoid that, we make it possible
for pack operations to contain multiple lots.
The implementation is done in the way that the links between moves
and pack operations remains the way it was. The important difference
is that on action_done, it will check all the reserved quants and their lots at
once first and only afterwards, it will check the lots one by one to check what
it can reserve.
As the details for the lots for the pack operation became a real object, the wizards related
to the pack operation details are not necessary anymore and were replaced
by a form view of the pack operation.
Pierre Masereel