(10-09-2016, 09:03 AM)joebordes Wrote: A note of warning: stay away from "standard" field names. For example, accountid. When you create a new uitype10 field referencing a standard module like accounts, contacts or potentials, DO NOT use accountid, contactid nor potentialid. We have inherited a lot of hard code references to these fieldnames. I mean there are pieces of code that specifically look for that fieldname and do something different spefically designed for that module. That is a hard to find non-expected functionality in your custom module. I usually use, accid, ctoid or potid (for example).
So, it is okay to use this:
PHP Code:
var $list_fields = Array (
/* Format: Field Label => Array(tablename => columnname) */
// tablename should not have prefix 'vtiger_'
'Packing Slip Name'=> Array('packingslip' => 'packingslipname'),
'Assigned To' => Array('crmentity' => 'smownerid'),
'Delivered' => Array('packingslip' => 'deliver_date'),
'Related Sales Order' => Array('salesorder' => 'salesorderid'),
'Related Account' => Array('account' => 'accountid')
);
and here I mean the last two entries in the array, where I reference the standard vtiger_salesorder table and vtiger_account table, but I should not use:
PHP Code:
var $list_fields_name = Array(
/* Format: Field Label => fieldname */
'Packing Slip Name'=> 'packingslipname',
'Assigned To' => 'assigned_user_id',
'Delivered' => 'deliver_date',
'Related Sales Order' => 'salesorderid',
'Related Account' => 'accountid'
);
(10-09-2016, 09:28 AM)joebordes Wrote: If you specify the sequence you have to manually set the value and increment it accordingly. It does not increment automatically nor restart on a new block, it uses the number you give it.
So if I use sequencing, I should just use one continuïng sequence throughout the manifest file?
(10-09-2016, 09:42 AM)joebordes Wrote: coreBOS does not have a Master-Detail solution. Even less with the Inventory modules.
The way the Inventory modules are programmed, the "Detail" part is saved internally in a non-standard table. This complicates everything and it is not the way I would recommend you solve this.
Since all the logic in the product lines of the inventory module is hardcoded it is hard to modify and maintain, specially in a way that would permit extending easily. The way the guys at ITS4You solved it when creating IssueCards and ReceiveCards (the base of the two modules available on github) is to replicate all the code and templates in their module. It is a solution and works rather well for us because we have two more inventory modules (for a total of 6). That is really enough in many of our installs.
When we need to implement a new Master-Detail module what we are currently doing is creating two modules; one for the master information and the other for the details. Then you use the related list. If you need more we program it, using detail/edit view blocks
keep asking
I think I don't fully understand what you mean by "master-detail", but if you mean creating a PackingSlip module and relating products to it through a related list, then I think I will not implement it in this way. I will go for the ITS4YOU example and start out with their setup. I feel using a related list is blocking the workflow for something that I feel would be used quite often in a business. The number of steps to create packing slips should be minimal and as much as possible should be automated. But maybe I am missing your point.
Again, thanks a lot for all your answers. I'll get at it and come back here if I have any issue or questions.
I saw this in the "EditView.php" file:
PHP Code:
if ($disp_view == 'edit_view')
$smarty->assign("BLOCKS", getBlocks($currentModule, $disp_view, $mode, $focus->column_fields));
else {
$bas_block = getBlocks($currentModule, $disp_view, $mode, $focus->column_fields, 'BAS');
$adv_block = getBlocks($currentModule, $disp_view, $mode, $focus->column_fields, 'ADV');
$blocks['basicTab'] = $bas_block;
if (is_array($adv_block))
$blocks['moreTab'] = $adv_block;
$smarty->assign("BLOCKS", $blocks);
$smarty->assign("BLOCKS_COUNT", count($blocks));
}
Which stands for (I think) Basic and Advanced. Are these blocktypes still in use? Are these the blocks under "more information"?