Changing Context when jumping between pages using the COM ASP API

Hints, Tips and Tricks

Technical Hints Tips and Tricks that cover customization and development using Sage CRM. API usage and coding are covered.

Changing Context when jumping between pages using the COM ASP API

  • Comments 4
  • Likes
 I have created a very simple page that contains a couple of buttons. The starting page is an ASP page in the context of the Opportunity. These buttons will allow me to jump to different places in the application. The first "company" button jump is built using

var strCompanyButton = CRM.Button("Company","findcompany.gif", CRM.Url(200));

The button when pressed will call the internal CRM action 200. This is the companysummary action and it will automatically change contexts and ensure that the correct information is displayed in the top content area.

If I wanted to call an ASP page I can do this from a button using

var strCustomButton = CRM.Button("CustomJump","myimage.gif", CRM.Url("custompage.asp"));

But this assumes the jump is taking place within the same context. The topcontent detailing the opportunity would not change and, unless I explicitly called the correct tab group in the destination page, the opportunity tabgroup would still be used.

This is because context is determined by the name/value pairs in the querystring that is passed to the eWare.dll. The CRM.URL() method when used on an ASP page builds the URL needed to maintain session but keeps the current context.
Below is the result of my custom Person jump and we can see here the topcontent and menus are all correct and even the "Testjump" tab has been correctly highlighted.

I made sure that this was the case by controlling the context myself.

The code behind the button looks like:

var strSID = new String(Request.QueryString("SID"));
var intDominateKey = 2; //person is the new target context
var intKey1 = 28; //unique id of target company
var intKey2 = 30; //unique id of target person
var strFileName = "testjump.asp"; //target file
var strTabName = "Person"; //tabgroup name to be used.
var strTarget = "http://localhost/CRMdemo/CustomPages/testjump.asp?SID="+strSID+"&Key0="+intDominateKey+"&Key1="+intKey1+"&Key2="+intKey2+"&J="+strFileName+"&T="+strTabName;

var strPersonButton = CRM.Button("Person","findperson.gif",strTarget);

I hardcoded some of the values above. In the real world the values would be derived from the existing context. Hopefully the comments make it clear what needs to be changed. The most important part is the change in the dominate key (Key0).

Other useful articles:

Key Values in URLs

  • Jeff, I've just used this on  7.3SP3 system and it works fine except....

    On one of my Company tabs I have SQL restriction: comp_type='Customer'

    When I jump to the company the correct context and tab is shown BUT I get an error:

    tabsql: Select NBQU_NBQuoteID from NBQuote WHERE NBQU_NBQuouteID = 3381 and (comp_type='Customer')

    3381 is the ID of my company. If I remove the SQL against the tab it's OK but I see a tab I shouldn't as my company is a 'Prospect'

    Any ideas?



  • Roger

    All pages have to be requested with a URL.  The question is how can we request a company summary page that has a tab restriction.  If the target page 'testjump' in the example above, is the tab that is restricted, then I am not sure we can do anything in the URL.  But if this is a custom page then we may be able to trap the error in an exception (try, catch).

  • Jeff:  I seem to be having the same issue as RBC.  I was actually reviewing this article to make sure that I am getting my URL correct for a button on the case summary screen that returns the user to a Property primary entity.

    After creating a case (work order), I needed a way for the user to return to the property that the case was created for.  Cases are only being created from the property entity so that the associated property id can be assigned to the case.

    During the creation/testing of the button, I kept getting an error related to the tabs and I was able to determine that the error was due to the SQL restriction that RBC describes.  I was trying to return the user to the cases tab on the property entity.  There was a SQL restriction on that tab based on the stage of the property.  I removed the restriction and thought I would be good.  However, I still got the error.  As I discovered, it does not matter which tab I returned the user to, the system will throw an error if ANY of the Property tabs have an SQL restriction.  Therefore, I had to remove all the SQL restrictions in order to get the button on cases to work correctly.  

    However, I cannot leave it that way.  I know there are at least 10 tabs that have restrictions as some only display during the Acquisition stage and some during the Ownership stage.  Right now all tabs are displaying no matter what stage but I really need to get these back to how they were before the button on the cases was requested.

    I don't see any other boxes on the tab screen that might allow a different way to restrict the display of the tab.  Is there any other way to restrict the display of the tab (i.e. somewhere other than the tab screen?)

    Also, in your reply to RBC, you recommend using a try/catch in the ASP page.  I am assuming this will allow the system to ignore the error and proceed to the page.  How might this try/catch look?  Is there an example you can point me towards?  

    Any assistance would be greatly appreciated!  Thank you!

  • I think we need to look at the URLs and how they are being formed.

    The SQL Tab Clauses use the either the context of the user (basically the SID variable in the URL determines this) or it is determined by the entity in context.  This is determined by the value of the dominant key.

    The SQL log should contain a hint as to how the SQL related to the tabs is being malformed.  This is if it thinks it is addressing the wrong entity or is not finding the key value.

    But a side by side comparison of a 'working URL' that allows the page to be displayed with the working SQL Tab Clauses and one that is generated by the ASP page and contains the errors should allow you to identify how the error-generating URL should be changed.