Our users require multiple windows of Sage CRM. The scenario is this, a user will be working in an opportunity adding a long note or other record, the telephone rings, and they need to go into another opportunity whilst leaving the first active. They will need to deal with this call, add a note to the other opportunity, before returning to their original long note on the first opportunity.
Now, Sage CRM 2018 R3 does allow users to duplicate windows (older versions used to kick out additional windows), and our users have discovered this and are using it, however, as its unsupported, CRM gets into a pickle and can end up updating incorrect records. So in the above, the first, long note, might end up going against the SECOND opportunity as CRM has lost the sessions context.
The business has told us, unequivocally, that users need to have multiple windows to allow multi-tasking. Both windows must be able to change data and move around the system changing context. Simply saying it is unsupported will not change the business requirement, they will just require us to bin Sage CRM and change systems. So how can we go about this?
Are we missing any other trick here? A readonly, model pop up box (as described by the great Jeff Richards here: https://community.sagecrm.com/partner_community/b/hints_tips_and_tricks/archive/2018/08/23/can-you-open-tabs-in-new-windows.aspx) will not satisfy the business requirement.
Are you getting the custom entity's ID from "Key58" in the URL? If so, this may be one of the issues. For custom entities, I normally ignore Key58 as much as I can and use a custom "ent_entityid" key in the URL instead.
Are you using "CRM.GetContextInfo" anywhere? This may also return values you don't want.
Maybe re-setting the context in a validate script on one of the relevant screens would help when saving? (CRM.SetContext("opportunity", oppoIdToActuallySave))
So with the multiple windows, are you suggesting it can be used safely if coded defensively?
In theory, as long as you avoid "context" as much as possible (e.g. only take the URL and posted form values into account, probably best to avoid "Key*" keys in the url as much as possible), however I have not had this requirement before so I haven't exactly done any thorough testing. You are pretty much guaranteed to have issues with "TopContent" and anything involving context, especially on built in entities which you have minimal control over.
Okay, so programming defensively we have had some success. All custom entity asp will look to the query string and xxxx_xxxxentityid and so will correct its stuffed context on postback. However, this doesn't work so easily on documents and communications. These appear to look at session context no matter what we do. We will do some more testing. Do you have any experience with making these tabs on custom entities context safe?
Afraid not, the only sure way to solve the issue is to rewrite the pages from scratch in a way that they don't read context.
© The Sage Group plc 2019All Rights Reserved