account auto-creation: what next?

> A website account for the anonymous user is created, and a ticket 'node' created.
> However, I can't understand how this 'anonymous account' is supposed to be used?
> How is the staff member supposed to proceed?

That is completely up to you! This functionality could use a little love, for certain.

> The problem is that the 'new user' doesn't have a password, so they can't log into
> the new account.

Correct. They'd have to request a new password, however:

> Also they're not notified about the account anyway.

Correct.

> Is the staff member supposed to finish the account creation manually and email
> the information to the user?

That is how I currently do it, but it's obnoxious at best. And unfortunately I'm not sure what the perfect solution is -- I have _many_ accounts created that won't ever be used by logged in users. It's only for a few that I actually need to convert them into logged in users for viewing/updating tickets online. So ideally there should be an easy way to set a password / send notifications only for specific users.

I'd be interested in more feedback from the community. What is the preferred way to handle this? Should this be turned into a feature request, and if so what feature is needed here?

I would find some way to designate the account as a "client user account", then:

1. Write an Action that will reset a given account's password and email the user a welcome message with said password.
2. Create an interface (Views Bulk Operations perhaps) to trigger that action on whichever accounts an admin deems ready for promotion.

I consider this kind of feature very useful- it groups all the tickets related to a given customer under one account, and if that person is ever going to reach a point of "premium" support, or taking a more active role in the system, their entire history is automatically available to them. Alternatively, you could create a taxonomy term for each email address, and write a snippet of code to associate that content with the email address if it completes registration. Both approaches have security considerations.

/Just evaluating for future consideration.

subscribing
This is also an area that I see I will need to resolve shortly. Let me think this through..

Jeremy,

Perhaps this functionality could be changed slightly to prevent the emails from being taken when the user attempts to register a new account.
Could the initial support tickets have both a uid and a new field 'from' email address. For new support tickets the email is stored with the ticket.
Then upon new user creation at some later date, a support_user hook finds all support tickets with a matching 'from' email address and assigns the new uid to them.

Thoughts?

@grayside, i also think that it's better to include the password in the ticket creation notification when a new user is created

+1. i support the idea that the ticket submitter should be notified about the created account.
i think that the notification could use the "new user created by administrator" mail template.