NickP writes:
- 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.
- 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