Le livre de Bugzilla -- version 2.18 Version française du livre The Bugzilla Guide (2005-01-14) L'équipe Bugzilla Adaptation française: Zahir Abdelouhab, Laurent Damour, Mathieu Vinel Adaptation française de la version 2.16.4: Romain Conseil, Guillaume Huray, Mickaël Lagneaux, Guillaume Tanguy Relecture: Yvon Benoist, Isabelle Hurbain, Emmanuel Seyman Relecture de la version 2.16.4: Yvon Benoist, Guillaume Lelarge Préparation de la publication de la v.f.: Jean-Philippe Guérard Version : 2.18.fr.1.0 9 novembre 2005 +------------------------------------------------------------------------+ | Historique des versions | |------------------------------------------------------------------------| | Version 2.18.fr.1.0 | 2005-08-25 | ZA, LD, MV, YB, IH, | | | | ES, JPG | |------------------------------------------------------------------------| | Mise à jour de l'adaptation française par une équipe | | d'élèves-ingénieurs en 4e et 5e année (Architecture des Systèmes | | d'Information) de l'INSA de Rouen. | |------------------------------------------------------------------------| | Version 2.18 | 2005-01-14 | ÉB | |-----------------------------+------------------+-----------------------| | Version 2.16.4.fr.1.0 | 2004-08-25 | RC, GH, ML, GT, YB, | | | | GL, JPG | |------------------------------------------------------------------------| | Première adaptation française par une équipe d'élèves-ingénieurs en 4e | | et 5e année (Architecture des Systèmes d'Information) de l'INSA de | | Rouen. | |------------------------------------------------------------------------| | Version 2.16.4 | 2003-11-01 | MPB, ÉB | +------------------------------------------------------------------------+ Résumé Ce livre est la documentation de Bugzilla, le système de suivi de bogues de mozilla.org. Bugzilla est un logiciel de qualité professionnelle qui permet à des centaines d'organismes dans le monde de suivre des millions d'anomalies. La version la plus récente de ce livre est toujours disponible sur la page du livre Bugzilla [http://www.bugzilla.org/documentation.html]. -------------------------------------------------------------------------- Table des matières 1. À propos de ce guide 1. Droits d'utilisation (Copyright Information) 2. Avertissement (Disclaimer) 3. Nouvelles versions 4. Remerciements 5. Conventions de ce document 2. Installer Bugzilla 1. Installation 1.1. Perl 1.2. MySQL 1.3. Serveur Web 1.4. Bugzilla 1.5. Modules Perl 1.6. Mail Transfer Agent (MTA) 2. Configuration 2.1. localconfig 2.2. MySQL 2.3. checksetup.pl 2.4. Web server 2.5. Bugzilla 3. Configuration supplémentaire facultative 3.1. Les graphiques de bogues 3.2. Diagrammes de dépendance 3.3. Le planificateur de pleurnicherie 3.4. Patch Viewer 3.5. Authentification LDAP 3.6. Traitement des formats différents avec le type de MIME adéquat 4. Notes d'installation sur un SE particulier 4.1. Microsoft Windows 4.2. Mac OS X(TM) 4.3. Linux-Mandrake 8.0 5. Notes d'installation sous UNIX (non administrateur) 5.1. Introduction 5.2. MySQL 5.3. Perl 5.4. Les modules Perl 5.5. Serveur HTTP 5.6. Bugzilla 3. Administrer Bugzilla 1. Configuration de Bugzilla 2. Administration des utilisateurs 2.1. Créer l'utilisateur par défaut 2.2. Gérer les autres utilisateurs 3. Produits 4. Composants 5. Versions 6. Cibles Jalon 7. Fanions 7.1. Exemple simple 7.2. À propos des fanions 7.3. Utilisation des requêtes par fanions 7.4. Deux types de fanions 7.5. Administration des fanions 8. Le vote 9. Les mots d'esprit 10. Groupes et sécurité des groupes 10.1. Création des groupes 10.2. Affecter des utilisateurs aux groupes 10.3. Affecter les commandes de groupe aux produits 10.4. Applications courantes des commandes de groupe 11. Mise à niveau aux nouvelles versions 4. Sécurité de Bugzilla 1. Le système d'exploitation 1.1. Ports TCP/IP 1.2. Comptes utilisateur du système 1.3. Environnement d'exécution fermé 2. MySQL 2.1. Les comptes Système MySQL 2.2. Le super utilisateur et l'utilisateur anonyme de MySQL 2.3. Accès au réseau 3. Serveur Web 3.1. Désactivation des accès à distance pour les fichiers de configuration Bugzilla 3.2. Utilisation de mod_throttle pour éviter un déni de service 4. Bugzilla 4.1. Empêcher les utilisateurs d'introduire du Javascript malveillant 5. Personnalisation de Bugzilla 1. Personnalisation des modèles 1.1. Structure du répertoire de modèles 1.2. Choix d'une méthode de personnalisation 1.3. Méthode d'édition de modèles 1.4. Formats et type des modèles 1.5. Modèles particuliers 1.6. Configurer Bugzilla pour détecter la langue de l'utilisateur 2. Crochets de modèles 3. Personnalisation : Qui peut faire quoi ? 4. Modifier votre système en fonctionnement 5. Introduction à la base de données MySQL de Bugzilla 5.1. Les fondamentaux de la base de données de Bugzilla 6. Intégrer Bugzilla avec des outils tiers 6.1. Bonsai 6.2. CVS 6.3. Perforce SCM 6.4. Subversion 6.5. Tinderbox/Tinderbox2 6. L'utilisation de Bugzilla 1. Introduction 2. Créez un compte Bugzilla 3. Anatomie d'un bogue 4. Cycle de vie d'un bogue de Bugzilla 5. Recherche de bogues 6. Listes de Bogues 7. Établissement d'un rapport de bogue 8. Visualisateur de correctifs 8.1. Consultation des correctifs dans Patch Viewer 8.2. Voir la différence entre deux correctifs 8.3. Obtenir plus de contexte dans un correctif 8.4. Réduction et déploiement des sections d'un correctif 8.5. Établir un lien vers une section d'un correctif 8.6. Se rendre sur Bonzai et LXR 8.7. Créer un diff unifié 9. Trucs et astuces 9.1. Création automatique de liens 9.2. Quicksearch 9.3. Commentaires 9.4. Pièces jointes 10. Préférences utilisateurs 10.1. Configuration du compte 10.2. Paramètres des courriels 10.3. Permissions 11. Rapports et diagrammes 11.1. Rapports 11.2. Les diagrammes 12. Fanions A. La foire aux questions de Bugzilla B. Résolution des problèmes 1. Conseils généraux 2. Le serveur Web Apache ne m'ouvre pas les pages de Bugzilla 3. J'ai installé un module Perl mais checksetup.pl affirme qu'il n'est pas installé ! 4. Bundle::Bugzilla met à niveau Perl à la version 5.6.1 5. « La préparation de DBD::Sponge::db a échoué » [DBD::Sponge::db prepare failed] 6. « Impossible d'exécuter chdir... » [cannot chdir(/var/spool/mqueue)] 7. « Votre fournisseur n'a pas défini... » [Your vendor has not defined Fcntl macro O_NOINHERIT] 8. On est constamment obligés de se reconnecter 9. Certains utilisateurs sont constamment obligés de se reconnecter 10. index.cgi ne s'affiche pas à moins qu'il ne soit spécifié dans l'URL C. Contrib 1. L'interface de recherche en ligne de commande 2. L'outil « envoi de courriel de bogue non-envoyé » en ligne de commande D. Installation manuelle des modules Perl 1. Instructions 2. Sites de téléchargement 3. Modules optionnels E. GNU Free Documentation License 0. Preamble 1. Applicability and Definition 2. Verbatim Copying 3. Copying in Quantity 4. Modifications 5. Combining Documents 6. Collections of Documents 7. Aggregation with Independent Works 8. Translation 9. Termination 10. Future Revisions of this License How to use this License for your documents Glossaire Liste des illustrations 6.1. Cycle de vie d'un bogue de Bugzilla Liste des exemples 3.1. Mise à niveau par le CVS 3.2. Mettre à niveau avec le tarball 3.3. Mise à niveau avec les correctifs 4.1. Affecter un mot de passe à l'utilisateur « root » de MySQL 4.2. Désactiver l'utilisateur « anonymous » de MySQL 4.3. Désactiver la gestion du réseau dans MySQL 4.4. Obliger Bugzilla à indiquer le codage utilisé (charset) B.1. Exemples de paires urlbase/cookiepath pour le partage des cookies d'ouverture de session B.2. Exemples de paires urlbase/cookiepath pour la restriction du cookie d'ouverture de session Chapitre 1. À propos de ce guide Table des matières 1. Droits d'utilisation (Copyright Information) 2. Avertissement (Disclaimer) 3. Nouvelles versions 4. Remerciements 5. Conventions de ce document 1. Droits d'utilisation (Copyright Information) Les droits d'utilisation de ce document © 2000-2005 appartiennent aux différents contributeurs Bugzilla qui y ont participé. This document is copyright © 2000-2005 by the various Bugzilla contributors who wrote it. Copyright © 2004-2005 Romain Conseil, Guillaume Huray, Mickaël Lagneaux, Guillaume Tanguy, Zahir Abdelouhab, Laurent Damour, Mathieu Vinel, Yvon Benoist, Isabelle Hurbain, Emmanuel Seyman, Guillaume Lelarge et Jean-Philippe Guérard pour la version française. Permission vous est donnée de copier, distribuer et modifier ce document selon les termes de licence de documentation libre GNU, en version 1.1 ou toute version ultérieure publiée par la Free Software Foundation : sans section invariante, sans texte de première ou de quatrième de couverture. Une copie de la licence est incluse dans l'Annexe E, GNU Free Documentation License. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in Annexe E, GNU Free Documentation License. Si vous avez des questions concernant ce document, ses droits d'utilisation ou sur la publication de ce document sous une forme non électronique, veuillez contacter l'équipe Bugzilla (N.D.T. : en anglais, SVP). If you have any questions regarding this document, its copyright, or publishing this document in non-electronic form, please contact the Bugzilla Team. 2. Avertissement (Disclaimer) Nous déclinons toute responsabilité quant au contenu de ce document. Vous utilisez les concepts, exemples et autres contenus du présent document à vos risques et périls. Ce document peut contenir des erreurs et des inexactitudes qui pourraient endommager votre système, provoquer une rupture dans votre couple, pousser votre patron à vous licencier, vos chats à faire pipi sur vos meubles et vêtements, voire déclencher une guerre thermonucléaire mondiale. Agissez avec prudence. No liability for the contents of this document can be accepted. Follow the instructions herein at your own risk. This document may contain errors and inaccuracies that may damage your system, cause your partner to leave you, your boss to fire you, your cats to pee on your furniture and clothing, and global thermonuclear war. Proceed with caution. Le fait de mentionner des marques ou des produits spécifiques ne constitue pas une recommandation, excepté pour ce qui est du terme « GNU/Linux ». Nous approuvons sans réserve l'utilisation de GNU/Linux. C'est un système d'exploitation extrêmement polyvalent, stable et robuste qui offre un environnement idéal de fonctionnement pour Bugzilla. Naming of particular products or brands should not be seen as endorsements, with the exception of the term "GNU/Linux". We wholeheartedly endorse the use of GNU/Linux; it is an extremely versatile, stable, and robust operating system that offers an ideal operating environment for Bugzilla. Bien que l'équipe de développement Bugzilla ait pris grand soin de corriger tous les bogues exploitables, il est bien évident que tout code contient des failles de sécurité. Le plus grand soin devra être pris quant à l'installation et l'utilisation de ce logiciel. Les membres de l'équipe de développement Bugzilla n'assumeront aucune responsabilité quant à l'usage que vous ferez de ce produit. Vous disposez du code source ; vous êtes responsable de le vérifier vous-même afin de vous assurer qu'il répond bien à vos critères en termes de sécurité. Although the Bugzilla development team has taken great care to ensure that all exploitable bugs have been fixed, security holes surely exist in any piece of code. Great care should be taken both in the installation and usage of this software. The Bugzilla development team members assume no liability for your use of Bugzilla. You have the source code, and are responsible for auditing it yourself to ensure your security needs are met. 3. Nouvelles versions Ceci est la version 2.18 du Guide Bugzilla. Elle est ainsi numérotée pour correspondre à la version de Bugzilla avec laquelle elle est distribuée. La dernière version de ce guide est toujours disponible à http://www.bugzilla.org [http://www.bugzilla.org], on peut aussi passer par le serveur CVS en suivant les instructions disponibles sur la page CVS de Mozilla [http://www.mozilla.org/cvs.html] et en sortant l'arborescence mozilla/webtools/bugzilla/docs/. Cependant, il est conseillé de lire la version correspondante à celle de Bugzilla que vous employez. Le guide Bugzilla, ou une partie de celui-ci, est aussi disponible dans les langues suivantes : Allemand [http://bugzilla-de.sourceforge.net/docs/html/]. Français [http://www.traduc.org/docs/guides/lecture/bugzilla/]. De plus, il y a des projets d'adaptation linguistique de modèles de Bugzilla dans les langues suivantes. La documentation disponible a peut-être été traduite : Biélorusse [http://sourceforge.net/projects/bugzilla-be/], Portugais Brésilien [http://sourceforge.net/projects/bugzilla-br/], Chinois [http://sourceforge.net/projects/bugzilla-cn/], Français [http://sourceforge.net/projects/bugzilla-fr/], Allemand [http://sourceforge.net/projects/bugzilla-de/], Coréen [http://sourceforge.net/projects/bugzilla-kr/], Russe [http://sourceforge.net/projects/bugzilla-ru/] et Espagnol [http://sourceforge.net/projects/bugzilla-es/]. Si vous voulez vous porter volontaire pour traduire ce guide dans d'autres langues, veuillez entrer en contact avec Dave Miller. 4. Remerciements Les personnes énumérées ci-dessous ont apporté d'énormes contributions à la création de ce guide, par leurs écrits, leur total investissement, de nombreuses séances d'aide par courriels ou IRC, et d'une façon générale leur engagement remarquable envers la communauté de Bugzilla : Matthew P. Barnson pour la tâche herculéenne qui a consisté à rassembler le guide Bugzilla et à le produire en version 2.14. Terry Weissman pour avoir été le premier à écrire Bugzilla et créer le README sur lequel la documentation d'installation UNIX est basée en grande partie. Tara Hernandez pour avoir maintenu le développement de Bugzilla à un rythme soutenu après le départ de Terry de mozilla.org et pour s'occuper de landfill. Dave Lawrence pour avoir fourni un aperçu des principales différences avec le Bugzilla personnalisé de Red Hat. Dawn Endico pour être un extraordinaire mordu d'informatique et avoir supporté les incessantes questions et pinaillages de Matthew sur irc.mozilla.org dans le canal #mozwebtools Jacob Steenhagen pour avoir pris la relève pendant la période de développement de la version 2.17. Dave Miller pour la prise en charge de la direction du projet quand Tara s'est retiré et pour les efforts incessants fournis pour que la documentation soit aussi bonne que possible. Nos remerciements vont également aux personnes suivantes pour leurs contributions significatives à cette documentation : Kevin Brannen, Vlad Dascalu, Ben FrantzDale, Eric Hanson, Zach Lipton, Gervase Markham, Andrew Pearson, Joe Robins, Spencer Smith, Ron Teitelbaum, Shane Travis, Martin Wulffeld. Il faut également remercier les membres du groupe de nouvelles de [1]netscape.public.mozilla.webtools. Sans vos discussions, perspicacité, suggestions, et correctifs, ceci n'aurait jamais pu exister. 5. Conventions de ce document Ce document utilise les conventions suivantes : Descriptions Représentation [2][Attention] Attention Attention Ne courez pas avec des ciseaux ! [3][Astuce] Astuce Conseil Voulez-vous un bonbon à la menthe ? Note [4][Note] Note Cher Jean... [5][Avertissement] Avertissement Information demandant une attention Lisez ceci sinon spéciale le chat va l'attraper. Nom de fichier ou de répertoire fichier Commande à taper commande Nom d'application application Invite de commande d'un utilisateur normal sous l'interpréteur de bash$ commandes bash Invite de commande super utilisateur sous l'interpréteur de commandes bash# bash Invite de commande d'un utilisateur normal sous l'interpréteur de tcsh$ commandes tcsh Variables d'environnement VARIABLE Terme trouvé dans le glossaire Bugzilla Exemple de code Début et fin de paragraphe Cette documentation est maintenue au format DocBook 4.1.2 XML. Il est préférable de soumettre les changements en texte clair ou en XML diff, joints à un bogue référencé dans le composant Bugzilla Documentation [http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation]. Chapitre 2. Installer Bugzilla Table des matières 1. Installation 1.1. Perl 1.2. MySQL 1.3. Serveur Web 1.4. Bugzilla 1.5. Modules Perl 1.6. Mail Transfer Agent (MTA) 2. Configuration 2.1. localconfig 2.2. MySQL 2.3. checksetup.pl 2.4. Web server 2.5. Bugzilla 3. Configuration supplémentaire facultative 3.1. Les graphiques de bogues 3.2. Diagrammes de dépendance 3.3. Le planificateur de pleurnicherie 3.4. Patch Viewer 3.5. Authentification LDAP 3.6. Traitement des formats différents avec le type de MIME adéquat 4. Notes d'installation sur un SE particulier 4.1. Microsoft Windows 4.2. Mac OS X(TM) 4.3. Linux-Mandrake 8.0 5. Notes d'installation sous UNIX (non administrateur) 5.1. Introduction 5.2. MySQL 5.3. Perl 5.4. Les modules Perl 5.5. Serveur HTTP 5.6. Bugzilla 1. Installation [6][Note] Note Si vous voulez juste utiliser Bugzilla, vous n'avez pas besoin de l'installer. Ce chapitre ne vous concerne pas. Demandez l'URL à votre administrateur de Bugzilla pour y accéder sur le web. Le serveur Bugzilla est généralement installé sur Linux ou Solaris. Si vous êtes en train d'installer un autre système d'exploitation, consultez Section 4, « Notes d'installation sur un SE particulier » la section 2.4 avant de commencer votre installation pour voir si il n'y a pas d'instructions particulières. Comme alternative pour suivre ces instructions, vous pouvez essayer l'installation non officielle et non supportée [http://www.softwaretesting.de/article/view/33/1/8/] de Arne Schimarcher, qui installe Bugzilla et tout le nécessaire sur des systèmes Linux ou Solaris. Dans ce guide, on considère que vous avez un accès administratif à la machine de Bugzilla. Il n'est pas possible d'installer et d'exécuter Bugzilla tout seul sans accès administratif sauf dans le cas très peu probable où chaque élément obligatoire a déjà été installé. [7][Avertissement] Avertissement L'installation peut rendre votre machine vulnérable pendant de courtes périodes de temps. Assurez vous qu'il y a un coupe-feu entre vous et Internet. Il vous est fortement recommandé de faire une sauvegarde de votre système avant d'installer Bugzilla (et à des intervalles réguliers par la suite :-) Dans les grandes lignes, l'installation procède comme suit : 1. Installation de Perl (5.6.0 ou au dessus pour les plates-formes autres que Windows; 5.8.1 pour Windows) 2. Installation de MySQL (3.23.41 ou au dessus) 3. Installation de un serveur Web 4. Installation de Bugzilla 5. Installation des modules de Perl 6. Installation d'un Agent de Transfert de Mail (Sendmail 8.7 ou au dessus, ou un ATM qui est compatible avec Sendmail avec au moins cette version) 7. Configuration de tout ce qui précède. 1.1. Perl 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 [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. 1.2. MySQL 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 [http://www.mysql.com]. Vous avez besoin de MySQL version 3.23.41 ou supérieure. [8][Note] 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. 1.3. Serveur Web Test de la version installée : regardez la page de bienvenue par défaut à http:/// 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 [http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=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/ [http://httpd.apache.org/]. 1.4. Bugzilla 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. [9][Attention] 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. 1.5. Modules Perl 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 ""' 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. [10][Astuce] 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 : 1. AppConfig (1.52) 2. CGI (2.93) 3. Data::Dumper (n'importe) 4. Date::Format (2.21) 5. DBI (1.36) 6. DBD::mysql (2.1010) 7. File::Spec (0.82) 8. File::Temp (n'importe) 9. Template (2.08) 10. Text::Wrap (2001.0131) Modules Perl facultatifs : 1. GD (1.20) pour les graphiques de bogues 2. Chart::Base (1.0) pour les graphiques de bogues 3. GD::Graph (n'importe) pour les graphiques de bogues 4. GD::Text::Align (n'importe) pour les graphiques de bogues 5. XML::Parser (n'importe) pour l'interface XML 6. PatchReader (0.9.4) pour une jolie vue en HTML des correctifs 7. MIME::Parser (n'importe) pour l'interface facultative par courrier électronique 1.5.1. DBD::mysql Au cours du processus d'installation, il vous sera posé quelques questions sur la cible que vous souhaitez pour la compilation et votre installation MySQL. Pour la plupart des questions, la réponse par défaut sera suffisante, mais quand le processus vous demandera si la cible souhaitée est le paquet MySQL ou mSQL, vous devrez choisir celle liée à MySQL. Plus tard, le programme vous demandera si vous voulez conserver une compatibilité inverse avec les paquets MySQL plus anciens. Vous devez répondre OUI alors que la réponse par défaut est NON. Une machine hôte « localhost » sera suffisante. Un utilisateur de tests « test », avec un mot de passe vide, doit avoir les droits d'accès suffisants pour faire des essais sur la base de données de tests « test » que MySQL génère à l'installation. 1.5.2. Template Toolkit (2.08) Lors de l'installation de Template Toolkit, une série de questions vous sera posée à propos des fonctionnalités à activer. Les options par défaut conviennent bien, à part qu'il est recommandé d'utiliser le très rapide « XS Stash » du Template Toolkit, pour réaliser de meilleures performances. 1.5.3. GD (1.20) Le module GD n'est nécessaire que si vous voulez des rapports graphiques. [11][Note] 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. [12][Astuce] 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. 1.5.4. Chart::Base (1.0) Le module Chart::Base n'est nécessaire que si vous voulez des rapports graphiques. Notez que les versions antérieures à 0.99c utilisaient les GIF, mais ils ne sont plus supportés par les dernières versions de GD. 1.5.5. GD::Graph (n'importe) Le module GD::Graph n'est nécessaire que si vous voulez des rapports graphiques. 1.5.6. GD::Text::Align (n'importe) Le module GD::Text::Align n'est nécessaire que si vous voulez des rapports graphiques. 1.5.7. XML::Parser (n'importe) Le module XML::Parser n'est nécessaire que si vous souhaitez importer les bogues XML en utilisant le script importxml.pl. Ceci est nécessaire pour utiliser la fonctionnalité « changement d'état d'un bogue » [« move bugs »] de Bugzilla ; vous aurez peut-être également besoin de l'utiliser pour un déplacement en provenance d'une autre base de données de bogues. XML::Parser a besoin que la bibliothèque expat soit déjà installée sur votre machine. 1.5.8. MIME::Parser (n'importe) Le module MIME::Parser est nécessaire seulement si vous voulez utiliser l'interface de messagerie électronique située dans le répertoire contrib. 1.5.9. PatchReader (0.9.4) Le module PatchReader est nécessaire seulement si vous voulez utiliser le « Patch Viewer », fonctionnalité de Bugzilla qui permet de montrer des correctifs de code dans votre navigateur WEB sous une forme plus lisible. 1.6. Mail Transfer Agent (MTA) 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. 2. Configuration [13][Avertissement] Avertissement Les installations de MySQL et Bugzilla dont la configuration était médiocre ont permis à des pirates informatiques de s'introduire dans des systèmes par le passé. Veuillez prendre au sérieux les parties de ces instructions qui portent sur la sécurité, même pour les machines Bugzilla bien cachées derrière un coupe-feu. N'oubliez surtout pas de lire les conseils de sécurité importants donnés dans le Chapitre 4, Sécurité de Bugzilla. 2.1. localconfig 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. 2.2. MySQL [14][Attention] Attention La configuration par défaut de MySQL est très vulnérable. Section 2, « MySQL » donne des informations utiles pour améliorer la sécurité de votre installation. 2.2.1. Autoriser les fichiers joints volumineux Par défaut, MySQL acceptera seulement les paquets ayants une taille maximum de 64 ko. Si vous voulez avoir des fichiers joints plus gros que ça, vous devez modifier votre /etc/my.cnf comme indiqué ci-dessous. Si vous utilisez MySQL 4.0 ou plus récente, entrez : [mysqld] # Allow packets up to 1M max_allowed_packet=1M Si vous utilisez une version plus vieille de MySQL, entrez : [mysqld] # Allow packets up to 1M set-variable = max_allowed_packet=1M Il y a aussi un paramètre dans Bugzilla appelé 'maxattachmentsize' (par défaut = 1000 ko) qui contrôle la taille maximum autorisable des pièces jointes. Les pièces jointes plus volumineuses que l'une des deux valeurs 'max_allowed_packet' ou 'maxattachmentsize' ne seront pas acceptées par Bugzilla. 2.2.2. Autoriser les mots courts dans les index en texte intégral Par défaut, les mots doivent avoir une longueur d'au moins quatre caractères pour être indexés dans les index en texte intégral de Bugzilla. En conséquence beaucoup de mots spécifiques à Bugzilla ne sont pas pris en compte, parmi lesquels « cc », « ftp » et « uri ». MySQL peut être configuré pour indexer ces mots en réglant le paramètre ft_min_word_len à la taille minimum des mots à indexer. Ceci peut être fait en modifiant le /etc/my.cnf selon l'exemple ci-dessous : [mysqld] # Allow small words in full-text indexes ft_min_word_len=2 La reconstruction des index peut être faite en s'appuyant sur la documentation trouvée à http://www.mysql.com/doc/en/Fulltext_Fine-tuning.html [http://www.mysql.com/doc/en/Fulltext_Fine-tuning.html]. (N.D.T. : la version française se trouve à http://www.mysql.com/doc/fr/Fulltext_Fine-tuning.html [http://www.mysql.com/doc/fr/Fulltext_Fine-tuning.html]). [15][Note] Note Le paramètre Ft_min_word_len est supporté seulement dans MySQL v4 ou supérieure. 2.2.3. Permettre à la table des fichiers joints de passer à une taille supérieure à 4 Go Par défaut, MySQL limitera la taille de la table à 4 Go. Cette limite existe même si le système de fichiers sous-jacent n'a pas une telle limite. Pour fixer une limite plus haute, suivez les instructions suivantes. Exécutez le client en ligne de commande MySQL et entrez : mysql> ALTER TABLE attachments AVG_ROW_LENGTH=1000000, MAX_ROWS=20000; La commande ci-dessus fera passer à 20 Go. Mysql devra faire une copie temporaire de l'intégralité de votre table pour cela. Idéalement, vous devriez faire ça quand la table est encore petite. 2.2.4. Ajouter un utilisateur à MySQL Vous devez ajouter un nouvel utilisateur que Bugzilla puisse utiliser. (Il n'est pas prudent que Bugzilla utilise le compte root de MySQL.) Les instructions suivantes supposent que les paramètres par défaut sont dans localconfig; si vous changez ces derniers, vous devez changer la commande MySQL de façon appropriée. Vous aurez besoin du mot de passe $db_pass vous avez mis dans localconfig dans Section 2.1, « localconfig ». Nous utilisons la commande SQL GRANT pour créer un utilisateur « bugs ». Cela restreint également les opérations de l'utilisateur « bugs » à celles agissant sur la base de données « bugs » et n'autorise le compte à se connecter que depuis « localhost ». Modifiez cela en fonction de votre configuration si vous devez vous connecter plus tard depuis une autre machine ou sous un autre utilisateur. Exécutez le client en ligne de commande mysql. Si vous utilisez MySQL 4.0 ou plus récent, entrez : mysql> GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE, LOCK TABLES, CREATE TEMPORARY TABLES, DROP, REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY '$db_pass'; mysql> FLUSH PRIVILEGES; Si vous utilisez une version plus ancienne de MySQL, les permissions de LOCK TABLES et CREATE TEMPORARY TABLES seront indisponibles et doivent être supprimées de la liste des permissions. Dans ce cas, on peut utiliser la ligne de commande suivante : mysql> GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER, CREATE, DROP, REFERENCES ON bugs.* TO bugs@localhost IDENTIFIED BY '$db_pass'; mysql> FLUSH PRIVILEGES; 2.3. checksetup.pl 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. 2.4. Web server 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 ». 2.4.1. httpd(TM) d'Apache Chargez httpd.conf dans votre editeur. Décommentez (ou ajouter) la ligne suivante. Ceci autorise Apache à exécuter les fichiers .cgi files en dehors du répertoire cgi-bin. AddHandler cgi-script .cgi Apache utilise les directives pour peaufiner les droits. Ajoutez les deux lignes suivantes à une directive qui s'applique soît au répertoire Bugzilla ou l'un de ses parents (i.e. la directive ). Ceci autorisent les fichiers .htaccess de Bugzilla à outrepasser les permissions globales. et permet aux fichiers .cgi de tourner dans le répertoire Bugzilla. Options +ExecCGI +FollowSymLinks AllowOverride Limit Ajoutez index.cgi à la fin de la ligne DirectoryIndex. checksetup.pl peut mettre des permissions plus restreintes sur les fichiers et les répertoires de Bugzilla si il sait en tant que quel groupe le serveur web est exécuté. Trouvez la ligne Group dans httpd.conf et placez la valeur que vous y trouvez dans la variable $webservergroup dans localconfig. Puis réexécutez checksetup.pl. 2.4.2. Internet Information Services(TM) de Microsoft Si vous êtes en train d'exécuter Bugzilla sous Windows et que vous choisissez d'utiliser Internet Information Services(TM) ou Personal Web Server(TM) 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 [http://support.microsoft.com/default.aspx?scid=kb;en-us;245225] « HOW TO: Configure and Test a PERL Script with IIS 4.0, 5.0, and 5.1 » (pour Internet Information Services(TM)) (N.D.T. : « HOW TO : configurez et testez un script PERL avec IIS 4.0, 5.0 et 5.1 » [http://support.microsoft.com/default.aspx?scid=kb;fr-fr;245225]) et 231998 [http://support.microsoft.com/default.aspx?scid=kb;en-us;231998] « HOW TO: FP2000: How to Use Perl with Microsoft Personal Web Server on Windows 95/98 » (pour Personal Web Server(TM)) (N.D.T. : « HOW TO : FP2000 : Perl utilisation avec serveur Web personnel Microsoft sous Windows 95/98 » [http://support.microsoft.com/default.aspx?scid=kb;fr-fr;231998]). 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:///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 : \perl.exe -x -wT "%s" %s Par exemple : c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s [16][Note] 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" } [17][Avertissement] 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 [http://bugzilla.mozilla.org/show_bug.cgi?id=186383] ou Bugtraq ID 6501 [http://online.securityfocus.com/bid/6501]. [18][Note] 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 [http://www.graphviz.org], vous devrez autoriser tout le monde à accéder aux *.png, *.gif, *.jpg et *.map dans le répertoire data/webdot. 2.5. Bugzilla Votre Bugzilla devrait maintenant fonctionner. Allez sur http:/// -- 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 ». 3. Configuration supplémentaire facultative Bugzilla a un nombre important d'options. Cette section décrit comment les configurer ou les activer. 3.1. Les graphiques de bogues 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 ; ./collectstats.pl Deux jours après, vous pourrez visualiser les graphiques de bogues depuis la page de rapport de bogue. [19][Note] 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 [http://www.nncron.ru/]. 3.2. Diagrammes de dépendance 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 : 1. Le chemin d'accès complet à la commande 'dot' (qui fait partie de GraphViz [http://www.graphviz.org/]) qui va générer les graphiques localement. 2. Un préfixe URL pointant vers une installation du logiciel webdot qui va générer les graphiques à distance. 3. Une valeur nulle qui désactive les graphiques de dépendance. La façon la plus simple de le faire fonctionner est d'installer GraphViz [http://www.graphviz.org/]. Dans ce cas, vous devez activer les cartes d'image côté serveur [http://httpd.apache.org/docs/mod/mod_imap.html] 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... 3.3. Le planificateur de pleurnicherie 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 ; ./whineatnews.pl [20][Note] 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 [http://www.nncron.ru/]. 3.4. Patch Viewer 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/ [http://cyberelk.net/tim/patchutils/]. Si ces programmes ne sont pas dans le chemin du système, vous pouvez configurer leurs emplacements dans localconfig. 3.5. Authentification LDAP 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. [21][Attention] 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 [http://bugzilla.mozilla.org/show_bug.cgi?id=201069]. Paramètres requis pour utiliser l'authentification LDAP : loginmethod Ce paramètre doit être fixé à « LDAP » seulement si vous allez utiliser un répertoire LDAP pour l'authentification. Si vous mettez ce paramètre à « LDAP » mais que vous ne réglez pas les autres paramètres de la liste ci-dessous, vous ne pourrez pas vous reconnecter à Bugzilla une fois que vous serez déconnecté. Si cela vous arrive, vous devrez éditer manuellement data/params et mettre loginmethod à « DB ». LDAPserver Pour ce paramètre, vous devez indiquer le nom (et le port si vous le souhaitez) de votre serveur LDAP. Si le port n'est pas spécifié, il considère que c'est le port LPDA par défaut 389. Ex. « ldap.company.com » ou « ldap.company.com:3268 » LDAPbinddn [Optional] Certains serveurs LDAP n'autoriseront pas une connexion anonyme à faire une recherche dans le répertoire. Si c'est le cas pour votre configuration, vous devrez régler le paramètre LDAPbinddn au compte de l'utilisateur que Bugzilla devra utiliser à la place de la connexion anonyme. Ex. « cn=default,cn=user:password » LDAPBaseDN Pour le paramètre LDAPBaseDN vous devrez indiquer l'emplacement dans votre arborescence LDAP où vous aimeriez que se fasse la recherche des adresses électroniques. Vos identifiants UID devraient être uniques sous la base DN indiqués ici. Ex. « ou=People,o=Company » LDAPuidattribute Pour le paramètre LDAPuidattribute vous devrez indiquer l'attribut qui contient l'UID unique de vos utilisateurs. La valeur récupérée de cet attribut sera utilisée quand ils essayeront de se connecter en tant qu'utilisateur pour confirmer leur mot de passe. Ex. « uid » LDAPmailattribute Le paramètre LDAPmailattribute doit être le nom de l'attribut qui contient l'adresse électronique que vos utilisateurs entreront dans les cases d'identification de Bugzilla. Ex. « mail » 3.6. Traitement des formats différents avec le type de MIME adéquat 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 pour votre Bugzilla, soit dans la section pour votre Bugzilla : AddType application/vnd.mozilla.xul+xml .xul AddType text/xml .rdf 4. Notes d'installation sur un SE particulier Le système d'exploitation sur lequel vous avez choisi d'installer Bugzilla peut avoir des effets sur de nombreux aspects de son installation. Selon le système, elle peut être plus facile ou être plus difficile. Cette section a pour but de vous aider à comprendre les difficultés rencontrées en l'exécutant sur un système d'exploitation spécifique ainsi que les utilitaires disponibles pour faciliter les choses. Si vous avez quelque chose à ajouter ou des notes pour un système d'exploitation non traité ici, signalez le dans Bugzilla Documentation [http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla&component=Documentation]. 4.1. Microsoft Windows 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.1. Win32 Perl On peut obtenir Perl pour Windows sur ActiveState [http://www.activestate.com/]. Vous devriez pouvoir trouver un binaire compilé à http://aspn.activestate.com/ASPN/Downloads/ActivePerl/ [http://aspn.activestate.com/ASPN/Downloads/ActivePerl/]. Les instructions suivantes supposent que vous utilisez la version 5.8.1 d'ActiveState. 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 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/ [22][Note] 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. [23][Astuce] 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. 4.1.3. Changements de code nécessaires à l'exécution sur win32 Bugzilla sur win32 est en général supporté du premier coup; il reste le problème lié aux courriels concernant les bogues. Pour qu'ils fonctionnent sous Win32 (jusqu'a la résolution du bogue 49893 [http://bugzilla.mozilla.org/show_bug.cgi?id=49893]), le moyen le plus simple est d'avoir le module de Perl Net::SMTP installé et de remplacer ces lignes dans le fichier Bugzilla/Bugmail.pm : open(SENDMAIL, "|/usr/lib/sendmail $sendmailparam -t -i") || die "Can't open sendmail"; print SENDMAIL trim($msg) . "\n"; close SENDMAIL; par 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; N'oubliez pas de changer le nom de votre serveur SMTP et le domaine de l'adresse d'envoi de courriel (après le '@') dans les lignes de codes ci-dessus. 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 ». [24][Note] Note Si vous utilisez Apache sous Windows, vous pouvez mettre les instructions ScriptInterpreterSource [http://httpd.apache.org/docs-2.0/mod/core.html#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. 4.2. Mac OS X(TM) 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/ [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. [25][Note] 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' [26]1 # perl Makefile.PL EXPATLIBPATH=/sw/lib EXPATINCPATH=/sw/include # make; make test; make install [27]2 # exit [28]3 [29]1 La commande look téléchargera le module et créera un nouveau shell [30]3 avec les fichiers extraits comme répertoire de travail courant. La commande exit vous renverra à votre shell d'origine. [31]2 Il vous faudra surveiller le résultat de ces commandes make, surtout « make test » dont les erreurs peuvent empêcher XML::Parser de fonctionner correctement avec Bugzilla. 4.3. Linux-Mandrake 8.0 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 [32]1 bash# urpmi apache-modules [33]1 pour l'intégration de la messagerie Bugzilla 5. Notes d'installation sous UNIX (non administrateur) 5.1. Introduction 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). 5.2. MySQL 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. [34][Avertissement] 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.) [35][Note] 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. [36][Avertissement] 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 ! 5.3. Perl 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. 5.4. Les modules Perl 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. 5.4.1. La méthode indépendante La méthode indépendante nécessite l'installation de votre propre version de Perl, comme on l'a expliqué dans la section précédente. Une fois installée, vous pouvez lancer l'interpréteur de commandes CPAN avec la commande suivante : bash$ /home/foo/perl/bin/perl -MCPAN -e 'shell' Puis : cpan> install Bundle::Bugzilla Avec cette méthode, l'installation de module se fera généralement avec beaucoup moins de difficultés, mais si vous avez le moindre problème, vous pouvez consulter la section suivante. 5.4.2. La méthode mixte Tout d'abord, vous allez devoir configurer CPAN pour installer les modules dans votre répertoire personnel. Voici ce que dit la FAQ de CPAN à ce sujet : 5) Je ne suis pas administrateur, comment puis-je installer un module dans un répertoire personnel ? Voici une façon de faire qui vous conviendra certainement : o conf makepl_arg "LIB=~/myperl/lib \ INSTALLMAN1DIR=~/myperl/man/man1 \ INSTALLMAN3DIR=~/myperl/man/man3" install Sybase::Sybperl Vous pouvez rendre ce réglage permanent comme tous les paramètres « o conf » à l'aide de : o conf commit Vous devrez ajouter ~/myperl/man à la variable d'environnement MANPATH ainsi qu'indiquer à vos programmes Perl de regarder dans ~/myperl/lib, par exemple en incluant : use lib "$ENV{HOME}/myperl/lib"; ou en réglant la variable d'environnement PERL5LIB. Une autre chose que vous devriez garder à l'esprit est que le paramètre UNINST ne devrait jamais être activé si vous n'êtes pas root. Il vous faudra donc créer un répertoire Perl dans votre répertoire personnel, ainsi que les répertoires lib, man, man/man1, et man/man3 dans ce répertoire Perl. Réglez la variable MANPATH et la variable PERL5LIB afin que l'installation des modules se fasse sans difficulté (régler UNINST=0 dans vos options « make install » lors de la première configuration de CPAN est aussi une bonne idée). Ensuite, allez dans l'interpréteur de commandes CPAN : bash$ perl -MCPAN -e 'shell' À partir de là, vous allez devoir entrer la commande « o conf » présentée plus haut et valider les changements. Puis vous pouvez lancer l'installation : cpan> install Bundle::Bugzilla L'essentiel du processus d'installation de module devrait se passer sans accrocs. Cependant, il se peut que vous ayez des problèmes avec Template. Pour commencer, il va falloir essayer d'installer Template avec les options XS Stash activée. Si ça ne marche pas, il se peut qu'on vous balance des messages d'erreur du compilateur C et qu'on vous renvoie à l'invite de l'interpréteur de commande CPAN. Dans ce cas, recommencez l'installation, et désactivez cette option. (En fait, répondez non à toutes les questions sur Template.) Il est également possible que le processus échoue à quelques tests. Si, au final, le taux de réussite aux tests est raisonnable (90+%), forcez l'installation à l'aide de la commande suivante : cpan> force install Template Si vous le souhaitez, vous pouvez aussi installer les autres modules optionnels : cpan> install GD cpan> install Chart::Base cpan> install MIME::Parser 5.5. Serveur HTTP 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é. [37][Note] 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. [38][Avertissement] 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 ! 5.6. Bugzilla 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. [39][Avertissement] 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. Chapitre 3. Administrer Bugzilla Table des matières 1. Configuration de Bugzilla 2. Administration des utilisateurs 2.1. Créer l'utilisateur par défaut 2.2. Gérer les autres utilisateurs 3. Produits 4. Composants 5. Versions 6. Cibles Jalon 7. Fanions 7.1. Exemple simple 7.2. À propos des fanions 7.3. Utilisation des requêtes par fanions 7.4. Deux types de fanions 7.5. Administration des fanions 8. Le vote 9. Les mots d'esprit 10. Groupes et sécurité des groupes 10.1. Création des groupes 10.2. Affecter des utilisateurs aux groupes 10.3. Affecter les commandes de groupe aux produits 10.4. Applications courantes des commandes de groupe 11. Mise à niveau aux nouvelles versions 1. Configuration de Bugzilla Pour configurer Bugzilla, il faut changer différents paramètres accessibles à partir du lien « Edit parameters » au bas de la page. Voici quelques-uns des paramètres importants de cette page. Il faut parcourir cette liste et les remplir correctement après l'installation de Bugzilla. 1. 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. 2. 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/. 3. makeproductgroups : permet de créer automatiquement ou pas des groupes quand des produits nouveaux sont créés. 4. 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. 5. 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. 6. 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é. [40][Note] 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. 7. 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. 8. 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. 9. 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. 10. 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. 11. 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). 12. 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. [41][Note] 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é !). 13. 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. 14. 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. 2. Administration des utilisateurs 2.1. Créer l'utilisateur par défaut 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. [42][Astuce] 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. 2.2. Gérer les autres utilisateurs 2.2.1. Créer de nouveaux utilisateurs Vos utilisateurs peuvent créer leurs propres comptes utilisateur en cliquant sur le lien « Nouveau compte » situé en bas de chaque page (en supposant qu'ils n'aient pas déjà ouvert une autre session sous un autre nom). Toutefois, si vous souhaitez créer les comptes utilisateur à l'avance, voici comment faire. 1. Après avoir ouvert votre session, cliquez sur le lien « Users » situé en bas de la page de requête, puis sur le lien « Add a new user ». 2. Remplissez le formulaire. Cette page est toute simple. Une fois que cela est fait, cliquez sur « Submit ». [43][Note] Note En ajoutant un utilisateur de cette façon, aucun message électronique ne lui sera envoyé pour l'informer de son nom d'utilisateur et de son mot de passe. Bien que cela soit utile pour créer des comptes factices (par exemple, des observateurs qui transmettent et reçoivent des messages électroniques à un autre système, ou des adresses électroniques qui font partie d'une liste de diffusion), il est, en général, préférable de fermer sa session et d'utiliser le bouton « New account » pour créer des utilisateurs, car tous les champs obligatoires seront remplis à l'avance et l'utilisateur sera également informé du nom de son compte et de son mot de passe. 2.2.2. Modifier les utilisateurs Pour voir un utilisateur particulier, recherchez-le en tapant son nom d'utilisateur dans la case prévue sur la page « Edit Users ». Pour voir tous les utilisateurs, laissez la case vide. Vous pouvez effectuer des recherches de différentes façons grâce à la liste déroulante située à droite de la zone de texte. Vous pouvez rechercher à partir d'une sous-chaîne (par défaut sans tenir compte de la casse), d'une expression rationnelle ou d'une expression rationnelle inverse, qui trouve tous les utilisateurs qui ne correspondent pas à l'expression rationnelle (Veuillez vous reporter au manuel issu de la commande man regexp pour des informations sur la syntaxe des expressions rationnelles). Une fois que vous avez trouvé votre utilisateur, vous pouvez changer les champs suivants : o Login Name : en général, c'est l'adresse électronique entière de l'utilisateur. Toutefois, si vous utilisez le paramètre « emailsuffix », ce champ peut contenir uniquement le nom d'utilisateur. On peut noter que les utilisateurs peuvent désormais changer leur nom d'utilisateur eux-mêmes (en le remplaçant par une adresse électronique valide). o Real Name : c'est le nom réel de l'utilisateur. On peut noter que Bugzilla n'exige pas cette information pour créer un compte. o Password : vous pouvez changer le mot de passe utilisateur ici. Les utilisateurs peuvent demander un nouveau mot de passe automatiquement, vous ne devriez donc pas avoir à le faire souvent. Si vous voulez désactiver un compte, reportez-vous à la description de « Disable Text » ci-dessous. o Disable Text : si vous entrez quelque chose dans cette case, ne serait-ce qu'un espace, vous empêchez l'utilisateur d'ouvrir sa session, ou d'apporter des modifications à des bogues via l'interface Internet. Le code HTML que vous tapez dans cette case est affiché à l'utilisateur quand il essaye d'effectuer une de ces actions. Il est conseillé d'y expliquer pourquoi le compte a été désactivé. Les utilisateurs ayant un compte désactivé continueront de recevoir des courriels de Bugzilla; en outre, ils seront incapables de se connecter eux-mêmes pour modifier leur propres préférences et l'arrêter. Si vous voulez qu'un compte (désactivé ou activé) arrête de recevoir des courriels, ajoutez le nom du compte (un compte par ligne) au fichier data/nomail. [44][Note] Note Même les utilisateurs dont le compte a été désactivé peuvent quand même transmettre des bogues via le portail de messagerie électronique, si il en existe une. Pour la sécurité des installations de Bugzilla, le portail de messagerie électronique ne doit pas être activé. [45][Avertissement] Avertissement Ne désactivez pas tous les comptes administrateurs ! o : si vous avez créé des groupes, comme « securitysensitive », des cases apparaîtront ici pour vous permettre d'ajouter ou de supprimer des utilisateurs à ces groupes. o canconfirm : ce champ n'est utilisé que si vous avez autorisé l'état « unconfirmed ». Si vous activez ce champ pour un utilisateur, celui-ci pourra passer des bogues de l'état « Unconfirmed » à un état « Confirmed » (par exemple : l'état « New »). o creategroups : cette option permet à un utilisateur de créer et détruire des groupes dans Bugzilla. o editbugs : les utilisateurs peuvent seulement éditer les bogues dont ils sont responsables ou qu'ils ont signalés, sauf si ce champ est activé. Même si l'option n'est pas sélectionnée, les utilisateurs peuvent tout de même ajouter des commentaires à des bogues. o editcomponents : cette option permet à un utilisateur de créer de nouveaux produits et composants, ainsi que de modifier et supprimer ceux auxquels aucun bogue n'est associé. Si un produit ou un composant a des bogues qui lui sont associés, ces bogues doivent être affectés à un autre produit ou composant pour que Bugzilla permette sa suppression. o editkeywords : si vous utilisez la fonctionnalité de mot-clé de Bugzilla, en activant cette option vous permettrez à un utilisateur de créer et détruire des mots-clé. Comme toujours, les mots-clé pour des bogues existants qui contiennent le mot-clé que l'utilisateur veut détruire doivent être modifiés pour que Bugzilla autorise sa suppression. o editusers : cette option permet à un utilisateur de faire ce que vous faîtes en ce moment : éditer d'autres utilisateurs. Cela permettra à ceux qui ont le droit de le faire de supprimer les droits administrateur d'autres utilisateurs ou de se les accorder. À activer avec précaution. o tweakparams : cette option permet à un utilisateur de changer les paramètres de Bugzilla (en utilisant editparams.cgi). o : ceci permet à un administrateur de spécifier les produits au sein desquels un utilisateur pourra voir des bogues. L'utilisateur devra quand même avoir le droit « editbugs » pour éditer les bogues dans ces produits. 3. Produits Les produits constituent la catégorie la plus importante dans Bugzilla, et représentent quasiment les produits réels embarqués. Par exemple, si votre entreprise conçoit des jeux vidéo, vous devriez avoir un produit par jeu, peut-être un produit « commun » pour les technologies utilisées dans de nombreux jeux, et peut-être quelques produits spéciaux (Site Internet, Administration, ...) Une grande partie des réglages de Bugzilla est paramétrable pour un produit donné. Le nombre de « votes » disponibles par utilisateur est fixé pour un produit donné, tout comme le nombre de votes nécessaire pour faire passer un bogue automatiquement de l'état UNCONFIRMED à l'état NEW. Pour créer un nouveau produit : 1. Sélectionnez « Produits » en bas de page 2. Sélectionnez le lien « Add » en bas à droite 3. Entrez le nom du produit et une description. Il est possible de remplir le champ Description en HTML. Ne vous souciez pas des options « Closed for bug entry », « Maximum Votes per person », « Maximum votes a person can put on a single bug », « Number of votes a bug in this Product needs to automatically get out of the UNCOMFIRMED state », et « Version » pour le moment. Nous allons les aborder dans quelques instants. 4. Composants Les composants sont des sous-sections des produits. Par exemple, le jeu vidéo que vous développez peut avoir un composant IHM, un composant « API », un composant « Sound System » et un composant « Plugins », chacun étant surveillé par un programmeur différent. Il est souvent pratique de séparer les composants dans Bugzilla suivant la répartition naturelle des responsabilités au sein du produit ou de votre entreprise. Chaque composant a un propriétaire et un contact QA (si vous l'activez dans les paramètres). Il est préférable que le propriétaire d'un composant soit la première personne à réparer les bogues dans ce composant. Il est conseillé que ce soit le contact QA qui s'assurera que ces bogues sont complètement réparés. Le propriétaire, le contact QA et celui qui a signalé le bogue recevront un message électronique quand de nouveaux bogues seront créés dans ce composant et quand ces bogues seront modifiés. Les champs Default Owner et QA contact indique seulement les affectations par défaut; celles-ci peuvent être modifiées lors de la soumission d'un bogue, ou à n'importe quel moment de la vie du bogue. Pour créer un nouveau composant : 1. Sélectionnez le lien « Edit components » dans la page « Edit product ». 2. Sélectionnez le lien « Add » en bas à droite. 3. Remplissez le champ « Component », une courte « Description », les champs « Initial Owner » et « Initial QA Contact » (s'ils sont activés). Il est possible de remplir les champs Component et Description en HTML. Vous devez remplir le champ « Initial Owner » avec un nom d'utilisateur déjà présent dans la base de données. 5. Versions Les versions sont les révisions d'un produit, comme « Flinders 3.1 », « Flinders 95 », et « Flinders 2000 ». La version n'est pas un champ à plusieurs choix; en général, on choisit la version la plus récente dont on sait qu'elle contient le bogue. Pour créer et éditer des versions : 1. Sélectionnez le lien « Edit Versions » à partir de la page « Edit product ». 2. Vous pourrez remarquer que le produit a déjà par défaut la version « undefined ». Cliquez sur le lien « Add » en bas à droite. 3. Entrez le nom de la version. Ce champ ne peut contenir que du texte. Ensuite, cliquez sur le bouton « Add ». 6. Cibles Jalon Les cibles jalons sont des « cibles » qui représentent la version pour laquelle vous prévoyez de réparer un bogue. Par exemple, si vous prévoyez de réparer un bogue pour la version 3.0, vous lui affecterez le jalon 3.0. [46][Note] Note Les options des cibles jalons n'apparaissent pour un produit que si vous activez le paramètre « usetargetmilestone » dans la page « Edit Parameters ». Pour créer de nouveaux jalons, définir les jalons par défaut et fixer l'URL des jalons : 1. Sélectionnez « Edit milestones » dans la page « Edit product ». 2. Sélectionnez « Add » dans le coin inférieur droit. 3. Entrez le nom du jalon dans le champ « Milestone ». En option, vous pouvez fixer le « sortkey », qui est un nombre positif ou négatif (-255 à 255) qui définit où ce point clé apparaîtra dans la liste. En effet, les jalons ne se présentent pas souvent dans l'ordre alphanumérique. Par exemple, on peut trouver « Future » après « Release 1.2 ». Sélectionnez « Add ». 4. Dans la page Edit product, vous pouvez entrer l'URL d'une page qui donne des informations sur vos jalons et ce qu'ils signifient. 7. Fanions Les fanions permettent d'attribuer un statut spécifique à un bogue ou une pièce jointe, aussi bien « + » que « - ». La signification de ces symboles dépend du texte du fanion lui-même, mais selon le contexte ils peuvent signifier passe/échoue, accepter/refuser, approuvé/refusé, ou même un simple oui/non. Si votre site autorise les fanions de requêtes, les utilisateurs peuvent attribuer au fanion la valeur « ? » de manière à en faire une requête auprès d'un autre utilisateur pour pouvoir regarder le bogue/pièce jointe, et donner au fanion son statut correct. 7.1. Exemple simple 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 : 1. L'administrateur de Bugzilla crée un type de fanion appelé « blocking2.0 » qui révèle tous les bogues de votre produit. Sur l'écran « Trouver bug », ce fanion affiche le texte « blocking2.0 » avec une zone déroulante à côté. La zone déroulante contient 4 valeurs : un espace vide, « ? », « - », et « + ». 2. Le développeur attribue au fanion la valeur « ? ». 3. Le directeur voit le fanion blocking2.0 à la valeur « ? » value. 4. Si le directeur pense que le dispositif devrait être inclus dans le produit avant la sortie de la version 2.0, il attribue au fanion la valeur « + ». Sinon il lui attribue « - ». 5. Maintenant, chaque utilisateur de Bugzilla qui voit le bogue sait si le bogue a besoin ou pas d'être corrigé avant la sortie de la version 2.0. 7.2. À propos des fanions 7.2.1. Valeurs Les fanions peuvent prendre 3 valeurs : ? Un utilisateur demande qu'un statut soit donné (considérez le comme « une question est posée »). - Le statut donné est négatif (on a répondu « non » à la question). + Le statut donné est positif (on a répondu « oui » à la question). En fait, il existe une quatrième valeur possible du fanion : « aucun statut » ; celle-ci est représentée par un espace vide. Cela veut juste dire que personne n'a exprimé d'opinion (ou demandé à quelqu'un d'autre d'exprimer une opinion) à propos de ce bogue ou de la requête par pièce jointe. 7.3. Utilisation des requêtes par fanions 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. 7.4. Deux types de fanions Les fanions peuvent se mettre à deux endroits : dans une pièce jointe, ou dans un bogue. 7.4.1. Fanions de pièce jointe Les fanions de pièce jointe sont utilisés pour poser une question sur une pièce jointe particulière à un bogue. Plusieurs installations Bugzilla s'en servent pour demander à un développeur « d'examiner » [« review »] le code d'un autre développeur avant de le valider. Ils joignent le code à un rapport de bogue, puis lui attribue un fanion nommé « review » à review?boss@domain.com. boss@domain.com est alors averti par courriel qu'il doit vérifier la pièce jointe et l'approuver ou la refuser. Pour un utilisateur Bugzilla, les fanions de pièce jointe apparaissent à deux endroits : 1. Sur la liste des pièces jointes sur l'écran « montrer un bogue » [« Show bug »], on peut voir l'état actuel de tous les fanions affectés de ?, +, ou -. On peut voir qui a demandé le fanion (le demandeur), et qui a été sollicité (le demandé). 2. Quand vous « modifiez » une pièce jointe, on peut voir les fanions qui n'ont pas encore de valeur, ainsi que ceux qui en ont déjà une. C'est sur l'écran « éditer une pièce jointe » que l'on met ou que l'on enlève ?, -, +. 7.4.2. Fanions de bogue Les fanions de bogue sont utilisés pour attribuer un statut au bogue lui-même. On peut voir les fanions de bogue sur l'écran « Show Bug » (editbug.cgi). Seuls les utilisateurs ayant le droit d'éditer le bogue peuvent attribuer des valeurs aux fanions qui sont sur des bogues. Cela inclut le propriétaire, celui qui signale les bogues, et tout utilisateur ayant la permission editbugs. 7.5. Administration des fanions 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.1. Créer un fanion Quand vous cliquez sur le lien « Create a Flag Type for... », il vous sera présenté un formulaire. Voici la signification des champs du formulaire : 7.5.1.1. Nom C'est le nom du fanion. Il s'affichera pour les utilisateurs Bugzilla qui sont en train de regarder ou de configurer un fanion. Le nom peut contenir n'importe quel caractère Unicode valide. 7.5.1.2. Description Donne plus de précisions sur le fanion. Pour le moment, cela n'a pas l'air d'être très utile; idéalement, ce serait bien que ce soit affiché comme aide. Ce champ peut être aussi long que vous le désirez, et peut contenir autant de caractères que vous voulez. 7.5.1.3. Catégorie Le comportement par défaut pour un fanion fraîchement créé est d'apparaître sur les produits et tous les composants, c'est pourquoi « __Any__:__Any__ » est déjà présent dans le champ « Inclusions ». Si ce n'est pas ce comportement que vous souhaitez, vous pouvez également configurer des exclusions (pour les produits sur lesquels vous ne voulez pas que le fanion apparaisse), ou bien vous devez enlever « __Any__:__Any__ » du champ Inclusion et définir les produits/composants spécialement pour ce fanion. Pour créer une Inclusion, sélectionnez un produit à partir du menu déroulant du haut. Vous pourrez également sélectionner un composant donné à partir de ce menu déroulant. (La configuration « __Any__ » pour les produits se traduit par « tous les produits de ce Bugzilla ». Choisir « __Any__ » dans le champ Composants veut dire « tous les composants du produit sélectionné ».) Une fois les sélections faites, appuyer sur « Include », et l'appariement de votre produit/composant sera visible dans le champ « Inclusions » sur la droite. Pour créer une Exclusion, la procédure est la même; choisissez un produit à partir du menu déroulant du haut, choisissez un composant donné si vous en voulez un, et appuyez sur « Exclude ». L'appariement de votre produit/composant sera visible dans le champ « Exclusions » sur la droite. Ce fanion devra et peut être configuré pour n'importe quel produit/composant apparaissant dans le champ « Inclusions » (ou qui dépend du « __Any__ » approprié). Ce fanion n'apparaîtra (et donc ne pourra être configuré) sur aucun des produits apparaissant dans le champ « Exclusions ». IMPORTANT : les Exclusions prévalent sur les Inclusions. Vous pouvez choisir un produit sans sélectionner un composant particulier, mais choisir un composant sans produit est contraire à la règle, de même que choisir un composant qui n'appartient pas au produit évoqué. Si vous le faites, vous obtiendrez une erreur, comme on l'indique dans ce texte (2.18rc3)... même si tous vos produits possèdent un composant du même nom. Exemple : disons que vous avez un produit appelé « Avion » qui contient des centaines de composants. Vous voulez avoir la possibilité de demander si un problème sera corrigé dans le prochain modèle d'avion que vous sortirez. Nous appellerons ce fanion « corrigerDansSuivant ». Cependant, il y a un composant dans « Jet », appelé « Pilote ». Il ne vous sert à rien de sortir un nouveau pilote, donc vous ne voulez pas que le fanion soit visible pour ce composant. Donc, vous incluez « Jet :__Any__ » et vous excluez « Jet :Pilote ». 7.5.1.4. Clé de tri Les fanions sont normalement visibles dans l'ordre alphabétique. Si vous voulez les afficher dans un ordre différent vous pouvez utiliser ce champ pour configurer l'ordre sur chaque fanion. Les fanions ayant une clé de tri inférieur apparaîtront avant les fanions à clés de tris supérieur. Les fanions ayant le même critère seront rangés alphabétiquement mais ils seront toujours après les fanions à clés de tri inférieur et avant ceux à clés supérieur. Exemple : j'ai AFanion (critère de tri 100), BFanion (critère de tri 10), CFanion (critère de tri 10), et DFanion (critère de tri 1). Ceux-ci s'affichent dans cet ordre : DFanion, CFanion, BFanion, AFanion. 7.5.1.5. Actif Il vous arrivera de vouloir conserver les informations de l'ancien fanion dans la base de données Bugzilla, tout en empêchant les utilisateurs d'initialiser de nouveaux fanions de ce genre. Pour ce faire, dé-sélectionnez « active ». Les fanions désactivés seront toujours visibles dans l'interface s'ils sont ?, +, ou -, mais ils peuvent seulement être effacés (non initialisés), et ne peuvent pas avoir de nouvelles valeurs. Une fois que le fanion désactivé est supprimé, il disparaîtra complètement du bogue/pièce jointe, et ne pourra plus être reconfiguré. 7.5.1.6. Fanions de requête Les nouveaux fanions sont, par défaut, des fanions « de requête », ce qui signifie qu'ils offrent aux utilisateurs l'option « ? », ainsi que « + » et « - ». Pour supprimer l'option ? , dé-sélectionnez « requestable ». 7.5.1.7. Liste CC Si vous voulez que certains utilisateurs soient avertis à chaque fois qu'un fanion est initialisé à ?,-,+, ou non initialisé, ajoutez les ici. Il s'agit d'une liste d'adresses électroniques, séparées par des virgules, qu'il n'est pas nécessaire de restreindre aux noms d'utilisateurs Bugzilla. 7.5.1.8. Fanions de requêtes spécifiques Par défaut cette case est cochée pour les nouveaux fanions, ce qui signifie que chaque utilisateur peut faire des requêtes de fanions destinées à des personnes en particulier. Décocher cette boîte supprimera le champ de texte à côté du fanion; s'il demeure fanion de requête, les demandes ne peuvent être faites qu' « à la cantonnade ». Le supprimer après que des demandes spécifiques aient été faites ne supprimera pas ces demandes; ces données vont rester dans la base de données (bien que cela n'apparaîtra plus aux utilisateurs). 7.5.1.9. Multipliable Tout fanion initialisé sur « Multipliable » (par défaut pour les nouveaux fanions) peut être configuré plus d'une fois. Après avoir été initialisé une fois, un fanion non initialisé du même type apparaîtra en dessous de lui avec « addl. » (abréviation de « additional ») sous son nom. Il n'y a pas de limite au nombre de fois qu'un fanion Multipliable peut être initialisé sur le même bogue/pièce jointe. 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. [47][Avertissement] 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. 7.5.3. Éditer un fanion Pour éditer les propriétés d'un fanion, il suffit de cliquer sur le lien « Edit » à côté de la description du fanion. Cela vous ramènera au formulaire décrit dans la partie « Créer un fanion ». 8. Le vote Le vote permet aux utilisateurs de disposer d'un certain nombre de voix qu'ils peuvent affecter à des bogues, pour indiquer qu'ils souhaitent que ces bogues soient réparés. Cela permet aux développeurs d'évaluer les besoins utilisateurs pour une amélioration ou une réparation particulière. En permettant que les bogues ayant un certain nombre de voix puissent passer automatiquement de « UNCONFIRMED » à « NEW », les utilisateurs du système de bogues peuvent attirer l'attention sur les bogues de priorité élevée de façon à ce qu'ils ne restent pas trop longtemps à en attente de triage. Pour modifier les paramètres de vote : 1. Allez jusqu'à la page « Edit product » du produit que vous voulez modifier. 2. Nombre de voix par personne : en mettant ce champ à 0, on désactive le vote. 3. Nombre de voix maximum qu'une personne peut donner à un seul bogue : à l'évidence, cela doit être un nombre inférieur au nombre inscrit dans le champ « Nombre de voix par personne ». Ne mettez pas ce champ à 0 si « Nombre de voix par personne » n'est pas à 0; cela n'a pas de sens. 4. Nombre de voix nécessaires pour qu'un bogue de ce produit sorte automatiquement de l'état UNCONFRIMED. : En mettant ce champ à « 0 », on désactive le passage automatique des bogues de UNCONFIRMED à NEW. 5. Une fois que vous avez ajusté les valeurs selon vos préférences, cliquez sur « Update ». 9. Les mots d'esprit Les mots d'esprit sont des messages texte courts qui peuvent être configurés pour apparaître à côté des résultats d'une recherche. Une installation Bugzilla peut avoir ses propres mots d'esprit bien spécifiques. Quel que soit le moment où le mot d'esprit a besoin d'être affiché, une sélection aléatoire est faite sur l'ensemble des mots d'esprits déjà existants. Les mots d'esprit sont gérés par le paramètre enablequips. Il a plusieurs valeurs possibles : actif, approuvé, gelé ou éteint. Pour permettre l'approbation de mots d'esprit, il vous faut initialiser ce paramètre à « approved ». De cette manière, les utilisateurs sont libres de proposer des mots d'esprits en plus mais un administrateur doit les approuver explicitement avant qu'ils puissent être en fait utilisés. Pour voir l'interface utilisateur pour les mots d'esprits, il suffit de cliquer sur l'un d'entre eux quand il est affiché avec les résultats de la recherche. On peut aussi le voir directement dans le navigateur en allant sur le lien quips.cgi (préfixé de l'adresse WEB habituelle de l'installation Bugzilla). Dès que l'interface des mots d'esprit s'affiche, il suffit de cliquer sur « voir et modifier la liste complète des mots d'esprit » afin de voir la page d'administration. Une page avec tous les mots d'esprits disponibles dans la base de données s'affichera. À côté de chaque mot d'esprit, il y a une case à cocher, dans la colonne « approved ». Les mots d'esprits qui ont leur case cochée sont déjà approuvés et apparaîtront après chaque résultat de recherche. Ceux dont la case est non cochée sont toujours présents dans la base de données mais n'apparaîtront pas sur les pages de résultats de recherche. Pour les mots d'esprit proposés par les utilisateurs, cette case est, au départ, non cochée. Il y a également un lien de suppression à côté de chaque mot d'esprit, lequel peut être utilisé pour supprimer définitivement un mot d'esprit. 10. Groupes et sécurité des groupes Les groupes permettent à l'administrateur d'isoler des bogues ou produits qui ne devraient être vus que par certaines personnes. L'association entre les produits et les groupes est gérée à partir de la page d'édition du produit sous « éditer les commandes des groupes ». Si le paramètre makeproductgroups est activé, un nouveau groupe sera automatiquement créé pour chaque nouveau produit. Il est principalement disponible pour la compatibilité descendante avec des sites plus anciens. Notez que les permissions de groupes sont telles que vous devez être membre de tous les groupes où se trouve un bogue, quelle qu'en soit la raison, pour voir ce bogue. De même, vous devez être membre de tous les groupes d'entrée d'un produit pour ajouter des bogues à un produit et vous devez être membre de tous les groupes « canedit » (« peut modifier ») d'un produit pour faire toute modification de bogues dans ce produit. [48][Note] Note Par défaut, les bogues peuvent également être vus par le propriétaire du bogue, le rapporteur et par toutes les personnes de la liste CC, quel que soit leur statut par rapport à leur accès normal au bogue. La visibilité pour le rapporteur et pour la liste CC peut être annulée (pour un bogue à la fois) en ressortant ce bogue, puis en allant à la section qui commence par « Utilisateurs dans les rôles sélectionnés ci-dessous... » et en décochant la case à côté de « rapporteur » ou « Liste CC » (ou les deux). 10.1. Création des groupes Pour créer des groupes : 1. Sélectionnez le lien « groups » dans le bas de page. 2. Lisez attentivement les instructions sur l'écran « Edit Groups », puis sélectionnez le lien « Add Groups ». 3. Remplissez les champs « Group », « Description », et « User RegExp ». « User RegExp » vous permet de placer automatiquement tous les utilisateurs qui remplissent les conditions de l'expression rationnelle dans le nouveau groupe. Quand vous avez fini, cliquez sur « Add ». Les utilisateurs dont les adresses électroniques correspondent à l'expression rationnelle seront automatiquement membres du groupe tant que leurs adresses électroniques continueront de correspondre à l'expression rationnelle. [49][Note] Note C'est une modification du 2.16 où l'expression rationnelle avait pour résultat l'adhésion permanente à un groupe pour un utilisateur. Pour supprimer un utilisateur d'un groupe dans lequel il était à cause d'une expression rationnelle, dans la version 2.16 ou précédemment, l'utilisateur doit être supprimé explicitement du groupe. [50][Avertissement] Avertissement Si vous spécifiez un domaine dans le regexp, assurez vous que vous avez bien terminé l'expression rationnelle avec un « $ ». Sinon quand vous autoriserez l'accès à @monentreprise\.com, vous autoriserez l'accès à mauvaisepersonne@monentreprise.com.cracker.net. Il vous faut utiliser @monentreprise\.com$ comme expression rationnelle. 4. Si vous décidez d'utiliser ce groupe pour contrôler directement l'accès aux bogues, cochez la case « use for bugs » . Les groupes non utilisés pour des bogues restent utiles car les autres groupes peuvent inclure le groupe entier. 5. Après avoir ajouté votre nouveau groupe, éditez le nouveau groupe. Sur la page d'édition, vous pouvez spécifier d'autres groupes qui devraient être inclus dans ce groupe et quels groupes devraient être autorisés à ajouter ou à supprimer des utilisateurs à partir de ce groupe. 10.2. Affecter des utilisateurs aux groupes Les utilisateurs peuvent devenir membres d'un groupe de plusieurs façons. 1. L'utilisateur peut être explicitement placé dans le groupe en éditant le propre profil de l'utilisateur. 2. Le groupe peut contenir un autre groupe auquel l' utilisateur appartient. 3. L'adresse électronique de l'utilisateur peut correspondre à une expression rationnelle que le groupe définit pour attribuer automatiquement le statut du membre. 10.3. Affecter les commandes de groupe aux produits 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... 1. est nécessaire pour entrer un bogue (Entry). 2. est sans objet pour ce produit (NA), est une restriction que les membres de ce groupe peuvent ajouter à ce produit (Shown), est une restriction par défaut lorsque les membres de ce groupe ajoutent un bogue à ce produit (Default), ou est une restriction obligatoire à placer sur les bogues de ce produit (Mandatory). 3. est sans objet pour ce produit pour les non membres (NA), est une restriction que les non membres de ce groupe peuvent ajouter à ce produit (Shown), est une restriction par défaut lorsque les non membres de ce groupe ajoutent un bogue à ce produit (Default), ou est une restriction obligatoire à placer sur les bogues de ce produit lorsqu'ils sont entrés par des non membres (Mandatory). 4. est nécessaire pour faire toute modification sur les bogues de ce produit y compris des commentaires. 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 10.4. Applications courantes des commandes de groupe 10.4.1. Accès utilisateur général avec le groupe Securité Pour laisser tout utilisateur soumettre des bogues dans chaque produit (A, B, C...) et lai