Confirmation e-mails should be sent to client users, not to the client email

Use the signup form to create sites and client nodes in one action

You can. if the client already exists.

create content >> site is more for admin use.

The clients will be able to create sites from themselves using node/$client_id/add/site
new clients can create accounts for themselves using hosting/signup.

I still feel that the contact email for the site should be the user. In fact, it could be considered that the user that created the site for client X is the main contact for the site. The hosting interface should also allow this setting to be changed on the fly and send password reset emails...

For future reference, the code that sets the client_email is in hosting_client.module, in hosting_client_provision_args(). The mail itself is sent from provision_drupal_send_welcome_mail .

The patch at :http://drupal.org/node/368020#comment-1234065 - MAY help.

Basically, my current stance on this bug is that we shouldn't have an email associated with the client, but with the users. Emails should be sent to some or all users of the client with the login URL.

I am also considering blending OpenID in there since we have a user database that is shared with our openid provider: every aegir user has an openid associated to it that we could just setup in the admin account of the new site. See #462790: enable SSO in deployed sites.

sooooo i am pretty close to marking this by design.

antoine: what do you think ?

I didn't have time to respond to this until now, but I don't see why we should send the email to the client instead of the user creating the account.

This, paired with #962330: refactor and clarify the fields in the client content type and #461840: type client/user relationships would make things much more orthogonal and sensical: emails would be sent to admin and tech contacts of the account, simply.

While the signup form allows creation of sites and clients in one shot, that doesn't cover all use cases, and especially not the "consulting firm" or "mass hosting" case where one client can have multiple sites and where you want to be able to control who the emails are sent to, for example.

Some progress here: I have opened a feature branch in the backend to get the email from the task dynamically. The branch is named dev-noreg-mail-336068

This requires the dev-refactor-client-962330 branch from #962330: refactor and clarify the fields in the client content type.

And if this doesn't work, i suggest we rip the mail sending code away from the frontend and do the mail stuff in the frontend, as a post task in hosting.

this actually work and is really simple - i posted a few patches on master.

More precisely, those patches are on hostmaster 'master' branch now and await testing before backporting.:

616053abf7e351d92d64ae5bdf118da76e8f8524
49a5d9f043520ae04e2d6041001babe6e7497ab8

this was merged in stable for the rc3 release.