Skip to content
This repository has been archived by the owner on Jan 4, 2022. It is now read-only.

TicketDesk 2.1 Configuration

Jump to bottom
StephenRedd edited this page Dec 27, 2014 · 5 revisions

Configuration & Settings:

Email Settings:

Email settings are stored in the web.config file in the mailSettings section under system.net. A typical setup for email using a locally installed SMTP agent would look like this:

 <system.net>
    <mailSettings>
      <smtp deliveryMethod="Network">
        <network host="localhost" port="25" defaultCredentials="true"/>
      </smtp>
    </mailSettings>
  </system.net>

In addition to the mailSettings in web.config, it is CRITICAL that you also set the "Site Root Url For Email" setting. This is done through the online administration tools, in the application settings section. This should be set to the full URL for the root of your deployed web site, exactly as you'd see it in a browser. If this setting is incorrect, hyperlinks and images in the email notifications will be broken, and in some cases email notifications may not be delivered at all.

Connection Strings:

The default configuration for TicketDesk 2.0 uses a single SQL database. This differs from previous versions of TicketDesk where the default configuration used seperate security and ticket databases.

Even though TicketDesk 2.0 only uses a single database by default, it still contains three connections strings:

  • TicketDeskSecurityConnectionString: This is a standard connection string that points to the ASP.NET security database you wish to use. The default configuration for TicketDesk 2.0 stores the security data directly in the TicketDesk database.

  • TicketDeskEntities: This is an EntityFramework 4.0 connection string that points to the main ticketdesk database. You will notice that EF connection strings are a little more complex than straight SQL provider connection strings.

  • ElmahLog: This is the connection string used by the ELMAH exception logging system. You may prefer to use a different database to combine ELMAH data from multiple applications, but the default configuration stores the ELMAH data in the ticketdesk database.

Alternate Database Server Editions:

TicketDesk can leverage almost any edition of Microsoft SQL Server 2005, 2008, or 2012. Express editions and full versions are both supported, as well as 2012 localdb.

If you are using SQL Express 2008 (non-R2) or SQL Express 2005 then an alternate file database is included in the {"app_data/SQLExpress2005FileDatabase"} folder. Simply replace the database files in the {"app_data"} folder with the ones in the SQLExpress2005FileDatabase folder.

If you are using a full edition of SQL 2005, 2008, or 2012, or want a permanently attached database within an express edition, then you can manually create the database using the scripts included in the {"app_data/NewDatabaseScripts"} folder. See the readme.txt file included in that folder for more information on using the scripts.

Please note that you will need to modify the connection strings in web.config.

The SQL express database files work with SQL 2012 localdb, just alter the connection strings in web.config to target your localdb instance instead of SQL express; e.g. change ".\SQLExpress" to "(localdb)\v11.0"

SQL Security Environments:

By default TicketDesk uses ASP.NET membership, role, and profile providers for security. The data is stored in a SQL database. The default configuration assumes the security database will be part of the main ticketdesk database.

A full discussion of alternative configurations for the security providers is far beyond the scope of this document, but the most common scenario is to use a separate asp.net security database. TicketDesk's web.config includes a separate connection string for the security providers to make this scenario simpler to configure.

The default web.config is already setup for SQL environments, but a copy of the stock SQL security settings can also be found in the SQLWeb.config file in the application's root folder.

Active Directory Security Environments:

TicketDesk also has support for Active Directory authentication. This requires a bit of manual configuration though.

NOTE: When configured for AD environments, TicketDesk will still use the SQL security providers for roles and profiles. An asp.net SQL security database is still required, but all membership operations will use AD instead. Please note that TicketDesk is NOT designed for use with local windows security (non-AD windows security).

To use TicketDesk within AD environment you should replace the contents of web.config file with the contents from the file named "ADWeb.config", which is included in the root of the web site.

You must then change some of the app settings in the web.config file to fit your environment. You must map three AD groups to fixed ticketdesk "roles". It is HIGHLY recommended that you create new groups in AD specifically for use with TicketDesk rather than using built-in AD groups. Most of the common built-in AD groups will also contain non-user accounts, which can be awkward in drop-down lists within the application's user interface. The three settings you need to map to AD groups are TicketSubmittersRoleName, HelpDeskStaffRoleName, and AdministrativeRoleName.

Additionally, TicketDesk will need a valid AD user account name and password. This user account must have premissions to at least read values from AD. TicketDesk uses this AD account to perform additional queries against the AD database to obtain email addresses and display names for the AD user accounts. These settings are also configured in the appSettings section via the following settings: ActiveDirectoryDomain, ActiveDirectoryUser, and ActiveDirectoryUserPassword.

Other Settings:

Unlike previous versions of TicketDesk, TicketDesk 2.0 stores most application settings in the SQL database. These settings can be altered online in the admin section of the application. Each setting is described below:

  • AdUserPropertiesSqlCacheRefreshMinutes:

    Used only in AD environments; sets the amount of time the system will wait before updating the user properties in the SQL cache.

    These values are less critical than other values cached from AD (such as the list of group members), and so these properties can be refreshed less frequently. This value should be the same or higher than the "Refresh Security Cache Minutes" setting.

  • AllowSubmitterRoleToEditPriority

    If true submitters can set the priority field either during ticket creation, or in the ticket editor. Setting this to false reserves the priority field for help desk staff use only, though priorities will still be visible to submitters once set by the staff.

    In all cases, the priority is an optional field.

  • AllowSubmitterRoleToEditTags

    If true submitters can set tags during ticket creation and in the ticket editor. Setting this to false reserves the tags for help desk staff use only, though tags will still be visible to submitters once set by the staff.

    Tagging is encouraged as it assists in later ticket searches.

  • BlindCopyToEmailAddress

    An email address that should be blind copied (BCC) on all email notifications.

    Usually this is left blank, but can be useful as a diagnostic tool to test the notifications system.

  • CategoryList

    This is the list of possible selections for the Category dropdown list.

    Is is advised that your use generic categories. The recommended rule-of-thumb is that there should be one option that fits any possible ticket a user might create, and there should NOT be a value such as "other", "N/A", or "unknown". Keeping the values general in nature increases the odds that users will pick a meaningful value.

  • CleanupPendingAttachmentsAfterHours

    This setting controls how long the system will leave pending attachments in the database before purging them.

    When users first upload an attachment to a ticket, the attachment is in an uncommitted state. This gives the user time to finish writing comments, adding more files, filling in other fields, etc. If for some reason the user does not finish submitting/updating the ticket, these attachments remain on the server for a while (in case they come back).

  • CreateSqlMembershipRegistrationsAsSubmitters

    If true new users that register will automatically be added to the submitters role.

    If your system is exposed to the public, and you do NOT intend for the general public to be able to use your system, you should set this to false and require that an admin manually grant new users permissions.

  • EmailDeliveryTimerIntervalMinutes

    Determines how often TicketDesk will fire off the background process that examines the email notifications queue.

    Generally 1 - 5 minutes is appropriate for most environments, but you can change this if you want.

    You should not set this to a value lower than the "Email Notification Initial Delay Minutes" setting.

  • EmailMaxConsolidationWaitMinutes

    This setting controls the max amount of time that the system will continue waiting on additional changes to a ticket before going ahead and sending a notification email.

    If changes continue to occur to a ticket within the wait-period, the system will continue to wait before sending the email until either the changes slow down or the limit set by this setting is reached.

    The value here can contain a decimal. This value should be larger or the same as the "Email Notification Initial Delay Minutes" setting.

  • EmailMaxDeliveryAttempts

    How many times the system will attempt to deliver an email notifications before giving up.

  • EmailNotificationInitialDelayMinutes

    This controls the minimum amount of time after a notification for a ticket change has been queued before the system will send the notification.

    If additional changes to a ticket occurs before this time is reached, TicketDesk will consolidate the multiple notifications into a single message rather than spamming the user with multiple messages about each change. Each time a new change occurs, the amount of time to wait is incremented again by this same value.

    The value here can contain a decimal. The value should never be lower than the "Email Delivery Timer Interval Minutes" setting (they can be the same), and should also not be shorter than the "Email Max Consolidation Wait Minutes" setting (again, they can be the same).

  • EmailResendDelayMinutes

    This setting detemines how long TicketDesk will wait if there is an error when trying to send an email notification. Each time the notification failes, the wiat time will be the number of attempts times the value of this setting: Example, if the setting is 5 and message fails the third attempt, it will wait 15 minutes before trying again.

  • EmailServiceName

    Change this setting only if you have created a custom MEF module to handle email delivery! This should be the name of the MEF Export Contract Name of your custom email module. If you don't know what that means, then DO NOT TOUCH THIS SETTING!

  • EnableEmailNotifications

    This setting controls if the email notifications system is enabled or not.

    If set to false, the system will still queue up notificaitons, but it will never send them out to the users.

  • EnableOutlookFriendlyHtmlEmail

    Determines if TicketDesk will use the email template that is "friendly" to outlook email clients when generating the HTML body of an email.

    TicketDesk normally generates both an HTML and a Plain text body for emails. The HTML is rendered using real CSS that is supported by the vast majority of browsers and email clients. However, Microsoft's Outlook (up to 2010) still use Microsoft Word to redner emails, instead of Internet Explorer. Word's HTML capabilities are very limisted and are not W3C standards based.

    If the majority of your users use Outlook, you should enable this setting so they their emails render well in outlook.

  • FromEmailAddress

    The email address to use in the "TO" field of email notifications.

    Usually this is not a real person's email address, just a made up address at your organization.

  • FromEmailDisplayName

    The "friendly name" to use in the "TO" field of email notifications.

  • IsDemo

    This setting indicates that TicketDesk is running in "demo mode".

    Currently the only thing this affects are attachments. In Demo mode, the attachments system will not store the file contents that are uploaded (to keep people from using your demo site as an ad-hoc warze server).

  • KillAllProfilesOnStartup

    Setting this to "true" will cause the system to delete stored profile settings for ALL users.

    This is sometimes useful after upgrading TicketDesk to a new version to reset user's TicketCenter List Settings. The system will auto-regenerate a default set of profile values.

  • LuceneDirectory

    This is the relative path to the directory where TicketDesk should store the full-text indexes used by the search feature.

    You can use the text "ram" (case sensitive) to tell Lucene.net to use a purely in-memory index, but this is not recommended for your production sites. The asp.net user account will need read/write access to this folder location.

  • PriorityList

    This is the list of possible selections for the Priority dropdown list.

  • RefreshSecurityCacheMinutes

    Used only in AD environments (for right now); sets the amount of time the system will wait before a background process attempts to rebuild the SQL cached values retrieved from AD.

    The system will always rebuild the cache when it first starts up.

  • SiteRootUrlForEmail

    The root URL of the web site; will be used in email notifications to create the fully qualified link URLs. Without a valid setting, users clicking links in their notification email will not be directed to the TicketDesk site.

  • TicketTypesList

    This is the list of possible selections for the Ticket Type dropdown list. The type of ticket is usually the "kind" of issue the user is submitting.

    Is is advised that your use generic types. The recommended rule-of-thumb is that there should be one option that fits any possible ticket a user might create, and there should NOT be a value such as "other", "N/A", or "unknown". Keeping the values general in nature increases the odds that users will pick a meaningful value.

copy right @ test

Clone this wiki locally