Make auto-account creation optional

It depends on your configuration.

If you do not define a globally allowed domain at "Administer >> Support ticketing system >> Settings", and you do not define a valid email domain for your client at "Administer >> Support ticket system >> Clients", then all inbound email will be accepted. If the user does not have a user account, it will be automatically created for them.

If you define a globally allowed domain and/or valid email domains for your client, then only mail from those domains will be accepted -- again, accounts will be automatically created for users that do not have any. Mail coming from other domains, however, will be silently dropped.

Does this meet your needs?

Updating ticket title and marking as a feature request.

We are using the support module in our technical support. It is a great module.

One thing regarding the auto-creation of non-existing user:

Due to the auto-creation of accounts, we had to turn of the inbound e-mail.

When the user is auto-created, the same links as for an existing user is inserted in the e-mail, which ends up in links which the user can't access due to non-exisiting password; "Access denied...". Am I right here or am I missing something?

Another thing when auto-creating the account is that the user name is the e-mail address, which is visible in comments etc in forums.

One good thing if this feature is implemted, would be to send a response to the requesting user that he/she must create an account. The reply e-mail would have a link to the registration page of a new user.

Please give me feedback in this matter if I'm way off...

David

> When the user is auto-created, the same links as for an existing user is inserted
> in the e-mail, which ends up in links which the user can't access due to non-exisiting
> password; "Access denied...". Am I right here or am I missing something?

I don't believe that there are any notifications sent to autocreated users. Are you experiencing otherwise?

> Another thing when auto-creating the account is that the user name is
> the e-mail address, which is visible in comments etc in forums.

Correct. This is exactly what I needed for my use case, though I see that this may not be applicable for other use cases.

> One good thing if this feature is implemted, would be to send a response to
> the requesting user that he/she must create an account. The reply e-mail
> would have a link to the registration page of a new user.

At this point, it's probably worth seeing if there's a third-party module out there that implements these sorts of features, which the support module could be integrated with.

Regarding the returning e-mail to auto-created user.

I experience that the auto-created user gets an e-mail. Here is an e-mail which was returned to the auto-created user:
>>
auto-created-user@elvaco.se has created the ticket 'help':
http://elvaco.com/support-ticket/105#comment-0

State: new
Priority: normal

You can reply to this email or visit the following URL to update this ticket:
http://elvaco.com/support-ticket/105#comment-form

Ticket text:
...
<<

Am I doing something wrong?

Best regards,

David

Subscribing. Got the same issue here. We want to send out notifications to the ticket creators but we don't accounts being created for them. (In essence an anonymous ticketing system in which the only point of contact those users get are the emails)

I just did a request for almost the same thing hopefully mine will just get merged with this one. The user autocreate is a major issue especially if you want to use email integration. We want forms from other non drupal systems in the organization to email an inbox, each inbox is setup as a different client and is autoasigned to the proper staff automatically. However because the sytem runs on the staff intranet as a "application" outside users that email the account automatically get a working account on the staff intranet. The only option now is to create a new user role "staff" and deny authenticated users access to the entire system, which means because we use LDAP authentication staff accounts have to be created in ldap, then the admin has to log in as that new user in drupal then on a seperate browser logged in as an admin account change the newly logged staff member from authenticated user to staff. Something I am not going to get the powers that be to agree to.

Disabling auto creation would be a fabulous feature. For my install I've modified the support.module so that it doesn't create new accounts for unrecognized users. It was about 10 lines of code.

Question for maintainer - shall I work this up as a menu option and provide a patch for your review?

Essentially all I am doing is faking the user object with my own fake object when user_save() is called. Since there is no real user, I have to append the $message['from'] to the $message['body'] so the anonymous post can be tracked back to whoever submitted it. It's not an ideal solution, but it does the job.

-Daniel

Patches are always welcome. I'll take a look at what you've done, and we'll go from there. Thanks!

Your solution regarding the user sounds workable, as if we're not tracking the user for email generated tickets when no email matches then their tickets will have to be assigned to the anonymous user...

Subscribing.

How is this coming along?

I would be glad to help both with development and testing. Do you have a patch or some code i could work out a patch from?

I'm thinking it would be nice with a checkbox integrated on each 'client' to get a detailed control on the system.

I have implemented a feature to turn off automatic user creation on our site. I don't think I have it exactly right since I am saving the setting as a variable in the 'support_admin_settings()' function. I think this option should be client specific but I haven't 'dared' go in and mess with the database to save values.

Do you have any recommendations on how to solve this without messing with the DB or is it ok if I create a field for this together with the fields on 'Inbound email integration'.

This is what I've come up with so far:

support.admin.inc, line 354 in support_admin_settings()

$form['user']['support_disallow_user_creation'] = array(
    '#title' => t('Disallow user creation on incoming mail'),
    '#type' => 'checkbox',
    '#default_value' => variable_get('support_disallow_user_creation', FALSE),
    '#description' => t('Check this box if you would like to turn off automatic user creation on incoming support mail. A notification will be sent to the user informing them that they have to register to be able to create support tickets via mail. This on only applicable if you have enabled "Integrate inbound email".'),
  );

support.module, line 454 in support_accound_load()

elseif (variable_get('support_disallow_user_creation', FALSE) == TRUE) {
  // User does not exist and the setting to disallow automatic creation is turned on so send notification to user and log it
  watchdog('support', 'An autocreation of a user from the e-mail address: !from was denied. The client recieving the request was: !client', array('!from' => utf8_encode($from), '!client' => $client->name));
  _support_mail_deny($from, $subject, $client->name);
  return FALSE;
  }

support.module, line 964 in support_mail_tokens()

'!uri_login' => url('user/register', array('absolute' => TRUE)),

support.module, line 1023 (after entering above code) in _support_mail_text()

case 'ticket_deny_subject':
  return t("Support ticket creation denied", $variables, $langcode);
case 'ticket_deny_body':
  return t("You have tried to create a support ticket on the !site site. The creation of the ticket has been cancelled since the e-mail address you sent the message from is not registered at our site.\n\nYou have to be a registered user to be able to create support tickets via mail.\n\nYour errand is important to us so please register at !uri_login and try again.\n\n!site Team", $variables, $langcode);

support.module, line 1382 (after entering above code) added a function

/**
 *	Using drupal_mail to send notification mail
 *	to user that is not registered and tried to
 *	use mail support.
 */
function _support_mail_deny($to, $subject, $client) {
  $language = language_default();
  $key = 'ticket_deny';
  $params = array();
  drupal_mail('support', $key, $to, $language, NULL);
}

I think in general this should do the trick but it would be nice to get the setting into the client settings instead.

It would be significantly easier to review your contributions if you attach them as patches. Here's a page talking about how to create patches:
http://drupal.org/patch/create

(And to answer your question, I don't see any problem with adding the per-client option to the inbound email integration options -- but you'll still need a database field to save this in.)

Ok, attaching a patch to the .install, .module and .admin.inc file and changing to needs review.

EDIT:
Argh, wrong one. Another one coming up in a sec.

Ok, here's another one.

Will try to make sure i get it right from now on.

Found another bug of course.

3 is the magic number!

Great, thanks! I made some changes:

• White space cleanup, removing tabs and cleaning the code to match the Drupal coding standards where necessary
• I added a global configuration option (your patch only included a per-client configuration form option)
• I cleaned up the help text a bit
• I reversed the logic so you uncheck the new box to disable the autocreation of users
• I cleaned up the logic when determining whether or not to create a new user so we don't duplicate code
• I added an update hook in the _install file.

The resulting patch was committed here:
http://drupal.org/cvs?commit=329136

Ok, looks good :]