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 "1" only - if you need to restrict access to products. - I suggest leaving this parameter off - while initially testing your Bugzilla. -
Set "usebuggroupsentry" to "1" 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. -
Note: 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. -
Note: 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 README, 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. -
Note: 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. -