Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X
We have some internal filds that we set in trigger scripts that are poluting the history with a bunch of non-valuable noise. How can we disable the history tracking for fields?
Hello Sean,
The bad news is that you can't disable the history tracking for fields. This is by design.
The good news is that you can suppress what is visible to you by taking advantage of field permissions. For instance, I have made it so that only Administrators can see anything related to the KLT_history_stealth field on this type:
If I look at the field from an account that belongs to the Administrators group, the field contents will be visible. If I do the same from an account that does not belong to Administrators, I see nothing related to the KLT_history_stealth field.
If you created a nobody group (for example), that had no users in it, and on the type made it visible only to that group, the field would not show up when looking at item history. Of course, if you have to debug the field, you would have to change the type to make the field visible to Administrators so that they could see it in item history, but that's the best I could come up with.
Does anyone have another idea of how to do this?
Regards,
Kael
Hi Kael,
Thanks for the quick reply. An RFC on this would be irrelavent, but it would have been a nice feature to be able to set a parameter to track history on fields vs. not. Competitive products to Integrity do this and we use it extensively.
We have found an alternative approach, not the most high-performance solution, but it works. Whenever we do calculations and set values within scripts, we now read the existing value, do a comparison, and only write a new value if it is changed.
It was interesting to discover that we had a write a different function based on the data-type of the field (users, vs. IBPLs, vs. pimitive types), but we got it to work.
-Sean