4.1. Post-Installation Checklist
After installation, follow the checklist below to ensure that + you have a successful installation. If you do not see a + recommended setting for a parameter, consider leaving it at the + default while you perform your initial tests on your Bugzilla + setup. +
Bring up "editparams.cgi" in your web browser. For + instance, to edit parameters at mozilla.org, the URL would + be http://bugzilla.mozilla.org/editparams.cgi, also + available under the "edit parameters" link on your query + page. +
Set "maintainer" to your email address. + This allows Bugzilla's error messages to display your email + address and allow people to contact you for help. +
Set "urlbase" to the URL reference for your Bugzilla + installation. If your bugzilla query page is at + http://www.foo.com/bugzilla/query.cgi, your url base is + http://www.foo.com/bugzilla/ +
Set "usebuggroups" to "on" only if you + need to restrict access to products. I suggest leaving this + parameter off while initially testing + your Bugzilla. +
Set "usebuggroupsentry" to "on" if you want to restrict + access to products. Once again, if you are simply testing + your installation, I suggest against turning this parameter + on; the strict security checking may stop you from being + able to modify your new entries. +
Set "shadowdb" to "bug_shadowdb" if you will be running a + *very* large installation of Bugzilla. The shadow database + enables many simultaneous users to read and write to the + database without interfering with one another. +
Once again, in testing you should avoid this option + -- use it if or when you need to use + it, and have repeatedly run into the problem it was designed + to solve -- very long wait times while attempting to commit + a change to the database. +Enabling "shadowdb" can adversely affect the stability + of your installation of Bugzilla. You may frequently + need to manually synchronize your databases, or schedule + nightly syncs via "cron" +
If you use the "shadowdb" option, it is only natural that + you should turn the "queryagainstshadowdb" option "On" as + well. Otherwise you are replicating data into a shadow + database for no reason! +
If you have custom logos or HTML you must put in place to + fit within your site design guidelines, place the code in + the "headerhtml", "footerhtml", "errorhtml", "bannerhtml", + or "blurbhtml" text boxes. +
+The "headerhtml" text box is the HTML printed out + before any other code on the page. + If you have a special banner, put the code for it in + "bannerhtml". You may want to leave these settings at + the defaults initially. +
Add any text you wish to the "passwordmail" parameter box. + For instance, many people choose to use this box to give a + quick training blurb about how to use Bugzilla at your site. +
Ensure "newemailtech" is "on". Your users will thank you. + This is the default in the post-2.12 world, and is only an + issue if you are upgrading. +
Do you want to use the QA Contact ("useqacontact") and + status whiteboard ("usestatuswhiteboard") fields? These + fields are useful because they allow for more flexibility, + particularly when you have an existing Quality Assurance + and/or Release Engineering team, but they may not be needed + for smaller installations. +
Set "whinedays" to the amount of days you want to let bugs + go in the "New" or "Reopened" state before notifying people + they have untouched new bugs. If you do not plan to use + this feature, simply do not set up the whining cron job + described in the installation instructions, or set this + value to "0". +
Set the "commenton" options according to your site policy. + It is a wise idea to require comments when users resolve, + reassign, or reopen bugs. +
+It is generally far better to require a developer + comment when resolving bugs than not. Few things are + more annoying to bug database users than having a + developer mark a bug "fixed" without any comment as to + what the fix was (or even that it was truly fixed!) +
Set "supportwatchers" to "On". This feature is helpful for + team leads to monitor progress in their respective areas, + and can offer many other benefits, such as allowing a + developer to pick up a former engineer's bugs without + requiring her to change all the information in the bug. +