Folks are really keen on RSS feeds in SharePoint, but the RSS web part only receives feed from 1 location. Well, good news, as Eric Shupps created (a while ago, actually) a feed aggregator web part. That’s a useful thing to know - but it’s interesting that he hit the problem I have with RSS feeds - too many formats of them…
As mentioned before the content types on a list are actually children of the site content types. I’ve also looked at adding columns to list content types, which naturally enough doesn’t affect their parent site content types. Anyway, there are issues to consider when dealing with adding and removing list content types - I suggest you refer to this post for more information.
So what about adding and removing columns from Site Content Types - are there issues with this? Well, yes, there are (unsurprisingly). If you add a new column to a Site Content Type, you have the option to ‘Update all content types inheriting from this type’
If you select ‘no’, then the change only applies to that Site Content Type. The next time you add that site content type to a list, the new List Content Type that is created will have the new column, but pre-existing list content types that inherit from the site content type will be unchanged.
If you select ‘yes’, then the List Content Types (or other Site Content Types) that inherit from this content type will have the new column. For the List content types, this means that there will be a new column on the list. Carrying on from an earlier example, here I’ve added a new column (’Job Title’) to the Example Travel Expenses site content type, and updated all content types inheriting from that. If we then go an look at the List Settings page, we can see our List Content Type has a new column:
Great! Now what happens if I remove that column from our Site Content Type? Well, again, I get the option to ‘Update all content types inheriting from this type’. If I choose no, then the existing List Content Types derived from this Site Content Type remain as they are. If I choose yes, though, I get a fairly large warning saying:
This column will be removed from all content types that are based on this type. If you are sure you want to remove this column from all content types based on this type, click OK. To remove this column from this content type only, click Cancel to close this dialog box, click No in the Update Lists and Columns section, and then click Remove.
Snappy message that:
Anyway, if you click OK, that column is removed from child content types. H0wever, the column is not deleted from lists that were using those child content types. I removed the ‘Job Title’ column from my ‘Example Travel Expenses’ site content type. If we return to our list settings page, we can see that the column still exists, although it isn’t used in any content types:
This makes sense, as the column could actually contain data, and it could be used in multiple places throughout our sites (potentially hundreds!) However, maybe you do want to remove that column from that list, or potentially those hundreds of lists. In that case (and this is why this is important) you have to delete the ‘orphan’ column on a list by list basis. Therefore, if your content type was used in hundreds of lists, you will have to delete this extra column hundreds of times, once for each list.
Therefore, be very careful when adding or removing columns from a Site Content Type - make sure that you really want to add it (as removing it might be hard), and be aware that removing the column is not the same as deleting it in the lists that use it already.
Content Types are great, but can cause a little confusion. Because you normally define a content type at a site level, that’s pretty much how we think of them - as centrally defined types of item. Often, we actually create these content types on the root site of a site collection, because all subsites will be able to use them then.
However, this isn’t really the case. We do have site content types - but we also have list content types. These are the content types that are actually used on the lists themselves, and they are children of those site content types. This can be most easily seen by clicking on a content type on the List Settings page.
Notice that our ‘Example Travel Expenses’ content type says it has a parent of… …’Example Travel Expenses’! This is our List Content Type telling us that it’s parent is the Site Content Type of the same name. Click on it, and it’ll take you to the Site content type description, and you can work on up the chain of content types until you reach Item.
A consequence of this is that, as our content types are actually used by lists, I can’t think of a way to use a Site Content Type directly (though I may be wrong about that).
That are also issues related to this in terms of modifying content types, but that’s the subject for another post…
This is sort of relevant to an earlier post on the Document Information Panel, and showing fields in it.
The behaviour depends on if you’ve enabled ‘Allow management of content types’ on the Document Library Settings > Advanced Settings page.
If you’ve not allowed management of content types, well, you just add the column and it’ll appear in the document information panel. That’s great! The new column will not show as belonging to any content types, as the ‘Test‘ column is in the screenshot below:
However, if you have allowed management of content types for the library, things get a little more complicated. When you add a new column, in the ‘Additional Column Settings’, there will be an option for ‘Add to all content types’. If you check this, well, it’ll add that column to all the content types currently on that list. This will make it appear on the document information panel. This is what I did with the ‘Test2′ column above (but before I added the Picture content type to the library).
(As a side note, the content types on the list are actually ‘children’ of your Site content type rather than instances of it. This means that if you update the content type on that list, it won’t update the parent content type, or other lists that use that content type. Similarly, it mean that if you update the parent content type - say, you edit the site content type - you need to update child content types with those changes to affect lists that are using them already. But that really should be another post, sometime.)
If you don’t check that ‘Add to all content types’ option, well, it doesn’t add it to the document information panel. Finally, what if you have added a column all content types, and you add a new content type to the list? Well, your new content type will not have that new column applied to it - and the only way I can see of applying it to the new content type is actually to delete and recreate it. Of course, that means deleting a column that contains data, so that is less than ideal. This is what happened with the Picture content type - I added it afterwards, and you can see that it doesn’t use the ‘Test2‘ content type.
For that reason, be very careful when adding columns to library that is allowing management of content types. If possible, keep the columns in the Site Content Type (i.e. the parent).
The Document Information Panel is great - it allows you to surface metadata to be filled in about a Word 2007 document in the client.
This is great, but I had a bit of a puzzling problem. I’ve set Libraries up to use this features many times now, and it’s pretty straight forward - I’ve added columns to the library, and then the template document for the library has included those columns. Thus, you just go into your document library, click new, and you get a blank word document with the correct document information panel thing. Sometimes I’ve modified that template, but that’s pretty straight forward through the Library Settings pages (Document Library Settings > Advanced Settings > Edit Template).
This time, though, I was using content types (i.e. setting up the library properly), rather than just adding columns directly to a list. Content Types encapsulate (amongst other things) their own set of metadata to be captured - so in other words, they define columns to be added to a list. That’s fine (and very useful).
However, when I went to my document library, clicked ‘New’ and selected my Content Type, I got a blank word document with only one field in the document information panel - title. The blankness was expected (I’d not defined my own template) but none of the other bits of metadata I’d defined for my content type were there. This was a bit of a puzzle. What was different?
Well, after much thinking, I realised something - Content Types ‘inherit’ from each other. My Content Type derived from the Document content type, which specified just one field of metadata - Title. Then it hit me - content types themselves have document templates. My new content type was inheriting from Document, and it was still using the Document content type’s template document. I specified my own template document for my content type and suddenly I had all of my fields available in the document information panel.
It is interesting that there is this difference between the document information panel fields being defined by the library when just using the default ‘Document‘ content type and no others, and the fields being defined by the content type you’ve created if you’re using other types (I.e. you’ve enabled ‘Allow management of content types’ on the Document Library Settings > Advanced Settings page).
Related to this, then, is the question of what happen if you add a column to a list. However, I’ll cover this in another post.
I was building a demo where I was wanting to show the document information panel in Word 2007 (which I think is one of the neatest features about it!) . It should look like:
But instead I was getting “The document information panel was unable to load“.
I couldn’t see a reason for this, but investigation found this post which shows the same error, and a solution in the comments:
The System Event Nofication Service (SENS) uses the same communication “channels” (not the correct word, but works) as does office products do in communicating with the server.
Stop and disable the SENS service on the server and everything will work perfectly.
So, open a command prompt and type:
net stop sens
Bit strange, but that fixed it for me. Also note the comment at the bottom that the Document Conversions service doesn’t work on a single server demo system like this.
More bugs in the dataview webpart - this time not being able to set the default locale for the page’s dates to being UK. When you add a datetime column to the view, if you look at the code, I can see the locale of 1033 (en-us), and the date formats available are only US format.
On my system, however, while the date formats appear to be US format in SharePoint designer, the code for a datatime column that I add to the view contains the 2057 locale (en-gb) , and the date formats display correctly in the page itself.
So it’s almost like SharePoint designer thinks it is working with US date formats, despite the settings of the Page Editor settings page, the Regional settings on the machine, and the Regional settings on the site all being set to UK date formats. I don’t know if I’m missing a setting somewhere, but if I am, I really don’t see it!
This problem can be fixed by resetting the locale by hand in the code, but really, you shouldn’t have to.
As mentioned previously, I was having some problems with not having the right operators in the Filter Criteria dialog of a DataForm Web Part. Although the field I was trying to filter by was a date, I was only being shown the options as if it was a string:
Well, proving that invention is 99% perspiration, I managed to find a solution. On the list on my customer’s system there was a Lookup column which referred to a list that no longer existed. Note the lack of List name for where it’s getting information:
When I removed that column from the list, I could filter correctly again:
This is despite the fact that the broken lookup column is not used either in the display on the DataForm webpart, or in it’s filter. Merely its presence is enough to screw things up. Note that this is a different solution to other ideas that have been suggested elsewhere.
I mentioned before about looking at other content editors for SharePoint 2007. Well, it came as a bit of a surprise for one of my colleagues to discover that you could do this!
Anyway… so I had a look at other content editors. Well, the one replacement that I could find. Telerik make a variety of controls that can be used in MOSS, including a free ‘RadEditor Lite‘ and then the full ‘RadEditor‘ (which has a free trial). A comparison is available. I’ve used their controls before - they’re pretty good, and their forums and support are very good (which is probably more important when you’re developing). Some of their controls I’ve used before had their quirks - but that’s true of all ‘rich’ controls in web applications, in my experience. The Telerik ones were better than most.
I must actually give it a go sometime. There are extensive instructions on the Telerik site.
This was a weird error - but I’m not the first one to see it. When using a dataview web part, and trying to do a comparison with a date column, the filter dialog wouldn’t let me choose certain comparisons. The ‘Less than’, ‘Less than or equal to’, ‘Greater than’ and ‘Greater than or equal to’ options were all unavailable, and options like ‘begins with’ were available. It’s very strange, as it’s almost like the date was a text column - except that isn’t, and that another user did get those options.
I’m not sure if this is a security related issue as the linked post seems to suggest, but it’s really weird that the two users with the same permissions looking at the same system see this field in such different ways. I don’t have a resolution, I’m afraid.
RSS