How to store user-specific data in SharePoint

Question

I have some user-specific data that I need to store in SharePoint and make accessible to the user through custom webparts. Let's say a list of favorite URLs. What would be the most straightforward way to store this information?

• Some builtin propertybag for SPUser or similar that I'm not aware of.
• SPList, associated through User column.
• Custom database table, associated through SPUser ID.
• Otherwise?

Sounds like a RTFM to me, but I'm probably asking google the wrong questions.

[Update]

We eventually stored this information in a simple list, in a fixed location, with a Person field to filter on. Perhaps the simplest solution indeed, but technically I think the marked answer below is nicer.

Belak

Answer 1

If you want to make them reusable across the site collection for each user you can add Fields to the User Information List. You can add a feature receiver to your web parts solution that can create this column or check to see if this column exists in the User information list to be sure that the Column exists.

The User Information list is a Standard SharePoint list that SharePoint uses to store user information. To access the User Information List you can go to the Root web of the Site Collection and use the SiteUserInfoList property

E.G.

SPList userInformationlist = SPContext.Current.Site.RootWeb.SiteUserInfoList;
//Or 
SPWeb web = SPContext.Current.Site.RootWeb;
SPList userInformationlist = web.SiteUserInfoList;

To access a users List Item you can use the Users Id to get the ListItem back from the User Information List

E.G.

SPListItem currentUserItem = userInformationlist.GetItemById(web.CurrentUser.ID);

If you are using MOSS you can store this information in the User Profiles and make it available across Site Collections this does not need My Sites to be enabled. You would need to use the User Profile classes to access this.

Sennacherib

Pretty good suggestions! Didn't know about the SiteUserInfoList, and I can probably get away with a single Site Collection (larger SharePoint layout design is still pending). Because the amount of data I need to store is small and it's atomical, I could persit it in a single Note field. – Belak

The property bag of the user profile should also work nicely. Sounds a bit heavy-handed to create a profile just for storing some data, but it might work out very well. – Belak

The User Information List is the core WSS list, MOSS then has a seprate User Profile Database provided by the SSP that syncs some of the data to the local User Information List, It would be more heavy-handed to use the User Profile Database but it depends on where you want to access this data as the User Information List is stored with in the site colection. – Sennacherib

Answer 2

I would go for the properties on the user profiles. You do not want to store the information on the root web as it is not information regarding the root web. Your example with the favorite urls, each user has a "quick links" collection on their profile. An ideal place for storing urls for each user. :)

Manama

Answer 3

Build a webpart that reads/writes a custom database and you'll have the flexibility to use the webpart across SiteCollections, WebApps, or even seperate Farms.

This was implemented where I work and it has been a big success. We needed a way to provide our end users a large selection of important, commonly used links. End users have the ability to display the links that are useful for their particular job function and have a webpart that can be put anywhere to reference those links that are important to them. You also have the ability for an “admin” to go to the custom database and update any URL’s that might change without the end user ever being impacted or ending up with a broken link.

Dipper

Answer 4

This is a very good question.

Although I have no perfect answer, here are some things you can consider:

• Store data in a browser cookie if this is feasible.

• Store in the Site collection's rootweb in the Properties, keyed by the user's login ID. You may want to elevate when reading / writing the properties just in case the user has access to a subweb, but not the rootweb.

Mithraism

I would not recommend the Rootwebs Properties collection; you will have performance issues on your site as it is not designed for a large number of records. – Sennacherib

Creatieve thinking, but cookies are just not as persistent as I'd like things to be. – Belak