This project has moved and is read-only. For the latest updates, please go here.

amateur tracking/audit script

Oct 8, 2014 at 1:35 PM
Edited Oct 8, 2014 at 3:16 PM
I have been curious about how some of our 2007 SharePoint site is actually being used. I had tried the normal administrative tracking tools but was frustrated about the lack of control over what is tracked and that they seemed to bog things down. Also, I didn't like having to use admin level tools. So I selectively added some JavaScript to the pages of interest. And of course the JavaScript used SPServices to write the tracking information to a SharePoint list. I've just started using this and so I haven't dealt with the potentially large number of list items this could create (this is a small site). I thought I would post this code here to help others do some specific tracking and get feedback on making it better. Currently I'm just adding the code to the page that I'm interested in, but it could be extended to a more generalized jQuery function that is more easily attached to the piece of the DOM that you are interested in monitoring.

I suppose that when I get tired of managing the tracking list, I will add a check to function to see if tracking is enabled.

Below is the code, which is mostly derived from either the SPServices documentation or SPServices discussions.
<script language="javascript" type="text/javascript">

    function reportUsageSPTool(action, title, list, site) {
// must be called after jquery and spservices (at least version 2013.01)
// all arguments are optional
    var action = action || "Page ready";
    var list = list || "Page Track";
    var site = site || $().SPServices.SPGetCurrentSite();
    var title = title || "";
// get user ID
    var thisUserAccount = $().SPServices.SPGetCurrentUser({
        fieldName: "ID",
        debug: false
// get URL
    var url      =  $(location).attr('href');     // returns full url 
// get current date and time
    var thisDate = $().SPServices.SPConvertDateToISO();
// setup the newID (global variable) as a return state
    newID = 0;
// write a new list item with this information
// changed async to true based on Marc's suggestion
                       operation: "UpdateListItems",
                       async: true,
                       batchCmd: "New",
                       webURL: site,
                       listName: list,
                       valuepairs: [["Title",title],["pageURL", url],["who",thisUserAccount],["when", thisDate],["action", action]],
                       completefunc: function(xData, Status) {
                           newID = $(xData.responseXML).SPFilterNode("z:row").attr("ows_ID");
                           //alert("Status: "+Status+" newID: "+newID+" XData: " + xData.responseText);
    return newID
    } // end reportUsage

    $(document).ready(function() {  
       var listID=reportUsageSPTool("Page ready","test title");
       //alert (listID);
Oct 8, 2014 at 2:19 PM
Not bad! This amounts to a poor man's auditing tool. The nice thing about it is that you get list data rather than something hidden away for administrators. Yes, you have some potential volume issues, but if you copy out the data from time to time to Excel or Access, you could mitigate that as well as get some better analytics capabilities.

One important suggestion I would make would be to convert from synchronous calls to promise-based calls. That will mean that the page load time won't be affected if the write to the list is slow.