Maarten Eekels's SharePoint blog

A very convenient URL parameter in SharePoint is the Source parameter. If you click on an item in a list for example, you’ll notice this Source parameter in the URL (e.g. /Lists/Projects/DispForm.aspx?ID=31&Source=http%3A%2F%2Fdev-server%2Fcorporate%2FLists%2FProjects%2FAllItems%2Easpx) Now when you click the Close button, you are redirected to the page where you came from. Of course this is also possible with a history.back() call, but there are situations when this won’t work. For example, what if you have custom columns on your NewForm.aspx that require a postback? So the Source parameter is a very neat feature to redirect a user to where he/she came from.

In DataView web parts, you might want to create your own dynamic URLs (inserting parameters from the Data Source into your URL), and have the user redirected back to the page with the DataView web part instead of the SharePoint list where the item was created. For example, we have a customer site for each of our customers. From the home page of such a site, we’d like to create a new item in a Projects list (which is located at a site higher in the hierarchy). Next when the user clicks the OK button, the user should be redirected back to the customer site. We can do this by manually adding the Source parameter to the URL:

<a>

<xsl:attribute name="href">/corporate/Lists/Projects/NewForm.aspx?AccountID=<xsl:value-of select="@AccountID" />

<xsl:text>&amp;Source=/corporate/customers/triplea</xsl:text>

</xsl:attribute>Create customer project</a>

(as a side note, you can also use the NewItem Javascript function for creating new list items, but this is beyond the scope of this article)

But what if the Source URL is actually also a dynamic URL, with some own parameters (like ID= and List= in a Workflow Task Form)? Javascript to the rescue! SharePoint comes with two great Javascript functions: GoToPage and GoToLink, which add the Source parameter to a URL automatically. I’ll discuss the difference between these two in a minute. Let’s change the URL XSLT example above to include the GoToLink function:

<a><xsl:attribute name="href">/corporate/Lists/Projects/NewForm.aspx?AccountID=<xsl:value-of select="@AccountID" />

</xsl:attribute><xsl:attribute name="OnClick"> GoToLink(this);return false;</xsl:attribute>

<xsl:attribute name="target">_self</xsl:attribute>Create customer project</a>

With this format, we can use this XSLT for example on a Workflow Task Form, from where the user can click the link, fills out the project details, clicks OK, returns to the Workflow Task Form, and completes the task.

So what about the difference between the GoToPage and GoToLink functions? Both functions are available in SharePoint pages. Both functions seem to do exactly the same, but there are some differences.

First, there is the location of the functions. The GoToPage function is available from the INIT.JS libray, the GoToLink function comes from the CORE.JS library.

Next, there is a slight difference in functionality. Let me first show both functions (the GoToPage function calls another function, called STSNavigate, so I’ll show this function as well, where the GoToLink function does exactly the same on its own):

GoToPage

function STSNavigate(Url)

{

    if (isPortalTemplatePage(Url))

        window.top.location=STSPageUrlValidation(Url);

    else

        window.location=STSPageUrlValidation(Url);

}

function GoToPage(url)

{

    var ch=url.indexOf("?") >=0 ? "&" : "?";

    var srcUrl=GetSource();

    if (srcUrl !=null && srcUrl !="")

        url+=ch+"Source="+srcUrl;

    STSNavigate(url);

}

GoToLink

function GoToLink(elm)

{

    if (elm.href==null)

        return;

    var ch=elm.href.indexOf("?") >=0 ? "&" : "?";

    var srcUrl=GetSource();

    if (srcUrl !=null && srcUrl !="")

        srcUrl=ch+"Source="+srcUrl;

    var targetUrl=elm.href+srcUrl;

    if (isPortalTemplatePage(targetUrl))

        window.top.location=STSPageUrlValidation(targetUrl);

    else

        window.location=STSPageUrlValidation(targetUrl);

}

Now, what we notice, is the GoToPage function expects a full URL as input, where the GoToLink function reads the href tag of the element. So in the GoToLink function you can use this as parameter, taking the value of the href tag as input parameter. Less error prone, and easier to maintain. But in the GoToPage function, you can use another URL in the href tag, than in the actual Javascript parameter. So you can show a different URL in the status bar of the user’s browser, than the actual URL the user is redirected to. Also quite nice in some occasions!

Using Word templates in combination with Content Types in SharePoint gives a user a rich experience in using SharePoint metadata in the content of a Word document.

For example: if you are making the meeting minutes for a certain meeting, you would like to have the Meeting Date as meta data of the document, but that same Meeting Date is probably also used in the minutes document itself somewhere.

So we could insert meta data columns as Document Property Quick Parts in the Word document. That way, entering the meta data information in the document information panel, will automatically update the Quick Parts in the document itself as well. If you have never done this before, no worries, I will show you how this works later on.

Now this all works well for SharePoint columns of every type, but lookup columns. Lookup columns have a typical way of storing data. What is you see is not what you get. When you use a lookup column to a SharePoint list, what you see as meta data is the Title field of that SharePoint list, but the value of the lookup column is actually the item ID of the list item you select in your lookup column. So when you insert this lookup column Document Property as a Quick Part in your Word document, not the Title field is shown in your document, but the item ID.

What I will describe in this blog posting is a way to work around this problem.

Let’s take the meeting minutes document as an example again. A typical minutes document could look like this:

Now what we would like as meta data of this document is the subtitle (let’s use the Title field for this), the Meeting Date, and the associated Project the meeting was held for. So let’s create a Content Type called Meeting Minutes as the screenshot below:

What you can see already, is two columns for the Project meta data. This is necessary for my work around to work, as you’ll see later on.

Under Advanced settings, upload your Word template for your meeting minutes.

Now we will create a custom Document Information Panel in InfoPath. Click Document Information Panel settings. Click Create a new custom template.

This will fire up InfoPath. InfoPath will first tell you that it will create a form template for your custom content type, and you need to publish the template if you’d like to use it. Duh! Click Finish. And there you have your Document Information Panel.

What we need to do, is have the Project field automatically updated when you choose a project from the Project Lookup. Do this as following: Double click the Project text box. In the Text Box Properties window, click the fx button next to Value. Click Insert Field or Group…. In the Data source drop down, select the data source starting with list_, and select the Title dataField.

We need to filter the Title value. Click Filter Data… and next Add… In the first drop down select ID, then is equal to, then select a field or group… Now choose the Main data source and select the Project dataField.

Click a few times OK, until all windows are closed, and you’re back at your InfoPath form.

 Before you close the last window, you could also decide to make the Project field read-only:

Save your InfoPath form (File –> Save as), and then publish it (File –> Publish), Next, Publish, Close.

Now we are going to add the meta data as Quick Parts in your Word template. Attach the new Content Type to a Document Library of your choice and start a new Word document from this Content Type.

On the Insert ribbon, click Quick Parts, then Document Property, and then insert the properties you like on the places in your document of your likings. The document will look like this:

Be sure to insert the Project property and not the Project Lookup property. If you insert the Project Lookup property, you will see the ID of the project will be inserted in your Word document, instead of the name of the project.

Finally, save this document and re-upload it as the template in your Content Type.

Now you have a SharePoint Content Type with a Word template attached, where Word content and meta data are in sync.

As some of you may already know, there is a problem with the SharePoint List attachments functionality if you use Custom List Forms: you lose it all. If you create a custom NewForm.aspx or EditForm.aspx, with a custom List Form control, the ability to add or delete attachments to a list item disappears.

Marc Davis has described a workaround on his Blog here, which is not supported by Microsoft, but works well.

Recently I encountered a situation at a customer's site, where only the DispForm.aspx had to be modified, because of some required re-formatting of list item values. I figured I didn't have to go through the whole process described by Marc, since all I wanted back was the functionality to display the list item attachments, not the upload and delete functionality (the NewForm.aspx and EditForm.aspx didn't need any customization, and these pages have the proper attachment functionality in place).

This turned out to be quite easy: you can use the SharePoint control AttachmentsField.

Here's the code I added in the dvt_1.rowview XSL template, part of the DataFormWebPart that SharePoint Designer creates for you when you insert a Custom List Form:

     <tr>
      <td width="190px" valign="top" class="ms-formlabel">
       <h3 class="ms-standardheader">
        <nobr>Attachments</nobr>
       </h3>
      </td>
      <td width="400px" valign="top" class="ms-formbody">
       <SharePoint:AttachmentsField ControlMode="Display" FieldName="Attachments" runat="server" Visible="true"/>
      </td>
     </tr>

That's it! Your list item attachements are back in your custom DispForm.aspx

P.S.: Of course, you should never edit your DispForm.aspx directly, but always leave it intact and create a new aspx page, based on the DispForm.aspx.

Update 16-09-2008:

I found out today, that Microsoft has released a knowledge base article a few days ago about this issue. It seems they have solved the issue regarding the adding and deleting of attachments in the Infrastructure Update for SharePoint. You still have to do some XSL editing, but hey, since you are creating a custom list form, my guess is you are doing this already. You can find the knowledge base article here: http://support.microsoft.com/kb/953271

A scenario that we encounter a lot, is where you have a project landing site with individual project sites below. On the landing site you have a SharePoint list with all your projects and on each individual project site, you would like to show the project details from this list of the parent site.

Basically this would mean you would have to add a Data View Web Part on the project site to show data from the Projects list of the parent site, and filter the data is some sort of way to show only the data for the appropriate project. This works quite well of course, but you don't want your users to have to set that filter every time they create a new project site. So what we would like is to set the filter in the project site template.

Of course you never know beforehand what actual value to filter the list data on, so we have to create a dynamic filter solution. My solution is to filter the list data in the Data View Web Part using the URL of the project site. This means that people creating a project site, should use the project name or project number (or any other unique column value you use in your Projects list) as the URL of the project site. In my example, the URL of the projects landing site is http://servername/sites/projectnet.

I assume you know how to add a Data View Web Part to the default.aspx page with SharePoint Designer. You'll also need SharePoint Designer to make the modifications I suggest below.

1. From the “Common Data View Tasks” menu, click “Parameters.”, click “New Parameter”, type “CurrentURL” as the Parameter Name, choose “Server Variable” as the Parameter Source, and type “URL” as the Server Variable Name.

   

2. From the “Common Data View Tasks” menu, click “Filter:”, enable “Add XSLT Filtering”, and click “Edit.”.

   

3. Enter the following XPath expression:

   [@ProjectName=substring-after(substring-before($CurrentURL,'/default.aspx'),'/projectnet/')]

   Where @ProjectName is the name of the column from your Projects list you would like to filter on, and /projectnet/ is the part of the URL preceding your project site URL (probably your project landing site).

Save your site as a SharePoint Site Template and every new project site should automatically show the project details on its default.aspx page

Recently, I received an intriguing question from a client of ours.

They have a document library with a lot of project documents, mainly meeting agendas and minutes, but some other important documents as well. Now what they would like is filtering out the older agendas and minutes, but not all the other document types. So just setting a Filter in a List View won’t do it. Here’s what you should do:

I assume you already have some kind of Document Type Column in your document library, to differentiate the types of document you use. I have named this column DocumentType and I have four types of documents: Action Plan, Agenda, Business Case, and Minutes. Now I only want to see the Agendas and Minutes from the past two months, and the Action Plan and Business Case.

1. In the Document Library, create a new Column to store some kind of flag which we can use to filter documents on in our View. I created an Archive column of type Yes/No, default No.

   

2. Next, create a new workflow with SharePoint Designer. I called it “Set Archive Status to Yes”. Make sure you enable the “Allow this workflow to be manually started from an item” option and disable the other two start options. Click Next. Choose the Document Types you would like to set the Archive flag for in the Conditions part, and set the Archive flag in the Actions part.

   

3. Finally, you have to create a policy on the document library, to call the workflow you just created. Go to you Document Library settings, and click the “Information management policy settings” link. Choose “Define a policy…” and click OK. Enable Expiration, choose the time period after which you would like to execute your workflow and select the workflow you created under step 2.

   

Voilà, you’re done! Of course you would have to modify your list view to filter out the documents with Archive set to No.