Feature Proposal: Should be able to audit new registrations

Motivation

Big brother is watching you.

It is often the case that you want to be able to have a human being in the registration loop to audit new registrations. This is mainly an anti-spam measure.

Description and Documentation

When a user registers (an possibly verifies, depending on settings) then:

1. Inform the user that their registration is pending approval
2. Mail one or more registered approvers (identified by a configure setting)

When an approver receives a mail requesting approval, they have two links in the mail to follow:

1. authorise
2. deny

In either case clicking the button takes them to a wiki page. The page contains a "submit" button to complete the process.

1. In the case of a rejection the rejector is also asked for an optional feeback statement for the registrant.
2. Clicking the button commits the registration (or denies it) and mails the registrant to inform them of the decision.

I have been asked to do this by a client, so will be implementing what I described above. This feature request is to decide whether it gets merged with core or not.

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: CrawfordCurrie - 06 Aug 2012

Discussion

See Tasks.Item9849. This was partially implemented and documented a while back. The purpose of Item9849 was to make it a bit easier for mere mortals to successfully configure. If finishing off that task is what this is proposing, I'm all for it. I had been treating it more as a bug because it's possible to accomplish this approval flow now, just a bit cumbersome.

Ah, as I read your proposal more closely, you would support both verification AND approval instead of using the verification process as the approval mechanism.

-- GeorgeClark - 06 Aug 2012

+1

The feedback statement in case of rejection should be optional

-- FlorianSchlichting - 06 Aug 2012

Tasks.Item9849 as you said merely scratches the surface. AFAICT no-one has attempted to do this properly before. Yes, I am implementing an approval step that follows the verification step.

The feedback statement is optional.

Some ideas for the future include; setting/auditing group memberships from the audit screen.

Code is attached; against rev 15267 of trunk. Please let me know of any problems.

-- CrawfordCurrie - 07 Aug 2012

Can I call for a vote on this, please? I think it's a no-brainer, but I'd like anyone who wants a veto to have a voice, and a vote seems the right way to get it noticed.

Who	Yes/No	Reason
CrawfordCurrie	Yes	It's immensely useful in the war against spam, and useful in an environment where the admin wants more control too.
PadraigLennon	Yes	Agree with Crawford that this is a useful addition
OlivierRaginel	Yes	This should have been in the core from the very beginning.
OliverKrueger	Yes	Very useful.
GeorgeClark	Yes	This has been requested for a long time and the hack using verify is an incomplete solution.
LynnwoodBrown	Yes	Essential tool for spam control on public sites.
MichaelTempest	Yes	This came up time and again on IRC when I was active there.
MichaelDaum	Yes	cool feature
KennethLavrsen	Yes	I am sure this will be popular, but should be disabled by default naturally. Excellent
MartinCleaver	Yes
KipLubliner	Yes
AndreLichtsteiner	Yes

-- CrawfordCurrie - 11 Aug 2012

Crawford, re the code. I think you removed the verify exception when enforcing the POST requirement.

• No, I didn't. The POST is asserted only on the action=register method, as it is only appropriate when the initial registration form is submitted. Other requests can be handled with GET just fine. - C.

-- GeorgeClark - 11 Aug 2012

1. The fact that Foswiki has strong authentication and authorization systems was one of the main reasons I went with it. Too many HippieWikis (my name, don't steal it) still feel in this day and age that everyone on the internet should be able to read and edit every wiki page everywhere. It's all a bit of a waste if anyone who knows how to create a free email account can register on your website and see all the users' information anyway. This would be a welcome addition for me. Yes, I've already done the "edit the template" Ugly Hack, but... that's an ugly hack.
2. The fact that it can already be done as an Ugly Hack does not mean that it shouldn't be done right. There is value in semantic correctness and obviousness of a solution (eg using an h2 tag because the enclosed text is a subheading, not because you just want bigger letters), and editing a page template does not smell like the right way to add an approval step in the workflow. It looks to me after perusing the diff that your solution should have no impact on those that don't want the feature, and it should be easy to configure.

I'll note your design also closely follows how GNU Mailman does it, which probably means You're Doing It Right. Mailman has the ability to reject (disallow and tell the registrant) or discard (disallow and do not tell the registrant). As CrawfordCurrie said, I think that's important functionality to leave at the discretion of the BOFH and should be configurable. p.s. Forgive me if I put this in the wrong place, there was no comment box on this page.

-- DavidKramer - 12 Aug 2012

Since there has been unanimous support for this I'm going to take it as accepted.

-- CrawfordCurrie - 13 Aug 2012