In SharePoint 2007, there was one list customization I had to do more than any other. A stakeholder would have a custom list, with a user field, and they would more often then not, want some profile fields to display in the list. So that they could filter the items by those profile fields. Things like State, or Office Location.
What i eventually had to do in SharePoint 2007, was kind of hacky, and really annoying to implement. Say if the user wanted the Office to be displayed in each row, i would create the Office field in the list definition as a Person field. Then make an event receiver, that on ItemAdding, would update the Office field to be the same user in the normal Person field, but instead of displaying the Name, i would display the user profile field that the stakeholder wanted.
So with multiple columns, i would end up with something like this:
[image]
But with SharePoint 2010 this problem goes away. Enter list joins and projected fields. What this allows is having one list, and showing value from a joined list. Things did not go as smoothly as i hoped though.
So i went into the column create screens and cycled through the different field types. I was disappointed that the person field did not have what i wanted. Only the lookup field type had the projected fields. Well i could live with that, but it would not be the ideal solution. Because you would not be able to make use of the people picker, it would just be a very large dropdown.
But when i went to assign the lookup table to the hidden "User Information List", well, it was hidden. This list if you dont know, holds a copy of the user profile fields marked as replicatable. Sharepoint takes care of keeping it in sync with the values in the SSP or Application Service.
I suspected that while it was hidden, i could still make the join, just not through the interface. So i went hunting from some scripts, preferably powershell to create this projected fields. I found them on msdn, and it looked pretty straight forward. It got me thinking.
Hang on though, a person field is just a lookup field, so i could go back to my orignial plan of joining the custom list to the "User Information List", but using a Person field instead of a lookup.
To my shock, everything work out as i had hoped for since the start. Effectively i have reduced a days work of hassle and deployment, to a few lines of powershell.
Scripts and screen shots to come later.
