Turn the audit log into a weekly change report

MaintenanceIntermediate~5 min

Before you start

The activity log read requires the manage-options capability, so run this as an administrator, not as a least-privilege agent user. No integrations needed.

Once an agent starts doing real work on your site, the question stops being “can it write” and becomes “what did it write.” The plugin keeps its own audit log of every ability call, so instead of guessing, you can have the agent read that log back to you as a plain weekly report.

The catch is deliberate. Reading the log takes the manage-options capability, which a properly scoped agent user should not have. So this is a report you run wearing your admin hat, looking down at the work the agent did under much tighter permissions.

The prompt
Read this plugin's own activity log and turn it into a weekly change
report. Read only. Go back over the last seven days, most recent first.
Group the entries by ability and by status, so I can see how many
create, update, and delete calls ran and how many succeeded, errored,
or were denied. Break the activity down by day, and note which account
each run acted as. I know the log records the argument keys but not the
values, so do not guess at specific post IDs; just tell me what ran,
how often, and whether it worked. Put the totals at the top.

Why this is safe to run

The activity log read is exactly that, a read. It cannot alter a single row of history, so running the report can never change what the log says or what the site looks like.

The honesty of the report comes from what the log deliberately withholds. It stores each call’s ability name, status, acting account, timestamp, and the keys of the arguments, but never the argument values and never network addresses. So the report can tell you that a run of updates happened and whether they landed, without leaking the contents of those calls. When you need the specific before-and-after on a given post, that lives in the post’s revisions, which is the draft-first change-review recipe’s job. Keeping this read behind manage-options is the point: the agent works on a short leash, and the oversight sits above it with you.

Already connected? Skip the paste. Ask your agent, as an admin, for the “weekly change report” recipe, or just ask what it has been doing this week, and it runs the same read on your own log.

How it works

  1. Read the audit log, most recent first, across the last seven days.
  2. Group the entries by ability and by status (success, error, denied).
  3. Break the activity down by day so you can see the shape of the week.
  4. Note which account each run acted as.
  5. Hand back a short report with the totals up top.

Questions

Can I see exactly which posts changed?
Not from the log alone. It records the ability name and the keys of the arguments passed, never the argument values, so it can tell you that eight update-post calls succeeded but not which post IDs. To review the actual before-and-after on a post, use the draft-first change-review recipe and read its revisions.
Why can't my agent user run this?
The log read is gated by the manage-options capability, which a least-privilege agent user should not hold. Running the report as an admin keeps that separation intact: the agent does the work under tight permissions, and you review it from above.