Updating the web.config file

Changes to the web.config file can leave Enterprise Tester inoperable. We advise taking a backup of your web.config file and database prior to making changes.

• appSettings
• Changing Path Separator Value
• Changing the Indexes Folder Location
• Setting Automatic Refresh Lookups
• Storing Attachments in a File System

The web.config file contains information specific to your Enterprise Tester instance including your database type and location.  It also allows you to change default settings for some features or to enable or disable certain features. See the help topic appSettings for a full list and description of configurable settings.

The web.config is located in the web subdirectory of the application installation path, which defaults to c:\Program Files (x86)\Catch Limited\Enterprise Tester\Web\ folder.

• appSettings
• Server Key Generation
• Specifying the Date Format

appSettings

Changes to the web.config file can leave Enterprise Tester inoperable.  We advise taking a backup of your web.config file and database prior to making changes.

Some configuration settings in Enterprise Tester are not yet exposed in the User interface.  You can apply custom settings to some features in the appSettings section in the web.config file. In the appSettings section, you can add key/value pairs which can be used to control features of Enterprise Tester .

Supported Keys 

Setting a Key

To set a key:

• Open the web.config file in a text editor.
• Locate the section starting with <appSettings>
• Add the new entry, in the format off: <add key=”key-name” value=”value” />
• Save changes
• Refresh ET in browser, it should reload with the new settings applied.

Example – before adding new values:

<appSettings>
    <add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect"/>
</appSettings>

Example – after adding new values:

<appSettings>
    <add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect"/>
    <add key="search.index.disable" value="true"/>
    <add key="versionControl.changeTracking.disable" value="true"/>
</appSettings>

Addendum

FileUploadRestrictions 

 An additional change to the web.config file is required for the FileUploadRestrictions app setting so that meaningful error messaging is provided when disallowed files are attempted to be uploaded.

 httpErrors, existingResponse PassThrough should be added to the system.webServer section of the web.config file. 

<system.webServer>
    <httpErrors existingResponse="PassThrough" />
</system.webServer>

jira.refreshlookups.sampleIssuesForAdditionFields

When refreshing lookups in the JIRA (REST based plugin – JIRA 5.2 and above), if this option is set to true (the default) it will use both create screen meta and a technique of sampling issues of each issue type in a project and getting their edit screen metadata to compile a list of all available custom fields. This does require that the project contains issues to sample in the first place, and will still not detect fields that are neither on the edit or create screen ( e.g. transition screens).

Sampling may be slow for instances with very large numbers of issue types. If performance is slow, it may be necessary to turn this value to false. Note that this does mean any field that you wish to map for synchronization must appear on the create screens for those issue types/screen schemes.

If enabled, and the logging level is “INFO” or “DEBUG” then when doing a refresh lookups, you will see this in the log file:

GetEditCustomFields - starting to retrieve metadata for sample issues
 
... activity
 
GetEditCustomFields - completed retrieval of metadata for sample issues, elapsed time: 00:01:22.000

Which allows you to see how much time is being spent retrieving getting custom field information by sampling issues and getting their edit meta data.

Additionally, if the feature is set to “off” (false) and the log level is “DEBUG” then in the logs you will see this message:

GetEditCustomFields - skipping because sampleIssuesForAdditionalFields is set to false.

So you can be assured that sampling of issue edit metadata is not occurring.

site.root.url.scheme

Here are the values that the appSetting site.root.url.scheme can be configured as.

Changing Path Separator Value

By default, the “|” is reserved for use as a path separator for package, requirement and script paths in imports and exports and cannot be used in Requirement, Script or Use Case names. Should you need to use the “|” extensively as part of your naming convention, the path separator can be changed in Enterprise Testers web.config file as follows.

Open the Web.Config file (usually located in c:\Program Files (x86)\Catch Limited\Enterprise Tester\web\) and find the following section near the top of the file.

<appSettings>

<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect"/>

</appSettings>

Add a new line with the path separator of your choice after “value=” as shown in bold below. The following example will replace “|” as a path separator with the pipe character “~”.

<add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect"/>

<add key="PathService.PackagePathSeparator" value="~"/>

</appSettings>

Changing the Indexes Folder Location

By default, the location of the Indexes folder will default to the “Data” folder of your installation. The indexes folder can grow up to 1 gigabyte in size, so if you don’t have a lot of space free on your installation drive, or prefer to store data in a different location, you will need to update the web.config file to specify this location.

To change the location, locate the <appSettings>…</appSettings> section in the web.config file and add a new value “search.indexes.path” on the line after <appSettings> like so:

<appSettings>

   <add key="search.indexes.path" value="c:\savemy\indexes\" />

The “value” section of this entry needs to contain the absolute path of the folder where you want to have the indexes stored.

Setting Automatic Refresh Lookups

Enabling/Disabling Automatic Refresh Lookups at start up

By default, Enterprise Tester is automatically set to refresh lookups on startup of the application. In the web.config file, by default defecttracking.settings.populator.syncuncachedonstartup is set to ‘true’. This initially triggers a check for “uncached” projects. If “uncached” projects are found, a refresh lookups synchronisation is triggered at startup. To disable, set defecttracking.settings.populator.syncuncachedonstartup is set to ‘false’.

In the web.config file, locate the appSetting section and add the following key value pair to disable the automatic refesh lookups at start up.

<appSettings>

   <add key="defecttracking.settings.populator.syncuncachedonstartup" value="false" />   

</appSettings>

Enabling/Disabling Automatic Refresh Lookups when a new project link is created

By default, Enterprise Tester is automatically set to refresh lookups when a new project link is created under the Resources tab. In the web.config file, by default externaldata.createlink.autorefreshlookups is set to ‘true’. This triggers a refresh of all the cached custom/inbuilt field data when a project link is created. The refresh process will only work if the defect tracker is also enabled. To disable the automatic refresh lookup, change externaldata.createlink.autorefreshlookups to ‘false’.

In the web.config file, locate the appSetting section and add the following key value pair to disable the automatic refesh lookups at start up.

<appSettings>

   <add key="externaldata.createlink.autorefreshlookups" value="false" />   

</appSettings>

Storing Attachments in a File System

Before you Begin

By default Enterprise Tester stores attachments in the file system from V4.3 and above. Note that the original installation must be V4.3 (released September 2012) and above. In this case, you do not need to make any additional configurations to your system unless you would like to change the default file storage location or the maximum file size. See the Additional Configurations section below.

Where the original installation of ET was a version earlier than 4.3 then the default attachment storage is in the database and you will need to migrate the attachments from the database in addition to making the changes to the web.config file described below. Failure to migrate your attachments from the database after changing the attachment storage method will make those attachments in the database unavailable to users and will leave your system with attachments in both the database and the file system. The migration process described below will not migrate attachments from the database if new attachments are already being stored in the file system. In this case, please contact Catch Support for assistance.

Before running the AttachmentMigrator tool ensure you backup the following;

• Enterprise Tester Database
• Enterprise Tester file directory (where Enterprise Tester is installed i.e. (c:\Program Files\Catch Limited\Enterprise Tester\)

Changing Attachment Storage from Database to File System 

Enterprise Tester provides a mechanism to migrate between storing attachments in the file system or database for an existing instance of Enterprise. 

Migrating from In-database to the file system

To store attachments in a location other than /Data/Attachments, you will need to add the “attachment.storage.path” setting to the web.config file (ensure the attachment storage method remains the same).

1)      Download EnterpriseTester- xxx-BIN.zip

2)     Go to the properties of the zip file and select Unblock.
         Select Apply.

3)      Extract the EnterpriseTester-XX-BIN.zip file.

4)  Copy all the files from the unzipped BIN directory to Enterprise Tester
          i.e. c:\Program Files\Catch Limited\Enterprise Tester\web\bin

5)     Replace all the files in the destination folder

6)      Create a new folder inside the BIN directory called “MigrationRunner”.  
          NOTE: Do not put a space between Migration and Runner

7)     Copy all files from the Bin directory into the MigrationRunner directory

8)     Copy the web.config file from the Enterprise Tester\Web directory to the Enterprise Tester\Web \Bindirectory 

9)     Stop IIS

10)  Go to …\Catch Limited\Enterprise Tester\Web\bin\MigrationRunner directory and run the AttachmentMigrator.exe
        executable. The following message will appear :

As the message suggests, you should always backup both your database and web.config file prior to using this tool – as if it fails halfway through, it will leave your Enterprise Tester database in an inconsistent state.

11)  Type yes  and press <Enter> to proceed.

You will then see progress displayed on screen, and eventually the migration will complete.

12)  Copy the web.config file

From  – …\Catch Limited\Enterprise Tester\web\bin
         To –  …\Catch Limited\Enterprise Tester\web\.
        This has the change made to the attachment.storage.method so the attachments are now stored in the file system.

13)   Open the command line and run the following

    cd\Program Files (x86)\Catch Limited\Enterprise Tester\web\bin

14) Now run postinstall.exe ziprelease

15)  Restart IIS or the application pool, and your attachments will now be stored in the new location.

If you are migrating from file system to in-database storage, you will need to manually delete/archive the attachment files after the migration.

Additional Configurations

Changing the Attachment Storage Location

By default, attachments are stored in the folder ../Data/Attachments/ (so normally c:\Program Files(x86)\Catch Limited\Enterprise Tester\Data\Attachments)

If however you wish store attachments in another location (i.e. if you have a lot of attachments and wish to store them on a NAS disk) you can set the path by adding another entry with the key “attachment.storage.path”.

<appSettings>

   <add key="migration.providerName" value="Migrator.Providers.SqlServer.SqlServer2005Dialect" />   

   <add key="attachment.storage.method" value="FileSystemCas" />

   <add key="attachment.storage.path" value="f:\et-attachments\" />

</appSettings>

Setting Maximum File Sizes

To support the attachment of very large files change to the configuration of the application are also required. By default Enterprise Tester sets a limit of 64mb for requests. To support attaching larger files you will need to change this value.

In the web.config file, locate this section:

<system.web>

    <httpRuntime executionTimeout="18000" maxRequestLength="65535" />

The value “maxRequestLength” controls the maximum size of requests in kilobytes, changing this to value such as 1024000, will allow you to upload files up to 1gigabyte in size.