HTML and EMail Templates

HTML Templates

Activation pages

When activating a new TeamDrive installation, an activation link is sent to the user via email. The activation link will direct him an activation web page on the Registration Server. Each Provider has their own activation pages, so that they can be modified to match the CI of the Provider.

The templates for these pages are stored in the Registration Server’s database and can be edited using the Administration Console. If you are upgrading from a pre-3.5 version of the Registration Server, your templates will be imported from the file system into the database automatically during the upgrade process.

The success page is:

activated-<platform>

<platform> can be win, mac, linux, ios, or android

Error pages are:

  • activated-already: Link was already clicked and the device is activated
  • activated-error: Unexpected error occurred
  • activated-invalid: Activation code invalid
  • activated-notfound: Activation code not found

Note

The system settings ActivationURL and ActivationHtdocsPath have been deprecated. If you were using these settings to re-direct to another server (which then, for example, uses the API to activate the device using an API call) on activation, you should now use the template stored in the database to perform the re-direct. This can be done by replacing the contents of the template with: Location: <url>, for example:

Location: http://www.example.com/my-activation-page-for-mac

Email pages

Changing an email address will send a notification email to the old email address, informing the user the new address is being set for the account, and an activation mail to the new email account.

The user must click the activation link in the activation email to confirm the change. He will then be directed to an activation web page on the registration Server.

The email change web page templates are stored in the database and can be edited using the Administration Console. If you are upgrading from a pre-3.5 version of the Registration Server, your templates will be imported from the file system into the database automatically during the upgrade process.

The success page is:

newemail-activated

The error pages:

  • newemail-error: The email address is already in use
  • newemail-duplicate: Unexpected error occurred
  • newemail-invalid: Activation code invalid
  • newemail-notfound: Activation code not found

Email Templates

The templates in the admin console are grouped into categories for a better overview:

  • CLIENT-INTERACTION
  • TRIAL-LICENSE
  • USER-INVITE-USER
  • SERVER-ADMINISTRATION
  • API
  • API-LICENSE-CHANGES

They are hidden by default if your settings will not require to use them, like the templates in the API-group if you dont use the Registration Server API.

The main group “CLIENT-INTERACTION” will be triggered by actions from the TeamDrive Client and will always be used.

There are templates for English and German available. The language in the filename is located at the last part of the filename (example: new-passwd-de.email). Additional languages can be added by creating a new file with a new language code.

Each Provider has their own set of templates, so that each Provider can use their own text and graphics in the templates. Each Provider has to define the available and allowed languages in their Provider settings as described in EMAIL Settings.

Templates can be all plain-text or plain-text with an HTML part. By default, the invitation templates have a text and an HTML part. All other templates are completely in plain text. All templates can be modified by you.

The notification mails for spaces or files can not be modified. This mail is directly generated by the teamdrive clients and can not use a template.

Structure of the mail templates

Text mail: The subject of the email will be divided using these two characters “//”. Everything before will be used as the subject. Everything behind is the mail body.

HTML mail: The structure is a little more complicated (see http://en.wikipedia.org/wiki/MIME#Multipart_messages), because for mail clients which do not display HTML you have to offer a plain text part. Otherwise the email will be shown as empty within this mail client. The template is divided into several parts. Replace the place holders with your content:

  • Definition of a multipart-mail (the boundary string will be used in the following text and HTML part):

    Content-Type: multipart/alternative; charset=UTF-8;
    boundary='www_teamdrive_net_e_mail_boundary_625141'
    
  • followed by the subject (divided by “//” again):

    //TeamDrive invitation//
    
  • followed by the text and HTML part:

    --'www_teamdrive_net_e_mail_boundary_625141'
    Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed
    Content-Transfer-Encoding: 8bit
    
    <Put in your plain text here>
    
    --'www_teamdrive_net_e_mail_boundary_625141'
    Content-Type: text/html; charset=UTF-8;
    Content-Transfer-Encoding: 8bit
    
    <put in your HTML code here>
    
    --'www_teamdrive_net_e_mail_boundary_625141'--
    

Templates for Client actions

[[BRAND]]
The product brand name, defined in the provider-specific setting EMAIL/BRAND_NAME. If not set or empty, the default is “TeamDrive”.

[[FULLGREETING]] or [[GREETING]]

depot-changed:
If the default depot changed on the server, the user will recieve this confirmation mail.
inv-email-invited (old name: td3-privacyinvited-email):

If a new user was invited who currently had no account, they will get an invitation sent to their email by the person who invited the user. A download link for the client application should be in this template so that the user can download and install the client. There are two new fields which have the same content, but have different line breaks:

[[INVITATIONTEXT]]: The invitation text the user wrote in the client application. Line breaks are carriage return

[[INVITATIONTEXTHTML]]: The same text, but line breaks are HTML conform <br>

[[DOWNLOADLINK]]: Download link taken from the download Redirect-URL page as described in REDIRECT_DOWNLOAD.

inv-email-invited-passwd (old name: td3-privacyinvitedsecure-email):
Same as above, but with the additional mechanism that the user has to type in a password to accept the invitation. The password will be defined by the user who send the invitation. (This is an additional security option to prevent anyone from accidentally inviting an invalid user)
inv-user-invited (old name: td3-privacyinvited-user):

Nearly the same as an invitation by email, but the user already exists and therefore they get invited via their username.

[[INVITEDUSER]]: The username of the invited user.

inv-user-invited-passwd (old name: td3-privacyinvitedsecure-user):
Before accepting the invitation the user must enter a password (as specified by the sender).
new-passwd:

If the user lost their password, they can reset the password during the login process (see Forgotten password for details). There must be one field in the email which will be replaced before the email can be send:

[[NEWPASSWORD]]: Only a temporary password will be send, which must be entered in the client together with some new password as specified by the user. Retrieving a new password also depends on the setting as described in registration server settings/client settings/allowpasswordchangeinclient.

Changing both password and email at the same time is not possible. If the email is different, this has to be changed before the password is changed.

passwd-changed:
Will be send, if the user change his password within the client application or using the API call updatepassword.
passwd-invalidated:
Will be send, if the password was invalidated using the admin console / API call resetpassword.
passwd-reset:
Will be send, if the password was invalidated using the admin console / API call resetpassword and external authentication is activated.
reg-activationlink:

This will send an email with an activation link to the user. They can only proceed with the registration by clicking the link within the email. The link must lead back to your server, so that the activation code can be verified. There are three fields available which will be replaced before the email will be send to the user:

[[SERVERURL]]: This is the URL defined in the xml file as described in RegServerURL. You can also replace it with an other URL which also points to the Registration Server. If you prefer to use an own page, you can use the Registration Server API which can also activate an installation.

[[SERVERPATH]]: The script name (“pbas/td2as”) of the internal module which handles the activation requests.

[[ACTIVATIONCODE]]: This is the activation code of a non-activated installation. The code is unique for each new installation, and is used for verification by the server.

[[DISTRIBUTOR]]: The Provider Code, which will be used to redirect to the success or error page (which are defined as described in HTML Templates).

reg-activationwithnewsletter:
Nearly the same like the above reg-activationlink. The template will be used in case the user accepted recieving newsletter in the client. This template could be used to confirm the activation together with accepting recieving newsletter.
reg-emailchangedtonew:

Upon requesting an email change, the user will receive an activation URL to verify that the new email belongs to him. The following fields are available:

[[SERVERURL]]: The same as described above in reg-activationlink

[[SERVERPATH]]: The same as described above in reg-activationlink

[[EMAILVERIFY]]: An verification code like the activation code in reg-activationlink

[[DISTRIBUTOR]]: The same as described above in reg-activationlink

reg-emailchangedtoold:
Whenever the user’s email is changed, a verification email is sent to the old address (to protect the user against potential hacking attempts). The following fields are available: [[NEWEMAIL]]: The new email address of the user
reg-notify:
By default, only the first installation must be manually activated (depends on the setting described in registration server settings/client settings/allowactivationwithoutemail). The user will just receive a notification mail that an additional device was installed

Mail Templates for trial licenses

Licenses expiry mails will be send in case of a configured ENABLE_LICENSE_EXPIRY and a PROFESSIONAL_TRIAL_PERIOD in the provider settings. There are three templates: ten days before the license will expire, three days before and at the day the license expired.

license-expired:
This template will be send, if you the license is expired. The user will fall back to his default license. The expired license could not be used any more and the user could not request a new expiry license.
license-expirein3days:
Three days before the license will expire, the user will recieved this email.
license-expirein10days:
Ten days before the license will expire, the user will recieved this email.

Mail Templates for user invite user

reg-storageincreasedinvited:

This mail will be used if you use the user referral functionality. Each new user which is invited, as well as the inviter, will get additional storage space. Configuring this functionality is described in chapter REFERRAL Settings.

This template will be send as a confirmation mail to the user which was invited. You can use the following fields: [[REFUSER]]: The username which invited the new user [[STORAGEINCREASED]]: The amount of storage which was added to the account.

reg-storageincreasedinviter:
This template will be send as a confirmation mail to the user which invited the new user. You can use the following fields: [[REFUSER]]: The username of the user which was invited [[STORAGEINCREASED]]: The amount of storage which was added to the account.

Mail Templates for Server Administration

email-setup:
Test email for verifying the SMTP configuration during the server configuration and to finalize the setup with the activation link in the mail. Several of the above macros will be used in the template. There is no need to customize this template.
two-factor-auth:
If the admin console will detect a second login attempt for an already logged in user, the second user has to request a mail for a two-factor-authentication. This template will send the requiered authentication code.

Mail Templates for API actions

Certain API requests also trigger the sending of notification emails. This can be disabled, see API_SEND_EMAIL.

The links within the templates must be point to a page where you call an API function again.

For more information on using the Registration Server API, see API Basics.

web-activationlink:
Similar to reg-activationlink.
web-activationwithnewsletter:
Similar to reg-activationwithnewsletter.
web-delete-user:
Deleting a user will delete all devices. Licenses (if defined) and all Spaces (if defined). So the user has to confirm to delete all his data.
web-emailchangedtonew:
Similar to reg-emailchangedtonew.
web-emailchangedtoold:
Similar to reg-emailchangedtoold.
web-newlicensepassword:
A license can be created without an user binding. To make this license managable by the license holder, an special license password will be created. This template can be used to request a new license password.
web-newpassword:
Similar to new-passwd.

Mail Templates for API license changes

Sending the API license change notifications will be defined in the parameters when calling the API function.

license: A language matching file for the actions used in the macro
[[CHANGE-TYPE]]
holder-license-rec:

A license confirmation mail for the holder of a new created client license.

[[TICKET-NUMBER]]: The number of the license key [[HOLDER-PASSWORD]]: The password for administrating the license key [[TICKET-TYPE]]: The type of the ticket: Permanent, Monthly Payment, Not for Resale, Yearly Payment, One-off Professional Trial License,1-Year Professional License Subscription [[HOLDER-CONTRACT]]: The contract number of the license. [[HOLDER-EMAIL]]: The email of the license. [[TICKET-LIMIT]]: The license user limit. [[TICKET-FEATURE]]: The feature for the license: Banner, WebDAVs, Personal, Professional, Restricted, SecureOffice [[VALID-UNTIL]]: In case of license with an expiry date.

holder-license-cha:

A license confirmation mail for the holder of a modified client license.

[[CHANGE-TYPE]]: An information what was changed (see license-template).

holder-tdpslic-rec:
A license confirmation mail for the holder of a new created personal server license.
holder-tdpslic-cha:
A license confirmation mail for the holder of a modified personal server license.
reseller-mod-license:
A license confirmation mail for the provider of a created / changed client license.
reseller-mod-tdpslic:
A license confirmation mail for the provider of a created / changed personal server license.