The Sugar Developer Guide is designed for developers who are new to Sugar, or to CRM and Web-based applications. This guide introduces you to some basic CRM concepts and helps you get familiar with the Sugar system. It describes how to install and upgrade Sugar and access it through a personal computer and a Web browser to perform a broad range of customer relationship management tasks.
Sugar consists of modules which represent a specific functional aspect of CRM such as Accounts, Activities, Leads, and Opportunities. For example, the Accounts module enables you to create and manage customer accounts, the Activities module enables you to create and manage activities related to accounts, opportunities, etc. Sugar modules are designed to help you manage your customer relationships through each step of their life cycle, starting with generating and qualifying leads, through the selling process, and on to customer support and resolving reported product or service issues. Since many of these steps are interrelated, each module displays related information. For example, when you view the details of a particular account, the system also displays the related contacts, activities, opportunities, and bugs. You can view and edit this information and also create new information.
Sugar Ultimate Application Guide, Sugar Enterprise Application Guide, Sugar Corporate Application Guide, Sugar Professional Application Guide, and Sugar Community Edition Application Guide: Describe how to install, upgrade, set up, configure, manage, and use Sugar Ultimate, Sugar Enterprise, Sugar Corporate, Sugar Professional, and Sugar Community Edition.
SugarCRM was originally written on the LAMP stack (Linux,
Apache,
MySQL and
PHP). Since version 1.0, the SugarCRM development team has added support for every operating system (including Windows, Unix and Mac OSX) on which the PHP programming language runs for the Microsoft IIS Web server, the Microsoft SQL Server, and Oracle databases. Designed as the most modern web-based CRM platform available today, SugarCRM has quickly become the business application standard for companies around the world. See the
Supported Platforms page for detailed information on supported software versions and recommended stacks.
Sugar is available in five editions: the Community Edition, which is freely available for download under the GPLv3 public license, and the Professional, Corporate, Enterprise, and Ultimate editions, which are sold under a commercial subscription agreement. All five editions are developed by the same development team using the same source tree with extra modules available in the Professional, Corporate, Enterprise, and Ultimate editions. Sugar customers using the Professional, Corporate, Enterprise, and Ultimate editions also have access to Sugar Support, Training, and Professional Services offerings. Contributions are accepted from the Sugar Community, but not all contributions are included because SugarCRM maintains high standards for code quality.
|
•
|
cache: Various cache files written to the file system to minimize database accesses and store user interface templates created from metadata. Files uploaded into the application such as Note Attachments or Documents reside in this directory (refer to upload_dir parameter in the config.php file). This is an active cache directory and not all files can be deleted.
|
|
•
|
custom: Stores upgrade-safe customizations such as custom field definitions, user interface layouts, and business logic hooks.
|
|
•
|
data: Key system files are located here, most notably the SugarBean base class which controls the default application logic for all business objects in Sugar.
|
|
•
|
include: Many Sugar utility functions are located here, as well as other libraries that Sugar utilizes as part of its operations. Most notable in this directory is the utils.php file that contains the most widely used utility functions.
|
|
•
|
metadata: Contains relationship metadata for all many-to-many data relationships between the business objects.
|
|
•
|
modules: Contains all modules in the system. Custom modules installed through the Module Loader exist here as well.
|
|
•
|
Controller: Directs all incoming page requests. This can be overridden in each module to change the default behavior and relies on Entry point parameters (described below) to serve the appropriate page.
|
|
•
|
Views: A set of user interface actions managed by the Controller, the default views in Sugar include the Detail View, Edit View, and List View.
|
|
•
|
Display strings: Sugar is fully internationalized and localizable. Every language pack has its own set of display strings which is the basis of language localization. There are two types of display strings in the Sugar application: application strings and module strings. Application strings contain the user interface labels displayed globally throughout the application. The $GLOBALS[‘app_strings’] array contains these labels. The $GLOBALS[‘app_list_strings’] array contains the system-wide drop-down list values. Each language has its own application strings variables. The $GLOBALS[‘mod_strings’] array contains strings specific to the current, or in-focus, module.
|
|
•
|
Drop-down lists: Drop-down lists are represented as name => value array pairs located in the application strings mentioned above. The name value is stored in the database where the value is displayed in the Sugar User Interface (UI). Sugar enables you to create and edit drop-down lists and their values through the UI in Studio. Use the handy get_select_options_with_id() utility function to help render the <select> input options to work with drop-down lists in Edit Views. Use the translate() utility function to translate the string key you are working with into the user’s currently selected display language.
|
|
•
|
SugarBean.php: This file located under the <sugar root>/data folder contains the SugarBean base class used by all business entity or module objects. Any module that reads, writes, or displays data will extend this class. The SugarBean performs all of the heavy lifting for data interactions, relationship handling, etc.
|
|
•
|
modules.php: The modules.php file contains several variables that define which modules are active and usable in the application.
|
|
•
|
$dictionary: The $dictionary array contains all module field variable definitions (vardefs), as well as the relationship metadata for all tables in the database. This array is dynamically built based upon the vardefs.php definitions.
|
|
•
|
module: The module to be accessed as part of the call
|
|
•
|
action: The action within the module
|
Other commonly used parameters are return_module ,
return_action,
and return_id. This group of request parameters is used when a user cancels an action such as creating or editing a record.
Note: As of Sugar 5.1, most entry points were consolidated into index.php. Previous versions had other files as entry points into the application.
|
•
|
List View: This Controller action enables the search form and search results for a module. Users can perform actions such as delete, export, update multiple records (mass update), and drill into a specific record to view and edit the details. Users can see this view by default when they click one of the module tabs at the top of the page. Files in each module describe the contents of the list and search view.
|
|
•
|
Detail View: A Detail View displays a read-only view of a particular record. Usually, this is accessed via the List View. The Detail View displays the details of the object itself and related items ( sub-panels). Sub-panels are mini List Views of items that are related to the parent object. For example, Tasks assigned to a Project, or Contacts for an Opportunity will appear in sub-panels in the Project or Opportunity Detail View. <module>/metadata/detailviewdefs.php defines a module's Detail View page layout. <module>/metadata/subpaneldefs.php defines the subpanels that are displayed in the module's Detail View page.
|
|
•
|
Edit View: The Edit View page is accessed when a user creates a new record or edits details of an existing one. Edit View can also be accessed directly from the List View. <module>/metadata/editviewdefs.php defines a module's Edit View page layout.
|
|
•
|
Save: This Controller action is processed when the user clicks Save in the record’s Edit View.
|
|
•
|
Delete: This action is processed when the user clicks Delete in the Detail View of a record or in the Detail View of a record listed in a sub-panel.
|
|
•
|
forms.php: This file contains two functions to render specific JavaScript for validation or other actions during edits/saves. By default you can leave these empty and have them return ‘’;
|
|
•
|
Menu.php: This file is responsible for rendering the Shortcuts menu, which was renamed as Actions menu as of Sugar 6.0. In Community Edition, the Actions menu displays below the module tabs and the Last Viewed bar. In Sugar Ultimate, Enterprise, Corporate, and Professional editions, the Actions menu displays on every module tab. By default, you usually add a link to create a new record, and a link to the List View to search.
|
|
•
|
Popup.php: This file acts as a wrapper to the central Popup class located under the utils folder. It is called when a module wants to get a popup list of records from a related module. The central Popup class uses the Popup_picker.html and <MODULE_NAME>/metadata/popupdefs.php file to render the popup.
|
|
•
|
Popup_picker.html: This is used by the central Popup class to display a module’s pop-ups.
|
|
•
|
vardefs.php: The vardefs.php metadata file defines db and non-db fields for Sugar objects as well as relationships between objects.
|
|
•
|
field_arrays.php: This file is deprecated as of Sugar version 5.1. It has been phased out over time with the addition of metadata structures in the application, most notably the vardefs metadata.
|
|
•
|
Sugar Dashlets: These are drag-and-drop forms displayed on the Sugar Home and Dashboard tabs. Sugar Dashlets display any data (including data from external connectors), and List View and Chart data for the modules. As a developer of a custom module, you can create a Sugar Dashlet for your new module. For each Sugar Dashlet you create, you will place the necessary files in the <MODULE_NAME>/Dashlets folder.
|
|
•
|
language: This folder holds the strings files for the module. By default you will have an en_us.lang.php file containing ALL strings used by your module. These strings are represented by the $mod_strings variable accessed at any time after a global $mod_string call. The .html files located in this folder are used by the Help subsystem. Sugar provides the capabilities for multi-language support and dynamic loading via the admin panel of new language packs.
|
|
•
|
metadata: Module-specific metadata files have been added to this folder with the addition of more metadata and extensibility into the Sugar Platform. Files in this directory include: additionaldetails.php which defines the content of the pop-up displayed in the List Views; listviewdefs.php which defines the columns displayed on the List View page; popupdefs.php, which defines the search fields and list columns for a module’s popup; SearchFields.php, which defines the Basic Search and Advanced Search forms seen in the List View page; and studio.php, which defines how the Studio tool interacts with a module's metadata files.
|
|
•
|
subpanels: This folder stores the definitions of a module’s sub-panels when the module is related in a one-to-many or many-to-many fashion. You can add any number of versions in the default.php file. You can also create custom versions of sub-panels of other modules to be displayed by your custom module. For example, you can relate a custom module with the Contacts module and have a Contacts subpanel under the Detail View. You could build and place a ForWidgets.php file under the <sugar root>/modules/Contacts/subpanels/ folder. The file name is referenced by the subpanel_name parameter called from a layout_defs.php definition.
|
|
•
|
tpls: This folder holds Smarty template files used for Quick Create forms.
|
|
•
|
views: This folder contains files that can override the default Model-View-Controller (MVC) framework view files. View files can perform multiple actions on the Smarty template or outputted HTML, allowing developers to modify and extend the default UI display classes and take full control of the user interface.
|
|
•
|
Modules: Create new modules and add them to Sugar
|
|
•
|
Vardefs: Add custom fields to existing modules with the addition of your custom module
|
|
•
|
Relationships: Create new relationships between your custom module(s) and existing modules
|
|
•
|
SubPanels: Create/add new sub-panel definitions to existing modules
|
|
•
|
Strings: Override or add to module and application strings
|
|
•
|
Menus: Override or add to Actions menus
|
|
•
|
Layout Defs: Specify the displayed subpanels and the order in which they are displayed. Create the layout definition for a custom module and add it as a sub-panel to the layout definition of an existing module.
|
For Community Edition, Sugar supports LinkedIn©’s Company Insider widget and InsideView. Use this as an example connector to learn the framework and create your own. Sugar Ultimate, Sugar Enterprise, Sugar Corporate, and Sugar Professional support additional connectors, such as Hoovers
© , Zoominfo, Google Docs, Twitter, Facebook, GoToMeeting, LotusLive, and WebEx, and have the ability to merge the data into existing Sugar records.
|
•
|
cron.php – used by the Windows Scheduler Service or the cron service on Linux and Unix for executing the Sugar Scheduler periodically
|
|
•
|
index.php – default entry point into the Sugar application
|
|
•
|
soap.php – entry point for all SOAP calls
|
|
•
|
rest.php – entry point for all REST calls
|
|
2.
|
For the pdf.php entry point, the array appears in include/MVC/Controller/entry_point_registry.php as:
|
For the above pdf.php example, we would change our references from:
|
•
|
campaign_tracker.php – used by the Campaign Management module for tracking campaign responses (deprecated as of Sugar 5.1.0)
|
|
•
|
cron.php – used by the Windows Scheduler Service or the cron service on Linux and Unix for executing the Sugar Scheduler periodically
|
|
•
|
index.php – default entry point into the Sugar application
|
|
•
|
soap.php – entry point for all SOAP calls
|
|
•
|
rest.php – entry point for all REST calls
|
Activate the Developer Mode (Admin->System Settings->Advanced->Developer Mode) to ignore these cached files during development activities in Sugar. This is especially helpful when you are directly altering templates, metadata, or language files. The system automatically refreshes the file cache in Module Builder and Studio. Deactivate the Developer Mode after completing customizations because this mode degrades system performance.
Sugar Dashlets use the abstract factory design pattern. Individual dashlets extend the base abstract class
Dashlet.php, List View Dashlets extend the base abstract class
DashletGeneric.php, and Chart Dashlets extend the base abstract class
DashletGenericChart.php.
Sugar Dashlet developers use the custom/ directory to upgrade-safe their Sugar Dashlets. Sugar Dashlets offered in base Sugar releases are located in the standard
modules/ directory.
The naming convention for the metadata file is className.meta.php, where
className is the name of the Sugar Dashlet. The metadata file must reside in the same directory as the Sugar Dashlet code. For JotPad Dashlet, the meta file is stored in
modules/Home/Dashlets/JotPadDashlet/JotPadDashlet.meta.php.
|
•
|
Portal – Sugar Dashlets that allow access to outside data (RSS, Web services, etc)
|
|
•
|
Tools – Various tools such as notepad, calculator, or world clock
|
The options element stores the options for the Sugar dashlet. This element is loaded/stored by
storeOptions /loadOptions functions in the base Dashlet class.
postForm is used to post the configuration form through AJAX. The callback to remove the configuration dialog is
SUGAR.sugarHome.uncoverPage.
callMethod is a generic way to call a method in a Dashlet class. Use this function to generically call a method within your Dashlet class (php side). Refresh your Dashlet after a call and utilize a callback function (optional). This method can also be used to proxy AJAX calls to Web services that do not exist in the Sugar installation, for example, Google Maps Mash-up.
As of version 5.1, Sugar uses a type-ahead combo box system called QuickSearch that utilizes components from the YUI framework. The Sugar QuickSearch (SQS) code resides in the file
<sugar_root>/include/javascript/quicksearch.js. This file, along with the YUI dependencies are grouped into
<sugar_root>/include/javascript/sugar_grp1_yui.js which is loaded in all the main pages of SugarCRM. A custom YUI AutoComplete widget is used to pull data through an AJAX call to
http://yourserver/SugarCRM/index.php. This then accesses the file
<sugar_root>/modules/Home/quicksearchQuery.php.
|
|
JS array sqs_objects is defined and contains the field name
|
sqsNoAutofill: Add this string to the field class to disable automatic filling of the field on Blur.
|
•
|
$category – Corresponds to the module directory where the bean resides. For example: Accounts.
|
|
•
|
$action – The action you want to check against. For example, Edit. These actions correspond to actions in the acl_actions table as well as actions performed by the user within the application.
|
|
•
|
$is_owner – verifies if the owner of the record is attempting an action. Defaults to false. This is relevant when the access level = ALLOW_OWNER.
|
See the Roles section in the
Sugar Application Guide for a list of actions and their possible values.
The name of the index must start with idx_ and must be unique across the database. Possible values for
type include
primary for a primary key or
index for a normal index. The fields list matches the column names used in the database.
|
•
|
Case-sensitivity: IDs abc and ABC are treated the same in MySQL but represent different values in Oracle. When migrating data to Sugar, some CRM systems may use case sensitive strings as their IDs on export. If this is the case, and you are running MySQL, you need to run an algorithm on the data to make sure all of the IDs are unique. One simple algorithm is to MD5 the ids that they provide. A quick check will let you know if there is a problem. If you imported 80,000 leads and there are only 60,000 in the system, some may have been lost due to non-unique primary keys, as a result of case sensitivity.
|
Note: If the Sugar config.php variables site_url is wrong, SugarSoap will not work. Be sure to verify this value before continuing.
See examples/SugarFullTest_Version2.php for more examples on usage.
The Serve function decodes or unserializes the appropriate datatype based on the input type; the
generateResponse function encodes or serializes it based on the output type. See
service/test.html for more examples on usage. In this file, the
getRequestData function, which generates URL with
json, is both the input_type and the response_type. That is, the request data from the javascript to the server is
json and response data from server is also
json. You can mix and match any datatype as input and output. For example, you can have
json as the input_type and
serialize as the response_type based on your application’s requirements.
All API classes are located in the Service directory. The URL for the Service directory is http://localhost/service/vX/soap.php, where X is the version of the API that you wish to reference. The following chart indicates which versions of the API are available along with the corresponding Sugar version it was released with. If you are using a particular version of the API, note that we will not modify the API signatures for existing versions. This ensures that you can safely upgrade your SugarCRM instance without worrying about any potential impact to your existing API calls. New calls and features will be released in a newer version of the API when they are made available.
Returns the ID, module name and fields for specified modules. Supported modules are Accounts, Bugs, Calls, Cases, Contacts, Leads, Opportunities, Projects, Project Tasks, and Quotes.
require_once('include/nusoap/nusoap.php');
$soapClient = new nusoapclient('http://YOURSUGARINSTANCE/service/v2/soap.php?wsdl',true);
$userAuth = $soapClient->call('login',
array('user_auth' =>
array('user_name' => 'jim',
'password' => md5('jim'),
'version' => '.01'),
'application_name' => 'SoapTest'));
$sessionId = $userAuth['id'];
$reportIds = array('id'=>'c42c1789-c8a6-5876-93a3-4c1ff15d17f6');
$myReportData = $soapClient->call('get_report_entries',
array('session'=>$sessionId,
'ids'=>$reportIds));
Note: it is also possible to create a NuSOAP client as follows without requiring the WSDL:
|
•
|
Model - This is the data object built by the business/application logic needed to present in the user interface. For Sugar, it is represented by the SugarBean and all subclasses of the SugarBean.
|
|
•
|
View - This is the display layer which is responsible for rendering data from the Model to the end-user.
|
|
•
|
Controller - This is the layer that handles user events such as "Save" and determines what business logic actions to take to build the model, and which view to load for rendering the data to end users.
|
We can take this a step further and add assignable to the mix. An
assignable module would be one that can be assigned to users. Although this is not used by every module, many modules do let you assign records to users. SugarObject interfaces allow us to add “assignable” to modules in which we want to enable users to assign records.
|
•
|
action_save - this is the broadest specification and gives the user full control over the Save process.
|
|
•
|
pre_save - a user could override the population of parameters from the form
|
|
•
|
post_save - this is where the view is being setup. At this point the developer could set a redirect url, do some post save processing, or set a different view
|
As a developer, to create a custom view you would place a view.<view_name>.php file in a
views/ subdirectory within the module. For example, for the DetailView, you would create a file name
view.detail.php and place this within the
views/ subdirectory within the module. If a views subdirectory does not exist, you must create one.
In the file, create a class named: <Module>View<ViewName>. For example, for a list view within the Contacts module the class would be
ContactsViewList. Note the first letter of each word is uppercase and all other letters are lowercase.
You can extend the class from SugarView, the parent class of all views, or you can extend from an existing view. For example, extending from the out-of-the-box list view can leverage a lot of the logic that has already been created for displaying a list view.
|
•
|
preDisplay() - This performs pre-processing within a view. This method is relevant only for extending existing views. For example, the include/MVC/View/views/view.edit.php file uses it, and enables developers who wishes to extend this view to leverage all of the logic done in preDisplay() and either override the display() method completely or within your own display() method call parent::display().
|
|
•
|
display() - This method displays the data to the screen. Place the logic to display output to the screen here.
|
The ViewFactory class tries to load the view for view in this sequence, and will use the first one it finds:
The $beanList() array stores a list of all active beans (modules) in the application. The
$beanList entries are stored in a ‘name’ => ‘value fashion with the ‘name’ value being in the plural and the ‘value’ being in the singular of the module name. The ‘value’ of a
$beanList() entry is used to lookup values in our next modules.php variable, the
$beanFiles() array.
The $beanFiles variable is also stored in a ‘name’ => ‘value’ fashion. The ‘name’, typically in singular, is a reference to the class name of the object, which is looked up from the $beanList ‘value’, and the ‘value’ is a reference to the class file. From these three arrays you can include the class, instantiate an instance, and execute module functionality.
The remaining relevant variables in the modules.php file are the $modInvisList variable which makes modules invisible in the regular user interface (i.e., no tab appears for these modules), and the
$adminOnlyList which is an extra level of security for modules that are can be accessed only by administrators through the Admin page.
The searchdefs.php file is invoked from the MVC framework whenever a module's list view is rendered (see include/MVC/View/views/view.list.php). Within
view.list.php checks are made to see if the module has defined a
SearchForm.html file. If this file exists, the MVC will run in classic mode and use the aforementioned
include/SearchForm/SearchForm.php file to process the search form. Otherwise, the new search form processing is invoked using
include/SearchForm/SearchForm2.php and the searchdefs.php file is scanned for first under the custom/modules/[module]/metadata directory and then in modules/[module]/metadata.
The process() method is invoked on the generic DetailView.php instance:
)
This specifies a default panel under the panels section with three rows. The first row has two fields (name and amount). The amount field has some special formatting using the label override option. The second row contains the account_name field and the third row contains the opportunity_type column.
The display() method is then invoked on the generic DetailView instance for the final step.
When the display() method is invoked, variables to the DetailView.tpl Smarty template are assigned and the module's HTML code is sent to the output buffer.
This section describes the SugarFields widgets that are found in the include/SugarFields/Fields directory. Inside this folder you will find a set of directories that encapsulate the rendering of a field type (for example, Boolean, Text, Enum, and so on.). That is, there are user interface paradigms associated with a particular field type. For example, a Boolean field type as defined in a module's vardef.php file can be displayed with a checkbox indicating the boolean nature of the field value (on/off, yes/no, 0/1, etc.). Naturally there are some displays in which the rendered user interface components are very specific to the module's logic. In this example, it is likely that custom code was used in the metadata file definition. There are also SugarFields directories for grouped display values (e.g. Address, Datetime, Parent, and Relate).
Note also the presence of file include/SugarFields/Fields/Address/SugarFieldAddress.js. This file is responsible for handling the logic of copying address values (from billing to shipping, primary to alternative, etc.). The JavaScript code makes assumptions using the key value of the grouped fields.
In the ./metadata directory, all the many-to-many relationships are defined and included in the $dictionary array. The files are stored in
./metadata/<relation_table_name>MetaData.php. Tables are generated based on these definitions. These files are included through the
./modules/TableDictionary.php. If you create a custom many-to-many relationship, you will need to add the reference to the new relationship by adding the new reference in the file
custom/application/Ext/TableDictionary/tabledictionary.php. You may need to create this file if it does not exist. These changes will take effect after you clear the Sugar Cache by running the “Quick Repair and Rebuild” option from the Admin Repair screen.
|
•
|
table - the name of the table that is created in the database
|
|
•
|
fields - array containing arrays for each column definition. The join table must have a field for the primary key of each table to be linked, a primary key for the join table itself, a deleted field for relationship unlinking, and a date_modified field to track when the relationship changes. Additional fields can be added to track the role played by the relationship,
|
|
•
|
indices - the database indices. Note see the example for indices below for necessary values.
|
|
•
|
relationships - definitions of the relationships between the two tables
|
|
o
|
lhs_module - the left hand module. Should match $beanList index
|
|
o
|
lhs_key - the key to use from the left table
|
|
o
|
rhs_module - the right hand module. Should match $beanList index
|
|
o
|
rhs_key - the key to use from the right table
|
|
o
|
join_key_lhs - left table key. Should exist in table field definitions above
|
|
o
|
join_key_rhs - right table key. Should exist in table field definitions above
|
In the ./metadata directory, the relationship must exist and included in the $dictionary array. To keep consistent with the above accounts_bugs example, here is the content of the
accounts_bugsMetaData.php
|
•
|
Studio - Edit Dropdowns, Custom Fields, Layouts and Labels
|
|
•
|
Module Builder - Build new modules to expand the functionality of SugarCRM
|
|
•
|
Module Loader - Add or remove Sugar modules, themes, and language packs
|
|
•
|
Dropdown Editor - Add, delete, or change the dropdown lists in the application
|
For further information on how to use these tools, please refer to the Sugar Application Guide. This guide will go into more detail on how to use the Module Builder and the Module Loader, as well as how to extend the Sugar system at the code-level beyond what these tools provide.
When developing in Sugar, we suggest that you turn on the Developer Mode (Admin->System Settings->Advanced->Developer Mode) to get the system to ignore the cached metadata files. This is especially helpful when you are directly altering templates, metadata, or language files. When using Module Builder or Studio, the system will automatically refresh the file cache. Be sure to turn off Developer Mode when you have completed your customizations since this mode does degrade system performance.
If you added a $module_menu=array(); to the top of this file, you would effectively clear out any of the standard menu items. You could then replace them all with new definitions.
If the custom file is in the /custom/Extension/application/Ext/Menus/ directory, then your menu changes will affect shortcut menus in every module.
where modulename is the name of the module to which you are adding the sub-panel.
Five of the six object templates contain pre-built CRM functionality for key CRM use cases. These objects are:”basic”, “company”, “file”, “issue”, “person”, and “sale”. The “basic” template provides fields such as Name, Assigned to, Team, Date Created, and Description. As their title denotes, the rest of these templates contain fields and application logic to describe entities similar to “Accounts”, “Documents, “Cases”, “Contacts”, and “Opportunities”, respectively. Thus, to create a Custom Module to track a type of account, you would select the “Company” template. Similarly, to track human interactions, you would select “People”.
$manifest array elements provide the Module Loader with descriptive information about the extension.
|
o
|
acceptable_sugar_flavors - Specifies which Sugar Editions the package can be installed on. Accepted values are any combination of: OS (valid prior to Sugar 5.0.0), CE (valid after Sugar 5.0.0), PRO, and ENT.
|
|
o
|
author - Contains the author of the package, i.e. “SugarCRM Inc.”
|
|
o
|
copy_files - An array detailing the source and destination of files that should be copied during installation of the package. See the example manifest file below for details.
|
|
o
|
dependencies - A set of dependencies that must be satisfied to install the module. This contains two arrays:
|
|
o
|
description - A description of the package. Displayed during installation. Note: Apostrophes (') are not supported in your description and will cause a Module Loader error.
|
|
o
|
icon - A path (within the package ZIP file) to an icon image that will be displayed during installation. Examples include: “./patch_directory/icon.gif” and “./patch_directory/images/theme.gif”
|
|
o
|
is_uninstallable - Setting this directive to TRUE allows the Sugar administrator to uninstall the package. Setting this directive to FALSE disables the uninstall feature.
|
|
o
|
name - The name of the package. Displayed during installation. Note: Apostrophes (') are not supported in your description and will cause a Module Loader error.
|
|
o
|
published_date - The date the package was published. Displayed during installation.
|
|
o
|
type - The package type. Accepted values are:
|
|
o
|
langpack - Packages of type langpack will be automatically added to the “Language” dropdown on the Sugar Login screen. They are installed using the Upgrade Wizard.
|
|
o
|
theme - Packages of type theme will be automatically added to the “Theme” dropdown on the Sugar Login screen. They are installed using the Upgrade Wizard.
|
|
o
|
version - The version of the patch, i.e. “1.0” or “0.96-pre1” .
|
$installdef array elements are used by the Module Loader to determine the actual installation steps that need to be taken to install the extension.
|
•
|
id - A unique name for your module; for example, “Songs”
|
|
•
|
copy - An array detailing files to be copied to the Sugar directory. A source path and destination path must be specified for each file or directory. See the example manifest file below for details.
|
|
•
|
language - An array detailing individual language files for your module. The source path, destination file, and language pack name must be specified for each language file. See the example manifest file below for details.
|
|
•
|
layoutdefs - An array detailing individual layoutdef files, which are used primarily for setting up subpanels in other modules. The source path and destination module must be specified for each layoutdef file. See the example manifest file below for details.
|
|
•
|
layoutfields - An array detailing custom fields to be added to existing layouts. The fields will be added to the edit and detail views of target modules. See the example manifest file below for details.
|
|
•
|
vardefs - An array detailing individual vardef files, which are used primarily for defining fields and non many-to-many relationships in other modules. The source path and destination module must be specified for each vardef file. See the example manifest file below for details.
|
|
•
|
menu - An array detailing the menu file for your new module. A source path and destination module must be specified for each menu file. See the example manifest file below for details.
|
|
•
|
beans - An array specifying the bean files for your new module. The following sub-directives must be specified for each bean:
|
|
•
|
relationships - An array detailing relationship files, used to link your new modules to existing modules. A metadata path must be specified for each relationship. See the example manifest file below for details.
|
|
•
|
custom_fields - An array detailing custom fields to be installed for your new module. The following sub-directives must be specified for each custom field:
|
The following sample manifest file defines the $manifest and
$installdef array elements for a new module (Songs) which depends on two other modules: "Whale Pod" and "Maps". In addition to defining the
$manifest and
$installdef array elements, it also defines the
$upgrade_manifest array.
|
o
|
name: the name of the event that you are hooking your custom logic to
|
|
o
|
array: an array containing the parameters needed to fire the hook
|
|
o
|
$bean - $this bean passed in by reference.
|
|
o
|
$event - The string for the current event (i.e. before_save)
|
|
o
|
$arguments - An array of arguments that are specific to the event.
|
You see that the $bean is fed into the function and allows access to all of the fields for the currently selected record. Any changes you make to the array will be reflected in the actual data. For example, in this script we are changing the description field. As shown above, there is
$event is set to whatever event is currently running like
after_retrieve or before_delete.
|
o
|
Make sure that the permissions on your logic_hooks.php file and the class file that it references are readable by the web server. If this is not done, Sugar will not read the files and your business logic extensions will not work. For example, *nix developers who are extending the Tasks logic should use the following command for the logic_hooks file and the same command for the class file that will be called.
|
|
o
|
Make sure that the entire custom/ directory is writable by the web server, or else the logic hooks code will not work properly.
|
Note: You do not have to necessarily create a view.edit.php file, but usually at this point of customization, you will want to add variables to your customized template that are not assigned by the generic EditView handling from the MVC framework. See the next example, Overriding the View, for more information about sub-classing the EditView and assigning Smarty variables to the resulting templates.
Here the $JSON_CONFIG_JAVASCRIPT Smarty variable was the result of a complex operation and not available via the vardefs.php file (i.e. there is no
JSON_CONFIG_JAVASCRIPT declaration in the vardefs.php file).
|
4)
|
Create a directory include/SugarFields/Fields/YouTube. The name of the directory (YouTube) corresponds to the name of the field type you are creating.
|
|
5)
|
In include/SugarFields/Fields/YouTube directory, create the file DetailView.tpl. For the DetailView we will use the "embed" tag to display the video. In order to do this, you need to add the following to the template file:
|
|
o
|
method: Unless you make a new method on the JSON server, keep this as query.
|
|
o
|
populate_list: This defines the id's of the fields to be populated after a selection is made. QuickSearch will map the first item of field_list to the first item of populate_list. ie. field_list[0] = populate_list[0], field_list[1] = populate_list[1].... until the end of populate list.
|
|
o
|
limit: reduce from 30 if query is large hit, but never less than 12.
|
|
o
|
conditions: options are like_custom, contains, or default of starts with if using 'like_custom' also define 'begin'/'end' for strings to prepend or append to the user input
|
|
o
|
disable: set this to true to disable SQS (optional, useful for disabling SQS on parent types in calls for example)
|
|
o
|
post_onblur_function: this is an optional function to be called after the user has made a selection. It will be passed in an array with the items in field_list as keys and their corresponding values for the selection as values.
|
|
1.
|
Customize the drop-down array lists in the global language file(s):
date_range_search_dom for dates and
numeric_range_search_dom for numbers.
For example, to add a First Quarter operator, add the following to the file custom/include/language/en_us.lang.php:
$app_list_strings['date_range_search_dom'] =
array(
'=' => 'Equals',
'not_equal' => 'Not On',
'greater_than' => 'After',
'less_than' => 'Before',
'last_7_days' => 'Last 7 Days',
'next_7_days' => 'Next 7 Days',
'last_30_days' => 'Last 30 Days',
'next_30_days' => 'Next 30 Days',
'last_month' => 'Last Month',
'this_month' => 'This Month',
'next_month' => 'Next Month',
'first_quarter' => 'First Quarter', //Added "First Quarter" operator
'last_year' => 'Last Year',
'this_year' => 'This Year',
'next_year' => 'Next Year',
'between' => 'Is Between',
);
|
|
2.
|
Alter the include/MVC/View/views/view.list.php. This step is not upgrade safe, but necessary since there are a lot of files that reference this file. The code to change is in the prepareSearchForm function. Load your custom SearchForm2.php implementation (say custom/include/SearchForm/SearchForm2.php) instead of include/SearchForm/SearchForm2.php, function prepareSearchForm() {
...
$this->use_old_search = false;
require_once('custom/include/SearchForm/SearchForm2.php');
...}
|
In this example, assume first_quarter to be the dates between January 1 and March 31, inclusive. Also, for brevity, this example covers mysql queries only.
NOTE: It is important to separate your JavaScript into a separate JavaScript file. This is because Sugar Dashlets are dynamically added to a page through AJAX. The HTML included into JavaScript is not evaluated when dynamically included.
|
o
|
acceptable_sugar_flavors Contains which Sugar editions the package can be installed on. Accepted values are any combination of: CE, PRO, CORP, ENT, and ULT.
|
|
o
|
author Contains the author of the package; for example, “SugarCRM Inc.”
|
|
o
|
copy_files An array detailing the source and destination of files that should be copied during installation of the package. See the example manifest file below for details.
|
|
o
|
description A description of the package. Displayed during installation.
|
|
o
|
icon A path (within the package ZIP file) to an icon image that will be displayed during installation. Examples include “./patch_directory/icon.gif” and “./patch_directory/images/theme.gif”
|
|
o
|
is_uninstallable Setting this directive to TRUE allows the Sugar administrator to uninstall the package. Setting this directive to FALSE disables the uninstall feature.
|
|
o
|
name The name of the package. Displayed during installation.
|
|
o
|
published_date The date the package was published. Displayed during installation.
|
|
o
|
type The package type. This should be set to “theme”
|
|
o
|
version The version of the patch, i.e. “1.0” or “0.96-pre1”
|
Note: You can also set the default language in the config.php. This value is used if a user does not specify a language while logging into the application.
Note: Some language files that ship with Sugar are not named “en_us.lang.php” but are “.html” or “.tpl” files. These files are used for the inline help system. A complete language pack will include the translated versions of these files as well.
Note: In the include/language/<new>.lang.php file, you will see that there are two global arrays defined. The $app_list_strings array is actually an array of arrays. The key values in this array must not be changed. There are comments and examples in the code that should keep you on track.
Note: Be careful to choose a language pack that is up to date and is working.
|
•
|
Header - This method override the regular Header() method to enable the custom image directory in addition to the OOB image directory.
|
|
•
|
SetFont - This method override the regular SetFont() method to enable the custom font directory in addition to the OOB font directory.
|
|
•
|
Cell - Handle HTML entity decode.
|
|
•
|
getNumLines - This method is a fix for a better handling of the count. It handles the line break between words.
|
|
•
|
predisplay - preprocessing before the display method is called. Is intended to setup general PDF document properties like margin, footer, header, etc.
|
|
•
|
display - performs the actual PDF content generation. This is where the logic to display output to the PDF should be placed.
|
|
•
|
process - calls predisplay and display.
|
|
•
|
writeCellTable – Method to print a table using the Cell print method of TCPDF
|
|
•
|
writeHTMLTable - Method to print a table using the writeHTML print method of TCPDF
|
This file is included by Sugarpdf.php
. This php file is a utils file. It contains many functions that can be used to generate PDFs.
|
1.
|
Add the file custom/modules/<myModule>/sugarpdf/sugarpdf.<mySugarpdf>.php
|
|
a)
|
require include/Sugarpdf/Sugarpdf.php
|
Warning: HTML and CSS support in writeHTML() is limited. For more details, read the TCPDF documentation
|
•
|
Add custom/modules/Contacts/sugarpdf/sugarpdf.test.php with this content :
|
|
•
|
Add custom/modules/Contacts/tpls/test.tpl with this content :
|
|
•
|
Create custom/modules/Configurator/metadata/SugarpdfSettingsdefs.php
|
Note: You can view
all the available settings in
modules/Configurator/metadata/SugarpdfSettingsdefs.php (commented and not commented).
Sugar Logic has several fundamental types. They are: number,
string,
boolean, and
enum (lists). Functions may take in any of these type or combinations thereof and return as output one of these types. Fields may also often have their value set to only a certain type.
A boolean type is simple. It can be one of two values: true or
false. This type mainly acts as a flag, as in whether a condition is met or not. For example, the function
contains takes in as input two strings and returns
true if the first string contains the second string or
false otherwise.
Custom functions will be stored in "custom/include/Expressions/Expression/{Type}/{Function_Name}.php". The first step in writing a custom function is to decide what category the function falls under. Take for example a function for calculating the
factorial of a number. In this case we will be returning a number so we will create a file in "
custom/include/Expressions/Expression/Numeric/" called "
FactorialExpression.php". In the new PHP file we just created, we will define a class called
FactorialExpression that will extend
NumericExpression. All formula functions must follow the format "{functionName}Expression.php" and the class name must match the file name. Next we need to decide what parameters the function will accept. In this case, we need take in a single parameter, the number to return the factorial of. Since this class will be a sub-class of
NumericExpression, it by default accepts only
numeric types, we need not worry about specifying the type requirement.
A simple action could be a "WarningAction" that shows an alert warning the user that something may be wrong, and logs a message to the
sugarcrm.log file if triggered on the server side. It will take in a message as a formula so that the message can be customized at run time. We would do this by creating a php file in "
custom/include/Expressions/Actions/WarningAction.php". containing the following code:
* @return string javascript.
* @return string javascript.
* @param SugarBean $target
Make a REST call to oauth_request_token method (supported in REST API version 4) to create a Request Token. Example using PHP OAuth extension:
One thing to note is the EditView class’s interaction with the TemplateHandler class. The TemplateHandler class is responsible for generating a Smarty template in the cache/modules/<module> directory. For example, for the Accounts module, the TemplateHandler will create the Smarty file cache/modules/Accounts/DetailView.tpl based on the Metadata file definition and other supplementary information from the EditView class. The TemplateHandler class actually uses Smarty itself to generate the resulting template that is placed in the aforementioned cache directory.
