Logging edits to a record

Dan, may you check the code:
(function(){
  var querystring=document.location.search;

  if(/a=er/i.test(querystring)) {

$("#_fid_797").attr("readonly", "readonly");

var label, oldValue, newValue, log;

$("#_fid_242,#_fid_138").on("change", function() {

  log = [];
  _.each([242,138], function(fid) {
    oldValue = $("[name=_fid_oval_" + fid + "]").val();
    newValue = $("#_fid_" + fid).val();
    if (oldValue != newValue) {
      label = $("label[for=_fid_" + fid + "]").text();
      log.push(label + " was =" + oldValue + "; now =" + newValue);
    }
  });
  $("#_fid_797").html(log.join("\n"));
      });
    }
})();


Thank you!

Inconsistent indentation. Fixed here:

http://pastie.org/9607867

What is not working?

Nop...Still typing in the same line...
May be you did change the properties for the [Log] field?

[Log] is a multi-line text field.

You did it! Thank you!

Celebrate - run through your office singing the Banana Boat Song. Here are the lyrics:

http://www.azlyrics.com/lyrics/harrybelafonte/dayothebananaboatsong.html

Thank you, Dan!
Have a wonderful day too!

Hello, Dan!
Everything runs great! Only one problem: the [Log] field takes too much space, a lot of changes in the Project. Than more changes then more longer field. The question is how to organize it?
The ideal would be to see only a few latest changes and other just hide, something similar to messages like 1,2,3 pages... Or may be to create a separate table for tracking...
Thank you!

> ...more changes then more longer field.

But this is the natural result of logging all the changes - it is going to take up more space if there are numerous changes. Beyond the general idea of using script to log changes to fields, you could track just the last n changes or perhaps just the changes made during the last 30 days. And where you store the changes is another dimension you can explore.

Also I should mention that the code I provided works for simple text and numeric fields. If you start logging checkboxes or lookup fields additional logic is needed. Date fields create another complexity. Date fields changed by direct user input  trigger a change event but dates entered through the popup calendar are made through JavaScript an do not generate a change event (you have to use periodic polling to detect date changes). These issues have come up (and have been solved) with some clients exploring other logging scenarios. This is the type of solution which will evolve as users try it out.

Ok. That's interesting to store date just n-days. Would you please clarify how to do it.
For example, it would be meaningful to store the changes for 7 days.