I’ve been giving some thought to the whole “Web 2.0″ concept; how people throw the term around in technical conversations the same way they do “governance”, “collaboration”, “KPIs”, and “B2B”. I love it when terms like this come around, seeing how they are used in conversation, the meaning they are given by different people. It really trips me out.
So after reading the term for the 100th time in some random blog. I decided to search on it, and see what other people are saying. I don’t want to bore you with all the details of what I found, (I doubt there are many people out there as easily amused) but I do recommend you check out this you tube video published by a professor of Cultural Anthropology from Kansas State University. It is one of the coolest presentations I’ve seen on… well… how do I say this in the least possible geeky way?… I cant; Separation of Content and Form. I know it may not sound very fun or interesting, but check it out, I thought it was fantastic:
In my previous post, “Hidden SharePoint Lists, Fields, and Other Advanced List Settings”, I demonstrated how we can develop a custom application page to easily expose and modify list and field settings. But once the custom application page has been created, how do we expose it to our users? Ideally we would create links to our Application Pages by adding new menu item entries to the SharePoint Site Settings and Site Actions menus. Fortunately, SharePoint allows us to do just that via Features and the CustomActionGroup and CustomAction elements.
The CustomAction element refers to the actual link or menu item.
The CustomActionGroup element, as Microsoft puts it, “contains the core definition for a grouping of custom actions.” Such as when you see a group of links or menu items grouped together in the “Operations” and “Application Management” pages of the Central Administration site.
What about the “Site Actions”, list or library “Actions” and “Settings” menus? These, like most other SharePoint menus, can also be configured via CustomActions.
The following steps demonstrate how we can use features and CustomActions to add a new menu item to the Site Settings page.
Creating the Feature
- Browse to the file system Feature folder located in “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\”
- Create a new folder for your feature. In my case I will call it “AdvancedListSettings” as I will use the feature to add a link to the Custom Application Page I created in my previous post; Hidden SharePoint Lists, Fields, and other Advanced List Settings
- Open the folder and create a new empty file naming it FEATURE.xml
- Open the file and paste the following XML, replacing NEWGUID with a newly generated GUID.
I like to call this file the “feature definition file”. It contains the general settings of our feature such as; title, description, feature scope, and whether or not the feature is hidden; but it doesn’t necessarily contain any of the “meat” or instructions for the feature, we’ll put those in our Elements Manifest file which we’ll create next.
- Save and close the file
- Create another file and name it “CustomMenuItem.xml”, we’ve specified this as an Elements Manifest file in our feature definition.
- Open the file and paste the following XML
- Looking at out CustomAction element the attributes break down as follows:
- ID – The ID specifies a unique identifier for the custom action, keep in mind that it must be unique, you may want to use a GUID.
- GroupID – Identifies an action group that contains the action, for example, "SiteManagement". If contained within a custom action group, the value of the GroupId attribute must equal the group ID of the CustomActionGroup element.
- Location – Specifies the location of this custom action. In this example we specified “Microsoft.SharePoint.SiteSettings", which tells SharePoint to create the custom action in the Site Settings Page.
- Sequence – Indicates what position the custom action should be placed in regards to other custom actions that may be in the same group.
- Title – Gives it the text to display
- Save and close the file.
- Open the command prompt and execute the following command to install the feature:
stsadm -o installfeature -file AdvancedListSettings
Where “AdvancedListSettings” is the name of the new feature folder in “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\”
- Browse to the Site Settings page of one of the SharePoint sites in Internet Explorer and click on the “Site Features” link
- Click the “Activate” button next to the new feature
- Go back to the Site Settings page to see your new menu item / custom action.
To create a new section in the site settings page and have the link appear in that new section, the elements manifest file (i.e. CustomMenuItem.xml in this example) would have too look as follows:
Notice the new CustomActionGroup element, it uses many of the same attributes of the CustomAction element. The GroupID attribute of the CustomAction element now references the ID of newly created CustomActionGroup.
For additional information see Custom Action Definitions in the SharePoint General Reference section of the MSDN:
We often have to create solutions involving hidden lists and libraries. If our hidden list is part of a SharePoint feature, we would probably handle the logic of hiding the list during our feature activation routine. But what if the solution is not part of a feature? Maybe the lists where created using the browser. What if we need to make our hidden list visible to help troubleshoot something that has gone wrong?
I’ve create a SharePoint Application Page that uses the SharePoint Object Model and a series of ASP.Net controls to display and modify properties of SharePoint Lists and Fields in a site. For security reasons only users with full control of the site can access the page.
The user can select the list from an ASP.Net list control. Upon selecting the list, the page exposes the Hidden, AllowDeletion, RequestAccessEnabled, and AllowEveryoneViewItems properties of the selected list.
I expose the list fields during the same time (when the user selects a list.) Upon selecting a field from the list, the page exposes the Hidden property of the selected field.
The following is the code for the application page:
Updated 8/26/2008: Changed how I obtained the reference to the SPWeb object throughout the code. The code was originally obtaining a reference to the SPWeb object via the current context from within a “using” statement. This was wrong as disposing of a shared resource such as an SPWeb object obtained from the current context may cause the SharePoint object model to behave unpredictably. Alternatively I could have removed the using statements and let SharePoint manage the object, but considering the number of lines of code it was easier to do a find and replace from “this.Web” to “SPContext.Current.Site.OpenWeb()” which does not return a reference to a shared resource. See Best Practices: Using Disposable Windows SharePoint Services Objects for more information on the subject.
While I wouldn’t recommend Firefox as my browser of choice for any enterprise environment leveraging SharePoint, I do occasionally run into users that have it set as their default browser. The main complaint I hear over and over again, has to do with integrated authentication; the users having to enter their credentials whenever they browse a SharePoint site. This is NOT a SharePoint related issue, if an issue at all. There are certain settings in Firefox that must first be enabled for Integrated Authentication to work for a specific site.
Settings for NTLM:
- In the address bar type “about:config”
- In filter type “network.automatic”
- In the list, double-click “network.automatic-ntlm-auth.trusted-uris”
- Enter the URL for which you’d like to enable integrated Authentication. To enter multiple, separate them by commas.
- Click OK
Settings for Kerberos:
- In the address bar type “about:config”
- Search for the following settings and change their values accordingly
- network.negotiate-auth.trusted-uris: Enter the URLs for which negotiate authentication should be done
- network.negotiate-auth.delegation-uris: Enter the URLs for which delegation will be allowed
- network.negotiate-auth.allow-proxies: Enables proxy authentication using the negotiate method
- network.auth.use-sspi: Tells Firefox to use the Windows SSPI library
Tim Jones has a fantastic post on the subject at http://simplyaprogrammer.com/2008/05/importing-files-into-sharepoint.html. I enjoyed the read and will likely need to do something similar in the feature.