in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

Toth’s Tales from the Trenches

Practical SharePoint experience articles, tips, and frustrated rants and ravings.

May 2008 - Posts

  • Filtering Data on the MySite Profile Page (person.aspx)

    Recently, a client had a requirement to filter data on the MySite profile page (person.aspx) based on the user whose profile page you were viewing. The particular scenario the client wanted was when user Jim was looking at user Mary's profile page, Jim should see some data (from the BDC) that was filtered to only include items that Mary was involved with. The challenge here was to determine which user's profile the current browsing user was looking at, pull the UserProfile data for that profile, and then provide that data as a filter for other web parts via connections.

    It turns out this was quite easy.

    Part 1 - Deconstructing person.aspx

    The first step was to figure out how SharePoint internally knows which user you are looking at, via the querystring parameters. Person.aspx can take in several different querystring parameters to figure out which user it should display. Following are the available querystring parameters that it can take in (listed in the same order that the page checks for):

    Parameter name Description
    accountname User's account name, e.g. (DOMAIN\username)
    guid The user's guid in SharePoint
    sid The user's sid from Active Directory
    preferredname Tries to find a match based on the displayName attribute from Active Directory
    user Takes various iterations of display names or usernames and tries to resolve to a user, by redirecting to _layouts/SelectUser.aspx.

    I figured that there must be some control on that page that reads those querystring values to figure out the user. I also figured that it probably is storing that information in the HttpContext.Items collection, so that it can be leveraged by all the web parts on that page that need access to the profile information.

    I cracked open Person.aspx to see what controls are being used, and zeroed in on ProfileViewer (the control that displays Profile Property values).

       1: <SPSWC:ProfileViewer id="ProfileViewer" ShowBusinessCardIfEmpty="false" runat="server" />

    I looked up ProfileViewer in Reflector, saw that it inherited from ProfileUI, and drilled into that object. Looking in InitControl, I found this code:

       1: this.objLoader = ProfilePropertyLoader.FindLoader(this.Page);

    Bingo, a static method call to get a loaded profile. Nice. Drilling into the ProfilePropertyLoader, you discover that it is kind of a quasi-singleton, that will create a new object if it is not found in the HttpContext.Items collection, or return one that it already finds. The ProfilePropertyLoader has two properties that return a UserProfile object, ProfileCurrentUser (the profile for the browsing user) and ProfileLoaded (the profile of the user to be displayed, which may be the same as ProfileCurrentUser).

    Part 2 - Building the filter web part

    Now that I knew how to get the UserProfile object via ProfilePropertyLoader, I set about creating a filter web part, so that I could pass in filter or query values from the UserProfile to other web parts via Connections. MSDN has a great article on creating a Filter provider web part, so I followed that and added my code to get user profile values and pass those into other web parts.

       1: public ReadOnlyCollection<string> ParameterValues
       2: {
       3:     get 
       4:     { 
       5:         // Get a reference to the ProfilePropertyLoader, 
       6:         // which contains the reference to the UserProfile
       7:         Microsoft.SharePoint.Portal.WebControls.ProfilePropertyLoader loader = Microsoft.SharePoint.Portal.WebControls.ProfilePropertyLoader.FindLoader(this.Page);
       8:  
       9:         if (loader == null)
      10:         {
      11:             return null;
      12:         }
      13:         
      14:         Microsoft.Office.Server.UserProfiles.UserProfile profile = loader.ProfileLoaded;
      15:  
      16:         if (profile == null)
      17:         {
      18:             return null;
      19:         }
      20:  
      21:         string thirdPartyAppUserID = (string)profile["ThirdPartyAppUserID"].Value;
      22:  
      23:         if (string.IsNullOrEmpty(thirdPartyAppUserID))
      24:         {
      25:             return null;
      26:         }
      27:         List<string> thirdPartyAppUserIDList = new List<string>();
      28:         thirdPartyAppUserIDList.Add(thirdPartyAppUserID);
      29:         return new ReadOnlyCollection<string>(thirdPartyAppUserIDList);
      30:  
      31:     }
      32: }

    Using this approach, I was able to pass in a filter value from a UserProfile property to BDC List web parts.

  • Ontolica - Great sales team, lousy support, poor extensibility

    We've implemented Ontolica search (for MOSS 2007) for several of our customers. The product fits our service offerings very well, and provides a great value add for minimal cost and effort (compared with other search replacement products).

    The sales team has been very helpful and responsive. They've provided trial licenses quickly and without hassle, have provided training and demos/overviews of the product, and have even been excellent interfaces to help escalate support incidents. I can't really say enough about the sales team.

    I can't say that about their support however. So far, they have had just about the worst level of support I have experienced with a third party SharePoint product. If you file a support incident through their web site or via email, you are guaranteed to not get a response.

    I filed one particular support incident, never heard back from anyone, until 2 months later, when I received an automated email asking me if my incident had been resolved. Another incident received no response until I involved the sales persons, who managed to look into the issue themselves. A co-worker filed another incident, and never heard a response. I'm not even convinced they have a support team.

    Outside of the support, if you are interested in their product, keep in mind that they have very little extensibility. This can be important if you ever need to write any customized search code, and would like to take advantage of the Ontolica features in your custom search solution.

    One client of ours had a need to run searches using impersonation, so we wrote code to leverage the MOSS search web service, passing in the credentials of the impersonating account. We would have liked to have been able to pass our returned results into the Ontolica web parts (or simply have been able to use Ontolica with impersonation), but the web parts all use internal hidden search objects that are obfuscated and cannot be interacted with (unless you like deciphering obfuscated code). This made it so that we had rich search tabs with all the Ontolica features, and then our customized search tab with stripped down functionality. To be fair, my beef also lies with Microsoft for closing up their own search with the SearchResultHiddenObject, which cannot be used easily without reflection and a big level of effort. I would have thought that a product that provides such a good experience with installation and configuration would have put more thought into extensibility (and support).

    Overall I would give Ontolica 3 out of 5 stars.


Need SharePoint Training? Attend a SharePoint Bootcamp!

Posts (c) their respective authors. Everything else (c) 2007 SharePoint Experts