Provide custom email messages for specific consumer sites

[Stuart Metcalfe]

Specific consumers (eg: Ubuntu One, U1 desktop) want to be able to send custom emails for account creation and possibly others. For web-based OpenID transactions, we can detect the consumer site by the trust root. For API transactions, we would need to rely on the application name passed in on the request. We will also need to maintain a mapping between these values and the custom templates for specific consumers.

The first users of this feature will be Ubuntu One. Please provide the custom content for the email(s).

[Stuart Metcalfe (stuartmetcalfe)]

It's been agreed to just change the default template to the following:

Hello!

As a final step of the Ubuntu Single Sign On (SSO) account creation process, please validate the email address <email>. Ubuntu SSO enables convenient access to a variety of Ubuntu-related services like <sitename> with the same username and password.

Copy and paste the confirmation code below into the desktop application.

<code>

If you don't know what this is about, then someone has probably entered your email address by mistake. Sorry about that. You don't need to do anything further. Just delete this message.

Thank you,

The Ubuntu Single Sign On team
https://login.ubuntu.com/

The <sitename> variable will be the trust root's display name if one exists or will default to "Ubuntu One" if it's an unknown site.

[Łukasz Czyżykowski (lukasz-czyzykowski)]

For this release we'll hard code this template for all users created by API.

[Stuart Metcalfe (stuartmetcalfe)]

Moved the interim static version of this to bug #616827 for the Ubuntu 10.10 release.

[Stuart Metcalfe (stuartmetcalfe)]

I think the static version of the content is actually enough to mark this bug as "Won't fix" unless we want to add some optional 3rd party branding to the email content. Assigning to myself to check requirements with stakeholders.

[Stuart Metcalfe (stuartmetcalfe)]

Following discussions with U1, this will either need to be implemented with heavy customisation on our side or we'll have to find a way to pass SSO-specific info to them to include in their introductory emails (and flag to us that our email shouldn't be sent for this request, but custom emails are definitely wanted.