Hi, Jeffrey,

Thanks for this detailed explanation. I should have replied long ago, as I have come to this page and reread it several times.

I realized that nowhere in the above did I ask an important question: how to request "B" (the current on-behalf-of) contact from iMIS. There are quite a few examples in old and new code for retrieving the logged in ID (L) and selected ID (S), but I don't think the B portion has ever been explicitly defined.

The docs link you gave (http://docs.imis.com/15.2/#!addingdynamicfilters.htm) suggests that B and S are the same thing, at least for IQA filters. Are they exactly the same thing in all places, or is there a different way to determine the current OBO?

--
Bruce Wilson
Director, Technology Solutions
McGladrey LLP

S can either be L or B. Commerce iParts/code call Asi.Security.Utility.SecurityHelper.GetSelectedImisIdForCart() to determine whose information to use (that method will not look in the Querystring for an ID of a user). Non-commerce iParts/code that wish to honor OBO call Asi.Security.Utility.SecurityHelper.GetSelectedImisId(). Currently, there is no method or property that will either return B, or null or empty if B has not been set.

So, I'm trying to combine this information with what Jeffrey shared before and come up with a model in my head I can work with.

It appears that GetSelectedImisId* methods all refer to the OBO if set. Therefore, when asking for S, I will get B (if set) or L (if not set) or another indicator if not logged in at all (could be blank or GUEST depending on the method I call and the params I pass). As far as I can see, the only other meaning of "selected ID" is when the ID is passed on the URL. The old definition of selected ID (a sticky value that the application remembers until you change it) is now called OBO.

It also appears that the only difference between GetSelectedImisId and GetSelectedImisIdForCart is that ...ForCart will ignore the URL param. I'm not exactly sure why that is a cart-related thing, but I'll take that as read until I need to do something with the cart.

As indicated above, feature permissions are always based on who is logged in. I would hope that Item/Entity permissions can be affected by the OBO record, so that (for example) if a person is not allowed to register for an event (no price rules exist), that the logged in user may be blocked from registering them inappropriately. (That's a separate discussion, I'm sure.)

So in summary:

- Logged in is always logged in. Nothing overrides it.
- On Behalf Of is the new name for a long-lasting selected record. iMIS will remember this ID until it is explicitly changed.
- A URL param is now used for transient selected records. It supersedes OBO without causing iMIS to forget the OBO ID. When it is dropped from the URL, GetSelected goes back to the OBO ID (if any).

So for my development purposes, it sounds like I just keep using GetSelectedImisId, and I need to decide whether it is appropriate for the URL param to override the OBO value on a case-by-case basis.

--
Bruce Wilson
Director, Technology Solutions
McGladrey LLP

... and thank you for helping to put some clarity on what is not an easy thing to grasp. I hope many others will find value in this discussion.

To reiterate what I began with in my earlier reply, OBO is specifically intended for use as a way for a privileged user to perform commerce type actions on behalf of another Party (any iPart that performs this type of action - not just the cart - should use GetSelectedImisIdForCart). Everybody else should always use the Directory find feature to lookup people and organizations (all iParts that need to respond to a selected Party should use GetSelectedImisId). The latter is one of the ways that an ID can get set in the URL.

Following this approach, you should be able to design most of your iParts to use the appropriate method based on the functionality being delivered. You should also consider whether or not any element of your iPart will navigate the user to another page where the PartyID from the URL should be passed along.

For example, in some of the recent sprints, we've seen addition of linking functionality for the Primary Organization name in the MiniProfile and the ability to navigate to a different Party by clicking a node in the GroupListEditor. In each of these cases, the target URL passes the ID. Of course, your iPart might also need to pass the same ID as it received in order to display other information for the same Party.

Finally, if I am interpreting your reference above correctly, you were suggesting that the legacy concept of Broadcast ID is now embodied in OBO. I would discourage that comparison since (as I've reiterated above) OBO is not designed to be used in quite the same way.

I haven't heard the term Broadcast ID before, so I can't tell whether I'm using it.

My original code (derived from ASI-provided examples) determined Selected ID by decrypting request.Cookies["UserID"]. More recently, I switched to using SecurityHelper.

If "ForCart" is not just for the cart, then I would suggest that it is named improperly. How about adding/exposing ignoreParamValue, much like includeAnonymousUser, as a parameter to GetSelectedImisId? This makes it easier for developers outside of ASI to see they have a choice, and to make the right choice.

It's good you mentioned this intended behavior. Most of my iParts assume that the "sticky" selected ID is available and reliable. What you're saying makes it sound like I can't expect it to be available for non-privileged (which in most cases means non-staff). Not sure if I like this, but better to know it so I can figure out what to do about it.

--
Bruce Wilson
Director, Technology Solutions
McGladrey LLP

I think Jeffrey was referring to Desktop when he mentioned the Broadcast ID.

You are correct that the SecurityHelper has replaced the functionality that was previously stored in cookies. That was the old "impersonation" model that was built into the public views. The security helper still respects impersonation if it is in use, but when it is removed one day the security helper should make that transition very smooth/invisible.

ForCart is probably really ForCommerce. Commerce/Cart iParts were the only use case we have in out-of-the-box iMIS for not respecting the ID in the URL so that's probably why we named it this way. It's funny you mention the boolean parameter because underneath that is actually how it's implemented. Maybe we should expose this as a public method and retire GetSelectedImisIdForCart one day...

And actually, we just went through some clean up on the SecurityHelper that you should see in the next release of iMIS. The only major change is that GetSelectedImisId will never return "GUEST" anymore. This was a bug in the initial implementation as it is not actually a proper iMIS ID. The other changes you will see are better API/intellisense documentation. This should make it a little more clear what results you can expect back from each of the methods.

Your idea of letting non-staff users be able to have a "sticky" selected ID is an interesting one. If you have a good use case for this I'd suggest talking to the iMIS product owners.

Cheers,
Courtney Robertson

I know you said owners, but I'll put an idea here too. The main defense I can make of the idea is that the line between staff and non-staff is getting more and more blurry. Chapter leaders often need staff-like powers, and this is starting to include committee chairs and other volunteers. CompanyAdministrator is typically used within a company but easily modified in the field to use any set of "is someone related to me" rules we choose (and we often do).

It's not a random coincidence that I mentioned the boolean parameter. Isn't reflection wonderful? :)

As a programmer, I like having direct control of the available options instead of using differently named methods which happen to match my intent. On the other hand, I appreciate and respect that it's often better for me to deal with an abstraction and not get too married to the implementation so the implementation can be changed. (Classic implementation hiding and all that.) I think it would be useful to expose this particular parameter, then through naming and intellisense, give guidance on when it is meant to be used.

Good to know about GUEST. As you might have inferred from this thread, I'm looking at how to incorporate the information from SecurityHelper into the library we use in all our projects. I'll step carefully around that pothole and try to pretend it isn't there.

--
Bruce Wilson
Director, Technology Solutions
McGladrey LLP

You mention that someday the cookies will no longer work. I'm running into a new problem with Selected ID which may be related to this.

One of my iParts uses some old IQAViewer sample code to do something magical and special with the links in the query results. When running on 15.2.5, the selected ID isn't always handled right. Here's a snippet:

	// OK Now Fun Part - We have URL - But we can not go right now - we have to set Current iMIS ID first and then GO
	// This one works VIA submit, but eventually we will fix it!
	// Apporach will be - Use PAGE METHOD
	link = new LinkButton {EnableViewState = true, Text = item[col.ColumnName].Text};

	// Call special Method to Generate COOKIES info
	string cookieName;
	string cookieValue;
	string cookieDomain;
	string cookiePath;
	DateTime cookieExpire;

	IMIS.GetSelectedIDFromCookie(userValue, Request, out cookieValue, out cookieDomain, out cookiePath, out cookieName, out cookieExpire);

	link.OnClientClick = "NavigateViaHelper('" + url + "','" + userValue + "','" + (newWindow ? "1" : "0") + "','" + cookieName + "','" + cookieValue + "','" + cookieDomain + "','" + cookiePath + "'); return cancelEvent();";

	link.ToolTip = "Click on the text to navigate. Link will open in " + (newWindow ? "a new" : "this") + " window.";
	item[col.ColumnName].Controls.Add(link);

IMIS.GetSelectedIDFromCookie is part of my library, also originally from an iParts example. It looks like this:

	public static void GetSelectedIDFromCookie(string iMISID, HttpRequest request, out string cookieValue, out string cookieDomain, out string cookiePath, out string cookieName, out DateTime cookieExpires)
	{
		Secure tool = new Secure();
		string id = tool.Encrypt(iMISID);

		cookieValue = id;
		cookieName = "UserID";

		HttpCookie httpCookie = request.Cookies["Login"];
		if (httpCookie != null)
		{
			cookieDomain = httpCookie.Domain;
			cookiePath = httpCookie.Path;
			cookieExpires = httpCookie.Expires;
		}
		else
		{
			cookieDomain = null;
			cookiePath = null;
			cookieExpires = new DateTime();
		}
	}

Finally, NavigateViaHelper (Javascript) looks like this:

	function NavigateViaHelper(url, IDValue, windowstatus, CookieName, CookieValue, CookieDomain, CookiePath) {
		//// Now Check for mode then set cookie and navigate
		// We Only Set Path and Value
		document.cookie = CookieName + '=' + CookieValue + ';' + ' path=' + CookiePath + ';';
		if (windowstatus == "1")
			window.open(url);
		else
			window.location = url;
	}

(Lots of unused variables there, but I will disclaim any fault for code I didn't write.)

So, if the cookie is no longer being used for selected ID, I will have to modify this area of code which I don't fully understand to do things another way. If the cookie *is* still used, then maybe I'm looking at some changes in the stock Javascript which are interfering with the existing code?

Any suggestions appreciated.
--
Bruce Wilson
Director, Technology Solutions
McGladrey LLP

Hi Bruce,
Did you get any more feedback from ASI on this. We have a similar problem having just upgraded to 15.2.15 where Request.Cookie["iMISID"] no longer works.
substituting SecurityHelper.GetSelectedImisId returns the currently logged in user not the selected user which I suspect points back to your discussion above.
Any comment greatly appreciated. We are trying to do this in Desktop iMIS.

Thanks
Keith Robertson
MAST-ICT Ltd
UK

I haven't heard back yet. What you see above is about all I know on the subject. Sorry.
--
Bruce Wilson
Director, Technology Solutions
McGladrey LLP