THE SET UP
So I just finished this webpart for a client. I wrote a blog post about how I did this the first time around and also a blog post about what didn't work about that. Let me first set it up so you know what the client wanted and how I got there. The client wanted a web part that would display the 10 most receant hires in the company. They wanted to display the full name, the department and the hire date. I should also mention that they wanted the full name to be clickable or a link to their user profile. So I'll break it down for you in terms of things to do and then I'll show you what I did.
List of to Do Items:
1) Build Basic WebPart - Using Visual Studio 2008 you can easily create a web part project that allows you to deploy the webpart quite easily. It also creates a WSP file for you in which you can then take and deploy that to other environments. This is the easiest part!
2) Retrieve Users - Here is where it starts to get complicated. We need to make a descision about how we are going to retrieve users. I already mentioned my two past entries. So I'll be brief. There were 3 options of me to do this, I will list then with a brief description and the pros and cons of each.
UserProfileManager - This Object allows you to access the User Store in SharePoint. This is store is actually the Shared Service Provider (SSP). This is really handy because you can access this object directly and enumerate through the objects and use Linq, like I wrote about in my initial post. I would have used this method excelt for the bug that I wrote about in the second blog entry about this. Do read up on it but the short of the story is that only Administrators can enumerate through the object. This webpart needs to be accesable to viewers and contributors, so this was not a good solution.
Web.Users - The second method that was easily determined that this was not going to work is through the SPWEB object. This object is your actual site. How users are populated into this object is when each user visits the site. Or if users are added directly to sharepoint user groups or to the site itself. By default when a new user visits the site, SPWeb is then able to reference the information. Where it gets it from, I don't know but I know that you can access user information at that point. You can see how this could be handy but also not desirable in this situation since new hires might not have visited the site first.
FullTextSqlQuery - This object is quite interesting. It allows you to enter a query string that is LIKE SQL but NOT SQL syntax. I cannot stress this enough! I will show you why when I talk about the solution. The important thing to remember is that FullTextSqlQuery queries the scopes in shared service provider and not the actual user store of Shared Service Provider. This is soooooo important! When you make a change to a user profile property in SSP, or re-map it to the active directory property, you will need to do an import of user profiles AND a crawl! The crawl is what allows the Scope to be populated. The two basic scopes in SharePoint are 'People' and 'All Sites'. You can create more scopes and create rules that populate the scope. This was the clear winner considering the issues outlined in all.
3) Display Users - I used the classing yet most popular grid in SharePoint, the SPGridView, This object extends Gridview so its all really familiar in nature. If you do not know anything about the SPGridView, just google aroudn and you'll find lots of tutorilas on how to use it. It's quite rich in functionality so give it a try!
Another thing to consider when displaying viewers is that client aslo wanted that clickable link to the user profile page. I will show you how I did that.
Off to the next Post!!
Next Post
Juan