I need help with a very simple modification log

[balooka]

Hi

I would like to have a log or list of users that modified a record, but I do not really need to see what they have modified. Anyway, I have tried using the on commit script trigger to fill a table with record ID, timestamp and account name, which in a way works but the problem with this is that every time something is modified in a record, like a radiobutton the script will trigger if the user clicks somewhere else on the same layout and same record. So it commits a lot of times, filling the table with countless and useless entries. I would like to see only the ten (or so) last users to modify the record (not those that only viewed it!). I can use a timer to do a nightly run and delete all entries that are over 10, but I have no idea how to stop it from filling up the table.

My script is now:

if Get(ModifiedFields) = "", do nothing

else

set current record and user values in a var and create a new record in the acces table.

 

It's triggered by the on commit script trigger.

(My FM is Dutch so the translation might be a bit off).

 

I am aware that there a solution that track everything, but all I need is so see who actually accessed and modified a record.

Thanks!

[comment]

26 minutes ago, balooka said:

So it commits a lot of times, filling the table with countless and useless entries. I would like to see only the ten (or so) last users to modify the record (not those that only viewed it!).

I am not sure I understand your request. If user A has modified (and committed) a record 10 times, then a list of 10 last users to modify the record would have 10 entries of A. Or didi you mean the last 10 distinct users to modify the record?

Also, why do you need to create a new record in another table? Wouldn't a field in the same table (showing a return-separated list of up to 10 user names) be sufficient?

 

[balooka]

Hi Comment,

 

You are correct when a user has modified a record ten different times it would need to show up ten times in the list (with a different timestamp). I have that now, but I saw a massive record increase in the new table and found that when a user opens a record and modifies a field and clicks somewhere on the layout in the same record, it commits. If a user modifies 10 fields and clicks on the layout between modifying the fields, it would commit 10 times. The result I now get is the same user modified the record 10 times when all that the user did was modify the whole record just once. In other words, this user only should have been mentioned once because he/she modified the record once, multiple fields, but just one record.

Problem I have seems to be that the record commits when you leave a field in a record, rather than when you leave a record.

 

A list of ten would indeed be much more efficient, I have to figure that out then (unless you have a working snippet for me?)

 

[Wim Decorte]

7 hours ago, balooka said:

Hi Comment,

Problem I have seems to be that the record commits when you leave a field in a record, rather than when you leave a record.

It's more nuanced than that.  Just leaving a field does not commit a record.  But clicking outside of a field and not into another field does.  Or going to another layout.  And plenty of other actions.  Understanding when FM commits is crucial to building a good audit log.

A simple trick to block those accidental 'clicks in the background' from committing is to use an empty web viewer that is the size of your layout and is at the bottom of the stack order.  There are other approaches too that may fit better with your intended workflow.

7 hours ago, balooka said:

Hi Comment,

The result I now get is the same user modified the record 10 times when all that the user did was modify the whole record just once. In other words, this user only should have been mentioned once because he/she modified the record once, multiple fields, but just one record.

Again: this is crucial to understand and create your workflow and layouts accordingly.  The user DID do 10 separate record modifications.  Each time FM had to commit, communicate with the server, re-open the record for the next field, check for record locks, communicate with the server.   That's what FM does with the design you put together.

If you don't want this to happen then you have change your design...

[balooka]

Thanks Wim

I seem to always assume that some things are pretty basic and would not involve that much hassle. I'm not in the position (time wise) to redo my designs, unfortunately. 

I tried to work around this by having am 'on commit' script trigger to set a field to 'yes'. So even if there are 10 modifications in a single record, the value would still be just one 'yes'.

I then made a second script that was triggered by the 'OnLoadRecord' script trigger (not sure what the English translation is) and using $$vars to see if the previous record was modified and if so, write a line to the log. But there are many flaws in this (if a user is not going to a next record or when the next action is a search etc).

Why isn't there a script trigger for leaving a record...

Thanks for the help!

 

[balooka]

Hmmm I think I have it working now... looking for the flaws that I missed.

I have an on commit trigger to set 2 $$vars with record ID and timestamp if there was a modification in the record (empty otherwise), the account name is the current user so no need for a $$var there,

So every time it is triggered by a modification and commit it will set these two $$vars to the exact same values.

The second trigger is the Onload script trigger that will check if both $$vars are empty. If both are in use, meaning there has been a modification in the previous record, it will set a new line in the log using the $$vars and the account name. Clearing both $$vars after that will reset the script trigger.

One flaw I already see is that a user could close the database after the last modification.

ETA

The two Vars somehow did not transfer as I would like them to. Solved that by using two globals to hold the content of the recordID and the timestamp. The vars are only used when adding the line because I needed to clear the globals before the end of the script (started looping).

Edited May 4, 2017 by balooka

[Wim Decorte]

have you tried that empty webviewer that I talked about?  That would save you having to juggle and maintain global vars for this (which is an ugly solution but if it works for you: then by all means use it).

[balooka]

Hello Wim,

I think I might have misread your solution. I already have a web viewer on my layouts and somehow I only half-read your solution. I thought you meant to view the whole thing inside a webviewer.... my mistake! I'm going to try that right now!