Archives For

I came across this post on Stack Overflow today…

Using SugarCRM’s REST API, I can’t seem to find where to get a user’s timezone info.

This isn’t possible in the current Web Services API, as there’s no way to get at the User preferences via the API. However, this is possible with the new REST API coming this fall with Sugar 7, as you can not only use the /me/preference/:preference_name endpoint to get at preferences for the current user, but also combine it with the sudo call to switch to another user if you are an admin. Check out the following code example to see how…

You could of course use this to get at any user preference, or get all of them by hitting the /me/preferences endpoint instead.

I came across this blog post the other day from Suga Angel Magaña, talking about the following error he saw on an instance he was working on…

MySQL error 1439: Display width out of range for column '<some_field_name>' (max = 255)

What the problem amounted to was a misinterpretation on what the ‘Max Size’ entry meant in Studio. From the blog…

When defining an integer field within the Studio tool in SugarCRM, the parameter that controls this width is labeled Max Size. In contrast, the maximum value that a given field can hold is controlled by the parameter in the field labeled Max Value. Please see the image below and note these two parameters.

Sometimes this distinction causes some confusion and the two values are mixed up, resulting in values greater than 255 in the Max Size field. For example, someone might mistakingly enter 1,000,000 to indicate the largest value the field should accept is one million. This in turn exceeds the hard limit of 255 and results in the above referenced error. 

So make note of this distinction. While you may want to set a limit of the value entered, you should always set the ‘Max Size’ to the maximum number of digits you want the field to accept ( including decimal places and the decimal point ).

Thanks Angel for this tip!

Sugar out of the box has all the basic pieces for a person’s name; first name, last name, and salutation. But what if you need to add a person’s middle name, or perhaps a suffix field? You can add the custom fields in easily enough, but then how can you ensure the full name display has all of these pieces properly together?

Here’s two ways you could do it. First, leveraging Sugar Logic, you could build a formula like this on the name and full_name fields…

concat($salutation," ",$first_name," ",$middle_name_c," ",$last_name," ",$suffix_c)

Another option is you could do is override the _create_proper_name_field() method in that specific module’s bean class to include in the $middle_name_c and $suffix_c fields in the method. See below for an example on how this could work…

Here’s something I’m sure comes up quite often for folks managing many SugarCRM instances, or wanting to automate the deploy process to production for
their own instance: How can I silent install packages to an instance? Fortunately, much of the API to do this is in the product, we just need a small script to wrap around the process to make it happen.

Take a look at the below script, which will do this for you with ease.

Big thanks to our excellent Ops team headed up by Zac Sprackett for this script.

We had a blog post a while back from Jeff Bickart which illustrated his script for doing a Quick Rebuilds and Repair in Sugar, which is a task many a Sugar developer does on a regular basis as they work on extending the app. Our very own Charles Hicks took Jeff’s script and added some nice pizzaz to it, adding a few more features such as…

  • You pass in the path to the instance needing repaired, so now the script can live anywhere and you can use it on multiple different Sugar instances
  • Clears all of the language file caches

Check it out below. Thanks Charles for this script!

One of the slightlly annoying parts of Sugar Logic for many users is that Sugar Logic calculations are only executed on record save. So if you have calculations based off of data outside the record ( such as a rollup value ) or if you want to populate a calculated field on a record that was last touched before the calculation was added, you’ll need to save the record.

There’s two ways to do this. If you want to have something a bit more automated and don’t mind writing some code, you could write a script like this to go thru all the records…

<?php

$bean = BeanFactory::newBean('BeanName');
foreach ( $bean->get_full_list() as $record ) {
	$focus = BeanFactory::getBean('BeanName',$record->id);
	$focus->save();
}

But what if you don’t want to write a script for this?

I came across this blog post from the folks at EnableIT the other day, which talked about a nice way to use the Mass Update functionality to do the same thing. Here’s how they said to do it…

Go to the relevant module which contains the calculated field you are wanting to update. Using the Search panel (either Basic or Advanced) filters, search for the records you want to update.

Use the Select All option on the Seletion options dropdown and then select Mass Update from the More Actions menu.

You will be presented with the Mass Update panel for that module. Without selecting any of the available fields to update, simply click the Update button.
You will be asked whether you really want to update the selected records. Click Yes.

What this will do is update (in essence, Edit and Save) each of the records, causing the calculated fields to populate.

It should be noted that if you have other fields in the system which have calculations which call on these fields which have just updated, they will automatically repopulate without the need to mass update in the other module.

Thanks Mike for this great tip!

Often times in a logic hook, you may want to perform an action only if a value changes from one thing to another or only if it’s a newly added record. You can easily detect this in before_save logic hooks via the fetched_row attribute, but this isn’t possible in the after_save hook. But, if you string together both hooks, you can bring the fetched_row over from one to the other with ease. See the below code example for an idea on how to do this…

Here we simply store the fetched_row array into a static class member, which we can leverage in the subsequent hook later on in the file. Then in the after_save hook, we can easily tell if a record field has changed, or even if it’s a newly added record.