I am trying to find “best practices” for managing new custom modules in SuiteCRM 7.1.5 (7.2 will have to wait)
So it seems that when you create a new custom Module in the Admin > Module Builder… you need to use that interface to add new fields and change layouts.
If you try to do this in Studio then you will lose any Studio changes if you eventually return to Module Builder and change anything there and re-Deploy.
I learned this the hard way.
One oddity is that if you create a Module that requires sub-panels (based on one-to-many relationship)… you can only do that through Studio and not through Module Builder even though the module was created there initially. Seems awkward…
Perhaps its better to use Module Builder to add the initial module info and then ongoing maintain it (make changes ) only in Studio after the initial creation.
Also … why do you have to create a Module group first before you create a new Module. I don’t see the added value to this. It would be cleaner to simply add modules as needed. Most of the time new modules will be related to standard modules so not sure what the grouping actually accomplishes. I am probably missing something obvious here.
You are correct in that if you redeploy a module you will loose studio customisations but that makes perfect sense since you are re-installing the module again from scratch.
I am sure you can create the relationships in module builder both one to many and many to one which achieves what you are asking.
You are also correct in that you create the initial module using module builder and then maintain it via studio but module builder is only a starting point. If you want to create anything more than basic functionality then you have to add custom code to your module. But module builder is the best starting point for any custom module.
The module grouping allows you to create multiple related modules in one installable package which can save a lot time when trying to write an installer for an extension that has many parts to it
There is also one more thing that you are missing: In studio its possible to export your customisations for any given module which would allow you to redeploy your module and then import your studio customisations again.
Create your module using Module Builder and save your package to a zip file;
Deploy your package in your installation;
Do any customizations you need through Studio and export those customizations to a zip file;
Open both zip files in your favorite text editor and try to “merge” files contents;
Create a new zip file consisting of Module Builder files + customization files + merges you did to Module files;
Uninstall your module deployed previously;
Re-deploy the new consolidated package and check to see if everything’s there.
As Andy said above, Module Builder is a starting point, it’s probably the best way to do it. But after you start to customize things, you’ll need to touch code yourself to achieve a better integrated solution.
I don’t really understand what your meaning here.
You can add relationships in module builder they don’t have to be added via studio. The only difference is that studio relationships can be deleted where as the relationships you create in module builder are non-editable unless you go into the code and delete them.
I created a module in Module Builder (ill call it “Groups”). I also created other new modules in the same Module package called “Project Requests” and
“General Requests”. While in Module Builder i added a one-to-many relationship between Groups and Project Requests and between Groups and General Requests. After deploying I went back into Module builder and under Group I would expect so see a option for Sub-Panels but they are not located there. To edit the Groups Sub-panels (for both Project REquests and General Requests) i need to do that in Studio only. You cannot change Sub-panels for custom modules inside Module Builder. That is my assumption.
Of course you cannot change the sub-panels in module builder once they have been deployed. Module builder is about building and deploying modules. Once they have been deployed you are correct you would use studio to edit them unless you want to make a fundamental change to the module and re-deploy it.
