Lucy's blog

When retrieving a UserProfile via UserProfileManager in a webservice, you need to change the value for 'HttpHandlerSPWeb' in the HttpContext.Current to your web. Otherwise no profile and you will get 'Operation is not valid due to the current state of the object'. Not a very helpful message.

if (HttpContext.Current != null)
{
    HttpContext.Current.Items["HttpHandlerSPWeb"] = new SPSite(serverurl).RootWeb;
}

And don't forget to run the code to retrieve the profile with elevated privileges.

For anyone needing to query data from several lists in a site collection the CQWP is the best tool to do so. However, sometimes you just need more flexibility. So did I, I am working on a News webpart which allows for tabs and filtering per tab on, well, basically anything you could want to filter on. Plus it is all asynchronous loading with jquery.

So, I wanted to create a webservice to give me my news pages from the entire site collection. A rather cool but relatively unused way to do this is to use the CrossListQueryCache and CrossListQueryInfo. This is the class that the ContentByQueryWebPart also uses to retrieve it's data. The advantage of this class vs SiteDataQuery is that this has built in caching and audience filtering. There are a few need-to-knows though to get this to work correctly.

Basically, to get the CrossListQueryInfo and CrossListQueryCache to work isn't rocket science, you can google enough about it. a rather nice blogpost about it can be found here: http://bloggingabout.net/blogs/bas/archive/2009/03/27/using-the-crosslistqueryinfo-and-crosslistquerycache.aspx

However, to get Audience Targeting to work is another story. It seems so simple, setting two properties in your CrossListQueryInfo:

clqinfo.FilterByAudience = true;
clqinfo.ShowUntargetedItems = true;

However this will still give you results, but will not filter. The class works as follows: first it queryies the lists and retrieves the data. After this, audience filtering is applied. To filter the audience, the audience info must be present in the data. So, add it to the viewfields as follows:

string viewFields = "<FieldRef Name=\"Title\"/>" +
"<FieldRef Name=\"ContentType\"/>" +
----- snip -----
"<FieldRef Name=\"FileRef\" Nullable=\"True\"/>" +


(string.Format("<FieldRef Name=\"{0}\" Type=\"{1}\" />", 
    "{" + FieldId.AudienceTargeting.ToString() + "}", 
    "TargetTo"));

And presto, now you will have audience filtering.
Note: because the audience filtering is applied after retrieving the data, specifying an rowlimit, this will result in less results after filtering. Make sure your rowlimit is high enough to allow the necessary amount of results to show up in your webpart after filtering. This is also a bug in CQWP and there's no fix as of yet. But you can workaround it in your code.

Sounds simple enough, but note that you also want your welcome page to show when you click the library. If not visitors are directed to the list. So you must generate some content and set the welcomepage for the wiki list.

       // Create Knowledge List
       SPList knowList = ListCreator.CreateList(currentWeb, "Knowledge", null,
       SPListTemplateType.WebPageLibrary, false, false, false, true, true, false);

       this.generateWikiContent(knowList);

       // Create Procedure List
       SPList procList = ListCreator.CreateList(currentWeb, "Procedures", null,
       SPListTemplateType.WebPageLibrary, false, false, false, true, true, false);

       this.generateWikiContent(procList);

   private void generateWikiContent(SPList wikilist)
        {
            try
            {
                wikilist.ParentWeb.AllowUnsafeUpdates = true;
                SPFolder rootFolder = wikilist.RootFolder;
                SPFile wikiHome = rootFolder.Files.Add(String.Format("{0}/{1}", rootFolder,
                   "Home.aspx"), SPTemplateFileType.WikiPage);
                SPListItem wikiItem = wikiHome.Item;
                wikiItem[SPBuiltInFieldId.WikiField] = wikiHomeText; // string with your html  
                wikiItem.UpdateOverwriteVersion();

                SPFile wikiHow = rootFolder.Files.Add(String.Format("{0}/{1}", rootFolder,
                   "How To Use This Wiki Library.aspx"),
                    SPTemplateFileType.WikiPage);
                SPListItem wikiHowitem = wikiHow.Item;
                wikiHowitem[SPBuiltInFieldId.WikiField] = wikiHowText; // string with your html
                wikiHowitem.UpdateOverwriteVersion();

                wikilist.RootFolder.WelcomePage = "Home.aspx";
                wikilist.RootFolder.Update();
            }
            catch { }
        }

A while back I made a custom pagelayout for my client, with lots of content query webparts already configured and placed in their webpart zones so that on creation of a new page, everything was in place and working fine.
A few weeks later I heard that suddenly new pages created based on this pagelayout were showing up empty, no web parts were appearing on creation. However, when I checked the pagelayout the webparts were still configured and present.

After some comparison with the last working version I noticed the difference was that now the property '__webpartid' was filled.
A collegue had made a quick change to the page in SharePoint Designer, but appearantly when the page is opened in SharePoint Designer and saved again, this property is also added and filled. This is what caused the webparts not to be added on creation of a new page.

Remove the '__webpartid' property and it will work fine again. Or better yet: get your last working copy from your sourcecontrol and redo your SD changes in notepad, Visual Studio, or anything other than SharePoint Designer. SD messes with code a bit too often imho.

No techie stuff in this post, just two things I thought I would share.

First: I have been a bad, bad blogger. I will make amends and blog more often. No, really, I promise this time.

Second: I've been long due for getting my certifications for SharePoint, Two of the four available SharePoint certifications I have had since way back in 2007, but I didn't do any more ever since. As the prerequisite for attending the upcoming 'Ignite' sessions was passing 70-542 this was a good motivator to study and get the other two also.

So, now I am proud MCTS in exam 70-541, 70-542, 70-630 and 70-631. and as a bonus i figured hey, while I'm at it lets go .NET and threw in 70-536 also.

Sad part is I've lucked out and have been waitlisted for Ignite after all. boohoo.