SugarCRM Script Installer Upgrade Process Breaks Installs

Right now, at http://www.sugarforge.org/frs/?group_id=6, there appears to be no patch between 5.2 and 5.5. There is a patch from 5.2 to 5.51RC3. Most people wouldn't want to mass upgrade to an RC3.

I have done a series of upgrades using the SI, but now have this situation where I have 5.5 code, but a 5.2 (apparently), datatbase.

For most of these, I guess there were no database changes, so I was able to just edit the config table in the database with the new version information, and Sugar started working again.

There's a thread at http://www.sugarcrm.com/forums/showthread.php?t=56130 , which specifically mentions that this trick will not work when there are structural changes in the db.

That thread also says that the correct way to upgrade is to use the integrated upgrade facility in Sugar, which obviates some of the benefit of using the SI for management, in that the domain owner still needs to do something. But, unless there are security fixes, this may be for the best. Except, in this case, the desired 5.2 to 5.5 patch did not appear to be available on the download page.

Messy....It may be that Feature in the Script Installer which installs the new version fresh, but then imports the old data would work in some cases?

The 5.5.0 to 5.5.0a upgrade is a good example. I just hosed a working install by trying this through Virtualmin.

Undoubtedly, the correct way to do these upgrades is via the upgrade patch manager in the Admin interface.

However, this nullifies some of the benefit of mass manageability.

Jamie, maybe you can some how figure out what the difference is between the regular installers (inital, Full version), and the patches, and come up with a way to make it automatable.

It occurs to me that there is a useful feature addition to the SI functionality, something like "prohibited transitions", reminiscent of the "Can't install Joomla 1.5 over top of Joomla 1.0" prohibited transition, a status of "requires manual intervention", something like that.

Otherwise, it seems to me that the Sugar Patches always have something indicative in their name, maybe even "Patch", I don't recall. If there is a Patch file for a certain version pair, it becomes a "prohibited transition" until some automatable workaround can be found. Make sense?

I don't know, Jamie. The manual update process within the application is top-notch, seems to do a lot of checks, and I have done dozens of upgrades, and never had a failure.

However, remember that Sugar actually doesn't want to make it "too" easy to to mass upgrades, because they SELL a Data Center Edition to their Partners. I've been to SugarCon twice, and they were really pushing that feature at the 2009 event. Anyway, the Patch .zip must have some PHP script, or else there is an upgrader PHP script within Sugar which interacts with the contents of the .zip file.

There is a stage in the upgrade process where if there are SQL changes you can toggle to select "Installer upgrades SQL" or "Manually upgrade SQL", or similar words, so the SQL must be in the .zip

Another factor is that maybe we don't really want to do mass upgrades, because people may have added extensions to their Sugar, which could be broken by an upgrade, not likely, but possible.

See if you can easily decipher their upgrade process, otherwise, we may have to dig deeper.

I am not aware of any command line options for upgrades, because it seems to me that would compete with their Data Center product.

Or parse the upgrade file, and find the SQL and the files, and apply each...

I think that my couple of ideas are good...you basically recognize and inform that there is a new version available, but in this case, 5.5 to 5.5a, for example, is a PATCH, which means that it has to be applied manually.

There are also "Silent Upgrades", and when those are offered, those should work using your Script Installer, I bet...I have never used them.

It looks like the current Silent Upgrade covers a wide range of existing versions, and there is a line in the ReadMe which says "Upgrade from Sugar Instances : 5.2.0x and 5.5.0".

You can see the Silent Upgrade in the list format that you'll probably need to trap somehow at http://www.sugarforge.org/frs/?group_id=6.

If this is too complicated, I would suggest you mod the Script Installer to ask for an Admin contact, but only during interactive install. IOW, don't alert the Host, alert the Sugar Admin that a new version is available, and requires manual intervention.

Hope this helps. Ken

My best figuring is that:

If there is a Silent Upgrade for the transition in question (which I have pointed out, the allowed transitions are covered in the .txt file within the SilentUpgrade.zip)- THEN, you should run the silent upgrade (or offer to do so).

The above seems like the most general solution, and most amenable to automation.

If there is only an Upgrade, then those upgrades give the transitions which they cover as part of their filename. If there is no "SilentUpgrade" which covers the intended transition (current version-> latest), then just inform somehow of the availability. This is the case where you would inform the domain owner, not the Host, because the host presumably is not the SugarCRM administrator.

BTW, other things to note...5.5.1 just transitioned to GA from RC. You might offer RCs somehow. SugarCRM is a professional company with something like 40 developers, this is not a guy hacking in his bedroom after his real job, so the RCs are likely valuable.

Go ahead and try to implement this...I have a bunch of dead in the water 5.5 installations I could test against, or deploy new.

Very good Jamie.

It may be helpful to you to know that there is an About type link in the Sugar Admin which returns the version number, and you likely know where that number comes from, but AFAIK, it's both in the config(uration?).php and in the config table in the database.

Looking forward to moving this forward.

I think it's a good opp. to incrementally beef up the internals and capability of the Script Installer to handle more "Enterprise" scripts.

Thanks for caring about this.

Best, Ken

Interesting. I just checked, and it's in my config.php in the sugar root, and I know that the database version is in the config table in the database. That seems a little bit precarious to my untrained eye. I would think it ideal to have it defined only once, but I am no expert.

I was just trying to give you more options for checking the version number, because more options seems better. I would bet that these numbers update at different parts of the upgrade cycle, so it's likely that they are out of sync at least momentarily, during upgrades.

Hey,

It's probably no news, but I was in the middle of an upgrade, and thought I would grab a screenshot of the upgrade Wizard in action, with the "Wizard runs SQL" default selected.