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

Portal Pages

The Registration Server Portal Pages allow a Provider to setup Web-based registration and login for TeamDrive. Pages are also provided for handling two-factor authentication using the Google Authenticator App (as described in How to Setup Two-Factor Authentication).

There are currently three main reasons for using the Portal Pages:

  • In order to use two-factor authentication.
  • To provide TeamDrive Web Portal (and other internet) users with a Web-based registration.
  • To customise the login and registration user-interface for the users of a particular Provider or Registration Server. Such a customisation is usually based on a corporate identity.

The Portal Pages are template pages which can be customised by a Provider. The is done in the Admin Console as described in Manage HTML Templates.

The pages contain variables which are replaced by the appropriate values when the page is requested. They also contain optional sections which enclosed by markup of the form [[IF:<cond-var>]], [[NOTIF:<cond-var>]] and [[ENDIF:<cond-var>]]. Optional sections depend on “conditional variables” (indicated as <cond-var>) which can either be “true” or “false” (variables that are “false” are empty).

Not all variables and optional sections are available in all pages. Only the variables and markers used in the default templates are guaranteed to be valid.

Note: be sure to not change the “name” or “id” of any od the input fields used in the Portal pages.

The URLs of the portal pages have the following form:

https://regserver.yourdomain.com/pbas/td2as/int/<page>.html

In order to use the Portal login and registration pages in the TeamDrive Client you must enable external authentication by setting USE_AUTH_SERVICE (USE_AUTH_SERVICE) to True. You must then add the following settings to CLIENT/PRE_LOGIN_SETTINGS (PRE_LOGIN_SETTINGS):

enable-login=false
enable-web-login=true
enable-registration=false
enable-web-registration=true

Substitution Variables

This is a list of variable used in the Portal Page templates:

[[REG-SERVER-NAME]]:
The name of the Registration Server.
[[DISTRIBUTOR]]:
The Provider Code of the Provider of the templates being used. Usually this is set by using the “dist=” search arg in the URL which references the page. If no search arg is provided, the Registration Server will return the templates belonging to the default Provider of the Registration Server.
[[LANGUAGE]]:
The language of the templates being used. Usually this is set using the “lang=” search arg in the URL that references the page.
[[AUTH-TOKEN]]:
This is the “authentication token”. This is a unique token issued by the Registration Server after successful login. A 3rd party system can verify a valid login by making a request to the “verify.html” “virtual” page with “authentication_token=” as search arg. Authentication tokens are only valid for a limited time.
[[AUTH-COOKIE]]:

The authorisation cookie is issued by the Registration Server after successful login. The cookie contains non-sensitive information (which includes the login name), about the users registration or login session. It should be passed back to the Registration Server by 3rd party systems, using the “cookie-” search arg, on the next login attempt by the same user.

This is a convenience to the user who, which restores some of the context of the pervious login so that the user does not have to retype his login name (username or email), for example.

[[USER-SECRET]]:
The user secret is generated by the Registration Server after successful login. It is a hash based on the users password which is used by the TeamDrive Client to access the Registration Server Key Repository.
[[COMMON-NAME]]:
This variable is currently not used (returns the empty string).
[[PHONE]]:
This variable is currently not used (returns the empty string).
[[EMAIL]]:
This is the email address of the user.
[[MOBILE]]:
This variable is currently not used (returns the empty string).
[[NEWSLETTER]]
The value is either “true” if the user is receiving the TeamDrive newsletter or not.
[[LOGIN-URL]]:
This variable is replaced by the URL of the login page.
[[ERROR-MESSAGE]]
This is a error message which is generated in the case of an unexpected error, for example due to a misconfiguration. The user may not understand the error, but the message should help with analysis of the problem. Further information about the error may be found in the /var/log/td-regserver.log file (see View Server Logs).
[[SERVER-DOMAIN]]:
This is the domain of the Registration Server.
[[USERNAME]]:
The username of the user.
[[TEMP-PASSWORD]]:
The variable contains value of the temporary password input by the user.
[[NEW-PASSWORD]]:
The new password of the user when changing passwords.
[[REPEAT-PASSWORD]]:
The repeat password of the user when changing passwords.
[[USER-DIST]]:
The user’s Provider Code after login. This is the actual Provider of the Registred user, which may be different to [[DISTRIBUTOR]], which is the Provider Code of the templates being used.

Conditional Variables

As mentioned above, conditional variables appear in [[IF:<cond-var>]]... [[ENDIF:<cond-var>]] or [[NOTIF:<cond-var>]]... [[ENDIF:<cond-var>]] blocks, which are called optional sections.

This is a list of conditional variables which can be used to specify optional sections. Note that substitution variables may also be used as conditional variables. In this case the variable is considered “true” if its value is not empty.

NOT-ACTIVATED:
This variable is “true” if the user’s account is not activated. This means that the user must still click the link in the activation email.
ACTIVATION-SENT:
This is set to “true” after the activation email has been sent.
REGISTER-ALLOWED:
“True” if registration is allowed. If not, users can only login using the Portal Pages.
DEBUG-MODE:
“True” of the Registration Server is in the debug deployment mode. The deployment mode can be set in the /etc/yvva.conf file (see List of relevant configuration files).
INCORRECT-CODE:
“True” if the Google Authentication code entered is incorrect.
INCORRECT-LOGIN:
“True” login failed because of an incorrect username, email or password.
ACCESS-DENIED:
This variable is set to true if the Portal Pages are used by the TeamDrive Web Portal, and the user does not have permission to access a Web Portal
INPUT-REQ:
Set to “true” if some input is missing.
PASSWORD-INVALID:
Set to “true” if the password is shorter than the required length.
PASSWORD-MISMATCH:
Set to “true” if the the “repeat password” does not match the new password.
PASSWORD-INCORRECT:
“True” if the temporary password entered is incorrect.
TEMP-SENT:
Setto “true” after the requested temporary password has been sent by email.

List of Portal Pages

portal-activate:
This page is display after registration but before the user’s account has been activated. The page may be used to resend the activation email. After the user has clicked on the activation link in the activation email, he can proceed, and is then logged in.
portal-goog-auth-login:
If two-factor authentication using the Google Authenticator App has been activated, the user will be directed to this page after login. Here the user is required to enter the authentication code provided by the App.
portal-goog-auth-ok:
This is the landing page after successful two-factor authentication using the Google Authenticator App.
portal-goog-auth-setup:
Users must be directed to this page to setup two-factor authentication using the Google Authenticator App.
portal-login:
The TeamDrive login page.
portal-login-ok:
This is the landing page after successful login.
portal-lost-pwd:

On this page users are required to enter the “temporary password”, and set a new password for their account. The temporary password is sent to the user via email the moment this page is requested, if an email address is provided as a POST or search arg.

The “”Get Temporary Password” button can be used to send or resend the temporary password. A temporary password is only valid for a limited time (10 minutes by default).

portal-register:
The TeamDrive registration page.

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 ALLOW_PASSWORD_CHANGE.

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 ALLOW_LOGIN_WITHOUT_EMAIL). 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.
support-notification:
This template will be used to send support notifications when a TeamDrive client uploads his logs together with the support informations. The email contains a link to the admin console to open the support case / download the client logs (see admin console/client log files)
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 (please notice that the two-factor authentication for the admin console is independent from the new client two-factor authentication added in version 3.6).

Mail Templates for API Actions

Certain API requests also trigger the sending of notification emails. Sending mails using API calls must be en-/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.