Iāve looked at SuiteCRM in the past, but noticed ver 8 was almost ready for release, so left it alone until the new ver was out and had a few updates. With 8.0.4 I think we should be good to goā¦
Iām looking at the default modules and seeing the need for a number of extra fields and some additional modules for things I specifically want to implement. From the potential issue of future upgrades breaking things if Iāve added or changed stuff in one of the default modules, whatās the general community feel on either editing the default modules, running updates and it just works, vs cloning and starting from scratch with the cloned modules, therefore (potentially) offsetting issues when the default modules get updates as time goes?
And yes, I realise that by editing the default modules, when updates are made to correct issues, they will be applied, however if I have cloned and used now-customized modules, none of these updates will be applied to my cloned modules.
Aha, good article. Yes, I decided that with the accounts and Contacts modules (in particular) being such core parts of everything, I should just modify them as needed and run with them. Thatās pretty much what your article says.
As an aside, in SuiteCRM 8.0.x when you link an existing Contact with an additional Account, that Contact is āreplicatedā in the Contacts but with an Account link to the new Account. (Not really replicated - the Contact appears multiple times, each time associated with a different Account, but the Contact is actually the same Contact - delete one and you delete all (yep, this is on test data).). I can handle that, and the users will just need to be aware that if they delete one of these contacts from Contacts, not just the Relationship from the āContacts Subpanel for an Accountā they will be doing some overtime correcting that issue.
@pqr
I donāt think that itās a bug and contacts have always been displayed multiple times when linked to multiple accounts (all versions of SuiteCRM and even in SugarCRM 6.x)
Thatsās due to the list displaying the account name.
Considering the SQL query necessary to get the contacts list, there is just no way to avoid that.
The problem I do now see is that on a test system, after customising the core Accounts and Contacts modules with some extra fields and an additional relationship and some view changes, thereās no straightforward way to have this backed up and imported into another SuiteCRM instance.
Sure, I can Export the customizations, import them using Module Loader, then perform a Quick Repair and Rebuild and the layouts are there, but this does nothing with the new database fields (ie, thereās no database backup) so the views are partially incomplete and all the fields still need to be added on the target instance.
So it seems that if you modify core modules and wish to have these customizations used on another SuiteCRM instance, youāre basically SOL as far as creating a replicable set of customizations - youād need to use Module Builder and create a whole new set of modules from scratch.
You can move the custom directory from one place to the other, this usually takes care of everything. Sometimes there are additional pieces under modules, you have to hand-pick from there any custom modules you created (I think these are only the ones created in Module builder).
Inside the custom dir, there are vardefs files that describe changes to data structures. In the Quick Repair and Rebuild, these are compared to the actual database and anything that needs changes will be proposed as an SQL query that you can execute.
So, moving the files + QR&R + Execute SQL should get you where you need to be.
