Annoying Exporting a list to Excel

SharePoint lists have the ability to export their contents to an Excel Workbook.

This is quite cute – it gives the users a way to get the data out into something they’re familiar with, can manipulate and can print. However, I was having an issue. Using a list based on a Custom List (above), one of my columns (Enquiry) wasn’t exported:

I wondered at first if this was because of it’s column type (Hyperlink), or because I’d created the column programmatically. Then, on a hunch really, I tried changing the column order. I added another column before it in the list view. I used the ID column, but any should work. When I exported the list – all the columns I wanted came through (but the ID column didn’t).

What I think is going on here is that if you used the same export on a document library then typically – though not always – the first column is an icon for the type of file it is. My suspicion is that some muppet, when writing the export to excel, realised that they’d have these icons, and decided to avoid them by excluding the first column. This is unfortunate for two reasons:

  • Not all lists have icons – witness my Custom List
  • Not all document libraries have the file icon as the first column.

For now the resolution would be to have another column as the first on your list.

Advertisement
Annoying Exporting a list to Excel

Clean up SharePoint's UI with jQuery

So, the case management system I’m working on has a ‘Mailbox’ library. Really, it’s just an email enabled document library, with the address set to the name of the case. Anyway, when emails are received into this list, we’d like to show the subject, sender, cc, to addresses, and so on. It turns out that email enabling a document library does in fact add columns for those properties (but they’re not automatically added to the default view).

mailbox-page-default

Neat! Until you start looking at the code itself – then it sucks… Continue reading “Clean up SharePoint's UI with jQuery”

Clean up SharePoint's UI with jQuery

List Definitions don't need their own forms…

List definitions don’t need their own forms – if you’re happy with the out of box ones. Mostly, if you use something like the solution generator to create your List definition, it will create a number of forms by default for you:

as-created-by-solution-generator

These are then deployed into your list:

when-deployed-as-seen-in-sharepoint-designer

However, you don’t actually need these in your definition, unless you’re providing your own custom forms! Continue reading “List Definitions don't need their own forms…”

List Definitions don't need their own forms…

Regular Expression Validated Column in SharePoint

What a great discovery – a Regular Expression Validated column on Codeplex. I’ve been talking about writing one of these for about 6 months – and Gael Duhamel has written one for me! Kudos!

I’ve not tried it yet, but I’m putting it to the top of my ‘things to try’ list. As my colleagues know I love regular expressions, and I rather feel this should be OOB.

Regular Expression Validated Column in SharePoint

What columns can I use in my Search Results?

In a previous post I described adding the FileExtension column to the XML you get back from a SharePoint search, so that you can use it in your results page. This raises the question – what columns are available for use in the Selected Columns setting on the Core Search Web Part?

Well, these columns are Managed Properties, and they’re configured on the Shared Service Provider (SSP)… Continue reading “What columns can I use in my Search Results?”

What columns can I use in my Search Results?

Self Referencing Lookup columns

Came across something I’d not considered – self referencing lookup columns! I was doing some testing, and this totally caught me out (and caused my Outlook plugin to crash and die).

Basically, this is a Lookup column where the List that it is looking up onto is the same as the list where the lookup column is in use. In our case we had a list called ‘Issues’, and the lookup was a multi-choice look-up called ‘Related Issues’. It would let a user select things from the Issues list. All in all, a perfectly sensible use of a multiple lookup, and one I’d not thought of!

However, this in itself wouldn’t cause my plug-in to suffer an error. The problem was with the data I was getting back from the Web Services I’m using. I use the List Webservice‘s GetListContentType method to get information about the Content Type, and I then read the information about the fields. Lookup fields normally come through with an attribute List ; this is the list that’s being looked up onto, and normally it is a GUID. However, for self-referencing lookup instead of a GUID, you get a string ‘Self’‘. Okay, I can’t argue that it’s wrong, but it’s a smidgen annoying that it is inconsistent. Couldn’t it just give me the GUID and let me figure out if that’s the same list? Or use another attribute to denote that it’s a self-reference?

I don’t get why this was built that way.

Self Referencing Lookup columns

List Items, Documents and Attached files

One of our customers is saving Outlook emails into SharePoint; I’ve written an Outlook plugin to do this. The emails themselves are being saved as .msg files within Document Libraries.

A Document Library containing .MSG files

However, they’d like a nice column with a little Paperclip icon if the Email has attachments. For normal Lists, there is a column like this (provided that the List allows attachments)… Continue reading “List Items, Documents and Attached files”

List Items, Documents and Attached files

Take care when adding or removing columns from Site Content Types

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’

Update Child Content Types

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:

Extra List Columns 2

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:

Silly Warning Dialog

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:

Extra List Columns 3

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.

Take care when adding or removing columns from Site Content Types

Content Types – Who's your daddy?

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.

List Content Type

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.

Site Content type

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…

Content Types – Who's your daddy?