<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Mantis Bug Tracker Administration Guide</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"></HEAD
><BODY
CLASS="BOOK"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="BOOK"
><A
NAME="INDEX"
></A
><DIV
CLASS="TITLEPAGE"
><H1
CLASS="TITLE"
><A
NAME="INDEX"
>Mantis Bug Tracker Administration Guide</A
></H1
><P
CLASS="COPYRIGHT"
>Copyright &copy; 2010 The MantisBT Team</P
><DIV
><DIV
CLASS="ABSTRACT"
><P
></P
><A
NAME="AEN7"
></A
><P
>Reference manual for the Mantis Bug Tracker.</P
><P
>Build Date: 23 April 2010</P
><P
></P
></DIV
></DIV
><DIV
CLASS="LEGALNOTICE"
><P
></P
><A
NAME="LEGAL"
></A
><P
>        THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
	"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
	LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
	FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
	COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
	INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
	BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
	LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
	CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
	STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
	ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
	ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    </P
><P
></P
></DIV
><HR></DIV
><DIV
CLASS="TOC"
><DL
><DT
><B
>Table of Contents</B
></DT
><DT
>1. <A
HREF="#ADMIN.ABOUT"
>About MantisBT</A
></DT
><DD
><DL
><DT
>1.1. <A
HREF="#ADMIN.ABOUT.WHAT"
>What is MantisBT?</A
></DT
><DT
>1.2. <A
HREF="#ADMIN.ABOUT.WHO"
>Who should read this manual?</A
></DT
><DT
>1.3. <A
HREF="#ADMIN.ABOUT.LICENSE"
>License</A
></DT
><DT
>1.4. <A
HREF="#ADMIN.ABOUT.REQUIRMENTS"
>Minimum Requirements</A
></DT
><DT
>1.5. <A
HREF="#ADMIN.ABOUT.DOWNLOAD"
>How to get it?</A
></DT
><DT
>1.6. <A
HREF="#ADMIN.ABOUT.NAME"
>About the Name</A
></DT
><DT
>1.7. <A
HREF="#ADMIN.ABOUT.HISTORY"
>History</A
></DT
><DT
>1.8. <A
HREF="#ADMIN.ABOUT.SUPPORT"
>Support</A
></DT
><DT
>1.9. <A
HREF="#ADMIN.ABOUT.NEWS"
>MantisBT News</A
></DT
><DT
>1.10. <A
HREF="#ADMIN.ABOUT.VERSIONING"
>Versioning</A
></DT
></DL
></DD
><DT
>2. <A
HREF="#ADMIN.INSTALL"
>Installation</A
></DT
><DD
><DL
><DT
>2.1. <A
HREF="#ADMIN.INSTALL.SUMMARY"
>Summary</A
></DT
><DT
>2.2. <A
HREF="#ADMIN.INSTALL.NEW"
>New Installations</A
></DT
><DT
>2.3. <A
HREF="#ADMIN.INSTALL.REQUIREMENTS"
>Requirements</A
></DT
><DT
>2.4. <A
HREF="#ADMIN.INSTALL.BACKUPS"
>Backups</A
></DT
><DT
>2.5. <A
HREF="#ADMIN.INSTALL.UNINSTALL"
>Uninstall</A
></DT
></DL
></DD
><DT
>3. <A
HREF="#ADMIN.USER"
>User Management</A
></DT
><DD
><DL
><DT
>3.1. <A
HREF="#ADMIN.USER.CREATE"
>Creating User Accounts</A
></DT
><DT
>3.2. <A
HREF="#ADMIN.USER.ENABLE"
>Enabling/Disabling User Accounts</A
></DT
><DT
>3.3. <A
HREF="#ADMIN.USER.DELETE"
>Deleting User Accounts</A
></DT
><DT
>3.4. <A
HREF="#ADMIN.USER.SIGNUP"
>User Signup</A
></DT
><DT
>3.5. <A
HREF="#ADMIN.USER.PASSWORDRESET"
>Forgot Password and Reset Password</A
></DT
><DT
>3.6. <A
HREF="#ADMIN.USER.PASSWORDCHANGE"
>Changing Password</A
></DT
><DT
>3.7. <A
HREF="#ADMIN.USER.PRUNING"
>Pruning User Accounts</A
></DT
><DT
>3.8. <A
HREF="#ADMIN.USER.ACCESS"
>Authorization and Access Levels</A
></DT
><DT
>3.9. <A
HREF="#ADMIN.USER.AUTOCREATE"
>Auto Creation of Accounts on Login</A
></DT
><DT
>3.10. <A
HREF="#ADMIN.USER.PREFS"
>User Preferences</A
></DT
><DT
>3.11. <A
HREF="#ADMIN.USER.PROFILES"
>User Profiles</A
></DT
></DL
></DD
><DT
>4. <A
HREF="#ADMIN.LIFECYCLE"
>Issue Lifecycle and Workflow</A
></DT
><DD
><DL
><DT
>4.1. <A
HREF="#ADMIN.LIFECYCLE.CREATE"
>Issue Creation</A
></DT
><DT
>4.2. <A
HREF="#ADMIN.LIFECYCLE.STATUS"
>Issue Statuses</A
></DT
><DT
>4.3. <A
HREF="#ADMIN.LIFECYCLE.WORKFLOW"
>Workflow</A
></DT
><DD
><DL
><DT
>4.3.1. <A
HREF="#ADMIN.LIFECYCLE.WORKFLOW.TRANSITIONS"
>Workflow Transitions</A
></DT
><DT
>4.3.2. <A
HREF="#ADMIN.LIFECYCLE.WORKFLOW.THRESHOLDS"
>Workflow Thresholds</A
></DT
></DL
></DD
></DL
></DD
><DT
>5. <A
HREF="#ADMIN.CONFIG"
>Configuration</A
></DT
><DD
><DL
><DT
>5.1. <A
HREF="#ADMIN.CONFIG.DATABASE"
>Database</A
></DT
><DT
>5.2. <A
HREF="#ADMIN.CONFIG.PATH"
>Path</A
></DT
><DT
>5.3. <A
HREF="#ADMIN.CONFIG.WEBSERVER"
>Webserver</A
></DT
><DT
>5.4. <A
HREF="#ADMIN.CONFIG.SETTINGS"
>Configuration Settings</A
></DT
><DT
>5.5. <A
HREF="#ADMIN.CONFIG.SIGNUP"
>Signup and Lost Password</A
></DT
><DT
>5.6. <A
HREF="#ADMIN.CONFIG.EMAIL"
>Email</A
></DT
><DT
>5.7. <A
HREF="#ADMIN.CONFIG.VERSION"
>Version</A
></DT
><DT
>5.8. <A
HREF="#ADMIN.CONFIG.LANGUAGE"
>Language</A
></DT
><DT
>5.9. <A
HREF="#ADMIN.CONFIG.DISPLAY"
>Display</A
></DT
><DT
>5.10. <A
HREF="#ADMIN.CONFIG.TIME"
>Time</A
></DT
><DT
>5.11. <A
HREF="#ADMIN.CONFIG.DATE"
>Date</A
></DT
><DT
>5.12. <A
HREF="#ADMIN.CONFIG.NEWS"
>News</A
></DT
><DT
>5.13. <A
HREF="#ADMIN.CONFIG.DEFAULTS"
>Default Preferences</A
></DT
><DT
>5.14. <A
HREF="#ADMIN.CONFIG.SUMMARY"
>Summary</A
></DT
><DT
>5.15. <A
HREF="#ADMIN.CONFIG.BUGNOTE"
>Bugnote</A
></DT
><DT
>5.16. <A
HREF="#ADMIN.CONFIG.UPLOADS"
>File Upload</A
></DT
><DT
>5.17. <A
HREF="#ADMIN.CONFIG.HTML"
>HTML</A
></DT
><DT
>5.18. <A
HREF="#ADMIN.CONFIG.AUTH"
>Authentication</A
></DT
><DT
>5.19. <A
HREF="#ADMIN.CONFIG.STATUS"
>Status Settings</A
></DT
><DT
>5.20. <A
HREF="#ADMIN.CONFIG.FILTERS"
>Filters</A
></DT
><DT
>5.21. <A
HREF="#ADMIN.CONFIG.MISC"
>Misc</A
></DT
><DT
>5.22. <A
HREF="#ADMIN.CONFIG.COOKIES"
>Cookies</A
></DT
><DT
>5.23. <A
HREF="#ADMIN.CONFIG.TABLES"
>Database Tables</A
></DT
><DT
>5.24. <A
HREF="#ADMIN.CONFIG.SPEED"
>Speed Optimisation</A
></DT
><DT
>5.25. <A
HREF="#ADMIN.CONFIG.REMINDERS"
>Reminders</A
></DT
><DT
>5.26. <A
HREF="#ADMIN.CONFIG.BUGHISTORY"
>Bug History</A
></DT
><DT
>5.27. <A
HREF="#ADMIN.CONFIG.SPONSORSHIP"
>Sponsorship</A
></DT
><DT
>5.28. <A
HREF="#ADMIN.CONFIG.SOURCECONTROL"
>Source Control Integration</A
></DT
><DT
>5.29. <A
HREF="#ADMIN.CONFIG.CUSTOMFIELDS"
>Custom Fields</A
></DT
><DT
>5.30. <A
HREF="#ADMIN.CONFIG.MYVIEW"
>My View Settings</A
></DT
><DT
>5.31. <A
HREF="#ADMIN.CONFIG.RELATIONSHIP"
>Relationship Graphs</A
></DT
><DT
>5.32. <A
HREF="#ADMIN.CONFIG.SUBPROJECTS"
>Sub-Projects</A
></DT
><DT
>5.33. <A
HREF="#ADMIN.CONFIG.FIELDS"
>Field Visibility</A
></DT
><DT
>5.34. <A
HREF="#ADMIN.CONFIG.LOGGING"
>System Logging</A
></DT
></DL
></DD
><DT
>6. <A
HREF="#ADMIN.PAGES"
>Page descriptions</A
></DT
><DD
><DL
><DT
>6.1. <A
HREF="#ADMIN.PAGES.LOGIN"
>Login page</A
></DT
><DT
>6.2. <A
HREF="#ADMIN.PAGES.MAIN"
>Main page</A
></DT
><DT
>6.3. <A
HREF="#ADMIN.PAGES.FILTER"
>View Issues page</A
></DT
><DT
>6.4. <A
HREF="#ADMIN.PAGES.ISSUEVIEW"
>Issue View page</A
></DT
><DT
>6.5. <A
HREF="#ADMIN.PAGES.ISSUESTATUS"
>Issue Change Status page</A
></DT
><DT
>6.6. <A
HREF="#ADMIN.PAGES.ISSUEEDIT"
>Issue Edit page</A
></DT
><DT
>6.7. <A
HREF="#ADMIN.PAGES.ACCOUNT"
>My Account Page</A
></DT
><DD
><DL
><DT
>6.7.1. <A
HREF="#ADMIN.PAGES.ACCOUNT.PREFS"
>Preferences</A
></DT
><DT
>6.7.2. <A
HREF="#ADMIN.PAGES.ACCOUNT.PROFILES"
>Profiles</A
></DT
></DL
></DD
><DT
>6.8. <A
HREF="#ADMIN.PAGES.MANAGE"
>System Management Pages</A
></DT
><DD
><DL
><DT
>6.8.1. <A
HREF="#ADMIN.PAGES.MANAGE.USERS"
>Manage Users</A
></DT
><DT
>6.8.2. <A
HREF="#ADMIN.PAGES.MANAGE.PROJECTS"
>Manage Projects Page</A
></DT
><DT
>6.8.3. <A
HREF="#ADMIN.PAGES.MANAGE.CUSTOMFIELDS"
>Manage Custom Fields</A
></DT
><DT
>6.8.4. <A
HREF="#ADMIN.PAGES.MANAGE.PROFILES"
>Manage Global Profiles</A
></DT
><DT
>6.8.5. <A
HREF="#ADMIN.PAGES.MANAGE.CONFIG"
>Manage Configuration</A
></DT
></DL
></DD
><DT
>6.9. <A
HREF="#ADMIN.PAGES.MONITOR"
>Monitor Issue</A
></DT
><DT
>6.10. <A
HREF="#ADMIN.PAGES.REOPEN"
>Reopen Issue</A
></DT
><DT
>6.11. <A
HREF="#ADMIN.PAGES.DELETE"
>Delete Issue</A
></DT
><DT
>6.12. <A
HREF="#ADMIN.PAGES.CLOSE"
>Close Issue</A
></DT
><DT
>6.13. <A
HREF="#ADMIN.PAGES.ASSIGNTOME"
>Assign to Me</A
></DT
><DT
>6.14. <A
HREF="#ADMIN.PAGES.RESOLVE"
>Resolve Issue</A
></DT
><DT
>6.15. <A
HREF="#ADMIN.PAGES.NEWS"
>News Syndication</A
></DT
></DL
></DD
><DT
>7. <A
HREF="#ADMIN.CUSTOMIZE."
>Customizing MantisBT</A
></DT
><DD
><DL
><DT
>7.1. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFIELDS"
>Custom Fields</A
></DT
><DD
><DL
><DT
>7.1.1. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFIELDS.OVERVIEW"
>Overview</A
></DT
><DT
>7.1.2. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFIELDS.DEFINITIONS"
>Custom Field Definition</A
></DT
><DT
>7.1.3. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFIELDS.EDITING"
>Adding/Editing Custom Fields</A
></DT
><DT
>7.1.4. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFIELDS.LINKING"
>Linking/Unlinking/Ordering Existing Custom Fields in Projects</A
></DT
><DT
>7.1.5. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFIELDS.LOCALIZE"
>Localizing Custom Field Names</A
></DT
><DT
>7.1.6. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFIELDS.DEFAULTS"
>Dynamic default values</A
></DT
><DT
>7.1.7. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFIELDS.DYNAMIC"
>Dynamic values for Enumeration Custom Fields</A
></DT
></DL
></DD
><DT
>7.2. <A
HREF="#ADMIN.CUSTOMIZE.ENUMS"
>Enumerations</A
></DT
><DT
>7.3. <A
HREF="#ADMIN.CUSTOMIZE.EMAIL"
>Email Notifications</A
></DT
><DT
>7.4. <A
HREF="#ADMIN.CUSTOMIZE.STATUS"
>Customizing Status Values</A
></DT
><DT
>7.5. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFUNCS"
>Custom Functions</A
></DT
><DD
><DL
><DT
>7.5.1. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFUNCS.DEFINED"
>Defined Functions</A
></DT
><DT
>7.5.2. <A
HREF="#ADMIN.CUSTOMIZE.CUSTOMFUNCS.EXAMPLE"
>Example Custom Function</A
></DT
></DL
></DD
></DL
></DD
><DT
>8. <A
HREF="#ADMIN.AUTH"
>Authentication</A
></DT
><DD
><DL
><DT
>8.1. <A
HREF="#ADMIN.AUTH.STANDARD"
>Standard Authentication</A
></DT
><DT
>8.2. <A
HREF="#ADMIN.AUTH.HTTP"
>HTTP_AUTH</A
></DT
><DT
>8.3. <A
HREF="#ADMIN.AUTH.BASIC"
>BASIC_AUTH</A
></DT
><DT
>8.4. <A
HREF="#ADMIN.AUTH.LDAP"
>LDAP</A
></DT
><DT
>8.5. <A
HREF="#ADMIN.AUTH.MSAD"
>Microsoft Active Directory</A
></DT
></DL
></DD
><DT
>9. <A
HREF="#ADMIN.PROJECT"
>Project Management</A
></DT
><DD
><DL
><DT
>9.1. <A
HREF="#ADMIN.PROJECT.CHANGELOG"
>Change Log</A
></DT
><DT
>9.2. <A
HREF="#ADMIN.PROJECT.ROADMAP"
>Roadmap</A
></DT
><DT
>9.3. <A
HREF="#ADMIN.PROJECT.TIMETRACKING"
>Time Tracking</A
></DT
><DT
>9.4. <A
HREF="#ADMIN.PROJECT.GRAPHS"
>Graphs</A
></DT
><DT
>9.5. <A
HREF="#ADMIN.PROJECT.SUMMARY"
>Summary Page</A
></DT
></DL
></DD
><DT
>10. <A
HREF="#ADMIN.CONTRIBUTING"
>Contributing to MantisBT</A
></DT
><DD
><DL
><DT
>10.1. <A
HREF="#ADMIN.CONTRIBUTING.DEVELOP"
>Talent and Time</A
></DT
><DT
>10.2. <A
HREF="#ADMIN.CONTRIBUTING.SHARE"
>Recommend MantisBT to Others</A
></DT
><DT
>10.3. <A
HREF="#ADMIN.CONTRIBUTING.BLOG"
>Blog about MantisBT</A
></DT
><DT
>10.4. <A
HREF="#ADMIN.CONTRIBUTING.INTEGRATE"
>Integrate with MantisBT</A
></DT
><DT
>10.5. <A
HREF="#ADMIN.CONTRIBUTING.REGISTER"
>Registered in MantisBT Users Directory</A
></DT
><DT
>10.6. <A
HREF="#ADMIN.CONTRIBUTING.DONATE"
>Donate Money</A
></DT
><DT
>10.7. <A
HREF="#ADMIN.CONTRIBUTING.SPONSOR"
>Sponsor MantisBT</A
></DT
></DL
></DD
><DT
><A
HREF="#CREDITS"
>Colophon</A
></DT
></DL
></DIV
><DIV
CLASS="LOT"
><DL
CLASS="LOT"
><DT
><B
>List of Tables</B
></DT
><DT
>6-1. <A
HREF="#AEN2088"
>Issues</A
></DT
></DL
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.ABOUT"
></A
>Chapter 1. About MantisBT</H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.WHAT"
>1.1. What is MantisBT?</A
></H2
><P
>            MantisBT is a web based bug tracking system that was first made
            available to the public in November 2000.  Over time it has matured
            and gained a lot of popularity, and now it has become one of the most
            popular open source bug/issue tracking systems.  MantisBT is developed
            in PHP, with support to multiple database backends including MySQL,
            MS SQL, PostgreSQL and DB2.
        </P
><P
>            MantisBT, as a PHP script, can run on any operating system that
            is supported by PHP and has support for one of the DBMSes that
            are supported.  MantisBT is known to run fine on Windows, Linux,
            OS/2, Mac OS X, System i and a variety of Unix operating systems.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.WHO"
>1.2. Who should read this manual?</A
></H2
><P
>            This manual is targeted for the person responsible for evaluating,
            installing and maintaing MantisBT in a company. Typically we refer
            to this person as the MantisBT administrator.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.LICENSE"
>1.3. License</A
></H2
><P
>            MantisBT is released under the terms of
            <A
HREF="http://www.gnu.org/copyleft/gpl.html"
TARGET="_top"
>GNU General
            Public License (GPL)</A
>.  MantisBT is free to use and modify.
            It is free to redistribute as long as you abide by the distribution
            terms of the <A
HREF="http://www.gnu.org/copyleft/gpl.html"
TARGET="_top"
>GPL</A
>.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.REQUIRMENTS"
>1.4. Minimum Requirements</A
></H2
><P
>            MantisBT has modest software and hardware requirements.
            It requires a computer that is able to run the server software.  All of the required
            software is free for commercial or non-commercial use.  The
            server can be a shared public web server or a dedicated co-located box.
            The disk space required will depend on the size of the database,
            however, it is typically driven by the expected number and size of
            the attachments.
        </P
><P
></P
><UL
><LI
><P
>                    Operating System: MantisBT runs on Windows, MacOS, OS/2, Linux, Solaris, the
                    BSDs, and just about anything that supports the required server software.
                </P
></LI
><LI
><P
>                    Web Server: MantisBT is mainly tested with
                    <A
HREF="http://www.microsoft.com/iis"
TARGET="_top"
>Microsoft IIS</A
> and
                    <A
HREF="http://www.apache.org/"
TARGET="_top"
>Apache</A
>.  However,
                    it is expected to work with any decent web server software.
                </P
></LI
><LI
><P
>                    <A
HREF="http://www.php.net/"
TARGET="_top"
>PHP</A
>: The web server
                    must have PHP installed on it.  It can be installed as CGI or
                    whatever other integration technology that is supported by PHP
                    and the web server.  Required version is PHP 5.1.x or higher.
                    Recommended version is PHP 5.2.x.
                </P
></LI
><LI
><P
>                    Database: MantisBT requires a database to store its data.
                    The supported DBMSes include MySQL (4.1.x or higher), MS SQL,
                    PostgreSQL and DB2.
                </P
></LI
><LI
><P
>                    Browser: MantisBT aims to support most of the browsers in
                    the market.  The mainly supported ones are Internet Explorer and
                    Firefox.  However, browsers like Safari, Chrome and Opera should
                    also work fine although they are not used by most developers during
                    development and testing.
                </P
></LI
></UL
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.DOWNLOAD"
>1.5. How to get it?</A
></H2
><P
>            MantisBT is available in several Linux distributions
            including: Debian, Ubuntu, Fedora, Gentoo, Frugalware and others.
            Hence, if you are running Linux, start by checking if your distribution
            has a package for MantisBT.  If not, or if the package is
            not up-to-date with the latest MantisBT version, then you may want
            to download it directly from
            <A
HREF="http://www.mantisbt.org/download.php"
TARGET="_top"
>here</A
>.
        </P
><P
>            For Windows, Mac OS X and other operating systems, use the link provided
            above to download MantisBT.  The download is compressed in tar.gz
            or zip format.  Both formats can be unpacked using tools like
            <A
HREF="http://www.7-zip.org/"
TARGET="_top"
>7-Zip</A
> (in case of Windows).
        </P
><P
>            Note that at any point in time there are typically two "latest"
            MantisBT releases that are available for download.  The latest
            production release (stable), and the latest development release
            which can be an alpha or a release candidate.  It is not recommended
            to use development releases in production specially if it is still
            in the alpha stage unless the administrator is familiar with PHP
            and is able to troubleshoot and fix any issues that may arise.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.NAME"
>1.6. About the Name</A
></H2
><P
>            When initially seeking to name this project Ken ran into a
            problem every programmer encounters. What is a good name?  It has to
            be descriptive, unique, and not too verbose.  Additionally having
            multiple meanings would be a nice touch.  Quickly
            ruled out were php*Something* names which, incidentally, although
            popular, do not seem to be condoned by the PHP Group
            developers.  Drawing inspiration from Open Source projects like
            Apache, Mozilla, Gnome, and so forth resulted in two eventual
            choices: Dragonfly and Mantis. Dragonfly was already the name of a
            webmail package. So the name became Mantis.
        </P
><P
>            Praying Mantis are insects that feed primarily on other insects and bugs.
            They are extremely desirable in agriculture as they devour insects that feed
            on crops. They are also extremely elegant looking creatures.  So, we
            have a name that is fairly distinctive and descriptive in multiple
            ways.  The BT suffix stands for "Bug Tracker" and distinguishes
            this project from general usage of the word Mantis.  However, over
            time the project was typically referred to as Mantis.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.HISTORY"
>1.7. History</A
></H2
><P
>            Kenzaburo Ito and a friend originally created a bug tracker
            as an internal tool for their pet project. A search for good, free
            packages came up with nothing suitable so they wrote their own.
            After a rewrite and cleanup it was made available to the public via
            the GNU General Public License (GPL). The GPL was chosen partly
            because of his belief that development tools should be cheap or
            free. In 2002, Ken was joined by Jeroen Latour, Victor Boctor and
            Julian Fitzell to be the administrators and the core development
            team of MantisBT. This marks a new era in MantisBT lifetime where it is
            now a team project.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.SUPPORT"
>1.8. Support</A
></H2
><P
>            There are plenty of resources to help answer support queries.  Following
            are the main ones:
        </P
><P
></P
><UL
><LI
><P
>                    <A
HREF="http://www.mantisbt.org/forums/"
TARGET="_top"
>Forums</A
> - The
                    forums are one of the most popular destinations for getting
                    MantisBT support.  Start off by searching the forums for your
                    questions, if not found, then go ahead and submit a question.
                </P
></LI
><LI
><P
>                    <A
HREF="http://www.mantisbt.org/mailinglists.php"
TARGET="_top"
>Mailing lists</A
> -
                    Available mailing lists are "mantisbt-announce"
                    for announcements, "mantisbt-dev" for development issues,
                    mantisbt-lang for localization and "mantisbt-help" for
                    general help/support questions.  There are public archives for such
                    mailing lists.  Note that only members of the mailing lists can
                    post to them, hence, subscribe to the lists before you attempt
                    to email them.
                </P
></LI
><LI
><P
>                    <A
HREF="http://www.mantisbt.org/irc.php"
TARGET="_top"
>IRC</A
> -
                    The IRC channel is mainly used by developers to engage in
                    in-person discussion.  The recommended tool for IRC is XChat (for Linux),
                    XChat 2 (for Windows).  However, you can also use <A
HREF="http://webchat.freenode.net/"
TARGET="_top"
>Web Chat</A
> to connect to IRC
                    via your web browser.  This is also useful when your work
                    firewall blocks the IRC port (although there are other
                    workarounds involving tunneling to fix this issue).  Many people
                    prefer to use IRC to ask questions to the developers and other
                    users who are in the IRC channel.  The IRC channel logs are archived
                    and made available on the web. (TODO: add irc logs link)
                </P
></LI
><LI
><P
>                    <A
HREF="http://www.mantisbt.org"
TARGET="_top"
>Wiki</A
> - The
                    MantisBT Wiki has information related to "How To (recipes)",
                    FAQ, feature requirements, etc.
                </P
></LI
><LI
><P
>                    Search - A good way for locating an answer for your question
                    or finding more information about a topic is to search across
                    all MantisBT website and the Internet via
                    <A
HREF="http://www.google.com"
TARGET="_top"
>Google</A
> or
                    <A
HREF="http://www.bing.com"
TARGET="_top"
>Bing</A
>.
                </P
></LI
></UL
><P
>            It is important to note that support questions should not be sent
            directly to MantisBT developers or through the MantisBT contact us
            pages.  Use of "Contact Us" page or emailing the developer directly
            is available if you are after a paid support or consulting service.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.NEWS"
>1.9. MantisBT News</A
></H2
><P
>            There are several ways to keep up to date with MantisBT news.  These
            include:
        </P
><P
></P
><UL
><LI
><P
>                    mantisbt-announce mailing list is a very low traffic
                    list that is used for major announcements,  typically
                    announcements about releases.  All MantisBT users are
                    encouraged to subscribe to this mailing list.  The
                    average traffic should be no more than one to two posts
                    per month.
                </P
></LI
><LI
><P
>                    <A
HREF="http://www.mantisbt.org/blog/"
TARGET="_top"
>MantisBT Blog</A
>
                    is used to communicate announcements about new releases, topics
                    relating to MantisBT, etc.  Users are encouraged to subscribe to
                    the RSS feed to know when new posts are posted there.
                </P
></LI
><LI
><P
>                    <A
HREF="http://twitter.com/mantisbt"
TARGET="_top"
>Twitter</A
> is used to
                    notify users about up-to-date details about what is happening with MantisBT development.
                    For example, a Twitter update is automatically posted by the official bug tracker
                    whenever an issue is resolved.  Twitter users are encouraged to follow "mantisbt".
                </P
></LI
></UL
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.ABOUT.VERSIONING"
>1.10. Versioning</A
></H2
><P
>           The release numbering convention we use is major.minor.micro (eg. 1.2.0rc1).
       </P
><P
></P
><UL
><LI
><P
>                     Major - Indicates a very large change in the core package.
                     Rewrites or major milestones.
                </P
></LI
><LI
><P
>                    Minor - Significant amount of feature addition/modification.
                </P
></LI
><LI
><P
>                    Micro - Mostly bug fixes and maintenance releases.
                </P
></LI
><LI
><P
>                    Suffix - rc1 for first release candidate, a1 for alpha 1, etc.
                </P
></LI
></UL
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.INSTALL"
></A
>Chapter 2. Installation</H1
><P
>Following are the steps for a new MantisBT installation:</P
><P
></P
><UL
><LI
><P
>                <A
HREF="#ADMIN.ABOUT.DOWNLOAD"
>Download</A
>
                Mantis
            </P
></LI
><LI
><P
>                Go through MantisBT <A
HREF="#ADMIN.CONFIG"
>Configuration</A
>
                and set the database options + whatever options where you need to
                override the default values.
            </P
></LI
><LI
><P
>Test your configuration through the admin
                folder
            </P
></LI
><LI
><P
>Create a new administrator account and remove the
                standard user 'administrator'
            </P
></LI
></UL
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.INSTALL.SUMMARY"
>2.1. Summary</A
></H2
><P
></P
><OL
TYPE="1"
><LI
><P
>Tranfer files</P
></LI
><LI
><P
>Uncompress files</P
></LI
><LI
><P
>Generate database tables</P
></LI
><LI
><P
>Edit configuration file, if needed</P
></LI
><LI
><P
>PHP File extensions</P
></LI
><LI
><P
>Login</P
></LI
><LI
><P
>Add projects and users</P
></LI
></OL
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.INSTALL.NEW"
>2.2. New Installations</A
></H2
><P
></P
><OL
TYPE="1"
><LI
><P
>First, transfer the file to your webserver using whatever
                        method you likebest (ftp, scp, etc). You will need to telnet/ssh
                        into the server machine forthe next steps.
                    </P
></LI
><LI
><P
>Next, untar/gunzip it to the directory that you want.The
                        usual command is (1 step):
                        tar zxvf &lt;filename.tar.gz&gt;
                        OR (2 steps):
                        gunzip &lt;filename.tar.gz&gt; tar xvf &lt;filename.tar&gt;
                        Winzip, Stuffit, and other programs should also be able to
                        handledecompression of the archive.At this point you may want to
                        rename the directory to something simpler like 'mantisbt'. You will
                        use the mv command to rename a directory (Windows users substitute
                        the "ren" command or use explorer).
                        mv &lt;directoryname&gt; mantisbt
                    </P
></LI
><LI
><P
>Next we will create the necessary database tables and a
                        basic configurationfile.From your web server, access
                        http://yoursite/mantisbt/admin/install.php.  This page will walk through
                        the following steps:

                        <P
></P
><OL
TYPE="a"
><LI
><P
>check basic parameters for the web server</P
></LI
><LI
><P
>prompt for the database type and location, and a database
                                    user/passwordpair. For installion, an administrative user/password
                                    pair can also be provided. The operating user requires SELECT,
                                    INSERT, UPDATE, and DELETE privileges. For installation, INDEX,
                                    CREATE, ALTER, and DROP privileges arealso required.
                                </P
></LI
><LI
><P
>create the database and tables.
                                    WARNING: A DEFAULT ADMINISTRATOR level account is created. The
                                    account name and password are administrator / root.
                                    Use this when you first login to MantisBT. Immediately go to Manage
                                    and create at least one administrator level account. Immediately
                                    after that DISABLE or DELETE the administrator account. You can
                                    recreate it but you should delete the account to prevent the
                                    cookie_string from being used to trick the package. It would be
                                    even better to rename the account or delete it permanently.
                                    REMEMBER: After setting up the package, REMOVE the default
                                    administrator account.
                                </P
></LI
><LI
><P
>write a basic "config_inc.php file to define the
                                    database.
                                </P
></LI
><LI
><P
>perform some post installation checks on the
                                    system.
                                </P
></LI
></OL
>

                    </P
></LI
><LI
><P
>The next part involves configuring the installation to
                        work with yourspecific setup.Open the file in an editor and add
                        anyother values that are required. There aremany more that you can
                        use to customize your MantisBT installation.
                        See <A
HREF="#ADMIN.CONFIG"
>Configuration</A
> for
                        in depth explanations.The file will overwrite the default values
                        with those necessary for setup.You can load up admin/check.php to
                        see if you set things up correctly.
                        NOTE: check.php sometimes reports the value of
                        register_globalsincorrectly.
                        Create a page with this line in it: &lt;? phpinfo() ?&gt;, save
                        itwith a .php extension and load it up in your web browser. It
                        will, among amultitude of other things, have the correct value of
                        register_globals that youare using.
                    </P
></LI
><LI
><P
>MantisBT now uses only .php files.If your webserver is
                        configured for other extensions (.PHP3, .PHTML) then youwill have
                        to have the administrator add support for .PHP files. This shouldbe
                        a trivial modification.Documentation can be found at:
                        http://www.php.net/manual/en/installation.php
                    </P
></LI
><LI
><P
>Login to your bugtracker and go to the manage section.
                        Click on the projects link. You will need to ADD a new project. Then
                        EDIT the new project and remember to ADD at least one category.
                        Otherwise you won't be able to add any issues. That should be
                        it. You're off and running.
                    </P
></LI
></OL
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.INSTALL.REQUIREMENTS"
>2.3. Requirements</A
></H2
><P
>The following versions are required for proper operation:</P
><DIV
CLASS="INFORMALTABLE"
><P
></P
><A
NAME="AEN164"
></A
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><COL><COL><COL><TBODY
><TR
><TD
>Package</TD
><TD
>Minimum Version</TD
><TD
>Tested with</TD
></TR
><TR
><TD
>MySQL</TD
><TD
>4.1.x</TD
><TD
>5.0.x</TD
></TR
><TR
><TD
>PostgreSQL (experimental)</TD
><TD
>7.0</TD
><TD
>8.0</TD
></TR
><TR
><TD
>PHP</TD
><TD
>5.2.x</TD
><TD
>5.2.x</TD
></TR
><TR
><TD
>Web Server</TD
><TD
>&nbsp;</TD
><TD
>Apache 1.3.x, Apache 2.2.x, lighttpd 1.4.x, IIS 6.0</TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
><P
>MantisBT is designed in a way to work in as many environments as possible.
            Hence the required extensions are minimal and many of them are optional affecting
            only one feature.  The following PHP extensions are the ones used:</P
><P
></P
><UL
><LI
><P
>mysqli (or the extension for the DBMS being used) - mandatory.</P
></LI
><LI
><P
>Curl - if the Twitter integration feature is required.</P
></LI
><LI
><P
>GD - if the graphs feature is required.</P
></LI
><LI
><P
>fileinfo - Guesses the MIME type of attachments.
                    This extension is included by default from version 5.3.x
                    of PHP. For older versions of PHP you will need to install
                    the fileinfo PECL extension (this requires root access to
                    the server you're using). Without this extension, file
                    attachment previews and downloads may not work correctly as
                    MantisBT won't be able to send the Content-Type header to a
                    browser requesting an attachment.</P
></LI
></UL
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.INSTALL.BACKUPS"
>2.4. Backups</A
></H2
><P
>It is recommended to backup your MantisBT database on a
                regular basis. This is easy to accomplish using the mysqldump
                command:
                mysqldump -u&lt;username&gt; -p&lt;password&gt; &lt;database
                name&gt; &gt; &lt;output file&gt;
                To restore a backup you will need to have a clean database. Then
                run:
                mysql -u&lt;username&gt; -p&lt;password&gt; &lt;database name&gt;
                &lt; &lt;input file&gt;
                You can also perform both of these tasks using
                <A
HREF="http://www.phpmyadmin.net/"
TARGET="_top"
>phpMyAdmin</A
>
                A good idea is to make a backup script and run it regularly through
                cron or a task scheduler (for Windows see
                <A
HREF="http://www.wincron.com/"
TARGET="_top"
>WinCron</A
>
                ).
                Using the current date in the filename can prevent overwriting and
                make cataloguing easier.
                !!! Backups should always be performed before an upgrade !!!
                Make sure to backup MantisBT code (which includes your configs +
                possibly customization), issue attachments / project documents, and
                database contents.
            </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.INSTALL.UNINSTALL"
>2.5. Uninstall</A
></H2
><P
>                It is recommended that you make an backup in case you wish to use
                your data in the future. See the
                <A
HREF="#ADMIN.INSTALL.BACKUPS"
>Backups</A
>
                page for details.
                To uninstall MantisBT:
                <P
></P
><UL
><LI
><P
>Delete the MantisBT directory and all files and
                            subdirectories.
                        </P
></LI
><LI
><P
>Drop all MantisBT tables from the database, these can be
                            identified by the configured prefix for the installation. The
                            default prefix is 'mantis'.
                        </P
></LI
><LI
><P
>Remove any customizations or additions that you may have
                            made.
                        </P
></LI
></UL
>
                If you have the permissions to create/drop databases and you have a
                specific database for MantisBT that does not contain any other data,
                you can drop the whole database.
            </P
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.USER"
></A
>Chapter 3. User Management</H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.CREATE"
>3.1. Creating User Accounts</A
></H2
><P
>In MantisBT, there is no limit on the number of user
	accounts that can be created.  Typically, installations with thousands
	of users tend to have a limited number of users that have access level
	above REPORTER.</P
><P
>By default users with ADMINISTRATOR access level have access to create
	new user accounts.  The steps to do that are:

            <P
></P
><UL
><LI
><P
>Click "Manage" on Main Menu.</P
></LI
><LI
><P
>Click "Manage Users" (if not selected by default).</P
></LI
><LI
><P
>Click "Create New Account" button just below the alphabet
		key.</P
></LI
><LI
><P
>Enter user name, email address, global access level (more details about
		access levels later).  Other fields are optional.</P
></LI
><LI
><P
>Click "Create Users".</P
></LI
></UL
>
	</P
><P
>Creating a user triggers the following actions:
	<P
></P
><UL
><LI
><P
>Creating a user in the database.</P
></LI
><LI
><P
>If email notifications ($g_enable_email_notification) is
		set to ON, then the user will receive an email allowing them to
		activate their account and set their password.  Otherwise, the
		account will be created with a blank password.</P
></LI
><LI
><P
>If email notifications ($g_enable_email_notification) is
		set to ON, users with access level about
		$g_notify_new_user_created_threshold_min will get a
		notification that a user account has been created.  Information
		about the user like user name and email address are provided.
		The IP of the user that created the account is also
		included.</P
></LI
></UL
></P
><P
>When the 'Protected' flag is set on a user account, it indicates
	that the account is a shared account (e.g. demo account) and hence users
	logged using such account will not be allowed to change account
	preferences and profile information.</P
><P
>The anonymous user account specified with the $g_anonymous_account
	option will always be treated as a protected user account. When you are
	creating the anonymous user account, the 'Protected' flag is essentially
	ignored because the anonymous user is always treated as a protected
	user.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.ENABLE"
>3.2. Enabling/Disabling User Accounts</A
></H2
><P
>The recommended way of retiring user accounts is to disable them.
	Scenarios where this is useful is when a person leaves the team and it
	is necessary to retire their account.</P
><P
>Once an account is disabled the following will be enforced:
	<P
></P
><UL
><LI
><P
>All currently active sessions for the account will be
	       invalidated (i.e. automatically logged out).</P
></LI
><LI
><P
>It will no longer be possible login using this account.</P
></LI
><LI
><P
>No further email notifications will be sent to the account
	       once it is disabled.</P
></LI
><LI
><P
>The user account will not show anymore in lists like
	       "assign to", "send reminder to", etc.</P
></LI
></UL
></P
><P
>The disabling process is totally reversible.  Hence, the account
	can be re-enabled and all the account history will remain intact.  For
	example, the user will still have issues reported by them, assigned to
	them, monitored by them, etc.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.DELETE"
>3.3. Deleting User Accounts</A
></H2
><P
>Another way to retire user accounts is by deleting them.  This
	approach is only recommended for accounts that have not been active
	(i.e. haven't reported issues).  Once the account is deleted, any
	issues or actions associated with such account, will be associated with
	user123 (where 123 is the code of the account that was deleted).  Note
	that associated issues or actions are not deleted.</P
><P
>As far as the underlying database, after the deletion of a user,
	records with the user id as a foreign key will have a value that no
	longer exists in the users table.  Hence, any tools that operate
	directly on the database must take this into consideration.</P
><P
>By default administrators are the only users who can delete user
	accounts.  They can delete accounts by clicking Manage, Manage Users,
	locating the user to be deleted and opening it details page, then
	clicking on the "Delete User" button which deletes the user.</P
><P
>Note that "Deleting Users" is not a reversible process.  Hence, if
	it is required to re-add the user account, it is not possible to
	recreate the user account so that it gets the same ID and hence retains
	its history.  However, manually creating a record in the users table
	with the same id, can possibly do that.  However, this approach is not
	recommended or supported.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.SIGNUP"
>3.4. User Signup</A
></H2
><P
>For open source and freeware projects, it is very common to setup
	MantisBT so that users can signup for an account and get a REPORTER
	access by default (configurable by the
	$g_default_new_account_access_level configuration option).  The signup
	process can be enabled / disabled using the $g_allow_signup
	configuration option, which is enabled by default.</P
><P
>If email notifications ($g_enable_email_notification) is
        set to ON, users with access level about
	$g_notify_new_user_created_threshold_min will get a
	notification that a user account has been created.  Information
	about the user like user name, email address, IP address are included in
	the email notification.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.PASSWORDRESET"
>3.5. Forgot Password and Reset Password</A
></H2
><P
>It is pretty common for users to forget their password.  MantisBT
	provides two ways to handle such scenario: "Forgot Password" and "Reset
	Password".</P
><P
>"Forgot Password" is a self service scenario where users go to the
	login page, figure out they don't remember their password, and then click
	the "Lost your password?" link.  Users are then asked for their user
	name and email address.  If correct, then they are sent an email with a
	link which allows them to login to MantisBT and change their password.</P
><P
>"Reset Password" scenario is where a user reports to the
	administrator that they are not able to login into MantisBT anymore.
	This can be due to forgetting their password and possibly user name or
	email address that they used when signing up.  The administrator then
	goes to Manage, Manage Users, locates the user account and opens its
	details.  Under the user account details, there is a "Reset Password"
	button which the administrator can click to reset the password and
	trigger an email to the user to allow them to get into MantisBT and set
	their password.  In the case where email notifications are disabled,
	resetting password will set the password to an empty string.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.PASSWORDCHANGE"
>3.6. Changing Password</A
></H2
><P
>Users are able to change their own passwords (unless their account
	is "protected").  This can be done by clicking on "My Account", and then
	typing the new password in the "Password" and "Confirm Password" fields,
	then clicking "Update User".  Changing the password automatically
	invalidates all logged in sessions and hence the user will be required
	to re-login.  Invalidating existing sessions is very useful in the case
	where a user going onto a computer, logs into MantisBT and leaves the
	computer without logging out.  By changing the password from another
	computer, the session on the original computer automatically becomes
	invalidated.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.PRUNING"
>3.7. Pruning User Accounts</A
></H2
><P
>The pruning function allows deleting of user accounts for accounts
	that have been created more than a week ago, and they never logged in.
	This is particulary useful for users who signed up with an invalid email
	or with a typo in their email address address.</P
><P
>The account pruning can be done by administrators by going to
	"Manage", "Manage Users", and clicking the "Prune Accounts" button
	inside the "Never Logged In" box.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.ACCESS"
>3.8. Authorization and Access Levels</A
></H2
><P
>MantisBT uses access levels to define what a user can do.  Each
	user account has a global or default access level that is associated
	with it.  This access level is used as the access level for such users
	for all actions associated with public projects as well as actions that
	are not related to a specific project.  Users with global access level
	less than $g_private_project_threshold will not have access to private
	projects by default.</P
><P
>The default access levels shipped with MantisBT out of the box are
	VIEWER, REPORTER, UPDATER, DEVELOPER, MANAGER and ADMINISTRATOR.  Each
	features has several configuration options associated with it and
	identifies the required access level to do certain actions.  For
	example, viewing an issue, reporting an issue, updating an issue, adding
	a note, etc.</P
><P
>For example, in the case of reporting issues, the required access
	level is configurable using the $g_report_bug_threshold configuration
	option (which is defaulted to REPORTER).  So for a user to be able to
	report an issue against a public project, the user must have a
	project-specific or a global access level that is greater than or equal
	to REPORTER.  However, in the case of reporting an issue against a
	private project, the user must have project specific access level (that
	is explicitly granted against the project) that is higher than REPORTER
	or have a global access level that is higher than both
	$g_private_project_threshold and $g_report_bug_threshold.</P
><P
>Note that project specific access levels override the global
	access levels.  For example, a user may have REPORTER as the global
	access level, but have a MANAGER access level to a specific project.  Or
	a user may have MANAGER as the global access level by VIEWER access to
	a specific project.  Access levels can be overriden for both public and
	private projects.  However, overriding access level is not allowed for
	users with global access ADMINISTRATOR.</P
><P
>Each feature typically has multiple access control configuration
	options to defines what access level can do certain operations.  For
	example, adding a note may require REPORTER access level, updating a
	note my require DEVELOPER access level, unless the own was owned by the
	same user and in this case REPORTER access level.  Such threshold
	configuration options can be set to a single access level, which means
	users with such threshold and above are authorized to do such action.
	The other option is to specify an array of access level which indicates
	that users with the explicitly specific thresholds are allowed to do
	such actions.</P
><P
>It is also worth mentioning that the access levels are defined by
	the $g_access_levels_enum_string configuration option, and it is
	possible to customize such list.  The default value for the available
	access levels is '10:viewer, 25:reporter, 40:updater, 55:developer,
	70:manager, 90:administrator'.  The instructions about how to customize
	the list of access levels will be covered in the customization section.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.AUTOCREATE"
>3.9. Auto Creation of Accounts on Login</A
></H2
><P
>In some cases MantisBT is setup in a way, where it allows users
	that already exists in a directory or another application to be
	automatically authenticated and added to MantisBT.  For example, a
	company may setup their MantisBT installation in a way, where its staff
	members that are already registered in their LDAP directory, should be
	allowed to login into MantisBT with the same user name and password.
	Another example, is where MantisBT is integrated into some content
	management system, where it is desired to have a single registration and
	single sign-on experience.  In such scenarios, once a user logs in for
	the first time, a user account is automatically created for them,
	although the password verification is still done against LDAP or the
	main users repository.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.PREFS"
>3.10. User Preferences</A
></H2
><P
>Users can fine tune they way MantisBT interacts with them via
	modifying their user preferences.  User preferences can only be managed
	by users and are not available for the administrators to tweak.  The
	administrators can only tweak the default value for such preferences.
	However, once a user account is created, it is then the responsibility
	of the user to manage their own preferences.  The user preferences
	include the following:

	<P
></P
><UL
><LI
><P
>Default Project: A user can choose the default project
		that is selected when the user first logs in.  This can be a
		specific project or "All Projects".  For users that only work on
		one project, it would make sense to set such project as the
		default project (rather than "All Projects").  The active
		project is part of the filter applied on the issues listed in
		the "View Issues" page.  Also any newly reported issues will be
		associated with the active project.</P
></LI
><LI
><P
>Refresh Delay: The refresh delay is used to specify the
		number of seconds between auto-refreshes of the View Issues
		page.</P
></LI
><LI
><P
>Redirect Delay: The redirect delay is the number of
		seconds to wait after displaying flash messages like "Issue created
		successfully", and before the user gets redirected to the
		next page.</P
></LI
><LI
><P
>Notes Sort Order: The preference relating to how notes
		should be ordered on an issue is viewed or in email
		notifications.  The ascending order is where notes are ordered
		so that ordered notes appear before newer notes, the descending
		order is the reverse.</P
></LI
><LI
><P
>Email on New: If unticked, then email notifications
		relating to creation of a new issue would be disabled.  Note
		that the preference is only used to disabled notifications that
		as per the administrator's configuration, this user would have
		qualified to receive them.</P
></LI
><LI
><P
>Email on Change of Handler: TODO - is this preference
		used?</P
></LI
><LI
><P
>Email on Feedback: TODO - is this preference used?</P
></LI
><LI
><P
>Email on Resolved: TODO</P
></LI
><LI
><P
>Email on Closed: TODO</P
></LI
><LI
><P
>Email on Reopened: TODO</P
></LI
><LI
><P
>Email on Note Added: TODO</P
></LI
><LI
><P
>Email on Status Change: TODO</P
></LI
><LI
><P
>Email on Priority Change: TODO - is this preference used?</P
></LI
><LI
><P
>Email Notes Limit: This preference can be used to limit
		the number of issue notes to view or to be included in an email
		notifications.  Specifying N here means that the latest N
		notes will be included.  The value 0 causes all notes to be
		included.</P
></LI
><LI
><P
>Language: The preferred language of the user.  This
		language is used by the GUI and in email notifications.  Note
		that MantisBT uses UTF8 for encoding the data, and hence, the
		user can be interacting with MantisBT user interface in Chinese
		while logging issue data in German.</P
></LI
></UL
>
	 </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.USER.PROFILES"
>3.11. User Profiles</A
></H2
><P
>A user profile describes an environment that the user uses to run
	the software for which issues are being tracked.  The profile
	information include "Platform", "Operating System", "OS Version", and
	"Additional Description".  Each user has access to profiles that they
	create (can be multiple), in addition to global ones that are shared
	created by other users.  When reporting issues, users can elect to enter
	information like platform, operating system, version manually, or they
	can choose from the list of profiles that are already defined.</P
><P
>Global profiles are typically used by the administrator to define
	a set of standard profiles that are typically used by the MantisBT
	users.  This makes it easier for the users to use such profiles without
	having to define create them.  The access level required for users to be
	able to create global profiles is configured by the $g_manage_global_profile_threshold
	configuration option and it is defaulted to MANAGER.</P
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.LIFECYCLE"
></A
>Chapter 4. Issue Lifecycle and Workflow</H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="ADMIN.LIFECYCLE.CREATE"
>4.1. Issue Creation</A
></H2
><P
>The life cycle of an issue starts with its creation.  An issue can
	be created via one of the following channels:

	<P
></P
><UL
><LI
><P
>MantisBT Web Interface - This is where a user logs
	    into MantisBT and reports a new issue.</P
></LI
><LI
><P
>SOAP API - Where an application automatically
	    reports an issue into MantisBT using the SOAP API web services
	    interfaces.  For example, the nighlty build script can automatically
	    report an issue if the build fails.</P
></LI
><LI
><P
>Email - This is not supported out of the box, but
	    there are existing MantisBT patches that would listen to emails on
	    pre-configured email addresses and adds them to the MantisBT
	    database.</P
></LI
><LI
><P
>Others - There can be several other ways to report
	    issues.  For example, applications / scripts that directly injects
	    issues into MantisBT database (not recommended, except for one-off
	    migration scripts), or PHP scripts that use the core MantisBT API
	    to create new issues.</P
></LI
></UL
>
	</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.LIFECYCLE.STATUS"
>4.2. Issue Statuses</A
></H2
><P
>An important part of issue tracking is to classify issues as
	per their status.  Each team may decide to have a different set of
	categorization for the status of the issues, and hence, MantisBT
	provides the ability to customize the list of statuses.  MantisBT assumes
	that an issue can be in one of three stages: opened, resolved and
	closed.  Hence, the customized statuses list will be mapped to these
	three stages.  For example, MantisBT comes out of the box with the
	following statuses: new, feedback, acknowledged, confirmed, assigned,
	resolved and closed.  In this case "new" -&#62; "assigned" map to opened,
	"resolved" means resolved and "closed" means closed.</P
><P
>Following is the explanation of what the standard statuses that
	are shipped with MantisBT means.

	<P
></P
><UL
><LI
><P
>New - This is the landing status for new issues.  Issues
	    stay in this status until they are assigned, acknowledged, confirmed
	    or resolved.  The next status can be "acknowledged", "confirmed",
	    "assigned" or "resolved".</P
></LI
><LI
><P
>Acknowledged - This status is used by the development team
	    to reflect their agreement to the suggested feature request.  Or to
	    agree with what the reporter is suggesting in an issue report, although
	    they didn't yet attempt to reproduce what the reporter is referring
	    to.  The next status is typically "assigned" or "confirmed".</P
></LI
><LI
><P
>Confirmed - This status is typically used by the
	    development team to mention that they agree with what the reporter
	    is suggesting in the issue and that they have confirmed and
	    reproduced the issue.  The next status is typically
	    "assigned".</P
></LI
><LI
><P
>Assigned - This status is used to reflect that the issue
	    has been assigned to one of the team members and that such team
	    member is actively working on the issue.  The next status is
	    typically "resolved".</P
></LI
><LI
><P
>Resolved - This status is used to reflect that the issue
	    has been resolved.  An issue can be resolved with one of many
	    resolutions (customizable).  For example, an issue can be
	    resolved as "fixed", "duplicate", "won't fix", "no change required",
	    etc.  The next statuses are typically "closed" or in case of the
	    issue being re-opened, then it would be "feedback".</P
></LI
><LI
><P
>Closed - This status reflects that the issue is completely
	    closed and no further actions are required on it.  It also typically
	    hides the issue from the View Issues page.  Some teams use "closed"
	    to reflect sign-off by the reporter and others use it to reflect the
	    fact that the fix has been released to customers.</P
></LI
></UL
>
	</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.LIFECYCLE.WORKFLOW"
>4.3. Workflow</A
></H2
><P
>Now that we have covered how an issue gets created, and what are
	the different statuses during the life cycle of such issues, the next
	step is to define the workflow.  In other words, how issues move from
	one status to another and who has access to trigger such transitions.
	MantisBT provides the ability for teams to define their own custom
	workflow which works on top of their custom status.  The workflow
	dictates the valid transitions between statuses and the user access
	level required of the user who triggers such transition.</P
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.LIFECYCLE.WORKFLOW.TRANSITIONS"
>4.3.1. Workflow Transitions</A
></H3
><P
>This "Manage &gt; Manage Configuration &gt; Workflow
	    Transitions" page allows users with ADMINISTRATOR access level to do the
	    following tasks.

	    <P
></P
><UL
><LI
><P
>Define the valid next statuses for each status.</P
></LI
><LI
><P
>Define the default next status for each
		status.</P
></LI
><LI
><P
>Define the minimum access level required for a
		user to transition to each status.</P
></LI
><LI
><P
>Define the default status for newly created
		issues.</P
></LI
><LI
><P
>Define the status at which the issue is
		considered resolved.  Any issues with this status code greater
		than or equal to the specified status will be considered
		resolved.</P
></LI
><LI
><P
>Define the status which is assigned to issues
		that are re-opened.</P
></LI
><LI
><P
>Define the required access level to change the
		workflow.</P
></LI
></UL
>
	    </P
><P
>Note that the scope of the applied change is
	    dependent on the selected project.  If "All Projects" is selected,
	    then the configuration is to be used as the default for all
	    projects, unless overidden by a specific project.  To configure for
	    a specific project, switch to the project via the combobox at the
	    top right corner of the screen.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.LIFECYCLE.WORKFLOW.THRESHOLDS"
>4.3.2. Workflow Thresholds</A
></H3
><P
>This "Manage &gt; Manage Configuration &gt; Workflow
	    Thresholds" page allows users with ADMINISTRATOR access level to
	    define the thresholds required to do certain actions.  Following is
	    a list of such actions and what they mean:

	    <P
></P
><UL
><LI
><P
>Report an issue - The access levels that are
		allowed to report an issue.</P
></LI
><LI
><P
>Update an issue - The access levels that are
		allowed to update the header information of an issue.</P
></LI
><LI
><P
>Allow issue to be closed on resolved - The
		access levels that are allow to resolve and close an issue in
		one step.</P
></LI
><LI
><P
>Allow reporter to close issue - Indicates if
		reporters should be allowed to close issues reported by them.</P
></LI
><LI
><P
>Monitor an issue - The access levels required
		for a user to be able to monitor an issue.  Once a user monitors
		an issue, the user will be included in all future email
		notifications relating to changes in the issue.</P
></LI
><LI
><P
>Handle an issue - The access levels required for
		a user to be shown in the list of users that can handle an
		issue.</P
></LI
><LI
><P
>Assign an issue - The access levels required for
		a user to be able to change the handler (i.e. assign / unassign)
		an issue.</P
></LI
><LI
><P
>Move an issue - The access levels required for a
		user to be able to move an issue from one project to another.
		(TODO: are these access levels evaluated against source or
		destination project?).</P
></LI
><LI
><P
>Delete an issue - The access levels required for
		a user to be able to delete an issue.</P
></LI
><LI
><P
>Reopen an issue - The access levels required for
		a user to be able to re-open a resolved or closed issue.</P
></LI
><LI
><P
>Allow Reporter to re-open Issue - Whether the
		reporter of an issue can re-open a resolved or closed issue,
		independent of their access level.</P
></LI
><LI
><P
>Status to which a reopened issue is set - This
		is the status to which an issue is set after it is re-opened.</P
></LI
><LI
><P
>Resolution to which a reopen issue is set - The
		resolution to set on issues that are reopened.</P
></LI
><LI
><P
>Status where an issue is considered resolved -
		The status at which an issue is considered resolved.</P
></LI
><LI
><P
>Status where an issue becomes readonly - Issues
		with such status and above are considered read-only.  Read-only
		issues can only be modified by users with a configured access
		level.  Read-only applies to the issue header information as
		well as other issue related information like relationships,
		attachments, notes, etc.</P
></LI
><LI
><P
>Update readonly issues - The access levels
		required for a user to be able to modify a readonly issue.</P
></LI
><LI
><P
>Update issue status - The access levels required
		for a user to be able to modify the status of an issue.</P
></LI
><LI
><P
>View private issues - The access levels for a
		user to be able to view a private issue.</P
></LI
><LI
><P
>Set view status (public vs. private) - The
		access level for a user to be able to set whether an issue is
		private or public, when reporting the issue.  If the user
		reporting the issues doesn't have the required access, then the
		issue will be created with the default view state.</P
></LI
><LI
><P
>Update view status (public vs private) - The
		access level required for a user to be able to update the view
		status (i.e. public vs. private).</P
></LI
><LI
><P
>Show list of users monitoring issue - The access
		level required for a user to be able to view the list of users
		monitoring an issue.</P
></LI
><LI
><P
>Set status on assignment of handler - The access
		levels required for a user to be able to re-assign an issue when
		changing its status.</P
></LI
><LI
><P
>Status to set auto-assigned issues to - The
		status - This is the status that is set on issues that are auto
		assigned to users that are associated with the category that the
		issuer is reported under.</P
></LI
><LI
><P
>Limit reporter's access to their own issues -
		When set, reporters are only allow to view issues that they have
		reported.</P
></LI
><LI
><P
>Add notes - The access levels required for users
		to be able to add notes.</P
></LI
><LI
><P
>Update notes - The access levels required for
		users to be able to update issue notes.</P
></LI
><LI
><P
>Allow user to edit their own issue notes - A flag
		that indicates the ability for users to edit issue notes report by them.</P
></LI
><LI
><P
>Delete note - The access levels required for a
		user to delete a note that they may or may not have reported
		themselves.</P
></LI
><LI
><P
>View private notes - The access levels required
		for a user to be able to view private notes associated with an
		issue that they have access to view.</P
></LI
><LI
><P
>View Change Log - The access levels required for
		a user to be able to view the change log.</P
></LI
><LI
><P
>View Assigned To - The access levels required
		for a user to be able to know the handler of an issue that they
		have access to.</P
></LI
><LI
><P
>View Issue History - The access levels required
		for a user to be able to view the history of changes of an
		issue.</P
></LI
><LI
><P
>Send reminders - The access levels required for
		a user to be able to send reminders to other users relating to
		an issue that they have access to.</P
></LI
></UL
>
	    </P
></DIV
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.CONFIG"
></A
>Chapter 5. Configuration</H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.DATABASE"
>5.1. Database</A
></H2
><P
>The database settings must be set in order for the package
            to work properly. These settings should be provided to you by your
            system administrator or your hosting company.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_hostname</DT
><DD
><P
>Host name or connection string for Database server. The
                        default value is localhost. For MySql, this should be hostname or
                        hostname:port (e.g. localhost:3306).
                    </P
></DD
><DT
>$g_db_username</DT
><DD
><P
>User name to use for connecting to the database. The user
                        needs to have read/write access to the MantisBT database. The default
                        user name is "root".
                    </P
></DD
><DT
>$g_db_password</DT
><DD
><P
>Password for the specified user name. The default password
                        is empty.
                    </P
></DD
><DT
>$g_database_name</DT
><DD
><P
>Name of database that contains MantisBT tables.  The default name is 'bugtracker'.</P
></DD
><DT
>$g_db_schema</DT
><DD
><P
>The database schema (used in case of DB2), otherwise should be left blank.</P
></DD
><DT
>$g_db_type</DT
><DD
><P
>The supported database types include: 'mysql' or 'mysqli' for MySQL,
		    'pgsql' for PostgreSQL, 'mssql' for MS SQL Server, 'oci8' for Oracle,
		    and 'db2' for DB2.  It is important to make sure that the PHP extension
		    corresponding to the database type is enabled.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.PATH"
>5.2. Path</A
></H2
><P
>These path settings are important for proper linking within
            MantisBT. In most scenarios the default values should work fine, and
            you should not need to override them.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_path</DT
><DD
><P
>URL to your installation as seen from the web browser; this
                        is what you type into the URL field. Requires trailing '/'
                        character. eg. 'http://www.example.com/mantisbt/'.  In the following example
                        https protocol is used: eg. 'https://www.example.com/mantisbt/'.  MantisBT will default this to
                        the correct value. However, in some cases it might be necessary to
                        override the default.  This is typically needed when an installation can be
			accessed by multiple URLs (internal vs external).
                    </P
></DD
><DT
>$g_icon_path</DT
><DD
><P
>This is the URL to the icons (images) directory as seen from
                        the web browser. All MantisBT images/icons are loaded from this URL.
                        The default value for this URL is based on $g_path (i.e. '%path%images/').  Note that a trailing
                        '/' is required.
                    </P
></DD
><DT
>$g_short_path</DT
><DD
><P
>Short web path without the domain name.  This requires the trailing '/'.
                    </P
></DD
><DT
>$g_absolute_path</DT
><DD
><P
>This is the absolute file system path to the MantisBT installation, it is
                        defaulted to the directory where config_defaults_inc.php resides.
                        Requires trailing '/' character (eg. '/usr/apache/htdocs/mantisbt/').
                    </P
></DD
><DT
>$g_core_path</DT
><DD
><P
>This is the path to the core directory of your installation.
                        The default value is usually OK, unless you move the 'core'
                        directory out of your webroot. Requires trailing DIRECTORY_SEPARATOR.
                        character.
                    </P
></DD
><DT
>$g_class_path</DT
><DD
><P
>This is the path to the classes directory which is a sub-directory of core by default.
                        The default value is typically OK.  Requires trailing DIRECTORY_SEPARATOR.
                        character.
                    </P
></DD
><DT
>$g_manual_url</DT
><DD
><P
>This is the url to the MantisBT online manual.  Requires trailing '/' character.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.WEBSERVER"
>5.3. Webserver</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_use_iis</DT
><DD
><P
>Indicates the IIS (Microsoft Internet Information Server) is the web server on which MantisBT is hosted.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.SETTINGS"
>5.4. Configuration Settings</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_global_settings</DT
><DD
><P
>This option contains the list of regular expressions that are used to determine if it is allowed for a specific configuraiton option to be saved to or loaded from the database.  Configuration options that matches the regular expressions are considered global only and hence are only configurable via the config_inc.php file and defaulted by config_defaults_inc.php file.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.SIGNUP"
>5.5. Signup and Lost Password</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_allow_signup</DT
><DD
><P
>Allow users to signup for their own accounts. Default is ON.
                    </P
></DD
><DT
>$g_max_failed_login_count</DT
><DD
><P
>Maximum failing login attempts before the account is locked.
                        Once locked, it's required to reset the password (lost password).
                        Value resets to zero at each successfully login.  Default is OFF.
                    </P
></DD
><DT
>$g_notify_new_user_created_threshold_min</DT
><DD
><P
>The minimum global access level required to be notified when a new user registers via the "signup form".  To pick specific access levels that are not necessarily at the higher end of access levels, use an array of access levels.  Default is ADMINISTRATOR.
                    </P
></DD
><DT
>$g_send_reset_password</DT
><DD
><P
>When set to ON, MantisBT will email the users their new
                        passwords when their accounts are reset. If set to OFF, the
                        password will be reset to blank and no e-mail will be sent. Default
                        is ON.
                    </P
></DD
><DT
>$g_password_confirm_hash_magic_string</DT
><DD
><P
>TODO</P
></DD
><DT
>$g_signup_use_captcha</DT
><DD
><P
>TODO</P
></DD
><DT
>$g_system_font_folder</DT
><DD
><P
>TODO</P
></DD
><DT
>$g_font_per_captcha</DT
><DD
><P
>TODO</P
></DD
><DT
>$g_lost_password_feature</DT
><DD
><P
>TODO</P
></DD
><DT
>$g_max_lost_password_in_progress_count</DT
><DD
><P
>TODO</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.EMAIL"
>5.6. Email</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_administrator_email</DT
><DD
><P
>The administrator's e-mail address. This is mainly prompted
                        to the user in case of errors that might require the intervention
                        of the system administrator. For example, SQL
                        errors. sysadmin@example.com
                    </P
></DD
><DT
>$g_webmaster_email</DT
><DD
><P
>The webmaster's e-mail address. This address is displayed in
                        the bottom of all MantisBT
                        pages. webmaster@example.com
                    </P
></DD
><DT
>$g_from_email</DT
><DD
><P
>The email address to be used as the source of all emails
                        sent by MantisBT. noreply@example.com
                    </P
></DD
><DT
>$g_return_path_email</DT
><DD
><P
>Email address to receive bounced emails.</P
></DD
><DT
>$g_enable_email_notification</DT
><DD
><P
>Set to ON to enable email notifications, OFF to
                        disable them. Default is ON. Note that disabling
                        email notifications has no effect on emails generated
                        as part of the user signup process. When set to OFF,
                        the password reset feature is disabled. Additionally,
                        notifications of administrators updating accounts are
                        not sent to users.
                    </P
></DD
><DT
>$g_default_notify_flags</DT
><DD
><P
>Associated with each action a list of flags to control who
                        should be notified.The default will be used if the action is not
                        included in $g_notify_flags orif the flag is not included in the
                        specific action definition. The list of actions include: new,
                        assigned, resolved, bugnote, reopened, closed, deleted,
                        feedback.The default is:
                        $g_default_notify_flags = array('reporter' =&gt; ON, 'handler'
                        =&gt; ON, 'monitor' =&gt; ON, 'bugnotes' =&gt; ON, 'explicit' =&gt; ON,
                        'threshold_min' =&gt; NOBODY, 'threshold_max' =&gt; NOBODY);
                        threshold_min and threshold_max are used to send messages to all
                        members of the project whose status is greater than or equal to
                        "threshold_min" and less than or equal to "threshold_max". Sending
                        messages to everyone would set "threshold_min" to ANYBODY and
                        "threshold_max to "NOBODY". To send to all DEVELOPERS and above (as
                        0.17.5), use DEVELOPER and NOBODY respectively.
                    </P
></DD
><DT
>$g_notify_flags</DT
><DD
><P
>Defines the notification flags that are different from the
                        defaults that are defined in $g_default_notify_flags. The following
                        code overrides the default by disabling notifications to bugnote
                        authors and users monitoring the bug on submitting a new bug:
                        $g_notify_flags['new'] = array('bugnotes' =&gt; OFF, 'monitor'
                        =&gt; OFF);
                        Available actions include:
                        <P
></P
><UL
><LI
><P
>'new': a new bug has been added</P
></LI
><LI
><P
>'reopened': the bug has been reopened</P
></LI
><LI
><P
>'deleted': a bug has been deleted</P
></LI
><LI
><P
>'owner': the bug has been assigned a new owner</P
></LI
><LI
><P
>'bugnote': a bugnote has been added to a bug</P
></LI
><LI
><P
>'sponsor': the sponsorship for the bug has changed
                                    (added, deleted or updated)
                                </P
></LI
><LI
><P
>'relation': a relationship for the bug has changed
                                    (added, deleted or updated)
                                </P
></LI
><LI
><P
>'monitor': a user is added to the monitor list.
                                </P
></LI
></UL
>
                        In addition, an action can match the bug status in
                        $g_status_enum_string. Note that spaces in the string are replaced
                        with underscores ('_') in creating the action. Thus, using the
                        defaults, 'feedback' would be a valid action.
                    </P
></DD
><DT
>$g_email_receive_own</DT
><DD
><P
>This defines whether users should receive emails for their
                        own actions. This option is defaulted to OFF, hence, users do not
                        receive email notification for their own actions.
                        This can be a source for confusions for users upgrading from MantisBT
                        0.17.x versions, since in these versions users used to get notified
                        of their own actions.
                    </P
></DD
><DT
>$g_validate_email</DT
><DD
><P
>Set to OFF to disable email checking. Default is ON.</P
></DD
><DT
>$g_check_mx_record</DT
><DD
><P
>Set to OFF to disable email checking. Default is
                        OFF.
                    </P
></DD
><DT
>$g_allow_blank_email</DT
><DD
><P
>If ON, allows the user to omit an email address field.
                        If you allow users to create their own accounts, they must specify
                        an email at that point, no matter what the value of this option is.
                        Otherwise they wouldn't get their passwords.
                    </P
></DD
><DT
>$g_limit_email_domain</DT
><DD
><P
>Only allow and send email to addresses in the given domain.
                        This is useful as a security feature and it is also useful in cases
                        like Sourceforge where its servers are only limited to send emails
                        to SourceForge email addresses in order to avoid
                        spam. $g_limit_email_domain =
                        'users.sourceforge.net';
                    </P
></DD
><DT
>$g_show_user_email_threshold</DT
><DD
><P
>This specifies the access level that is needed to have user
                        names hyperlinked with mailto: links. The default value is NOBODY,
                        hence, even administrators won't have this feature enabled.
                    </P
></DD
><DT
>$g_mail_priority</DT
><DD
><P
>If use_x_priority is set to ON, what should the value be?
                        Urgent = 1, Not Urgent = 5, Disable = 0 . Default is 3
                        Some MTAs interpret X-Priority = 0 to mean 'Very Urgent'
                    </P
></DD
><DT
>$g_phpMailer_method</DT
><DD
><P
>Select the method to mail by: PHPMAILER_METHOD_MAIL for use of mail() function,
                    PHPMAILER_METHOD_SENDMAIL for sendmail (or postfix), PHPMAILER_METHOD_SMTP for SMTP.
                    Default is PHPMAILER_METHOD_MAIL.
                    </P
></DD
><DT
>$g_smtp_host</DT
><DD
><P
>This option specifies the SMTP server to submit messages to.  The SMTP
                    server (MTA) then takes on the responsibility of deliverying such messages
                    to their final destinations.  To use the local SMTP (if available) set this
                    to 'localhost', otherwise use the fully qualified domain name of the remote
                    SMTP server.  Default value is 'localhost'.
                    </P
></DD
><DT
>$g_smtp_port</DT
><DD
><P
>					The smtp port to use.  The typical SMTP ports are 25 and 587.  The port to use
					will depend on the SMTP server configuration and hence others may be used.
					The default is 25.
					</P
></DD
><DT
>$g_smtp_connection_mode</DT
><DD
><P
>This option allows you to specify the connection mode to the SMTP server.
                    Possible values are '', 'ssl', 'tls'.  The default value is ''.
                    </P
></DD
><DT
>$g_smtp_username</DT
><DD
><P
>This option allows the use of SMTP Authentication when using
                        a remote SMTP host with PHPMailer. If smtp_username is not '' then
                        the username and password will be used when logging in to the SMTP
                        server. Default is ''.
                    </P
></DD
><DT
>$g_smtp_password</DT
><DD
><P
>This is the password that is used in SMTP Authentication .
                        Default is ''.
                    </P
></DD
><DT
>$g_email_send_using_cronjob</DT
><DD
><P
>TODO</P
></DD
><DT
>$g_email_set_category</DT
><DD
><P
>Specify whether e-mails should be sent with the category set
                        or not. This is tested with Microsoft Outlook. More testing for
                        this feature + other formats will be added in the future. OFF,
                        EMAIL_CATEGORY_PROJECT_CATEGORY (format: [Project] Category).
                        Default is OFF.
                    </P
></DD
><DT
>$g_email_separator1</DT
><DD
><P
>Default is str_pad('', 70, '='); This means 70 equal
                        signs.
                    </P
></DD
><DT
>$g_email_separator2</DT
><DD
><P
>Default is str_pad('', 70, '-'); This means 70 minus
                        signs.
                    </P
></DD
><DT
>$g_email_padding_length</DT
><DD
><P
>Default is 28.</P
></DD
></DL
></DIV
><P
>MantisBT uses flags and a threshold system to generate emails on
            events. For each new event, email is sent to:
            <P
></P
><UL
><LI
><P
>the reporter, qualified by the notify flag 'reporter'
                        below
                    </P
></LI
><LI
><P
>the handler (or Assigned to), qualified by the notify
                        flag 'handler' below
                    </P
></LI
><LI
><P
>anyone monitoring the bug, qualified by the notify flag
                        'monitor' below
                    </P
></LI
><LI
><P
>anyone who has ever added a bugnote the bug, qualified by
                        the notify flag 'bugnotes' below
                    </P
></LI
><LI
><P
>anyone assigned to the project whose access level is
                        greater than or equal to the notify flag 'threshold_min' and less
                        than or equal to the notify flag 'threshold_max' below
                    </P
></LI
></UL
>
        </P
><P
>            From this list, those recipients who meet the following criteria
            are eliminated:
            <P
></P
><UL
><LI
><P
>the originator of the change, if $g_email_receive_own is
                        OFF
                    </P
></LI
><LI
><P
>the recipient either no longer exists, or is
                        disabled
                    </P
></LI
><LI
><P
>the recipient has turned their email_on_&lt;new
                        status&gt; preference OFF
                    </P
></LI
><LI
><P
>the recipient has no email address extered</P
></LI
></UL
>
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.VERSION"
>5.7. Version</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_show_version</DT
><DD
><P
>Whether to show the MantisBT version at the bottom of each
                        page or not. Default is ON.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.LANGUAGE"
>5.8. Language</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_default_language</DT
><DD
><P
>This is the language used by default in MantisBT.  This may be set
		    to 'auto' where MantisBT will try to determine the language from the browser.
                    </P
></DD
><DT
>$g_language_choices_arr</DT
><DD
><P
>This is to be set to an array of languages that are
                        available for users to choose from. The default value includes all
                        languages supported by MantisBT. The administrator can limit the
                        languages available for users to choose from by overriding this
                        value. For example, to support English, French and German include
                        the following code: array( 'english', 'french', 'german'
                        ); Of course, administrators can also add their own languages
                        by translating the strings and creating their own language files.
                        You are encouraged to share any translation work that you do with
                        the MantisBT team. This will ensure that the newly created language
                        file is maintained with future MantisBT releases.All language files
                        reside in the lang/ folder. They are all named according to the
                        following pattern: strings_&lt;language&gt;.txt.
                    </P
></DD
><DT
>$g_fallback_language</DT
><DD
><P
>This is the language used if MantisBT cannot determine the
                        language from the browser. It defaults to 'english'.As of 0.19.0,
                        this may be set to 'auto' where MantisBT will try to determine the
                        language from the browser.
                    </P
></DD
></DL
></DIV
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>If a string does not exist in the active language, the
                English string is used instead.
            </P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.DISPLAY"
>5.9. Display</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_window_title</DT
><DD
><P
>This is the browser window title (&lt;TITLE&gt;
                        tag).
                    </P
></DD
><DT
>$g_page_title</DT
><DD
><P
>This is a heading that is displayed in the viewing area of
                        the page.
                    </P
></DD
><DT
>$g_favicon_image</DT
><DD
><P
>Path to the favorites icon relative to MantisBT root folder (default 'images/favicon.ico').</P
></DD
><DT
>$g_logo_image</DT
><DD
><P
>Path to the logo image relative to MantisBT root folder (default 'images/mantis_logo.gif').</P
></DD
><DT
>$g_logo_url</DT
><DD
><P
>The default URL to be associated with the logo.  By default this is set to $g_default_home_page (which defaults to My View page). Clicking on the logo from any page in the bug tracker will navigate to the URL specified in this configuration option.</P
></DD
><DT
>$g_show_footer_menu</DT
><DD
><P
>Show the menu at the bottom of the page as well as at the
                        top. Default value is OFF.
                    </P
></DD
><DT
>$g_show_project_menu_bar</DT
><DD
><P
>This option specifies whether to add menu at the top of the
                        page which includes links to all the projects. The default value is
                        OFF.
                    </P
></DD
><DT
>$g_show_assigned_names</DT
><DD
><P
>When a bug is assigned then replace the word "assigned" with
                        the name of the developer in parenthesis. Default is ON.
                    </P
></DD
><DT
>$g_show_priority_text</DT
><DD
><P
>Specifies whether to show priority as text (ON) or icon
                        (OFF) in the view all bugs page. Default is OFF (icon).
                    </P
></DD
><DT
>$g_priority_significant_threshold</DT
><DD
><P
>Define the priority level at which a bug becomes
                        significant. Significant bugs are displayed with
                        emphasis. Set this value to -1 to disable the feature.
                        The default value is HIGH.
                    </P
></DD
><DT
>$g_severity_significant_threshold</DT
><DD
><P
>Define the severity level at which a bug becomes
                        significant. Significant bugs are displayed with
                        emphasis. Set this value to -1 to disable the feature.
                        The default value is MAJOR.
                    </P
></DD
><DT
>$g_view_issues_page_columns</DT
><DD
><P
>This configuration option is used to select the columns to be included in the View Issues page and in which order.  If one of the column is not accessible to the logged in user, or corresponds to a disabled feature, then it will be automatically removed from the list at runtime.  Hence, the same column list may show a different set of columns based on the logged in user, the currently selected project and enabled features (e.g. sponsorship_total is only shown if the sponsorship feature is enabled).</P
><P
>The supported columns are: selection, edit, id, project_id, reporter_id, handler_id, priority, reproducibility, projection, eta, resolution, fixed_in_version, view_state, os, os_build, build (for product build), platform, version, date_submitted, attachment, category, sponsorship_total, severity, status, last_updated, summary, bugnotes_count, description, steps_to_reproduce, additional_information.  As for custom fields they can be referenced by adding a 'custom_' to their name (e.g. xyz would be custom_xyz).</P
><P
>By default the following columns are selected: selection, edit, priority, id, sponsorship_total, bugnotes_count, attachment, category_id, severity, status, last_updated, summary.</P
></DD
><DT
>$g_print_issues_page_columns</DT
><DD
><P
>This configuration option is used to select the columns to be included in the Print Issues page and in which order.  See $g_view_issues_page_columns for more details about the supported fields.</P
><P
>By default the following columns are selected: selection, priority, id, sponsorship_total, bugnotes_count, attachment, category_id, severity, status, last_updated, summary</P
></DD
><DT
>$g_csv_columns</DT
><DD
><P
>This configuration option is used to select the columns to be included in the CSV export and in which order.  See $g_view_issues_page_columns for more details about the supported fields.</P
><P
>By default the following columns are selected: id, project_id, reporter_id, handler_id, priority, severity, reproducibility, version, build, projection, category_id, date_submitted, eta, os, os_build, platform, view_state, last_updated, summary, status, resolution, fixed_in_version, duplicate_id.</P
></DD
><DT
>$g_excel_columns</DT
><DD
><P
>This configuration option is used to select the columns to be included in the CSV export and in which order.  See $g_view_issues_page_columns for more details about the supported fields.</P
><P
>By default the following columns are selected: id, project_id, reporter_id, handler_id, priority, severity, reproducibility, version, build, projection, category_id, date_submitted, eta, os, os_build, platform, view_state, last_updated, summary, status, resolution, fixed_in_version, duplicate_id.</P
></DD
><DT
>$g_show_bug_project_links</DT
><DD
><P
>Show project links when in All Projects mode. Default is
                        ON.
                    </P
></DD
><DT
>$g_status_legend_position</DT
><DD
><P
>Specifies the position of the status colour legend, can be:
                        STATUS_LEGEND_POSITION_TOP or STATUS_LEGEND_POSITION_BOTTOM.
                        Default is STATUS_LEGEND_POSITION_BOTTOM.
                    </P
></DD
><DT
>$g_show_attachments_indicator</DT
><DD
><P
>In view all bug page, show a clip icon next to bugs that has
                        one or more attachments. The default value is OFF.
                        The reason why this is defaulted to OFF is that it adds an extra
                        query for every bug dispayed in the list.
                    </P
></DD
><DT
>$g_show_product_version</DT
><DD
><P
>This controls display of the product version in the
                        report, view, update and print issue pages. This flag also applies
						to other product version related fields like product build, fixed in version,
						and target version.  Valid values are ON, OFF, and AUTO.
                        ON for always displayed, AUTO for displayed when project has versions defined, and OFF for
 						always OFF.  The default value is AUTO.
                    </P
></DD
><DT
>$g_show_version_dates_threshold</DT
><DD
><P
>The access level threshold at which users will see
                        the date of release for product versions. Dates will
                        be shown next to the product version, target version
                        and fixed in version fields. Set this threshold to
                        NOBODY to disable the feature. Default value is NOBODY.
                    </P
></DD
><DT
>$g_show_realname</DT
><DD
><P
>This control will replace the user's userid with their
                        realname. If it is set to ON, and the real name fiels has been
                        populated, the replacement will occur. It defaults to OFF.
                    </P
></DD
><DT
>$g_show_avatar</DT
><DD
><P
>Show user avatar (default OFF); the current implementation is based on http://www.gravatar.com,
                    users will need to register there with the same email address used in
                    this MantisBT installation to have their avatar shown.</P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="90%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Upon registration or avatar change, it takes some time for the updated gravatar images to show on sites.</P
></TD
></TR
></TABLE
></DIV
></DD
><DT
>$g_show_avatar_threshold</DT
><DD
><P
>The threshold of users for which MantisBT should attempt to show the avatar (default DEVELOPER).  Note that the threshold is related to the user for whom the avatar is being shown, rather than the user who is currently logged in.</P
></DD
><DT
>$g_default_avatar</DT
><DD
><P
>The full URL to the image to be used when a user doesn't have an avatar account.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.TIME"
>5.10. Time</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_cookie_time_length</DT
><DD
><P
>Time for 'permanent' cookie to live in seconds. This is what
                        is used when a user selects "save login". Default is the equivalent
                        of 1 year (30000000).
                    </P
></DD
><DT
>$g_wait_time</DT
><DD
><P
>Time to delay between page redirects (in seconds). Users can
                        override this setting in their user preferences. Default is 2
                        seconds.
                    </P
></DD
><DT
>$g_content_expire</DT
><DD
><P
>Time to wait before document is stale (in minutes). This is
                        used in meta_inc.php. Default is 0 (expires right away).
                    </P
></DD
><DT
>$g_long_process_timeout</DT
><DD
><P
>This timeout is used by pages which does time consuming
                        operations like upgrading the database. The default value of 0
                        disables timeout. Note that this timeout is specified in
                        seconds.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.DATE"
>5.11. Date</A
></H2
><P
>These variables control how the date is displayed (default
            is 'US' formatting). Go to the
            <A
HREF="http://www.php.net/manual/en/function.date.php"
TARGET="_top"
>date()</A
>
            function in PHP online manual for detailed instructions on date
            formatting.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_short_date_format</DT
><DD
><P
>This format is used in the bug listing pages (eg: View
                        Bugs). Default is 'm-d-y'.
                    </P
></DD
><DT
>$g_normal_date_format</DT
><DD
><P
>This format is used in the view/update bug pages, bug notes,
                        manage section, and news section. Default is 'm-d-y H:i'.
                    </P
></DD
><DT
>$g_complete_date_format</DT
><DD
><P
>This format is used on the top of each page (current time)
                        and the emails that are sent out. Default is 'm-d-y H:i T'.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.NEWS"
>5.12. News</A
></H2
><P
>These options are used to control the query that selects the
            news entries to be displayed.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_news_enabled</DT
><DD
><P
>Indicates whether the news feature should be enabled or disabled.
                        The default is OFF.  The news feature is deprecated in favor of
                        being moved to a plugin.
                    </P
></DD
><DT
>$g_news_limit_method</DT
><DD
><P
>Limit the news entry that are displayed by number of entries
                        (BY_LIMIT) or by date (BY_DATE). The default is BY_LIMIT.
                    </P
></DD
><DT
>$g_news_view_limit</DT
><DD
><P
>The limit for the number of news entries to be displayed.
                        This option is only used if $g_news_limit_method is set to
                        BY_LIMIT.
                    </P
></DD
><DT
>$g_news_view_limit_days</DT
><DD
><P
>Specifies the number of dates after which the news are not
                        displayed. This option is only used if $g_news_limit_method is set
                        to BY_DATE.
                    </P
></DD
><DT
>$g_private_news_threshold</DT
><DD
><P
>Specifies the access level required to view private news.
                        The default is DEVELOPER.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.DEFAULTS"
>5.13. Default Preferences</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_default_new_account_access_level</DT
><DD
><P
>This is the default access level users are given when their
                        account is created by email. The default access level is REPORTER.
                        Look in constant_inc.php for other values.
                    </P
></DD
><DT
>$g_default_bug_view_status</DT
><DD
><P
>The default viewing status for the new bug (VS_PUBLIC or
                        VS_PRIVATE). The default is VS_PUBLIC.
                    </P
></DD
><DT
>$g_default_bugnote_view_status</DT
><DD
><P
>The default viewing status for the new bugnote (VS_PUBLIC or
                        VS_PRIVATE). The default is VS_PUBLIC.
                    </P
></DD
><DT
>$g_default_reminder_view_status</DT
><DD
><P
>The default viewing status for the new reminders (VS_PUBLIC
                        or VS_PRIVATE). The default is VS_PUBLIC.
                    </P
></DD
><DT
>$g_reminder_receive_threshold</DT
><DD
><P
>The minimum access level for a user to show up in the reminder user picker.
                    Note that this is the access level for the project for which the issue belongs.
                    The default is DEVELOPER.
                    </P
></DD
><DT
>$g_default_bug_resolution</DT
><DD
><P
>The resolution for a newly created issue. The default
                        is OPEN. Look in constant_inc.php for other values.
                    </P
></DD
><DT
>$g_default_bug_severity</DT
><DD
><P
>The severity for a newly created issue. The default is
                        MINOR. Look in constant_inc.php for other values.
                    </P
></DD
><DT
>$g_default_bug_priority</DT
><DD
><P
>The priority for a newly created issue. The default is
                        NORMAL. Look in constant_inc.php for other values.
                    </P
></DD
><DT
>$g_default_bug_reproducibility</DT
><DD
><P
>The reproducibility for a newly created issue. The
                        default is REPRODUCIBILITY_HAVENOTTRIED. Look in
                        constant_inc.php for other values.
                    </P
></DD
><DT
>$g_default_bug_projection</DT
><DD
><P
>The projection for a newly created issue. The default
                        is PROJECTION_NONE. Look in constant_inc.php for other
                        values.
                    </P
></DD
><DT
>$g_default_bug_eta</DT
><DD
><P
>The ETA for a newly created issue. The default is
                        ETA_NONE. Look in constant_inc.php for other values.
                    </P
></DD
><DT
>$g_default_limit_view</DT
><DD
><P
>Number of bugs to show in the View Bugs page. The default
                        value is 50.
                    </P
></DD
><DT
>$g_default_show_changed</DT
><DD
><P
>Highlight bugs that have changed during the last N hours.
                        The default value is 6.
                    </P
></DD
><DT
>$g_hide_status_default</DT
><DD
><P
>Controls which issues will be displayed in the View Issues
                        page. Default value is CLOSED, implying that all issues at "closed"
                        or higher state will not be shown.
                    </P
></DD
><DT
>$g_min_refresh_delay</DT
><DD
><P
>This is the delay between automatic refreshes of the View
                        Issues page in minutes. Make sure refresh delay in user preferences isn't too
                        short. If a users set their preferences to be lower then it is
                        bumped back up to this minimum value. The default value is 10
                        minutes.
                    </P
></DD
></DL
></DIV
><P
>            These settings are used as the default values for preferences for
            new users. Each user can override these settings through the user
            preferences form. Default language is set to default site language
            ($g_default_language).
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_default_refresh_delay</DT
><DD
><P
>Default page refresh delay (in minutes). This is for the bug
                        listing pages. Default value is 30 minutes.
                    </P
></DD
><DT
>$g_default_redirect_delay</DT
><DD
><P
>Default delay before a user is redirected to a page after
                        being prompted by a message (eg: operational successful). Default
                        value is 2 seconds.
                    </P
></DD
><DT
>$g_default_bugnote_order</DT
><DD
><P
>This controls the time order in which bug notes are
                        displayed. It can be either ASC (oldest first, the default) or DESC
                        (newest first).
                    </P
></DD
><DT
>$g_default_email_on_new$g_default_email_on_assigned$g_default_email_on_feedback$g_default_email_on_resolved$g_default_email_on_closed</DT
><DD
><P
>Default user preferences to enable receiving emails when a
                        bug is set to the corresponding status. This option only has an
                        effect if users have the required access level to receive such
                        emails. Default value is ON.
                    </P
></DD
><DT
>$g_default_email_on_reopened</DT
><DD
><P
>Default user preferences to enable receiving emails when
                        bugs are re-opened. Default value is ON.
                    </P
></DD
><DT
>$g_default_email_on_bugnote</DT
><DD
><P
>Default user preferences to enable receiving emails when
                        bugnotes are added to bugs. Default value is ON.
                    </P
></DD
><DT
>$g_default_email_on_status$g_default_email_on_priority</DT
><DD
><P
>Default user preferences to enable receiving emails when
                        status or priority is changed. Default is ON. Note that this option
                        is not implemented.
                    </P
></DD
><DT
>$g_default_email_on_new_minimum_severity$g_default_email_on_assigned_minimum_severity$g_default_email_on_feedback_minimum_severity$g_default_email_on_resolved_minimum_severity$g_default_email_on_closed_minimum_severity$g_default_email_on_reopened_minimum_severity$g_default_email_on_bugnote_minimum_severity</DT
><DD
><P
>Default user preferences to enable filtering based on issue
                        severity. These correspond to the email_on_&lt;status&gt; settings.
                        Default is 'any'.
                    </P
></DD
><DT
>$g_default_email_on_bugnote_minimum_severity</DT
><DD
><P
>Default user preference to enable filtering based on issue
                        severity. These corresponds to the email_on_bugnote setting.
                        Default is 'any'.
                    </P
></DD
><DT
>$g_default_email_on_status_minimum_severity$g_default_email_on_priority_minimum_severity</DT
><DD
><P
>Default user preferences to enable filtering based on issue
                        severity. These correspond to the email_on_status and
                        email_on_priority settings. Default is 'any'. Note that this option
                        is not yet implemented.
                    </P
></DD
></DL
></DIV
><P
>See also:
            <A
HREF="#ADMIN.CUSTOMIZE.EMAIL"
>Email Notifications</A
>
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.SUMMARY"
>5.14. Summary</A
></H2
><P
>These are the settings that are used to configuration
            options related to the Summary page. This page contains statistics
            about the bugs in MantisBT.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_reporter_summary_limit</DT
><DD
><P
>Limit how many reporters to show in the summary page. This
                        is useful when there are dozens or hundreds of reporters. The
                        default value is 10.
                    </P
></DD
><DT
>$g_date_partitions</DT
><DD
><P
>An array of date lengths to count bugs by (in days) for the
                        summary by date. The default is to count for 1, 2, 3, 7, 30, 60,
                        90, 180, and 365.
                    </P
></DD
><DT
>$g_summary_category_include_project</DT
><DD
><P
>Specifies whether category names should be preceeded by
                        project names (eg: [Project] Category) when the summary page is
                        viewed for all projects. This is useful in the case where category
                        names are common accross projects. The default is OFF.
                    </P
></DD
><DT
>$g_view_summary_threshold</DT
><DD
><P
>Specifies the access level required to view the summary
                        page. Default is VIEWER.
                    </P
></DD
><DT
>$g_severity_multipliers</DT
><DD
><P
>An array of multipliers which are used to determine
                        the effectiveness of reporters based on the severity of
                        bugs. Higher multipliers will result in an increase in
                        reporter effectiveness. The default multipliers are:
                        <PRE
CLASS="PROGRAMLISTING"
>$g_severity_multipliers = array ( FEATURE =&gt; 1,
                                                                          TRIVIAL =&gt; 2,
                                                                          TEXT =&gt; 3,
                                                                          TWEAK =&gt; 2,
                                                                          MINOR =&gt; 5,
                                                                          MAJOR =&gt; 8,
                                                                          CRASH =&gt; 8,
                                                                          BLOCK =&gt; 10 );
                        </PRE
>
                        The keys of the array are severity constants from
                        constant_inc.php or from custom_constants_inc.php if
                        you have custom severities defined. The values are
                        integers, typically in the range of 0 to 10. If you
                        would like for a severity to not count towards
                        effectiveness, set the value to 0 for that severity.
                    </P
></DD
><DT
>$g_resolution_multipliers</DT
><DD
><P
>An array of multipliers which are used to determine
                        the effectiveness of reporters based on the resolution
                        of bugs. Higher multipliers will result in a decrease
                        in reporter effectiveness. The only resolutions that
                        need to be defined here are those which match or exceed
                        $g_bug_resolution_not_fixed_threshold. The default
                        multipliers are:
                        <PRE
CLASS="PROGRAMLISTING"
>$g_resolution_multipliers = array( UNABLE_TO_DUPLICATE =&gt; 2,
                                                                           NOT_FIXABLE =&gt; 1,
                                                                           DUPLICATE =&gt; 3,
                                                                           NOT_A_BUG =&gt; 5,
                                                                           SUSPENDED =&gt; 1,
                                                                           WONT_FIX =&gt; 1 );
                        </PRE
>
                        The keys of the array are resolution constants from
                        constant_inc.php or from custom_constants_inc.php if
                        you have custom resolutions defined. Resolutions not
                        included here will be assumed to have a multiplier
                        value of 0. The values are integers, typically in the
                        range of 0 to 10. If you would like for a resolution to
                        not count towards effectiveness, set the value to 0 for
                        that resolution or remove it from the array completely.
                        Note that these resolution multipliers are stacked on
                        top of the severity multipliers. Therefore by default,
                        a user reporting many duplicate bugs at severity level
                        BLOCK will be far worse off than a user reporting many
                        duplicate bugs at severity level FEATURE.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.BUGNOTE"
>5.15. Bugnote</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_bugnote_order</DT
><DD
><P
>Order to use for sorting bugnotes by submit date. Possible
                        values include ASC for ascending and DESC for descending order. The
                        default value is ASC.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.UPLOADS"
>5.16. File Upload</A
></H2
><P
>MantisBT allows users to upload file attachements and
            associated them with bugs as well as projects. Bug attachments /
            project documents can be uploaded to the webserver, database, or an
            FTP server. When bugs are uploaded to the webserver they are
            uploaded to the path that is configured in the project
            properties.In case of problems getting the file upload feature to
            work, check the following resources:
            <A
HREF="http://www.php.net/manual/en/features.file-upload.php"
TARGET="_top"
>PHP
                Manual
            </A
>
            .
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_allow_file_upload</DT
><DD
><P
>Whether to allow/disallow uploading of attachments. Default
                        value is ON.
                    </P
></DD
><DT
>$g_file_upload_method</DT
><DD
><P
>Specify the location for uploading attachements. This can be
                        DISK, DATABASE, or FTP. In case of FTP, the files are saved on the
                        webserver (same as disk) as well as on the specified FTP server.
                        Default value is DATABASE.
                        In case of DISK / FTP upload methods you need to provide the
                        webserver with write access rights to the configured upload path
                        (configured in the project) and temporary upload path (used by
                        PHP).
                    </P
></DD
><DT
>$g_max_file_size</DT
><DD
><P
>The maximum file size to allow as an attachment.
                        You may also have to configure your php.ini file to increase the
                        execution time, memory limit, max post size, and max upload size.
                    </P
></DD
><DT
>$g_file_upload_ftp_server</DT
><DD
><P
>Address of the FTP server to write to (eg: ftp.example.com).
                        This option is only effective if upload method is FTP.
                    </P
></DD
><DT
>$g_file_upload_ftp_user</DT
><DD
><P
>FTP user name for account to be used in uploading files to
                        the FTP server. This account must have read/write access to the FTP
                        server. The default path for the account is used for uploading the
                        files.
                    </P
></DD
><DT
>$g_file_upload_ftp_pass</DT
><DD
><P
>Password to use when loggin in to the FTP server.</P
></DD
><DT
>$g_max_file_size</DT
><DD
><P
>Maximum file size that can be uploaded. Default value is
                        about 5MB.
                        The max file upload size is also affected by the value specified in
                        php.ini. The PHP value is usually defaulted to 2MB.
                    </P
></DD
><DT
>$g_allowed_files</DT
><DD
><P
>Files that are allowed. Separate items by commas. eg.
                        "zip,bmp,gif,jpg,txt" If $g_allowed_files is filled in NO other
                        file types will be allowed. If empty it will assume any files are
                        accepted that pass the $g_disallowed_files list.
                    </P
></DD
><DT
>$g_disallowed_files</DT
><DD
><P
>Files that are not allowed. Separate items by commas. eg.
                        "php,php3,phtml,html,class,java,exe,pl" $g_disallowed_files takes
                        precedence over $g_allowed_files.
                        It is recommended to disable all extensions that can be executed by
                        your server.
                    </P
></DD
><DT
>$g_document_files_prefix</DT
><DD
><P
>Prefix to give to uploaded files when saved to the upload
                        directory. This is used for documents that are attached to projects
                        in order to be able to differentiate them from files that are
                        attached to bugs. The name of the file has the following format
                        prefix-projectcode-filename. The default value is 'doc'.
                    </P
></DD
><DT
>$g_preview_attachments_inline_max_size</DT
><DD
><P
>This limit applies to previewing of image / text attachments.
                        If the attachment size is smaller than the specified value, the attachment
                        is previewed with the issue details.  The previewing can be disabled
                        by setting this configuration to 0.  The default value is 256 * 1024 (256KB).
                    </P
></DD
><DT
>$g_fileinfo_magic_db_file</DT
><DD
><P
>Specify the filename of the magic database file.
		        This is used by PHP 5.3.0 (or earlier versions with the
		        fileinfo PECL extension) to guess what the MIME type of a
		        file is. Usually it is safe to leave this setting as the
		        default (blank) as PHP is usually able to find this file
	                by itself.
		    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.HTML"
>5.17. HTML</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_html_tags</DT
><DD
><P
>This is the list of HTML tags that are allowed.Do NOT
                        include href or img tags here.Do NOT include tags that have
                        parameters (eg. )The HTML code is allowed to enter the database as
                        is. The $g_allow_href_tags does not have to be enabled to make URL
                        links. The package will automatically hyperlink properly formatted
                        URLs&nbsp;eg. http://blah.blah/ or
                        mailto://me@more.com/&nbsp;
                    </P
></DD
><DT
>$g_hr_size</DT
><DD
><P
>hr size.</P
></DD
><DT
>$g_hr_width</DT
><DD
><P
>hr width. Leave off the percentage (%) symbol.</P
></DD
><DT
>$g_bottom_include_page</DT
><DD
><P
>If this page eixsts it will be displayed at the bottom of
                        every page. It makes a good company branding include page.
                    </P
></DD
><DT
>$g_top_include_page</DT
><DD
><P
>If this page exists it will be displayed at the top of every
                        page. It makes a good company branding include page.
                    </P
></DD
><DT
>$g_css_include_file</DT
><DD
><P
>Set this to point to the CSS file of your choice.</P
></DD
><DT
>$g_css_rtl_include_file</DT
><DD
><P
>Set this to point to the RTL CSS file of your choice.</P
></DD
><DT
>$g_meta_include_file</DT
><DD
><P
>Set this to point to the META tag file of your
                        choice.
                    </P
></DD
><DT
>$g_main_menu_custom_options</DT
><DD
><P
>This option will add custom options to the main menu. It is
                        an array of arrays listing the caption, access level required, and
                        the link to be executed. For example:
                        $g_main_menu_custom_options = array( array( "My Link", MANAGER,
                        'my_link.php' ), array( "My Link2", ADMINISTRATOR, 'my_link2.php' )
                        );
                        Note that if the caption is found in custom_strings_inc.php, then
                        it will be replaced by the translated string. Options will only be
                        added to the menu if the current logged in user has the appropriate
                        access level.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.AUTH"
>5.18. Authentication</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_login_method</DT
><DD
><P
>                        <P
></P
><UL
><LI
><P
>MD5</P
></LI
><LI
><P
>LDAP</P
></LI
><LI
><P
>PLAIN</P
></LI
><LI
><P
>CRYPT</P
></LI
><LI
><P
>CRYPT_FULL_SALT</P
></LI
><LI
><P
>BASIC_AUTH</P
></LI
><LI
><P
>Some systems (mostly non-unix) do not have crypt support
                                    in PHP. MD5 will accomplish almost the same thing. PLAIN is plain
                                    text and there is no attempt to secure the password in the
                                    database. You will not be able to easily convert between encryption
                                    methods so this needs to be chosen at install time. MD5 is the default.
                                </P
></LI
></UL
>
                    </P
></DD
><DT
>$g_reauthentication</DT
><DD
><P
>TODO</P
></DD
><DT
>$g_reauthentication_expiry</DT
><DD
><P
>TODO</P
></DD
></DL
></DIV
><P
>LDAP authentication method parameters</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_ldap_server</DT
><DD
><P
>The ldap server (eg: ldaps://ldap.example.com).</P
></DD
><DT
>$g_ldap_port</DT
><DD
><P
>LDAP port (default 389).  If this doesn't work, try 389.</P
></DD
><DT
>$g_ldap_protocol_version</DT
><DD
><P
>                        The LDAP Protocol Version, if 0, then the protocol version is not set.  Default is 0.
                        For Active Directory use protocol version 3.
                    </P
></DD
><DT
>$g_ldap_follow_referrals</DT
><DD
><P
>                        Determines whether the LDAP library automatically follows referrals returned by LDAP servers or not.
                        This maps to LDAP_OPT_REFERRALS ldap library option.  For Active Directory, this should be set to OFF.
                        Default value is ON.
                    </P
></DD
><DT
>$g_ldap_root_dn</DT
><DD
><P
>The root distinguished name.  For example, "dc=example, dc=com".</P
></DD
><DT
>$g_ldap_organization</DT
><DD
><P
>The organization.  For example, "organizationname=*Example)".  Default value is ''.</P
></DD
><DT
>$g_ldap_uid_field</DT
><DD
><P
>The LDAP field for user id.  The default value is 'uid'.  For Active Directory, set to 'sAMAccountName'.</P
></DD
><DT
>$g_ldap_realname_field</DT
><DD
><P
>The LDAP field for real name (i.e. common name).  Default value is 'cn'.</P
></DD
><DT
>$g_use_ldap_email</DT
><DD
><P
>Use email address in LDAP rather than the email stored in
                        the database.
                    </P
></DD
><DT
>$g_use_ldap_realname</DT
><DD
><P
>Use realname in LDAP rather than the email stored in the database.
                        ON for LDAP, OFF for database.  The default value is OFF.
                    </P
></DD
><DT
>$g_ldap_bind_dn</DT
><DD
><P
>                        The distinguished of the user account to use for binding to the LDAP server.
                        For example, 'CN=ldap,OU=Administrators,DC=example,DC=com'.
                    </P
></DD
><DT
>$g_ldap_bind_passwd</DT
><DD
><P
>The password for the service account to be used for connecting to the LDAP server.</P
></DD
><DT
>$g_ldap_simulation_file_path</DT
><DD
><P
>                        For development purposes, this is a configuration option that allows replacing
                        the ldap communication with a comma separated text file.  The text file has a line
                        per user.  Each line includes: user name, user real name, email, password.
                        For production systems this option should be set to ''.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.STATUS"
>5.19. Status Settings</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_bug_submit_status</DT
><DD
><P
>Status to assign to the bug when submitted. Default value is
                        NEW_.
                    </P
></DD
><DT
>$g_bug_assigned_status</DT
><DD
><P
>Status to assign to the bug when assigned. Default value is
                        ASSIGNED.
                    </P
></DD
><DT
>$g_bug_reopen_status</DT
><DD
><P
>Status to assign to the bug when reopened. Default value is
                        FEEDBACK.
                    </P
></DD
><DT
>$g_bug_feedback_status</DT
><DD
><P
>                        Status to assign to the bug when feedback is required from the issue reporter.
                        Once the reporter adds a note the status moves back from feedback to $g_bug_assigned_status
                        or $g_bug_submit_status based on whether the bug assigned or not.
                    </P
></DD
><DT
>$g_reassign_on_feedback</DT
><DD
><P
>						When a note is added to a bug currently in $g_bug_feedback_status, and the note
						author is the bug's reporter, this option will automatically set the bug status
						to $g_bug_submit_status or $g_bug_assigned_status if the bug is assigned to a
						developer.  Defaults to enabled.
                    </P
></DD
><DT
>$g_bug_reopen_resolution</DT
><DD
><P
>Resolution to assign to the bug when reopened. Default value
                        is REOPENED.
                    </P
></DD
><DT
>$g_auto_set_status_to_assigned</DT
><DD
><P
>Automatically set status to $g_bug_assigned_status whenever
                        a bug is assigned to a person. Installations where assigned status
                        is to be used when the defect is in progress, rather than just put
                        in a person's queue should set it to OFF. Default is ON.
                    </P
></DD
><DT
>$g_bug_resolved_status_threshold</DT
><DD
><P
>Bug is resolved, ready to be closed or reopened. In some
                        custom installations a bug maybe considered as resolved when it is
                        moved to a custom (FIXED OR TESTED) status.
                    </P
></DD
><DT
>$g_bug_resolution_fixed_threshold</DT
><DD
><P
>Threshold resolution which denotes that a bug has
                        been resolved and successfully fixed by developers.
                        Resolutions above this threshold and below
                        $g_bug_resolution_not_fixed_threshold are considered
                        to be resolved successfully. Default value is FIXED.
                    </P
></DD
><DT
>$g_bug_resolution_not_fixed_threshold</DT
><DD
><P
>Threshold resolution which denotes that a bug has
                        been resolved without being successfully fixed by
                        developers. Resolutions above this threshold are
                        considered to be resolved in an unsuccessful way.
                        Default value is UNABLE_TO_DUPLICATE.
                    </P
></DD
><DT
>$g_bug_readonly_status_threshold $g_update_readonly_bug_threshold</DT
><DD
><P
>Bug becomes readonly if its status is &gt;=
                        $g_bug_readonly_status_threshold. The bug becomes read/write again
                        if re-opened and its status becomes less than this threshold. The
                        default is RESOLVED. Once the bug becomes readonly, a user with an
                        access level greater than or equal to
                        $g_update_readonly_bug_threshold can still edit the bug.
                    </P
></DD
><DT
>$g_status_enum_workflow</DT
><DD
><P
>'status_enum_workflow' defines the workflow, and reflects a
                        simple 2-dimensional matrix. For each existing status, you define
                        which statuses you can go to from that status, e.g. from NEW_ you
                        might list statuses '10:new,20:feedback,30:acknowledged' but not
                        higher ones.The default is no workflow, where all states are
                        accessible from any others.
                    </P
></DD
><DT
>$g_report_bug_threshold</DT
><DD
><P
>This is the access level required to open a bug. The default
                        is REPORTER.
                    </P
></DD
><DT
>$g_update_bug_threshold</DT
><DD
><P
>This is the access level generally required to update the
                        content of a bug. The default is UPDATER.
                    </P
></DD
><DT
>$g_handle_bug_threshold</DT
><DD
><P
>This is the access level generally required to be access
                        level needed to be listed in the assign to field. The default is
                        DEVELOPER. If a more restrictive setting can be determined from
                        $g_set_status_threshold, it will be used.
                    </P
></DD
><DT
>$g_update_bug_status_threshold $g_set_status_threshold</DT
><DD
><P
>These settings control the access level required to promote
                        a bug to a new status once the bug is
                        opened.$g_set_status_threshold is an array indexed by the status
                        value that allows a distinct setting for each status. It defaults
                        to blank.If the appropriate status is not defined above,
                        $g_update_bug_status_threshold is used instead. The default is
                        DEVELOPER.
                    </P
></DD
><DT
>$g_allow_close_immediately</DT
><DD
><P
>If set, bugs are allowed to be resolved and closed in one
                        action. The default is OFF.
                    </P
></DD
><DT
>$g_allow_reporter_close</DT
><DD
><P
>If set, the bug reporter is allowed to close their own bugs,
                        regardless of their access level. The default is OFF.
                    </P
></DD
><DT
>$g_allow_reporter_reopen</DT
><DD
><P
>If set, the bug reporter is allowed to reopen their own bugs
                        once resolved, regardless of their access level. This allows the
                        reporter to disagree with the resolution. The default is
                        ON.
                    </P
></DD
></DL
></DIV
><P
>See also:
            <A
HREF="#ADMIN.CUSTOMIZE.STATUS"
>Customizing Status Values</A
>
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.FILTERS"
>5.20. Filters</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_filter_by_custom_fields</DT
><DD
><P
>Show custom fields in the filter dialog and use these in
                        filtering. Defaults to ON.
                    </P
></DD
><DT
>$g_filter_custom_fields_per_row</DT
><DD
><P
>The number of custom fields to display per row. The default
                        is 7. The value should be greater than or equal to 7.
                    </P
></DD
><DT
>$g_view_filters = SIMPLE_DEFAULT;</DT
><DD
><P
>Controls the display of the filter pages. Possible values
                        are:
                        <P
></P
><UL
><LI
><P
>SIMPLE_ONLY - only simple view</P
></LI
><LI
><P
>ADVANCED_ONLY - only advanced view (allows multiple value
                                    selections)
                                </P
></LI
><LI
><P
>SIMPLE_DEFAULT - defaults to simple view, but shows a
                                    link for advanced
                                </P
></LI
><LI
><P
>ADVANCED_DEFAULT - defaults to advanced view, but shows a
                                    link for simple
                                </P
></LI
></UL
>
                    </P
></DD
><DT
>$g_dhtml_filters = OFF;</DT
><DD
><P
>Controls the use of DHTML filters that will display the
                        filter in view page using DHTML and javascript. Default is OFF.
                        This requires $g_use_javascript to ne set to ON. This may not work
                        in all browsers as it requires xmlhttprequest
                        functionality.
                    </P
></DD
><DT
>$g_create_permalink_threshold</DT
><DD
><P
>The threshold required for users to be able to create permalinks (default DEVELOPER).  To turn this feature off use NOBODY.</P
></DD
><DT
>$g_create_short_url</DT
><DD
><P
>The service to use to create a short URL.  The %s will be replaced by the long URL.  By default http://www.tinyurl service is used to shorten URLs.</P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.MISC"
>5.21. Misc</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_user_login_valid_regex</DT
><DD
><P
>                        The regular expression to use when validating new user login names.
                        The default regular expression allows a-z, A-Z, 0-9, +, -, dot, space and
                        underscore.  If you change this, you may want to update the
                        ERROR_USER_NAME_INVALID string in the language files to explain
                        the rules you are using on your site.
                    </P
><P
>                        See <A
HREF="http://en.wikipedia.org/wiki/Regular_Expression"
TARGET="_top"
>Wikipedia</A
> for more
                        details about regular expressions.  For testing regular expressions, use
                        <A
HREF="http://rubular.com/"
TARGET="_top"
>Rubular</A
>.
                    </P
></DD
><DT
>$g_monitor_bug_threshold</DT
><DD
><P
>Access level needed to monitor bugs. The default
                        value is REPORTER.
                    </P
></DD
><DT
>$g_monitor_add_others_bug_threshold</DT
><DD
><P
>Access level needed to add other users to the list of
                        users monitoring a bug. The default value is DEVELOPER.
                    </P
></DD
><DT
>$g_monitor_delete_others_bug_threshold</DT
><DD
><P
>Access level needed to delete other users from the
                        list of users monitoring a bug. The default value is
                        DEVELOPER.
                    </P
></DD
><DT
>$g_limit_reporters</DT
><DD
><P
>Limit reporters to only viewing bugs that they
                        report.
                    </P
></DD
><DT
>$g_allow_reporter_close</DT
><DD
><P
>Allow reporters to close the bugs they reported.</P
></DD
><DT
>$g_allow_close_immediately</DT
><DD
><P
>Allow developers and above to close bugs immediately when
                        resolving bugs.
                    </P
></DD
><DT
>$g_allow_bug_delete_access_level</DT
><DD
><P
>Allow the specified access level and above to delete
                        bugs.
                    </P
></DD
><DT
>$g_bug_move_access_level</DT
><DD
><P
>Allow the specified access level and above to move bugs
                        between projects.
                    </P
></DD
><DT
>$g_allow_account_delete</DT
><DD
><P
>Allow users to delete their own accounts.</P
></DD
><DT
>$g_allow_anonymous_login</DT
><DD
><P
>Enable anonymous access to Mantis. You must also
                        specify $g_anonymous_account as the account which
                        anonymous users will browse Mantis with. The default
                        setting is OFF.</P
></DD
><DT
>$g_anonymous_account</DT
><DD
><P
>Define the account which anonymous users will assume
                        when using Mantis. This account is considered by Mantis
                        to be protected from modification. In other words, this
                        account can only be modified by users with an access
                        level equal to or higher than $g_manage_user_threshold.
                        Anonymous users will not be able to adjust preferences
                        or change account settings like normal users can.
                    </P
><P
>You will need to create a new account to use for this
                        $g_anonymous_account setting. When creating the account
                        you should specify a password, email address and so
                        forth in the same way you'd create any other account.
                        It is suggested that the access level for this account
                        be set to VIEWER or some other read only level.
                    </P
><P
>The anonymous user account will not receive standard
                        notifications and can not monitor issues.
                    </P
><P
>The default setting is blank/undefined. You only need
                        to define this setting when $g_allow_anonymous_login
                        is set to ON.
                    </P
></DD
><DT
>$g_cvs_web</DT
><DD
><P
>This allows for quick linking to CVS files via CVSweb or
                        ViewCVS.
                    </P
></DD
><DT
>$g_bug_link_tag</DT
><DD
><P
>If a number follows this tag it will create a link to a
                        bug. eg. for # a link would be #45 eg. for bug: a
                        link would be bug:98
                    </P
></DD
><DT
>$g_show_timer</DT
><DD
><P
>Time page loads. Shows at the bottom of the page.</P
></DD
><DT
>$g_show_queries_count</DT
><DD
><P
>Shows the total number/unique number of queries executed to
                        serve the page. Default is ON.
                    </P
></DD
><DT
>$g_show_queries_list</DT
><DD
><P
>Shows the list of all queries that are executed in
                        chronological order from top to bottom. This option is only
                        effective when $g_show_queries_count is ON. Default is OFF.
                        WARNING: Potential security hazard. Only turn this on when you
                        really need it (for debugging or profiling)
                    </P
></DD
><DT
>$g_register_globals</DT
><DD
><P
>If your register_globals is Off then set this to OFF. Check
                        your register_globals setting in php.ini or phpinfo().
                    </P
></DD
><DT
>$g_enable_project_documentation</DT
><DD
><P
>Specifies whether to enable support for project documents or
                        not. Default is OFF.  This feature is deprecated and is expected
                        to be moved to a plugin in the future.
                    </P
></DD
><DT
>$g_admin_site_threshold</DT
><DD
><P
>Threshold at which a user is considered to be a site
                        administrator. These users have the highest level of
                        access to your Mantis installation. This access level
                        is required to change key Mantis settings (such as
                        server paths) and perform other administrative duties.
                        You may need to change this value from the default of
                        ADMINISTRATOR if you have defined a new access level
                        to replace the default ADMINISTRATOR level in
                        constant_inc.php.
                    </P
><DIV
CLASS="WARNING"
><P
></P
><TABLE
CLASS="WARNING"
WIDTH="90%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/warning.gif"
HSPACE="5"
ALT="Warning"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>This is a potentially dangerous configuration
                            option. Users at or above this threshold value will
                            have permission to all aspects of Mantis including
                            the admin/ directory. With this access level, users
                            can damage your installation of Mantis, destroy
                            your database or have elevated access to your
                            server.
                        </P
><P
>DO NOT CHANGE THIS VALUE UNLESS YOU ABSOLUTELY
                            KNOW WHAT YOU'RE DOING. BE VERY CAREFUL WITH
                            CHANGING THIS CONFIGURATION VALUE FROM THE DEFAULT
                            SETTING.
                        </P
></TD
></TR
></TABLE
></DIV
></DD
><DT
>$g_view_configuration_threshold</DT
><DD
><P
>Threshold for users to view the raw system configurations as stored in the database.
                        The default value is ADMINISTRATOR.
                    </P
></DD
><DT
>$g_set_configuration_threshold</DT
><DD
><P
>Threshold for users to set the system configurations generically via MantisBT web interface.
                        WARNING: Users who have access to set configuration via the interface MUST be trusted.  This is due
                        to the fact that such users can set configurations to PHP code and hence there can be a security
                        risk if such users are not trusted. The default value is ADMINISTRATOR.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.COOKIES"
>5.22. Cookies</A
></H2
><P
>The configuration variables $g_string_cookie,
            $g_project_cookie, $g_view_all_cookie, $g_manage_cookie are
            calculated based on $g_cookie_prefix. When you change the cookie
            prefix in config_inc.php, you need to follow it with a copy of the
            four lines that calculate the names for these cookies.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_cookie_path</DT
><DD
><P
>This is specifies to the path under which a cookie is
                        visible. All scripts in this directory and its sub-directories will
                        be able to access MantisBT cookies. Default value is '/'. It is
                        recommended to set this to the actual MantisBT path.
                    </P
></DD
><DT
>$g_cookie_domain</DT
><DD
><P
>Unused</P
></DD
><DT
>$g_cookie_version</DT
><DD
><P
>Cookie version is used as a prefix for cookies that should
                        be expire when the code is changed in a certain way. The developers
                        would increase this version when necessary, which in effect will
                        cause the creation of new cookies that are compatible with the new
                        code. It is not expected for the user to need to change this
                        setting.
                    </P
></DD
><DT
>$g_cookie_prefix</DT
><DD
><P
>This should be set to a unique identifier which does not
                        include spaces. Again, this should be unique per MantisBT
                        installation, specially if the $g_cookie_path is not restricting
                        the cookies scope to the actual MantisBT directory.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.TABLES"
>5.23. Database Tables</A
></H2
><P
>MantisBT enables users to configure a table prefix for all its
            tables. This is useful to be able to have multiple MantisBT
            installation in the same database. The advantage of that is for
            users who are limited by their ISP to have one database.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_db_table_prefix</DT
><DD
><P
>Specifies the prefix to be use for all table names. The
                        default value is 'mantis'. If you override the default prefix, make
                        sure to update doc/db_generate.sql file before generating your
                        database. The other option is to import db_generate.sql as is, then
                        rename the tables to match the new prefix.
                    </P
><P
>The prefix is used to help make sure table names are unique.
                        This is useful for users who are limited to one database.
                    </P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="90%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>                            The table name for each of the tables is stored in a variable which
                            is calculated based on this configuration option. If you change the
                            prefix you have to make sure these variables are re-calculated (by
                            adding these calculation statements to config_inc.php after
                            assigning the new prefix). An example of these variables is:
                            $g_mantis_bug_file_table
                        </P
></TD
></TR
></TABLE
></DIV
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.SPEED"
>5.24. Speed Optimisation</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_compress_html</DT
><DD
><P
>This option is used to enable buffering/compression of HTML
                        output if the user's browser supports it. Default value is ON.
                        This option will be ignored in the following scenarios:
                        <P
></P
><UL
><LI
><P
>If php.ini has zlib.output_compression
                                    enabled.
                                </P
></LI
><LI
><P
>If php.ini has output_handler set to a
                                    handler.
                                </P
></LI
><LI
><P
>If PHP does not include the zlib extension (PHP 4.3.0 and
                                    later include zlib extension by default).
                                </P
></LI
></UL
>
                        You can check the loaded modules in your PHP by running "php -m" on
                        the command line, or by using php_info() command in a php script.
                    </P
></DD
><DT
>$g_use_persistent_connections</DT
><DD
><P
>Use persistent database connections, setting this to ON will
                        open the database once per connection, rather than once per page.
                        There might be some scalability issues here and that is why it is
                        defaulted to OFF.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.REMINDERS"
>5.25. Reminders</A
></H2
><P
>Sending reminders is a feature where a user can notify /
            remind other users about a bug. In the past, only selected users
            like the managers, or developers would get notified about bugs.
            However, these people can not invite other people (through MantisBT)
            to look at or monitor these bugs.
        </P
><P
>This feature is useful if the Manager needs to get feedback
            from testers / requirements team about a certain bug. It avoid
            needing this person to do this manual outside MantisBT. It also
            records the history of such reminders.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_store_reminders</DT
><DD
><P
>Specifies if reminders should be stored as bugnotes. The
                        bugnote will still reflect that it is a reminder and list the names
                        of users that got it. Default is ON.
                    </P
></DD
><DT
>$g_reminder_recipients_monitor_bug</DT
><DD
><P
>Specifies if users who receive reminders about a bug, should
                        be automatically added to the monitor list of that bug. Default is
                        ON.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.BUGHISTORY"
>5.26. Bug History</A
></H2
><P
>Bug history is a feature where MantisBT tracks all
            modifications that are made to bugs. These include everything
            starting from its creation, till it is closed. For each change, the
            bug history will record the time stamp, user who made the change,
            field that changed, old value, and new value.
        </P
><P
>Independent of the these settings, MantisBT will always track
            the changes to a bug and add them to its history.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_history_default_visible</DT
><DD
><P
>Make the bug history visible by default. If this option is
                        not enabled, then the user will have to click on the Bug History
                        link to see the bug history. Default is ON.
                    </P
></DD
><DT
>$g_history_order</DT
><DD
><P
>Show bug history entries in ascending or descending order.
                        Default value is 'ASC'.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.SPONSORSHIP"
>5.27. Sponsorship</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_enable_sponsorship</DT
><DD
><P
>enable/disable the whole issue sponsorship feature. The
                        default os OFF.
                    </P
></DD
><DT
>$g_sponsorship_currency</DT
><DD
><P
>The currency string used for all sponsorships. The default
                        is 'US$'.
                    </P
></DD
><DT
>$g_minimum_sponsorship_amount</DT
><DD
><P
>The minimum sponsorship amount that can be entered. If the
                        user enters a value less than this, an error will be flagged. The
                        default is 5.
                    </P
></DD
><DT
>$g_view_sponsorship_total_threshold</DT
><DD
><P
>The access level threshold needed to view the total
                        sponsorship for an issue by all users. The default is
                        VIEWER.
                    </P
></DD
><DT
>$g_view_sponsorship_details_threshold</DT
><DD
><P
>The access level threshold needed to view the details of the
                        sponsorship (i.e., who will donate what) for an issue by all users.
                        The default is VIEWER.
                    </P
></DD
><DT
>$g_sponsor_threshold</DT
><DD
><P
>The access level threshold needed to allow user to sponsor
                        issues. The default is REPORTER. Note that sponsoring user must
                        have their email set in their profile.
                    </P
></DD
><DT
>$g_handle_sponsored_bugs_threshold</DT
><DD
><P
>The access level required to be able to handle sponsored
                        issues. The default is DEVELOPER.
                    </P
></DD
><DT
>$g_assign_sponsored_bugs_threshold</DT
><DD
><P
>The access level required to be able to assign a sponsored
                        issue to a user with access level greater or equal to
                        'handle_sponsored_bugs_threshold'. The default is MANAGER.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.SOURCECONTROL"
>5.28. Source Control Integration</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_source_control_account</DT
><DD
><P
>Account to be used by the source control script. The account
                        must be enabled and must have the appropriate access level to add
                        notes to all issues even private ones (DEVELOPER access
                        recommended). The default is '' (not set).
                    </P
></DD
><DT
>$g_source_control_notes_view_status</DT
><DD
><P
>This sets whether the note added will be public or private
                        (VS_PUBLIC or VS_PRIVATE). For open source projects it is expected
                        that the notes be public, however, for non-open source it will
                        probably be VS_PRIVATE. The default is VS_PRIVATE.
                    </P
></DD
><DT
>$g_source_control_set_status_to</DT
><DD
><P
>If set to a status, then after a checkin, the issue status
                        is set to the specified status, otherwise if set to OFF, the issue
                        status is not affected. The default is OFF.
                    </P
></DD
><DT
>$g_source_control_regexp</DT
><DD
><P
>Regular expression used to detect issue ids within checkin
                        comments. See
                        <A
HREF="http://www.php.net/manual/en/function.preg-match-all.php"
TARGET="_top"
>preg_match_all()</A
>
                        documentation for more details on setting a pattern. The default is
                        "/\bissue [#]{0,1}(\d+)\b/i" (e.g., issue #745).
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.CUSTOMFIELDS"
>5.29. Custom Fields</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_manage_custom_fields_threshold</DT
><DD
><P
>Access level needed to manage custom fields. The default is
                        ADMINISTRATOR.
                    </P
></DD
><DT
>$g_custom_field_link_threshold</DT
><DD
><P
>Access level needed to link a custom field to a project. The
                        default is MANAGER.
                    </P
></DD
><DT
>$$g_custom_field_edit_after_create</DT
><DD
><P
>This flag determines whether to start editng a custom field
                        immediately after creating it, or return to the definition list.
                        The default is ON (edit the custom field after creating).
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.MYVIEW"
>5.30. My View Settings</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_my_view_boxes</DT
><DD
><P
>This is an array of values defining the order that the boxes
                        to be shown. A box that is not to be shown can have its value set
                        to 0. The default is:
                        <PRE
CLASS="PROGRAMLISTING"
>$g_my_view_boxes = array ( 'assigned' =&gt; '1',
                            'unassigned' =&gt; '2',
                            'reported' =&gt; '3',
                            'resolved' =&gt; '4',
                            'recent_mod' =&gt; '5',
                            'monitored' =&gt; '6'
                            );
                        </PRE
>
                        If you want to change the definition, copy the default value and
                        apply the changes.
                    </P
></DD
><DT
>$g_my_view_bug_count</DT
><DD
><P
>Number of bugs shown in each box. The default is 10.</P
></DD
><DT
>$g_default_home_page</DT
><DD
><P
>Default page to transfer to after Login or Set Project. The
                        default is 'my_view_page.php'. An alternative would be
                        'view_all_bugs_page.php' or 'main_page.php'.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.RELATIONSHIP"
>5.31. Relationship Graphs</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_relationship_graph_enable</DT
><DD
><P
>                        This enables the relationship graphs feature where issues are represented by
                        nodes and relationships as links between such nodes.  Possible values are ON or OFF.
                        Default is OFF.
                    </P
><P
>                        This feature requires installing <A
HREF="http://www.research.att.com/sw/tools/graphviz/"
TARGET="_top"
>GraphViz</A
>
                        (all OSes except Windows) or <A
HREF="http://home.so-net.net.tw/oodtsen/wingraphviz/"
TARGET="_top"
>WinGraphviz</A
> (only Windows).
                        Refer to the notes near the top of core/graphviz_api.php and
                        core/relationship_graph_api.php for more information.
                    </P
></DD
><DT
>$g_relationship_graph_fontname</DT
><DD
><P
>                        Font name and size, as required by Graphviz. If Graphviz fails to run
                        for you, you are probably using a font name that gd PHP extension can't find.
                        On Linux, try the name of the font file without the extension.  The default
                        value is 'Arial'.
                    </P
></DD
><DT
>$g_relationship_graph_fontsize</DT
><DD
><P
>                        Font size, default is 8.
                    </P
></DD
><DT
>$g_relationship_graph_orientation</DT
><DD
><P
>                        Default dependency orientation.  If you have issues with lots of children
                        or parents, leave as 'horizontal', otherwise, if you have lots of
                        "chained" issue dependencies, change to 'vertical'.  Default is 'horizontal'.
                    </P
></DD
><DT
>$g_relationship_graph_max_depth</DT
><DD
><P
>                        Max depth for relation graphs.  This only affects relationship graphs,
                        dependency graphs are drawn to the full depth.  The default value is 2.
                    </P
></DD
><DT
>$g_relationship_graph_view_on_click</DT
><DD
><P
>                        If set to ON, clicking on an issue on the relationship graph will open
                        the bug view page for that issue, otherwise, will navigate to the
                        relationship graph for that issue.
                    </P
></DD
><DT
>$g_dot_tool</DT
><DD
><P
>                        The full path for the dot tool.  The webserver must have execute
                        permission to this program in order to generate relationship graphs.
                        This configuration option is not relevant for Windows.  The default
                        value is '/usr/bin/dot'.
                    </P
></DD
><DT
>$g_neato_tool</DT
><DD
><P
>                        The full path for the neato tool.  The webserver must have execute
                        permission to this program in order to generate relationship graphs.
                        This configuration option is not relevant for Windows.  The default
                        value is '/usr/bin/neato'.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.SUBPROJECTS"
>5.32. Sub-Projects</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_show_extended_project_browser</DT
><DD
><P
>                        Whether to use the extended project selector, where top level projects have their
                        separate selector, and sub-projects have another.  If OFF, there will be one combo box
                        at the top right to select the project/sub-project.  If ON, there will be two.  The default
                        is OFF.
                    </P
></DD
><DT
>$g_subprojects_inherit_versions</DT
><DD
><P
>                        Whether sub-projects should inherit versions from parent projects.  For project X which
                        is a sub-project of A and B, it will have versions from X, A and B.  The default value is ON.
                    </P
></DD
><DT
>$g_subprojects_inherit_categories</DT
><DD
><P
>                        Whether sub-projects should inherit categories from parent projects.  For project X which
                        is a sub-project of A and B, it will have categories from X, A and B.  The default value is ON.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.FIELDS"
>5.33. Field Visibility</A
></H2
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_enable_eta</DT
><DD
><P
>                        Enable or disable usage of 'ETA' field.  Default value is OFF.
                    </P
></DD
><DT
>$g_enable_projection</DT
><DD
><P
>                        Enable or disable usage of 'Projection' field.  Default value is OFF.
                    </P
></DD
><DT
>$g_show_product_build</DT
><DD
><P
>                        Enable or disable usage of 'Product Build' field.  Default is OFF.
                    </P
></DD
><DT
>$g_bug_report_page_fields</DT
><DD
><P
>                        An array of fields to show on the issue view page.  Some of these fields may be
                        filtered out if their features are disabled or if the user doesn't have access
                        to view them.  See BUG_FIELD_* in constant_inc.php for all possible values.
                    </P
><P
>                        The following fields can not be included: BUG_FIELD_ID, BUG_FIELD_PROJECT,
                        BUG_FIELD_DATE_SUBMITTED, BUG_FIELD_LAST_UPDATED, BUG_FIELD_STATUS,
                        BUG_FIELD_RESOLUTION, BUG_FIELD_TAGS, BUG_FIELD_FIXED_IN_VERSION,
                        BUG_FIELD_PROJECTION, BUG_FIELD_ETA, BUG_FIELD_REPORTER.
                    </P
><P
>                        The following fields must be included:
                        BUG_FIELD_CATEGORY, BUG_FIELD_SUMMARY, BUG_FIELD_DESCRIPTION.
                    </P
><P
>                        To overload these settings per project, then the settings must be included in the database through
                        the generic configuration form.  Note that the array in the database should consistent of the
                        values of the constants below.  For example, replace BUG_FIELD_CATEGORY with 'category_id'.
                        See constant_inc.php for the values of the constants.
                    </P
></DD
><DT
>$g_bug_view_page_fields</DT
><DD
><P
>                        An array of fields to show on the issue view page.  Some of these fields may be
                        filtered out if their features are disabled or if the user doesn't have access
                        to view them.  See BUG_FIELD_* in constant_inc.php for all possible values.
                    </P
><P
>                        To overload this setting per project, then the setting must be included in the database through
                        the generic configuration form.  Note that the array in the database should consistent of the
                        values of the constants.  For example, replace BUG_FIELD_CATEGORY with 'category_id'.
                        See constant_inc.php for the values of the constants.
                    </P
></DD
><DT
>$g_bug_print_page_fields</DT
><DD
><P
>                        An array of fields to show on the issue print page.  Some of these fields may be
                        filtered out if their features are disabled or if the user doesn't have access
                        to view them.  See BUG_FIELD_* in constant_inc.php for all possible values.
                    </P
></DD
><DT
>$g_bug_update_page_fields</DT
><DD
><P
>                        An array of fields to show on the issue update page.  Some of these fields may be
                        filtered out if their features are disabled or if the user doesn't have access
                        to view them.  See BUG_FIELD_* in constant_inc.php for all possible values.
                    </P
><P
>                        To overload this setting per project, then the setting must be included in the database through
                        the generic configuration form.  Note that the array in the database should consistent of the
                        values of the constants.  For example, replace BUG_FIELD_CATEGORY with 'category_id'.
                        See constant_inc.php for the values of the constants.
                    </P
></DD
><DT
>$g_bug_change_status_page_fields</DT
><DD
><P
>                        An array of fields to show on the issue change status page.  Some of these fields may be
                        filtered out of their features are disabled or if the user doesn't have access
                        to view them.  See BUG_FIELD_* in constant_inc.php for all possible values.
                    </P
><P
>                        To overload this setting per project, then the setting must be included in the database through
                        the generic configuration form.  Note that the array in the database should consistent of the
                        values of the constants.  For example, replace BUG_FIELD_CATEGORY with 'category_id'.
                        See constant_inc.php for the values of the constants.
                    </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONFIG.LOGGING"
>5.34. System Logging</A
></H2
><P
>The system logging interface is used to extract detailed
            debugging information for the MantisBT system. It can also serve as
            an audit trail for user actions.
        </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>$g_log_level</DT
><DD
><P
>This controls the type of logging information recorded.
                        Possible values include:

                        <P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>LOG_EMAIL</DT
><DD
><P
>logs issue id, message type and recipients for all emails
                                        sent
                                    </P
></DD
><DT
>LOG_EMAIL_RECIPIENT</DT
><DD
><P
>logs the details of email recipient determination. Each user
                                        id is listed as well as why they are added, or deleted from the
                                        recipient list
                                    </P
></DD
></DL
></DIV
>
                    </P
></DD
><DT
>$g_log_destination</DT
><DD
><P
>specifies the file where the log data goes. This file must
                        be writable by the web server userid running MantisBT. Right now,
                        only "file:&lt;file path&gt;" is supported. For example,
                        $g_log_destination = 'file:/tmp/mantis_log';
                        See http://www.php.net/error_log for details.
                    </P
></DD
></DL
></DIV
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.PAGES"
></A
>Chapter 6. Page descriptions</H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.LOGIN"
>6.1. Login page</A
></H2
><P
>Just enter your username and password and hit the login
            button. There is also a Save Login checkbox to have the package
            remember that you are logged in between browser sessions. You will
            have to have cookies enabled to login.If the account doesn't exist,
            the account is disabled, or the password is incorrect then you will
            remain at the login page. An error message will be displayed.The
            administrator may allow users to sign up for their own accounts. If
            so, a link to Signup for your own account will be available.The
            administrator may also have annonymous login allowed. Annonymous
            users will be logged in under a common account.You will be allowed
            to select a project to work in after logging in. You can make a
            project your default selection from the Select Project screen or
            from your Account Options.SignupHere you can signup for a new
            account. You must supply a valid email address and select a unique
            username. Your randomly generated password will be emailed to your
            email account. If MantisBT is setup so that the email password is not
            to be emailed, newly generated accounts will have an empty
            password.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MAIN"
>6.2. Main page</A
></H2
><P
>This is the first page you see upon logging in. It shows you
            the latest news updates for the bugtracker. This is a simple news
            module (based off of work by Scott Roberts) and is to keep users
            abreast of changes in the bugtracker or project. Some news postings
            are specific to projects and others are global across the entire
            bugtracker. This is set at the time of posting in the Edit News
            section.The number of news posts is controlled by a global
            variable. When the number of posts is more than the limit, a link
            to show "older news" is displayed at the bottom. Similarly a "newer
            news" is displayed when you have clicked on "older news".There is
            an Archives option at the bottom of the page to view all
            listings.ArchivesA title/date/poster listing of ALL past news
            articles will be listed here. Clicking on the link will bring up
            the specified article. This listing will also only display items
            that are either global or specific to the selected project.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.FILTER"
>6.3. View Issues page</A
></H2
><P
>Here we can view the issue listings. The page has a set of
            viewing filters at the top and the issues are listed below.FiltersThe
            filters control the behavior of the issues list. The filters are saved
            between browsing sessions but do not currently save sort order or
            direction.If the number of issues exceeds the "Show" count in the
            filter a set of navigation to go to "First", "Last", "Previous",
            "Next" and specific page numbers are added.The Search field will
            look for simple keyword matches in the summary, description, steps
            to reproduce, additional information, issue id, or issue text id
            fields. It does not search through issue notes.

            Issue List - The issues are
            listed in a table and the attributes are listed in the following
            order: priority, id, number of issue notes, category, severity,
            status, last updated, and summary. Each (except for number of
            issue notes) can be clicked on to sort by that column. Clicking again
            will reverse the direction of the sort. The default is to sort by
            last modification time, where the last modified issue appears at the
            top. The issue id is a link that leads to a more detailed report about
            the issue. You can also add issue notes here. The number in the
            issue note count column will be bold if an issue note has been
            added in the specified time frame. The addition of an issue note
            will make the issue note link of the issue appear in the unvisited
            state. The text in the "Severity" column will be bold if the
            severity is major, crash, or block and the issue not resolved. The
            text in the "Updated" column will be bold if the issue has changed
            in the last "Changed(hrs)" field which is specified in the viewing
            filters. Each table row is color coded according to the issue
            status. The colors can be customised through MantisBT
            <A
HREF="#ADMIN.CONFIG"
>Configuration</A
>
            .Severitiesblock
            - prevents further work/progress from being made
            crash - crashes the application or blocking,
            major - major issue,
            minor - minor issue,
            tweak - needs tweaking,
            text - error in the text,
            trivial - being nit picky,
            feature - requesting new feature
            - Status
            new - new issue,
            feedback - issue requires more information from reporter,
            acknowledged - issue has been looked at but not confirmed or assigned,
            confirmed - confirmed and reproducible (typically set by an
            Updater or other Developer),
            assigned - assigned to a Developer,
            resolved - issue should be fixed, waiting on confirmation of fix,
            closed - issue is closed,
            Moving the mouse over the status text will
            show the resolution as a title. This is rendered by some browsers
            as a bubble and in others as a status line text.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.ISSUEVIEW"
>6.4. Issue View page</A
></H2
><P
>Here is the simple listing of the issue report. Most of the
            fields are self-explanatory. "Assigned To" will contain the
            developer assigned to handle the issue. Priority is fully functional
            but currently does nothing of importance. Duplicate ID is used when
            an issue is a duplicate of another. It links to the duplicate issue
            which allows users to read up on the original issue report. Below the
            issue report is a set of buttons that a user can select to work on
            the issue.
        </P
><P
></P
><UL
><LI
><P
>Update Issue - brings up a page to edit all aspects of
                    the issue
                </P
></LI
><LI
><P
>Assign to - in conjunction with the dropdown list next
                    top the button, this is a shortcut to change the assignment of an
                    issue
                </P
></LI
><LI
><P
>Change Status to - in conjunction with the dropdown list
                    next top the button, this is a shortcut to change the status of an
                    issue. Another page (Change Status) will be presented to allow the
                    user to add notes or change relevant information
                </P
></LI
><LI
><P
>Monitor / Unmonitor Issue - allows the user to monitor
                    any additions to the issue by email
                </P
></LI
><LI
><P
>Create Clone - create a copy of the current issue. This
                    presents the user with a new issue reporting form with all of the
                    information in the current issue filled in. Upon submission, a new
                    issue, related to the current issue, will be created.
                </P
></LI
><LI
><P
>Reopen Issue - Allows the user to re-open a resolved
                    issue
                </P
></LI
><LI
><P
>Move Issue - allows the user to move the issue to another
                    project
                </P
></LI
><LI
><P
>Delete Issue - Allows the user to delete the issue
                    permanently. It is recommended against deleting issues unless the
                    entry is frivolous. Instead issues should be set to resolved and an
                    appropriate resolution category chosen.
                </P
></LI
></UL
><P
>            A panel is provided to view and update the sponsorship of an
            issue.Another panel is provided to view, delete and add
            relationships for an issue. Issues can have a parent/child
            relationship, where the user is warned about resolving a parent
            issue before all of the children are resolved. A peer relationship
            is also possible.Below this, there may be a form for uploading file
            attachments. The Administrator needs to configure the bugtracker to
            handle file uploads. If uploading to disk is selected, each project
            needs to set its own upload path.  Issue notes are shown at the bottom
            of the issue report. A panel to add issue notes is also shown.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.ISSUESTATUS"
>6.5. Issue Change Status page</A
></H2
><P
>This page is used to change the status of an issue. A user
            can add an issue note to describe the reason for change.In addition,
            the following fields may be displayed for update:
            <P
></P
><UL
><LI
><P
>Resolution and Duplicate ID - for issues being resolved
                        or closed
                    </P
></LI
><LI
><P
>Issue Handler (Assigned to)</P
></LI
><LI
><P
>any Custom Fields that are to be visible on update or
                        resolution
                    </P
></LI
><LI
><P
>Fixed in Version - for issues being resolved</P
></LI
><LI
><P
>Close Immediately - to immediately close a resolved
                        issue
                    </P
></LI
></UL
>
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.ISSUEEDIT"
>6.6. Issue Edit page</A
></H2
><P
>The layout of this page resemples the Simple Issue View
            page, but here you can update various issue fields. The Reporter,
            Category, Severity, and Reproducibility fields are editable but
            shouldn't be unless there is a gross mis-categorization.Also
            modifiable are the Assigned To, Priority, Projection, ETA,
            Resolution, and Duplicate ID fields.As per version 0.18.0, the user
            can also add an issue note as part of an issue update.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.ACCOUNT"
>6.7. My Account Page</A
></H2
><P
>This page changes user alterable parameters for the system.
            These selections are user specific.My AccountThis allows the user
            to change their password, screen name, and email address. It also
            reports the user's access levels on the current and other
            projects.
        </P
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.ACCOUNT.PREFS"
>6.7.1. Preferences</A
></H3
><P
>                This sets the following information:
                <P
></P
><UL
><LI
><P
>Default project</P
></LI
><LI
><P
>whether the pages used for reporting, viewing, and
                            updating are the simple or advanced views
                        </P
></LI
><LI
><P
>the delay in minutes between refreshes of the view all
                            issues page
                        </P
></LI
><LI
><P
>the delay in seconds when redirecting from a confirmation
                            page to the display page
                        </P
></LI
><LI
><P
>the time order in which notes will be sorted</P
></LI
><LI
><P
>whether to filter email messages based on type of message
                            and severity
                        </P
></LI
><LI
><P
>the number of notes to append to notification
                            emails
                        </P
></LI
><LI
><P
>the default language for the system. The additional
                            setting of "auto" will use the browser's default language for the
                            system.
                        </P
></LI
></UL
>
            </P
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.ACCOUNT.PROFILES"
>6.7.2. Profiles</A
></H3
><P
>                Profiles are shortcuts to define the values for Platform,
                OS, and version. This page allows you to define and edit personal
                shortcuts.
            </P
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MANAGE"
>6.8. System Management Pages</A
></H2
><P
>A number of pages exist under the "Manage" link. These will
            only be visible to those who have an appropriate access
            level.
        </P
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MANAGE.USERS"
>6.8.1. Manage Users</A
></H3
><P
>This page allow an administrator to manage the users in the
                system.It essentially supplies a list of users defined in the
                system. The user names are linked to a page where you can change
                the user's name, access level, and projects to which they are
                assigned. You can also reset their passwords through this page.At
                the top, there is also a list of new users (who have created an
                account in the last week), and accounts where the user has yet to
                log in.New users are created using the "Create User" link above the
                list of existing users. Note that the username must be unique in
                the system. Further, note that the user's real name (as displayed
                on the screen) cannot match another user's user name.
            </P
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MANAGE.PROJECTS"
>6.8.2. Manage Projects Page</A
></H3
><P
>This page allows the user to manage the projects listed in
                the system.Each project is listed along with a link to manage that
                specific project. The specific project pages allow the user to
                change:
                <P
></P
><UL
><LI
><P
>the project name</P
></LI
><LI
><P
>the project description</P
></LI
><LI
><P
>its status</P
></LI
><LI
><P
>whether the project is public or private. Private
                            projects are only visible to users who are assigned to it or users
                            who have the access level to automatically have access to private
                            projects (eg: administrators).
                        </P
></LI
><LI
><P
>afile directory used to store attachments for issues and
                            documents associated with the project. This folder is located on
                            the webserver, it can be absolute path or path relative to the main
                            MantisBT folder. Note that this is only used if the files are stored
                            on disk or via FTP. In case of FTP, the cached version that is
                            saved on the webserver, is stored in the specified path.
                        </P
></LI
><LI
><P
>common subprojects. These are other projects who can be
                            considered a sub-project of this one. They can be shared amongst
                            multiple projects. For example, a "documentation" project may be
                            shared amongst several development projects.
                        </P
></LI
><LI
><P
>project categories. These are used to sub-divide the
                            issues stored in the system.
                        </P
></LI
><LI
><P
>project versions. These are used to create ChangeLog
                            reports and can be used to filter issues. They are used for both
                            the Found In and Fixed In versions.
                        </P
></LI
><LI
><P
>Custom Fields linked to this project</P
></LI
><LI
><P
>Users linked to this project. Here is the place where a
                            user's access level may be upgraded or downgraded depending on
                            their particular role in the project.
                        </P
></LI
></UL
>
            </P
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MANAGE.CUSTOMFIELDS"
>6.8.3. Manage Custom Fields</A
></H3
><P
>This page is the base point for managing custom fields. It
                lists the custom fields defined in the system. There is also a
                place to enter a new field name to create a new field.The "Edit"
                links take you to a page where you can define the details of a
                custom field. These include it's name, type, value, and display
                information. On the edit page, the following information is defined
                to control the custom field:
                <P
></P
><UL
><LI
><P
>name</P
></LI
><LI
><P
>type. Possible values are listed below.</P
></LI
><LI
><P
>Value constraints (Possible values, default value,
                            regular expression, minimum length, maximum length).
                        </P
></LI
><LI
><P
>Access (who can read and write the field based on their
                            access level).
                        </P
></LI
><LI
><P
>Display control (where the field will show up and must be
                            filled in
                        </P
></LI
></UL
>
            </P
><P
>                All fields are compared in length to be greater than or equal to
                the minimum length, and less than or equal to the manimum length,
                unless these values are 0. If the values are 0, the check is
                skipped. All fields are also compared against the regular
                expression. If the value matches the expression, then the value is
                stored. For example, the expression "/^-?([0-9])*$/" can be used to
                constrain an integer.The table below describes the field types and
                the value constraints.
            </P
><DIV
CLASS="INFORMALTABLE"
><P
></P
><A
NAME="AEN1833"
></A
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><COL><COL><COL><TBODY
><TR
><TD
>Type</TD
><TD
>Field Contents</TD
><TD
>Value Constraints</TD
></TR
><TR
><TD
>String</TD
><TD
>text string up to 255 characters</TD
><TD
>&nbsp;</TD
></TR
><TR
><TD
>Numeric</TD
><TD
>an integer</TD
><TD
>&nbsp;</TD
></TR
><TR
><TD
>Float</TD
><TD
>a floating point number</TD
><TD
>&nbsp;</TD
></TR
><TR
><TD
>Enumeration</TD
><TD
>one of a list of text strings</TD
><TD
>Enter the list of text strings separated by "|" (pipe
                                character) in the Possible Values field. The Default value should
                                match one of these strings as well. This will be displayed as a
                                dropdown menu.
                            </TD
></TR
><TR
><TD
>Email</TD
><TD
>an email address string up to 255 characters</TD
><TD
>When displayed, the value will also be encapsulated in a
                                mailto: reference.
                            </TD
></TR
><TR
><TD
>Checkbox</TD
><TD
>zero or more of a list of text strings</TD
><TD
>Enter the list of text strings separated by "|" (pipe
                                character) in the Possible Values field. The Default value should
                                match one of these strings as well. This will be displayed as a
                                list of text strings with a checkbox beside them.
                            </TD
></TR
><TR
><TD
>List</TD
><TD
>one of a list of text strings</TD
><TD
>Enter the list of text strings separated by "|" (pipe
                                character) in the Possible Values field. The Default value should
                                match one of these strings as well. This will be displayed as a
                                multi-line dropdown menu.
                            </TD
></TR
><TR
><TD
>Multiselection List</TD
><TD
>zero or more of a list of text strings</TD
><TD
>Enter the list of text strings separated by "|" (pipe
                                character) in the Possible Values field. The Default value should
                                match one of these strings as well. This will be displayed as a
                                multi-line dropdown menu.
                            </TD
></TR
><TR
><TD
>Date</TD
><TD
>text string defining a date</TD
><TD
>This is displayed as a set of dropdown menus for day, month,
                                and year. Defaults should be defined in yyyy-mm-dd format.
                            </TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
><P
>                The display entries are used as follows:
                <DIV
CLASS="INFORMALTABLE"
><P
></P
><A
NAME="AEN1877"
></A
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><COL><COL><TBODY
><TR
><TD
>Entry</TD
><TD
>Meaning</TD
></TR
><TR
><TD
>Display Only On Advanced Page</TD
><TD
>If checked, the field will NOT be shown on the simple issue
                                    displays
                                </TD
></TR
><TR
><TD
>Display When Reporting Issues</TD
><TD
>If checked, the field will be shown on the report issues
                                    displays
                                </TD
></TR
><TR
><TD
>Display When Updating Issues</TD
><TD
>If checked, the field will NOT be shown on the update issue
                                    and change status displays
                                </TD
></TR
><TR
><TD
>Display When Resolving Issues</TD
><TD
>If checked, the field will NOT be shown on the update issue
                                    displays and change status displays, if the new status is
                                    resolved.
                                </TD
></TR
><TR
><TD
>Display When Closing Issues</TD
><TD
>If checked, the field will NOT be shown on the update issue
                                    displays and change status displays, if the new status is
                                    closed.
                                </TD
></TR
><TR
><TD
>Required On Report</TD
><TD
>If checked, the field must be filled in on the issue
                                    reports.
                                </TD
></TR
><TR
><TD
>Required On Update</TD
><TD
>If checked, the field must be filled in on the update issue
                                    and change status displays.
                                </TD
></TR
><TR
><TD
>Required On Resolve</TD
><TD
>If checked, the field must be filled in on the update issue
                                    and change status displays, if the new status is resolved.
                                </TD
></TR
><TR
><TD
>Required On Close</TD
><TD
>If checked, the field must be filled in on the update issue
                                    and change status displays, if the new status is closed.
                                </TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
>
            </P
><P
>Notes on Display
                <P
></P
><UL
><LI
><P
>Be careful not to set both a required attribute and show
                            only on advanced display. It may be possible to trigger a
                            validation error that the user cannot recover from (i.e., field is
                            not filled in).
                        </P
></LI
></UL
>
            </P
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MANAGE.PROFILES"
>6.8.4. Manage Global Profiles</A
></H3
><P
>This page allows the definition of global profiles
                accessible to all users of the system. It is similar to the user
                definition of a profile consisting of Platform, OS and
                Version.
            </P
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MANAGE.CONFIG"
>6.8.5. Manage Configuration</A
></H3
><P
>This set of pages control the configuration of the MantisBT
                system. Note that the configuration items displayed may be on a
                project by project basis.These pages serve two purposes. First,
                they will display the settings for the particular aspects of the
                system. If authorized, they will allow a user to change the
                parameters. They also have settings for what access level is
                required to change these settings ON A PROJECT basis. In general,
                this should be left alone, but administrators may want to delegate
                some of these settings to managers.
            </P
><DIV
CLASS="SECTION"
><HR><H4
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MANAGE.CONFIG.THRESHOLDS"
>6.8.5.1. Workflow Thresholds</A
></H4
><P
>This page covers the adjustment of the settings for many of
                    the workflow related parameters. For most of these, the fields are
                    self explanatory and relate to a similarly named setting in the
                    configuration file. At the right of each row is a selector that
                    allows the administrator to lower the access level required to
                    change the particular parameter.The values changeable on this page
                    are:
                </P
><DIV
CLASS="FORMALPARA"
><P
><B
>Issues. </B
><DIV
CLASS="INFORMALTABLE"
><P
></P
><A
NAME="AEN1926"
></A
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><COL><COL><COL><TBODY
><TR
><TD
>Title</TD
><TD
>Variable</TD
><TD
>Description</TD
></TR
><TR
><TD
>Report an Issue</TD
><TD
>$g_report_bug_threshold</TD
><TD
>threshold to report an issue</TD
></TR
><TR
><TD
>Status to which a new issue is set</TD
><TD
>$g_bug_submit_status</TD
><TD
>status issue is set to when submitted</TD
></TR
><TR
><TD
>Update an Issue</TD
><TD
>$g_update_bug_threshold</TD
><TD
>threshold to update an issue</TD
></TR
><TR
><TD
>Allow Issue to be closed on Resolve</TD
><TD
>$g_allow_close_immediately</TD
><TD
>allow close immediately on resolve</TD
></TR
><TR
><TD
>Allow Reporter to close an issue</TD
><TD
>$g_allow_reporter_close</TD
><TD
>allow reporter to close issues they reported</TD
></TR
><TR
><TD
>Monitor an issue</TD
><TD
>$g_monitor_bug_threshold</TD
><TD
>threshold to monitor an issue</TD
></TR
><TR
><TD
>Handle Issue</TD
><TD
>$g_handle_bug_threshold</TD
><TD
>threshold to handle (be assigned) an issue</TD
></TR
><TR
><TD
>Assign Issue</TD
><TD
>$g_update_bug_assign_threshold</TD
><TD
>threshold to be in the assign to list</TD
></TR
><TR
><TD
>Move Issue</TD
><TD
>$g_move_bug_threshold</TD
><TD
>threshold to move an issue to another project. This setting
                                    is for all projects.
                                </TD
></TR
><TR
><TD
>Delete Issue</TD
><TD
>$g_delete_bug_threshold</TD
><TD
>threshold to delete an issue</TD
></TR
><TR
><TD
>Reopen Issue</TD
><TD
>$g_reopen_bug_threshold</TD
><TD
>threshold to reopen an issue</TD
></TR
><TR
><TD
>Allow reporter to reopen Issue</TD
><TD
>$g_allow_reporter_reopen</TD
><TD
>allow reporter to reopen issues they reported</TD
></TR
><TR
><TD
>Status to which a reopened Issue is set</TD
><TD
>$g_bug_reopen_status</TD
><TD
>status issue is set to when reopened</TD
></TR
><TR
><TD
>Resolution to which a reopened Issue is set</TD
><TD
>$g_bug_reopen_resolution</TD
><TD
>resolution issue is set to when reopened</TD
></TR
><TR
><TD
>Status where an issue is considered resolved</TD
><TD
>$g_bug_resolved_status_threshold</TD
><TD
>status where bug is resolved</TD
></TR
><TR
><TD
>Status where an issue becomes read-only</TD
><TD
>$g_bug_readonly_status_threshold</TD
><TD
>status where bug is read-only (see
                                    update_readonly_bug_threshold)
                                </TD
></TR
><TR
><TD
>Update readonly issue</TD
><TD
>$g_update_readonly_bug_threshold</TD
><TD
>threshold to update an issue marked as read-only</TD
></TR
><TR
><TD
>Update Issue Status</TD
><TD
>$g_update_bug_status_threshold</TD
><TD
>threshold to update an issue's status</TD
></TR
><TR
><TD
>View Private Issues</TD
><TD
>$g_private_bug_threshold</TD
><TD
>threshold to view a private issue</TD
></TR
><TR
><TD
>Set View Status</TD
><TD
>$g_set_view_status_threshold</TD
><TD
>threshold to set an issue to Private/Public</TD
></TR
><TR
><TD
>Update View Status</TD
><TD
>$g_change_view_status_threshold</TD
><TD
>threshold needed to update the view status while updating an
                                    issue or an issue note
                                </TD
></TR
><TR
><TD
>Show list of users monitoring issue</TD
><TD
>$g_show_monitor_list_threshold</TD
><TD
>threshold to see who is monitoring an issue</TD
></TR
><TR
><TD
>Set status on assignment of handler</TD
><TD
>$g_auto_set_status_to_assigned</TD
><TD
>change status when an issue is assigned</TD
></TR
><TR
><TD
>Status to set auto-assigned issues to</TD
><TD
>$g_bug_assigned_status</TD
><TD
>status issue is set to when assigned</TD
></TR
><TR
><TD
>Limit reporter's access to their own issues</TD
><TD
>$g_limit_reporters</TD
><TD
>reporters can see only issues they reported. This setting is
                                    for all projects.
                                </TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
></P
></DIV
><DIV
CLASS="FORMALPARA"
><P
><B
>Notes. </B
>                <DIV
CLASS="INFORMALTABLE"
><P
></P
><A
NAME="AEN2036"
></A
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><COL><COL><COL><TBODY
><TR
><TD
>Title</TD
><TD
>Variable</TD
><TD
>Description</TD
></TR
><TR
><TD
>Add Notes</TD
><TD
>$g_add_bugnote_threshold</TD
><TD
>threshold to add an issue note</TD
></TR
><TR
><TD
>Update Notes</TD
><TD
>$g_update_bugnote_threshold</TD
><TD
>threshold to edit an issue note</TD
></TR
><TR
><TD
>Allow users to edit their own bugnotes</TD
><TD
>$g_bugnote_allow_user_edit_delete</TD
><TD
>can a user edit/delete their own issue notes</TD
></TR
><TR
><TD
>Delete Note</TD
><TD
>$g_delete_bugnote_threshold</TD
><TD
>threshold to delete an issue note</TD
></TR
><TR
><TD
>View private notes</TD
><TD
>$g_private_bugnote_threshold</TD
><TD
>threshold to view a private issue note</TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
></P
></DIV
><DIV
CLASS="FORMALPARA"
><P
><B
>Others. </B
>                <DIV
CLASS="INFORMALTABLE"
><P
></P
><A
NAME="AEN2066"
></A
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><COL><COL><COL><TBODY
><TR
><TD
>View Change Log</TD
><TD
>$g_view_changelog_threshold</TD
><TD
>threshold to view the changelog</TD
></TR
><TR
><TD
>View Assigned To</TD
><TD
>$g_view_handler_threshold</TD
><TD
>threshold to see who is handling an issue</TD
></TR
><TR
><TD
>View Issue History</TD
><TD
>$g_view_history_threshold</TD
><TD
>threshold to view the issue history</TD
></TR
><TR
><TD
>Send Reminders</TD
><TD
>$g_bug_reminder_threshold</TD
><TD
>threshold to send a reminder</TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
></P
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H4
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MANAGE.CONFIG.TRANSITIONS"
>6.8.5.2. Workflow Transitions</A
></H4
><P
>This page covers the status workflow. For most of these, the
                    fields are self explanatory and relate to a similarly named setting
                    in the configuration file. At the right of each row is a selector
                    that allows the administrator to lower the access level required to
                    change the particular parameter.The values changeable on this page
                    are:
                </P
><DIV
CLASS="TABLE"
><A
NAME="AEN2088"
></A
><P
><B
>Table 6-1. Issues</B
></P
><TABLE
BORDER="1"
CLASS="CALSTABLE"
><COL><COL><COL><TBODY
><TR
><TD
>Title</TD
><TD
>Variable</TD
><TD
>Description</TD
></TR
><TR
><TD
>Status to which a new issue is set</TD
><TD
>$g_bug_submit_status</TD
><TD
>status issue is set to when submitted</TD
></TR
><TR
><TD
>Status where an issue is considered resolved</TD
><TD
>$g_bug_resolved_status_threshold</TD
><TD
>status where issue is resolved</TD
></TR
><TR
><TD
>Status to which a reopened Issue is set</TD
><TD
>$g_bug_reopen_status</TD
><TD
>status issue is set to when reopened</TD
></TR
></TBODY
></TABLE
></DIV
><P
>                    The matrix that follows has checkmarks where the transitions are
                    allowed from the status on the left edge to the status listed
                    across the top. This corresponds to the $g_enum_workflow array.At
                    the bottom, there is a list of access levels that are required to
                    change the status to the value listed across the top. This can be
                    used, for instance, to restrict those who can close an issue to a
                    specific level, say a manager. This corresponds to the
                    $g_set_status_threshold array and the $g_report_bug_threshold
                    setting.
                </P
></DIV
><DIV
CLASS="SECTION"
><HR><H4
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MANAGE.CONFIG.EMAIL"
>6.8.5.3. Email Notifications</A
></H4
><P
>This page sets the system defaults for sending emails on
                    issue related events.  MantisBT uses flags and a threshold system to
                    generate emails on events. For each new event, email is sent to:
                    <P
></P
><UL
><LI
><P
>the reporter</P
></LI
><LI
><P
>the handler (or Assigned to)</P
></LI
><LI
><P
>anyone monitoring the issue</P
></LI
><LI
><P
>anyone who has ever added a issue note the issue</P
></LI
><LI
><P
>anyone assigned to the project whose access level matches
                                a range
                            </P
></LI
></UL
>
                    From this list, those recipients who meet the following criteria
                    are eliminated:
                    <P
></P
><UL
><LI
><P
>the originator of the change, if $g_email_receive_own is
                                OFF
                            </P
></LI
><LI
><P
>the recipient either no longer exists, or is
                                disabled
                            </P
></LI
><LI
><P
>the recipient has turned their email_on_&lt;new
                                status&gt; preference OFF
                            </P
></LI
><LI
><P
>the recipient has no email address extered</P
></LI
></UL
>
                    The matrix on this page selects who will receive messages for each
                    of the events listed down the left hand side. The first four
                    columns correspond to the first four points listed above. The next
                    columns correspond to the access levels defined. Note that because
                    a minimum and maximum threshold are used, a discontinuous selection
                    is not allowed.
                </P
></DIV
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.MONITOR"
>6.9. Monitor Issue</A
></H2
><P
>The monitor issues feature allows users to subscribe to
            certain issues and hence get copied on all notification emails that
            are sent for these issues.Depending on the configuration, sending a
            reminder to a user about an issue can add this issue to the user's
            list of monitored issues. Users who reported the issue or are assigned
            the issue typically don't need to monitor the issue to get the
            notifications. This is because by default they get notified on
            changes related to the issue anyway. However, administrators can
            change the configuration to disable notifications to reporters or
            handlers in specific scenarios.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.REOPEN"
>6.10. Reopen Issue</A
></H2
><P
>Re-open issue button is visible in the issue view pages if the
            user has the appropriate access level and the issue is
            resolved/closed. Re-opening a issue will allow users to enter
            issue notes for the re-opening reason. The issue will automatically be
            put into the Feedback status.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.DELETE"
>6.11. Delete Issue</A
></H2
><P
>The delete issues button appears on the issue view pages for the
            users who have the appropriate access level. This allows you to
            delete an existing issue. This should only be used on frivolous or
            test issues. A confirmation screen will prompt you if you really want
            to delete the issue. Updaters, Developers, Managers, and
            Administrators can remove issues (you can also configure
            this).
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.CLOSE"
>6.12. Close Issue</A
></H2
><P
>This is a button that appears on the issue view pages for
            users that are authorized to close issues. Depending on the
            configuration, users may be able to close issues without having to
            resolve them first, or may be able to only close resolved issues.
            After the button is clicked, the user is redirected to a page where
            an issue note maybe added.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.ASSIGNTOME"
>6.13. Assign to Me</A
></H2
><P
>This button appears in the issue view pages in case of users
            with access level that is equal to handle_bug_threshold or higher.
            When this button is clicked the issue is assigned to the
            user.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.RESOLVE"
>6.14. Resolve Issue</A
></H2
><P
>This option on the View Issues page allows you to resolve the
            issue. It will lead you to a page where you can set the resolution
            state and a duplicate id (if applicable). After choosing that the
            user can choose to enter an issue note detailing the reason for the
            closure. The issue is then set to the Resolved state. The reporter
            should check off on the issue by using the Close Issue button.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PAGES.NEWS"
>6.15. News Syndication</A
></H2
><P
>MantisBT supports news syndication using RSS v2.0 protocol.
            MantisBT also supports authenticated news feeds for private projects
            or installations where anonymous access is not enabled. Authenticated feeds takes a
            user name and a key token that are used to authenticate the user
            and generate the feed results in the context of the user's access
            rights (i.e. the same as what the user would see if they were to
            logged into MantisBT).To get access to the News RSS as anonymous
            user, visit the following
            page:&nbsp;http://www.example.com/mantisbt/news_rss.php&nbsp;While a
            user is logged in, the RSS links provided in the UI will always
            provide links to the authenticated feeds, if no user is logged in
            (i.e. anonymous), then anonymous links will be provided.
        </P
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.CUSTOMIZE."
></A
>Chapter 7. Customizing MantisBT</H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS"
>7.1. Custom Fields</A
></H2
><DIV
CLASS="SECTION"
><H3
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.OVERVIEW"
>7.1.1. Overview</A
></H3
><P
>Different teams typically like to capture different information
	as users report issues, in some cases, the data required is even
	different from one project to another.  Hence, MantisBT provides the
	ability for managers and administrators to define custom fields as way
	to extend MantisBT to deal with information that is specific to their
	teams or their projects.  The aim is for this to keep MantisBT native
	fields to a minimum.

	Following are some facts about the implementation of
        custom fields in MantisBT:
            <P
></P
><UL
><LI
><P
>Custom fields are defined system wide.</P
></LI
><LI
><P
>Custom fields can be linked to multiple
                        projects.
                    </P
></LI
><LI
><P
>The sequence of displaying custom fields can be different
                        per project.
                    </P
></LI
><LI
><P
>Custom fields must be defined by users with access level
                        ADMINISTRATOR.
                    </P
></LI
><LI
><P
>Custom fields can be linked to projects by users with
                        access level MANAGER or above (by default, this can be
                        configurable).
                    </P
></LI
><LI
><P
>Number of custom fields is not restricted.</P
></LI
><LI
><P
>Users can define filters that include custom fields.</P
></LI
><LI
><P
>Custom fields can be included in View Issues, Print
		    Issues, and CSV exports.</P
></LI
><LI
><P
>Enumeration custom fields can have a set of static
		    values or values that are calculated dynamically based on
		    a custom function.</P
></LI
></UL
>
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.DEFINITIONS"
>7.1.2. Custom Field Definition</A
></H3
><P
>            The definition of a custom field includes the following logical
            attributes:

            <P
></P
><UL
><LI
><P
>Caption variable name (eg: This is the value that is
                        supplied to lang_get() API, or displayed as-is if not found in
                        language file).  This should not include any space or
			any character that would be an invalid PHP identifier.
                    </P
></LI
><LI
><P
>Custom field type (string, numeric, float,
		    enumeration, email, checkbox, radio, list, multi-selection list, date).
                    </P
><P
>Type 'string' is used for strings of up to 255 characters.</P
><P
>Type 'numeric' is used for numerical integer values.</P
><P
>Type 'float' is used for real (float / double) numbers.</P
><P
>Type 'enumeration' is used when a user selects one entry from a list.  The user interface for such type is a combo-box.</P
><P
>Type 'email' is used for storing email addresses.</P
><P
>Type 'checkbox' is like enumeration but the list is shown as checkboxes and the user is allowed to tick more than one selection.  The default value and the possible value can contain multiple values like 'RED|YELLOW|BLUE' (without the single quote).</P
><P
>Type 'radio' is like enumeration but the list is shown as radio buttons and th euser is allowed to tick on of the options.  The possible values can be 'RED|YELLOW|BLUE', where the default value can be 'YELLOW'.  Note that the default value can't contain multiple values.</P
><P
>Type 'list' is like enumeration but the list is shown as a list box where the user is only allowed to select one option.  The possible values can be 'RED|YELLOW|BLUE', where the default value can be 'YELLOW'.  Note that the default value can't contain multiple values.</P
><P
>Type 'multi-selection list' is like enumeration but the list is shown as a list box where the user is allowed to select multiple options.  The possible values can be 'RED|YELLOW|BLUE', where the default value can be 'RED|BLUE'.  Note that in this case the default value contains multiple values.</P
><P
>Type 'date' is for date values.  The default value can be empty, or {tomorrow}, {yesterday}, {next week}, {last week}, {+3 days}, {-2 days}.</P
></LI
><LI
><P
>Enumeration possible values (eg: RED|YELLOW|BLUE).
                        Use the pipe ('|') character to separate possible values for an
                        enumeration. One of the possible values can be an
			empty string.  The set of possible values can also be
			calculated at runtime.  For example, "=versions" would
			automatically resolve into all the versions defined
			for the current project.
                    </P
></LI
><LI
><P
>Default value - see details above for a sample default value for each type.</P
></LI
><LI
><P
>Minimum/maximum length for the custom field value (use 0
                        to disable).  Note that these metrics are not really relevant to custom fields that are based on an enumeration of possible values.
                    </P
></LI
><LI
><P
>Regular expression to use for validating user input (use <A
HREF="http://www.php.net/manual/en/reference.pcre.pattern.syntax.php"
TARGET="_top"
>PCRE syntax</A
>).
                    </P
></LI
><LI
><P
>Read Access level: Minimum access level for users to be
                        able to see the value of the custom field.
                    </P
></LI
><LI
><P
>Write Access level: Minimum access level for users to be
                        able to edit the value of the custom field.
                    </P
></LI
><LI
><P
>Display when reporting issues? - If this custom
		    field should be shown on the Report Issue page.
                    </P
></LI
><LI
><P
>Display when updating issues? - If this custom
		    field should be shown on the Update Issue page.
                    </P
></LI
><LI
><P
>Display when resolving issues? - If this custom
		    field should be shown when resolving an issue.  For
		    example, a "root cause" custom field would make sense to
		    set when resolving the issue.
                    </P
></LI
><LI
><P
>Display when closing issues? - If this custom
		    field should be shown when closing an issue.
                    </P
></LI
><LI
><P
>Required on Report - If this custom
		    field is a mandatory field on the Report Issue page.
                    </P
></LI
><LI
><P
>Required on Update - If this custom
		    field is a mandatory field on the Update Issue page.
                    </P
></LI
><LI
><P
>Required on Resolve - If this custom
		    field is a mandatory field when resolving an issue.
                    </P
></LI
><LI
><P
>Required on Close - If this custom
		    field is a mandatory field when closing an issue.
                    </P
></LI
></UL
>
        </P
><P
>All custom fields are currently saved to a field of type
        VARCHAR(255) in the database. However, in future releases, it is
        possible to support custom fields of different types (eg: memo,
        file).</P
><P
>            If the value of a custom field for a certain defect is not found,
            the default value is assumed.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.EDITING"
>7.1.3. Adding/Editing Custom Fields</A
></H3
><P
>                <P
></P
><UL
><LI
><P
>The logged in user needs $g_manage_custom_fields_threshold
                            access level.
                        </P
></LI
><LI
><P
>Select "Manage" from the main menu.</P
></LI
><LI
><P
>Select "Manage Custom Fields" from the management
                            menu.
                        </P
></LI
><LI
><P
>In case of edit, click on the name of an existing
			custom field to edit its information.
                        </P
></LI
><LI
><P
>In case of adding a new one, enter the name of the
			new custom field then click "New Custom Field".
                        </P
></LI
></UL
>
            </P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>Added custom fields will not show up in any of the issues
	    until the added custom field is linked to the appropriate
	    projects.</P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.LINKING"
>7.1.4. Linking/Unlinking/Ordering Existing Custom Fields in Projects</A
></H3
><P
>                <P
></P
><UL
><LI
><P
>The logged in user needs to have access level that is
                            greater than or equal to $g_custom_field_link_threshold and
                            $g_manage_project_threshold.
                        </P
></LI
><LI
><P
>Select "Manage" from the main menu.</P
></LI
><LI
><P
>Select "Manage Projects".
                        </P
></LI
><LI
><P
>Select the name of the project to manage.</P
></LI
><LI
><P
>Scroll down to the "Custom Fields" box.</P
></LI
><LI
><P
>Select the field to add from the list, then click "Add
                            This Existing Custom Field".
                        </P
></LI
><LI
><P
>To change the order of the custom fields, edit the
                            "Sequence" value and click update. Custom fields with smaller
                            values are displayed first.
                        </P
></LI
><LI
><P
>To unlink a custom field, click on "Remove" link next to
                            the field.
                            Unlinking a custom field will not delete the values that are
                            associated with the issues for this field. These values are only
                            deleted if the custom field definition is removed (not unlinked!)
                            from the database. This is useful if you decide to re-link the
                            custom field. These values may also re-appear if issues are moved to
                            another project which has this field linked.
                        </P
></LI
></UL
>
            </P
><DIV
CLASS="FORMALPARA"
><P
><B
>Moving Issues. </B
>                When an issue is moved from one project to another, custom
                fields that are not defined for the new project are not deleted.
                These fields will re-appear with their correct values if the issue is
                moved back to the original project, or if these custom fields are
                linked to the new project.
            </P
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.LOCALIZE"
>7.1.5. Localizing Custom Field Names</A
></H3
><P
>It is possible to localize the label for the custom fields.
	    This can be as follows:

	        <P
></P
><UL
><LI
><P
>Give the custom field a valid variable name
		    (i.e. start with an alpha character, no spaces, etc) - For
		    example, we will use "my_start_date" for a custom field of
		    type "Date" which stores the "Start Date" for working on an
		    issue.</P
></LI
><LI
><P
>Add the localized string for "my_start_date"
		    - This can be done by creating custom_strings_inc.php in the
		    MantisBT root folder and adding the following code to it:
<PRE
CLASS="PROGRAMLISTING"
>&lt;?php
if ( lang_get_current() == 'german' ) {
    $s_my_start_date = 'Start Date XX';  // German translation of Start Date
} else {
    # Default (use your preferred language as the default)
    $s_my_start_date = 'Start Date';
}
?&gt;</PRE
></P
></LI
></UL
>
	    </P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>If we would have decided to use start_date as the
	    name of the custom field, then we have used an already localized
	    string from MantisBT standard strings.  In this case, there is no
	    need to create the custom_strings_inc.php or to add any strings to
	    it.  To check for standard strings, inspect
	    lang/strings_english.txt.</P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.DEFAULTS"
>7.1.6. Dynamic default values</A
></H3
><DIV
CLASS="SECTION"
><H4
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.DEFAULTS.DATE"
>7.1.6.1. Dynamic defaults for Date fields</A
></H4
><P
>Custom fields of type date can be defaulted to a specific dates or to relative dates.  Typically relative dates is the scenario that makes sense in most of the cases.  The format for specific dates is an integer which indicates the number of seconds since the Unix Epoch (January 1 1970 00:00:00 GMT), which is the format consumed by the PHP <A
HREF="http://www.php.net/date"
TARGET="_top"
>date()</A
> method.  The relative scenario expects default values like {tomorrow}, {yesterday}, {+2 days}, {-3 days}, {next week}, etc.  The curly brackets indicate that this is a logical value which is then evaluated using the PHP <A
HREF="http://www.php.net/strtotime"
TARGET="_top"
>strtotime()</A
> function.</P
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.DYNAMIC"
>7.1.7. Dynamic values for Enumeration Custom Fields</A
></H3
><P
>As discussed earlier, one of the possible types of a custom
	    field is "enumeration".  This type of custom field allows the user
	    to select one value from a provided list of possible values.  The
	    standard way of defining such custom fields is to provide a '|'
	    separated list of possible values.  However, this approach has two
	    limitations: the list is static, and the maximum length of the list
	    must be no longer than 255 characters.  Hence, the need for the
	    ability to construct the list of possible values dynamically.</P
><DIV
CLASS="SECTION"
><HR><H4
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.DYNAMIC.DEFAULT"
>7.1.7.1. Dynamic possible values included by default</A
></H4
><P
>MantisBT ships with some dynamic possible values, these
	    include the following:

	    	<P
></P
><UL
><LI
><P
>=categories - a list of categories defined
		    in the current project (or the project to which the issue
		    belongs).</P
></LI
><LI
><P
>=versions - a list of all versions defined
		    in the current project (or the project to which the issue
		    belongs).</P
></LI
><LI
><P
>=future_versions - a list of all versions that
		    belong to the current project with
		    released flag set to false.</P
></LI
><LI
><P
>=released_versions - a list of all versions
		    that belong to the current project with released flag set to
		    true.</P
></LI
></UL
>
	    </P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
>The '=' before the name of the dynamic list of options is used
	    to tell MantisBT that this is a dynamic list, rather than a static
	    list with just one option.</P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H4
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFIELDS.DYNAMIC.CUSTOM"
>7.1.7.2. Defining Custom Dynamic Possible Values</A
></H4
><P
>If the user selects =versions, the actual custom function
		that is executed is custom_function_*_enum_versions(). The reason
		why the "enum_" is not included is to have a fixed prefix for all
		custom functions used for this purpose and protect against users
		using custom functions that were not intended for this purpose.
		For example, you don't want the user to use
		custom_function_*_issue_delete_notify() which may be overridden
		by the web master to delete associated data in other
		databases.</P
><P
>Following is a sample custom function that is used to
		populate a field with the categories belonging to the currently
		selected project:

<PRE
CLASS="PROGRAMLISTING"
># --------------------
# Construct an enumeration for all categories for the current project.
# The enumeration will be empty if current project is ALL PROJECTS.
# Enumerations format is: "abc|lmn|xyz"
# To use this in a custom field type "=categories" in the possible values field.
function custom_function_override_enum_categories() {
    $t_categories = category_get_all_rows( helper_get_current_project() );

    $t_enum = array();
    foreach( $t_categories as $t_category ) {
        $t_enum[] = $t_category['category'];
    }

    $t_possible_values = implode( '|', $t_enum );

    return $t_possible_values;
}</PRE
></P
><P
>Notice the following:

<P
></P
><UL
><LI
><P
>The custom function doesn't take any
	parameters.</P
></LI
><LI
><P
>The custom function returns the possible values in the
	format (A|B|C).</P
></LI
><LI
><P
>The custom function uses the current
	project.</P
></LI
><LI
><P
>The custom function builds on top of the already
	existing APIs.</P
></LI
></UL
></P
><P
>To define your own function \u201c=mine\u201d, you will have to define it
with the following signature:

<PRE
CLASS="PROGRAMLISTING"
># --------------------
# To use this in a custom field type "=mine" in the possible values field.
function custom_function_override_enum_mine() {
    $t_enum = array();

    :

    $t_possible_values = implode( '|', $t_enum );

    return $t_possible_values;
}</PRE
></P
><P
>Notice "override" in the function name. This is because this method is
defined by the MantisBT adminstrator/webmaster and not part of the MantisBT source.
It is OK to override a method that doesn't exist.</P
><P
>As usual, when MantisBT is upgraded to future releases, the custom functions
will not be overwritten. The difference between the "default" implementation and
the "override" implementation is explained in more details in the custom
functions section.</P
></DIV
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.ENUMS"
>7.2. Enumerations</A
></H2
><P
>Enumerations are used in MantisBT to represent a set of
            possible values for an attribute. Enumerations are used for access
            levels, severities, priorities, project statuses, project view
            state, reproducibility, resolution, ETA, and projection.  MantisBT
            provides the administrator with the flexibility of altering the
            values in these enumerations. The rest of this topic explains how
            enumerations work, and then how they can be customised.
        </P
><DIV
CLASS="FORMALPARA"
><P
><B
>How enumerations work? </B
>                <TT
CLASS="FILENAME"
>core/constant_inc.php</TT
> defines the
                constants that correspond to those in the enumeration. These are
                useful to refer to these enumerations in the configs and the code.
                <PRE
CLASS="PROGRAMLISTING"
>                    define( 'VIEWER', 10 )
                    define( 'REPORTER', 25 )
                    define( 'UPDATER',  40 )
                    define( 'DEVELOPER', 55 )
                    define( 'MANAGER', 70 )
                    define( 'ADMINISTRATOR', 90 )
                </PRE
>
            </P
></DIV
><P
>            <TT
CLASS="FILENAME"
>config_defaults_inc.php</TT
> includes the defaults for the
            enumerations. The configuration options that are defaulted here are
            used in specifying which enumerations are active and should be used
            in MantisBT.  However, the strings included in the enumerations here
            are just for documentation purpose, they are not shown to the user
            (due to the need for localisation). Hence, if an entry in this
            enumeration is not found in the corresponding localised enumeration
            (i.e. 70:manager), then it will be printed to the user as @70@.

            <PRE
CLASS="PROGRAMLISTING"
>                $g_access_levels_enum_string =
                '10:viewer,25:reporter,40:updater,55:developer,70:manager,90:administrator';
            </PRE
>
        </P
><P
>            <TT
CLASS="FILENAME"
>lang/strings_german.txt</TT
> provide the
            localised strings (in this case, in german) for enumerations. But again, the master list is
            the enumeration in the configs, the ones in the language files are
            just used for finding the localised equivalent for an entry. Hence,
            if a user changes the config to have only two types of users
            developers and administrators, then only those will be prompted to
            the users even if the enumerations in the language files still
            includes the full list.
            <PRE
CLASS="PROGRAMLISTING"
>&#13;                $s_access_levels_enum_string =
                '10:Betrachter,25:Reporter,40:Updater,55:Entwickler,70:Manager,90:Administrator';
            </PRE
>
        </P
><DIV
CLASS="FORMALPARA"
><P
><B
>How can they be customised? </B
>Let say we want to remove access level
                "Updater" and add access level "Senior
                Developer".
            </P
></DIV
><P
>            The file <TT
CLASS="FILENAME"
>custom_constants_inc.php</TT
> is supported for the
            exclusive purpose of allowing administrators to define their own
            constants while maintaining a simple upgrade path for future
            releases of MantisBT. Note that this file is not distributed with
            MantisBT and you will need to create it if you need such
            customisation. In our example, we need to define a constant for the
            new access level.
            <PRE
CLASS="PROGRAMLISTING"
>                define ( 'SENIOR_DEVELOPER', 60 );
            </PRE
>
        </P
><P
>            In <TT
CLASS="FILENAME"
>config_inc.php</TT
>
            <PRE
CLASS="PROGRAMLISTING"
>                // Remove Updater and add Senior Developer
                $g_access_levels_enum_string =
                '10:viewer,25:reporter,55:developer,60:senior_developer,70:manager,90:administrator';
                // Give access to Senior developers to create/delete custom field.
                $g_manage_custom_fields_threshold = SENIOR_DEVELOPER;
            </PRE
>
        </P
><P
>            The file <TT
CLASS="FILENAME"
>custom_strings_inc.php</TT
> is introduced for a similar reason
            to that of custom_constants_inc.php, which is to define custom
            strings. The advantage of defining them here is to provide a simple
            upgrade path, and avoid having to re-do the changes when upgrading
            to the next MantisBT release. Note that you will need to create this
            file if you need such customisation. The file is automatically
            detected and included by MantisBT code.
            <PRE
CLASS="PROGRAMLISTING"
>                # Note that we don't have to remove the Updater entry from the
                localisation file if ( lang_get_current() === 'english' ) {
                $s_access_levels_enum_string =
                '10:Betrachter,25:Reporter,40:Updater,55:Entwickler,60:Senior
                Developer,70:Manager,90:Administrator'; }
            </PRE
>
        </P
><DIV
CLASS="FORMALPARA"
><P
><B
>Conclusion. </B
>We have covered how enumerations work in general, and how
                to customise one of them. If you are interested in customising
                other enumerations, a good starting point would be to go to "MantisBT
                Enum Strings" section in config_defaults_inc.php. This section
                defines all enumerations that are used by MantisBT.
                For versions that are older than 0.18.0, custom_*_inc.php files are
                not supported, and hence you will need to change in the actual
                constants / language files directly.
            </P
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.EMAIL"
>7.3. Email Notifications</A
></H2
><P
>See Email in the Configuration section.</P
><P
>Examples:
            <P
></P
><UL
><LI
><P
>Notify only managers of new issues.
                        <PRE
CLASS="PROGRAMLISTING"
>                            $g_notify_flags['new']['threshold_min'] = MANAGER;
                            $g_notify_flags['new']['threshold_max'] = MANAGER;
                        </PRE
>
                    </P
></LI
><LI
><P
>Notify Developers and managers of all project events,
                        except, exclude developers from the 'closed' events.
                        <PRE
CLASS="PROGRAMLISTING"
>$g_default_notify_flags['threshold_min'] = DEVELOPER;
                            $g_default_notify_flags['threshold_max'] = MANAGER;
                            $g_notify_flags['closed']['threshold_max'] = MANAGER;
                            $g_notify_flags['closed']['threshold_max'] = MANAGER;
                        </PRE
>
                    </P
></LI
><LI
><P
>Exclude those who contributed issue notes from getting
                        messages about other changes in the issue.
                        <PRE
CLASS="PROGRAMLISTING"
>$g_default_notify_flags['bugnotes'] = OFF;</PRE
>
                    </P
></LI
><LI
><P
>Exclude those monitoring issues from seeing the 'closed'
                        message
                        <PRE
CLASS="PROGRAMLISTING"
>$g_notify_flags['closed']['monitor'] = OFF;</PRE
>
                    </P
></LI
><LI
><P
>Only notify developers when issue notes are added.
                        <PRE
CLASS="PROGRAMLISTING"
>$g_notify_flags['bugnote']['threshold_min'] = DEVELOPER;
                            $g_notify_flags['bugnote']['threshold_max'] = DEVELOPER;
                        </PRE
>
                    </P
></LI
><LI
><P
>Notify managers of changes in sponsorship.
                        <PRE
CLASS="PROGRAMLISTING"
>$g_notify_flags['sponsor']['threshold_max'] = MANAGER;
                            $g_notify_flags['sponsor']['threshold_max'] = MANAGER;
                        </PRE
>
                    </P
></LI
><LI
><P
>Notify originator and managers of changes in ownership
                        ("Assigned To:").
                        <PRE
CLASS="PROGRAMLISTING"
>$g_notify_flags['owner']['threshold_max'] = MANAGER;
                            $g_notify_flags['owner']['threshold_max'] = MANAGER;
                            $g_notify_flags['owner']['reporter'] = ON;
                        </PRE
>
                    </P
></LI
><LI
><P
>I'm paranoid about mail. Only send information on issues
                        to those involved in them. Don't send mail people already know
                        about. Also send new issue notifications to managers so they can
                        screen them.
                        <PRE
CLASS="PROGRAMLISTING"
>$g_mail_receive_own = OFF;
                            $g_default_notify_flags =
                            array('reporter' =&gt; ON, 'handler' =&gt; ON, 'monitor' =&gt; ON,
                            'bugnotes' =&gt; ON, 'threshold_min' =&gt; NOBODY, 'threshold_max'
                            =&gt; NOBODY);
                            $g_notify_flags['new']['threshold_min'] = MANAGER;
                            $g_notify_flags['new']['threshold_max'] = MANAGER;
                        </PRE
>
                    </P
></LI
><LI
><P
>How do I replace the $g_to_email configuration variable
                        to log all messages to an email logger.
                    </P
><P
>You will need to create a
                        dummy user with the appropriate access level for the notices you
                        want to log. Once this user is added to projects, they will receive
                        mail using the appropriate rules.
                    </P
></LI
></UL
>
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.STATUS"
>7.4. Customizing Status Values</A
></H2
><P
>The default is no workflow, where all states
            are accessible from any others. The following example can be
            transferred to config_inc.php. The workflow needs to have a path
            from the statuses greater than or equal to the resolved state back
            to the feedback state. Otherwise, the re-open operation won't work.
            <PRE
CLASS="PROGRAMLISTING"
>$g_status_enum_workflow[NEW_]=
                '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,80:resolved';
                $g_status_enum_workflow[FEEDBACK] =
                '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,80:resolved';
                $g_status_enum_workflow[ACKNOWLEDGED] =
                '20:feedback,30:acknowledged,40:confirmed,50:assigned,80:resolved';
                $g_status_enum_workflow[CONFIRMED] =
                '20:feedback,40:confirmed,50:assigned,80:resolved';
                $g_status_enum_workflow[ASSIGNED] =
                '20:feedback,50:assigned,80:resolved,90:closed';
                $g_status_enum_workflow[RESOLVED] =
                '50:assigned,80:resolved,90:closed';
                $g_status_enum_workflow[CLOSED] = '50:assigned';
            </PRE
>
        </P
><P
>To add a status:
            <P
></P
><OL
TYPE="1"
><LI
><P
>Define a constant to map the new status to.In a new file
                        custom_constants_inc.php in the main mantisbt directory:
                        <PRE
CLASS="PROGRAMLISTING"
>&lt;?php define ( 'TEST', 60 ); ?&gt;</PRE
>
                    </P
></LI
><LI
><P
>Define the language strings required. This may need to be
                        defined in several languages.In a new file custom_strings_inc.php
                        in the main mantisbt directory:
                        <PRE
CLASS="PROGRAMLISTING"
>&lt;?php if ( lang_get_current() == 'german' ) {
                            $s_status_enum_string =
                            '10:neu,20:R&cedil;ckmeldung,30:anerkannt,40:best&permil;tigt,50:zugewiesen,
                            60:zu testen,80:behoben,90:geschlossen'; } else {
                            $s_status_enum_string =
                            '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned, 60:to
                            be tested,80:resolved,90:closed'; $s_to_be_tested_bug_button =
                            "Issue Ready to Test"; $s_to_be_tested_bug_title = "Set Issue Ready
                            to Test"; $s_email_notification_title_for_status_bug_to_be_tested =
                            "The following issue is ready TO BE TESTED."; } ?&gt;
                        </PRE
>
                    </P
></LI
><LI
><P
>Define any configurations required.In the existing file
                        config_inc.php in the main mantisbt directory:
                        <PRE
CLASS="PROGRAMLISTING"
>$g_status_enum_string =
                            '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned, 60:to
                            be tested,80:resolved,90:closed'; # Status color additions
                            $g_status_colors['to be tested'] = '#ACE7AE';
                        </PRE
>
                    </P
></LI
><LI
><P
>Add the status to any workflow defined.In config_inc.php:
                        <PRE
CLASS="PROGRAMLISTING"
>$g_status_enum_workflow[NEW_]=
                            '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,60:to
                            be tested'; $g_status_enum_workflow[FEEDBACK] =
                            '10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,60:to
                            be tested'; $g_status_enum_workflow[ACKNOWLEDGED] =
                            '20:feedback,30:acknowledged,40:confi rmed,50:assigned,60:to be
                            tested'; $g_status_enum_workflow[CONFIRMED] =
                            '20:feedback,40:confirmed,50:assigned,60:to be tested';
                            $g_status_enum_workflow[ASSIGNED] = '20:feedback,50:assigned,60:to
                            be tested,90:closed'; $g_status_enum_workflow[TEST] =
                            '10:new,20:feedback,50:assigned,60:to be
                            tested,80:resolved,90:closed'; $g_status_enum_workflow[RESOLVED] =
                            '50:assigned,60:to be tested,80:resolved,90:closed';
                            $g_status_enum_workflow[CLOSED] = '50:assigned,90:closed';
                        </PRE
>
                    </P
></LI
></OL
>
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFUNCS"
>7.5. Custom Functions</A
></H2
><P
>Custom functions are used to extend the functionality of
                MantisBT by integrating user writtenfunctions into the issue
                processing at strategic places. This allows the system
                administrator to changethe functionality without re-writing parts
                of the internals of the code.
            </P
><P
>User versions of these functions are
                placed in a file called custom_functions_inc.php in the
                root directory of MantisBT. This is the same place that the
                "config_inc.php" file modifying MantisBT defaults is placed. In normal
                processing, MantisBT will look for override functions and execute
                them instead of the provided default functions.</P
><P
>Custom functions have
                    names like custom_function_override_descriptive_name where
                    descriptive namedescribed the particular function. The specific
                    functions are described below. The simplest way tocreate a custom
                    function is to copy the default function, named
                    custom_function_default_descriptive_namefrom the
                    core/custom_function_api.php file to your override file
                    (custom_functions_inc.php), andrename it. The specific
                    functionality you need can then be coded into the override
                    function.
            </P
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFUNCS.DEFINED"
>7.5.1. Defined Functions</A
></H3
><P
>custom_function_default_changelog_include_issue( $p_issue_id
                    ) returns true or false if the issue if to be included in the
                    Changelogcustom_function_default_changelog_print_issue( $p_issue_id
                    ) returns a formatted string to be included for the issue in the
                    Changelogcustom_function_default_checkin( $p_issue_id, $p_comment,
                    $p_file, $p_new_version ) registers a checkin in source control in
                    MantisBT custom_function_default_issue_update_validate( $p_issue_id,
                    $p_new_bug, $p_bug_note_text ) validate issue field settings before
                    an update occurs. It returns true or fails with an
                    error.custom_function_default_issue_update_notify( $p_issue_id )
                    notify after an issue has been
                    updatedcustom_function_default_issue_create_validate( $p_new_bug )
                    validate issue field settings before an issue is created. It returns
                    true or fails with an
                    error.custom_function_default_issue_create_notify( $p_issue_id )
                    notify after an issue has been
                    openedcustom_function_default_issue_delete_validate( $p_issue_id )
                    validate issue field settings before an issue can be deleted. It
                    returns true or fails with an
                    error.custom_function_default_issue_delete_notify( $p_issue_id )
                    notify after an issue has been deleted
                </P
></DIV
><DIV
CLASS="SECTION"
><HR><H3
CLASS="SECTION"
><A
NAME="ADMIN.CUSTOMIZE.CUSTOMFUNCS.EXAMPLE"
>7.5.2. Example Custom Function</A
></H3
><P
>The following function is used to validate an issue before
                    it is resolved.
                    <PRE
CLASS="PROGRAMLISTING"
>&#60;?php
# --------------------
# Hook to validate Validate field settings before resolving
# verify that the resolution is not set to OPEN
# verify that the fixed in version is set (if versions of the product exist)

function custom_function_override_issue_update_validate( $p_issue_id, $p_bug_data, $p_bugnote_text ) {
if ( $p_bug_data-&#62;status == RESOLVED ) {
if ( $p_bug_data-&#62;resolution == OPEN ) {
error_parameters( 'the resolution cannot be open to resolve the issue' );
trigger_error( ERROR_BUG_VALIDATE_FAILURE, ERROR );
}
$t_version_count = count( version_get_all_rows( $p_bug_data-&#38;gt;project_id ) );
if ( ( $t_version_count &#62; 0 ) &#38;&#38; ( $p_bug_data-&#62;fixed_in_version == '' ) ) {
error_parameters( 'fixed in version must be set to resolve the issue' );
trigger_error( ERROR_BUG_VALIDATE_FAILURE, ERROR );
}
}
}
?&#62;
                    </PRE
>
                    The errors will also need to be defined by adding the following to <TT
CLASS="FILENAME"
>custom_constants_inc.php</TT
>
                    <PRE
CLASS="PROGRAMLISTING"
>                        define ( 'ERROR_VALIDATE_FAILURE', 2000 );
                        To custom_strings_inc.php
                        $MANTIS_ERROR['ERROR_VALIDATE_FAILURE'] = 'This change cannot be made because %s';
                    </PRE
>
                </P
></DIV
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.AUTH"
></A
>Chapter 8. Authentication</H1
><P
>MantisBT supports several authentication techniques out of the box.  In addition, there is work in progress relating to supporting authentication plug-ins.  Once authentication plug-ins are implemented, then authentication against any protocol or repository of user names and passwords can be done without having to touch MantisBT core code.</P
><P
>Although MantisBT supports multiple authentication techniques, it is important to note that MantisBT doesn't yet support hybrid authentication scenarios.  For example, internal staff authentications against LDAP where customer authentications against MantisBT database.</P
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.AUTH.STANDARD"
>8.1. Standard Authentication</A
></H2
><P
>Standard, or native, authentication is where MantisBT users are authenticated against user records in the MantisBT database.  The passwords are stored in the database in one of several formats:
            <P
></P
><UL
><LI
><P
>CRYPT - deprecated.</P
></LI
><LI
><P
>CRYPT_FULL_SALT - deprecated.</P
></LI
><LI
><P
>PLAIN - deprecated.</P
></LI
><LI
><P
>MD5 - This is default and recommended approach.  See <A
HREF="http://en.wikipedia.org/wiki/MD5"
TARGET="_top"
>MD5 topic on Wikipedia</A
> for more details.</P
></LI
></UL
>
        </P
><P
>See $g_login_methods for more details about how to configure MantisBT to use one of the above authentication techniques.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.AUTH.HTTP"
>8.2. HTTP_AUTH</A
></H2
><P
>When MantisBT is configured to use basic auth, it automatically detects the logged in user and checks if they are already registered in MantisBT, if not, then a new account is automatically created for the username.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.AUTH.BASIC"
>8.3. BASIC_AUTH</A
></H2
><P
>TODO</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.AUTH.LDAP"
>8.4. LDAP</A
></H2
><P
>Functionality is provided by using the php-ldap module
            (/usr/lib/php4/ldap.so). An extra login method is defined within
            core/user_API.php inside of function is_password_match $f_username,
            $p_test_password, $p_password ).This has a simple, non encrypted
            (yet) test of the LDAP directory for that user by asking for an
            entry with uid=username and password=test_password, if this exists,
            it is presumed that the user should be granted access.</P
><DIV
CLASS="FORMALPARA"
><P
><B
>Configuration basics. </B
>the LDIF format that was tested is as follows:
                    <PRE
CLASS="PROGRAMLISTING"
>dn: uid=tests,
                        dc=test, dc=com, dc=au
                        department: testdep
                        organizationname: Testing Organization
                        cn: Test Smith
                        assignedgroup: users
                        givename: Test
                        sn: Smith
                        mail: tests@example.com.au
                        uid: testsuser
                        Password: password
                        objectclass: testPerson
                    </PRE
>

                    The password may be in clear, taken
                    from the /etc/passwd or /etc/shadow file, or simply encrypted and
                    added using current LDAP tools.There are some specialized software
                    for replicating passwd to LDAP and inversely (eg.
                    <A
HREF="http://freshmeat.net/projects/cpu/"
TARGET="_top"
>http://freshmeat.net/projects/cpu/</A
>
                    ).
                </P
></DIV
><P
>Also setup the LDAP parameters explained in the
                <A
HREF="#ADMIN.CONFIG.AUTH"
>Authentication</A
>
                section. Don't forget to change your $g_login_method to
                LDAP.
            </P
><DIV
CLASS="FORMALPARA"
><P
><B
>Creating new accounts. </B
>There is still a bit of problem when you
                    want to create a new user to MantisBT using LDAP, you must create the
                    LDIF entry to LDAP, and also sign up for a new account, if both of
                    these line up correctly, authentication will proceed.  Email
                    is queried from the LDAP database if the
                    authentication is set to use LDAP instead of the user record in the
                    database entry.</P
></DIV
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.AUTH.MSAD"
>8.5. Microsoft Active Directory</A
></H2
><P
>TODO</P
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.PROJECT"
></A
>Chapter 9. Project Management</H1
><P
>This section covers the project management features of MantisBT.  This includes features like change log, roadmap, time tracking, reporting and others.</P
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PROJECT.CHANGELOG"
>9.1. Change Log</A
></H2
><P
>MantisBT doesn't just track the status of issues, it also relates issues to versions.  Each project can have several versions, which are marked with attributes like released and obsolete.  Users typically report issues against released issues and developers typically fix issues in not released versions.  With every new release comes question like: what's new?  what has been fixed?  Customers wonder if the new release is of interest to them and whether they should take an upgrade.  Well, the change log is specifically tailored to answer these kind of questions.</P
><P
>In order for an issue to show up in the change log, it has to satisfy certain criteria.  The criteria is that the issue has to be resolved with a 'fixed' resolution and has to have the 'fixed_in_version' field set.  Users sometimes wonder why resolved or closed issues don't show up in the change log, and the answer is that the 'fixed_in_version' field is not set.  Without the 'fixed_in_version', it is not possible for MantisBT to include the issues in the appropriate section of the changelog.  Note that it is possible to set the 'fixed_in_version' for multiple issues using the 'Update Fixed in Version' group action on the View Issues page (just below the issues list).  This option is only available when the selected project is not 'All Projects'.  Once a version is marked as obsolete, it is now longer included in the change log.</P
><P
>MantisBT also provides the ability to customize the criteria used for an issue to be included in the change log.  For example, for installations that use a custom set of resolutions, it is possible to select multiple resolutions as valid candidates for the change log.  This can be done using custom functions (see custom functions documentation for more details).  The custom function below overrides the MantisBT default behavior to include issues with both FIXED and IMPLEMENTED (a custom resolution) resolutions in the change log.

<PRE
CLASS="PROGRAMLISTING"
># --------------------
# Checks the provided bug and determines whether it should be included in the changelog
# or not.
# returns true: to include, false: to exclude.
function custom_function_override_changelog_include_issue( $p_issue_id ) {
    $t_issue = bug_get( $p_issue_id );

    return ( ( $t_issue-&#62;resolution == FIXED || $t_issue-&#62;resolution == IMPLEMENTED ) &#38;&#38;
        ( $t_issue-&#62;status &#62;= config_get( 'bug_resolved_status_threshold' ) ) );
}</PRE
>
        </P
><P
>MantisBT also provides the ability to customize the details to include from the issue and in what format.  This can be done using the following custom function.

<PRE
CLASS="PROGRAMLISTING"
># --------------------
# Prints one entry in the changelog.
function custom_function_override_changelog_print_issue( $p_issue_id, $p_issue_level = 0 ) {
    $t_bug = bug_get( $p_issue_id );

    if ( $t_bug-&#62;category_id ) {
        $t_category_name = category_get_name( $t_bug-&#62;category_id );
    } else {
        $t_category_name = '';
    }

    $t_category = is_blank( $t_category_name ) ? '' : '&lt;b&gt;[' . $t_category_name . ']&lt;/b&gt; ';
    echo str_pad( '', $p_issue_level * 6, '&nbsp;' ), '- ', string_get_bug_view_link( $p_issue_id ), ': ', $t_category, string_display_line_links( $t_bug-&#62;summary );

    if ( $t_bug-&#62;handler_id != 0 ) {
        echo ' (', prepare_user_name( $t_bug-&#62;handler_id ), ')';
    }

    echo ' - ', get_enum_element( 'status', $t_bug-&#62;status ), '.&lt;br /&gt;';
}</PRE
>
        </P
><P
>By combining both customization features, it is also possible to do more advanced customization scenarios.  For example, users can add a 'ChangelogSummary' custom field and include all issues that have such field in the change log.  Through customizing what information being included for a qualifying issue, users can also include the 'ChangelogSummary' text rather than the native summary field.</P
><P
>In some cases, users know that they fixed an issue and that the fix will be included in the next release, however, they don't know yet the name of the release.  In such case, the recommended approach is to always have a version defined that corresponds to the next release, which is typicalled called 'Next Release'.  Once the release is cut and has a concrete name, then 'Next Release' can be renamed to the appropriate name and a new 'Next Release' can then be created.  For teams that manage releases from multiple branches for the same project, then more than one next release can be possible.  For example, 'Next Dev Release' and 'Next Stable Release'.</P
><P
>Another common requirement is to be able to link to the change log of a specific project from the project's main website.  There is a variety of ways to do that:
            <P
></P
><UL
><LI
><P
>To link to the changelog of version "ver1" of project "myproject":
						<PRE
CLASS="PROGRAMLISTING"
>						http://www.example.com/mantisbt/changelog_page.php?project=myproject&amp;version=ver1
						</PRE
>
	                </P
></LI
><LI
><P
>To link to the changelog of all non-obsolete versions of project 'myproject':
						<PRE
CLASS="PROGRAMLISTING"
>						http://www.example.com/mantisbt/changelog_page.php?project=myproject
						</PRE
>
                	</P
></LI
><LI
><P
>To link to the changelog of project with id 1.  The project id can be figured out by going to the management page for the project and getting the value of project_id field form the URL.  
						<PRE
CLASS="PROGRAMLISTING"
>						http://www.example.com/mantisbt/changelog_page.php?project_id=1
						</PRE
>
                	</P
></LI
><LI
><P
>To link to the changelog of version with id 1.  The version id is unique accross all projects and hence in this case it is not necessary to include the project id/name.  The version id can be figured out by going to the manage project page and editing the required version.  The version_id will be included in the URL.
						<PRE
CLASS="PROGRAMLISTING"
>						http://www.example.com/mantisbt/changelog_page.php?version_id=1
						</PRE
>
                	</P
></LI
></UL
>
        </P
><P
>Another approach is to go to the project page and from there users can get to multiple other locations relating to the project include the change log.  This can be done by a URL like the following:
<PRE
CLASS="PROGRAMLISTING"
>http://www.example.com/mantisbt/project_page.php?project_id=1</PRE
>
        </P
><P
>It is possible to customize the access level required for viewing the change log page.  This can be done using the $g_view_changelog_threshold configuration option.</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PROJECT.ROADMAP"
>9.2. Roadmap</A
></H2
><P
>            One of the very important scenarios in project management is where the project managers (or team leads) triage the issues to set their priorities, target version, and possibly assign the issues to specific developers or take other actions on the issue.  By setting the target version of an issue to a version that is not yet released, the issue shows up on the project roadmap, providing user with information about when to expect the issues to be resolved.  The roadmap page has a section for each release showing information like planned issues, issues done and percentage of issues completed.  Issues that are fixed in a specific version, but didn't have the target_version field set, will not show up in the roadmap.  This allows the ability to control the issues that are significant enough to show in the roadmap, while all resolved fields can be found in the change log.  Note that it is possible to set the 'target_version' for multiple issues using the 'Update Target Version' group action that is available through the View Issues page (below the issues list).  This option is only available when the current project is not 'All Projects'.  Although it is not a typical scenario, it is worth mentioning that once a version is marked as obsolete, it is not included in the roadmap.
        </P
><P
>            Note that the roadmap only includes future versions, once a version is marked as released, it no longer is included in the roadmap.  For information about such releases, the change log feature should be used.  For an issue to be shown on the roadmap, it has to have the target version set.  It does not matter whether the feature is resolved or not.  Resolved features will be decorated with a strikethrough and will be counted as done.
        </P
><P
>            MantisBT provides the ability to customize the criteria for issues to show up on the roadmap.  The default criteria is that the issue has to belong to a version that is not yet released and that the issues is not a duplicate.  However, such criteria can be customized by using custom functions as below.

<PRE
CLASS="PROGRAMLISTING"
># --------------------
# Checks the provided bug and determines whether it should be included in the roadmap or not.
# returns true: to include, false: to exclude.
function custom_function_override_roadmap_include_issue( $p_issue_id ) {
    return ( true );
}</PRE
>
        </P
><P
>            It is also possible to customize the details included about an issues and the presentation of such details.  This can be done through the following custom function:

<PRE
CLASS="PROGRAMLISTING"
># --------------------
# Prints one entry in the roadmap.
function custom_function_override_roadmap_print_issue( $p_issue_id, $p_issue_level = 0 ) {
    $t_bug = bug_get( $p_issue_id );

    if ( bug_is_resolved( $p_issue_id ) ) {
        $t_strike_start = '&lt;strike&gt;';
        $t_strike_end = '&lt;/strike&gt;';
    } else {
        $t_strike_start = $t_strike_end = '';
    }

    if ( $t_bug-&#62;category_id ) {
        $t_category_name = category_get_name( $t_bug-&#62;category_id );
    } else {
        $t_category_name = '';
    }

    $t_category = is_blank( $t_category_name ) ? '' : '&lt;b&gt;[' . $t_category_name . ']&lt;/b&gt; ';

    echo str_pad( '', $p_issue_level * 6, '&nbsp;' ), '- ', $t_strike_start, string_get_bug_view_link( $p_issue_id ), ': ', $t_category, string_display_line_links( $t_bug-&#62;summary );

    if ( $t_bug-&#62;handler_id != 0 ) {
        echo ' (', prepare_user_name( $t_bug-&#62;handler_id ), ')';
    }

    echo ' - ', get_enum_element( 'status', $t_bug-&#62;status ), $t_strike_end, '.&lt;br /&gt;';
}</PRE
>
        </P
><P
>            Some teams manage different branches for each of their projects (e.g. development and maintenance branches).  As part of triaging the issue, they may decide that an issue should be targetted to multiple branches.  Hence, frequently the request comes up to be able to target a single issue to multiple releases.  The current MantisBT approach is that an issues represents an implementation or a fix for an issue on a specific branch.  Since sometimes applying and verifying a fix to the two branches does not happen at the same time and in some cases the approach for fixing an issue is different based on the branch.  Hence, the way to manage such scenario is to have the main issue for the initial fix and have related issues which capture the work relating to applying the fix to other branches.  The issues for porting the fix can contain any discussions relating to progress, reflect the appropriate status and can go through the standard workflow process independent of the original issues.
        </P
><P
>Another common requirement is to be able to link to the roadmap of a specific project from the project's main website.  There is a variety of ways to do that:
            <P
></P
><UL
><LI
><P
>To link to the roadmap of version "ver1" of project "myproject":
						<PRE
CLASS="PROGRAMLISTING"
>						http://www.example.com/mantisbt/roadmap_page.php?project=myproject&amp;version=ver1
						</PRE
>
	                </P
></LI
><LI
><P
>To link to the roadmap of all non-obsolete versions of project 'myproject':
						<PRE
CLASS="PROGRAMLISTING"
>						http://www.example.com/mantisbt/roadmap_page.php?project=myproject
						</PRE
>
                	</P
></LI
><LI
><P
>To link to the roadmap of project with id 1.  The project id can be figured out by going to the management page for the project and getting the value of project_id field form the URL.  
						<PRE
CLASS="PROGRAMLISTING"
>						http://www.example.com/mantisbt/roadmap_page.php?project_id=1
						</PRE
>
                	</P
></LI
><LI
><P
>To link to the roadmap of version with id 1.  The version id is unique accross all projects and hence in this case it is not necessary to include the project id/name.  The version id can be figured out by going to the manage project page and editing the required version.  The version_id will be included in the URL.
						<PRE
CLASS="PROGRAMLISTING"
>						http://www.example.com/mantisbt/roadmap_page.php?version_id=1
						</PRE
>
                	</P
></LI
></UL
>
        </P
><P
>Another approach is to go to the project page and from there users can get to multiple other locations relating to the project include the roadmap.  This can be done by a URL like the following:
<PRE
CLASS="PROGRAMLISTING"
>http://www.example.com/mantisbt/project_page.php?project_id=1</PRE
>
        </P
><P
>            The access level required to view and modify the roadmap can be configured through $g_roadmap_view_threshold  and $g_roadmap_update_threshold respectively.  Modifying the roadmap is the ability to set the target versions for issues.  Users who have such access can set the target versions while reporting new issues or by updating existing issues.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PROJECT.TIMETRACKING"
>9.3. Time Tracking</A
></H2
><P
></P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PROJECT.GRAPHS"
>9.4. Graphs</A
></H2
><P
>Assigned to me: TODO</P
><P
>Release Delta: TODO</P
><P
>Category: TODO</P
><P
>Severity: TODO</P
><P
>Severity / Status: TODO</P
><P
>Daily Delta: TODO</P
><P
>Reported by Me: TODO</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.PROJECT.SUMMARY"
>9.5. Summary Page</A
></H2
><P
>By Status: TODO</P
><P
>By Severity: TODO</P
><P
>By Category: TODO</P
><P
>Time Stats for Resolved Issues (days): TODO</P
><P
>Developer Status: TODO</P
><P
>Reporter by Resolution: TODO</P
><P
>Developer by Resolution: TODO</P
><P
>By Date: TODO</P
><P
>Most Active: TODO</P
><P
>Longest Open: TODO</P
><P
>By Resolution: TODO</P
><P
>By Priority: TODO</P
><P
>Reporter Status: TODO</P
><P
>Reporter Effectiveness: TODO</P
></DIV
></DIV
><DIV
CLASS="CHAPTER"
><HR><H1
><A
NAME="ADMIN.CONTRIBUTING"
></A
>Chapter 10. Contributing to MantisBT</H1
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONTRIBUTING.DEVELOP"
>10.1. Talent and Time</A
></H2
><P
>	     One of the greatest ways to contribute to MantisBT is to contribute
	     your talent and time. For MantisBT to keep growing we need such support
	     in all areas related to the software development cycle. This includes:
	     business analysts, developers, web designers, graphics designers,
	     technical writers, globalization developers, translators, testers,
	     super users, packagers and active users. If you would like to
	     contribute in any of these capacities please contact us through the
	     "Contact Us" page.
        </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONTRIBUTING.SHARE"
>10.2. Recommend MantisBT to Others</A
></H2
><P
>	    It feels great when we get feedback from the user community about
	    how MantisBT boosted their productivity, and benefited their organization.
	    A lot of the feedback I get is via email, some on mailing lists, and some
	    on forums. I would encourage such users to blog about it, tell their
	    friends about MantisBT, and recommend MantisBT to other organizations.
	    MantisBT is driven by it's community, the greater the community, the
	    greater the ideas, the greater of a product it becomes.
	</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONTRIBUTING.BLOG"
>10.3. Blog about MantisBT</A
></H2
><P
>	     If you have a blog, then blog about MantisBT, review it's features
	     and help us spread the word.  A lot of users also like to blog
	     about how they customized MantisBT to fit their needs or to
	     integrate with other tools that they use in their work environment.
	 </P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONTRIBUTING.INTEGRATE"
>10.4. Integrate with MantisBT</A
></H2
><P
>	    If you have a product that can be integrates with MantisBT to provide
	    a value for MantisBT users, that would be a great place to contribute
	    and benefit both your project's community and the MantisBT community.
	    A great examples in this area are integrations with content management
	    systems (e.g. *Nuke, Xoops), project management (PHPProjekt), and
	    TestLink for Test Management. MantisBT can easily be integrated with
	    projects in any programming language whether it is hosted on the same
	    webserver or anywhere else in the world. This can be achieved through
	    it's SOAP API and MantisConnect client libraries. MantisConnect comes
	    with client libraries and samples in languages like PHP, .NET, Java and
	    Cocoa.
	</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONTRIBUTING.REGISTER"
>10.5. Registered in MantisBT Users Directory</A
></H2
><P
>	    Join the <A
HREF="http://www.mantisbt.org/directory.php"
TARGET="_top"
>Users
	    Directory</A
> by clicking Submit. While entering your company or
	    project details you will be able to write up a testimonial about
	    MantisBT which will then be included in the <A
HREF="http://www.mantisbt.org/testimonials.php"
TARGET="_top"
>Testimonials
	    page</A
>.
	</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONTRIBUTING.DONATE"
>10.6. Donate Money</A
></H2
><P
>	    Use the PayPal donate buttons that you will see around the website
	    (e.g. bottom left of the home page).  You can donate using your
	    credit card even if you don't have a PayPal account. Donations is
	    a very easy way for the MantisBT community to give back to MantisBT.
	    The donations can be as small as US$1 or as big as you or your organization
	    want it to be.
	</P
></DIV
><DIV
CLASS="SECTION"
><HR><H2
CLASS="SECTION"
><A
NAME="ADMIN.CONTRIBUTING.SPONSOR"
>10.7. Sponsor MantisBT</A
></H2
><P
>	    MantisBT Sponsors are organizations that have realized the benefit
	    brought to their business by using MantisBT and would like to
	    protect such investment and always push it forward via sponsorship.
	    Please take a moment to visit our sponsors page and use the "Contact
	    Us" page for further information.
        </P
></DIV
></DIV
><DIV
CLASS="COLOPHON"
><HR><H1
><A
NAME="CREDITS"
></A
>Acknowledgements</H1
><P
><B
>Acknowledgements</B
></P
><P
>We would like to thank all the past and present contributors to the
    project:</P
><P
></P
><UL
><LI
><P
>name</P
></LI
><LI
><P
>name</P
></LI
><LI
><P
>name</P
></LI
><LI
><P
>name</P
></LI
></UL
></DIV
></DIV
></BODY
></HTML
>
