Audit Trial / Document History

HCL Domino Domino Forum
1

Good Day:

I intend to keep the document history / audit trial with the user’s name, date & time the document has been changed and what the fields has been changed.

The code I tapped here is perferctly good but the limitation is I have to specify each of the field names one-by-one.

Any solution would help to make the program intelligent to indentify the data has been changed on which field instead of I have to name it one-by-one. Please take note that from time to time, there will be addtional field comes into my form.

Many thanks.

(Declarations)

Dim session As NotesSession

Dim old List As String

PostOpen

Sub Postopen(Source As Notesuidocument)

Set session = New NotesSession

old(“ABC”) = Source.FieldGetText(“ABC”)

old(“XYZ”) = Source.FieldGetText(“XYZ”)

End Sub

QuerySave

Sub Querysave(Source As Notesuidocument, Continue As Variant)

On Error Goto E

Source.Refresh

On Error Goto 0

initial = Source.IsNewDoc

If initial Then m$ = session.CommonUserName & " - " & Cstr(Now()) & " - created document"

Forall F In old

v$ = Source.FieldGetText(Listtag(F))

If Not initial And Not v$ = F Then

If m$ = “” Then

m$ = session.CommonUserName & " - " & Cstr(Now()) & " - modified "

Else

m$ = m$ & ", "

End If

If F = “” Then F = {“”}

m$ = m$ & Listtag(F) & " from " & F & " to " & v$

End If

F = v$

End Forall

If initial Then

Source.FieldSetText “History”, m$

Elseif Not m$ = “” Then

Source.FieldAppendText “History”, Chr$(10) & m$

End If

X: Exit Sub

E: Continue = False

Resume X

End Sub

Apart from the above, hope the reply can come with sorting the history in decending order - latest on the top.

Many thanks!

2

Subject: Audit Trial / Document History

Thomas Woehrer has an excellent LS history class. You can find it on his website (can’t remember the url at the moment) or at openntf.org in the code bin. His site address should be there as well, and I’d recommend using that version to get the latest updates. It is very easy to implement. While it DOES not auto fill the fields to be tracked, you can easily implement this in the post open (where the calling function will reside on the form anyway) by building your array of fields to track from the fields available on the form (though i recommend using a control document for this and just typing them in, then accessing this document in the postopen to create the array, or using a naming convention to achieve the same goal). The reason? In Notes/Domino applications, we often pass data around via fields or have fields whose purpose is simply to store something temporarily or do a calculation. If you have these fields on your form, you probably will not want them to be tracked in your history.

The only thing about the history class, which you will note in a recent post I made if you look at his site, is that it is designed to write the history to one field. This doesn’t format so well if you intend to use it in conjunction with a similar field logger for the web (client and web browser don’t handle tabs the same way). The History class can be modified to write each column to its own field. I don’t remember if the sort order is configurable, but there are plenty of examples for reversing lists in vb and ls on the web. A search for sorting arrays would probably find it on this site.

3

Subject: Audit Trial / Document History

Hi,

In the PostOpen event you could grab the values of each field by looping through until there are no fields left, these could be placed into an array. If you use the ‘Preserve’ statement and redim the array each time you will be able to dynamically grab the data of any form, if they have 2 or 18 fields.

If you do the same in the QuerySave event and compare the values you will be able to see what fields have changed.

Hope this helps.

4

Subject: RE: Audit Trial / Document History

The problem with this global approach is that it doesn’t distinguish between editable and computed fields. There is presumably no reason to waste valuable audit trail space on computed fields, and I’ve always felt that over-recording is almost as bad as under-recording in terms of usability of data.

I’ve been thinking about this recently a lot, and wonder if it would be helpful on my next such application if I named all the editable fields, or all the fields that will need auditing, with _e at the end, or something like that. This way, one could loop through all fields and only worry about the ones that end with “_e”.

Just musing,

raphael

5

Subject: RE: Audit Trial / Document History

On the flip side, some computed fields are tied to workflow and do need to be audited. Your idea of using a prefix or suffix on the fieldname is simple and effective, and one I have used in the past. In more complex applications I create a profile for each form and list out which fields need to be audited, then do a lookup to retrieve it.

– Charles

6

Subject: RE: Audit Trial / Document History

Thus, mean while, we can call the case close :slight_smile:

p/s: guess a lot of us don’t aware there are sites that stores a lot of good notes coding (Formula, JS, LS, etc…). IBM/Lotus should have it “publish” on the top of this Forum to bring awarness to everyone so less questions will be posted and reduce the redundancy…

Again, many thanks.

7

Subject: Audit Trial / Document History

Thomas Woehrer has an excellent LS history class. You can find it on his website (can’t remember the url at the moment) or at openntf.org in the code bin. His site address should be there as well, and I’d recommend using that version to get the latest updates. It is very easy to implement. While it DOES not auto fill the fields to be tracked, you can easily implement this in the post open (where the calling function will reside on the form anyway) by building your array of fields to track from the fields available on the form (though i recommend using a control document for this and just typing them in, then accessing this document in the postopen to create the array, or using a naming convention to achieve the same goal). The reason? In Notes/Domino applications, we often pass data around via fields or have fields whose purpose is simply to store something temporarily or do a calculation. If you have these fields on your form, you probably will not want them to be tracked in your history.

The only thing about the history class, which you will note in a recent post I made if you look at his site, is that it is designed to write the history to one field. This doesn’t format so well if you intend to use it in conjunction with a similar field logger for the web (client and web browser don’t handle tabs the same way). The History class can be modified to write each column to its own field. I don’t remember if the sort order is configurable, but there are plenty of examples for reversing lists in vb and ls on the web. A search for sorting arrays would probably find it on this site.