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.
- Rename some labels
- Add menu tips for picking type views
- Set Operations menuitem in group_no_one
- The options under configuration should not be in technical features
- Reorganized the configuration menuitems
- Hide the internal transfers in the picking type views if the option Use multi location and warehouse is disabled
Conflicts:
addons/stock/product_view.xml
Pack operations will not appear in a transfer wizard or bar code interface anymore, but
in the picking form itself. Some wizards are still needed however to ask whether a
backorder needs to be created and whether we need to do an immediate transfer
The biggest change in the model is in the picking where the locations of the picking
are not a related anymore, but need to be set. That is why the tests need to be changed.
This allows also to have pickings without moves initially and just move one pack e.g.
Locations won't be visible on stock moves in a picking either. (as they should be those of the picking)
In order to avoid confusion, the pack operations are created immediately when stock is reserved and we
are not waiting until the wizard or the bar code interface is launched anymore.
The recompute button previously in the barcode interface will only appear when the reservation changed
and the user indicated in the pack operations that something was moved already. Otherwise it will
recompute the pack operations. That way the reservation on the stock moves, is reflected by the pack operations.
Return pickings are not confirmed automatically when confirming the return wizard.
That should make it possible to choose another location for the return. (Don't return in output e.g.)
Barcode scanning is not in this commit.
Only admin was able to create product.putaway records. Gives all access
to warehouse manager.
If a putaway strategy was present on a location, a warehouse user was not able
to transfer goods as he had no access to the rule lines (no read to
stock.fixed.putaway.strat). Give read access. opw 619774
Yannick Tivisse