Template arch can contrains "groups" attributes on the html tag but can't have group_id setted. (to allow a cache per template and lang instead of a cache per template, user and lang)
In master , some places the string "Lot" is used and at some places
"Serial Numbers" is used , which is very confusing for the user.
Make a common string "Lots / Serial Numbers" everywhere for the uniformity.
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.
When doing an internal trasnfer, you can choose any destination
location in the header, but not on the line
This is problematic when doing a pick-pack-ship transfer. For the pick
move, you may want to change the source destination location (maybe another
warehouse why not) but as the transfer is already validated you cannot
modify it on the form. But with the Operation Details (Pencil button) you
can modify the source/destination location. The only problem is that a domain
is forcing the user to choose a source destination that is a child of the source
destination on the transfer, which makes impossible to choose a destination on
another warehouse. This tool is pretty much advanced, so we don't need to be so
restrictive.
In odoo at many places the filter items are having repeated strings eventhough the
fiter works differently , so find all the places where this happens and give
proper string to each filter..
Purpose:
When we create a return transfer, the return location should be selected as
the default destination location of the "Picking type for return". Odoo should
be using that return location as the default return location during reverse transfer,
but only if the default destination location of the "Picking type for return" is a
return location
Specification:
For all transfers, if the default destination location of the "Picking type for return"
is a return location, then the return location should be selected as the default
destination location during reverse transfer.
1/ In Return form Change the string 'To Refund in SO' to 'To Refund'.
2/ Return form wizard: Reduce the space in header.
3/ Change the button string name 'Reverse' into 'Return'.
Remove no_one group on the Picking waves menu entry.
Add a search on the picking waves in the transfer lists.
Remove the 'Print all Picking' button and add primary button which is 'PRINT' button.
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.
PURPOSE:
The source document should be in the chatter and clickable
NEW MAIL TEMPLATE:
mail: new template 'message_origin_link' with clickable link to origin
Variables to pass:
- origin: the record from which the current record had been created
- self: The current record
Optional:
- edit: If true, the record has been modified. Otherwise it has been created
from the origin
SPECIFICATION:
Source Document is available in following models
1) After creating SO then Sale to Invoice -> Source Document (After creating Sales Order and then clicking on Create invoice)
2) When procurement is created after SO or MO or Order Point(procurement.order) - > Source Document
3) Stock.picking -> Source Document ( After Creating SO or PO)
4) When Manufacturing Order is Created (mrp.production) -> Source Document (Coming after creating a sale order of product)
5) Event -> Attendees(event.registration) -> Source Document
6) Request For Quotation -> Source Document (After creating Purchase Tender, SO)
7) In Purchase Tender(purchase.requisition) -> Source Document (When a new Purchase Tender is Created)
8) After creating PO then create invoice(vendor bill)-> Source Document
9) After creating Invoice from contract (subscription) - > source Document.
10) Refund invoice from Invoice --> Source Document.
11) Return picking from picking --> Source Document.
12) sale use POS to create invoice and picking --> Source Document.
MESSAGES TO DISPLAY:
-In Customer Invoice, there is a source document of Sale Order.
"This Invoice has been created from Sale Order(s): SO001, SO002"
-In Procurement, the source document can be either of Sale Order or Manufacturing Order or Order Point.
"This procurement is created from: SO001 or MO0001 or OP/0001"
-In Stock Picking, the source document can be either of Sale Order or Purchase Order.
"This transfer has been created from sales order(s): SO001 or PO0001"
-Create new Sales order of manufactured product , there will be Source Document with that Sale Order number
"This production has been created from procurement(s): WH: Stock -> CustomersMTO"
-When registering for Event from website, Sale Order is Created and it is stored in Source Document,
"The attendee has been created from Sale order: SO001"
-In RFQ, the source document can be either Purchase Tender or Sale Order or Order Point,
"This purchase order has been created from purchase requisition(s): TE0001 or SO001 or OP/0001"
-In Purchase Tender, the source document can be either of Sale Order/ Manufacturing Order/ Order Point.
"This Purchase Requisition has been created from: WH: Stock -> CustomersMTO"
-In Vendor bill, there is a source document of Purchase Order.
"This Vendor bill has been created from Purchase Order(s): PO0001, PO002"
-When creating refund of invoice
"This customer invoices refund has been created from customer invoices: INV/2016/0001"
-when create invoice and picking form pos.
"This invoce has been create from point of sale: MainXX"
onchange_picking_type func now return picking_type_code
The stock.picking has an attrs to hide the partner_id for internal transfers.
It was not set as picking_type_code was not set.
Closes#12117
Hide the group in the stock_picking_type form view if in configuration setting:
- Packages: Record packages used on packing is false
- Lots: Track lots or serial numbers is false
This sentence was turned in a way that was making the user reluctant to click on
Apply while this is a normal flow to follow most of the time.
Closes#11763
When creating a new stock.quant.package, the method tried to access a key
that does not exist in an intermediate dict. Indeed a new record does not
have an ID available in self.ids.