C/D/H Talks Tech

Author:

David Tappan

I have been working in IT for 11+ years and have spent the last 5 years with C/D/H.

My specialties have grown over the years, and now include:
Active Directory/LDAP/Directory Synchronization, Exchange and SMTP, Office Communications Server, and SharePoint, SharePoint, SharePoint!

When I’m not at work, my favorite activities are gardening, skiing and spending time with my wife and 3 kids.

More about David
Articles by David Tappan

Customizing SharePoint begins with understanding the built-in customization settings. Here’s how to get started.

When customizing SharePoint, it’s always best to understand the built-in customization settings before creating a custom-developed solution. A good example of this is when you’re trying to customize the behavior of the built-in Issues List. Here’s an example of what the Issues list can look like:

The Issues list built into WSS is especially useful on projects because it uses a special column type called Related Issues which allows the user to link a given issue with any other issues in the same list. Here’s an example of what it looks like when creating a new item on the issues list:

As you can see, multiple other issues from the list can be selected and designated to the new issue.
A common request I get is to remove the ID from the display of Related Issues in the forms for creating and editing list items (newform.aspx and editform.aspx). The ID is incremented for each new item as it is created. This is good information to have, but as you can see above, it takes up valuable space in NewForm.aspx, making it difficult to read the issue title.

So how do we go about removing the ID from the Issues List? First we need to get some insight into where the Related Issues column is coming from so we begin by going into Advanced Settings under List Settings, and choosing to show content types.

Now in List Settings, a new Content Types section appears and we can see that the list uses a list content type called Issue, which inherits from a parent, also called Issue:

If we click on the parent, we find that we have reached a top-level site content type, whose parent is the base Item type, and that the Issue site content type uses a site column called Related Issues.

Unfortunately, we don’t find a way to customize the Related Issue in the browser so that it doesn’t use the ID value in NewForm.aspx. So now we have to dig deeper into the 12 hive (%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12). To do that, search the Template folder in the 12 hive for the Related Issue internal name which is shown in the URL when editing the Related Issues site column in a browser:

https://demo.cdh.com/_layouts/FldEditEx.aspx?CloseOnCancel=1&Field=RelatedIssues

We find that the field is referenced in a Feature called IssuesList, in the file schema.xml:

<Field ID=”{875fab27-6e95-463b-a4a6-82544f1027fb}”
Name=”RelatedIssues”
DisplaceOnUpgrade=”TRUE”
Type=”LookupMulti”
Mult=”TRUE”
DisplayName=”$Resources:core,Related_Issues;”
List=”Self”
ShowField=”Title”
PrependId=”TRUE”
SourceID=”http://schemas.microsoft.com/sharepoint/v3″
StaticName=”RelatedIssues” />

Now we find a parameter called PrependID, which certainly sounds like it is what we are looking for.
As a rule, it’s a bad idea to change any built-in files in the 12 hive, but just as an experiment.  Let’s save a copy of the file schema.xml, change PrependID from TRUE to FALSE, and reload the 12 hive into memory with an IISRESET. Now, when we examine NewForm.aspx in our Issues List, we find this:

BINGO! Now that we have proved the point, we must go back and put the original schema.xml file in place. To actually implement this fix safely, you need to create a new feature based on IssuesList, deploy that to your site collection, and use it to make new custom Issues Lists. But that’s another blog post.