NickP writes:
1) What if I add a variable $wgUserEditCommentTimeout,
which specifies a
*time limit*, in minutes, and specifies the amount time a user has to
modify a comment before the comment "becomes permanent"? ... I could
allow values of 0,
don't allow users to make any changes to comments, which would satisfy
Nick Triantos's request, or -1 to allow a user all the time in the world
to modify a comment.
I have implemented this. If a time limit is set, once a user starts
editing a comment (summary), I give them an extra 2 minutes to allow them
to edit the change. After the timeout their change is rejected.
2) Comment changes should be logged in Recent Changes. Recent Changes is
the most accurate audit trail now and should have note of these changes. A
brief look at the definition of the table 'recent changes' suggests to me
that it may need modification to record these changes.
I have implemented this. I put a message in Recent Changes of the form:
"Summary of *article* changed (diff; *hist*) . . *Username* (Talk) was
(*original comment*) now (*new comment*)". I made the link to the article
open the article revision whose summary was revised.
It turns out that I did not have to change the schema of 'recentchanges'
to implement this. I added a new type of change (define(
"RC_EDIT_COMMENT", 5);) and usurped the field, 'rc_moved_to_title', to
hold the original comment, since it is only used when logging
moves--slightly kludgy. I modified Skin.php to properly format the new
type for old and new format RC pages.
But while this all works great, I did discover a bit of a "got cha". I
noticed that the number of 'recentchanges' records in my 'wikidb' is a
small fraction of the number in 'cur' and 'old'. It seems that after
every
1-1,000 changes the RC table is "pruned" to hold only the last week's
changes. Hmmmm. I found this disturbing for several reasons: 1) The Recent
Changes page lets you "see" up to 30 days of recent changes--won't work.
2) As this could be the definitive log of *all* changes on a wiki, I would
think you should *never* want to prune this. 3) At the very least, the age
to which it is pruned should be a variable in DefaultSetting.php so it
could be adjusted on a wiki by wiki basis.
My changes are based on 1.3.7, so I have yet to merge them to the head
branch.
Nick