The requirement has come to fruition to see the elapsed time from the “Modified Date” to “Now” on a reports document library. This is not possible in a calculated value unfortunately do to [Today] and [Me] values being consumed in a calculated value are considered “Volatile” by SharePoint out of the box. These use the core MOSS/WSS functions and since the list is 100% dynamic it doesn’t pull session or current state information before loading the list on page load. Every possible solution was attempted prior to using this custom solution. Although this is all “client side” customization all methods of using out of the box methods were tried prior to this solutions development, the downfall being that even when [Today] was able to be used in a calculated value it did not record the time, only the current date.

Required Items

This solution involves slight modification of Meta Data through a simple SharePoint Designer workflow, a short JavaScript function, and the creation of a “Last Updated” field that is a Date and Time field. Below are step by step instructions with screen shots of how to properly customize any List or Document Library to use this functionality. SharePoint Designer, .NET Frame Work 3.5, and WSS 3.0 are required to implement this solution.

Elapsed Time

Create or open an existing document library and go to settings.

Figure 1 Document Library Settings

Click Create Column

Figure 2 Create Column

Name the Column “Last Updated” (Red) and make it a Date & Time column (Blue)

Figure 3 Configure Column

Click Save, and go back to the Document Library page. Click Site Actions, and Edit Page.

Figure 4 Edit Page

Click Add a Web Part and select a Content Editor Web Part and click add.

Figure 5 Add a Web Part

Figure 6 Content Editor Web Part

Select Edit on the Content Editor Web Part and select Modified Shared Web Part

Figure 7 Modify Web Part

Select source editor and copy the following into the source box and click save.

I used the below code from this website: http://www.endusersharepoint.com/2009/01/23/jquery-for-everyone-replacing-today/

Source:

<script src=”http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js” type=”text/javascript”></script>

<script type=”text/javascript”>

$(function() {

var str = “Last Updated”; //change this based on col header

var today = new Date();

today = Date.parse(today)/1000;

var a=0;

var headers = $(“table.ms-listviewtable:first> tbody> tr:first th”).get();

$.each(headers, function(i,e){

x = $(e).contents().find(“a[title*='"+str+"']“).length;

a = x > 0 && i > a ? i : a;

});

var dArray = $(“table.ms-listviewtable:first> tbody> tr:gt(0)”).find(“>td:eq(“+a+”)”).get()

$.each(dArray, function(i,e){       �

var d1 = Date.parse($(e).text())/1000;

var dd = (today-d1)/86400;

var dh = (dd-Math.floor(dd))*24;

var dm = (dh-Math.floor(dh))*60;

var time = ((Math.floor(dd) > 0 ? Math.floor(dd) +” days, ” : “”)+

(Math.floor(dh) > 0 ? Math.floor(dh)+” hrs, ” : “”)+

(Math.floor(dm)+” min”));

$(e).text(time);

});

});

</script>

Figure 8 Source Editor Selection

Figure 9 Source Editor Input

Open the page in SharePoint Designer and create a new workflow file.

Figure 10 Create a Workflow

Name the workflow as “SetLUAsModified” select the list to attach as the document library you are using and select on create and on edit as when the workflow will run.

Figure 11 Set Last Updated Time

Click next and now create your Action, we are setting the last updated field to equal modified. Go to the Actions Drop down and select set field in current item (Red), then set value 1 as “Last Updated” and Value 2 as “Current Item” “Modified” (Blue)

Figure 12 Set Field

Figure 13 Set Last Updated

Figure 14 Set Modified

Save the Workflow and go back to the site, add a document to the library or edit an existing document and the “Last Updated” field will change to 0 minutes.

Figure 15 Test Results

The Document Library drives this Workflow not the List.

As seen in the previous blog, Step 1 is the ChangeTitle step and this copies the File Name into the Title Column, the rationale was to maintain unique file names but keep the documents grouped by non-unique Titles.

Step 2 is new and it is the “CreateListItem” step.  This creates the item in the list if it not already there.  Validating that it is not there maintains only one record in the List while allowing for multiple records in the Library.  I validate it off of the current item (Document) title but it ensures that there is no such record in the List which maintains an accurate “Version” count.  Once this validation has completed the list Item is completed, if there is already an item with like Title in the list it skips to Step 3 which sets the Version count.  The Item is created the Title is copied from the Current Item (Document) and the Version Count is set to 0.  Please see the Screen Shots Below for “CreateListItem” Step.

Step 3 adds 1 to the current version # in the List.  If this is a new document it becomes Version 1, if it is an old document it is version x + 1.  We will use this field to create a variable to add to our New Calculated value we are calling this step “SetCount” and it updates the lists count and stores a “calc” variable.  The calc variable set in step three will enable the “Versioning” as seen in Step 4.  Please see the Screen Shots Below.

Step 4 has been modified slightly, as before the pause was to give time for the File Name to enter into the calculated value, since this step actually places the “Count” Value into the Item and Calculated Values pull from the Item itself the pause has been moved to below the input of the calc variable into the “Count” field on the current item.  The pause allows for the calculated value NameCount to wait for the Count variable to be added which takes about 30 seconds, however 1 minute is the shortest pause possible in SharePoint Designer.  Please see the screen shot below:

There will be a third post regarding this effort as far as adding the JavaScript mouse over tool tips for the groups by title in the default view.

Ok… so you’ve done it, you’ve dared to click the ‘Add Web Part’ button and have ‘ooohhed’ and ‘ahhhed’ at the enormous list of available Web Parts.   Of course, each Web Part provides its own special function that can lend support to how content is displayed on your site.  Through trial and error I have spent time learning functionality of available Web Parts.  Over time– and with some creative application –I have also learned alternate uses to some of the commonly used ones.   Probably my favorite, or at least the one I use most often, is the Content Editor Web Part (CEWP).  I use this Web Part for a variety of different things such as for the creation of site banners and as a broadcast tool, which I’ll write about in my next blog.  I also use the CEWP to create navigational buttons:

Buttons Example

Buttons are another way we can provide intuitive navigation for our site users.

Situations where use of buttons may be appropriate:

• To provide easy access to other related SharePoint sites (that may be several clicks away).  For example, when implementing sites, you may choose to add a help button that links to a Technical FAQ Wiki.
• To provide navigation in a Web Part Page (WPP).  Unless we access the code and ‘unblock’ the Quick Launch bar we don’t get that navigational tool in a Web Part Page.  Using breadcrumbs to navigate out of a WPP can also be confusing to novice SharePoint users, because the breadcrumbs (of course) map to the library holding this file.   Because of this, whenever I create a WPP I like to give users a ‘home’ button to give them easy access back to where they came from.

• To provide links into specific list and library views.  Remember when you change views in a list or library, the URL also changes.  You can use that path to provide users a link directly to a filtered view– for example, to provide a view of items that have been recently added –or to provide direct access a new list item form.

• To provide access to an external site or a network directory.  If you have an address for it, you can link to it (it doesn’t have to be another SharePoint site).

The point is to provide your site users with navigation that is intuitive and easy to use.  Buttons certainly fit the bill on both criteria.  Ok, have I sparked your interest yet?  The below steps will demonstrate how you use a CEWP to add a button to your page:

*Note: To create a button using the CEWP, you’ll need to begin by uploading the graphic you want to use as a button, to a SharePoint library.  The steps below assume that you have already taken this action.  * A friendly reminder, make sure those accessing the site displaying the button, have at least ‘read’ access to the image file.

To create a button using a CEWP:

1.     On the site where you wish to add the button, click Site Actions then Edit Page.

2.      Click Add a Web Part.

3.      Select and add a Content Editor Web Part (displayed under the Miscellaneous category).

4.      To configure your new Web Part, click on the Edit drop-down and select the option Modify Shared Web Part.

5.      In the Properties box (displayed on the right hand side of your screen), click on the Rich Text Editor button.

6.      In the HTML Editor box that appears, click the Insert Image icon.

7.      In the Edit Image Properties window enter the path to the image, or use the browse button to navigate to, select, and add the image.

8.      In the HTML Editor window, click the image (that you just added to your CEWP) to select it.

9.      Use the Insert Hyperlink icon in the toolbar to map a destination path.

10.  Either browse to a location within your site collection, or type (or paste) in a path.

11.  Click OK to accept the path.

12.  Click OK again to exit the HTML Editor window.

13.  Turn off the chrome (you probably don’t want a title for your button), by expanding the Appearance section of the Web Part Properties box, and change Chrome Type to None.

14.  Click OK at the bottom of the Web Part Properties box.

15. Click Exit Edit Mode.

You now have a new button- Congratulations!

Happy ‘SharePointing’