Add moderation log - with username

some more progress - inserts data, but no display yet.

display of log overview and single events.

TODO: overview per node, link on the moderation form to node's overview.

added overview per node, but no links to it yet.

very close to being done!

added hook_cron to delete old entries

in response to comments from moshe:

- drupal_set_title(t("One post's moderation log")); - IMO, is worth it to load the node and get a more descriptive title

- i would default the clear interval to Never. moderation log events are not frequent enough to be a storage concern.

- $message = filter_filter('process', 2, -1, $message);. looks unusual. perhaps try check_markup($message) instead.

- truncate_utf8($event->title, 50, TRUE, TRUE). maybe use drupal_substr()

- i like the idea of the moderation log being viewed a tab on the usual node view. so change admin/logs/modr8/node/ to node/x/modr8.

In response to this, I relocated the moderation log per post to a tab on the node page, and set the default clearing time to 'Never'.

In terms of: $message = filter_filter('process', 2, -1, $message);.

I'm using this to just add automatic line breaks to the e-mail message. check_markup() requires the use of an existing site filter number- which will vary by site and may never include one that just applies the line break filter. I'd be happy to know of any cleaner way to call this.

In terms of: truncate_utf8 vs. drupal_substr

I got this usage from the watchdog module, and it looks like it should be faster than drupal_substr in this case.

@moshe- the call to filter_filter is after the e-mail is sent. Since the e-mail is plain text (not HTML) the idea is just to add <br /> tags automatically, so that the e-mail message displays nicely in the moderation log.

Well, since the filtering and content will never change, it made more sense to me to put in the necessary HTML before stuffing it into the DB.

However, it might be worth santizing that message even more (e.g. check_plain() before the break filter).

Only last question- should the "moderation log" tab be hidden if there are no moderation events for a particular node?

A final patch (perhaps). Access to the tab depends on the existence of log events for that node. Also added a link to the moderation log from the top of the moderation queue page. Things also work well enough for deleted nodes.

adding to README

doing some more thorough testing with an access contriol module enabled (OG).

Attached patch fixes one bug. However, the behavior with deleted nodes isn't quite what I'd want- it seems that for non-admins, deleted nodes don't show up in the moderation log, maybe since there is no entry in the node_access table.

committed the attached patch - will sort out node access another day.

#1- I think it's useful to keep a log of deleted items in order to identify which moderator deleted them and why. However, I could certainly add an option to delete them via hook_nodeapi.

#2- I'll work on the tab

#3- I was torn whether to list the author, moderator, or both in the log view. Is listing both better than listing just the moderator?

Well, since you're the only one voting, take a look at the attached patch to address #2 and 33.

(make that #3 not 33)

Another patch attached, which cleans up on node deletion- log entries are deleted if the node is not currently in moderation. This is a pretty minimal cleanup that leaves in the log entries for nodes deleted as part of the moderation process.

Ok, I'm going to commit the attached combined patch to HEAD and 5.x, and make a 5.x-2.1 release.

note, that I also cut the unused 'submit' code in hook_nodeapi.