Since Dan referred to something like an audit trail in:
http://groupserver.org/r/post/1I7HqKutBUZJ0JwWMLkHr9
I thought it might be a good idea to re-visit this, since it seems likely (and
useful) for email verification to be the first use of this.
We can utilise the idea that audit logs are pretty much entirely event driven,
and hook into the Z2/Z3 event subscription framework (so that when an event
happens, it gets logged if we've written a handler for it).
Having had a quick discussion of this with Mike, it seems that we have a number
of fields that have fairly strong commonality for different events we might
want to log:
===
id (REQUIRED)
-------------
A unique identifier for the event, for potential linking of the event to other
tables.
timestamp (REQUIRED)
--------------------
The date and time of the event.
subsystem (REQUIRED)
--------------------
The subsystem related to the event (eg. email, profile, group).
event (REQUIRED)
----------------
The event code (eg. notification, bounce, verification request, verified). This
is subsystem specific.
user_id (OPTIONAL)
------------------
The ID of the actor initiating the event. This may be null if it is the system
acting.
instance_user_id (OPTIONAL)
---------------------------
The ID of the user being *acted upon*. This may be null if the ID cannot be
identified (for example, a bounce for an unknown email address).
site_id (OPTIONAL)
------------------
The site ID related to the event, if applicable.
group_id (OPTIONAL)
-------------------
The group ID related to the event, if applicable.
instance_datum (OPTIONAL)
-------------------------
Data that may be required to assist in distinguishing this specific instance of
the event. For example, the email address being sent a verification_request.
supplementary_datum (OPTIONAL)
------------------------------
Data related to the event, that may prove useful as part of the log. For
example, the actual bounce email in the event of a bounce, or a message entered
by the administrator explaining a user ban.
===
Mike: we had discussed an XML field for containing even more data -- can you
think of a case where that would be actually be necessary?
--Richard