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 user, and an activation mail to the new email address.

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.

Since Registration Server version 3.6.2, the Portal Pages will not allow login of a user that has previously logged in using an external authentication service, such as LDAP or AD.

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.

You can also set variables using the following syntax:

[[SET:<variable>=<value>]]

Variables set in this way can be used in substitutions. Note that the order of appearance in the template in not important. Conditional sections are evaluated first, then set variables are executed, and finally substitutions take place.

Note: be sure to not change the “name” or “id” of any of 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 set to “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.

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
ACTIVATION-SENT:
This is set to “true” after the activation email has been sent.
DEBUG-MODE:
Set to “true” if 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).
DUP-EMAIL:
Contains “true” or an error message when the email address is already in use.
DUP-USERNAME:
Contains “true” or an error message when the email address is already in use.
EMAIL-INVALID:
Contains an error message when the email address is not valid.
EMAIL-PWD-REQ:
Set to “true” if the Provider code, email or password is not provided by the user.
EXT-LOGIN-REQ:
Set to “true” if the user is using an external authentication service. In other words, the user previously logged in using an external authentication service. In this case login using the Portal Pages is not allowed.
INCORRECT-CODE:
Set to “true” if the Google Authentication code entered is incorrect.
INCORRECT-LOGIN:
Set to “true” login failed because of an incorrect username, email or password.
INPUT-REQ:
Set to “true” if some input is missing.
NOT-ACTIVATED:
This variable is “true” if the user is not activated. This means that the user must still click the link in the activation email.
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:
Set to “true” if the temporary password entered is incorrect.
REGISTER-ALLOWED:
“true” if registration is allowed. If not, users can only login using the Portal Pages.
SETUP-2FA:
Set to “true” if clicks link to setup 2-factor authentication. This variable indicates that after login, 2-factor authentication will be enabled.
TEMP-SENT:
Set to “true” after the requested temporary password has been sent by email.
UNKNOWN-DIST:
Set to “true” if the Provider code that was entered is unknown.
USERNAME-INVALID:
Set to an error message if the username contains an invalid character is has the incorrect length.
USERNAME-REQ:
Set to “true” if a username is required.

List of Portal Pages

portal-activate:
This page is display after registration but before the user 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 user. 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.

Set Password Pages

These pages are used in conjunction with the registration of user via the API or using the Admin Console.

The “Set Password Pages” are reached by from a link in the email templates: web-activationsetpassword in the case of an API call, or reg-activationsetpassword in the case of the Admin Console. The web-activationsetpassword email is send by the “registeruser” API call when the <setpassword> tag is set to true. Sending the reg-activationsetpassword email is the default option when creating a user in the Admin Console.

The link in the web-activationsetpassword email may reference a custom set password page, which is implemented by the provider.

The link includes arguments that include the user’s preferred language, the provider code and an activation code generated by the Registration Server during registration.

These pages contain variables which are replaced by the appropriate values when the page is requested. Like the portal pages 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).

set-password:

This allows the user to set a password and activate the user account. The user may also select whether he/she would like to receive a newsletter or not, before activation.

Users with accounts that have already been activated will not be allowed to access this page. Instead they will be redirected to the set-password-error page.

The following fields are available:

[[PASSWORD-REQUIRED]]: Set to “true” if a password was not provided by the user, otherwise empty.

[[REPEAT-INCORRECT]]: Set to “true” if the verification password does not match the password entered, otherwise empty.

[[INVALID-PASSWORD]]: Set to “true” if the password is too short, otherwise empty.

[[MIN-PASSWORD-LEN]]: Contains the minimum password length.

[[NEWSLETTER]]: Set to “true” if the user currently accepts the newsletter.

set-password-error:

This page is returned if there is something wrong with the activation code or if the user is already activated.

The following fields are available:

[[INVALID-CODE]]: Set to “true” if the activation code is missing or invalid, otherwise empty.

[[ALREADY-ACTIVATED]]: Set to “true” if the user is already activated, otherwise empty.

set-password-ok:
After successful activation, the set-password redirects to this page. On this page you may place links to download the client software, or a link to the online Web-portal.

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

The following fields are available in all or a number of email templates:

[[BRAND]]:
The product brand name, defined in the provider-specific setting EMAIL/BRAND_NAME. If not set or empty, the default is “TeamDrive”.
[[GREETING]] or [[FULLGREETING]]:
The greeting form used is determined by the contents of the greetings email template. If the username is known, then it will be included in the greeting. If only the email address is known, then a general greeting is used.
[[ADMIN-CONSOLE]]`, ``[[USER-IMPORT]], [[LOGIN-PORTAL]], [[CLIENT-CALL]], [[API-CALL]]:
One of these is set to “true” in order to specify the sytem that initiated the email.
[[3RD-PARTY-REG]]:
This field is set to “true” of the origin is either ADMIN-CONSOLE or USER-IMPORT. The field means that the registration of a user was initiated by a 3rd party, rather than the user himself.

These templates are sent depending on certain events are actions that take place in the TeamDrive client software, the Login Portal or the Admin Console.

inv-email-invited (old name: td3-privacyinvited-email):

If a new user was invited who is currently not registered, they will get an invitation sent to their email address 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-activationnotify:
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.
reg-activationsetpassword:

When a user created in the Admin Console the default option is to send an email using this template. Ths email contains a link to the set-password HTML template page, which allows the user to set his password, and activate his user account (see ref:html_templates_set_password_pages).

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-activationwithnewsletter:
This template is sent in place of reg-activationlink if the user accepted recieving the newsletter in the client. The email is used to both activate the user and to accept the receipt of the 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-registrationnotify:
This email is sent when a user is registered on the Admin Console, and the user is activated during creation.

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 user’s default depot.

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 user’s default depot.

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 Download Client Log Files)
two-factor-auth:
If the admin console detects 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 required 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 reference a page that has access to the Registration Server API.

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

web-activationlink:
Similar to reg-activationlink.
web-activationsetpassword:
Similar to reg-activationsetpassword, but the link may be changed to reference a custom page created by the provider (see ref:html_templates_set_password_pages).
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-depotchanged:
This email is sent of the user’s depot configuration changed. This can be in the form of a addition or removal, or the default depot is changed on the server.
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.
web-registrationnotify:
This email is sent when a user is registered using the “registeruser” API call, and the user is automatically activated. If the user is not automatically activated, then the web-activationlink or web-activationwithnewsletter email will be sent.

Mail Templates for API License Changes

In the Admin Console you can determine whether a license change email is sent to the license owner (or holder) using the checkbox titled Send license change email. The checkbox is set to checked by default if the API_SEND_EMAIL provider setting is set to True.

With regards to the API, whether an email is sent to the license owner is determined by the <sendmail> tag which may be set to true or false. If this tag is missing then by default an email is not sent accept in the case of the “resetlicensepassword” API call.

Other API calls that do not involve changing licenses use the API_SEND_EMAIL provider setting as the default. This includes calls involving change of password and changes to a users depot configuration.

Note that a license change email are always sent to the provider regardless of any settings or user selection. The providers License email address is used for this purpose.

If the license has no owner, then the value set for the Holder email of the license is used. The language used in the email can also be set in the appropriate license field for this purpose.

license:
A language matching file for the actions used in the macro [[CHANGE-TYPE]]
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-license-rec:

A license confirmation mail for the holder of a newly 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: WebDAV, Professional, SecureOffice, Agent and Restricted.

[[VALID-UNTIL]]: In case of license with an expiry date.

holder-tdpslic-cha:
A license confirmation mail for the holder of a modified personal server license.
holder-tdpslic-rec:
A license confirmation mail for the holder of a newly created 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.

Mail Templates for Groups

group-friend-invitation:
This email is sent to invite a user to a group as a friend.
group-member-invitation:
This email is sent to invite a user to a group as a member.