Skip navigation
All Places > Developer > Blog > 2017 > August
2017

Are you learning about Sugar for the first time?  Or maybe, it has been a while, and you want to see how the Sugar platform has evolved since the Community Edition days?

 

Watch the video below to learn why SugarCon and UnCon is the perfect way to get started with building on and integrating with Sugar.

 

Hey there, Sugar Developers!

 

I'm SugarCRM's newest Developer Advocate, and I wanted to take a moment to introduce myself.  My name is Lauren Schaefer. Since getting my bachelor's and master's degrees in Computer Science at North Carolina State (go pack!), I've been slowly migrating north over the years, and I currently live in Pennsylvania.

 

I love developing web interfaces in JavaScript. That moment when you finally get an interface pixel perfect after tinkering for hours is so rewarding.

 

I believe that technology should be easy to use, and I love helping people get started with technology that is new to them. I'm excited about making the process of becoming a Sugar developer even easier as well as introducing the community to the latest and greatest features and customizations as they become available.

 

One important part of my job is listening to what you, members of the Sugar developer community, have to say and bringing that feedback back to the engineering team. I'm looking forward to chatting with you in the Sugar Developer Community as well as in person at events like SugarCon.

 

Some facts about me...  I'm obsessed with the color pink. I'm a sucker for reality tv shows like Dancing with the Stars as well as PBS dramas like Victoria. I love to travel and have visited all seven continents (Antarctica is truly amazing!).

 

I'm really excited about meeting so many of you at SugarCon in a little over a month! Here's why:

 

 

See you in September!

 

Lauren

Post originally written by dwheelz.

 

Here is an important message from David Wheeler, a long time Software Engineer and Architect at SugarCRM, about using e-mail fields correctly.

 

E-mail handling is core to CRM software. Almost everyone we know uses multiple e-mail addresses every single day for both personal or work purposes. So it goes without saying that managing a person's multiple e-mail addresses correctly is essential in your Sugar customizations and integrations.

 

History of Sugar E-Mail fields

 

Several years ago, Sugar changed from using email# named text fields (like email1, email2, etc.) to using an e-mail relationship. This was done to better handle multiple e-mails, multiple relationships, and e-mail attributes like opt in or invalid.

 

However, use of the email1 field remains particularly persistent. We observe many examples of custom code (and some core code) that still use the old email# fields. This is probably because it is convenient to use the email1 field like a regular text field.But this is out of date, inaccurate, deprecated, and subject to removal in upcoming Sugar releases.

 

Below we will describe the proper method for using e-mail fields within Sugar customizations and integrations.

 

Sugar Metadata

 

You should reference the "email" field instead of "email#".

 

For record views, this will load a "email" type field widget with all related e-mail addresses included.

 


 

For list views, instead of all e-mail addresses only the primary e-mail address will be displayed.

 


 

Sugar PHP code

 

Instead of

$bean->email#

 

use

$bean->emailAddress->addresses

 

which references an array of e-mail addresses.

 

To determine the primary e-mail, you can iterate over the addresses array to find where the primary_address attribute is true.

foreach ($bean->emailAddresses->addresses as $address) {
    if ($address->primary_address == true) {
        // Found primary e-mail
    }
}

 

v10 REST API

 

When selecting a record's email field in a GET request, it will return a JSON array of all associated e-mail addresses.

 

When using a PUT request to update an e-mail address on a record, provide the complete e-mail address array.

 

For example,

"email": [
    {
        "email_address": "judith.banks@yahoo.com",
        "primary_address": true,
        "reply_to_address": false,
        "invalid_email": false,
        "opt_out": false
    },
    {
        "email_address": "jbanks@hotmail.com",
        "primary_address": false,
        "reply_to_address": false,
        "invalid_email": false,
        "opt_out": true
    }
],

 

If you leave off an e-mail address in a PUT request then this will be removed during the update to the record.

 

Sidecar code

 

For Sidecar code, you should not reference fields like email1, etc, when working with Beans or other models. You should be referencing the email field instead.

model.get("email1") --> model.get("email")

 

This will return a JavaScript array in the same format as returned by the REST API (above). This array of e-mails is typically iterated through for display in custom Handlebars templates.

 

PDF Templates

 

This change also applies to PDF templates. Here is the correct way to reference the primary e-mail address from a PDF template.

{$field.email1} --> {$fields.email_addresses_primary.email_address}

 

Other locations

 

You may still see email1 field referenced in e-mail templates used with Advanced Workflow or Campaigns module. Don't count on those sticking around. Please, use the email field instead.