See User Guide: Login.

Note: Ozibug can be configured to support pluggable authentication modules, whereby user authentication is performed against an external source such as a user management system or LDAP directory. Refer to Pluggable Authentication for further details.

This section displays information about your Ozibug application and its installation. Note: this information is subject to your Java VM and Web Container installation & configuration and it may not always be present.

• Ozibug Information

  This section contains information about the actual application. Information such as the number of modules and bugs in each module, the type and number of users configured for the system, who is currently logged in, the base locale of your system and how long the application has been running.

• License Information

  This section shows the details of your Ozibug license such as who its licensed to, the expiry date and license type.

• System Information

  This section contains information about the operating system, Java VM and web container that the application is running under.

Database administration provides the ability to configure and test database connection details, as well as convert an Ozibug installation from the default of XML file backed storage to database backed storage.

Database connections can be either configured through JNDI or in Standalone mode. This determines whether database connections are to be obtained from a preconfigured datasource managed by your J2EE application server (eg., WebLogic, WebSphere, JBoss) or whether connections are to be managed by a connection pool within Ozibug when running in a servlet container without datasource management (eg., Tomcat, Jetty). Note: in both cases the database user must have the necessary privileges to allow table/index creation.

• JNDI
  • DataSource. This specifies the JNDI name of the database used to provide a connection pool to the database managed by your J2EE application server. The value will be dependent on the server configuration but an example is provided as a guideline.
• Standalone
  • Driver. This specifies the class name of the database driver used to provide JDBC connectivity to the database. The value will be dependent on the database but several examples of popular drivers are provided. The driver must be in the classpath, either provided to all contexts by the servlet container (eg., TOMCAT_HOME/common/lib/jdbcDriver.jar ), or just to the Ozibug context (eg., OZIBUG_HOME/WEB-INF/lib/jdbcDriver.jar ).
  • URL. This specifies the URL used to access your database. The value will be dependent on the database driver but several examples for popular drivers are provided as guidelines. The URL may contain the user and password.
  • User. The name of the user to connect to the database with. Need not be specified if the URL contains user and password.
  • Password. The name of the password to connect to the database with. Need not be specified if the URL contains user and password.
  • Maximum active connections. The maximum number of database connections available to the connection pool.

In order to confirm that the database configuration is correct and working a test connection can be made using the configuration as displayed. The configuration does not need to have been saved allowing tests to be made without overwriting a previous configuration. A new browser window will be displayed showing the results of the test connection as well as the data types and field sizes to be used.

Once a working database configuration has been established and saved the installation can be converted from XML file backed storage to database backed storage. The time taken to complete the conversion will be dependent on the volume of data in the existing XML repositories, but should be no more than a minute or two in most cases. A progress page showing the status of each repository (user, preference, reference, bug) through the conversion process (in progress, loaded, converted) will be automatically displayed every 10 seconds until the process is complete, no other user action is allowed while the conversion is underway. While extensive testing has been performed on the conversion process it is recommended that the converted data in the database is examined for correctness before making the system fully operational. Note: values longer than the maximum field sizes (see Data) will be truncated to fit.

As part of the conversion process the original XML repositories are archived in order to provide a backup in the event of failure. These XML archives can be restored if it is decided to abandon the database backed repositories. Note: this will only restore the data to the point at which the conversion took place, any data entered since the conversion will be lost. In order to perform a subsequent conversion the database should first be cleaned to remove all Ozibug data.

Support for multi-byte characters is dependent on the capabilities of the underlying database and may require additional configuration. It may also be necessary to increase the default field sizes (see Data) if more than one database character is required to store the multi-byte character, typically 3 database characters are required depending on the actual character set.

• MySQL 4.0
  • Append ?useUnicode=true&characterEncoding=UTF-8 to the database URL.
• Oracle 8i
  • The database must have been created with support for the required character set. Execute the sql statement "SELECT value FROM v$nls_parameters WHERE parameter = 'NLS_CHARACTERSET';" to determine which character set your database is configured for. US7ASCII does not provide any support, whereas UTF8 is probably the best option if not supporting a specific language.
• SQLServer 8.0
  • The Unicode character string types, NVARCHAR and NTEXT should be used for the Varchar and LongVarchar data type mappings. These values can be set by the appropriate properties in ozibug.properties.

• MySQL 4.0
  • By default MySQL is configured with a packet size of 1M. To save comments and file attachments larger than this size increase the parameter max_allowed_packet in the mysqld section of the MySQL configuration file to the size your wish to save, a maximum of 16M in MySQL 3.23 and 2G in MySQL 4.0.

• See User Guide: User Preferences for details of colours, number of bugs per page, date/time format, email notification and session timeout.
• Allow user maintenance by guests defines whether Guests can modify their own user details and preferences. Modification is not allowed by default.
• Create bugs as private defines whether bugs are created by default as private, which means that they cannot be viewed by Guests or other Customers. This can be changed on a per bug basis by the creator or updator of the bug. Bugs are created as publicly accessible bugs by default.
• Force customer bugs to be private defines whether bugs created by users in the Customer role are always created as private, ensuring that they cannot be viewed by Guests or other Customers. This preference overrides the Create bugs as private preference for users in the Customer role. The creator (ie., Customer) does not have the ability to change the privacy of a bug, however Developers and Managers do. Private customer bugs are not enforced by default.
• Default domain defines the template to use for the email address of a new user. It is only used to save on typing when adding new users ;) and is therefore not mandatory. There is no system default available unless one has been added to ozibug.properties on installation.
• Outgoing mail server defines the outgoing mail (SMTP) server to use when sending email notifications for changes to bugs. If it is not specified then notifications will not be sent. There is no system default available unless one has been added to ozibug.properties on installation.
• Contact email address defines the from address to use when sending email notifications for changes to bugs. It is recommended to set this to the email address or a real person, probably the administrator of Ozibug. If it is not specified then notifications will not be sent. There is no system default available unless one has been added to ozibug.properties on installation.
• Allow incoming mail defines whether bugs can be submitted from an external mail source. Incoming mail is not enabled by default. Refer to Incoming Mail Gateway Configuration for further details.
• Allow anonymous creation of bugs defines whether bugs can be submitted anonymously from an external mail source. Bugs created anonymously will have a creator of Anonymous and the Notifications field set to the email address of the submittor. If anonymous creation is not allowed, bugs submitted from external mail must be from an email address that maps to a single registered Ozibug user. Anonymous creation of bugs is not allowed by default.
• Incoming mail server, protocol, port and check interval define the connection details to use for the incoming mail gateway. Incoming mail server defaults to the value of the outgoing mail server, protocol defaults to POP3 with IMAP also available, port defaults to -1 which indicates that the default port for the protocol should be used (ie., 110 for POP3 or 143 for IMAP) and check interval defaults to 10 minutes.
• Debug log level defines the level of debug (or application) logging. The logging levels range from the highest (FATAL) to the lowest (DEBUG). The selected level indicates that only messages of that level and higher are captured. The ERROR or WARN level is probably suitable for most systems unless trying to capture logging information for submitting as part of a bug report on Ozibug.
• Debug and Audit log message formats use the notation defined by the Java logging library class PatternLayout in Jakarta log4j.
• Debug and Audit maximum log file size, scale and number of backup files combine to control the logging. Logging uses a rolling file behaviour which means that the log file is written to until it reaches the specified maximum size/scale, at which point it is moved to a backup file. The backup files are preserved until the maximum number is reached after which time the oldest will be overwritten.
• The headers and footer templates of certain pages can be replaced with custom html templates. This allows a corporate look and feel to be maintained, links to help pages placed on the footers, etc, etc. Note: Any custom template must preserve any <tag.n> references from the original template, even if they are only in comments. The custom templates must be installed into the OZIBUG_HOME/WEB-INF/templates directory.
• System name defines the name of the system displayed in such places as the title of each page, mail notifications, as well as on login and logout pages.
• Base system url defines the fully qualified base url of the Ozibug installation to be used in mail notifications, eg., http://www.mydomain.com/ozibug. This will allow the viewBugLink url to be correctly set when Ozibug is running in a proxy environment such as behind an Apache webserver. The url will be taken from the client's HTTP request by default.
• Header image, tooltip & url and body image allow the image at the left hand side of the top navigation panel and the large image at the left hand side of the center panel on a number of pages (eg., login, welcome, logout) to be replaced with custom images. This allows additional control of a corporate look and feel. As the Ozibug application will be active when the header image is seen its corresponding url will open in a new browser window. The custom images must be installed into the OZIBUG_HOME/images directory.

User details display a summary of all users in the system.

To create a new user chose the required values from the select boxes in the User Details section or type into the edit boxes as appropriate, and select the Submit button.

• See User Guide: User Details for details of password, name and email address.
• Id must be a unique value.
• Role defines the level of access the user will have to Ozibug.
  • Guest: read only access to modules. Restricted to those modules granted explicit access to and those modules that are unrestricted (ie., those with no users granted explicit access), and to those bugs that have not been created as private bugs (ie., only publicly accessible bugs).
  • Customer: as per Guest, plus create new bugs and update bugs they own. Also, update user preferences and user details.
  • Developer: as per Customer, plus view and update all bugs.
  • Manager: as per Developer, plus mass update on bug summary page.
  • Admin: update own and system preferences, all user details, reference data and view system log files.
• Active defines the status of a user. An inactive user cannot login, be assigned bugs or have any modules assigned to them.
• Unrestricted modules is a read only attribute that identifies those modules to which no users have been granted explicit access, and hence the user will have implicit access to.
• Available/Assigned Modules manages user access control at a module level. Available Modules displays those modules which are available to be explicitly assigned to the user, this excludes inactive modules and those already assigned. Assigned Modules displays those modules which are currently assigned to the user. Modules can be assigned/unassigned by selecting the required module and then using the left/right control buttons to move the selection between the two lists as appropriate. Note: multiple modules can be assigned/unassigned at one time, the key strokes to make a multiple selection are browser dependent.

To update an existing user, select the required user from the summary section. This will cause the details for the selected user to be displayed in the User Details section. As per new user chose the required values from the select boxes in the User Details section or type into the edit boxes as appropriate, and select the Submit button.

• All details except Id can be updated.
• Updating a user to be inactive will cause any current module assignments to be removed. Note: bugs assigned to the user will not be unassigned, this must be done manually.

To delete an existing user, select the required user from the summary section. This will cause the details for the selected user to be displayed in the User Details section. The Delete button can then be selected.

• Deletion of a user must be confirmed.
• A user that is currently logged in cannot be deleted (including yourself!), and the deletion attempt will fail.
• Deletion of a user that currently has assigned bugs can cause unpredictable behaviour. Until further notice it is advisable to make users inactive rather than deleting them.

Reference data provides the ability to customize the bug or defect tracking core of Ozibug. The select box contains a list of predefined core reference categories, custom categories and an option to create a new custom category. The core reference categories are Module, Priority and Status. These categories form the basis of any bug or defect tracking system system and thus cannot be deleted, however their display names can be changed to better suit terminology used in your environment.

To create a new custom category, select the New option from the select box. A new category page will be presented, chose the required values or type into the edit boxes as appropriate, and select the Update button. A new category will be created and the update category page displayed.

• Category is the display name used throughout the system. While not required to be unique, there is no reason to have multiple categories with the same name.
• Input type defines the format the user will be required to enter data for the category on the bug page.
  • Fixed list: input is chosen from a select box. Use when a bug must have a value entered for the category and it must be from a know set of values. The core reference categories are all of this type (and cannot be changed).
  • Free format: input is typed into an edit box. Use when a bug is not required to have a value entered for the category and there is no predefined values available.
  • Mixed: input may be chosen from a select box or typed into a edit box. Use when a bug is not required to have a value entered for the category and there is some predefined values available but other values are allowed.
• If any modules have been defined the used by modules option will be displayed. This defines the modules that the custom category is to be used for. For each selected module, the view, new and update bug pages for the module will show the custom category, and the module category page will show the custom category for the selected module.

To update an existing category, select the required category from the select box. The update category page will be displayed, for categories with an input type of fixed list or mixed the values section will also be displayed.

• All category details can be updated.
• Values can be added, changed or deleted for a category in the value section of the page.

  Create value

  To add a new value, chose the required values or type into the edit boxes of the value details section as appropriate, and select the Update button.

  • Value is the display name used throughout the system. While not required to be unique, there is no reason to have multiple values within a single category with the same name.
  • Sort order is a numeric value that defines the order in which the values are displayed in the select box on the new/update bug page, and the order in which bugs are sorted when the category is chosen as a component of a filter/sort on the bug summary page. If multiple values have the same sort order then they will be sorted on display name.
  • Active defines the status of a value. An inactive value will not appear in any select lists. Updating a module to be inactive will cause any current user assignments to be removed.
  • Status category only.
    • The special value of New cannot be deleted and is used as the initial value for creation of a new bug. This value can be identified in the value section by the presence of a (*) following its name.
  • Module and status categories only.
    • Read only defines an attribute to manage access control to modules and bugs. The read only attribute is false by default. A module that is designated as read only, or a bug with a status that is designated as read only can only by modified by Managers. Only Managers can update a bug to a read only status.
  • Module category only.
    • Bug id prefix and suffix define optional display attributes to use when displaying bug ids on all the bug pages. This allows customization of the format of bugs ids which are otherwise a simple incrementing numeric value.
    • If any custom categories have been defined the categories used option will be displayed. This defines the custom categories that the module is to use. The view, new and update bug pages for the module will show each selected custom category, and each corresponding custom category page will show the module.
    • Mail templates are used to customize the presentation and content of both the subject and body of email notifications. Simply select the templates that you want the email notifications to be based on. Basic templates are shipped with Ozibug, however custom templates can also be defined. Refer to Creating Mail Notification Templates for further details.
    • Incoming mail username and password define the connection details to use for the incoming mail gateway. Refer to Incoming Mail Gateway Configuration for further details.
    • Available/Assigned Users manages user access control to the module. Available Users displays those users which are available to be granted access to the module, this excludes inactive users and those already granted access. Assigned Users displays those users which have currently been granted access to the module. Users can be assigned/unassigned by selecting the required user and then using the left/right control buttons to move the selection between the two lists as appropriate. Note: multiple users can be assigned/unassigned at one time, the key strokes to make a multiple selection are browser dependent.
  • Priority and fixed list custom categories only.
    • Default defines the value that is to be used as the default for the category. If a default value has been defined it will be automatically selected in the corresponding select list for creation of a new bug, otherwise the first entry in the list will be used as the default selection. The default can be identified in the value section by the presence of a (*) following the value name.

  Update value

  To update an existing value, select the required value from the value summary section. This will cause the details for the selected value to be displayed in the value details section. Update as per create value.

  • All value details can be updated.

  Delete value

  To delete an existing value, select the required value as per update then select the Delete button.

  • Deletion of a value must be confirmed.
  • Deletion of a value that is currently used in a bug can cause unpredictable behaviour. Until further notice it is advisable to make values inactive rather than deleting them

To delete an existing category, select the required category from the select box. The category page will be displayed and the Delete button can then be selected.

• The core reference categories of Module, Priority and Status cannot be deleted.
• Deletion of a category must be confirmed.

The template files are used by Ozibug to create the html pages that are returned to a client. These templates form the view (MVC) that a client will see and as such can be modified by using a simple editor.

These files can only contain UTF-8 data. Additional Unicode characters can be added to the templates by using an ascii Unicode escape sequence \uXXXX where XXXX is the character code, for example \u00AB is the escape sequence for the single character '<<' and \u00BB is the escape sequence for the single character '>>'.

These files define messages in the form of Java properties that are language or locale dependent. When a message is required it is searched for according to the locale that the client specified when requesting the page.

These files can only contain ascii data. Additional Unicode characters can be added to the properties by using an ascii Unicode escape sequence. For example the property definition key = value might become key = valu\u00E9 for a non-english locale.

These are created by the logging subsystem which simply records each character on a byte by byte basis (carrying out no character set translations.)

This may look strange when editing or viewing the file directly as some of the multibyte characters may not be understood. Note: this is also the case when the logging data is output to the console rather than a file. The console device may not understand the multibyte characters and display what looks like garbage.

The logfiles will be displayed correctly when viewed through the Ozibug administration facility. See Audit Log and Debug Log.

The following maximum sizes apply to user enterable fields in Ozibug. These sizes can be changed by setting the appropriate properties in ozibug.properties.