Beware SharePoint Site Columns In Site Templates

This one's a real doosy but very easy to recreate.

First, the what I expect scenario:

1. First create a site collection with a blank root site.
2. From the root site create two child sites, again both blank.
3. On both child sites create a Site Column called Project Id, single text value, with a default of P1 for the first and P2 for the second.
4. Now add an Annoucment list  to both child sites and add the corresponding site column to each list.
5. Now go back to the Site Column definition of the first site and change the default value for Project Id to "Proj1" and be sure to keep the "Update all list columns based on this site column" set to to yes.
6. Then go back to the Announcements list on the other (second) child site and check the list settings to see what the Project Id column is set to. Note that this is the List column not the site column it is based on. The default at the list level should still be P2.

This is of course exactly what we would expect. Changing the default of the site column only affects that site and child sites under it, but certainly not sibbling sites.

Now create a Site Template from one of the child sites and stand up a couple of more sites based on this site template as children to the root site, so sibblings to the site the template was generated from.

And now change the Site Column default for Project Id on one of these new child sites to say "PX" and again be sure to keep the "Update all list columns based on this site column" set to to yes.

Now start looking around.

You will find that while all the Site Column defaults other than the one you worked on are unchanged, the List Column defaults have been changed for the current site, the other site generated from that teamplte, and also in the site that the template was generated from. But apparently not the other sibbling site that was generated manually and has nothing to do with the tempalte.

It is of course, my old friends SPSolutionExporter and associated, though in this case the problem is most likely with the import/stand up process.

I have no work around for this at the moment. Just don't include Site Columns in Site Templates unless you will only ever have one instance of that site in a collection.

You know, life sucks enough without having to add SharePoint to it.

Why I Hate SharePoint #4

You would think that after I had been using SharePoint for a while the rate of discovery of bugs and issues should go down. You'd think but...

Oh well. I just thinking about all the sin I'm in credit for because of all this penance I'm serving having to work on this product.

1. Event List Webpart Issue

This one is so peculiar I'm having trouble narrowing down. I can reliably make it happen when I have the following in the same webpart zone in order:

1. a content editor webpart
2. another content editor webpart
3. an announcement list webpart
4. a calendar webpart that I then make the following changes to:

• Change the web-part view to use Current Events
• Edit the current view to just select Title, Start Time & Location
• Change the title link to specifically jump to the Current Events view of the list rather than calendar

 And then suddenly the web-part appears as if it was minimised. From this point on nothing seems to be able to fix it (and yes I tried to minimize then un-minimise it. Looking at the HTML that results, the content of the webpart is just not being rendered. This one is driving me nuts. I've been trying to take other bits out to reduce what is needed to make this happen but to no avail. The next thing I'll try is to recreate the problem again and see if there is any error in the log but I only have limited time to work on this issue.

2. Conflict Update Error

Our deployment PowerShell scripts works fine most of the time but occasionally we get the error "An Update Conflict has occurred, and you must retry this action."

We have had it intermittently in one environment with the New-SPContentDatabase command, and in another we had it with a New-SPManagedPath.

It's the sort of error I would expect if I was using optimistic locking and somone has changed the record I was working on between the point where I read the record for editting and the point where I went to save the editted record back. That's just a guess.

My thoughts are that the PowerShell commandletts themselves probably have some assumptions on the sequence of events occuring and sometimes that assumption proves to be incorrect. To be honest, I think this is a little unfair. How about the commandlet itself does a few of the retry attempts itself and try to be a little more robust, or just not assume stuff and do some checking first.

I can't explain just how difficult life becomes when you get intermittent errors in your deployment scripts and there doesn't seem to be any logical way to address it.