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.
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.
var strTabName = "Person"; //tabgroup name to be used.
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).
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.
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?
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.