Non-core contributed modules

I would very much like to have this option.

Another related option I would like is to have the equivalent of an enrollment key for creating accounts.

I'm happy to have this implemented if people think it's useful (I see it has a lot of votes!), but is it really useful?

My question is: will an admin actually be able to tell whether a new account is a spammer or not?

If they are looking at the email address to tell this then they could use the automated domain filtering to avoid this manual work. Otherwise I think this would just be one of those measures that results in escalating admin workload to blindly approve all the email they'll start getting. Please tell me if you think it'd be useful anyway!

I like the idea from Peter Wallace about a key to create accounts.

Another one might be to rate-limit the amount of accounts that can be created from one IP address to 1 per 24 hours or something.

I like the concept, although you make good points about this not always being effective other than to make work. I had always assumed an approval system would have an admin GIU with a series of check boxes and a select all option, rather than the email based interface suggested. I could see points for either or both though now that I have re-read this request.

I think it could be a useful option for some administrators to have. Its not a fix all, but if it had good mass approval options it could still be useful for the right administrator to notice strange patterns in new registrations.

For my organization, I have a potential user base of 5,000 or so. Currently, only a fraction of that is registered. I like the idea of this feature because most of the time I would be able to tell immediately if the account creation request was valid just by looking at the email domain. If there was an email domain that I did not recognize, I could write back to that person and ask for additional proof or references that they had the right to register on the site (or put in a References field in the signup page.)

I think the time savings in allowing the valid users to self-enroll would outweigh the pain in finding out if some addresses where authorized or not. That may be a naive assumption but there's my 2 cents

I'm voting for this as even though I can see Michael's point of view about the relative administrative workloads - I think its a case of this being a useful function for some Moodle sites (including it would seem quite a few people who have already voted for the change).

Mark's on the right track about this. This is a really inefficient way of dealing with spam, and if all legit users have the same email domain then the "Allowed email domains" setting takes care of that.

But as a adjunct at three different schools, I use Moodle to centralize my LMS content. A second-tier approval process would be useful to make sure that I'm only enrolling my students rather than the whole world. That's where I see the virtue of this: a setting where (a) registrations need to be checked against a list of specific users, and (b) specific information is needed from the user-like the email address that they actually use as opposed to the institutional one that they ignore-that makes manual registration impractical.

Of course, I'm not sure how widespread such needs are. That may be a pretty narrow need that makes a built-in solution more trouble than it's worth.

My bad--I overlooked that Martin already pointed out the automated domain filtering.

If implemented this should have the option to select account "approvers" who are not necessarily admins - see the new course request interface for how this should work.

Placed my vote for this option. while I certainly would like to have "approvers" as Ray has noted or other ways to confirm beyond a simple email address. I see no reason that I could not simply email the requests that I do not know and confirm who they are as Micheal has noted. Currently we have our users going through a two step process one where they sign in to our phpbb forum site that has an administrative approval process. Moodle then looks to this phpbb database of user to allow access. It should would be nice to have only one step in this process. Andy

I heartily support this process / feature. It would help me by allowing us control over who could create accounts, and give us a chance to double check that they have set up their account properly and to immediately place them in their proper group (in my case, it's emergency medical services agency) at the outset. So two thumbs-up on this one.

I with most of you. This feature may seem redundant to some but is absolutely necessary. If implemented as an option, whomever does not need not simply needs not use it.

By the way, it's been almost a year since this was first posted. Any update on IF and WHEN this will actually be implemented?

Daren - My impression was that this will not be implemented in Moodle core; however, if someone would like to provide a patch I would be happy to put it in CONTRIB where folks could use it as a patch. If there is no objection, I am going to move this to CONTRIB so that there is some clarity about where this code would go. Peace - Anthony

Petr - I am going to leave this assigned to you for now; however, feel free to re-assign to Nobody and we will wait and see if someone provides a patch that I can put in to CONTRIB. Peace - Anthony

Hi Folks,

My 2 Bobs worth....

I think this option is generally a good idea...however, without diminishing other's requests for having a double confirmation process, I am more interested in an option for Admin to receive a notification email whenever there is a new registration. It would appear to me that such an option would be more simple to implement and serves a similar purpose. i.e. The admin still has to be present to check either that a new registration has occurred or that one requires confirmation. Even with a simple notification, if I consider the new registration dubious I can still unconfirm/delete the account manually...which is effectively the same process as a second confirmation without necessity for further email configuration and therefore more complicated server-side security protocols.

Re: Admin Notification of New Registrations via email - There is a line of code (mentioned in a forum post in 2008 here - http://moodle.org/mod/forum/discuss.php?d=92958), which I have tried...but given that my installation is not sending confirmation emails (for details see my post here - http://moodle.org/mod/forum/discuss.php?d=141695#p644809), I have no way of verifying it's efficacy...yet.

Thanks

Stephen Glanville

I would like a specific email address to be notified when there is a self registration. This is not about spam but more about a loose level of security. On several sites I work with, we would task someone with checking on 0 to 10 self registrations a week.

There are different kinds of support. At least I would like to see $supportuser email go to someplace that an administrator can change it. Perhaps similar to the Course request pulldown.

I would like to see support user field/pulldown under security>notifications. This is also the logical place to perhaps have a check box for "email supportuser after self enrolment request" and "email supportuser after self enrolment request confirmed".

I do note the feature in 1.9.9+ where site administration>users>bulk user actions> advanced >"first access is after" will create a filter, then someone can perform a download in text, ods or excel. There is no date, or reprinting of the parameter on the download. This is an issue and someone has to be told to do it on a periodic basis, then keep track of who they already checked.

I am not a big fan of hacking moodlelib.php code. But realize this is the beauty of Moodle.

Chris

For those watching CONTRIB-1444, Petr has assigned this to nobody which means it is open season for whoever might be willing to provide a patch that implements the desired functionality. If you are interested in giving it a shot just let me know. I'm happy to give suggestions, help test, etc. but it is unlikely that I will have time to write the patch. Peace - Anthony

p.s. - I've assigned this to myself just to keep it on the radar but I will not be working on creating a patch and will happily re-assign to whomever wishes to write the patch.

Anthony, since this issue has lots of votes, I'm wondering whether it should be changed from a contrib issue to an MDL one, so that we can consider adding the feature to a future version of Moodle?

As the "Admin" in Moodle 2 is now somewhat different to previous versions it's more important that approvers can be selected individually or by role. See the course requests model.

Helen - I think this started out as a MDL issue and was switched to CONTRIB in the hopes of writing a patch similar to what I did for the forum approval patch. I've not time to work on this at the moment but I can see where arguments can be made on either side. It may be worth a discussion in the forums to determine whether it is really helpful or not. I'm open to do whatever is most beneficial to the community. After a bit of discussion, then perhaps HQ can determine whether or not to include it. Peace - Anthony

Something of this sort has come up for us as well:
We would like to allow our teachers to create accounts for specific trusted people. For instance, if a Lecturer has scheduled an industry partner to come in and teach for a couple of sessions, the teacher should be allowed to make an account, or vouch for the new account in a way or another, without the administrator having to get involved.

My thinking so far is that there could be a user account creation form that all (or a subset of) authenticated users could use. They could enter the details of the person they would like to have an account, and an email with the details would be sent to newly invited user. The user could then finalise the account creation process by clicking a link and choosing a password.

Cheers,
Minh-Tam

I would really appreciate an inbuilt solution to this task; also in v2. of moodle!

Most of our users are LDAP but they do not come from the same domain. They are coming from any domain their email is hosted on. As such I can't restrict to domains. We also have small groups of frequently changing users that are not in our x.500 tree(LDAP). As such having them self-register is very, very handy. The recommended feature above would be great. Have them register with the system, confirm their email and then the admin gets notified to actually confirm their account. It would be amazing if the email to the admin could include direct links to confirm or delete the account.