Cross posting this from Reddit, since it's not getting a lot of love there.

One of the biggest challenges I have with getting users to buy in to SharePoint's versioning features is the fact that version history is kind of a PIA (from a user experience perspective) to get to. Adding to that, if you use an append only comments field, and you happen to have an item (say, a project tracking line item) that takes a lot of updates over time, the form can get unwieldy and stupid to deal with. I get a ton of complaints about that.

So, I had the brilliant idea to use a little javascript/jquery magic to go GET the version history page for an item and remake it into something that could be viewable on the edit/view item form. Here's my code (don't laugh at me, I literally taught myself javascript last year on the job):

function getVersionHistory(guid,id){
    var d=$.Deferred()
    var versionsUrl=url+'/_layouts/versions.aspx?list='+guid+'&ID='+id;
        var versionEntries=parseVersionList(data);
    return d.promise();

function parseVersionList(data){
    var items=[];
    var versionList=$(data).find('table.ms-settingsframe > tbody > tr[class]').each(function(i){
        var item={};
        if(i > 0 && (i-1) % 2 == 0) {
            var row=$(this);
                    item.notes=row.find('tr[id*="ProjectUpdates"] > td.ms-vb:not(:empty)').text();
                var previous=$(this).attr('title').split(': ');
                var field=$(this).find('td.ms-propertysheet').html().trim();
                var newValue=$(this).find('td.ms-vb').html().trim();
                var change={field:field,preV:previous[1],newV:newValue};
    return items;

Your mileage may vary on that, but that appears to be all the correct classes/elements for parsing the HTML on the version history page. getVersionHistory(), given the list's GUID and item ID, returns an object that I then pass into a handlebars template for rendering a nice little Office UI-ish card.

Now, to my actual problem: on the version history page, anything over 250 characters in the append-only comments (AOC) field gets cut. But only on the version history page. If I look at the edit form with the AOC, you can see the full text.

So, therein lies my dilemma. What would you all do with this? Should I scrape up the previous AOC entries from the edit form and try and shoehorn them into my version history object somehow? Should I stop trying to placate my users and let them deal with an edit form that can scroll out to infinity when the AOC entries get voluminous?

1 Answer 1


Well, I decided to go ahead and scrape the full note text off of the edit form and work it into my version card, like so:

//Get the updates.
var updates=$('span[data-displayName="ProjectUpdates"] > div').contents();

//Parse each one into a div.
for(var i=0;i<updates.length;i+=7){updates.slice(i,i+7).wrapAll('<div class="update"></div>')};

//Work through the div and create an object with the notes and the last modified date.
updates.map(function(i,u){var update={},eot=$(u).text().indexOf('M): ')+4;update.fullText=$(u).text().substring(eot);update.dateTime=$(u).children()[1].innerHTML;updateFullText.push(update)});

Then, once I'm building my little version card, I just compare the last modified date on the version history page with the one I grabbed from the on screen text. If they match, I create a new object property called "fullTextNotes" and put that in an if/then statement in my handlebars template. Then I used a jQuery plugin to keep the text truncated until the user wants to look at the whole thing.

Hopefully this will be helpful to someone else.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.