Application Settings

Application settings are standard settings built into a class that can be overridden by a configuration file.

These settings can be maintained from Design > Configuration > Installed Modules > Business Rule > Settings.

The qbo.Application class includes the following application settings.


(Defaults to true) When set to true, permissions may be inherited in cascading calls. For example, saving an ImportForm may result in updating a SmartWorklistMember. 

If AllowInheritance is true, any users with permission to ImportFormUpdate will not need explicit permission to SmartWorklistMemberUpdate; the permission is assumed since the SmartWorklistMember/Update call is being made indirectly from ImportForm/Save.

If AllowInheritance is false, in the example above, users must have permissions to both ImportFormUpdate and SmartWorklistMemberUpdate to successfully complete an ImportForm/Save.

Note that this system-wide setting can be overridden on a statement-by-statement basis, so 'sensitive' statements can prevent inheritance and require the user have explicit permissions to execute the statement.


ApplicationRoot defines the virtual folder that the qbo3 installation live in. The default value is '/', indicating that the QBO3 installation lives in the root of the website. For websites with both QBO 2.0 and QBO 3 installed, this should be modified in web.config to be 'qbo3/'. This setting is used as follows:
  • Functions.BaseHref: returns BaseUrl (see below) + ApplicationRoot; this is used in all QBO 3 HTML pages to determine the root for all hyperlinks
  • XmlWebResolver: looks in a folder BasePath (see below) + ApplicationRoot for XSLT files
  • Login: prepends ApplicationRoot to the redirect locations for various login functions
  • SmartWorklistMember.ashx: prepends ApplicationRoot to the redirect locations for various login functions


(Defaults to true) When set to true, QBO 3 will attempt to self-install, repair or code-generate needed components. Examples include:
  • Database tables: if a table or some of it's column are missing, and the table creation script is built into the C# project's resource file, the table creation script will be run automatically on encountering an "Invalid object name" or "Invalid column name" error.
  • Entity view: the ObjectData method returns no SQL, this implies the Entity view does not include the subject table. AutoGenerateEntity() will automatically extend the Entity view to include the table.
  • XSLTs: if a request is made for a 'standard' XSLT and it does not exist, one will be code-generated automatically.
  • Javascript: if a request is made for a 'standard' javascript object and it has not been defined, a javascript file will automatically be created.
Note that with the database tables, the corresponding C# class file must have an override of qbo.Application.AbstractObject.Resource() method, and the project must contain the table script in a resource file name CreateTable{TableName}.


BasePath defines the physical path to the root of the website. The default value is '' (string.Empty). This setting exists for backward compatibility, and should not need to be set. It is used by the XmlWebResolver class to determine the root of the website. If BasePath is null or empty (which is the default), XmlWebResolver will assume the BasePath is Server.MapPath("/").

Unless you encounter an error stating, "The qbo.Application setting 'BasePath' must be not be empty", leave this setting empty.


BaseUrl defines the URL to the root of the website. The default value is '' (string.Empty). qbo.Application.Functions.BaseUrl will return this value if it is not empty, otherwise, the value will be determined from the HttpContext. Note that if you provide a setting for the value, you will lose flexibility as follows:
  • The site may not offer both HTTP and HTTPS (it will break AJAX requests between HTTP and HTTPS)
  • A multi-homed site ( and resolving to the same site) will break AJAX requests
Unless you have use cases demanding otherwise, leave this setting empty.


(Default is 1200 seconds.) The CommandTimeout is the default timeout for standard SQL queries. This can be overridden by DbStatement.Timeout for very long-running queries.


(Default is qbo.Default.) Configuration entries in QBO3 can be overridden by entries in a ConfigurationEntry table. This table is by default native to the QBO database, but it can be moved into a different database if need be.


(Default is null.) If a configuration filter is specified, data-driven configuration entries can be customized per filter. This allows 'branded' websites to have custom versions of standard configuration entries. For example, the Template FileObject may change from load-balanced web server to web server.


(Default is True.) When true, various configuration handlers will create a SqlDependency to the ConfigurationEntry table, so real-time changes in configuration propagate automatically to all instances using the database.


The SQL statement used to select rows from and monitor the ConfigurationEntry table.


Default value is DisplaySize=25&Batch=500&RecordStart=0.

Query string-formatted parameters made available to every DbStatement, if not otherwise specified.


Queue used during startup of the QueueService after a queue failure.


When qbo.Application.HttpHandler.cs class processes requests, it will include a header in the response indicating actual server execution time. This enables us to troubleshoot speed issues, isolating server-side execution time from network transmission or browser processing issues. The default value is 'X-Execution-Time'. Setting this value to '' (string.Empty) will cause the HttpHandler class to stop emitting the execution time header.


This boolean setting is used by SqlPattern.cs to determine if extranet clauses should be added to statements that are coded for them. The default value is true. This setting may be set to false if every user of the system should have universal access (that is, they should be able to see all rows of data for any tables they have permissions to view).


This string value determines whether brief or detailed error messages are send to the clients. When set to 'Brief', any errors processed by HttpHandler will result in just the innermost error message being emitted to the browser.  When set to 'Detail', any errors processed by HttpHandler will be routed through an XSLT error handler (see HttpErrorTransform below). The default value is 'Detail'.


This string value determines the XSLT to use when rendering error messages on the browser. The default value is 'Templates/Application/Error.Select.xslt', which suggests that the user contact support. For DEV or UAT systems, override this value with 'Templates/Application/Error.Detailed.xslt' for a full stack trace (and some humor).


This string value determines the HTTP header to look for to indicate when a site's traffic is being decrypted by a load balancer. The default value is 'X-Forwarded-Proto', which is a common non-standard response header used by Amazon's Elastic Load Balancers. For example:
  • browsing to routes to an Amazon load balancer
    • the request is forwarded to IIS as, with the header X-Forwarded-Proto: HTTPS
  • browsing to routes to an Amazon load balancer
    • the request is forwarded to IIS as, with the header X-Forwarded-Proto: HTTP
If QBO sees a request come over port 80 (http), but that request includes a header 'X-Forwarded-Proto: HTTPS', we can assume that original request to the load balancer was made on port 443 (https), and need to act accordingly.

This setting is currently used in two places:
  • qbo.Application.Functions.BaseUrl: when auto-calculating the BaseUrl from an HttpContext, the presence of this header will cause 'https' to be included in the BaseUrl, even if the request reaching IIS is over http.
  • qbo.SecurityWeb.Global.asax: if the site requires HTTPS and there is no indication that HTTPS has been used, the user is redirected to the same URL using https instead of http.
All sites should leave this setting alone, unless the site is using a custom load balancer with a different non-standard header.


This string value defaults to 'HTTPS'. See the LoadBalancerHeader description above for more detail.


When true, this boolean value is used by qbo.Application.Utilities.XsltArgumentList to include IIS server variables as standard parameters to XSLTs. This allows XSLTs to respond to variables such as HTTP_USER_AGENT, targeting mobile platforms and such. The default value is true. This should only be disabled if adding these parameters causes conflicts with other parameter names.


This string is a comma-separated list of the IIS server variables to include as XSLT parameters. The default value is 'LOGON_USER,HTTPS,PATH_INFO,SERVER_NAME,SERVER_PORT,HTTP_HOST,HTTP_USER_AGENT,QUERY_STRING'.


This integer determines how many minutes to cache XslCompiledTransforms for. The default value is 1440. Load XslCompliedTransforms can take several seconds for complex XSLTs (such as Valuation.Summary.xslt). Caching these transforms provides huge performance lift for production sites. However, caching can be annoying during iterative development. DEV environments should override this value as 0 in web.config, so developers do not need to clear the XSLT cache on every change.


This boolean value determines whether XslCompiledTransforms support Visual Studio debugging. The default value is false, and should remain false for UAT and PROD environments. Local development environments should set this to true in order to debug XSLTs in Visual Studio.