I have quite heavily adapted the audittrial module to my needs.

First of all you should run a scheduled event once a month for example and remove old audittrial logs. In combination with the MxReflectionModel module I have specified the members/attributes of an entity that should be audittrialed. Achieved this by creating a boolean where the admin can specify whether a logline should be created for a particular attribute/member (some fields are used internally by the developer/under the bonnet and should not be audittrialed/visible for the user)

Using the mxreflectionmodel you can also specify user-friendly names for the attributes and associations. I have also managed to change the way certain values are displayed (old and new) especially in regard to associations and enumerations.

most of the things can be achieved by using microflows but I also used some java and manipulated a few audittrial classes/methods.

1. use mxreflectionmodel module and add a boolean "log" which will determin whether it should be logged or not. In the createlog java class you can check for this boolean and prevent loglines from being created
2. manipulate the domain model - adding a attribute and form where you can set what should be audited (change,add, delete, all - e.g. enumeration) - have a look at the audittrialsuperclass entity and its events (before commit and before delete) you can manipluate the java classes for example and pass a parameter to the java actions telling it what log type to create

Thanks Karol,I understand. but I have a general concern for the way that auditing module works by using the inheritance of auditing-trial-super-class which will save many many records overtime if we apply auditing on many entities , we cant clear this super-class data(which will contain all the number of records of the sub classes)

You have to be very carefull with this module. It serves its purposes but is too technical to be used by business users and can easily clog up your database, hence needs quite some adaptations.  A couple I implemented:

• In the MxModelReflection add a Functional Name to each entity and association. Use this to display to the user;
• References are very badly logged, since the full object is logged. I added per item a Key Attribute field in the ModelReflection, which is added in the Log object, to know what specific business object was changed;
  • The Java code retrieves that (combination of) attribute and only logs that attribute for the association;
• Skip the Domain model prefix in the LogObject, since it does not have business value;
• Every technical attribute has a prefix of _ in my domain models. All those attributes I am not auditing as a generic check on whether the name does not start with an _;
• There is a bug in the Delete logtype. If the LogType is delete and no attributes are changed, the audit trail will not log the delete. Needs a Java code changes as well;
• The usage of the two calculated attributes should be ommitted. Very bad for performance. I mean the Diff and Description fields

Hi Ivo,

Thanks for you reply.

If its possible with you can you help me with the implementation of same thing in JAVA ACTION or you can share that updated JAVA ACTION code with me.So it will be very helpful for me.