Signature Sterling

There's been much published about how to achieve a 1-many relationship using SharePoint lists such as this one (one parent to multiple children). This method works great for exhibiting master/detail-type relationships. However, I was tasked with generating a knowledge base list to which our internal IT professionals could publish content and reference for information related to various server records within our SharePoint server list for troubleshooting or informational purposes. Since any single server record could have multiple related knowledge base articles, and any knowledge base article could potentially apply to multiple server records, I needed to emulate an (automated) many-to-many relationship between the server and knowledge base list. Given the limited resources available describing how to achieve this behavior, I decided to post my solution.

My task called for a ‘Knowledge Base’ column within the server list which would contain a hyperlink to a page displaying all of the knowledge base articles pertaining to that particular server record. Here’s how I achieved such behavior:

1. Create a multiple-value look-up column within the knowledge base list to server record values.
2. Create a KnowledgeBase.aspx page (within SharePoint Designer) and drag/drop a knowledge base list onto the page. (See the article above for more detailed instruction).
3. Add a data view parameter to the list called ‘ServerQS’ with value ‘ServerID’.
• Select the list within the design view
• Click the grey box with the ‘<’ symbol that appears to the right of the list (to access Common Data View Tasks)
• Click ‘Parameters’
• Click ‘New Parameter’
• Enter ‘ServerQS’ for the parameter name
• Select ‘Query String’ as the parameter source and enter ‘ServerID’ as the query string variable.
• Click OK

4. Filter the Data View by using the ServerID query string value:
• Navigate to the Common Data View Tasks pane again.
• Select ‘Filter’
• Check the ‘Add XSLT Filtering’ box and click the associated ‘Edit’ button.
• Choose ‘All’ from the ‘Select a function category:’ dropdown.
• Select the ‘contains’ function, you should see the textbox above populate with your selection.
• Expand the dsQueryResponse > Rows > Row tree in the left-hand navigation and select the server look-up column created earlier (I called mine ‘Network Appliance Hostname’).
• Paste ‘$ServerQS’ as the second parameter in the contains() function within the textbox.
• Click OK.
• Save/publish your page.

5. Test your reference page:
• Create a new knowledge base article and select arbitrary server look-up values.
• Visit your new page URL providing one of the look-up values as a query string parameter: KnowledgeBase.aspx?ServerID=TestServer.
• Confirm your newly created knowledge base articles are displaying.
*Note: The ‘Common Data View Tasks’ pane also provides a plethora of formatting settings for the result set such as sorting, grouping. In addition, the ‘Change Layout’ option, ‘General ‘ tab contains a toolbar option allowing users to dynamically implement their own sorting, grouping, and filtering preferences within the page.
6. Add the knowledge base hyperlink (look-up) column to the server list:
• Create a calculated column within the server list.
• Provide the following formula, where ‘ServerListNameColumn’ equals the name of the column used to uniquely identify your server records (and the value provided as the ServerID query string parameter).

=("https://pvhome.pv.com/Departments/IT/PV%20Share%20Documents/KnowledgeBase.aspx?ServerID="&ServerListNameColumn)

Upon import of a user's profile (from AD), the user is still not recognized as a 'bonafide' SharePoint account until they actually login (authenticate) to the SharePoint site. Consequently, if you're attempting to write code that iterates thru a group of users and programmatically sets their profile image - that code will fail for any user who has not logged into the SharePoint site (and will throw the infamous 'User Cannot Be Found' exception). I stumbled onto this issue when working with a new MOSS site, so most users had not yet logged in. I resolved the issue by calling SPWeb.EnsureUser(username) - (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spweb.ensureuser.aspx) before attempting to access the user object. This method requires elevated permissions to run.
Happy Coding!

1. Generate images for web part corners - I used http://www.roundedcornr.com.
2. Copy/paste the following JavaScript content into a text editor - RoundedWebPart.js (2.20 kb)
3. Replace the following corner image URL's with paths to your newly generated corner images (ensure your users have 'read' privileges to the images' location)
   • /Shared%20Pictures/Top_Left_Corner.png
   • /Shared%20Pictures/Top_Right_Corner.png
   • /Shared%20Pictures/Bottom_Left_Corner.png
   • /Shared%20Pictures/Bottom_Right_Corner.png
4. Replace the '#f3de96' color with the value of your images' color
5. Add a Content Editor Web Part to the SharePoint page
6. Modify the Web Part and paste your modified JavaScript text content into the Source Code Editor

Check the content editor's layout 'Hidden' property to prevent it from displaying with a rounded corner background.

I felt compelled to blog on this topic since I had a heck of a time finding any decent documentation on it. What finally pointed me in the right direction after hours of hunting was this random info nugget.

Here's what I had: A dashboard/portal page with operable web part per-user personalization. However, I have multiple roles within my site (not using Asp.net built-in roles, but my own custom provider). When users hit my dashboard page, their role was variable depending on the query string parameters present. Sometimes users should see certain web parts and other times be limited to other web parts. So what I needed was a way to dynamically evaluate within the code-behind whether to actually display a web part contained within that user's aspnet_PersonalizationPerUser record entry.

Thank-you, WebPartManager.AuthorizeWebPart event:

protected void MyWebPartManager1_AuthorizeWebPart(object sender, WebPartAuthorizationEventArgs e)
{
if (!String.IsNullOrEmpty(e.AuthorizationFilter))
{
if (e.AuthorizationFilter.ToString().Equals("Admin"))
{
if (UserIsAdmin())
e.IsAuthorized = false;
}
else if (e.AuthorizationFilter.ToString().Equals("Student"))
{
if (UserIsStudent())
e.IsAuthorized = false;
}
}
}

Now to populate the web part AuthorizationFilter attribute appropriately. This is fairly straight-forward if you're declaratively adding web parts to your CatalogZone and/or WebPartZone, simply add the AuthorizationFilter attribute into the declarative web part statement. However, if like me you're dynamically populating a DeclarativeCatalogPart using the WebPartsListUserControlPath property - you'll need to add the attribute to your user control declaration within the WebPartsListUserControlPath file:

<%@ Control Language="C#" AutoEventWireup="true" CodeFile="AdminWebParts.ascx.cs" Inherits="AdminWebParts" %>
<%@ Register TagPrefix="uc" TagName="adminuc" Src="~\AdministrationUC.ascx" %>


Once the attribute is added to the user control declaration, you should be able to access its value (if any) within the WebPartManager.AuthorizeWebPart event. One little gotcha to keep in mind when working with personalization and web parts. If you've already added web parts to the profile of an existing user prior to making the changes described here, the attribute won't exist. You need to delete all existing web parts within that user's profile, and add new ones after you've added the relevant AuthorizationFilter attribute.