Alonso Robles

Andrew Connell, a SharePoint MVP, hosted two introduction to SharePoint 2010 webinars for developers over the last couple of days in conjuction with DevExpress. These were a really good concise introduction to SharePoint development. I would recommend that anyone who is interested in getting started with SharePoint development take a couple of hours to check these out.

Intoduction to SharePoint 2010 for Developers

This webinar is also available on the DevExpress Channel.

SharePoint 2010 Data Access

This webinar is also available on the DevExpress Channel.

Andrew was also kind enough to publish a wrap-up blog post with links to additional references.

Real World SharePoint 2010

I never got around to buying Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs (Programmer to Programmer) but, I did get a chance to glance through the book and there was some great material. Today, I found out that Real World SharePoint 2010: Indispensable Experiences from 22 MVPs is going to be available on November 23, 2010.

Of course, I just pre-ordered my copy.

Problem

In a MOSS 2007 installation we have a site with a wiki library. The wiki library has been customized a bit with event handlers to do some fancy automatic permission assignments to individual wiki pages and prevent some users from approving wiki pages that they are not allowed to. This was done so that every user is able to add, read, edit wiki pages but let individual identified users handle the approval of the pages in a large wiki library. These details are probably inconsequential.

The real problem is there is a single user who can can read, add, and edit wiki pages. He is also assigned to approve some wiki pages. However, when he attempts to view the history of a wiki page for approval he gets an access denied error. The history page for a wiki page in a wiki library is an application page (in _layouts directory) with the following path: http://<path to sharepoint site>/_layouts/VersionDiff.aspx?ListID=<my wiki library id>&ID=<id for the wiki page>&Source=<return path>

The user also experiences this error when clicking the link to view incoming links. The path for this page is: http://<path to sharepoint site>/_layouts/BackLinks.aspx?ListID=<my wiki library id>&ID=<id for the wiki page>

This user has the following permissions being applied:

• Site Permissions – Limited Access
• List Permissions – Limited Access
• Item Permissions – Design

This user is also part of a domain group which has the following permissions being applied:

• Site Permissions – Limited Access
• List Permissions – Contribute
• Item Permissions – Contribute

Solution

I started a thread in the TechNet SharePoint forum in hopes of finding someone who has run into this problem before. Thanks to the folks in the forums, there were a few suggestions on how to resolve the problem. Unfortunately, I didn’t have the opportunity to try most of these. But here are the suggestions:

• Delete the user from the SharePoint site and re-add the user and re-apply permissions.
• Recreate the AD account
• Assign a higher level privillege to a parent object (This is the band aid that I applied which resolved the problem)

I came across this reference in the past and I needed it again today. Took me a few minutes to find it, so I decided to save a copy of the table here on my blog:

Problem

I was working with a client with a MOSS 2007 implementation where MySites were completely disabled and making heavy use of user profiles. Eventually, we noticed that when a user clicked on a hyperlink to get user information they would be redirected to http://MySiteHost/Person.aspx?account=something (we will refer to this as the Person Page or PP).  The problem was that the client had not branded the MySites host and did not want users to navigate to it whatsoever. After some digging we found that the hyperlinks were actually linking the users to http://MySharePointHost/_layouts/userdisp.aspx?ID=### (we will refer to this as the User Info Page or UIP).

Solution

Some research showed that users navigating to UIP would automatically be redirected to the PP when the a user profile existed for the user being displayed in the UIP. After making sure MySites were in fact disabled in our production farm and reading a some posts on the TechNet forms we came across the answer. We needed to uninstall the MySite feature from the production farm in order to disable the redirection. This was easily accomplished by a simple STSADM command:

stsadm -o uninstallfeature -name MySite