SharePoint Blogs

Today we encountered this error at our current client location too. We were able to deploy forms to basic site collections but not able to deploy to certain site collections that fell under the following path format: http://servername/sites/sitecollection or the custom url: http://customurl/sites/sitecollection Didn"t make much sense, we had activated all the necessary features and the Form Server components were properly installed. Finally we found a difference between a site collection where it...(read more)

I have created the following article page, this has a step by step guide to creating a Site Column using a feature. The feature is deployed using a Solution Package.

 http://www.sharepointblogs.com/martinbailey/pages/create-a-site-column-using-a-feature-deployed-via-a-solution-package.aspx

I figured out how to add additional fields from the Profile Import into the People Search today.

This requirement occured to me after discussing how this might be done with Aaron Saikovshi at the APAC SharePoint Conference.

In this particular case, I wanted to add one of the extended properties from the Exchange Users into both the Search Box control and the results page. I suspect, but have not confirmed that this process would work for extensions to the AD Schema too.

There are several steps to make this happen:

1. Assuming that you have a property with data in it, go to the Shared Services Administration page and click on "User Profiles and Properties" link.

2. Add a new Profile Property for the property you want to include by clicking the "Add profile property" link at the bottom of the page. The things to pay attention to are the policy settings (properties will need to be available to all those who need to see them!) and the Property Import Mapping (you need to map your property to a physical property crawled by the indexer - just like Managed Properties in MOSS Search - which is actually what this property becomes). In the case of my Exchange extended property this was extensionAttribute1.

3.  At this point I did a full import, just to make sure I could see the values coming through when I viewed the user profiles.

4. Go to the people search page in the Search Centre (or wherever you put the people search). Edit the page and then edit the properties of the People Search Box. Open the Properties property and add a new Property element to the list, eg:

<Property Name="NewProp" ManagedName="NewProp" ProfileURI="urn:schemas-microsoft-com:sharepoint:portal:profile:NewProp"/>

where NewProp is the name you gave to the new Profile Property above.

5. In the Results Query Options section of the properties for the People Search Core Results web part, edit the Selected Columns property. If your default value is like mine, it will look like there is nothing in there - which tricked me for a while, but click the ... button and add a new Column element for your property equal to the name of your new Profile Property.

6. Edit the Data View Properties of the People Search Core Results web part to add the new column (in lower case), somewhere in the XSL eg. <xsl:value-of select="newprop"/>. Click Apply and Publish (if you have content management turned on). Don"t worry if you get a nasty looking error in the web part unless it happens after you publish! You did backup the XSL before you modified it, right?!

I also had to do some crawling of the Content Sources once I had added the new Property and at one point had to reset and re-crawl. I think there is something strange going on there, because the first property I added only seemed to require a Crawl to be available, but the second would no work as a Selected Column until I reset and re-crawled! I"m not 100% on what requires what level of crawling. I can understand a full crawl being required for new properties because that probably updates the property store, but a Reset Crawled Content?!

If anyone has, or tries to get this working with a custom Active Directory column it would be great to know and complete the puzzle!

 

As promised, here is part 1 of my user management tutorial:

http://www.sharepointblogs.com/dooke/pages/part-1-importing-user-profiles.aspx

Duh... the "Hello World" of blog posts, I guess.

I"ve decided to throw my hat into the mix of tech blogs as I"ve had difficult times trying to find answers to many questions. SharePoint 2007 has many new capabilities (can"t say features since that"s now a reserved word! ) and I keep having to figure most of it out myself since either no one has done it or no one has publicly documented it. Most of my posts will be about SharePoint 2007. I may occasionally sneak in a SharePoint 2003, general .Net, or other technology post, but those will probably...(read more)

Ok, I"ve seen TONS of posts where people are having issues attempting to get their Quicklaunch or side navigation to use flyouts, and I was one of them until 4:30pm today. The issue is not stylesheets or code, but literally just the config of the /folder/sharepoint.htm:AspMenu. In order for this to work, you"ll have to create a new master page or edit the default one.

By default, here"s how the menus are config"d (this is for the top navigation)

 <SharePoint:AspMenu
   ID="TopNavigationMenu"
   Runat="server"
   DataSourceID="topSiteMap"
   EnableViewState="false"
   AccessKey="<%$Resources:wss,navigation_accesskey%>"
   Orientation="Horizontal"
   StaticDisplayLevels="2"
   MaximumDynamicDisplayLevels="0"
   DynamicHorizontalOffset="0"
   StaticPopoutImageUrl="/_layouts/images/menudark.gif"
   StaticPopoutImageTextFormatString=""
   DynamicHoverStyle-BackColor="#CBE3F0"
   SkipLinkText=""
   StaticSubMenuIndent="1"
   CssClass="ms-topNavContainer">
  <StaticMenuStyle/>
  <StaticMenuItemStyle CssClass="ms-topnav" ItemSpacing="0px"/>
  <StaticSelectedStyle CssClass="ms-topnavselected" />
  <StaticHoverStyle CssClass="ms-topNavHover" />
  <DynamicMenuStyle  BackColor="#F2F3F4" BorderColor="#A7B4CE" BorderWidth="1px"/>
  <DynamicMenuItemStyle CssClass="ms-topNavFlyOuts"/>
  <DynamicHoverStyle CssClass="ms-topNavFlyOutsHover"/>
  <DynamicSelectedStyle CssClass="ms-topNavFlyOutsSelected"/>
 </SharePoint:AspMenu>

The two properties we are interested is are the following 
   StaticDisplayLevels="2"
   MaximumDynamicDisplayLevels="0"

To get flyouts to work, you need to set the StaticDisplayLevels to ONLY 1 and MaximimDynamicDisplayLevels to 1 or more than one depending on how confused you want your users to be :-)
   StaticDisplayLevels="1"
   MaximumDynamicDisplayLevels="1"

Soooo...here"s the final product:
 <SharePoint:AspMenu
   ID="TopNavigationMenu"
   Runat="server"
   DataSourceID="topSiteMap"
   EnableViewState="false"
   AccessKey="<%$Resources:wss,navigation_accesskey%>"
   Orientation="Horizontal"
   StaticDisplayLevels="1"
   MaximumDynamicDisplayLevels="1"
   DynamicHorizontalOffset="0"
   StaticPopoutImageUrl="/_layouts/images/menudark.gif"
   StaticPopoutImageTextFormatString=""
   DynamicHoverStyle-BackColor="#CBE3F0"
   SkipLinkText=""
   StaticSubMenuIndent="1"
   CssClass="ms-topNavContainer">
  <StaticMenuStyle/>
  <StaticMenuItemStyle CssClass="ms-topnav" ItemSpacing="0px"/>
  <StaticSelectedStyle CssClass="ms-topnavselected" />
  <StaticHoverStyle CssClass="ms-topNavHover" />
  <DynamicMenuStyle  BackColor="#F2F3F4" BorderColor="#A7B4CE" BorderWidth="1px"/>
  <DynamicMenuItemStyle CssClass="ms-topNavFlyOuts"/>
  <DynamicHoverStyle CssClass="ms-topNavFlyOutsHover"/>
  <DynamicSelectedStyle CssClass="ms-topNavFlyOutsSelected"/>
 </SharePoint:AspMenu>

For the quicklaunch, simplly change the same properties.
Hope this helps someone out there, what a great way to go into the weekend!
-Eben

Recently someone emailed me asking if there was a way to find out what content types various lists and libraries were using in MOSS2007. After a little investigation I decided to write some C# code. If you take a look at the object model you will notice that you have hierarchy that you can traverse down to find this information. In the code I have used I am using the following:

SPSite Class – The root Site (Portal)

SPWeb Class – To get details about the current site (Portal)

SPWebCollection Class – List all sub sites that exist at the current parent site (Portal)

SPListCollection Class – List all the Lists and Libraries within the various sites under the portal

SPContentTypeCollection Class – List all the content types that are associated with the selected list

 

As you can see there is a very nice structure available for us to traverse down. The code is not the most elegant and has no error handling and I am sure there are better ways to write it but you get the idea. I created a test console application for this to simply output to the screen. Anyway the code:

SPSite siteCollection;

SPWeb webSite;

static void Main(string[] args)

{

GetCurrentMOSSContext(args[0].ToString());

}

static void GetCurrentMOSSContext(string PortalURL)

{

siteCollection = new SPSite(PortalURL.ToString());

      webSite = siteCollection.AllWebs["/"];

 

      System.Console.WriteLine(webSite.Url.ToString());

}

 

static void GetAllSubSitesListsAndContentTypesUnderContext()

{

SPWebCollection subSites = siteCollection.AllWebs;

 

for (int i = 0; i < subSites.Count; i++)

{

System.Console.WriteLine(“...” + subSites.Title.ToString() + “ – Site”);

 

            SPListCollection lists = subSites.Lists;

            for (int j = 0; j < lists.Count; j++)

{

System.Console.WriteLine(“......” + lists[j].Title.ToString() + “ – List”);

 

                  SPContentTypeCollection types = lists[j].ContentTypes;

                  for (int k = 0; k < types.Count; k++)

                  {

System.Console.WriteLine(“.........” + types[k].Name.ToString() + “ – Content Type”);

                  }

}

}

}

 

As you can see the code is very simple and works like a treat. Be aware that this code only works for root site collections. You would need to change it to make it work when trying to check a site collection that had the following format of URL: http://[Server]/[Sites]/[Site]

Once it is run the output is simliar to this:

http://intranet.labs.local

....Document Center - Site

........Announcements - List

............Announcement - Content Type

............Folder - Content Type

........Documents - List

............Document - Content Type

............Folder - Content Type

........Master Page Gallery - List

............Master Page - Content Type

............Folder - Content Type

........Tasks - List

............Task - Content Type

............Folder - Content Type

 

Anyway hopefully you get the idea.

Dentro del Community Kit para SharePoint se provee un webpart para un "chat" (ChatterBox webpart --download) que básicamente almacena el nombre de usuario (o nick) y el mensaje que deja en una lista de SharePoint (bastante simple y últil en realidad).

 

(imagen tomada del post original)

Estuve haciendo pruebas y al parecer el webpart NO funciona en sitios habilitados con WCM (publishing feature). Es decir, se puede agregar el webpart y luego de configurarlo funciona perfectamente hasta el momento en que publico la página, donde deja de funcionar. Esto fue confirmado por el  Matt Swann del SharePoint Team como podrás ver en los comentarios de este post.

No me pasó lo mismo con un sitio WSS (sin WCM), donde sí funciona perfectamente, aunque si salgo del sitio y luego regreso, tengo que reconfigurar el webpart (específicamente volver a colocar mi nick) para poder seguir utilizándolo.

 Conclusiuón: el webpart es magnífico pero no funciona con sitios que utilicen WCM.

-.M.-

This post describes an issue we were having using the SharePoint PageFieldFilter webpart in combination with a Lookup field. First the issue is explained, then a solution is provided.

The issue

In our intranet we were setting up a product catalog. The documentation for the products are stored in 1 document library. This doclib has a (multivalued) lookup field to the products list. We wanted to create 1 page per product in the same publishing site. This page will the the landing page for a product. It will show general information and the available documentation. To do this we added a lookup field to the Pages library to the same product list and added the PageFieldFilter webpart to the page. Turns out this does not work for a lookup field (the same applies to a user/group field).

Here is how you recreate this (it also shows the reasons why it doesn’t work):

• Create a Publishing site
• Create a list “Products” and add some items
• Create a document library “Documentation” and add some documents
• Add a (multivalued) lookup field to the document library
• Select product(s) for the documentation:
  
• Add a (singlevalued) lookup field to the Pages library
• Add a new page and select one of your products:
  
• Add the “Documentation” library to the page and show the name and product fields.
• Add the Page Field Filter webpart to the page and select the “Product” field.
• Connect the filter webpart to the Documentation list.
• Check-in and notice that the list shows no documents:
  

The filter webpart does not provide the correct value to the consuming webparts. In the screenshot below you will see why.After adding a TextFilter webpart to the page, you can set the default value for this text filter from the Page Field Filter webpart.

This shows our problem; the value is not the title of the selected item, but it is the value that SharePoint uses internally to store the value. This applies to both Lookup and Person or Group fields.

The solution

The solution for this is to build our own custom Page Field Filter webpart. You can do this by creating a new webpart that inherits from the ContextFilterWebPart in the Microsoft.SharePoint.Portal.WebControls namespace. Below I describe the most important bits to include in your code. My webpart is called “WebpageFieldFilter”.

• Create a private member and a property of type Guid (called “PageFieldID”)
• Create a new EditorPart that renders a dropdown showing all field in the pages library. These fields can be added directly from the context:
  

         SPContext.Current.List.Fields

  Also implement the ApplyChanges and SyncChanges methods:
  

      public override bool ApplyChanges()

      {

          WebpageFieldFilter webpart = WebPartToEdit as WebpageFieldFilter;

          webpart.PageFieldID = new Guid(_selectField.SelectedValue);

          return true;

      }

      public override void SyncChanges()

      {

          EnsureChildControls();

          WebpageFieldFilter webpart = WebPartToEdit as WebpageFieldFilter;

          _selectField.SelectedValue = webpart.PageFieldID.ToString("B");

      }

• Implement the IWebEditable interface on your webpart. Implement CreateEditorParts. This should return the new EditorPart we just created, but also the EditorParts that are generated by the base webpart, otherwise we won’t have our filter options:
  .cf { font-family: Courier New; font-size: 9pt; color: black; background: white; } .cl { margin: 0px; } .cb1 { color: teal; } .cb2 { color: blue; }

      EditorPartCollection IWebEditable.CreateEditorParts()

      {

          List<EditorPart> newEditors = new List<EditorPart>();

          EditorPartCollection editors = base.CreateEditorParts();

          foreach (EditorPart part in editors)

              newEditors.Add(part);

          newEditors.Add(new SelectListFieldEditor());

          return new EditorPartCollection(newEditors);

      }

• In the webpart class, override FilterConfigured and return true if our PageFieldID has a valid Guid value.
• In the webpart class, override DesignTimeHtml to return the correct text for your webpart in design mode.
• Override GetRawFilterValues to return the values for the field that was chosen by the user:
  

      protected override string[] GetRawFilterValues()

      {

          SPListItem listItem = SPContext.Current.ListItem;

          if (listItem != null && PageField != null)

          {

              SPField field = SPContext.Current.List.Fields[PageFieldID];

              return GetFieldValues(listItem[PageFieldID], field);

          }

          return null;

      }

  In GetFieldValues I implemented the code to extract the value for the lookup and user field and return a string array with the value or the values in case of a multi valued field. You can find the code to do this in the ZIP file (see attachments).

After installing the webpart, you can add the new WebpageFieldFilter to the page and connect that to the Documentation library. When modifying the properties of the webpart, things look a bit different, because of the implementation of our custom EditorPart:

And when we look at the page, the documentation is now filtered as expected:

The webpart also works if you add a multivalued lookup field to the Pages library. It then provides all selected products in a string array to the consuming webparts. When I was testing this it looked like handling these multiple valued filters was not always correct. I’ll investigate this a bit further.

Enjoy!

You can find a WSP file containing a working version of the webpart. If you don’t know what to do with a wsp file, start looking at Chris Johnson’s blog, or use the SharePoint Solution Installer. Attached to this post, you will also find the full code for the webpart. Both are in the same ZIP file. Do whatever you like to do with them, but please let me know if you use them and what you think of it. Might give me some ideas to improve it. Enjoy!