SugarCRM administrators that have utilized the Module Builder tool are likely to have run into this scenario on more than one occasion....
A custom module is created and you proceed to click the Deploy button.
The deployment process initiates and appears to be working as expected, but suddenly, the following error message is displayed:
"An error has occured during deploy process, you package may not have installed correctly."
Does it seem familiar to you?
It happened to me for the first time some months back, ironically, not long after attending the yearly SugarCON event where I had attended an in-depth discussion on the mechanics of the Module Builder tool. This experience became important because it helped explained the error and eventually led me to the solution, which we will now discuss.
The condensed version of the explanation is that the deploy process creates a package similar to those used by the Module Loader tool (including a manifest.php file) and then the Module Builder tool triggers the code in SugarCRM which normally executes were one to install a package via the Module Loader tool. In turn, this code processes the package created by the Module Builder and the custom module is installed.
After giving this some thought, it dawned on me that the likely source of the error at hand was rooted in the Module Loader tool.
Upon inspecting Module Loader, its related database table (upgrade_history) and the contents of the <sugar_root>/cache/upload directory, a discrepancy became apparent.
In short, there were entries in the upgrade_history table -- and in turn, in the installed extensions section of the Module Loader screen -- which did not actually have their corresponding files in the <sugar_root>/cache/upload directory, as they should.
Under normal circumstances, all packages installed via the Module Loader end up in the <sugar_root>/cache/upload directory, as was explained in the discussion about the Module Builder mechanics.
Editing the upgrade_history table to remove the record pertaining to the Module Loader package with the missing files in cache/upload resolves the problem. Try re-deploying the custom module after making that change to the database and see if that corrects it.
Another potential solution relates to having entries of the custom module one is attempting to deploy already listed on the bottom pane of the Module Loader screen. Removing those entries via the Delete Package button prior to deploying the custom module will usually resolve the matter.