|
Filter
|
Description
|
|
ID
|
ID number of individual audit log detail. Allows search for individual record found in previous search.
|
|
Parent ID
|
ID of audit detail that spawned specified operation (that is, all operations spawned by audit detail with specified ID number).
|
|
Timestamp
|
Date information to use when filtering audit log. All operations with specified timestamps included.
To set timestamp, click Change and Timestamp Filter dialog box displays. Adjust filter settings as required to filter for target date:
• today, tomorrow, or yesterday
• last|next total number days|months|years
• date between date and date
|
|
User
|
User ID to search for when filtering audit log. Login ID of user who performed operation.
|
|
Category
|
Root component of Windchill RV&S you want to monitor, for example, workflows and documents (im), configuration management (si), or the Windchill RV&S server (is).
To refine level of auditing, you can also specify subcategory, or subcomponent, of category you want to monitor. For example, to monitor administrative operations related to workflows and documents, subcategory is admin (as in mksis.auditor.im.admin). To monitor member operations, subcategory is member (as in mksis.auditor.si.member).
For a list of categories and subcategories, see “Windchill RV&S Server Operations”, “Workflow and Document Operations”, and “Configuration Management Operations”.
|
|
Operation
|
Operation, or command, being audited. Can also include operation that spawned audit or suboperation.
For example, to monitor state editing operations , operation name is editstate (as in mksis.auditor.im.admin.editstate). To monitor a checkin operation, operation name is ci (as in mksis.auditor.si.member.ci).
For a list of operations, see “Windchill RV&S Server Operations”, “Workflow and Document Operations”, and “Configuration Management Operations”.
|
|
Context
|
For configuration management only. Applies only where target of operation is member and project must be given to uniquely identify that member.
Possible configuration management contexts are as follows:
• si.project format is <project ID>for example, c:\sourcecode\applications\project.pj
• si.buildProject format is <project ID>(<revision ID>)for example, c:\sourcecode\applications\project.pj(1.10.1.1)
• si.variantProject format is <project id>(<variant name>)for example, c:\sourcecode\applications\project.pj(AppVariant)
Optional field.
|
|
Target
|
Object that specified operation acts on, for example:
• applications\engine.c(1.12) in case of si.member target
• Submit in case of im.state target
• Element number 3274 in case of im.issue target
Optional field.
|
|
Parameters
|
Parameters defined in operation. Parameters take form of key=value pairs in a comma (,) separated string. Parameter keys and values depend on operation being recorded, for example, label=5_0_Release,saveTimestamp=true.
For configuration management, arguments should match those created for corresponding trigger scripts.
Optional field.
|
|
Result
|
Type of operation result to filter for. Value of result depends on operation being recorded and is not always populated. Potential result types include: exception, im.issue, or si.revision.
Optional field.
|
|
State
|
Status of operation being audited. Available states are Completed or Failed.
|