Test de la version installée : perl -v

Toute machine qui ne possède pas Perl est une machine bien malheureuse. Si vous ne l'avez pas et que votre système d'exploitation ne fournit pas de paquetages officiels, allez sur http://www.perl.com. Bien que Bugzilla fonctionne avec Perl 5.6.0, c'est une bonne idée d'utiliser la dernière version stable. Au moment où ces lignes sont écrites, c'est Perl 5.8.3.

Test de la version installée : mysql -V

Si vous ne l'avez pas et que votre système d'exploitation ne fournit pas de paquetages officiels, allez sur http://www.mysql.com. Vous avez besoin de MySQL version 3.23.41 ou supérieure.

Note

De nombreuses versions binaires de MySQL stockent leurs fichiers de données dans le répertoire /var. Sur certains systèmes UNIX, ce répertoire se trouve dans la partition principale (root). Si celle-ci est trop petite, il peut ne pas y avoir assez de place pour contenir la base de données des bogues. Pour changer le répertoire de données, vous devez compiler MySQL vous-même à partir des sources, et le mettre comme option à configure.

Si vous installez à partir d'autre chose qu'un packaging/installation du système, comme un .rpm (Paquetage Redhat), .deb (Paquetage Debian), .exe (Executable Windows) ou .msi (Installateur Microsoft), assurez vous que le serveur MySQL soit lancé au démarrage de la machine.

Test de la version installée : regardez la page de bienvenue par défaut à http://<votre-machine>/

Là, vous avez le choix, à peu près tous les serveurs web capables de faire fonctionner les scripts CGI conviennent. Cependant, nous recommandons fortement d'utiliser le serveur web Apache (soit 1.3.x ou 2.x), et les instructions d'installation supposent généralement que vous l'employez. Si vous avez Bugzilla qui fonctionne en utilisant un autre serveur web, n'hésitez pas à partager votre expérience avec nous en utilisant la procédure de soumission de bogues dans Bugzilla Documentation.

Si vous n'avez pas Apache et que votre système d'exploitation ne fournit pas de paquetage officiel, allez sur http://httpd.apache.org/.

Téléchargez une archive tar Bugzilla (ou jetez un œil sur CVS) et placez la dans un répertoire approprié, accessible par l'utilisateur du serveur web par défaut (probablement « apache » ou « www »). Le mieux est de la mettre soit directement dans l'espace web principal de votre ou peut être dans /usr/local avec un lien symbolique provenant de l'espace web.

	Attention
	La distribution Bugzilla par défaut n'est PAS conçue pour être placée dans un répertoire cgi-bin. Ceci est valable pour chaque répertoire configuré à l'aide de l'instruction du ScriptAlias d'Apache.

Une fois que tous les fichiers sont dans un répertoire accessible du web, faites en sorte que le répertoire soit accessible en écriture pour votre utilisateur du serveur web. Il s'agit là d une étape provisoire en attendant de lancer le script checksetup.pl, ce qui terminera votre installation.

Le processus d'installation de Bugzilla s'appuie sur un script nommé checksetup.pl. vérifie en premier lieu si vous avez les bonnes versions de tous les modules Perl obligatoires. Cette section a pour but de mener à bien cette vérification. Lorsque que c'est le cas, ne l'exécutez pas à nouveau, mais passez à Section 2, « Configuration ».

À ce stade, vous devez vous identifier comme administrateur (vous connecter en tant que root). Il vous faudra poursuivre la totalité de l'installation comme administrateur. Ensuite exécutez :

bash# ./checksetup.pl

checksetup.pl va imprimer une liste de modules de Perl obligatoires et optionnels, en même temps que les versions (si il y en a) installés sur votre machine. La liste des modules obligatoires est relativement longue; cependant, vous pouvez déjà en avoir plusieurs d'installés.

Il y a un méta-module nommé Bundle::Bugzilla, qui installe tous les autres modules avec une simple commande. Vous devriez l'utiliser si vous installez Perl 5.6.1 ou une version au dessus.

Le mode préféré pour installer des modules de Perl est via CPAN sur UNIX, ou PPM sur Windows (voir Section 4.1.2, « Perl Modules on Win32 »). Ces instructions supposent que vous utilisez CPAN ; si pour une raison ou une autre vous devez installer les modules de Perl manuellement, consultez Annexe D, Installation manuelle des modules Perl.

bash# perl -MCPAN -e 'install "<modulename>"'

Si vous utilisez Bundle::Bugzilla, invoquez la commande magique CPAN. Sinon, vous devez parcourir la liste des modules que checksetup.pl dit être obligatoires, dans l'ordre donné, en invoquant la commande pour chacun d'eux.

Astuce

Beaucoup d'utilisateurs se plaignent que les modules Perl ne s'installent pas chez eux. La plupart du temps, les messages d'erreur indiquent ne pas trouver un fichier dans « @INC ». À chaque fois ou presque, cette erreur se déclare soit parce que vous n'avez pas les droits suffisants pour compiler les modules Perl, soit parce que les bibliothèques de développement de Perl nécessaires ne sont pas installées sur votre système. Demandez à votre administrateur UNIX de vous accorder les droits d'accès suffisants. Si vous êtes l'administrateur UNIX, veuillez consulter le forum ou la liste de diffusion pour une aide plus poussée, ou faites appel à quelqu'un pour vous aider.

Voici une liste complète de modules et de leur version minimum. Quelques modules ont des notes d'installation spéciales; celles-ci sont indiquées juste après.

Modules Perl obligatoires :

Modules Perl facultatifs :

1.5.3. GD (1.20)

Le module GD n'est nécessaire que si vous voulez des rapports graphiques.

	Note
	Le module Perl GD nécessite d'autres bibliothèques qui peuvent ou non être installées sur votre système, telles que libpng et libgd. La liste complète des bibliothèques nécessaires se trouve dans le fichier README du module Perl GD. Si la compilation de GD échoue, c'est probablement parce qu'il manque une des bibliothèques demandées.

	Astuce
	La version du module GD dont vous avez besoin est très étroitement liée à la version de libgd installée sur votre système. Si vous avez une version 1.x de libgd, les versions 2.x du module GD ne fonctionneront pas chez vous.

Bugzilla s'appuie sur la possibilité d'accès à un système de messagerie électronique pour son authentification utilisateur et pour d'autres tâches.

Sous Linux, tout MTA compatible avec Sendmail suffira. Sendmail, Postfix, qmail et Exim font partie des MTA courants. Sendmail est le MTA d'origine d'UNIX, mais les autres sont plus faciles à configurer, ce qui fait que beaucoup de personnes remplacent Sendmail par Postfix ou Exim. Le remplacement se fait sous forme d'échange standard, si bien que Bugzilla ne fera pas la différence entre eux.

Si vous utilisez Sendmail, la version 8.7 ou supérieure est nécessaire. Si vous utilisez un MTA compatible avec Sendmail, il doit être conforme au minimum à la version 8.7 de Sendmail.

Consultez les instructions d'installation détaillées dans le manuel correspondant au MTA que vous choisissez. Chacun de ces programmes aura son propre fichier de configuration où vous devrez configurer certains paramètres pour vous assurez que le message électronique est transmis correctement. Ils sont exécutés comme utilitaires, et vous devez vous assurer que le MTA est dans la liste de démarrage automatique des utilitaires de la machine.

Si un simple message électronique envoyé avec la ligne de commande mail fonctionne, alors Bugzilla devrait également être opérationnel.

Dès que vous exécutez checksetup.pl avec tous les bons modules installés, il affiche un message concernant un fichier nommé localconfig qu'il crée. Ce fichier contient les réglages par défaut pour un certain nombre de paramètres de Bugzilla.

Chargez ce fichier dans votre éditeur. La seule valeur que vous devez changer est $db_pass, mot de passe utilisateur que vous allez créer pour votre base de données. Tapez à cet endroit le mot de passe adéquate (pour simplifier, il ne devrait pas contenir le caractère « guillemet unique ») que vous avez choisi.

Les commentaires fournis dans le fichier localconfig donnent des informations sur les autres options. Si vous avez une installation de MySQL légèrement non standard, vous aurez la possibilité de changer un ou plusieurs des autres paramètres « $db_* ».

Si vous le souhaitez, vous pouvez changer le nom des priorités, les niveaux de gravité, les systèmes d'exploitation et les plates-formes pour votre installation. Cependant, vous pouvez toujours changer tout ça après que l'installation soit finie ; si vous re-exécutez checksetup.pl, les changements seront mis à jour.

Ensuite, réexécutez checksetup.pl. Il reconfirme que tous les modules sont présents et fait remarquer que le fichier localconfig a changé, qu'il considère comme ayant été édité à votre satisfaction. Il compile les modèles UI [User Interface templates], se connecte à la base de données en utilisant l'utilisateur « bugs » que vous avez créé et le mot de passe que vous avez défini et il crée la base de données de « bugs » et les tables incluses.

Après cela, il demande des informations sur un compte administrateur. Bugzilla peut avoir plusieurs administrateurs — vous pouvez encore en créer d'autres plus tard — mais il en a besoin d'un pour commencer. Entrez l'adresse de courrier électronique d'un administrateur, son nom complet et un mot de passe Bugzilla approprié.

checksetup.pl a maintenant fini. Vous pouvez réexécuter checksetup.pl quand vous le souhaitez.

Configurez votre serveur web selon les instructions données dans la section appropriée. (Si cela peut influencer votre choix, l'équipe de Bugzilla recommande Apache.) Quel que soit le serveur web que vous utilisez, cependant, faites en sorte que les informations sensibles ne soient pas disponibles à distance en appliquant correctement les contrôles d'accès indiqués dans Section 3.1, « Désactivation des accès à distance pour les fichiers de configuration Bugzilla ».

  AddHandler cgi-script .cgi

Options +ExecCGI +FollowSymLinks
AllowOverride Limit

2.4.2. Internet Information Services™ de Microsoft

Si vous êtes en train d'exécuter Bugzilla sous Windows et que vous choisissez d'utiliser Internet Information Services™ ou Personal Web Server™ de Microsoft, vous devrez exécuter un certain nombre d'autres étapes de configuration comme expliqué ci-dessous. Vous aurez peut-être également besoin de consulter les articles suivants de la base de connaissance de Microsoft : 245225 « HOW TO: Configure and Test a PERL Script with IIS 4.0, 5.0, and 5.1 » (pour Internet Information Services™) (N.D.T. : « HOW TO : configurez et testez un script PERL avec IIS 4.0, 5.0 et 5.1 ») et 231998 « HOW TO: FP2000: How to Use Perl with Microsoft Personal Web Server on Windows 95/98 » (pour Personal Web Server™) (N.D.T. : « HOW TO : FP2000 : Perl utilisation avec serveur Web personnel Microsoft sous Windows 95/98 »).

Vous aurez besoin de créer un répertoire virtuel pour l'installation de Bugzilla. Mettez les fichiers de Bugzilla dans un répertoire dont le nom est différent du répertoire que vous voulez rendre accessible à l'utilisateur final. C'est-à-dire, si vous voulez que vos utilisateurs accèdent à l'installation de Bugzilla par « http://<lenomdevotredomaine>/Bugzilla », ne mettez pas les fichiers de Bugzilla dans un répertoire appelé « Bugzilla ». Mettez les plutôt dans un endroit différent, puis utilisez l'outil d'administration de IIS pour créer un répertoire virtuel appelé « Bugzilla » qui joue le rôle d'alias pour l'emplacement réel des fichiers. En créant ce fichier virtuel, assurez vous que vous avez ajouté les droits d'accès « Execute (comme les applications ISAPI ou CGI) ».

Vous devrez aussi dire à IIS comment s'y prendre avec les fichiers .cgi de Bugzilla. Utilisez de nouveau l'outil d'administration de IIS, ouvrez les propriétés pour le nouveau répertoire virtuel et choisissez l'option de configuration pour accéder aux scripts d'applications [Script Mapping]. Créez une entrée d'application .cgi à l'adresse :

<chemin complet vers perl.exe >\perl.exe -x<chemin complet vers Bugzilla> -wT "%s" %s
        

Par exemple :

c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s
        

	Note
	L'installation d'ActiveState peut avoir déjà créé une entrée pour les fichiers .pl qui est limitée à « GET,HEAD,POST ». Si c'est le cas, cette application doit être supprimée car les fichiers .pl de Bugzilla ne sont pas conçus pour être exécutés via un serveur web.

IIS devra également savoir que l'index.cgi doit être traité comme un document par défaut. Sur la page onglets de Documents des propriétés du répertoire virtuel, vous devez ajouter index.cgi comme type de document par défaut. Si vous le voulez, vous pouvez effacer les autres types de document par défaut de ce répertoire virtuel particulier, puisque Bugzilla n'utilise aucun d'eux.

De plus, et on ne le soulignera jamais assez, assurez-vous que les fichiers tels que localconfig et votre répertoire data sont sécurisés comme décrit dans Section 3.1, « Désactivation des accès à distance pour les fichiers de configuration Bugzilla ».

2.4.3. Serveur AOL

Ben FrantzDale que l'utilisation du serveur AOL avec Bugzilla a donné d'excellents résultats. Il a fait part de son expérience et celle-ci nous permet de proposer ce qui suit.

Le serveur AOL devra être configuré pour pouvoir exécuter les scripts CGI, veuillez consulter la documentation qui va avec votre serveur pour plus d'information sur la façon de procéder.

Parce que les serveurs AOL ne supportent pas les fichiers .htaccess, vous devrez créer un script TCL. Vous devrez créer un aolserver/modules/tcl/filter.tcl (le nom du fichier sera sans importance) avec le contenu suivant (remplacez /bugzilla/ par le chemin web de votre instance Bugzilla) :

  ns_register_filter preauth GET /bugzilla/localconfig filter_deny
  ns_register_filter preauth GET /bugzilla/localconfig~ filter_deny
  ns_register_filter preauth GET /bugzilla/\#localconfig\# filter_deny
  ns_register_filter preauth GET /bugzilla/*.pl filter_deny
  ns_register_filter preauth GET /bugzilla/syncshadowdb filter_deny
  ns_register_filter preauth GET /bugzilla/runtests.sh filter_deny
  ns_register_filter preauth GET /bugzilla/data/* filter_deny
  ns_register_filter preauth GET /bugzilla/template/* filter_deny

  proc filter_deny { why } {
      ns_log Notice "filter_deny"
      return "filter_return"
  }
        

	Avertissement
	Ceci ne fonctionne probablement pas pour tous les fichiers de sauvegarde d'éditeur possibles alors vous aurez peut-être envie d'ajouter quelques variations supplémentaires de localconfig. Pour plus d'informations, voyez le bogue 186383 ou Bugtraq ID 6501.

	Note
	Si vous utilisez le logiciel webdot depuis research.att.com (la configuration par défaut pour le paramètre webdotbase), vous devrez autoriser l'accès à data/webdot/*.dot pour la machine reasearch.att.com. Si vous utilisez une installation locale de GraphViz, vous devrez autoriser tout le monde à accéder aux *.png, *.gif, *.jpg et *.map dans le répertoire data/webdot.

Votre Bugzilla devrait maintenant fonctionner. Allez sur http://<your-bugzilla-server>/ — vous devriez voir la page d'accueil de Bugzilla. Si ce n'est pas le cas, consultez la section Dépannage, Annexe B, Résolution des problèmes.

Identifiez vous avec le compte administrateur que vous avez défini lors de la dernière exécution de checksetup.pl. Vous devriez parcourir les options sur la page « Edit Parameters » (le lien est en bas de page) et voir s'il n'y en pas certaines que vous aimeriez changer. Les options importantes sont documentées dans Section 1, « Configuration de Bugzilla »; vous devrez certainement modifier maintainer et urlbase; vous pouvez aussi modifier cookiepath ou requirelogin.

Cela pourrait être l'occasion de refaire un tour sur le fichier localconfig et de vous assurer que les noms des priorités, degrés de gravité [severities], plate-formes et systèmes d'exploitation sont ceux que vous souhaitez utiliser quand vous commencez à créer un bug. N'oubliez pas de réexécuter checksetup.pl si vous changez ce dernier.

Bugzilla a plusieurs options facultatives qui nécessitent des configurations supplémentaires. Vous pouvez vous documenter à ce sujet dans Section 3, « Configuration supplémentaire facultative ».

Si vous avez installé les modules Perl nécessaires, vous pouvez commencer à collecter des statistiques pour les superbes graphes Bugzilla.

bash# crontab -e

Ceci devrait afficher le fichier crontab dans votre éditeur. Ajoutez une entrée « cron » comme ceci pour exécuter collectstats.pl tous les jours à minuit 5 :

5 0 * * * cd <your-bugzilla-directory> ; ./collectstats.pl

Deux jours après, vous pourrez visualiser les graphiques de bogues depuis la page de rapport de bogue.

	Note
	Windows n'a pas de 'cron', mais il a un planificateur de tâches, qui fournit les mêmes fonctions. Il y a également des outils conçus par des tiers qui peuvent être utilisés pour exécuter cron, tels que nncron.

Tout comme les arborescences de dépendance en mode texte, Bugzilla permet également des aperçus graphiques, en utilisant un logiciel appelé « dot ». C'est le paramètre webdotbase qui en assure précisément le fonctionnement ; il peut prendre l'une de ces trois valeurs :

La façon la plus simple de le faire fonctionner est d'installer GraphViz. Dans ce cas, vous devez activer les cartes d'image côté serveur dans Apache. Autrement, vous pouvez installer un serveur webdot ou utiliser le serveur public webdot AT&T. C'est le choix par défaut pour l'option webdotbase mais il est souvent surchargé et lent. Notez que le serveur de AT&T ne fonctionnera pas si Bugzilla n'est accessible que par HARTS. Note du rédacteur : Mais bon sang, qu'est ce que c'est que ce HARTS ? Google ne sait pas...

Les meilleurs bogues ne sont-ils pas aussi les plus énervants ? Pour vous aider à rendre ces bogues encore plus agaçants, vous pouvez activer le système automatique de plainte de Bugzilla pour vous plaindre des ingénieurs qui laissent leur bogues dans un état NEW ou REOPENED sans faire de triage.

Pour ce faire, ajoutez la commande suivante en tant qu'entrée crontab quotidienne, de la même manière que cela a été fait plus haut pour les diagrammes de bogue. Dans cet exemple, le planificateur s'active à minuit 55 :

55 0 * * * cd <your-bugzilla-directory> ; ./whineatnews.pl

	Note
	Windows n'a pas de 'cron', mais il a un planificateur de tâches, qui fournit les mêmes fonctions. Il y a également des outils conçus par des tiers qui peuvent être utilisés pour exécuter cron, tel que nncron.

Patch Viewer est le moteur qui permet l'affichage graphique des correctifs. Vous pouvez l'intégrer avec des copies des outils cvs, lxr et bonsai si vous les avez, en donnant l'emplacement de votre installation de ces outils dans editparams.cgi.

Patch Viewer pourra aussi éventuellement utiliser les utilitaires de ligne de commande cvs, diff et interdiff s'ils existent sur le système. On peut obtenir Interdiff sur http://cyberelk.net/tim/patchutils/. Si ces programmes ne sont pas dans le chemin du système, vous pouvez configurer leurs emplacements dans localconfig.

L'authentification LDAP est un module pour l'architecture d'authentification de plugin de Bugzilla.

Le schéma d'authentification traditionnel de Bugzilla utilise les adresses de courrier électronique comme identifiant utilisateur primaire et un mot de passe pour identifier l'utilisateur. Tous les endroits de Bugzilla qui traitent les utilisateurs (par exemple pour assigner un bogue) utilisent l'adresse de courrier électronique. L'authentification LDAP se place au dessus de ce schéma au lieu de le remplacer. L'utilisateur se connecte au début avec un nom d'utilisateur et un mot de passe pour l'annuaire LDAP. L'adresse de courrier électronique est récupérée depuis LDAP et l'utilisateur est identifié par le système traditionnel d'une façon cohérente en utilisant son adresse de courrier électronique. Si un compte pour cette adresse de courrier électronique existe déjà dans votre système Bugzilla, il s'y connectera. Si aucun compte pour cette adresse de courrier électronique n'existe, un compte est créé au cours de la connexion. (Dans ce cas, Bugzilla essaie d'utiliser les attributs « displayName » ou « cn » pour déterminer le nom complet de l'utilisateur). Après l'authentification, toutes les tâches liées à cet utilisateur sont gérées par l'adresse de courrier électronique et non par le nom d'utilisateur LDAP. Vous continuez d'assigner des bogues par adresse de courrier électronique, de rechercher des utilisateurs par adresse de courrier électronique, etc.

Attention

Du fait que le compte Bugzilla ne se crée qu'à la première connexion d'un utilisateur, un utilisateur qui ne s'est pas encore connecté est inconnu de Bugzilla. Ceci signifie qu'ils ne peuvent pas être utilisés comme propriétaire d'un bogue ou contact QA (que ce soit par défaut ou autrement), ajoutés à une liste cc, ou toute autre opération de ce genre. Une solution de rechange possible est le script bugzilla_ldapsync.rb dans le répertoire contrib. Une autre solution possible est de corriger le bogue 201069.

Paramètres requis pour utiliser l'authentification LDAP :

Certaines pages de Bugzilla ont des formats différents, autres que le HTML ordinaire. En particulier, quelques pages peuvent produire leur contenu soit en XUL (un format spécial de Bugzilla, qui ressemble à un programme GUI) soit en RDF (un genre d'XML structuré qui peut être lu par de nombreux programmes).

Pour que vos utilisateurs voient ces pages correctement, Apache doit les envoyer avec le type MIME adéquat. Pour ce faire, ajoutez les lignes suivantes à la configuration d'Apache, soit dans la section <VirtualHost> pour votre Bugzilla, soit dans la section <Directory> pour votre Bugzilla :

AddType application/vnd.mozilla.xul+xml .xul
AddType text/xml .rdf

Faire fonctionner Bugzilla sous Windows est plus difficile que de le faire fonctionner sous Unix. Pour cette raison, nous recommandons toujours de le faire sur un système basé sur Unix tel que GNU/Linux. Ceci dit, si vous voulez que Bugzilla fonctionne sous Windows, vous devrez faire les réglages suivants.

4.1.2. Perl Modules on Win32

Bugzilla sous Windows nécessite l'utilisation des mêmes modules Perl que ceux de Section 1.5, « Modules Perl ». La principale différence est que Windows utilise PPM au lieu de CPAN.

C:\perl> ppm install <module name>
        

La meilleure source pour les modules PPM de Windows nécessaires pour Bugzilla est probablement le serveur de test de Bugzilla (alias 'landfill') donc vous devriez ajouter l'ensemble des PPM de landfill comme suit :

ppm repository add landfill http://www.landfill.bugzilla.org/ppm/
        

	Note
	Sur landfill, les modules PPM sont regroupés en 'paquetages' qui peuvent avoir un nom légèrement différent de celui du module. Si vous récupérez ces modules à partir de là, vous devrez faire attention aux informations fournies lorsque vous exécutez checksetup.pl car il vous dira quel package vous devrez installer.

	Astuce
	Si vous êtes derrière un pare-feu d'entreprise, vous devrez informer l'utilitaire PPM ActiveState sur la façon de le contourner afin d'accéder aux fichiers contenant les PPM en configurant la variable d'environnement du système HTTP_proxy. Pour plus d'information sur la configuration de cette variable, voir la documentation de ActiveState.

open(SENDMAIL, "|/usr/lib/sendmail $sendmailparam -t -i") ||
  die "Can't open sendmail";

print SENDMAIL trim($msg) . "\n";
close SENDMAIL;
        

use Net::SMTP;
my $smtp_server = 'smtp.mycompany.com';  # changez ceci

# Utiliser die en cas d'erreur pour que le mail aille dans les 'mails non envoyés' et
# puisse être envoyé de la page sanitycheck.
my $smtp = Net::SMTP->new($smtp_server) ||
  die 'Cannot connect to server \'$smtp_server\'';

$smtp->mail('bugzilla-daemon@mycompany.com');  # changez ceci
$smtp->to($person);
$smtp->data();
$smtp->datasend($msg);
$smtp->dataend();
$smtp->quit;
        

4.1.4.  Traitement des pages Web

Comme c'est le cas sur les systèmes basés sur Unix, tous les serveurs web devraient supporter Bugzilla ; toutefois, si on lui demande son avis, l'équipe de Bugzilla recommande toujours Apache. Peu importe quel serveur web vous choisissez, surtout faites attention aux notes de sécurité de Section 3.1, « Désactivation des accès à distance pour les fichiers de configuration Bugzilla ». On trouvera plus d'informations sur la configuration de serveurs web particuliers dans la section Section 2.4, « Web server ».

	Note
	Si vous utilisez Apache sous Windows, vous pouvez mettre les instructions ScriptInterpreterSource dans votre configuration d'Apache pour éviter d'avoir à modifier la première ligne de chaque script afin qu'il contienne votre chemin vers perl au lieu de /usr/bin/perl.

Apple n'a pas inclus la bibliothèque GD dans MacOS X. Bugzilla en a besoin pour les graphes de bogues.

Vous pouvez l'installer en utilisant un programme appelé Fink, qui est proche de l'installeur CPAN mais il installe les utilitaires GNU courants. Fink est disponible à l'adresse http://sourceforge.net/projects/fink/.

Suivez les instructions pour configurer Fink. Une fois qu'il est installé, vous devez l'utiliser pour installer le paquetage gd2.

Fink va alors vous demander s'il doit résoudre un certain nombre de dépendances. Saisissez « y » et appuyez sur la touche Entrée pour installer toutes les dépendances et surveillez alors que tout se passe bien. Vous pourrez alors utiliser CPAN pour installer le module Perl GD.

Note

Pour ne pas entrer en conflit avec les logiciels installés par défaut par Apple, Fink crée sa propre arborescence dans /sw et y place la plupart des logiciels qu'il installe. Cela signifie que vos bibliothèques et vos entêtes seront dans /sw/lib et /sw/include au lieu de /usr/lib et /usr/include. Quand le script de configuration du module Perl vous demande où est votre libgd, dites lui bien /sw/lib.

Expat est également disponible via Fink. Après avoir utilisé fink pour installer le paquetage expat, vous pourrez installer XML::Parser en utilisant CPAN. Il y a une restriction. À la différence des versions récentes du module GD, XML::Parser n'invite pas à indiquer l'emplacement des bibliothèques nécessaires. Quand vous utilisez CPAN, vous devrez utiliser l'enchaînement des commandes suivant :

# perl -MCPAN -e'look XML::Parser'        
# perl Makefile.PL EXPATLIBPATH=/sw/lib EXPATINCPATH=/sw/include
# make; make test; make install           
# exit                                    
      

Linux-Mandrake 8.0 comporte toutes les bibliothèques obligatoires et facultatives pour Bugzilla. La manière la plus simple de les installer consiste à utiliser l'utilitaire urpmi. Si vous suivez ces commandes, vous devriez avoir tout ce qu'il vous faut pour Bugzilla et ./checksetup.pl ne devrait pas se plaindre de bibliothèques manquantes. Il se peut que vous ayez certaines de ces bibliothèques déjà installées.

bash# urpmi perl-mysql
bash# urpmi perl-chart
bash# urpmi perl-gd
bash# urpmi perl-MailTools             
bash# urpmi apache-modules
      

Si vous exécutez un *NIX OS avec un compte limité (non administrateur), soit en raison d'un manque d'accès (les hôtes web, par exemple) ou pour des raisons de sécurité, cette partie vous indiquera comment installer Bugzilla sur une telle installation. Il est recommandé que vous lisiez d'abord la Section 1, « Installation » pour avoir une idée des étapes d'installation nécessaires (ces notes renverront à des étapes de ce guide).

Il se peut que MySQL soit installé en tant qu'administrateur. Si vous êtes en train d'installer un compte avec un hôte web, un compte MySQL devra être créé pour vous. À partir de là, vous pouvez créer le compte bugs ou utiliser le compte qui vous est fourni.

Avertissement

Vous pourriez avoir des problèmes en essayant de régler les permissions GRANT à la base de données. Si vous utilisez un hôte web, il y a de grandes chances que vous ayez une base de données séparée qui est déjà verrouillée (ou une grosse base de données sans accès ou avec des accès limités aux autres zones) mais vous pouvez demander à votre administrateur système comment les réglages de sécurité ont été fixés, et/ou qu'il exécute la commande GRANT pour vous. En plus, vous ne pourrez sans doute pas changer le mot de passe administrateur de MySQL (pour des raisons évidentes) alors sautez cette étape.

5.2.1. Exécuter MySQL comme non administrateur

5.2.1.1. La méthode de configuration personnalisée

Créez un fichier .my.cnf dans votre répertoire home (/home/foo est utilisé dans cet exemple) comme suit...

[mysqld]
datadir=/home/foo/mymysql
socket=/home/foo/mymysql/thesock
port=8081

[mysql]
socket=/home/foo/mymysql/thesock
port=8081

[mysql.server]
user=mysql
basedir=/var/lib

[safe_mysqld]
err-log=/home/foo/mymysql/the.log
pid-file=/home/foo/mymysql/the.pid

5.2.1.2. La méthode de construction personnalisée

Vous pouvez installer MySQL en tant que non « root », si vous le souhaitez vraiment. Construisez le avec /home/foo/mysql comme PREFIX ou utilisez des exécutables pré installés, en spécifiant que vous voulez mettre tous les fichiers de données dans /home/foo/mysql/data. S'il y un autre serveur MySQL qui s'exécute sur le système dont vous n'êtes pas le propriétaire, utilisez l'option -P pour indiquer un port TCP qui n'est pas utilisé.

5.2.1.3. Démarrage du serveur

Après que votre programme mysqld soit construit et que les éventuels fichiers .my.cnf soient en place, vous devez initialiser la base de données (UNE FOIS).

bash$ mysql_install_db

Ensuite démarrez le démon avec

bash$ safe_mysql &

Après le premier démarrage de mysqld, connectez vous en tant qu'administrateur et accordez les droits GRANT aux autres utilisateurs. (Encore une fois, le compte administrateur MySQL n'a rien à voir avec le compte administrateur *NIX.)

	Note
	Vous devrez démarrer les démons vous-même. Vous pouvez soit demander à votre administrateur système de les ajouter au fichier de démarrage, soit ajouter une entrée crontab qui exécute un script qui fera une vérification de ces démons et les redémarrera si besoin est.

	Avertissement
	N'exécutez PAS de démons ou d'autres programmes sur un serveur avant de consulter d'abord l'administrateur système ! Les démons consomment des ressources système et en exécuter un peut être en contradiction avec les règles d'utilisation de la machine sur laquelle vous êtes !

Dans le cas très rare où vous n'auriez pas Perl sur la machine, vous devrez construire les sources vous-même. Avec les commandes suivantes, vous devriez pouvoir installer votre propre version de Perl sur votre système avec :

bash$ wget http://perl.com/CPAN/src/stable.tar.gz
bash$ tar zvxf stable.tar.gz
bash$ cd perl-5.8.1 (ou quelque soit la version de Perl qui est appelée)
bash$ sh Configure -de -Dprefix=/home/foo/perl
bash$ make && make test && make install

Une fois que Perl est installé dans un répertoire (probablement dans ~/perl/bin), vous devrez changer les emplacements dans les scripts, ce qui est expliqué plus loin dans cette page.

Installer les modules de Perl en tant que non administrateur est probablement la partie la plus difficile du processus. Il y a deux méthodes différentes : un Perl complètement indépendant avec ses propres modules, ou des modules personnels utilisant la version actuelle de Perl (installée par l'administrateur). La méthode indépendante prend pas mal d'espace disque, mais est moins complexe, alors que la méthode mixte n'utilise pas plus d'espace que les modules eux-mêmes, mais demande plus de travail à installer.

bash$ /home/foo/perl/bin/perl -MCPAN -e 'shell'

cpan> install Bundle::Bugzilla

bash$ perl -MCPAN -e 'shell'

cpan> install Bundle::Bugzilla

cpan> force install Template

cpan> install GD
cpan> install Chart::Base
cpan> install MIME::Parser

Idéalement, il faut également l'installer en tant que root et l'exécuter sous un compte serveur web particulier. Tant que le serveur Web permettra l'exécution des fichiers *.cgi hors d'un répertoire cgi-bin, ainsi qu'un moyen de refuser l'accès à certains fichiers (comme un fichier .htaccess), vous devriez bien vous en sortir.

5.5.1. Lancer Apache en tant qu'utilisateur non root

Vous pouvez lancer Apache en tant qu'utilisateur non root, mais le port attribué devra être supérieur à 1024. Si vous entrez httpd -V, vous obtiendrez une liste des variables qu'utilise votre copie système de httpd. L'une d'entre elles, à savoir HTTPD_ROOT, vous indique l'endroit où l'installation cherche ses informations de configuration.

À partir de ce point, vous pouvez copier les fichiers de configuration dans votre répertoire personnel pour commencer leur modification. Lorsque vous les éditez et que vous utilisez l'option -d pour outrepasser le HTTPD_ROOT compilé dans votre serveur web, vous prenez le contrôle de votre propre serveur Web personnalisé.

	Note
	Vous devrez démarrer les démons vous-même. Vous pouvez soit demander à votre administrateur système de les ajouter au fichier de démarrage, soit ajouter une entrée crontab qui exécute un script qui fera une vérification de ces démons et les redémarrera si besoin est.

	Avertissement
	N'exécutez PAS de démons ou d'autres programmes sur un serveur avant de consulter d'abord l'administrateur système ! Les démons consomment des ressources système et en exécuter un peut être en contradiction avec les règles d'utilisation de la machine sur laquelle vous êtes !

Si vous deviez installer des modules Perl en tant qu'utilisateur non root (Section 5.4, « Les modules Perl ») ou dans des répertoires non standards, vous devrez modifier les scripts, en spécifiant l'emplacement correct des modules Perl :

perl -pi -e 's@use strict\;@use strict\; use lib \"/home/foo/perl/lib\"\;@' \
    *cgi *pl Bug.pm processmail syncshadowdb

Modifiez /home/foo/perl/lib dans votre répertoire de bibliotèques Perl personnel. Vous pouvez vraisemblablement sauter cette étape si vous utilisez la méthode indépendante d'installation du module Perl.

Lorsque vous lancerez ./checksetup.pl pour créer le fichier localconfig, il fera une liste des modules Perl qu'il trouvera. S'il en manque un, revenez en arrière et revérifiez l'installation du module depuis l'interpréteur de commandes CPAN, puis supprimez le fichier localconfig et réessayez.

Avertissement

L'option dans localconfig avec laquelle vous risquez d'avoir des problèmes est le groupe du serveur Web. Si vous ne parvenez pas à remonter jusqu'à index.cgi (vous obtenez une erreur du type Accés Interdit, vous devrez peut-être être assouplir vos droits d'accès et effacer le groupe du serveur Web. Bien entendu, cela peut représenter un risque pour la sécurité. Il est vrai qu'un interpréteur de commandes correctement sécurisé et/ou un accès limité aux comptes munis d'interpréteurs de commandes diminuent le risque au niveau sécurité, mais c'est à vous d'assumer.

Quand vous lancez pour la première fois checksetup.pl après l'installation de Bugzilla, on vous demandera le nom de l'administrateur (adresse électronique) et le mot de passe de ce « super utilisateur ». Si, pour une raison quelconque, vous supprimez ce compte, relancez checksetup.pl et on vous redemandera le nom d'utilisateur et le mot de passe de l'administrateur.

	Astuce
	Si vous souhaitez ajouter plus d'administrateurs, ajouter les au groupe « admin » et, éventuellement, éditez les groupes tweakparams, editusers, creategroups, editcomponents et editkeywords pour ajouter le groupe entier d'administrateurs à ces groupes.

Un développeur peut avoir envie de demander à sa hiérarchie : « Devrions nous corriger ce bogue avant de sortir la version 2.0 ? ». Ils peuvent avoir envie de le faire pour de nombreux bogues, et donc ce serait bien de rationaliser le procédé...

Avec Bugzilla, cela marcherait ainsi :

Si un fanion a été déclaré comme étant fanion « de requête », les utilisateurs sont autorisés à attribuer au fanion le statut « ? ». Ce statut indique que quelqu'un (alias « le demandeur ») demande à quelqu'un d'autre d'attribuer « + » ou « - ».

Si un fanion a été défini comme « fanion de requête particulière », une zone de texte apparaîtra à côté du fanion dans laquelle le demandeur peut entrer un nom d'utilisateur Bugzilla. La personne mentionnée (alias « le demandé ») recevra un courriel l'avertissant de la requête et renvoyant celle-ci vers le bogue ou la pièce jointe en question.

Si un fanion n'a pas été défini « fanion de requête particulière », aucune zone de ce genre n'apparaîtra. Une requête pour marquer ce fanion ne peut pas être faite à une personne en particulier, mais doit être demandée « à la cantonade ». Un demandeur peut « demander à la cantonade » pour n'importe quel fanion simplement en laissant la zone de texte vide.

Les fanions peuvent se mettre à deux endroits : dans une pièce jointe, ou dans un bogue.

Si vous avez le privilège « editcomponents », vous aurez « Edit: ... | Flags | ... » en bas de page. En cliquant sur ce lien vous pourrez accéder à la page « Administrer des types de fanions ». Ici, vous pouvez choisir si vous voulez créer (ou éditer) un fanion de bogue, ou un fanion de pièce jointe.

Peu importe celui que vous choisissez, l'interface est la même, donc nous ne l'aborderons qu'une fois.

7.5.2. Supprimer un fanion

Sur le boîte de dialogue « Administrer les types de fanions », vous verrez une liste de fanions de bogues et une liste de fanions de pièces jointes.

Pour supprimer un fanion, cliquez sur le lien « Delete » à côté de la description du fanion.

Avertissement

Une fois que vous avez supprimé un fanion, il n'est plus dans votre Bugzilla. Toutes les données de ce fanion seront supprimées. Il disparaîtra de tous les endroits où il était installé, et vous ne pourrez pas récupérer les données. Si vous voulez garder les données d'un fanion, mais ne voulez pas que n'importe qui configure de nouveaux fanions ou modifie les fanions courants, dé-sélectionnez « active » dans le formulaire d'édition des fanions.

Pour créer des groupes :

Les utilisateurs peuvent devenir membres d'un groupe de plusieurs façons.

Sur la page d'édition du produit, il y a une page pour éditer le « Group Controls » d'un produit. Cela vous permet de paramétrer le lien qui existe entre un groupe et un produit. Les groupes peuvent être applicables, par défaut et obligatoires ainsi qu'être utilisés pour contrôler qui a le droit d'entrer un rapport de bogue ou pour limiter à un groupe particulier le droit de modifier les rapports de bogue.

Pour chaque groupe, il est possible de spécifier si être membre de ce groupe...

Ces paramètres sont souvent indiqués dans cet ordre. Par exemple, pour un produit qui demande, pour entrer un bogue, qu'un utilisateur soit membre du groupe « foo » et demande ensuite que le bogue reste en permanence restreint au groupe « foo » et enfin que seuls les membres du groupe « foo » puissent modifier ce bogue, bien que celui-ci puisse être visible pour d'autres, le paramétrage du groupe serait résumé ainsi :

 
foo: ENTRY, MANDATORY/MANDATORY, CANEDIT

La norme TCP/IP établit plus de 65000 ports pour le trafic entrant et sortant. Parmi ceux-là, Bugzilla en a besoin précisément d'un pour fonctionner (selon les configurations et les options, on pourra en avoir besoin de 2, voire 3). Il faut vérifier votre serveur et vous assurer qu'il n'est pas à l'écoute sur des ports dont vous n'avez pas besoin. Il est également fortement recommandé que le serveur sur lequel se trouve Bugzilla, ainsi que toute autre machine que vous administrez, soit placé derrière quelque chose du genre coupe-feu.

Beaucoup de démons tels que le httpd d'Apache ou le mysqld de MySQL s'exécutent aussi bien en tant que « root » qu'en tant que « nobody ». C'est encore pire sur les machines Windows où la majorité des services sont exécutés en tant que « SYSTEME ». Bien que l'exécution en tant que « root » ou « SYSTEM » présente des problèmes de sécurité évidents, les problèmes que présente l'exécution de tout en tant que « nobody » peuvent ne pas être si évidents. En gros, si vous exécutez tous les démons en tant que « nobody » et que l'un d'entre eux se trouve compromis, il peut compromettre tous les autres démons exécutés en tant que « nobody »sur votre machine. Pour cette raison, il est conseillé de créer un compte utilisateur pour chaque démon.

	Note
	Il vous faudra configurer l'option webservergroup dans localconfig pour le groupe dans lequel votre serveur Web s'exécute. Cela permettra à ./checksetup.pl de configurer les permissions des fichiers sur les systèmes Unix de manière à ce que rien ne soit en écriture libre.

Si votre système le supporte, vous souhaitez peut être exécuter Bugzilla à l'intérieur d'un environnement d'exécution fermé chroot. Cette option fournit une sécurité sans précédent en interdisant à tout ce qui s'exécute dans cet environnement d'exécution fermé d'accéder à toute information lui étant extérieure. Si vous souhaitez utiliser cette option, veuillez consulter la documentation livrée avec votre système.

Comme mentionné dans Section 1.2, « Comptes utilisateur du système », le démon MySQL devrait s'exécuter comme utilisateur unique non privilégié. Ne manquez pas de consulter les instructions de la documentation MySQL ou de la documentation livrée avec votre système.

Par défaut, MySQL est fourni avec un utilisateur « root » dont le mot de passe est vide et avec un utilisateur « anonymous », dont le mot de passe est également vide. Afin de protéger vos données, il faut demander un mot de passe à l'utilisateur « root » et l'utilisateur anonyme doit être désactivé.

bash$ mysql mysql
mysql> UPDATE user SET password = password('new_password') WHERE user = 'root';
mysql> FLUSH PRIVILEGES;
        

bash$ mysql -u root -p mysql           
Enter Password: new_password
mysql> DELETE FROM user WHERE user = '';
mysql> FLUSH PRIVILEGES;
        

Si MySQL et votre serveur Web fonctionnent tous les deux sur la même machine et que vous n'avez pas d'autres raisons d'accéder à MySQL à distance, vous devriez désactiver l'accès au réseau. Cela, ainsi que ce qui est proposé dans Section 1.1, « Ports TCP/IP », vous permettra de protéger votre système de toutes vulnérabilités à distance de MySQL.

[myslqd]
# Prevent network access to MySQL.
skip-networking
        

Il y a beaucoup de fichiers placés dans la zone du répertoire Bugzilla qui ne doivent pas être accessibles depuis le web. À cause de la présentation actuelle de Bugzilla, la liste de ceux qui doivent être accessibles ou pas est plutôt compliquée. Une nouvelle méthode d'installation est actuellement en cours de réalisation; elle devrait résoudre cela en autorisant les fichiers qui ne doivent pas être accessibles depuis le web à être placés dans un répertoire à l'extérieur de la racine internet. Voir le bogue 44659 pour plus d'informations.

	Astuce
	À l'état brut, Bugzilla a la capacité de créer des fichiers .htaccess qui imposent ces règles. Les instructions pour activer ces directives dans Apache sont disponibles dans Section 2.4.1, « httpd™ d'Apache ».

Surtout faites bien un test pour voir si les données qui ne doivent pas être accessibles à distance sont correctement bloquées. Le fichier localconfig qui contient votre mot de passe de base de données est particulièrement intéressant ici. Sachez également que beaucoup d'éditeurs créent des fichiers temporaires et de restauration dans le répertoire de travail et que ceux-ci ne doivent également pas être accessibles. Pour plus d'informations, voyez le bogue 186383 ou le Bugtraq ID 6501. Pour le test, précisez simplement à votre navigateur web où est le fichier; par exemple, pour tester une installation mozilla.org, on essaiera d'accéder à http://bugzilla.mozilla.org/localconfig. Vous devriez obtenir une erreur « 403 Forbidden ».

	Astuce
	N'oubliez pas de consulter, dans Section 2.4, « Web server », les instructions spécifiques au serveur web que vous utilisez.

	Note
	Cette partie ne concerne que les gens qui ont choisi un serveur Apache. Il est peut-être possible de faire des choses similaires avec d'autres serveurs web. Consultez la documentation livrée avec votre serveur web pour voir si c'est le cas.

Il est possible pour un utilisateur, par erreur ou volontairement, d'accéder plusieurs fois de suite à la base de données, ce qui peut engendrer des vitesses d'accès très faibles pour les autres utilisateurs (en fait, c'est une attaque par DOS). Si votre installation Bugzilla rencontre ce problème, vous pouvez installer le module Apache mod_throttle qui est capable de limiter le nombre de connexions par adresse IP. Vous pouvez télécharger ce module à http://www.snert.com/Software/mod_throttle/. Suivez les instructions pour l'insérer dans votre installation d'Apache. La commande qu'il vous faut est ThrottleClientIP. Veuillez lire la documentation du module pour plus d'informations.

Il est possible pour un utilisateur Bugzilla de profiter des ambiguïtés de codage du jeu de caractères pour injecter du HTML dans les commentaires Bugzilla. Celui-ci pourrait contenir des scripts malveillants. En raison de considérations liées à l'internationalisation, nous ne sommes pas en mesure d'intégrer par défaut les modifications de code proposées par les services d'assistance du CERT sur cette question. Si votre installation est destinée uniquement à un public anglophone, vous éviterez ce problème en effectuant la modification de Exemple 4.4, «  Obliger Bugzilla à indiquer le codage utilisé (charset)  ».

$self->charset('');

$self->charset('ISO-8859-1');

La structure de répertoires des modèles est composée d'un répertoire de haut niveau nommé template, qui contient un répertoire pour chaque région installée. Le niveau suivant définit la langue utilisée dans les modèles. Bugzilla est livré avec des modèles en anglais, le nom du répertoire est donc en, et nous parlerons de template/en dans toute la documentation. En dessous de ça, template/en est un répertoire default qui contient tous les modèles standard fournis avec Bugzilla.

	Avertissement
	Un répertoire data/templates existe aussi ; c'est là où Template Toolkit met les versions compilées à partir des répertoires par défaut ou personnalisés. N'éditez pas directement les fichiers dans ce répertoire, ou alors toutes vos modifications seront perdues la prochaine fois que Template Toolkit recompilera les modèles.

Si vous voulez éditer des modèles Bugzilla, la première choix à faire est de décider comment vous allez vous y prendre. Il y a deux possibilités et celle que vous utiliserez dépend principalement de la portée de vos modifications, et de la méthode que vous prévoyez d'utiliser pour mettre à niveau Bugzilla.

La première méthode pour personnaliser les modèles consiste à éditer directement ceux qui sont dans template/en/default. C'est probablement la meilleure méthode pour de petites modifications si vous comptez utiliser la méthode de mise à niveau par CVS, parce qu'alors, si vous exécutez un cvs update, toute correction dans un modèle s'intègrera automagiquement dans les versions que vous aurez mises à jour.

	Note
	Si vous utilisez cette méthode, et si des conflits CVS surviennent pendant une mise à jour, les modèles en conflit (et éventuellement d'autres parties de votre installation) ne fonctionneront pas tant qu'ils ne seront pas résolus.

L'autre méthode consiste à copier les modèles à modifier dans une arborescence de répertoires miroir sous template/en/custom. Les modèles de cette arborescence de répertoire prennent le pas sur tous les modèles de même nom et situés au même endroit dans le répertoire default.

	Note
	Le répertoire custom n'existe pas initialement et doit être créé si vous voulez l'utiliser.

C'est la technique que vous devez utiliser si vous utilisez la méthode de mise à niveau par réécriture, parce qu'autrement vos modifications seront perdues. Cette méthode est peut-être également la meilleure si vous utilisez la méthode de mise à niveau par CVS et que vous comptez faire des modifications majeures, car il est garanti que le contenu de ce répertoire ne sera pas touché au cours d'une mise à niveau, et vous pouvez alors décider soit de continuer en utilisant votre propre modèle, soit de faire l'effort d'intégrer à la main vos modifications dans les nouvelles versions.

Avec cette méthode, votre installation peut être perdue en cas de modifications incompatibles faites à l'interface des modèles. Si de telles modifications sont faites, elles seront détaillées dans la notice de la version, à condition que vous utilisiez une version stable de Bugzilla. Si vous utilisez du code instable, vous devrez vous occuper de ça vous-même, bien que, autant que possible, les modifications seront citées, avant qu'elles ne s'appliquent, dans la partie « À éviter » de la notice de la précédente version stable.

	Note
	Quelle que soit la méthode que vous avez choisie, il est recommandé d'exécuter ./checksetup.pl après la création ou l'édition de tout modèle dans le répertoire template/en/default, et après l'édition de tout modèle dans le répertoire custom.

	Avertissement
	Il est indispensable d'exécuter ./checksetup.pl après la création d'un nouveau modèle, dans le répertoire custom. Si vous ne le faites pas, cela entraînera un message d'erreur incompréhensible.

	Note
	Si vous apportez des modifications aux modèles que vous souhaitez voir inclus dans le Bugzilla standard, il faut lire les parties correspondantes du guide des développeurs.

La syntaxe du langage de Template Toolkit dépasse le cadre de ce guide. Elle est assez facile à comprendre en regardant les modèles actuels ; vous pouvez également lire le manuel, disponible sur la page d'accueil de Template Toolkit.

Cependant, une chose à laquelle vous devriez apporter un soin particulier est la nécessité de filtrer correctement, par rapport au langage HTML, les données qui ont été transmises dans le modèle. Cela signifie que si les données sont susceptibles de contenir des caractères HTML spéciaux comme <, et que les données ne sont pas sensées être du HTML, elles doivent être converties sous la forme d'entité, c'est-à-dire &lt; on utilise le filtre « html » de Template Toolkit pour faire cela. Si vous ne le faîtes pas, vous pouvez exposer votre installation à des attaques par scripts à l'intérieur du site.

Notez également que Bugzilla inclut de lui-même quelques filtres, qui ne sont pas dans le Template Toolkit standard. En particulier, le filtre « url_quote » peut convertir les caractères qui sont illégaux ou qui ont un sens particulier dans les URL, comme &, en une forme encodée, c'est-à-dire %26. En fait, celui-ci encode la plupart des caractères (mais pas les plus fréquents comme les lettres et les nombres et cætera), y compris les caractères HTML spéciaux, de sorte que, par la suite, vous n'avez jamais besoin de filtrer par rapport au langage HTML.

Editer des modèles est une bonne façon de faire les « champs personnalisés du pauvre ». Par exemple, si vous n'utilisez pas le Tableau Blanc mais que vous souhaitez disposer d'une boîte d'entrée de texte de forme libre pour le « Identifiant de Création », vous pouvez vous contenter d'éditer les modèles pour changer le nom des champs. Ca s'appellera toujours status_whiteboard en interne, mais vos utilisateurs n'ont pas besoin de le savoir.

Certains CGI sont capables d'utiliser plus d'un modèle. Par exemple, buglist.cgi peut générer des listes de bogues en RDF ou en 2 formes différentes de HTML (complexe et simple). Le mécanisme qui fournit ce dispositif est extensible.

Bugzilla peut supporter différents types de sorties, qui peuvent eux aussi avoir des formats multiples. Pour demander un certain type, vous pouvez joindre le &ctype=<contenttype> (tel que rdf ou html) au lien <cginame>.cgi. Si vous souhaitez rechercher un certain format, vous pouvez utiliser le &format=<format> (comme simple ou complex) dans l'URL.

Pour savoir si un CGI supporte plusieurs formats de sortie et plusieurs types, effectuez un grep sur le CGI pour « GetFormat ». S'il n'y en a pas, l'ajout de support de plusieurs formats/types n'est pas trop dur ; regardez comment c'est fait dans d'autres CGI, i.e. config.cgi.

Pour faire un nouveau modèle de format pour un CGI qui supporte ça, ouvrez un modèle existant pour ce CGI et prenez note du commentaire INTERFACE (s'il est présent). Ce commentaire définit quelles variables sont passées dans ce modèle. S'il n'y en a pas, j'ai bien peur que vous deviez lire le modèle et le code pour voir ce que vous avez comme informations.

Vous pouvez écrire votre modèle dans n'importe quel style de balisage ou de texte qui convient.

Il vous faut maintenant choisir le type de contenu dans lequel vous voulez qu'il soit utilisé. Les types de contenu sont définis dans le fichier Bugzilla/Constants.pm dans la constante contenttypes. Si votre type de contenu ne s'y trouve pas, ajoutez le. Mémorisez l'étiquette de trois ou quatre lettres affectée à votre type de contenu. Cette étiquette fera partie du nom de fichier du modèle.

	Note
	Après l'ajout ou la modification d'un type de contenu, il convient d'éditer Bugzilla/Constants.pm afin de répercuter les modifications. En outre, le fichier doit être conservé à jour après une mise à jour si des types de contenu ont été personnalisés dans le passé.

Enregistrez le modèle sous <stubname>-<formatname>.<contenttypetag>.tmpl. Testez le modèle en appelant le CGI par <cginame>.cgi?format=<formatname>&ctype=<type>.

Il y a quelques modèles qui pourraient vous intéresser tout particulièrement pour personnaliser votre installation.

index.html.tmpl : c'est la page d'accueil de Bugzilla.

global/header.html.tmpl : définit l'en-tête qui apparaît sur toutes les pages de Bugzilla. L'en-tête inclut la bannière, qui est ce qui apparaît aux utilisateurs et qui est probablement ce que vous voulez éditer plutôt que l'en-tête. Cependant, l'en-tête inclut également la section HTML HEAD, vous pourriez donc par exemple ajouter une feuille de style ou une balise META en éditant l'en-tête.

global/banner.html.tmpl : contient la « bannière », la partie de l'en-tête qui apparaît en haut de toutes les pages de Bugzilla. La bannière par défaut est assez sommaire, vous voudrez donc probablement la personnaliser pour donner à votre installation son propre aspect et sa propre convivialité. Il est recommandé de conserver le numéro de version Bugzilla sous une forme ou une autre pour permettre de déterminer la version que vous utilisez, et que les utilisateurs sachent quelle documentation ils doivent lire.

global/footer.html.tmpl : définit le pied de page qui apparaît sur toutes les pages de Bugzilla. En l'éditant, vous avez un autre moyen de donner rapidement son propre aspect et sa propre convivialité à votre installation Bugzilla.

global/variables.none.tmpl : définit une liste de termes qui peuvent être modifiés afin « d'estampiller » l'instance Bugzilla. De cette manière, les termes tels que « bugs » peuvent être remplacés par « problèmes » dans toute l'installation Bugzilla. Le nom « Bugzilla » et d'autres mots peuvent être tout aussi bien personnalisés.

list/table.html.tmpl : ce modèle gère l'apparence des listes de bogues créées par Bugzilla. En éditant ce modèle, on peut modifier la largeur et le titre des colonnes une par une, la taille maximale de l'affichage pour chaque entrée, et le comportement de l'enveloppe des entrées longues. Pour les longues listes de bogues, Bugzilla insère un « break » tous les 100 bogues par défaut ; ce comportement est également géré par ce modèle, et c'est là que cette valeur pourra être modifié.

bug/create/user-message.html.tmpl : message qui apparaît près du haut de la page de soumission de bogues. En le modifiant, vous pouvez dire à vos utilisateurs comment soumettre des bogues.

bug/process/midair.html.tmpl : ceci est le modèle utilisé si deux personnes modifient un bug simultanément. La deuxième personne a soumettre une modification verra apparaître cette page indiquant la modification apportée par la première personne et demandant s'ils veulent écraser cette modification ou revenir sur le bogue. Le titre et l'en-tête par défaut de cette page est « Collision en plein vol détectée ! » Si vous travaillez dans l'industrie aero-nautique ou un autre milieu ou ceci peut géner quelqu'un (oui, on nous a rapporté des histoires vraies à ce sujet), vous voudrez peut-être changer cette phrase.

bug/create/create.html.tmpl et bug/create/comment.txt.tmpl : vous n'avez peut-être pas envie de vous casser la tête à créer des zones personnalisées dans Bugzilla, mais vous voulez être sûr que chaque rapport de bogue contienne un nombre d'informations importantes pour lesquelles il n'y a pas de zone spéciale. Le système d'entrée de bogues a été conçu sous une forme extensible pour vous permettre d'ajouter arbitrairement des gadgets HTML, tels que listes déroulantes et zones de texte, à la page d'entrée de bogues et de faire apparaître leurs valeurs formatées dans la description initiale. Un champ caché qui indique le format doit être ajouté à l'intérieur du formulaire afin de rendre le modèle fonctionnel. Sa valeur doit être le suffixe de nom du fichier du modèle. Par exemple, si le fichier s'appelle create-cust.html.tmpl, alors

<input type="hidden" name="format" value="cust">

doit être utilisé à l'intérieur du formulaire.

Un exemple en est le formulaire de soumission de bogues de mozilla.org. Le code pour cela est livré avec la distribution Bugzilla comme exemple à copier par vous. Vous le trouverez dans les fichiers create-guided.html.tmpl et comment-guided.html.tmpl.

Donc pour utiliser ce dispositif, créez un modèle personnalisé pour enter_bug.cgi. Le modèle par défaut, sur lequel vous pouvez vous baser, est custom/bug/create/create.html.tmpl. Nommez le create-<formatname>.html.tmpl et ajoutez y des gadgets pour chaque information que vous aimeriez voir collectée : un numéro de création, l'ensemble des étapes pour le reproduire.

Puis, créez un modèle comme custom/bug/create/comment.txt.tmpl, et nommez le comment-<formatname>.txt.tmpl. Ce modèle doit renvoyer aux champs du formulaire que vous avez créé en utilisant la syntaxe [% form.<fieldname> %]. Quand un rapport de bogue est soumis, le commentaire initial joint au rapport de bogue sera formaté d'après la disposition de ce modèle.

Par exemple, si votre modèle enter_bug possédait un champ

<input type="text" name="buildid" size="30">

et que votre comment.txt.tmpl avait

BuildID : [% form.buildid %]

alors

BuildID : 20020303

apparaîtrait dans le commentaire initial.

Bugzilla prend en compte l'en-tête HTTP Accept: de l'utilisateur. Vous pouvez installer des modèles dans d'autres langues, et Bugzilla retiendra le plus approprié d'après l'ordre de priorités que vous avez défini. Beaucoup de modèles de langue peuvent être récupérés à partir de http://www.bugzilla.org/download.html#localizations. Les instructions pour intégrer de nouvelles langues sont aussi disponibles à cet endroit.

Après avoir décompressé les localisations (ou créé les vôtres) dans le répertoire BUGZILLA_ROOT/template, vous devez mettre à jour le paramètre languages pour contenir toutes les adaptations que vous aimeriez laisser. Vous pouvez également, si vous le souhaitez, modifier le paramètre defaultlanguage en remplaçant « en » par autre chose si vous ne voulez pas l'anglais comme langue par défaut.

Si, comme je l'étais, vous êtes totalement ignorant des mécanismes internes de MySQL à ce stade, et si vous n'étiez pas sous les ordres du Vice-Président, vous vous moqueriez de la différence qui existe entre un champ « bigint » et un « tinyint » dans MySQL. Je vous recommande de consulter la documentation MySQL en ligne. Vous trouverez ci-dessous les rudiments nécessaires pour comprendre la base de données de Bugzilla. Consultez la documentation MySQL ci-dessus pour plus d'informations.

5.1.1. Les tables de la base de données de Bugzilla

Imaginez votre base de données MySQL comme une série de feuilles de calcul d'un tableur, et vous ne serez pas loin de la vérité. Si vous tapez cette commande :

mysql> show tables from bugs;

vous pourrez voir le nom de toutes les « feuilles de calcul » (tables) dans votre base de données.

À partir de la commande tapée ci-dessus, vous devriez obtenir une réponse qui ressemble à celle-ci :

+-------------------+
| Tables in bugs    |
+-------------------+
| attachments       |
| bugs              |
| bugs_activity     |
| cc                |
| components        |
| dependencies      |
| fielddefs         |
| groups            |
| keyworddefs       |
| keywords          |
| logincookies      |
| longdescs         |
| milestones        |
| namedqueries      |
| products          |
| profiles          |
| profiles_activity |
| tokens            |
| versions          |
| votes             |
| watch             |
+-------------------+

Voici un aperçu de ce que fait chaque table. La plupart des colonnes de chaque table possèdent un nom descriptif qui permet de comprendre relativement rapidement leur rôle.

attachments

cette table contient tous les fichiers joints aux bogues. Cette table tend à être la plus grande mais généralement aussi celle qui comporte le moins d'entrées car les fichiers joints sont (relativement) gros.

bugs

c'est le cœur de votre système. La table bugs contient la plupart des informations concernant les bogues à l'exception des informations stockées dans les autres tables.

bugs_activity

conserve les informations concernant les changements apportés aux bogues — un fichier d'historique.

cc

cette petite table conserve simplement toutes les informations de copie carbone (CC) des bogues dont le champ CC est renseigné. Notez que, comme la plupart des autres tables dans Bugzilla, il n'est pas fait référence aux utilisateurs par le biais de leur nom d'utilisateur, mais par leur seul identifiant utilisateur, stocké dans la table profiles comme clé primaire.

components

stocke les programmes et les composants (ou les produits et les composants dans le nouveau langage de Bugzilla) de Bugzilla. Curieusement, le champ « program » (product) est le nom complet du produit et non un autre identifiant unique, comme bug_id et user_id le sont ailleurs dans la base de données.

dependencies

contient les données sur ces supers arbres de dépendance.

fielddefs

table pratique qui définit les autres tables. Par exemple lorsque vous validez un formulaire qui change la valeur de « AssignedTo », cette table permet le transfert de l'information vers le champ actuel dont le nom est « assigned_to » pour une entrée de MySQL.

groups

définit les masques binaires pour les groupes. Un masque binaire est un nombre qui peut identifier de manière unique les appartenances à un groupe. Par exemple, disons que le groupe qui a le droit d'apporter quelques petites modifications aux paramètres est affecté d'une valeur « 1 », le groupe qui a la droit d'éditer les utilisateurs est affecté d'une valeur « 2 » et le groupe qui peut créer de nouveaux groupes est affecté d'un masque binaire de « 4 ». Simplement en combinant les masques binaires des groupes (tout comme la commande chmod d'UNIX,) vous pouvez identifier un utilisateur qui a le droit de modifier légèrement les paramètres et de créer des groupes mais pas d'éditer les utilisateurs, en lui affectant un masque binaire de « 5 », ou bien un utilisateur ayant le droit d'éditer des utilisateurs et de créer des groupes, mais pas de modifier les paramètres, en lui donnant un masque binaire de « 6 ». Simple, hein ?

Si vous n'avez pas compris, essayer en tapant ceci à l'invite de commande de mysql :

mysql> select * from groups;

Vous verrez la liste, c'est plus compréhensible de cette manière.

keyworddefs

définition des mots-clés utilisés.

keywords

à l'inverse de ce que vous pensez, cette table dit quels mots-clés sont associés avec quels identifiants de bogues.

logincookies

cette table stocke tous les cookies de connexion qui vous sont assignés pour chaque machine à partir de laquelle vous vous êtes connecté à Bugzilla. Curieusement, elle ne gère pas le nettoyage ; je retrouve des cookies que je n'ai pas utilisés depuis des mois. Cependant, comme Bugzilla ne donne pas de date d'expiration aux cookies, cela se comprend.

longdescs

la substance de Bugzilla : voici où sont stockés tous les commentaires des utilisateurs ! Vous disposez uniquement de 2^24 octets par commentaire (il s'agit d'un champ de type mediumtext), donc soyez concis ; cela représente seulement l'espace que l'Ancien Testament prendrait (16 mégaoctets, non compressé). Tout commentaire reçoit comme clé le bug_id du bogue auquel il est lié de telle manière que l'ordre soit nécessairement chronologique car les commentaires sont retournés dans l'ordre où ils ont été reçus.

milestones

c'est une bonne chose que les jalons soient associés à un produit particulier dans cette table mais Bugzilla ne supporte pas encore les jalons qui diffèrent en fonction des produits via l'interface de configuration standard.

namedqueries

c'est ici que chacun stocke ses « requêtes personnelles ». Caractéristique très sympa ; avec cela, plus besoin de se casser la tête à mettre un signet sur chaque requète sympa que vous élaborez.

products

indique les produits dont vous disposez, si les nouveaux ajouts de bogues sont permis pour ce produit, sur quel jalon vous travaillez avec ce produit, les votes, etc. Ce sera bien lorsque la table components contiendra les mêmes attributs, de telle façon que l'on puisse bloquer l'ajout de nouveaux bogues pour un composant particulier sans bloquer un produit entier...

profiles

ah, alors vous vous demandiez où vos précieuses informations d'utilisateur étaient gardées ? C'est ici ! Avec les mots de passe en clair pour tout le monde ! (mais chuut... n'en parlez pas à vos utilisateurs !)

profiles_activity

vous avez besoin de savoir qui a fait quoi à quel profil utilisateur ? C'est ici que vous le saurez, il s'agit d'un historique assez complet.

versions

informations sur la version de chaque produit.

votes

qui a voté pour quoi et quand.

watch

qui (relativement au userid) consulte les bogues de qui (relativement à leur userid).

5.1.1.1. Les détails

Ah, alors vous vous demandez que faire des informations ci-dessus ? À l'invite de commande vous pouvez visualiser les informations sur n'importe quelle colonne d'une table grâce à cette commande (où « table » est le nom de la table que vous souhaitez voir) :

mysql> show columns from table;

Vous pouvez aussi voir toutes les données contenues dans une table avec cette commande :

mysql> select * from table;

	Note
	il est fortement déconseillé de le faire sur, par exemple, la table « bugs » si vous avez 50 000 bogues. Vous pourriez rester planté là un bon moment avant de faire un ctrl-c ou à attendre que les 50 000 bogues s'affichent à l'écran.

Vous pouvez limiter un peu l'affichage ci-dessus avec cette commande où « colonne » est le nom de la colonne à laquelle vous voulez restreindre l'affichage d'information :

mysql> select * from table where (column = "some info");

— ou l'inverse de cela

mysql> select * from table where (column != "some info");

Reprenons l'exemple de l'introduction et supposons que vous ayez besoin de changer le mot « verified » par « approved » dans le champ de résolution. Nous savons depuis la partie précédente que la résolution doit se trouver dans la table « bugs ». Notez que nous devrons changer un peu le code perl en plus de la modification de la base de données mais je ne vais pas aborder cela dans ce document. Vérifions que l'information est bien stockée dans la table « bugs » :

mysql> show columns from bugs
(résultat bien trop long, on l'a raccourci)
| bug_status| enum('UNCONFIRMED','NEW','ASSIGNED','REOPENED','RESOLVED','VERIFIED','CLOSED')||MUL | UNCONFIRMED||

Désolé de cette longue ligne. Nous voyons à partir du résultat que la colonne « bug status » est de type « enum field », ce qui est une particularité de MySQL où un champ de type chaîne de caractères ne peut prendre que certaines valeur en entrée. Bien que je trouve cela vraiment sympa, il ne s'agit pas de SQL standard. Néanmoins, nous avons besoin d'ajouter « APPROVED » dans les valeurs possibles du champ « enum » en modifiant la table « bugs ».

mysql> ALTER table bugs CHANGE bug_status bug_status
    -> enum("UNCONFIRMED", "NEW", "ASSIGNED", "REOPENED", "RESOLVED",
    -> "VERIFIED", "APPROVED", "CLOSED") not null;

(notez que vous pouvez entrer trois lignes ou plus ; tout ce que vous placerez avant le point virgule sera compris comme une seule expression)

Maintenant si vous faites cela :

mysql> show columns from bugs;

vous verrez que le champ bug_status dispose d'un « APPROVED » supplémentaire dans « enum » ! Une autre chose sympa serait que ce changement soit aussi propagé jusqu'à votre page de requête ; vous pouvez effectuer une requête au moyen du nouveau statut. Mais comment cela se propage-t-il dans la réalité des choses ?

Il semble que vous deviez retourner chercher les instances du mot « verified » dans le code perl de Bugzilla ; partout où vous trouvez « verified », remplacez le par « approved » et voilà, ça roule (assurez-vous que la recherche n'est pas sensible à la casse). Bien que vous puissiez effectuer des requêtes grâce au champ « enum », vous ne pouvez donner le statut « APPROVED » à quoi que ce soit avant d'avoir réalisé les changements dans le code perl. Notez que ce changement que j'ai mentionné peut aussi être réalisé en éditant checksetup.pl, qui automatise un bon nombre de choses. Mais vous avez besoin de connaître ce truc aussi, pas vrai ?

Bonsai est un outil orienté web pour gérer CVS, le Concurrent Versioning System . En utilisant Bonsai, les administrateurs peuvent contrôler les états ouverts/fermés des arbres, interroger une base de données relationnelle rapide pour modifier, relier, et commenter des informations, et voir les changements effectués depuis la dernière fois que l'arbre a été fermé. Bonsai s'intègre également avec Tinderbox, the Mozilla automated build management system.

Pour l'instant, l'intégration de CVS se fait mieux en utilisant l'entrée messagerie de Bugzilla.

Suivez les instructions de ce guide pour permettre l'intégration des courriels dans Bugzilla. Faites en sorte que vos scripts d'inscription envoient un courriel à l'entrée messagerie de Bugzilla avec en objet « [Bug XXXX] », et vous pouvez faire ajouter des commentaires d'inscriptions CVS à votre bogue Bugzilla. Si vous voulez que le bogue se ferme automatiquement, vous devrez modifier le script contrib/bugzilla_email_append.pl.

Il y a également un projet CVSZilla, basé sur un code de Bugzilla qui date, pour intégrer CVS et Bugzilla grâce aux capacités de CVS à envoyer des courriels. Allez voir à l'adresse : http://homepages.kcbbs.gen.nz/~tonyg/.

Un autre système capable d'intégrer CVS à Bugzilla est Scmbug. Ce système fournit une intégration générique de la gestion de la configuration du code source avec suivi des bogues. Jetez-y un œil à l'adresse : http://freshmeat.net/projects/scmbug/.

Vous pouvez trouver la page de projet pour l'intégration de Bugzilla et de Teamtrack Perforce (p4dti) à l'adresse : http://www.ravenbrook.com/project/p4dti/. « p4dti » est maintenant un produit officiellement supporté de Perforce, et vous pouvez trouver la page p4dti « Perforce Public Depot » à l'adresse http://public.perforce.com/public/perforce/p4dti/index.html.

L'intégration de Perforce avec Bugzilla, une fois que les correctifs sont installés, se fait sans difficulté. Les informations de réplication de Perforce apparaîtront au-dessous des commentaires de chaque bogue. Veillez à avoir un ensemble assorti de correctifs pour la version de Bugzilla que vous êtes en train d'installer. p4dti est conçu pour être compatible avec les dispositifs de suivi des défauts multiples, et pour mettre à jour sa propre documentation dans ce but. Veuillez consulter les pages en lien ci-dessus pour de plus amples informations.

Subversion est un système libre de suivi des révisions, conçu pour palier à différentes limites de CVS. L'intégration de Subversion dans Bugzilla est possible en utilisant Scmbug, système qui propose une intégration générique de la gestion de la configuration du code source avec suivi des bogues. Scmbug est disponible à l'adresse : http://freshmeat.net/projects/scmbug/.

Tinderbox est un système de construction en continu pouvant s'intégrer à Bugzilla — consultez http://www.mozilla.org/projects/tinderbox pour plus d'information sur Tinderbox et http://tinderbox.mozilla.org/showbuilds.cgi pour le voir à l'œuvre.

Le moyen principal pour visualiser un correctif dans Patch Viewer est de cliquer sur le lien « Diff » situé à côté d'un correctif dans la liste des pièces joints d'un bogue. Vous pouvez également y arriver en cliquant sur le bouton « Visualiser le fichier joint en tant que Diff » dans l'écran d'édition des pièces jointes de la fenêtre d'édition.

Pour voir la différence entre deux correctifs, vous devez en premier lieu visualiser le correctif le plus récent dans Patch Viewer. Puis sélectionnez le correctif le plus ancien dans le menu déroulant en haut de la page (« Différences entre menu déroulant et ce correctif ») et cliquez sur le bouton « Diff ». Vous verrez ainsi ce qui est nouveau ou ce qui a changé dans le correctif le plus récent.

Afin d'obtenir plus de contexte dans un correctif, indiquez un nombre dans la zone de texte en haut de Patch Viewer (« Correctif / Fichier / zone de texte ») et appuyez sur Entrée. Cela vous fournira un nombre de lignes relatives au contexte avant et après chaque modification. Une autre possibilité est de cliquer sur le lien « Fichier » présent; cela fera apparaître chaque changement dans l'intégralité du contexte du fichier. Cette fonctionnalité fonctionne avec les fichiers qui ont été mis au format « diff » en utilisant « cvs diff ».

Pour visualiser uniquement un assortiment de fichiers dans un correctif (par exemple, si un correctif est absolument gigantesque et que vous souhaitez n'en revoir qu'une partie à la fois), vous pouvez cliquer sur les liens « (+) » et « (-) » à côté de chaque fichier (afin de le réduire ou de l'étendre). Si vous voulez réduire tous les fichiers ou déployer tous les fichiers, vous pouvez cliquer sur les liens « Réduire tout » et « Étendre tout » du haut de la page.

Pour établir un lien vers une section d'un correctif (par exemple, si vous voulez être en mesure de donner à quelqu'un une URL pour lui indiquer de quelle partie vous parlez), cliquez simplement sur le lien « Établir un lien ici » de l'entête de section. L'URL qui en résulte peut alors être copiée et utilisée dans une discussion. (Copier la cible du lien dans Mozilla fonctionne tout aussi bien.)

Pour aller sur Bonsai afin de voir les responsables des lignes qui vous intéressent, vous pouvez cliquer sur le lien « Lignes XX-YY » de l'entête de section qui vous intéresse. Cela fonctionne même si le correctif correspond à une version ancienne du fichier, puisque Bonsai stocke toutes les versions du fichier.

Pour accéder à LXR, cliquez sur le nom de fichier de l'entête du fichier (malheureusement, puisque LXR ne s'occupe que de la version la plus récente, il est probable que les numéros de ligne ne correspondent plus).

Si le correctif n'est pas dans le format que vous souhaitez, vous pouvez le convertir dans un format diff unifié en cliquant le lien « brut unifié » en haut de la page.

Les commentaires de Bugzilla sont sous forme de texte ordinaire ; Ainsi le fait de taper <U> produira inférieur à, U, supérieur à, au lieu de souligner le texte. Cependant, Bugzilla fera automatiquement la transformation de certains types de textes en liens dans les commentaires. Par exemple, le texte « http://www.bugzilla.org » sera transformé en lien : http://www.bugzilla.org. Les autres chaînes de caractères qui sont transformées en liens de façon classique sont les suivants :

Un corollaire à ceci est que, si vous tapez un numéro de bogue dans un commentaire, vous devez mettre le mot « bug » devant, de façon à ce que le lien soit fait de façon automatique pour que ce soit pratique pour tous.

Quicksearch est un outil de requête muni d'un champ de recherche unique qui emploie des méta-caractères pour indiquer ce qui doit être recherché. Par exemple, si vous tapez « foo|bar » dans Quicksearch, Quicksearch cherchera le mot « foo » ou bien le mot « bar » dans le résumé et le tableau blanc des états d'un bogue ; ajouter « :BazProduct » effectuera la requête seulement dans ce produit.

Vous trouverez le cadre de recherche Quicksearch sur la page d'accueil de Bugzilla, avec un lien d' aide qui explique comment l'utiliser.

Si vous modifiez les champs d'un bogue, n'ajoutez un commentaire que si vous avez quelque chose de pertinent à dire, ou si Bugzilla l'exige. Autrement, votre modification pourrait entraîner l'envoi de courriels inutiles à certaines personnes. Pour prendre un exemple : un utilisateur peut configurer son compte de façon à filtrer les messages par lesquels quelqu'un s'ajoute simplement à la zone de cc d'un bogue (ce qui se produit souvent). Si vous vous ajoutez dans la zone « cc », et ajoutez un commentaire disant « je m'ajoute dans la rubrique CC », la personne obtiendra un courriel sans intérêt qu'elle aurait autrement évité.

N'utilisez pas les signatures dans les commentaires. Signer avec votre nom (« Bill ») est acceptable, en particulier si vous avez l'habitude de le faire, mais des créations artistiques surchargées en ASCII de plusieurs lignes ne le sont pas.

Utilisez les pièces jointes, plutôt que les commentaires, pour de grandes quantités de données ASCII, tels que les fichiers de traçage, ou les fichiers de log de débogage. C'est pour éviter d'infliger des bogues surchargés à ceux qui veulent les lire, et pour qu'ils ne reçoivent pas des courriers inutiles et de taille importante.

Allégez les copies d'écrans. Il n'est pas nécessaire de montrer l'écran entier pour signaler un problème qui peut être illustré avec seulement quelques pixels.

Ne joignez pas des cas qui constituent des précédents (par exemple un fichier HTML, un fichier CSS et une image) comme fichier ZIP. Au lieu de cela, envoyez-les dans l'ordre inverse et éditez le fichier référent de sorte qu'il pointe vers les fichiers joints. De cette façon, le cas qui constitue un précédent fonctionne immédiatement hors du bogue.

Bugzilla stocke et utilise un type de contenu pour chaque pièce jointe (par exemple text/html). Pour télécharger une pièce jointe présentant un type de contenu différent (par exemple application/xhtml+xml), vous pouvez prendre la main en utilisant un paramètre 'content-type' dans l'URL, par exemple &content-type=text/plain.

Dans cette partie, vous pouvez changer les informations de base sur votre compte, y compris votre mot de passe, votre adresse électronique et votre vrai nom. Pour des raisons de sécurité, avant de changer quoi que ce soit sur cette page, vous devez taper votre mot de passe actuel dans la zone « Mot de passe » située en haut de la page. Si vous essayez de changer votre adresse électronique, un courriel de confirmation sera envoyé aussi bien à votre ancienne qu'à votre nouvelle adresse, avec un lien à utiliser pour confirmer le changement. Ceci a pour but d'essayer d'empêcher le détournement de compte.

Cet onglet contrôle la quantité de courriels que Bugzilla vous envoie.

Le premier élément sur cette page s'intitule « Utilisateurs à observer ». Si vous entrez un ou plusieurs comptes utilisateurs, séparés par des virgules, dans la zone de texte, vous recevrez une copie de tous les courriels de rapport de bogue envoyés à ces utilisateurs (si les paramètres de sécurité le permettent). Cette puissante fonctionnalité permet de réaliser des transitions en douceur lorsque des développeurs changent de projet, ou que des utilisateurs partent en vacances.

	Note
	La capacité à observer d'autres utilisateurs pourrait ne pas s'avérer disponible sur toutes les installations de Bugzilla. Si vous ne voyez pas cette fonctionnalité et que vous pensez en avoir besoin, parlez-en à votre administrateur.

En général, les utilisateurs ont quasiment un contrôle complet de la quantité (importante ou faible) de courriels que Bugzilla leur envoie. Si vous souhaitez recevoir la quantité maximum de courriels possible, cliquez sur le bouton « Activer tous les courriels ». Si vous souhaitez ne recevoir aucun courriel de Bugzilla, cliquez sur le bouton « Désactiver tous les courriels ».

	Note
	Votre administrateur Bugzilla peut empêcher un utilisateur de recevoir des courriels de rapport de bogue en ajoutant le nom de l'utilisateur dans le fichier data/nomail. Il s'agit d'un dernier recours, utilisé à bon escient uniquement dans le cas des comptes désactivés, puisqu'il supplante les préférences de courriels individuelles des utilisateurs.

Si vous désirez régler vos courriels de rapport de bogue à un niveau autre que « Complètement Activé » et « Complètement Désactivé », c'est précisément le tableau « Champ/Options spécifique du destinataire » qui vous permet de le faire. Les lignes du tableau définissent les évènements pouvant survenir sur un bogue, comme par exemple l'ajout de pièces jointes, de nouveaux commentaires, un changement de priorité, etc. Les colonnes du tableau définissent votre relation avec le bogue :

	Note
	Certaines colonnes peuvent s'avérer être invisibles dans votre installation, cela dépend de la configuration de votre site.

Afin de paramétrer au mieux vos courriels de rapports de bogue, choisissez donc les évènements pour lesquels vous souhaitez recevoir des courriels de rapport de bogue; puis choisissez si vous voulez en recevoir en permanence (activez la case à cocher pour toutes les colonnes), ou seulement lorsque vous avez une certaine relation avec un bogue (n'activez la case à cocher que pour ces colonnes). Par exemple : si vous ne vouliez pas recevoir de courriel lorsque quelqu'un s'ajoute à la liste CC, vous pourriez décocher toutes les cases de la ligne « Changements dans le champ CC ». Un autre exemple : si vous vouliez ne jamais recevoir de courriels à propos des bogues que vous signalez tant que ceux-ci n'ont pas été traités, vous pourriez décocher toutes les cases de la colonne « Rapporteur » à part celle correspondant à la ligne « Le bogue est traité ou vérifié ».

	Note
	Bugzilla ajoute l'entête « X-Bugzilla-Reason » à tous les courriels qu'il envoie, en y décrivant la relation du destinataire avec le bogue (AssignéÀ, Rapporteur, ContactQA, CC ou Votant). Cet en-tête peut être utilisé pour poursuivre le filtrage du côté client.

Deux éléments hors du tableau (« M'envoyer un courriel lorsque quelqu'un me demande de positionner un fanion » et « M'envoyer un courriel lorsque quelqu'un positionne un fanion dont j'ai fait la demande ») définissent la manière dont vous souhaitez recevoir les courriels de rapport de bogue au vu des fanions. Leur utilisation est assez simple : activez les cases à cocher si vous voulez que Bugzilla vous envoie des courriels à l'une ou l'autre des conditions ci-dessus.

Par défaut, Bugzilla envoie des courriels sans se préoccuper de qui a effectué le changement... même si vous étiez au départ le responsable de l'envoi du courriel. Si ça ne vous intéresse pas de recevoir des courriels de rapport de bogue dûs à vos propres changements, cochez la case marquée « M'envoyer uniquement les rapports de changements effectués par d'autres personnes ».

C'est une page purement informative qui décrit vos permissions en cours sur cette installation de Bugzilla : à quels groupes de produit vous appartenez, et si vous pouvez éditer les bogues ou assurer diverses fonctions d'administration.

Un rapport est une vue de l'état courant de la base de données des bogues.

Vous pouvez lancer soit un rapport basé sur des tableaux HTML, soit un rapport graphique de type courbe/camembert/histogramme. Les deux présentent différentes pages pour les définir, mais sont de proches cousins ; une fois que vous avez défini et visualisé un rapport, vous pouvez passer à votre guise de l'une à l'autre des différentes représentations des données.

Les deux types de rapports ont pour principe de définir un groupe de bogues en utilisant l'interface de recherche standard, puis en choisissant certains aspects de ce groupe que vous voulez représenter sur les axes horizontal et/ou vertical. Vous pouvez également obtenir une sorte de rapport tridimensionnel en choisissant d'avoir de multiples images ou tableaux.

Ainsi, par exemple, vous pourriez utiliser le format recherche pour choisir « tous les bogues du produit WorldControl », puis tracer leur degré de gravité par rapport à leur composants, afin d'observer quel composant a eu le plus grand nombre de mauvais bogues signalés.

Une fois que vous avez défini vos paramètres et cliqué sur « Générer le rapport », vous pouvez choisir entre HTML, CSV, Histogramme, Courbe et Camembert. (Note : Le camembert n'est disponible que si vous ne définissez pas d'axe vertical, puisque les diagrammes camembert n'en ont pas) Les autres commandes sont largement explicites ; vous pouvez changer la taille de l'image si les textes se superposent, ou que vous ne voyez pas les barres parce-qu'elles sont trop fines.

Un diagramme est une représentation de l'état de la base de données par rapport au temps.

Bugzilla possède deux systèmes de diagrammes : les anciens diagrammes et les nouveaux diagrammes. Les anciens diagrammes font partie de Bugzilla depuis longtemps ; ils représentent chaque statut et chaque résolution pour chaque produit, et c'est tout. Ils sont dénigrés et vont bientôt disparaître ; nous ne nous étendrons pas plus là-dessus. L'avenir est dans les nouveaux diagrammes : ils vous permettent de représenter tout ce que vous pouvez définir comme étant une recherche.

	Note
	Les deux formes de diagrammes requièrent la configuration du script collecteur de données par l'administrateur. Si vous ne pouvez voir aucun diagramme, demandez lui s'il a pris les dispositions nécessaires.

Une courbe particulière sur un diagramme s'appelle une série de données. Tous les ensembles de données sont organisés en catégories et sous-catégories. Les séries de données que Bugzilla définit automatiquement utilisent le nom de produit comme catégorie et les noms des composants comme sous-catégorie, mais il n'est pas nécessaire de respecter ce schéma de noms avec vos propres diagrammes si vous ne le souhaitez pas.

Les séries de données peuvent être publics ou privés. Tout le monde voit les séries de données publics dans la liste mais seul leur créateur peut voir les séries de données privés. Seuls les administrateurs peuvent rendre un ensemble de données public. Deux ensembles de données, mêmes s'ils sont privés, ne peuvent pas avoir le même ensemble de catégorie, sous-catégorie et nom. Ainsi, si vous créez des séries de données privés, c'est une bonne idée que de mettre votre nom d'utilisateur dans la catégorie.