Different way of handling inventorylines in template

[Guido1982]

I'd like to suggest a different way of handling inventorylines in the Smarty template (did not post this in the PackingSlip thread because I think it should be more generic):

In "Smarty/templates/Inventory" we have "InventoryEditView.tpl" and "InventoryCreateView.tpl" (and I think also detailview) we have this line:

PHP Code:

{if $MODULE eq 'PurchaseOrder' || $MODULE eq 'SalesOrder' || $MODULE eq 'Quotes' || $MODULE eq 'Invoice'} 


That limits the use of inventorylines to only these modules, but why? First of all, this is a special Inventory template, why would it even ask if it should show inventorylines? That's its job, right? And if we still want to impose an 'if' statement here, why not make it more general. Make every module that has inventory capabilities set a smarty variable called 'HAS_INVENTORY' (or something like that) in its EditView.php file and then use that in the 'if' statement. Right now, when creating the packingslip module I'm struggling because the only way to create packingslips using the system templates is to include my modulename in the file, which I don't want to do (shouldn't change core files for module development).

So, I'd be happy to create a PR for this if there are no objections.

[joebordes]

I really don't want to modify that code much, just the basic functionality and enhancements.

I would prefer to discuss a generic way of doing Master-Detail modules.
The inventory modules are a mess, there is a lot of javascript code scattered around in different places, the detail view has a bunch of HTML hard coded, the inventory lines themselves are not modules, ....

I think we should define a way of creating dependent module relations. So that we can indicate somehow that one module is the master of some others, which fields you want to use to tie them together and which fields you want to see when viewing and editing the master. Also which types of aggregations you need to have calculated. Note that this is the better part of the maser-detail mapping.

I would stay away from the stock inventory modules and create a new, more modern and flexible way of doing this.

This is on our roadmap, but at a very far distance....

[Guido1982]

Quote:The inventory modules are a mess, there is a lot of javascript code scattered around in different places, the detail view has a bunch of HTML hard coded, the inventory lines themselves are not modules, ....

Yes, they are.

Quote:I think we should define a way of creating dependent module relations. So that we can indicate somehow that one module is the master of some others

I'm starting to grasp your idea of master-detail. You'd like every abstract entity in the app to actually have a module and record/entry/entity, which I believe is the right way to look at it. I'm thinking we could add a column to the "vtiger_tabs" table that would be (something like) "is_child_of", where the tab ID's of "parent" modules could live (multiple CSV). Then in the main PHP file of a module, like we define related list fields and search list fields now, we could define the behaviour of the module records when viewed in the detailview of their "master". When generating the "Blocks" in detailview we could generate blocks that represent entries from child-modules after the master-module's blocks, but before the "related" blocks. This way the priority order would be "this module - child module entries - related module entries".

Child module blocks should have extended functionality like editing fields through AJAX, removing records, and/or removing the record's relation to this master, ordering/sequencing for this master.

This is just my brainstorm when trying to follow your adventure...