si viewauditlog
view a record of operations performed on the Integrity Lifecycle Manager Server
Synopsis
si viewauditlog [--fields=field1[:width1],field2[:width2]...] [--filter[=id:<expression>] [--[no]batch] [--height=value] [--maxRows=value] [--width=value] [-x value] [-y value] [--cwd=directory] [--forceConfirm=[yes|no]] [-g|--gui][--user=name] [--hostname=server] [(-N|--no)] [--password=password] [--[no]persist] [--port=number] [(-Ffile|--selectionFile=file)] [--quiet] [--settingsUI=[gui|default]] [--status=[none|gui|default]] [(-?|--usage)] [(-Y|--yes)]
Description
si viewauditlog allows you to view a record of operations performed on the Integrity Lifecycle Manager Server
Auditing categories are organized into independent hierarchies, with an individual Integrity Lifecycle Manager Server component at the root of each category (workflows and documents-im, configuration management-si, or the Integrity Lifecycle Manager Server-is). These root component categories are independent of one another.
For example, the following command returns all records where "co" (check out) is in the operation name, including "recomputehistory":
si viewauditlog --filter=operation:co
Options
This command takes the universal options available to all
si commands, as well as some general options. See the
options reference page for descriptions.
• --fields=field1[:width1],field2[:width2]...]
where fieldn can be any of:
◦ id
specifies the ID number of an individual audit log detail. This is the ID number of an individual record found in a previous search.
◦ parentid
specifies the ID of the audit detail that spawned the specified operation (that is, all operations that have been spawned by the audit detail with the specified ID number).
◦ user
specifies a user ID. This is the login ID of the user who performed the operation.
◦ state
specifies the status of the operation being audited. Valid states are completed or failed.
◦ category
specifies the root component of Integrity Lifecycle Manager. For example, workflows and documents is im, configuration management is si, and the Integrity Lifecycle Manager Server is is.
◦ operation
specifies the operation or command. This can also include the operation that spawned the audit or sub-operation.
◦ contexttype
applies for configuration management only. Applies only when the target of the operation is a member and the project must be given to uniquely identify that member. Valid contexts are si.project, si.buildProject, and si.variantProject.
◦ context
applies for configuration management only. Applies only when the target of the operation is a member and the project must be given to uniquely identify that member. Valid contexts are si.project in the format <project id>, si.buildProject in the format <project id>(<revision ID>), and si.variantProject in the format <project id>(<variant name>).
◦ date
specifies the timestamp information for the target operation.
◦ detail
specifies the audit log detail.
◦ targettype
specifies the type of object the specified operation is acting on. For example, si.member, im.state, and im.issue.
◦ target
specifies the object that the specified operation acts on. Optional field.
◦ parameters
specifies the parameters defined in the operation. Parameters take the form of key=value pairs in a comma-separated string. Parameter keys and values depend on the operation being recorded, for example, label=Version2,saveTimestamp=true. For configuration management, arguments should match those created for the corresponding trigger scripts. Optional field.
◦ resulttype
specifies the type of operation result. Valid result types include exception in the format <exception class>;, im.issue in the format <issue ID>, si.revision in the format <revision ID>.
◦ result
specifies the operation result. Valid results include exception, im.issue, and si.revision. Optional field.
• --filter[=value:<expression>]
specifies filter to apply when viewing the audit log results. Valid filters include the following:
◦ id:<expression>
specifies the ID number of an individual audit log detail. This allows you to search for an individual record found in a previous search.
◦ parentid:<expression>
specifies the ID of the audit detail that spawned the specified operation (that is, all operations that have been spawned by the audit detail with the specified ID number).
◦ user:<expression>
specifies a user ID to search for when filtering the audit log. This is the login ID of the user who performed the operation.
◦ state:<expression>
specifies the status of the operation being audited. Valid states are completed or failed.
◦ timestamp:<expression>
specifies the timestamp information for the target operation. Valid filter options are today¦tomorrow¦yesterday, last¦next<total number of days, between<MMM DD\, YYYY> and <MMM DD\, YYYY>.
◦ category:<expression>
specifies the root component of Integrity Lifecycle Manager you want to filter for. For example, workflows and documents is im, configuration management is si, and the Integrity Lifecycle Manager Server is is. To refine the level of filtering, you can also specify a subcomponent. For example, to filter the audit log for workflow and document administrative operations use im.admin as the expression. To filter for member operations, use si.member as the expression.
◦ operation:<expression>
specifies the operation or command being filtered in audit log. This can also include the operation that spawned the audit or sub-operation.
◦ contexttype:<expression>
applies for applies for configuration management only. Applies only when the target of the operation is a member and the project must be given to uniquely identify that member. Valid contexts are si.project, si.buildProject, and si.variantProject.
◦ context:<expression>
applies for configuration management only. Applies only when the target of the operation is a member and the project must be given to uniquely identify that member. Valid contexts are si.project in the format <project id>, si.buildProject in the format <project id>(<revision ID>), and si.variantProject in the format <project id>(<variant name>).
◦ targettype:<expression>
specifies the type of object the specified operation is acting on. For example, si.member, im.state, and im.issue.
◦ target:<expression>
specifies the object that the specified operation acts on. Optional field.
◦ parameters:<expression>
specifies the parameters defined in the operation. Parameters take the form of key=value pairs in a comma-separated string. Parameter keys and values depend on the operation being recorded, for example, label=Version2,saveTimestamp=true. For configuration management, arguments should match those created for the corresponding trigger scripts. Optional field.
◦ resulttype:<expression>
specifies the type of operation result to filter for. Valid result types include exception in the format <exception class>;, im.issue in the format <issue ID>, si.revision in the format <revision ID>.
◦ result:<expression>
specifies the operation result to filter for. Valid results include exception, im.issue, and si.revision. Optional field.
• --maxRows=value
specifies the maximum number of audit log view records to return from the server.
• --[no]persist
controls whether this presentation of information should continue to be updated as new information becomes available. --nopersist forces a static "snapshot" of information, while --persist gives real-time updates.
See Also