Problem with Shared vs Personal Settings in WSS3.0

Topics: Developer Forum, Project Management Forum, User Forum
Aug 6, 2007 at 9:58 PM
I've been running FeedReader in WSS3.0 for several months now - and I've noticed one quirk that I hope I can fix if someone can give me some direction:
Apparently when one of the users changes their "Personal" setting for the feed list - it affects the "Shared" settings...? It's strange because the opposite is not true - meaning if I change the "Shared" feed list - it does not affect their "Personal" lists. Which is great... But I really wish I could keep the users from changing everyone else's!

I guess I could always lock it down so they can't change it at all or something - but that's a big part of what I like about FeedReader - the per-user customizability-

Has anyone else experienced similar behavior? Or know of a workaround/solution?
Thanks!
Aug 10, 2007 at 11:31 PM
I wonder if this may be due to caching. FeedReader caches the feed using shared storage:

this.PartCacheWrite(Storage.Shared, "FeedReader" + this.Parent.ClientID, this.RefreshFeedCache(), TimeSpan.FromMinutes(Convert.ToDouble(this.cacheDuration)));

You could change it to personal storage.

Regards,
Mike Sharp
Aug 17, 2007 at 4:19 PM
Edited Aug 17, 2007 at 4:21 PM
-
Aug 17, 2007 at 4:21 PM
Well, I tried changing Stoage.Shared to Storage.Personal in the 4 references I found. I am assuming I had to change it in all 4 because one was reading from cache, one was writing, one was invalidating the cache, and i cant remember the fourth one off hand.. but logically it made sense to change all 4 to Storage.Personal. So then I recompiled and copied the dll's to Sharepoint.. and it wont even render.. just throws a generic exception "object reference not set to instance of an object". When I change them back to Storage.Shared everything works like a charm. But Storage.Personal bombs.
Any ideas? Are there any other changes necessary to switch to Storage.Personal?

Thanks-

Aug 17, 2007 at 5:21 PM
Something's a bit odd here. I see 8 places where storage.personal is used for configuration, including the URIs of the feed:

/// <summary>
/// RSSFeeds is a semicolon delimited list of URIs for various RSS feeds.
/// </summary>
DefaultValue(_defaultRss)
WebPartStorage(Storage.Personal)
XmlElement(ElementName="RssFeeds", IsNullable=false)
public string RssFeeds
{
get { return this._rssFeeds; }
set { this._rssFeeds = value; }
}

If that's the case, I don't see why the feed itself should be cached in shared storage (though I haven't yet spent much time looking at the source). You'll probably have to debug to find out where the exception is being thrown.

I presume the original problem you're seeing is that if you have a web part page with an RSS feed on it, and someone changes their personal view (maybe selecting a filter or a different feed), then everyone sees the change, right? If they change the shared view, then it should change for everyone in any case.

What happens if you change the property attributes to shared storage? Of course, you'll lose the personalization that way, but maybe you could change only the URIs property or whichever properties should be shared. It seems to me that CacheMinuteDuration, RssFeeds and both the proxy settings should be shared, not personal.

I have a similar situation as yours, except that I'm going to be using this to roll up announcements across site collections, which will require security trimming. I'll be working on that next week, if you can wait that long. Otherwise, perhaps Tim Heuer can chime in here with some insight.

Regards,
Mike Sharp