View Issue Details

IDProjectCategoryView StatusLast Update
0004112mantisbtbugtrackerpublic2019-08-09 19:13
Reporterpdugas Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
Summary0004112: Admin approval of new accounts
Description

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?

Tagspatch
Attached Files
mantis_4112_1.zip (6,105 bytes)

Activities

roleary

roleary

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.

vboctor

vboctor

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:
http://www.mantisbt.org/wiki/doku.php/mantisbt:approval_of_signup_accounts_requirements

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.

spmeesseman

spmeesseman

2019-07-31 02:31

reporter   ~0062465

ok ok its been 12 years i know haha, but was this ever addressed? I had a "pornhub" account created on my mantis site, and left a comments on every ticket (i only had 5) and created 1, all in less than a few seconds, and it happened not even a half hour after my site went live. I immediately had to turn sign_up option to OFF.

cas

cas

2019-07-31 08:16

reporter   ~0062470

perhaps a plugin is a shorter route....

dregad

dregad

2019-08-02 13:21

developer   ~0062483

Responding to @spmeesseman's note 0025946:0062481

would there be any future plans for this? If not I think I may take this task on, but

No plans that I know about - the original author never responded to @vboctor and the momentum got lost.

would need some hooks in the application if I were to do it in a plugin probably

I have no problem with adding new hooks, as long as they are well defined, reusable and documented.

Feel free to discuss the requirements, here or in a separate thread.

spmeesseman

spmeesseman

2019-08-02 17:05

reporter   ~0062495

got it, I may indeed end up doing this, but probably cant start until next week. Ill post to this thread for discussion

thanks for your help today

spmeesseman

spmeesseman

2019-08-09 16:04

reporter   ~0062548

i've been spinning up a security plugin based on how the spammers are spamming my site, would you be able to add a hook for when the SPAM event happens? Preferrably right before the default error banner is shown with the ant-spam message. I know you mentioned they had to be documented and reusable, just let me know exactly what you need, where to put it, etc, id be more than happy to provide it. First time through all this so once I learn the ways Ill be less of a pain

the one thing i cannot figure out is how they are creating accounts with me getting the "a new account has been created" email. But i will

dregad

dregad

2019-08-09 19:13

developer   ~0062550

In a nutshell, you need to

  • define the new event in core/events_inc.php
  • add event_signal() call(s) in Core, as appropriate
  • document the event in Developers' guide Events reference section (docbook/Developers_Guide/en-US/Events_Reference*.xml)
  • open an issue in the tracker to describe the new event
  • commit all this in a feature branch, referencing the issue you just created
  • send a PR for review