si viewauditlog
view a record of operations performed on the PTC RV&S 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 PTC RV&S Server
Auditing categories are organized into independent hierarchies, with an individual PTC RV&S Server component at the root of each category (workflows and documents-im, configuration management-si, or the PTC RV&S 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 PTC RV&S. For example, workflows and documents is im, configuration management is si, and the PTC RV&S 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 PTC RV&S you want to filter for. For example, workflows and documents is im, configuration management is si, and the PTC RV&S 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