Thursday, January 15, 2009

Creating custom Item ID's

A customer would like to use custom ID's to track items throughout the site. These ID's are something like:

I would like to delete the Title field and use this throughout the system, but this causes some problems. I can't rename Title without renaming Title on every item in the entire site. I can hide title, and create my own column, but then I have to create custom datasheet views everywhere because Title is the only field that has a link to the new form, and has the drop down list available. I suppose I'll just have to use the Edit link everywhere.

Creating a custom ID field should be easy right? Just use a calculated field you say!
Sadly, it's not that simple. First, I would like to have the ID portion padded to 4 spaces. ie. 0001, 0021, etc. This causes some troubles. Second and most important, the ID field is set after the calculated field is set. If you do this strictly through a calculated field, you'll end up with TYPE_DATE_0000.

Ok, so then do it with a workflow! This solves the ID being 0 problem, but the Designer workflows don't seem to support the formula's needed to create the Date in a YYYYMMDD format. If you just use Created as the date, you'll end up with something like: TYPE_1/15/2009 8:43:03 AM_0001. UGLY.

The solution is to use a hybrid of both. Create a calculated field that is:
Next, create a workflow that is activated on New item created for you're list. The workflow will need two steps.
The first step is to create the necessary padding for your ID. Mine is something like:

If ID < 10 set variable 'padding' = '000'
if ID >=10 and ID <100 set variable 'padding' = '00'
If ID >=100 and ID <1000 set variable 'padding' = '0'

Next, set the prefix = 'TYPE' or whatever you want. If this is dynamic, you'll need another step to set this to be what you want.

Use the string builder to put all your variables together. [PREFIX]_[createDate]_[padding][ID]

Set your Identifier field to the new variable you created with the string builder. DONE!

Tuesday, January 13, 2009

Changing Title Site Column name

When creating a new site content type you are required to choose a type that it will inherit from. The simplest type is a list content type who's parent is 'Item'.
The problem is that you'll end up with a default column called 'Title'. Great, what if I don't want a column called Title?

This column is inherited by every list item across the site. If you change the name, the entire site will change! What really gets you, is that you can't change it back!
The form checks and see's that the name 'Title' is reserved. It doesn't care that you're not using it anymore.

If you've already done this, There is a way to change it back. (

Here's the basic idea:
Open the page that lets you change the name and save it to your computer(the complete page). Open the page, and remove the javascript that does the check:

if (doesFieldNameConflict(DisplayName))
return false;

Open the page, rename it back to "Title" and hit save. SharePoint isn't smart enough to realize that the page lives on your computer and not the server. It will let you change it back.

The right solution is to edit your site content type, and change the 'Title' field to be hidden. Then create a new column called Title, or whatever you want to name it.

The problem this creates, is that whenever you have a view of the list, the Title field is the one that is used to link to the DispForm, and also has the drop down list of options to modify that row.
The only solutions I've seen so far is to create your content types with a feature. This isn't a good solution when you're trying to prototype something though.

Importing and Exporting Webparts

Frequently, I find myself creating XSLT data view webparts because the out of the box layouts don't cut it.

I found that if a webpart is added to the page using the browser, then edited in designer and converted into a XSLT view, it can cause problems. I was no longer able to export the webpart and import it to another page.

Unfortunately, to work on a webpart in designer, it has to be on a web part page since you have to break the page from the template. I then exported the webpart and imported it to a normal publishing page. The webpart imports, but causes the page to error out. You must then edit the page in the maintenance view and remove the offending webpart(the last one listed, since they are listed in order they were added to the page).

So, add your webparts in Designer as a Dataview, edit them in designer, and move them later. Sorry if you're trying to edit one you created in the browser and converted to an XSLT view, just start over and save your self a headache later.

Friday, January 9, 2009

Customizing List Forms using Javascript

A cool feature you can get access to using SharePoint Designer is the ability to create your own List forms. You can create a new NewForm page, with certain fields removed, or add the form to another page, allowing users to create or edit a new item without having to dig into the appropriate NewForm or EditForm.

In Designer, it's under the Insert -> SharePoint Controls -> Custom List Form.

I've been using this recently, and I wanted to be able to manipulate the fields using JavaScript. I would like to pre-fill certain fields with data, and hopefully create a better user experience.

So far, I've found two pages to be helpful:
Accessing and Changing Form fields -

There is an example about halfway down for grabbing a people Picker field. Looks like it can only grab the first one?

I also needed to be able to grab and edit a Radio Button option
One solution I found was at:

This solution didn't work for me, it was looking for:

somewhere in the parent's innerHTML. My customized forms don't have that. I changed the code to look up another level and look for the Field name there. Seems to work ok. Example below:

function SetRadio(tagName, identifier, title, value) {
var len = identifier.length;
var tags = document.getElementsByTagName(tagName);
for (var i=0; i < idstring =" tags[i].id;" namestring =" tags[i].name;" type ="="" identifier ="="" tagparenthtml =" tags[i].parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.parentElement.innerHTML;">'+title) > -1) {
var radioButtons = document.getElementsByName(nameString);
var radioValue = "";

for (var x=0; x < radioButtons.length; x++) {
if(radioButtons[x].parentElement.title == value){
radioButtons[x].checked = true;
radioButtons[x].checked = false;
return null;

Tuesday, January 6, 2009

Workflows and "The data source control failed to execute the insert command. "

I recently took over the design of a site that makes heavy use of Designer created workflows and custom Edit Forms.

While trying to figure out how the system worked, I ran into this error when starting a workflow:
"The data source control failed to execute the insert command. "

After googling around for a few minutes, I found this:

I had never actually seen the remove workflow page on a list before. Interesting. I was able to remove the workflow from the list. Once I re-opened the workflow and saved it, the workflow starting working again. Weird. But at least it works again.