View Issue Details

IDProjectCategoryView StatusLast Update
0004112mantisbtbugtrackerpublic2007-09-05 20:48
Reporterpdugas Assigned To 
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0004112: Admin approval of new accounts

Could new accounts created by users via the "signup" feature be marked as "pending admin approval" before enabling them and sending the "welcome" message to the user?



2007-08-15 22:53 (6,105 bytes)


2007-08-15 23:00

reporter   ~0015437

I needed this feature so I created a patch for it. The patch was written against 1.1.0a4. With the approval option enabled, the following occurs:
1) NewUser signs up via signup form
2) NewUser is notified via website that their account is pending approval
3) Any user specified by g_notify_new_user_created_threshold_min is notified that a NewUser has signed up and is provided with a link to Approve the user account
4) NewUser login and password retrieval is disabled
5) CurrentUser clicks the approve link in the email -OR- goes to the User Manage page, edits the user, and clicks the Approve User button
6) NewUser is approved and is sent an email with the activation link (similar to current behavior)
7) System now acts like usual

IMPORTANT: This patch will prevent login with anyone that has a 0 in the 'approved' field (new) in the user table. This means, after running the upgrade.sql script, you must set approved=1 to enable the current users (UPDATE mantis_user_table SET approved=1).

NOTE: Any users manually created by an administrator will automatically have the approved flag set.

Feedback is appreciated.



2007-09-05 20:48

manager   ~0015572

This looks to me like an interesting feature. I haven't looked at the patch, but following are my functional comments:

  1. Instead of adding 'approved' field in the schema, why don't we set the access_level of the user to NOBODY until it is approved and then set it to the default signup access level. We must make sure that users with NOBODY access level are not allowed to login.

  2. In the moderation email, we should ideally offer three options: 1. approve, 2. delete, 3. reject. The delete option will delete the user without sending an email, reject should allow the admin to write a reason for the rejection.

  3. When approving a user the admin should be able to select another user to be used as a template (optional), the user being approved will get the same default access level as the chosen level as well as the same access to private projects.

  4. We should have a configuration option to enable/disable moderation.

  5. Should we have an access level threshold for users who should receive moderation emails or should we have a list of user names? In the signup notifications we use the threshold, hence the current solution is consistent. However, the admin may want to delegate the moderation job without giving someone a higher access level or lowering the access level required which may cause more people to be included in the moderation process.

I've created a skeleton requirements page:

Lets continue with the discussion and update the requirements page to reflect the details of the features, sample emails, configuration, database changes (if any), etc.

If we get a quick turnaround for this feature, it may make it into the rc1 release.

Issue History

Date Modified Username Field Change
2004-07-16 11:05 pdugas New Issue
2007-08-15 22:53 roleary File Added:
2007-08-15 23:00 roleary Note Added: 0015437
2007-09-05 20:48 vboctor Note Added: 0015572
2007-09-05 20:48 vboctor Status new => acknowledged
2007-09-05 20:48 vboctor Tag Attached: patch