10-13-2016, 07:33 AM
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...