Here is a guest post from Shijin Krishna from BHEA, an Elite SugarCRM Partner, and active member of the Sugar Developer community.

Are you interested in posting on the Sugar Developer Blog? Contact developers@sugarcrm.com with your idea.

In this post we are going to see how we can add a quick create pop-up view for related modules in record view. This idea is taken from Sugar Portal which comes with Sugar Enterprise, Ultimate and Corporate editions. Sugar Portal’s detail view for Bugs and Cases modules includes an action to add a note to the bug or case. In this post, we are going to see how we can create a similar quick create pop up on the base Sugar 7 web client which will be shown at the click of a button. Continue Reading…

Below is some details from Andreas Sandberg, Director of Engineering, at SugarCRM.  Andreas is on his second tour of duty at SugarCRM.  He first joined SugarCRM back in 2007 as an Engineering manager.  He was also the Head of Engineering at Stitch prior to their acquisition by SugarCRM.

Below he shares some information about some changes that have gone into Sugar 7.7 that change how PHP sessions are stored and the underlying implementation.  Sugar Developers need to be aware of these changes so that their interactions with $_SESSION variable do not yield any unpredicted results.

What has changed with $_SESSION?

We have refactored PHP Session storage so that it is more configurable and allow more control over PHP session handling.  We have introduced a new SessionStorage class at src/Session/SessionStorage.php which extends from the TrackableArray class at src/Util/Arrays/TrackableArray/TrackableArray.php. This means that the $_SESSION variable is now an object instance of a TrackableArray which implements the ArrayAccess interface. This means that most code that treated $_SESSION like an array will continue to work as before.

However, there are three changes that Sugar Developers need to be aware of when working with the PHP session objects.  Each change is outlined below. Two of them are API level changes and the last is really just an adherence to best practices but may yield unexpected results if ignored.

Continue Reading…

The “Works On My Machine” Problem.

How often have you reported a software bug and had it rejected with a terse response such as “could not reproduce”?

You press the issue with your colleague and the conversation usually goes something like this:

You:  Here, look at my screen.  You can see the problem happening right here.

Them: Whatever. It works on my machine. L8tr dude.

Doesn’t this drive you crazy?

Ultimately, even if you are both running the exact same source code there are always factors related to configuration and platform environment that can affect how an application behaves.

The flexibility of Sugar that we all love also means that we are often running Sugar in multiple different places and in varying configurations. For example, your team could be running Sugar instances in the cloud or on-premise, on real or virtualized hardware, on different operating systems, database servers, etc.

How do you keep track of all these different configurations, let alone try to make them as consistent as possible to avoid the “works on my machine” problem?

Introducing Vagrant and Packer

Vagrant is a tool built by Hashicorp.  It is a tool designed to make managing development environments really easy.  If an existing Vagrant box exists, you are never more than two commands away from launching a development environment that you need.  But it is a tool designed specifically for developers.  It is not the right tool for hosting customer instances or for doing QA because it does not alone replicate a real operational environment.  Also, if a Vagrant box doesn’t already exist for the platform you want to work with then you need to create one.  This is where Packer comes in.

Packer is also built by Hashicorp, the same folks behind Vagrant.  Here is the definition of Packer straight off their website.

Packer is a tool for creating machine and container images for multiple platforms from a single source configuration

SugarCRM Engineering uses Packer as the base tool for creating all the images we use for development, continuous integration, and QA.

Packer can be used to create Virtualbox or VMWare images, Amazon AMIs, Vagrant boxes, or even Docker containers all from a single source.  Recall Cedric’s recent post on using Docker containers to run Sugar.  There is even a Null builder that you could use to run the same provisioners used to build your images on existing machines.

Below we will explore how you can use Packer to build a consistent Sugar 7 ready LAMP stack for Vagrant or on any other platform of your choice.  The code from this post is all available in a Sugar 7 Ready template Github repository.

Continue Reading…

Based on Sugar Developer community feedback, we have an additional update about the CreateActionsView changes in Sugar 7.7.

CreateActions migration script added to Sugar 7.7 Upgrader

During Sugar 7.7 upgrade, the upgrader will identify existing create-actions view/layout customizations and automatically migrate them to create view/layout.  This is a best effort migration that follows the two steps listed near bottom of this blog post.

If a custom create view/layout already exists, then create-actions changes will not be automatically migrated.

This will mitigate impact of this change for existing Sugar customers.

The Sugar application requires that a number of directories be writable in order to properly function.  The precise directories and minimum permissions needed are covered in the Sugar Install Guide.

A common practice for Sugar Developers to work around file permission issues is to make everything writable to the web user.  In practice, this does not cause any functional issues and is an easy way to avoid problems. But this is not desirable in production or sensitive environments from a security point of view because it violates the principle of least privilege. So Developers should really familiarize themselves with setting up secure file permissions for their web servers since this will be more in line with real production environments.

Here are some tips for working with extended file system permissions on your Sugar deployments from Jelle Vink our Security Architect.

Continue Reading…

Sidecar and Backbone.js

The Sidecar user interface framework is built on a variety of browser side technologies.  Being proficient in these underlying technologies is important for any developer writing Sugar 7 user interface code.

They key JavaScript component that pulls Sidecar together is Backbone.js. Backbone provides the underlying structure to Sidecar as well as providing a rich set of base features and APIs that are heavily used throughout the Sugar 7 application.

Sugar 7.6.x uses Backbone 0.9.10.

If you’ve ever created a Sugar Dashlet or any other user interface component in Sugar 7 then you will familiar with Backbone concepts such as customizing a View or working with a Model. However, many loosely coupled customizations or integrations with Sugar 7 user interface are possible through the use of Backbone Events.

For server side code, recall that you can use Logic