Pawn:Package Old Logging

The Audit trail of a package is contained on the receiving server and contains a list of actions that occurred against that package. These actions are concerned w/ the accessioning process of a package into an archive. This means that the initial construction and editing of a package is NOT logged. This is because there is no clear way to draw a line between initial client assembly and later changing / additions by the client. What is logged are modification/edits by any party other than the creating client.

Each log event contains all affected items. In the case of actions encomosing an entire package, a log entry may be fairly long. Log entries are generated on a per-call basis. That means that an ingest of manifests and an ingest of objects will result in seperate log entries. This means that what the end-user views as one operation may in fact be multiple calls resulting in multiple log entries.

Sample log entry:

<Event Date="2006-06-09T12:41:07.153-04:00" Domain="umiacs" Issuer="http://umiacs.umd.edu" 
User="umiacs:toaster" xmlns="http://umiacs.umd.edu/adapt/pawn/event">
  <Lock/>
</Event>

This log entry shows that the lock package operation. From the event header, you can see that the user, domain, and what management server they authenticated against. There are no error messages and the operation succeeded.

Another sample:

<verbatim>

</verbatim>

This is an example of a larger action. Here several manifests and objects are ingested. You can see the client first ingests the three new manifests, then for each manifest ingests attached data items.

Log types

Archive

When data is transfered from PAWN into an archive. The archive tag will contain the resource used and the individual manifest and item tags will contain the destination of the data in the archive

Accept

When an object or manifest is moved from the reject state to ingested state. An optional reason may be supplied

Add

When an object or manifest is added or overwritten through the ingest* calls.

lock

When a the entire reservation is frozen, no items or manifests should be listed. A reason may be given

Reject

When an item or manifest is moved to the reject state. A reson may be given.

Remove

When an item or manifest is removed through the remove* calls.

Unlock

When the entire reservation is unfrozen/unlocked. A reason may be given