Ben There, Done That

Another SharePoint 2007 development post from the non developer, so feel free to offer any suggestions and comments around my code as I’m still learning.  I know, I should be doing this on SharePoint 2010.  Trust me, I’m trying to get us there.

Anyways, a brief background on what I’m trying to accomplish. I’m working on a navigation solution for our current intranet that queries a list of SharePoint sites that have been requested, approved and created via our site request process.  The query results are then filter based on if the current user has access to the site.  This list contains variety of sites, site collections and sub-sites that are spread out across 3 different web applications.  The solution then displays those sites in a web part for users to have “quick access” to their collaboration sites.  It’s basically a way to provide navigation (contained in a web part) across site collections and web applications automatically off a list of sites.

In order to check for access I decided to use the DoesUserHavePermissions() function.  However, after writing this function:

private bool UserAccessToSite(String user, SPWeb testWeb, SPSite testSite){
    bool access = false;
    try{
        access = testWeb.DoesUserHavePermissions(user, SPBasePermissions.EmptyMask);
        return access;
    }
    catch{
        access = false;
        return access;
    }
}

I was getting the following error stating that the “List does not exist”

I tried a variety of different approaches just to get it to return false if the user has Access Denied to the site.  After a bunch of different tries and some searching online, I ran across this post by Krichie that solved the problem for me.

Right before checking DoesUserHavePermissions I had to add the line SPSite.CatchAccessDeneidExceptoin=false;

So, the final code that is now working is:

private bool UserAccessToSite(String user, SPWeb testWeb, SPSite testSite){
    bool access = false;
    try{
        testSite.CatchAccessDeniedException = false;
        access = testWeb.DoesUserHavePermissions(user, SPBasePermissions.EmptyMask);
        return access;
    }
    catch{
        access = false;
        return access;
    }
}

My web part is now configured in order to query the list and only return a link to a SharePoint site if the user currently logged into SharePoint has access to that site.  I still have some work to do on the web part and the rest of the solution, so as I continue this adventure I’ll try to post any other updates.  Who knows, maybe once I finish it I’ll even post the whole solution up here.

Again, feel free to correct my code or offer other suggestions as I continue to delve into the SharePoint development space.

We have been having an issue with our search indexing and crawling in one of our SharePoint farms.  The problem is that after an undetermined set of time, pretty much all search queries wind up returning several results that show nothing but an IE icon.  The result isn’t attached or any page or give any textual information.  Obviously best case would be to figure out what causes this error, but at this point in time we haven’t been able to find the problem.

However, what we have discovered is that simply resetting the search index and running a full crawl will solve the issue.

So…until we can solve the issues, I wrote a small SharePoint timer job that simply resets our search index right before a scheduled full crawl runs.  I used Andrew Connell’s post (http://www.andrewconnell.com/blog/articles/CreatingCustomSharePointTimerJobs.aspx) to develop the Timer Job, Solution and Feature and modified it and was able to find the following code on http://www.sharepointdev.net/sharepoint–development-programming/programmatically-reset-all-crawled-content-41959.shtml that I inserted into the timer job frame work in order to automatically reset our index on a regular schedule to minimize the risk of our search issue effecting the end users.

try
{
    SearchContext sc = SearchContext.GetContext(ServerContext.Default);
    sc.Reset(true);
}
catch (Exception ex)
{
    throw new InvalidOperationException("Unable to reset content index.", ex);
}

For some of you, this may not seem like much, but coming from the SharePoint Administration/Configuration side of SharePoint and having very little real development experience I was rather proud of myself.