You are viewing limited content. For full access, please sign in.

Question

Question

Audit Trail - Track field changes without tracking the field values

Audit Trail
Updated August 1, 2014
asked on July 24, 2014

Is there any way to track that a field has been changed but NOT track the data in those fields?

 

In my situation we have certain fields (like SS#'s) that should NOT be in the audit log. However they would like to know if the document was edited and by whom.

 

How would I go about doing this? 

0 0

Replies

replied on July 24, 2014

Auditing in the Laserfiche server doesn't offer that level of configurability, you would have to turn off all field event logging for the users who would be updating those fields.  But just because these data go into the audit logs doesn't mean you have to show them to your users.  There are at least 2 opportunities to intercept them:

 

1) You could modify the reporting database.  If you added insert triggers to the "audit_propval" and "audit_prop" tables, you could intercept the values as they are being written into the database.  This would be unsupported and as far as I know nobody has done it.

 

2) You could write a custom reporting tool that queries the audit database and knows how to avoid returning that data.  You could even put the logic in a SQL view so that it wouldn't rely on the client making a correct query.  This would be supported, but you wouldn't be able to use our web reporting tool (as it wouldn't contain the right logic).

0 0
replied on July 24, 2014

Unfortunately even having the data in the raw log files is something that would violate their security requirements for data retention.

 

Is there any way to track that someone made a change to a particular document, without tracking metadata?

0 0
replied on July 24, 2014

Not with Audit Trail.  Workflow might be able to do it in theory, but starting a new workflow for every single field update could be problematic.  You could put a trigger on the propval table in the Laserfiche server database, but you lack some context (like who is making the change) and that again gets you into an unsupported configuration (see this related question).

0 0
replied on July 24, 2014

The log files can be secured, the LFServer is the one writing to them and Audit Trail reads data from them to load into SQL. Users do not have access to the log files themselves. You can let Audit Trail load the data into SQL for you, but not use the web reporter at all. You could have canned SQL reports that don't use the field values. Or even have some scheduled task that clears out the audit table that holds field changes.

0 0
replied on August 1, 2014

Hi Chris, 

 

If your question has been answered, please let us know by clicking the "This answered my question" button on the response.

 

If you still need assistance with this matter, just update this thread. Thanks!

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...