Ferrara Data Consulting | Company Blog

A frequent request from end-users is the ability to remove the “title” column from Sharepoint lists and document libraries. You can rename this column to something else, but I do not recommend this for various reasons. “Title” is a reserved Sharepoint word and renaming it has been known to break things. Generally this only occurs if you change it in the Site Content Type Gallery, but I tend to err on the side of caution here. You can read about that particular limitation here.

But you can hide the title column from the default content types already built in to Sharepoint with a few easy steps. I’ve posted ample screenshots below for the visually stimulated!

Step 1. Navigate to the desired list that needs to be configured. I am starting with an out-of-the-box Sharepoint task list that has not been configured in any way. You can do the same or start with a custom list.

Step 2. Click on Settings and then List Settings. Once on the settings page for your list, click on the advanced settings link as shown below.

Step 3. The advanced settings page is not all that advanced as there are some common settings here, but you will need to set “Allow management of content types” to yes before proceeding. Click OK to continue.

Step 4. You should see the Content Types section now which will allow you to edit all settings pertaining to the content type that we want to edit. Although not in the scope of this article, this is also where you can create/edit workflows pertaining to your content types. Click on the content type name, Tasks in my case, to get to the next step.

Step 5. Select the Title column from the column list.

Step 6. Change the status of this column to “Hidden (Will not appear in forms)” and click OK.

Step 7 (Best Practice Option). When you are finished managing your content type, then you might want to go back into the advanced settings page and disallow the management of content types. Either way, your configurations will be saved, but this prevents the conspiracy theorist admins out there from blaming inadvertent changes on “the other IT guy”. I’ve added another caveat of this step below in the update section.

After these steps have been completed, then you will no longer see the Title column when adding a new item on this list.

As you can see, altering the default content type is not very difficult, but it can enhance usability on your lists. In the future, I will discuss the benefits of creating your own content types in the Site Content Type Gallery, and why it can make your life a lot easier when creating custom lists for yours users.

Update 2008-09-05: I failed to mention in my original post that you will not be able to manage the order of your columns on the list settings page again until you switch “Allow management of content types” back to No. When the management of content types if enabled, you can then reorder the columns for each specific content type. You may or may not want this to be your standard setup, so my best practice here would be to turn this feature back off when you are finished managing the content type.

Part 1 Part 2

It’s not everyday that you find a company or IT department that keeps a structured and updated “update log” for their systems, let alone Sharepoint. Updating your software is as easy as clicking a few buttons and trusting that everything will work as advertised. And for the most part, application updates really do what they are supposed to without causing outages. With communities, blogs and wikis for just about every application in existence, developers find it much easier to distribute test builds to the masses and receive responses rather quickly. This translates to quicker bug fixes and an overall better experience for end-users. But this can also lead to an ultra-trusting mentality when it comes to updating your software with major upgrades and/or patches. It only takes one patch to create hours of work for you and your team to get the system back online when incompatibilities rear their ugly heads.

This three part article will aim to give you my thoughts for an effective update log for your Sharepoint servers.

NOTE: I’ve written this article with respect to Sharepoint specifically. It is part of a larger concept that could be incorporated into all LOB systems.

The first thing that we need to do is figure out where we should store our data. Depending on your needs and organizational size this may be a very simple setup, but it still helps to think it through first.

The table below summarizes a few pros and cons for 4 possible scenarios.

This is a pretty self-explanatory table, but I want to touch on one of these a little bit deeper. When thinking of an update log for Sharepoint servers, the first thing that comes to mind would be an easy to maintain Sharepoint list. It is by far the quickest way to get data in a nice format that others can read/edit. But this option does not accomplish enough independence from the platform itself. If your Sharepoint farm is down, then you’ve negated the update log completely. So although Sharepoint may be an option for you (if you aren’t worried about a severe failure), I would recommend not storing your data in a native Sharepoint list.

With that said, I’ve chosen to store my data in a custom table on MS SQL Server 2005. The below query will get you started with a simple update log table to store your data. You can change the structure below to match your naming system, but make sure that you are not adding this table to any of your existing Sharepoint content databases. It can be tempting to store this data in your default Sharepoint content database for ease of use, but that comes along with a higher security/corruption risk. And although I haven’t tried this long enough to see if it will break something in Sharepoint (like a restore process), play it safe and create a separate database. I’ve called mine “admin” to keep things simple.

USE [admin]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[sp_updates](
[id] [int] IDENTITY(1,1) NOT NULL,
[developer] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the developer of the update
[application] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the application affected
[type] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the type of update applied
[number] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the update number or KB number for Microsoft updates
[change_log] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
–Refers to a UNC path or HTML link to a change log file
[date] [datetime] NOT NULL
) ON [PRIMARY]

Stay tuned for the next article where I will show you a small custom aspx site that will access this table. Furthermore, in the third and final article on this subject, I will display the best of both worlds. It will cover the usage of Sharepoint as a front-end display for your update log, while still maintaining a level of data independence.

Your feedback is always welcome!

Ferrara Data Consulting’s new web identity is nearly complete! The site design is undergoing some final tweaks and will be unleashed soon.

All Sharepoint and development content will be migrated here, so check back periodically for updates.

In the meantime check out a new favorite Sharepoint blog of mine, Sharepoint Magazine.