maintainer : Le paramètre « maintainer » est l'adresse électronique de la personne chargée de maintenir cette installation Bugzilla. Il n'est pas nécessaire que l'adresse soit celle d'un compte Bugzilla valide.

urlbase : Ce paramètre indique à votre installation Bugzilla le nom de domaine entier et le chemin du serveur web.

Par exemple, si votre page de requête Bugzilla est http://www.foo.com/bugzilla/query.cgi, fixez votre paramètre « urlbase » à http://www.foo.com/bugzilla/.

makeproductgroups : permet de créer automatiquement ou pas des groupes quand des produits nouveaux sont créés.

useentrygroupdefault : Les produits de Bugzilla peuvent avoir un groupe associé, si bien que certains utilisateurs ne voient des bogues que dans certains produits. Quand ce paramètre a pour valeur « on », cela peut provoquer le fait que les commandes du groupe initial sur les produits fraîchement créés placent immédiatement tous les bogues fraîchement générés dans le groupe ayant le même nom que le produit. Après la création initiale d'un produit, les commandes du groupe peuvent être réglées plus précisément sans interférence avec le mécanisme.

shadowdb : Un problème intéressant se pose quand Bugzilla atteint un niveau élevé d'activité en continu. MySQL supporte uniquement le verrouillage en écriture au niveau des tables. Cela signifie que, si quelqu'un doit apporter une modification à un bogue, il devra verrouiller la table tout entière jusqu'à la fin de l'opération. Le verrouillage en écriture bloque également la lecture jusqu'à ce que l'écriture soit terminée. Notez que des versions plus récentes de mysql acceptent le verrouillage des lignes en utilisant différents types de tables. Ces types sont plus lents que le type standard, et Bugzilla ne bénéficie pas encore des fonctionnalités comme les transactions qui justifieraient une diminution de la vitesse. L'équipe Bugzilla espère bien avoir des informations sur toute expérience relative au verrouillage des lignes et à Bugzilla.

Le paramètre « shadowdb » a été conçu pour contourner cette limitation. Alors qu'un seul utilisateur est autorisé à écrire dans la table à un moment donné, la lecture peut continuer sans difficulté sur une copie fantôme en lecture seule de la base de donnée. Bien que votre base de données sera deux fois plus volumineuse, une base de donnée fantôme peut apporter une énorme amélioration des performances quand elle est implémentée sur des bases de données Bugzilla à gros trafics.

À titre indicatif, sur du matériel relativement ancien, mozilla.org n'a pas eu besoin de « shadowdb » avant d'arriver à environ 40000 utilisateurs de Bugzilla avec plusieurs centaines de modifications et de commentaires sur les bogues de Bugzilla par jour.

La valeur du paramètre définit le nom de la base de données fantôme contenant les bogues. Vous aurez besoin de configurer les paramètres de l'hôte et du port depuis la page paramètres, et de configurer une copie sur votre serveur de base de données de manière à ce que les mises à jour atteignent le miroir en lecture seul. Consultez la documentation de votre base de données pour plus d'informations.

shutdownhtml : Si vous devez éteindre Bugzilla pour des tâches d'administration, tapez un texte descriptif (en langage HTML imbriqué, si vous voulez) dans ce champ. Chaque personne qui essayera d'utiliser Bugzilla (y compris les administrateurs) recevra une page affichant ce texte. Les utilisateurs ne peuvent ni se connecter ni se déconnecter tant que shutdownhtml est activé.

Note

Bien que les possibilités habituelles de connexion soient désactivées tant que 'shutdownhtml' est activé, des protections sont mises en place pour protéger l'administrateur malchanceux qui perd sa connexion à Bugzilla. Si cela vous arrive, allez directement à editparams.cgi (en tapant le lien manuellement si nécessaire). Vous serez alors invité à vous connecter, et là (mais nulle part ailleurs) votre nom d'utilisateur/mot de passe seront acceptés.

passwordmail : Chaque fois qu'un utilisateur crée un compte, le contenu de ce paramètre (avec des adaptations) ainsi que son mot de passe lui est envoyé.

Ajoutez le texte que vous souhaitez dans le champ du paramètre « passwordmail ». Par exemple, beaucoup de personnes utilisent ce champ pour donner de rapides indications sur la façon d'utiliser Bugzilla sur leur site.

movebugs : Cette option est une fonctionnalité non documentée permettant de déplacer les bogues entre des installations Bugzilla distinctes. Vous aurez besoin de comprendre le code source pour utiliser cette fonctionnalité. Veuillez consulter movebugs.pl dans votre arborescence de fichiers Bugzilla pour davantage d'informations, comme il se doit.

useqacontact : Permet de définir une adresse électronique pour chaque composant, en plus de celle du propriétaire par défaut, à laquelle seront envoyées des copies des nouveaux bogues.

usestatuswhiteboard : Ce paramètre indique si vous souhaitez un champ réinscriptible de forme libre associé à chaque bogue. L'avantage du « Status Whiteboard » est qu'il peut être supprimé ou modifié aisément, et qu'il fournit un champ interrogeable facilement pour l'indexation des bogues qui ont des traits en commun.

whinedays : Fixez ce paramètre au nombre de jours que vous souhaitez laisser les bogues à l'état « NEW » ou « REOPENED » avant de signaler aux personnes concernées qu'elles ont des bogues non traités. Si vous ne pensez pas utiliser cette fonctionnalité, il suffit tout simplement de ne pas installer la fonction cron de rappel (« whining cron ») comme cela est décrit dans les instructions d'installation, ou de fixer la valeur à « 0 » (aucun rappel).

commenton* : Tous ces champs vous permettent de signaler quelles modifications ne nécessitent pas de commentaires et celles qui doivent être commentées par leur auteur. Souvent, les administrateurs autorisent les utilisateurs à s'ajouter eux-mêmes à la liste des copies, à accepter des bogues, ou à changer le « Status Whiteboard » sans ajouter de commentaires sur les raisons du changement, et exigent cependant que la plupart des autres changements soient accompagnés d'une explication.

Remplissez les options « commenton » conformément à la politique de votre site. Au minimum, il est bon de demander des commentaires quand les utilisateurs résolvent, réassignent ou rouvrent des bogues.

	Note
	Il est généralement préférable de demander le commentaire du développeur quand il résout un bogue. Il n'y pas grand chose de plus agaçant pour les utilisateurs de base de données de bogues que de rencontrer un bogue marqué comme « fixed » par un développeur sans aucun commentaire sur la nature de la réparation (ou même pour indiquer qu'il a vraiment été réparé !).

supportwatchers : Activer cette option permet aux utilisateurs de demander à recevoir des copies de tous les messages électroniques concernant un bogue particulier d'un autre utilisateur. Observer un utilisateur avec des permissions de groupe différentes ne permet pas pour autant de 'contourner' le système; les messages copiés restent toujours soumis aux permissions de groupe normales sur un bogue, et les « observateurs » seront seulement en copie sur des courriels provenant de bogues qu'ils seraient normalement autorisés à voir.

noresolveonopenblockers : Cette option évitera aux utilisateurs de résoudre des bogues considérés comme RESOLVED [FIXED] s'ils ont des dépendances non résolues. Seule la résolution FIXED est affectée. Les utilisateurs seront toujours en mesure de passer les bogues à une résolution autre que CORRIGES s'ils ont des bogues de dépendances non résolues.