So, many issues I had to resolve today were typical over-rushed developer stuff: non checking for nulls, not testing with users that don’t have MySites, yadda yadda.
Two errors stood out as things I'd like to help people avoid doing.
First, the developer of the web parts I am fixing failed to make a distinction between System.Web.UI.WebParts.WebPart and Microsoft.SharePoint.WebPartPages.WebPart. They are almost identical, but each implements Web Part Properties in code slightly differently.
using
com = System.ComponentModel;
using aspnetwebparts = System.Web.UI.WebControls.WebParts;
using wsswebparts = Microsoft.SharePoint.WebPartPages;
...
// for System.Web.UI web parts
[aspnetwebparts.Personalizable(aspnetwebparts.PersonalizationScope.Shared)]
[aspnetwebparts.WebBrowsable(false)]
[com.Category("Configuration")]
[aspnetwebparts.WebDisplayName("Parent Category ID")]
[aspnetwebparts.WebDescription("Determines the Parent Category from the Categories List on the Taxonomy Administration site")]
// for WSS web part
[wsswebparts.WebPartStorage(wsswebparts.Storage.Shared)]
[com.Browsable(false)]
[wsswebparts.SPWebCategoryName("Configuration")]
[com.DisplayName("Parent Category ID")]
[com.Description("Determines the Parent Category from the Categories List on the Taxonomy Administration site")]
This was probably a copy-pasta error, but he used the System implementation instead of the SharePoint one. As a result, none of these web part properties actually showed up where users could change them.
To be honest, I used to make this mistake all the time, especially when copying properties from other web parts I had written. These days, I just suck it up and define all of the attributes so I don't have to deal with this issue.
That was actually good news, because it means that maybe with a little more work, this solution will be about 10x as configurable as it is now.
The second thing almost drove me crazy, because it was very similar to a problem I saw a year ago (or more) and I couldn’t remember what it was. It turned out in the end this was a slightly different issue, but I digress. The problem was that when you have a Tool Pane Editor (basically a fancy custom Web Part Property) and it is used to set a WPP that’s also visible in the browser, the WPP will overwrite the changes that the TPE makes. So for example, you pick "IT Apps" in a dropdown TPE. The TPE goes and looks up the List ID for "IT Apps", and comes back with “15” and saves that to the WPP called Parent ID, but since Parent ID is also visible in the web page and has a value of “” (empty) the empty value then overwrites the “15” and you’re back where you started. The solution here is to hide the WPP by setting Browsable/WeBrowsable = false, thus proving it’s not how much code it takes to fix a bug but finding the correct line to change. J
To the developer's credit, I was the one who set this to true, because I was trying to make it visible so I could troubleshoot the ToolPane picker. Oops!
(By the way Ted, I hope you're settling in nicely at DOE. <grin>)