Not unlike other areas of Sugar 7, a variety of layouts and views are used to render this screen. In a follow-up post we will take a closer look at specific areas of this same diagram as there is more info to be had.
Welcome to cheleguanaco's blog (AKA Angel Magaña), a small corner of the blogosphere dedicated to my insights on SugarCRM which I hope you will find helpful.
Thursday, December 22, 2016
SugarCRM Reference: Analyzing a Record page
As a continuation of a prior post, below is a diagram depicting the various components used on the record page within Sugar 7.
Not unlike other areas of Sugar 7, a variety of layouts and views are used to render this screen. In a follow-up post we will take a closer look at specific areas of this same diagram as there is more info to be had.
Not unlike other areas of Sugar 7, a variety of layouts and views are used to render this screen. In a follow-up post we will take a closer look at specific areas of this same diagram as there is more info to be had.
Wednesday, May 18, 2016
SugarCRM: Working with Sugar 7 Sessions
One of the changes that was introduced in Sugar 7 relates to the manner in which user sessions are managed.
In older versions of Sugar, the length of a user session was determined by a PHP parameter that controls the lifetime of a PHP session. For all intents and purposes, a Sugar session was equivalent to a PHP session and deleting the latter would in turn cause your Sugar session to also be destroyed.
For the Sugar 7 release, this process was changed and a Sugar user session is now primarily controlled by means of a series of OAuth tokens. Those of you that have worked with the REST v10 API should be familiar with the topic, but even if you have not, the information contained herein should still be of help.
A common question that is asked in relation to sessions in Sugar 7 is: how does one change the lifetime of an OAuth token?
By default, the access_token has a lifespan of 1 hour and the refresh_token, used to obtain a new access_token, lives for 2 weeks.
A brief description of the manner in which the tokens are used follows...
In older versions of Sugar, the length of a user session was determined by a PHP parameter that controls the lifetime of a PHP session. For all intents and purposes, a Sugar session was equivalent to a PHP session and deleting the latter would in turn cause your Sugar session to also be destroyed.
For the Sugar 7 release, this process was changed and a Sugar user session is now primarily controlled by means of a series of OAuth tokens. Those of you that have worked with the REST v10 API should be familiar with the topic, but even if you have not, the information contained herein should still be of help.
A common question that is asked in relation to sessions in Sugar 7 is: how does one change the lifetime of an OAuth token?
By default, the access_token has a lifespan of 1 hour and the refresh_token, used to obtain a new access_token, lives for 2 weeks.
A brief description of the manner in which the tokens are used follows...
Wednesday, May 4, 2016
SugarCRM Troubleshooting: Still Loading...
Some months back I posted an article that spoke to a problem that caused Sugar to get stuck at a "Loading..." message. As discussed in that post, the culprit usually revolves around the rewrite module or its configuration.
In recent months, however, some Sugar customers reported puzzling situations where the Loading... problem could not be resolved through corrections to the rewrite configuration. Adding to the bewilderment was the point that the configuration of these environments seemed to be in order. For example, PHP versions and configuration seemed to line up with recommendations provided by SugarCRM.
Eventually, after much effort from several folks at SugarCRM, the source of the problem was finally revealed. It turns out that late last year, the JSMin PHP extension was modified and updated to version 2.0.1. The changes in this new version of JSMin introduced an incompatibility for Sugar, which in turn causes the Loading... problem. Note this is usually accompanied by errors in the JavaScript console.
If you are encountering the Loading... issue and have already completed the steps to verify and/or correct the potential rewrite issues, double check your version of the JSMin extension. You can check the version by taking a look at the JSMin section of the output from phpinfo().
Should you have version 2.x of JSMin installed, you can correct the problem by:
In recent months, however, some Sugar customers reported puzzling situations where the Loading... problem could not be resolved through corrections to the rewrite configuration. Adding to the bewilderment was the point that the configuration of these environments seemed to be in order. For example, PHP versions and configuration seemed to line up with recommendations provided by SugarCRM.
Eventually, after much effort from several folks at SugarCRM, the source of the problem was finally revealed. It turns out that late last year, the JSMin PHP extension was modified and updated to version 2.0.1. The changes in this new version of JSMin introduced an incompatibility for Sugar, which in turn causes the Loading... problem. Note this is usually accompanied by errors in the JavaScript console.
If you are encountering the Loading... issue and have already completed the steps to verify and/or correct the potential rewrite issues, double check your version of the JSMin extension. You can check the version by taking a look at the JSMin section of the output from phpinfo().
Should you have version 2.x of JSMin installed, you can correct the problem by:
- Downgrading your version of JSMin to 1.1. Please note that if you are installing via PECL, you will need to specify the version you wish to install or it will install the latest version (2.x). To ensure it installs version 1.1, use the following command: pecl install jsmin-1.1.0
- Disable the JSMin extension. Sugar does not require this extension for proper operation. The JSMin extension is used in a limited capacity as it helps expedite the process that minifies JavaScript code used throughout Sugar. Its absence will not cause that process to fail, only reduce the speed at which it completes, thus, it is perfectly safe to disable it.
Hope this helps.
Friday, February 26, 2016
SugarCRM: Bulk API Explained
Recently I have found myself in various conversations revolving around the topic of the Bulk API and its capabilities. These conversations have helped highlight various misunderstandings relating to its functionality, which I believe are the result of a lack of documentation on the subject. Hopefully this post will help clarify some of the more common themes.
To begin with, let us discuss what the Bulk API is not.
It is not a separate interface to Sugar. It is merely another endpoint of the existing REST v10 API. In short, the moniker Bulk API is a misnomer, as the term is just referring to a component of the REST v10 API, not an alternative to it.
Quite regularly I also hear of attempts to use the Bulk API to perform mass insertions of data. For example, migrating hundreds of thousands of records from another system and into Sugar. While the Bulk API can help expedite the process, it is not specifically designed for that task and its benefits for that type of work are limited.
What is the purpose of the Bulk API endpoint?
The Bulk API endpoint aims at helping developers reduce the quantity of web requests sent to the REST v10 API. By reducing the number of requests necessary to complete a programmatic task, the time to completion can also be reduced.
The following example helps demonstrate its value quite well.
To begin with, let us discuss what the Bulk API is not.
It is not a separate interface to Sugar. It is merely another endpoint of the existing REST v10 API. In short, the moniker Bulk API is a misnomer, as the term is just referring to a component of the REST v10 API, not an alternative to it.
Quite regularly I also hear of attempts to use the Bulk API to perform mass insertions of data. For example, migrating hundreds of thousands of records from another system and into Sugar. While the Bulk API can help expedite the process, it is not specifically designed for that task and its benefits for that type of work are limited.
What is the purpose of the Bulk API endpoint?
The Bulk API endpoint aims at helping developers reduce the quantity of web requests sent to the REST v10 API. By reducing the number of requests necessary to complete a programmatic task, the time to completion can also be reduced.
The following example helps demonstrate its value quite well.
Subscribe to:
Posts (Atom)