emuaudit
The emuaudit command is used to control the types of operations that are audited by the database manager. All auditing is performed by the database manager on the EMu server. As the database manager handles all access methods to the data, audit information is generated regardless of the access method used. For example, if a module has search auditing operations enabled, audit records are generated for searches performed via the EMu Windows client, the EMu Web interface or the texql command line processor.
The emuaudit command is located on the EMu server and can only be accessed by user emu, that is the EMu System Administrator account.
To determine the operations audited for a given module, run emuaudit followed by the name of the table. For example to check the Loans module (eloans table) settings use:
emuaudit eloans
eloans change
The change setting indicates that auditing for the Loans module is enabled for operations that alter records (that is insertions, updates and deletions). To list all modules settings, enter emuaudit without supplying a module name.
emuaudit
eaccessionlots change
ebibliography change
ecatalogue search,change
econdition change
econservation change
edocuments change
eevents change
efieldhelp change
egroups change
einsurance change
einternal change
eloans change
elocations change
emovements change
emultimedia change
enarratives change
eparties all
eregistry change
erights change
etemplate change
ethesaurus change
evaluations change
Notice that both ecatalogue and eparties are auditing more than just changes made to records. The list of available operations for auditing is:
The change
operation audits any activity that results in a record being created, modified or deleted. This is the default operation for all modules and is used to track who has made changes to records. It is not possible to disable this operation (although the loading of these records into the Audit Trails module can be turned off if you do not want to track record changes). When a record is modified, a complete list of all fields before and after the change is generated. In the case of an insertion, only the new value is listed, and for a delete the old value is recorded.
The corresponding xmlauditoptions for the database manager are:
update;updatehistory;insert;delete;tempinsert;tempdelete;tempupdate;tempmove
If search
operations are enabled for auditing, audit records containing the TexQL statement used to perform the search are generated. By monitoring search audit records, administrators can determine what fields are being searched and what search terms are used. With this information it is possible to adjust database indexing to provide faster searching (e.g. by enabling NULL searching) or to reduce the indexing overhead by removing indexing from fields that are not searched on a regular basis.
The corresponding xmlauditoptions for the database manager are:
query
Using the display
operation, audit records are created every time a record is accessed. A record is accessed when it is viewed by a user, involved in a sort operation or used as part of a report. The audit record contains an Identifier that can be used to link the record displayed with the search that found the record.
The corresponding xmlauditoptions for the database manager are:
display
When a user accesses a module for the first time the database server must log in to the underlying table. The login process must occur before the module can access the data. If the login
operation is enabled, audit records are created each time a user first accesses a module within a session. An audit record is also created when the user logs out of the module, just before terminating the session. Using this operation it is possible for administrators to calculate the time periods that a user has accessed the system.
The corresponding xmlauditoptions for the database manager are:
login;logout;badlogin
The all
operation may be used to generate audit records for every activity performed on a given module. Not only are all of the above operations audited, but system activities (e.g. module reindexing) are also recorded. An administrator can use the all operation to get a complete picture of all usage of a module. This setting should be used with caution as it can generate a large number of audit records.