Adding Office File Types to all Document Libraries New Menu without Content Types
One of the questions I am asked the most from my end-users when using SharePoint is "Why can’t I select new Word, Excel, and PowerPoint from the new drop down on all my document libraries?"
With the introduction of Content Types in Windows SharePoint Services ("WSS" 
3.0 people solved this problem by creating a content type called Word Document, Excel Document, and PowerPoint Document. They would then apply those content types to all the document libraries on their site.
While WSS 3.0 added this flexibility and my end-users were happy I noticed an issue with this implementation. When users were saving documents to SharePoint via Windows Explorer or the multiple file upload it selects the default content type (Word Document).
As you can see, this starts to cause an issue because all different file types start being marked incorrectly. Of course, the users can go back and change this to make it work but realistically this is not going to happen.
At the end of the day, content types should be used as they were intended (Memos, Invoices, etc) and simply creating one for Word, Excel, and PowerPoint was a "hack" to solve an end-user experience problem.
The Solution
I created a SharePoint feature (Source and Solution links available below) that basically adds Word, Excel, and PowerPoint to the new drop down menu of all document libraries within a site collection. This implementation does not make use of Content Types and allows users to quickly create a new document of these types in any document library. The beauty of this implementation is that if a document library does have content types, such as an invoice, when the user saves a document the first time (after selecting Word, Excel, or PowerPoint) it will prompt them to select the appropriate content type. Since my new menu items are not implemented as content types they are not visible from within the Content Type selector.
The following is a series of screen captures that demonstrate my implementation of Office File Types.
Once the feature is activated via the Site Collection Features, all document libraries will now look like this:
As you can see, you can still have content types and the Office File Types appear at the bottom.
When the Office application launches and you click Save and provide a filename, it will now ask you to select the appropriate content type:
The document library will refresh and everything appears as it should be:
I personally think this just creates a better end-user experience especially for those people who work a lot with Office documents in SharePoint.
Known Limitations
Right now the Office File Types feature does not recognize the folders you drill into. This was really put together as a proof of concept and will most likely be enhanced overtime.
Source and Solution
Note: No assembly was developed to get this to work. The feature basically just adds some custom actions to the document library list type and all the magic happens through JavaScript.
http://cid-06457d244696ab3c.skydrive.live.com/browse.aspx/WSS/OfficeFileTypes
I hope you find this useful.
[Update - 5/15/2008]
Just incase anybody needed this information — Here are the installation instructions:
stsadm -o addsolution -filename OfficeFileTypes.wsp
stsadm -o deploysolution -name OfficeFileTypes.wsp -url <url of your site> -immediate -allowgacdeployment
Once the solution has been deployed, you just navigate to the site collection and activate the Office File Types feature.
[Update – 7/7/2008]
I removed the rights attribute from the OfficeFileTypes.xml because SharePoint completely ignores this if you have unique permissions set on the document library itself (thanks Marco). In this particular case, since I am added the Office file types to the new menu which is only visible to people who can add content, the rights was not necessary. However, this seems to be a bigger issue if you wanted to add something to the actions menu, or settings menu.
Both source and WSP files have been updated.
[Update - 7/8/2008]
Even though the new solution works around the issue mentioned above it has introduced another scenario. Because I removed the AddListItems right the New menu now shows up with the Office File Types for users who have read-only rights.
I have started a thread on the MSDN SharePoint Development forums (http://forums.microsoft.com/forums/ShowPost.aspx?PostID=3590618&SiteID=1) so hopefully Microsoft can offer some guidance to this issue. I personally believe this is a bug, or CustomAction implementation issue that will have to be resolved by Microsoft so that I can use the Rights attribute of CustomAction again.
[Update - 7/8/2008 - Part II]
Due to the issues I ran into using the Rights attribute of the feature I completely re-worked the whole solution. Now it uses code to figure out if they have the appropriate permissions or not based on the library and folder they are in.
Both the source and WSP file has been updated.
[Update – 7/11/2008]
The solution has been updated to hide and show the specific Office Types depending on what the document content type has been setup for. For example, if the default document content type is an XLS file, the Excel Office File type will not show on the new drop down. The feature also now supports localization, so you simply need to copy the officefiletypes.resx file and create it for your appropriate language and you are good to go.
Hi,
I’m having the same problem as you when working with dynamic menu’s.
I’ve also developed a control to render my menu items dynamicly and this one works everywhere I put it, except under NewMenu.
Under NewMenu I can add labels and other controls, just not MenuItemTemplates.
I’ve read you had the same problem and I wondered if you had found a solution now.
Greetings,
Pascal
Pascal,
Unfortunately not. Before I came up with the JavaScript solution I tried many different methods to attempt to get the CustomActions to appear on the NewMenu and nothing worked.
Paul Liebrand
To bad
Thanks for your fast reaction !!!
Hey,
After 2 days of searching, I found a way to make it work
If you are still interessed, I’ll send you the code next week
Please do… I am interested.
Here is the link of the blog item I made about it:
http://docs.teamlink.be/collaborate/PublicBlog/Lists/Posts/Post.aspx?ID=3
Okay,
I’ve worked my solution out a bit and now I’m having the following problems.
I used a document library to store document templates and then this feature to show them.
2 problems arise now:
1. the document properties of the first document library are shown in word
2. the save location, doesn’t save well.
Do you have any solution to this ?
I’ve noticed you use javascript fuctions in your feature. I suspect it places a http://url to use as savelocation, does it ?
Thanks
Pascal
Pascal,
Yes — my solution does make use of JavaScript to get the context of the list and then call the createNewDocumentWithProgID function. The second parameter of this function is the Save Location you are passing to the Office Application. For example,
createNewDocumentWithProgID(’Excel.Sheet.8′,’http://site/library’,'SharePoint.OpenDocuments’, false)
This will create a blank Excel spreadsheet and set the save location to http://site/library.
Yeah,
Figured this out
Got everything to work now.
I use a custom list to organise my templates (category etc)
and a document library to store the templates and if I need a column for all the templates i make one in that library.
the saving problem was related to windows 2008.
Thanks
Hi,
Great solution!! Wish I’d found this solution a while back…
But, after implementing it on our test environment I’m experiencing a strange problem.
When a specific test user tries to test the solution the office file types don’t show up in the new menu.
Another test user (with the same rights on the doclib) it works as expected.
Any clues on where to start looking?
Marco,
In the “OfficeFileTypes.xml” you will see that each menu item has an attribute called “Rights” I would try remove that from the file, redeploy and reactivate the feature and then see if it shows up for the other user.
This “rights” attribute basically tells SharePoint to only render the menu if the user has “Add List Items” rights. If both your users have the exact same permission, I would at least start here.
This will basically render the menu regardless of user permissions.
I’ll attempt to see if I can duplicate this problem and report back if I find anything.
Hi Liebrand,
I’ve removed the rights attribute. It shows up for the specific user. Another test-account with only read rights it shows up as well. So the rights attribute works well.
The strange thing is after re-deploying the original officefiletypes.xml the 3 entries aren’t visible. Just the New Folder and New Document (contenttype).
…
I think i’ve narrowed it down to the following:
A user must be a member of the site members group. When a user is given modify rights on the documentlibrary self it doesn’t work.
Does this make sense to you?
Okay,
This is the situation:
3 test users
test_1: member of the site members group
test_2: read right on the doclib
test_3: contribute right on the doclib.
test_1 user sees the 3 officefiletypes + new folder/document
test_2 user sees nothing
test_3 user sees only the new folder/document option
Could this be a bug in SharePoint?
HTH,
Marco
I have read through the SDK and there is no indication of such limitation. However, I was able to duplicate the issue using the permissions you outlined here. I’ll let into some more but it appears it might be a bug.
Since the Office File Types are being added to the New Menu which is not visible unless you have the rights to add something to the list, I went ahead and updated my solution file it remove the “rights” attribute. Download the new one and deploy it — you should be good to go.
Hi Liebrand,
When removing the rights attribute people with read rights on the doclib see the officefiletypes (and the new button).
So this is not an option for me.
Probably not the way to go.
Let me know if you find another solution.
Thanks
Odd. When my users do not have the ability to add content they “new” button is not visible. Is the Office File types the only thing listed there, or do you also have “New Folder” and “New Document”.
What is the version of SharePoint you are running?
Hi, only the Office File Types are shown.
MOSS 3.0 SP1 (12.0.0.6039).
I’ve mentioned this situation in comment#12.
Marco,
Please install the new WSP file using the link above in your environment. This should resolve the issue you outlined in comment#12. See my comment#15. I fixed it.
Hi Liebrand,
The issue that a read only user now has a new button with only the Office File Types still exists.
Marco,
Try again — the solution has been completely redone and it should solve that problem (hopefully).
Hi Paul,
The last version of the solution works!
I’ve tested it tonight. And it seems to work fine!
Do you have plans to make it multilingual?
Thanks for spending your time in fixing the solution.
Regards,
Marco