How can a moderator reject a revision?

I too have the same question.

You can delete any revision in the Revisions list by clicking on its Date/Time and then clicking the "delete" option in the sub menu.

But I do not see anywhere we can link in a trigger (under Site Building >> Triggers >> Revisioning) to add extra functions on delete. Nor is there the ability to simply reject the change and ask the user to come back and modify the work they already have done.

Any hints from those who have done this before? In a perfect world, a rejection (or even deletion of a revision) would trigger an event (such as an email).

Cheers,
Jason

Sorry for late reply.

Revisioning by itself doesn't have a "reject" as such. To reject is to not publish.

With both the Revisioning and Workflow modules enabled you'd typically have at least three states "in draft", "in moderation" and "live".
When an author is done with their draft they change the workflow state to "in moderation". To reject that draft, a moderator simply flicks the state back to "in draft" (and Workflow can be configured to send an email for this state transition). There isn't a "Reject" button, just radio buttons to change state. I'm beginning to think I should introduce a Reject button, as I just had this question in another context this week.

@Jason, #1:
With Workflow installed, any state transition may trigger an email, including rejection and acceptance.

See also this Revisioning + Workflow tutorial.

Hi RdeBoer,

The concept of "rejecting" can in fact be a bit of a logical conundrum, and I am beginning to "cool" on the idea because of that.

To reject is to imply the node author needs to know. But there may also be the possibility the rejection will be accepted if certain changes are made.

This becomes unworkably complex if you have your users working as the authors without clear demarkations like a wiki (as is needed on my site). A node has been authored by author 1 and approved/published. It is then updated by author 2, but the change is "rejected" as author 2's additional content is not up to scratch. Author 1 then comes along and makes another update (unrelated) - who's content does author 1 update? Their own? Or the rejected Author 2's? If its Author 2's rejected update, this means Author 1's update will now also be likely to be rejected unless Author 2's content is removed. If Author 2 then reads they have to make changes, (s)he goes back and finds their content has been wiped out - all that hard work gone!

Thus, its a mine field unless revisions are locked to only one user. And on my site, that would be unworkable. I am beginning to think it is better to bypass rejected content all together.

Cheers,
Jason