Customizing Line Item in SugarCRM in upgrade safe manner
Posted By: Doddy.Amijaya on October 25th, 2013 in SugarCRM
No Gravatar

I came across this request not too long a go and it did take a while for me to figure out. Now I’d like to share it with you guys hopefully this will save your hours of researching.
I used Aptana as my text editor because I need to reformat the minified Quotes.js

there are 6 files that you have to modify (7 if you would like to customize print to pdf feature as well):
1. Quotes.js (this is where you’d create the line items form)
2. EditView.js (This is to update the value)
3. editviews.php (this is where you would reference the EditViewFooter.tpl)
4. view.edit.php (this is to set the line items value)
5. EditViewFooter.tpl (this is where you reference the Quotes.js)
6. DetailViewFooter.tpl (this is the detail view of line items form)
7. sugarpdf.standard.php (this is to export to pdf)

(more…)


SalesLogix 8 – Validating 1:M Data from an Editable Grid before insert
Posted By: Alex.Cottner on October 16th, 2013 in General, Saleslogix
No Gravatar

I ran into a problem recently where I needed to have a 1:M editable grid (contacts) on an insert page (opportunity). The data in that grid needed to go through validation along with the base entity before any records could be inserted. However, this isn’t the way insert pages in SalesLogix 8 normally work. Normally, the base entity is saved first. Once it is saved the 1:M records in the editable grid are then saved all at once (via the editable grid’s “InsertAssociationAction” method).

This wouldn’t work for me. If one of the validation rules for the 1:M data threw an exception, then the user was stuck on the insert page with partially saved data. The base entity already existed in the database but the 1:M grid data hasn’t been saved yet.

The easiest way to resolve this is to take the code from the grid’s “InsertAssociationAction” and move it into your insert form’s save action. You will have to either hard code or search for an ID in the postback, but that is the only hard thing. See code example below.
(more…)


Customizing the activity form on Saleslogix 8
Posted By: nicocrm on October 14th, 2013 in Saleslogix
No Gravatar

In SalesLogix 8 the activity editor has been completely reworked to be entirely Javascript based. Although this brought a little bit of pain as none of the previous customizations carried over, and there wasn’t a whole lot of documentation available, it’s a big improvement over the last screen in term of how it makes possible modular customizations – where our changes can plug into the existing form instead of overwriting it.

To do that, we take advantage of the dynamic nature of Javascript to modify the way the ActivityEditor and ActivityService javascript classes methods work – adding bits that will implement our custom functionality. Once you know which method to modify, you can use dojo.aspect to add your own method that will run after the stock one is called. Because that can be called repeatedly it will still work if different modules add their own customizations to the form, effectively enabling third party modules that include changes to the activity form without requiring the customer to manually edit them (previously this was impossible because the ascx and ascx.cs files had to be edited directly – there was no provision to add functionality to them without that).

A common customization request is adding an activity capability to a custom entity. Adding the tab itself is easy enough – once you add the column to the activity table and update the entity in App Architect to reflect the change it will detect it and populate the tab automatically, so you just need to drop the tab’s smart part onto the custom entity page. The other customizations require us to load a Javascript module which will implement them. This itself can be done by modifying the base.master file, but ideally implemented instead via a .NET module defined in your business rules assembly and registered with the portal in Application Architect. For example this is my “ScriptOutputModule”:

(more…)


Custom control without a custom smartpart
Posted By: nicocrm on October 10th, 2013 in Saleslogix
No Gravatar

On Saleslogix 8 most of the controls used on quickforms map directly to dojo controls (called “dijit”, short for “dojo widget”), and the properties that are set on the quickform editor are just passed to the javascript control. This makes it very easy for us to use a custom javascript control, or customize the properties passed to an existing control, without having to start a whole custom smart part.

For example, the currency control that we use on our Saleslogix forms has a few limitations, one of which being that the maximum number of decimal places is hard coded to 2 (you can specify 3, but the system will still only display the first 2). This is not a limitation of the underlying javascript control, but is caused by the way the property is passed down via the ASP.NET wrapper. To understand this it is important to realize that when you use a control on a quickform, 3 different controls are actually used:

  1. - The quickform wrapper, which holds the properties that are set on the quickform editor
  2. - The asp.net wrapper, which receives the properties from the quickform wrapper (during the “Build” process of Application Architect)
  3. - The javascript control, which is responsible for the actual display in your browser

Because of the way dojo controls are declared, typically the javascript control declaration will look something like this in the HTML:

<input type='text' dojoType='Sage.UI.Controls.Currency' multiCurrency='true' required='false'>

All of the attributes on the HTML tag (except for the “type=’text’”) are not directly used by the browser, but are interpreted by the dijit. This lets us use our own custom dijit properties by using a standard textbox and adding the dojoType property as an HTML attribute, in the form’s load action – for example in this case, to specify we want to use a numeric control with up to 3 decimal places:

MyControl.Attributes.Add("data-dojo-type", "Sage.UI.NumberTextBox");
MyControl.Attributes.Add("data-dojo-props", "constraints: { places: '0,3' }");

I used the new “data-dojo-type” and “data-dojo-props” to enable better compatibility should the dojo framework be updated, but you could just as well set the “dojoType” and “constraints” attributes. The data binding should still be done in the quick form as usual, against the Text property of the Textbox. The javascript code will handle the rest of the details. Using the HTML attributes in this way will let the binding work seamlessly (if you were to instantiate those controls directly from Javascript using ScriptManager, for instance, a little bit more work would be required to ensure the databinding is preserved).

This can be used with custom javascript controls as well, though they will have to be registered first via a bit of custom javascript.