User email domain [#1284234]

Control what domains a user may use in their email address. This can be used to force users to standardize on a single email service. If email confirmation is required, then this is a good way to restrict the site to users within an organization.
Even if you don't want to restrict the domains, this module can be useful just for checking email syntax.

Allows for one or many approved domains to check against, or leave the domains field empty.
Allows you to customize the Description text under the user email field.
Checks the email field using AJAX.
Ensures the email address has correct email syntax.
If there's a problem with the email address, presents status messages to tell the user what's wrong.
Validates the email field again when submitted.
Problem submissions are reported via Watchdog.

Works with the Email registration module.
See project page

See Git repository

git clone --branch 7.x-1.x tomogden@git.drupal.org:sandbox/tomogden/1284132.git
This project is for Drupal 7 only.

Comments

Comment #1

coderintherye CreditAttribution: coderintherye commented 19 September 2011 at 22:29

Status:

Needs review

» Needs work

For others cloning your git project, it's actually git clone --branch 7.x-1.x http://git.drupal.org/sandbox/tomogden/1284132.git user_email_domain

First thing you'll want to do is get your coding style cleaned up.
Please follow the guidelines at: http://drupal.org/coding-standards

Download http://drupal.org/project/coder and use it to run a review on your module, which will help you easily see what needs to be cleaned up.

It's mostly just you need to change tabs to 2 spaces, and some other spacing issues.

Also, Line 141 of useremaildomain.module you should be escaping the variable used in t(), please see http://api.drupal.org/api/drupal/includes--bootstrap.inc/function/t/7

Comment #2

tomogden CreditAttribution: tomogden commented 20 September 2011 at 14:52

Tabs are already all 2-spaces each. Perhaps I am using tabs more liberally?

The variable in line 141 is pure text and has actually already been translated at this point--t() is redundant. Thank you for pointing it out, I have removed both occurrences of the t() function here.

I have committed the changes.

Comment #3

tomogden CreditAttribution: tomogden commented 20 September 2011 at 15:05

Status:

Needs work

» Needs review

Comment #4

tomogden CreditAttribution: tomogden commented 27 September 2011 at 17:52

It has been explained to me that tab characters are not allowed at all, regardless of width. I have removed all tabs and rechecked spacing.

Changes are ready for review.

Comment #5

jthorson CreditAttribution: jthorson commented 11 October 2011 at 23:46

Status:

Needs review

» Needs work

tomogden,

To help my understanding, can you provide an explanation on how the functionality of this module differs from that offered by, for example, the 'User Restrictions' module, which was built to replace this capability which used to exist in Drupal 6 core?

Thanks!

Comment #6

tomogden CreditAttribution: tomogden commented 14 October 2011 at 17:01

Status:

Needs work

» Needs review

Thank you very much for responding.

Put simply, this User Email Domain module is simple to use, lightweight and the simplest way to accomplish this use case without incurring a lot of functional baggage.

The User Restrictions module does have the reputation of being able to do "everything". Unfortunately, my attempts to install and run it have failed, even with patches. On one site the config page is redirected to the People landing page. In another basic installation I can reach the config page, but only the "Mask" field shows up, and any attempt to submit the form ends in code failure.

Consider the fact that User Restrictions currently only shows 46 installations. That's statistically insignificant in the Drupal community, especially for a legacy module. None of the listed contributors have contributed anything since D7 launched.

The old Rules module, which was the D6 incarnation was quite powerful, but it is a more complex UI than many of my users care for. Even so, I would consider using it if the D7 version had a viable alternative. Still, this module fills a need.

Comment #7

sreynen CreditAttribution: sreynen commented 15 October 2011 at 16:30

Status:

Needs review

» Reviewed & tested by the community

Hi tomogden,

You should add a description of how your module differs to the project page, to help users choose. Toward that goal, I strongly recommend simply pointing out objective differences and leaving users to make their own value judgements on those differences.

On to the review, I noticed just one minor issue: useremaildomain.info should include files[] = useremaildomain.checker.inc so this class can be auto-loaded, even if you're not relying on auto-loading.

Otherwise, I didn't notice any problems, so I think this is ready to approve.

Comment #8

tomogden CreditAttribution: tomogden commented 17 October 2011 at 14:25

Excellent recommendations. I have added the [files] entry to the .info file.

I have added the following to the description:

This project has a very simple focus and narrow use cases in contrast with the User Restrictions module, which is a more full-featured security solution.

I have asked a colleague in security systems here to look at User Restrictions to see if there's a way to get it to work for us. That module would have great potential for our benefit.

Comment #10

greggles

he/him

English

Denver, Colorado, USA

CreditAttribution: greggles commented 19 October 2011 at 00:55

Status:	Reviewed & tested by the community	» Fixed
Issue tags:		+PAreview: security

Small notes:

_mail_useremaildomain_validate looks like it has some odd spacing issues at the end.

165 form_set_error('mail', t("@title address domain, '@domain', cannot be registered.", array(@title => $checker->title, @domain => $checker->domain)));

You need '' around @title and @domain.

useremaildomain_form_alterTEST from useremaildomain.admin.inc looks like dead code that can be removed (since TEST is going to cause the hook not to be called.

I also created #1313952: filter useremaildomain_description, avoid clobbering validators which should ideally be fixed before creating a release, but doesn't need to be handled as a security issue since it requires the "administer site configuration" permission to exploit (see the policy for details).

Thanks for your contribution, tomogden! Welcome to the community of project contributors on drupal.org.

I've granted you the git vetted user role which will let you promote this to a full project and also create new projects as either sandbox or "full" projects depending on which you feel is best.

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.

As you continue to work on your module, keep in minde: Commit messages - providing history and credit and Release naming conventions.