[Vtigercrm-developers] upgrade to 7.2
Alan Lord
alanslists at gmail.com
Wed Nov 13 08:54:20 GMT 2019
On 12/11/2019 17:02, Rubén A. Estrada Orozco wrote:
> Hi Uma,
>
> Thanks for your quick reply.
>
> My question is regarding why, when upgrading from 7.1 to 7.2, the 7.0.1
> -> 7.1.0 database changes are taking place.
>
> The migration did fail, but that's something unrelated (I think). It
> failed in the 701_to_710.php schema script in the following section:
>
> image.png
> It failed in the case of custom two modules "AutomatedBackup"
> (VTExperts) and "ITS4YouReports" (ITS4YOU). What I did is I added both
> to the $restrictedModules array (as you can see above) and that way the
> script could complete.
Just as an aside, this bit of code was really broken a little while ago.
It made the assumption that all cf tables were simply the same name as
the basetable + "cf" at the end which was completely wrong. Fortunately
my contribution was accepted and made it into 7.2.0.
https://code.vtiger.com/vtiger/vtigercrm/issues/1094
Your issue about having to add module names to the restrictedModules
array is one I have also suffered from.
What I have done in my own migration scripts (I have modified all of
them, fixed loads of bugs, and run them from the command line) is to
only retrieve Entity Modules (not all modules) and then do a test for
the module's class file before proceeding:
> $moduleModels = Vtiger_Module_Model::getEntityModules();
> $badModuleNames = array('Dashboard', 'Home', 'Rss', 'Portal', 'Webmails', 'Import');
> foreach ($moduleModels as $moduleModel) {
> $moduleName = $moduleModel->getName();
> if(in_array($moduleName, $badModuleNames)) {
> continue;
> if(!class_exists($moduleName)) {
> continue;
> }
> }
then the script processes the $moduleModel as before...
Maybe this is better?
But unfortunately I can't answer your question as to why 701_to-710.php
should be run when migrating from 7.1.0 to 7.2.0...
Alan
More information about the vtigercrm-developers
mailing list