When you work with Module Builder and Studio, usually things go well. The only thing to remember is that once you start using Studio to amend things, you can’t go back to Module Builder. If you do you loose the Studio amendments, and that is really how it should work.

My problem today came from exporting customization from a development instance of Sugar and loading it into the production instance. I’ve done this many times, as a means of migrating custom fields, layouts and code (logic hooks). This time it didn’t work, and I’m not sure why. Certainly the manifest file of the exported module looked a mess, so it it is not surprising that it caused all sort or problems.

I’m not going to bore you with going through all the steps I had to take, but I would like to document the few general rules that I found applied. These need more testing out, so don’t depend on them 100%. If I have any wrong, or missed anything, please let me know.

1.    If custom fields don’t appear in the fields_meta_data table in the database, nothing else will solve your problems.

2. When you edit any vardef type fields, always do a Quick Repair afterwards. There is no need to clear cache or log off or anything else.

3. Sometimes you need to go into Studio, and save an deploy each of DetailView, EditView etc, to correct some type of problems.

I’ll add some more notes here from time to time, but I would be interested if you have any further suggestions or ideas.

I had the need to take an existing module that had been built earlier with Module Builder, but needed some fields added. In fact there were a large number to add, so much in fact that I didn’t fancy entering them one by one in Module Builder.

As all were very similar fields I thought I should be able to edit files within the module directly. As it turned out this was quite possible.

The steps I went through were as follows.

1. Obtain the existing module. This is a zip file you can locate in the upload/modules directory

2. Unzip this file

3. Edit the vardefs file for the module you want to add fields to. If the module was Test, the file would be SugarModules/modules/Test/vardefs.php

When you look at this file you will see the format of the various fields. Just add and edit as needed.

Note you may wish to edit the language files as well, though I didn’t.

4. Zip up the folder again. Something like the following

zip -r ../test.zip *

Will give you a file test.zip that you can upload.

If the module exists, you will need to uninstall the previous version first. You can conserve the data.

5. Use Module Loader to install the modules.

That’s it. Most times you won’t want to do it this way, but in my case I needed to duplicate 5 fields 15 times. An horrible job in Module Builder.

I’ve spent some time recently working with HTML5 and thought it might be fun to use its local database capabilities to build an offline client for Sugar, especially for mobile. I know Sugar have offline apps, but they cost money and are rather inflexible. It would be good to build a framework that allowed bespoke offline applications to be built to meet clients specific needs.

Two ideas came to mind, but there are sure to be many more. Firstly, collecting leads at a business show is often done on tablets. This should be possible offline, with the stored results sent to Sugar once an internet connection becomes available.

The other possibility is simply to hold data from Sugar for offline viewing. This could be client and contact details, and maybe product details or sales history.

I know this functionality is well short of the two way syncing that can be provided by some apps, but that is much more difficult to accomplish, so that will have to wait for another day.

I’m keen to know what the capabilities and limitations are for HTML5 databases. How do they handle hundreds of thousands of records. One of my first tests will be to load large data sets from Sugar and see how they go.

Well so far I have in place the various elements needed, as follows.

1. User Interface

As these will be mainly mobile solutions I thought it best to start with JQuery Mobile to handle the user interface. This will give me mobile capabilities with very little work.

2. Internal Database

I’ve tried creating databases, and adding and reading records.

3. Communicating With Sugar

I’ve used web services to access Sugar many times from PHP, mainly for integration processes, but never from a browser. The JQuery Ajax capability is easy to use, but getting the parameters configured in JSON is a bit tricky. I can now read and insert records into Sugar, though there is more to do.

Well that’s the start. In Part 2 I’ll put all the bits together.

I would be interested to hear any comments or suggestions.