Le guide de Bugzilla - version 4.4.13 L'équipe Bugzilla 2018-02-16 Résumé Ceci est la documentation pour Bugzilla, un système de suivi de bogues de mozilla.org. Bugzilla est un logiciel taillé pour l'entreprise qui permet de suivre des millions de bogues et de problèmes et adopté par des centaines d'organisations dans le monde. La version la plus à jour de ce document est disponible sur la page de documentation de Bugzilla. __________________________________________________________________ Table des matières 1. À propos de ce guide 1.1. Information sur le copyright 1.2. Avis de non-responsabilité 1.3. Nouvelles versions 1.4. Contributeurs 1.5. Conventions du document 2. Installer Bugzilla 2.1. Installation 2.1.1. Perl 2.1.2. Moteur de base de données 2.1.3. Serveur Web 2.1.4. Bugzilla 2.1.5. Modules Perl 2.1.6. Mail Transfer Agent (MTA) 2.1.7. Installer Bugzilla avec mod_perl 2.2. Configuration 2.2.1. localconfig 2.2.2. Serveur de base de données 2.2.3. checksetup.pl 2.2.4. Le serveur Web 2.2.5. Bugzilla 2.3. Configuration optionnelle supplémentaire 2.3.1. Graphiques de bogues 2.3.2. Les notifications programmées 2.3.3. Notifications 2.3.4. Servir des formats alternatifs avec le bon type MIME 2.4. Plusieurs bases de données Bugzilla dans une seule installation 2.5. Notes d'installation spécifiques aux systèmes d'exploitation 2.5.1. Microsoft Windows 2.5.2. Mac OS X™ 2.5.3. Distributions GNU Linux/BSD 2.6. Notes d'installation Unix (non-root) 2.6.1. Introduction 2.6.2. MySQL 2.6.3. Perl 2.6.4. Modules Perl 2.6.5. Le serveur HTTP 2.6.6. Bugzilla 2.7. Mettre à jour vers de nouvelles versions 2.7.1. Avant de mettre à jour 2.7.2. Obtenir la nouvelle version de Bugzilla 2.7.3. Terminer la mise à jour 2.7.4. Notifications automatiques pour les nouvelles versions 3. Administrer Bugzilla 3.1. Configuration de Bugzilla 3.1.1. Paramètres requis 3.1.2. Politiques d'administration 3.1.3. Authentification utilisateur 3.1.4. Fichiers joints 3.1.5. Politique de modification des bogues 3.1.6. Champs des bogues 3.1.7. Déplacement de bogue 3.1.8. Graphiques de dépendances 3.1.9. Restrictions de groupe 3.1.10. LDAP 3.1.11. Authentification RADIUS 3.1.12. Courriel 3.1.13. Visionneuse de correctif 3.1.14. Options par défaut des requêtes 3.1.15. Base de données esclave 3.1.16. Correspondance d'utilisateur 3.2. Administrer les utilisateurs 3.2.1. Créer l'utilisateur par défaut 3.2.2. Gérer les autres utilisateurs 3.3. Catégories 3.4. Produits 3.4.1. Créer de nouveaux produits 3.4.2. Modifier des produits 3.4.3. Ajouter ou modifier les composants, versions et jalons cibles 3.4.4. Affecter des restrictions de groupes à des produits 3.5. Composants 3.6. Versions 3.7. Jalons 3.8. Étiquettes 3.8.1. Un simple exemple 3.8.2. À propos des étiquettes 3.8.3. Utiliser les demandes d'étiquettes 3.8.4. Deux types d'étiquettes 3.8.5. Gérer les étiquettes 3.9. Keywords 3.10. Champs personnalisés 3.10.1. Ajouter des champs personnalisés 3.10.2. Modifier les champs personnalisés 3.10.3. Supprimer des champs personnalisés 3.11. Valeurs autorisées 3.11.1. Voir/Modifier les valeurs autorisées 3.11.2. Supprimer des valeurs autorisées 3.12. Worflow des états de bogue 3.13. Voter 3.14. Citations 3.15. Groupes et restrictions de groupes 3.15.1. Créer des groupes 3.15.2. Modification de groupes et affectation de restrictions 3.15.3. Affecter des utilisateurs aux groupes 3.15.4. Affecter des restrictions de groupes à des produits 3.16. Vérifier et maintenir l'intégrité de la base de données 4. La sécurité dans Bugzilla 4.1. Système d'exploitation 4.1.1. Ports TCP/IP 4.1.2. Comptes utilisateur système 4.1.3. La prison chroot 4.2. Serveur Web 4.2.1. Désactiver l'accès à distance aux fichiers de configuration de Configuration 4.3. Bugzilla 4.3.1. Prevent users injecting malicious Javascript 5. Utilisation de Bugzilla 5.1. Introduction 5.2. Création d'un compte Bugzilla 5.3. Anatomie d'un bogue 5.4. Cycle de vie d'un bogue 5.5. Recherche de bogues 5.5.1. Tableaux booléens 5.5.2. Recherche d'un bogue spécifique 5.5.3. Sensibilité à la casse dans les recherches 5.5.4. Listes des bogues 5.5.5. Ajout/suppression de marqueurs 5.6. Rapporter des bogues 5.6.1. Rapporter un nouveau bogue 5.6.2. Clônage d'un bogue existant 5.7. Fichiers joints 5.7.1. Visionneuse de fichiers 5.8. Trucs et astuces 5.8.1. Hyperlien automatique 5.8.2. Commentaires 5.8.3. Formatage des commentaires du côté du serveur 5.8.4. Arbre de dépendance 5.9. Informations d'horodatage 5.10. Préférences utilisateur 5.10.1. Préférences générales 5.10.2. Préférences de messagerie 5.10.3. Recherches enregistrées 5.10.4. Préférences du compte 5.10.5. Permissions 5.11. Rapports et graphiques 5.11.1. Rapports 5.11.2. Graphiques 5.12. Étiquettes 5.13. Notifications 5.13.1. Évènement 5.13.2. Programmation des notifications 5.13.3. Requêtes de notifications 5.13.4. Enregistrement des modifications 6. Personnaliser Bugzilla 6.1. Extensions Bugzilla 6.2. Thèmes personnalisés 6.3. Personnaliser des modèles 6.3.1. Struvture de répertoires des modèlesTemplate 6.3.2. Choisir une méthode de personnalisation 6.3.3. Comment modifier les modèles 6.3.4. Types et formats de modèles 6.3.5. Modèles particuliers 6.3.6. Configurer Bugzilla pour détecter la langue de l'utilisateur 6.4. Personnaliser qui peut changer quoi 6.5. Intégration de Bugzilla avec des outils tiers A. Dépannage A.1. Notice générale A.2. Le serveur Apache n'affiche pas les pages de Bugzilla A.3. J'ai installé un module Perl mais checksetup.pl dit qu'il n'est pas installé ! A.4. DBD::Sponge::db prepare failed A.5. cannot chdir(/var/spool/mqueue) A.6. Tout le monde est obligé de se reconnecter constamment A.7. index.cgi n'apparaît pas à moins de le spécifier dans l'URL A.8. « checksetup.pl » signale « Client does not support authentication protocol requested by server… » B. Contrib B.1. Interface de recherche en ligne de commande B.2. Outil en ligne de commande « Envoyer les courriels de bogues en attente » C. Manuel d'installation des modules Perl C.1. Instructions C.2. Liens de téléchargement C.3. Modules optionnels D. GNU Free Documentation License D.0. Preamble D.1. Applicability and Definition D.2. Verbatim Copying D.3. Copying in Quantity D.4. Modifications D.5. Combining Documents D.6. Collections of Documents D.7. Aggregation with Independent Works D.8. Translation D.9. Termination D.10. Future Revisions of this License D.. How to use this License for your documents Glossaire Liste des illustrations 5.1. Cycle de vie d'un bogue Bugzilla Liste des exemples A.1. Exemples de paires « urlbase »/« cookiepath » partageant les cookies de connexion A.2. Exemples de paires « urlbase »/« cookiepath » pour limiter les cookies de connexion Chapitre 1. À propos de ce guide Table des matières 1.1. Information sur le copyright 1.2. Avis de non-responsabilité 1.3. Nouvelles versions 1.4. Contributeurs 1.5. Conventions du document 1.1. Information sur le copyright Ce document est sous copyright © 2000-2018 de ses divers contributeurs Bugzilla qui l'ont écrit. [Avertissement] Seule la version anglaise du texte de licence a valeur officielle, la traduction est donnée ici à titre informatif. 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 D, GNU Free Documentation License. Traduction : « Vous pouvez copier, distribuer et/ou modifier ce document sous les termes de la GNU Free Documentation License, Version 1.1 ou toute version ultérieure publiée par la Free Software Foundation ; sans sections invariantes, sans texte de couverture ni texte de plat verso. Une copie de la licence se trouve dans Annexe D, GNU Free Documentation License. » If you have any questions regarding this document, its copyright, or publishing this document in non-electronic form, please contact the Bugzilla Team. Traduction : « Si vous avez des questions concernant ce document, son copyright ou la publication sous forme non-électronique, veuillez contacter l'équipe de Bugzilla. » 1.2. Avis de non-responsabilité 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. Traduction : « Aucune responsabilité sur le contenu de ce document ne saurait être assumée. Suivez les informations ci-jointes à vos risques et périls. Ce document peut contenir des erreurs et des imprécisions qui peuvent endommager votre système, provoquer le départ de votre partenaire, vous faire virer par votre chef, faire uriner vos chats sur vos meubles et vos vêtements et provoquer une guerre thermonucléaire. Procéder avec précaution. » 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. Traduction : « Les citations de produits ou de marques particuliers ne doivent pas être pris pour des témoignages publicitaires, à l'exception du terme “GNU/Linux”. Nous approuvons de tout coœur l'utilisation de GNU/Linux ; c'est un système d'exploitation extrêmement plyvalent, stable et robuste offrant un environnement d'exploitation idéal pour Bugzilla. » 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. Traduction : « Bien que l'équipe de développement de Bugzilla ait pris grand soin de s'assurer que tous les bogues de sécurité aient été corrigés, des trous de sécurité existent sûrement quelque part dans le code. Un grand soin doit être apporté à l'installation et à l'utilisation de ce logiciel. L'équipe de développement de Bugzilla n'assume aucune responsabilité pour votre utilisation de Bugzilla. Vous disposez du code source et vous êtes responsable de son inspection pour vous assurer que vos besoins en sécurité sont atteints. » 1.3. Nouvelles versions C'est la version 4.4.13 du guide de Bugzilla. Il est ainsi numéroté pour correspondre au numéro de version de Bugzilla. La dernière version de ce guide est toujours disponible sur http://www.bugzilla.org/docs/. Cependant, vous devriez lire la version fournie avec la version de Bugzilla que vous utilisez. De plus, il y a des projets de localisation des modèles de Bugzilla dans différentes langues. Il peut y avoir de la documentation traduite disponible. Si vous voulez vous porter volontaire pour traduire le guide dans d'autres langues, veuillez visiter la page Bugzilla L10n team. 1.4. Contributeurs Les personnes listées ci-dessous ont fait d'énormes contributions pour la création de ce guide, par leur écriture, les efforts de codage dédiés, de nombreux courriels et sessions d'aide sur IRC, et généralement une excellente contribution à la communauté Bugzilla : Matthew P. Barnson pour la tâche herculéenne de rassemblement des documents du guide Bugzilla et pour l'avoir mené à sa version 2.14. Terry Weissman pour avoir initialement écrit Bugzilla et créer le fichier README sur lequel la documentation d'installation Unix est largement basée. Tara Hernandez pour avoir maintenu le rythme de développement après le départ de Terry de mozilla.org et pour maintenir landfill. Dave Lawrence pour avoir fourni son expertise sur les différences essentielles avec la version personnalisée de Bugzilla de Red Hat. Dawn Endico pour être un hacker extraordinaire et répondre aux incessants arguments et questions de Matthew sur irc.mozilla.org sur le canal #mozwebtools Jacob Steenhagen pour s'être occupé de la documentation pendant la période de développement de la version 2.17. Dave Miller pour avoir pris la tête du projet quand Tara a levé le pied et pour pousser continuellement pour avoir la documentation la meilleure possible. Merci aussi 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. Des remerciements sont nécessaires aussi pour les membres de la liste de diffusion mozilla.support.bugzilla (et son prédécesseur, netscape.public.mozilla.webtools). Sans vos discussions, points de vue, suggestions et correctifs, ceci n'aurait jamais pu arriver. 1.5. Conventions du document Ce document utilise les conventions suivantes : [Attention] Ceci est une mise en garde. Assurez-vous de lire ceci pour ne pas avoir de problèmes ! [Astuce] Ceci est une astuce, généralement sur des paramètres de configuration. [Note] Ceci est une note, pour votre information. [Avertissement] Ceci est un avertissement, auquel vous devriez prêter attention. Un nom de fichier ou un chemin de nom de fichier est affiché comme ceci : /chemin/vers/nom_de_fichier.ext Une commande à saisir dans un shell est affichée comme ceci : commande --arguments bash$ représente l'invite de commande d'un utilisateur normal dans le shell Bash bash# représente l'invite de commande d'un utilisateur root dans le shell Bash Un mot présent dans le glossaire apparaît comme ceci : Bugzilla Un échantillon de code est affiché comme ceci : Première ligne de code Deuxième ligne de code … Cette documentation est maintenue en format XML DocBook 4.2. Les modifications sont plus claires lorsqu'elles sont soumises sous forme de diff de fichiers texte ou XML, joint à un bogue créé dans le composant Bugzilla Documentation. Chapitre 2. Installer Bugzilla Table des matières 2.1. Installation 2.1.1. Perl 2.1.2. Moteur de base de données 2.1.3. Serveur Web 2.1.4. Bugzilla 2.1.5. Modules Perl 2.1.6. Mail Transfer Agent (MTA) 2.1.7. Installer Bugzilla avec mod_perl 2.2. Configuration 2.2.1. localconfig 2.2.2. Serveur de base de données 2.2.3. checksetup.pl 2.2.4. Le serveur Web 2.2.5. Bugzilla 2.3. Configuration optionnelle supplémentaire 2.3.1. Graphiques de bogues 2.3.2. Les notifications programmées 2.3.3. Notifications 2.3.4. Servir des formats alternatifs avec le bon type MIME 2.4. Plusieurs bases de données Bugzilla dans une seule installation 2.5. Notes d'installation spécifiques aux systèmes d'exploitation 2.5.1. Microsoft Windows 2.5.2. Mac OS X™ 2.5.3. Distributions GNU Linux/BSD 2.6. Notes d'installation Unix (non-root) 2.6.1. Introduction 2.6.2. MySQL 2.6.3. Perl 2.6.4. Modules Perl 2.6.5. Le serveur HTTP 2.6.6. Bugzilla 2.7. Mettre à jour vers de nouvelles versions 2.7.1. Avant de mettre à jour 2.7.2. Obtenir la nouvelle version de Bugzilla 2.7.3. Terminer la mise à jour 2.7.4. Notifications automatiques pour les nouvelles versions 2.1. Installation [Note] Si vous voulez juste utiliser Bugzilla, vous n'avez pas besoin de l'installer. Aucun de ces chapitres ne vous concerne. Demandez à votre administrateur Bugzilla l'URL pour y accéder par avec votre navigateur Web. Le logiciel serveur Bugzilla est habituellement installé sur GNU/Linux ou Solaris. Si vous l'installez sur un autre système d'exploitation, vérifiez Section 2.5, « Notes d'installation spécifiques aux systèmes d'exploitation » avant de commencer votre installation pour voir s'il n'y a pas des instructions particulières. Ce guide suppose que vous avez un accès administrateur à la machine Bugzilla. Il n'est pas possible d'installer et d'exécuter Bugzilla sans accès administrateur, excepté dans la très improbable éventualité où tous les prérequis seraient déjà déjà installés. [Avertissement] Le processus d'installation peut rendre votre machine non-sûre pendant quelques courtes périodes. Assurez-vous qu'il y a un pare-feu entre vous et le réseau Internet. Il est fortement recommandé de faire une sauvegarde de votre système avant d'installer Bugzilla (et à intervalles réguliers après cela :-). Dans les grandes lignes, l'installation se déroule ainsi : 1. Installation de Perl (5.8.1 ou supérieur) 2. Installation d'un moteur de base de données 3. Installation d'un serveur Web 4. Installation de Bugzilla 5. Installation des modules Perl 6. Installation d'un agent de transfert de courrier (MTA) (Sendmail 8.7 ou supérieur ou un MTA compatible avec Sendmail de cette version au moins) 7. Configuration de tous les éléments ci-dessus. 2.1.1. Perl Test de la version installée : perl -v Toute machine n'ayant pas Perl installé est une machine bien triste. Si vous ne l'avez pas et que votre système d'exploitation ne fournit pas de paquets officiels, visitez http://www.perl.org. Bien que Bugzilla fonctionne avec Perl 5.8.1, c'est une bonne idée que d'utiliser la dernière version stable. 2.1.2. Moteur de base de données Bugzilla gère les serveurs de bases de données MySQL, PostgreSQL et Oracle. Vous n'avez besoin que d'un seul de ces moteurs de base de données pour faire fonctionner Bugzilla. 2.1.2.1. 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 paquets officiels, visitez http://www.mysql.com. Vous avez besoin de MySQL version 5.0.15 ou supérieur. [Note] Beaucoup de versions binaires de MySQL stockent leurs fichiers de données dans le répertoire /var. Sur certains systèmes Unix, ce répertoire fait partie d'une plus petite partition « root », et peut ne pas avoir assez de place pour votre base de données de bogues. Pour changer le répertoire des données, vous devez compiler MySQL à partir des sources vous-même, et le définir comme option pour configure. Si vous installez à partir d'autre chose qu'un des systèmes d'installation/empaquet suivants : « .rpm » (paquet RPM), « .deb » (paquet Debian), « .exe » (exécutable Windows) ou « .msi » (Microsoft Installer), assurez-vous que le serveur MySQL soit lancé au démarrage de la machine. 2.1.2.2. PostgreSQL Test de la version installée : psql -V Si vous ne l'avez pas et si votre système d'exploitation ne fournit pas de paquets officiels, visitez http://www.postgresql.org/. Vous avez besoin de PostgreSQL version 8.03.0000 ou supérieur. Si vous installez à partir d'autre chose qu'un des systèmes d'installation/empaquet suivants : « .rpm » (paquet RPM), « .deb » (paquet Debian), « .exe » (exécutable Windows) ou « .msi » (Microsoft Installer), assurez-vous que le serveur PostGreSQL soit lancé au démarrage de la machine. 2.1.2.3. Oracle Test de la version installée : select * from v$version (vous devez d'abord vous connectez à votre base de données) Si vous ne l'avez pas ou que votre système d'exploitation ne fournit pas de paquets officiels, visitez http://www.oracle.com/. Vous devez avoir Oracle version 10.02.0 ou supérieure. Si vous installez à partir de quelque chose d'autre qu'un paquet/installation système, comme un .rpm (paquet RPM), un .deb (paquet Debian), un .exe (exécutable Windows), ou un .msi (Microsoft Installer), assurez-vous que le serveur Oracle est démarré au lancement de la machine. 2.1.3. Serveur Web Test de la version installée : Consultez la page d'accueil par défaut sur http:/// Vous avez la liberté de choix ici, pratiquement n'importe quel serveur capable d'exécuter des scripts CGI fonctionnera. Cependant, nous vous recommandons fortement d'utiliser un serveur Apache (version 1.3.x ou 2.x), et les instructions d'installation supposent généralement que vous utilisez Apache. Si vous utilisez Bugzilla avec un autre serveur Web, veuillez partager vos expériences en rapportant un bogue dans http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla;component=Do cumentation. Si vous n'avez pas Apache et que votre système d'exploitation ne fournit pas de paquets officiels, visitez http://httpd.apache.org/. 2.1.4. Bugzilla Téléchargez une archive de Bugzilla (ou récupérez-le à partir de Bzr) et placez-le dans un répertoire approprié accessible par l'utilisateur par défaut du serveur Web (probablement « apache » ou « www »). Les meilleurs emplacements sont dans les répertoires de documents du serveur Web ou dans /usr/local avec un lien symbolique vers les répertoires de documents du serveur Web ou un alias dans la configuration du serveur Web. [Attention] La distribution par défaut de Bugzilla n'est PAS conçue pour être placée dans un répertoire cgi-bin. Ceci inclut tout répertoire configué en utilisant la directive ScriptAlias d'Apache. Quand tous les fichiers sont dans un répertoire accessible par le serveur Web, rendez le répertoire accessible en écriture pour l'utilisateur de votre serveur Web. Ceci est une étape temporaire jusqu'à ce que vous exécutiez le script checksetup.pl qui verrouille votre installation. 2.1.5. Modules Perl Le processus d'installation de Bugzilla est basé sur un script appelé checksetup.pl. La première chose qu'il fait est de vérifier si vous avez les versions appropriées de tous les modules Perl requis. Le propos de cette section est de passer cette vérification. quand elle est passée, procédez à la Section 2.2, « Configuration ». À partir de ce point, vous devez faire la commande su - root. Vous devrez demeurer « root » jusqu'à la fin de l'installation. Pour vérifier que vous avez les modules requis, exécutez : bash# ./checksetup.pl --check-modules checksetup.pl affichera une liste de tous les modules Perl requis et optionnels avec leur numéro de version (le cas échéant) installés sur votre machine. La liste des modules requis est plutôt longue ; cependant, vous devez déjà avoir plusieurs d'entre eux installés. Il existe un méta-module appelé « Bundle::Bugzilla », qui installe tous les autres modules en une simple commande. Vous devriez utiliser ceci si vous exécutez Perl 5.6.1 ou supérieur. La manière à privilégier pour installer les modules Perl manquants est d'utiliser le gestionnaire de paquets fourni par votre système d'exploitation (par ex.« rpm » ou « yum » pour les ditributions GNU/Linux, ou « ppm » pour Windows si vous utilisez ActivePerl, consulter Section 2.5.1.2, « Modules Perl sur Win32 »). Si certains modules Perl sont toujours manquants ou sont trop vieux, nous vous recommandons alors d'utiliser le script install-module.pl (il ne fonctionne pas avec ActivePerl sous Windows). Si pour une raison ou une autre vous avez vraiment besoin d'installer les modules Perl manuellement, consulter Annexe C, Manuel d'installation des modules Perl. Par exemple, sous GNU/Linux, le script install-module.pl est exécuté ainsi : bash# perl install-module.pl [Astuce] Beaucoup de gens se plaignent que les modules Perl ne s'installent pas pour eux. La plupart du temps, les messages d'erreur indiquent un fichier manquant dans « @INC ». Pratiquement à chaque fois, cette erreur est due aux permissions qui sont trop restrictives pour compiler les modulesPerl ou à l'absence des bibliothèques de développement Perl installées sur votre système. Consultez votre administrateur système Unix local pour vous aider à résoudre ces problèmes de permissions ; si vous êtes l'administrateur système Unix local, veuillez consulter le forum ou la liste de discussion pour plus d'assistance ou engagez quelqu'un pour vous aider. [Note] Si vous utilisez un paquet fourni par votre système d'exploitation et que vous essayez d'installer les modules Perl à partir de CPAN, vous aurez peut-être besoin d'installer les paquets « développement » pour MySQL et GD avant d'essayer d'installer les modules Perl relatifs. Le nom de ces paquets varieront en fonction de la distribution que vous utilisez, mais ils sont souvent appelés -devel. Voici la liste complète des modules et leur version minimum. Certains modules ont des notes d'installation spéciales qui suivent cette liste. Modules Perl nécessaires : 1. CGI (3.51) 2. Date::Format (2.23) 3. DateTime (0.28) 4. DateTime::TimeZone (0.71) 5. DBI (1.614) 6. DBD::mysql (4.001) si utilisation de MySQL 7. DBD::Pg (2.7.0) si utilisation de PostgreSQL 8. DBD::Oracle (1.19) si utilisation de Oracle 9. Digest::SHA (any) 10. Email::Send (2.04) 11. Email::MIME (1.904) 12. Template (2.22) 13. URI (1.37) Modules Perl optionnels : 1. GD (1.20) pour les tableaux de bogues 2. Template::Plugin::GD::Image (any) pour les rapports graphiques 3. Chart::Lines (2.1.0) pour les tableaux de bogues 4. GD::Graph (any) pour les tableaux de bogues 5. GD::Text (any) pour les tableaux de bogues 6. XML::Twig (any) pour l'import et l'export des bogues 7. MIME::Parser (5.406) pour l'import et l'export des bogues 8. LWP::UserAgent (any) pour les notifications automatiques de mises à jour 9. PatchReader (0.9.6) pour un affichage HTML amélioré des correctifs 10. Net::LDAP (any) pour l'authentification LDAP 11. Authen::SASL (any) pour l'authentification SASL 12. Authen::Radius (any) pour l'authentification RADIUS 13. SOAP::Lite (0.712) pour l'interface de web service 14. JSON::RPC (any) pour l'interface JSON-RPC 15. Test::Taint (any) pour l'interface de web service 16. HTML::Parser (3.67) pour plus de HTML dans les descriptions des produits et groupes 17. HTML::Scrubber (any) pour plus de HTML dans les descriptions des produits et groupes 18. Email::Reply (any) pour les courriels sortants 19. TheSchwartz (1.07) pour les files d'attente de courriel 20. Daemon::Generic (any) pour les files d'attente de courriel 21. mod_perl2 (1.999022) pour mod_perl 2.1.6. Mail Transfer Agent (MTA) Bugzilla dépend de la disponibilité d'un système de messagerie pour son authentification utilisateur et d'autres tâches. [Note] Ce n'est pas entièrement vrai. Il est possiblede désactiver complètement l'envoi de courriels, ou de faire stocker à Bugzilla les courriels dans un fichier plutôt que de les envoyer. Cependant, c'est principalement destiné aux tests, car désactiver ou détourner des courriels sur une machine de production signifierait que les utilisateurs pourrait manquer d'importants événements (comme les changements sur les bogues et la création de nouveaux comptes). Pour plus d'informations, consultez le paramètre « mail_delivery_method » dans Section 3.1, « Configuration de Bugzilla ». Sous GNU/Linux, tout MTA (Mail Transfer Agent) compatible avec Sendmail suffira. Sendmail, Postfix, qmail et Exim sont des exemples de MTA courants. Sendmail est le MTA original d'Unix, mais les autres sont plus faciles à configurer et par conséquent, beaucoup de gens remplacent Sendmail par Postfix ou Exim. Ce sont des remplacements trasparents donc Bugzilla ne fera pas la différence. Si vous utilisez Sendmail, la version 8.7 ou supérieure est requise. Si vous utilisez un MTA compatible avec Sendmail, il doit être congruent avec au moins la version 8.7 de Sendmail. Consultez le manuel du MTA que vous avez choisi pour des instructions d'installation détaillées. Chacun de ces programmes a ses propres fichiers de configuration ou vous devez configurer certains paramètres pour vous assurer que les courriels seront distribués correctement. Ils sont mis en œuvres en tant que services et vous devez vous assurer que le MTA est dans la liste de démarrage automatiques des services de votre machine. Si un courrier envoyé avec le programme en ligne de commande mail réussit, alors Bugzilla devrait fonctionner correctement. 2.1.7. Installer Bugzilla avec mod_perl Il est maintenant possible d'exécuter Bugzilla dans mod_perl sur Apache. mod_perl a des prérequis supplémentaires autre que celui d'exécuter Bugzilla sous mod_cgi (la manière standard et précédente). Bugzilla nécessite que mod_perl soit installé, lequel peut être obtenu sur http://perl.apache.org - Bugzilla nécessite que la version 1.999022 (aussi connue comme 2.0.0-RC5) soit installée. 2.2. Configuration [Avertissement] Des installations mal configurées de MySQL et Bugzilla ont permis de donner l'accès complet au système aux pirates dans le passé. Veuillez prendre au sérieux les recommandations sur la sécurité de ce guide, même pour des machines Bugzilla protégées derrière votre pare-feu. Assurez-vous de lire Chapitre 4, La sécurité dans Bugzilla pour ces conseils sur la sécurité importants. 2.2.1. localconfig Vous devez maintenant exécuter checksetup.pl à nouveau, cette fois sans l'argument --check-modules. bash# ./checksetup.pl Cette fois, checksetup.pl devrait vous dire que tous les modules appropriés sont installés et affichera un message à ce sujet, et générera un fichier de sortie appelé localconfig. Ce fichier contient les paramètres par défaut pour un grand nombre de paramètres de Bugzilla. Ouvrez ce fichier dans votre éditeur. Les deux seules valeurs que vous avez besoin de changer sont « $db_driver » et « $db_pass », respectivement le type de base de données et le mot de passe pour l'utilisateur qui créera pour vous la base de données. Choisissez un mot de passe compliqué (pour la simplicité, il ne dervait pas contenir d'apostrophe) et saisissez-le dans le fichier. « $db_driver » peut être 'mysql', 'Pg', 'oracle' ou 'SQLite'. [Note] Sous Oracle, $db_name devrait en fait être le nom du SID de votre base de données (par ex. « XE » si vous utilisez Oracle XE). Vous devrez peut-être changer la valeur de webservergroup si votre serveur Web ne s'exécute pas dans le groupe « apache ». Sur Debian, par exemple, Apache s'exécute dans le groupe « www-data ». Si vous allez exécuter Bugzilla sur une machine où vous n'avez pas l'accès « root » (comme sur un serveur Web partagé hébergé), vous aurez besoin de laisser webservergroup vide, en ignorant les avertissements que checksetup.pl affichera à chacune de ses exécutions. [Attention] Si vous utilisez « suexec », vous devez utiliser votre propre groupe principal pour webservergroup plutôt que de le laisser vide, et consultez les autres directives dans la section suexec Section 2.6.6.1, « suexec ou hébergement partagé ». Les autres options du fichier localconfig sont documentés par les commentaires les accompagnant. Si vous avez une configuration légèrement non-standard, vous voudrez sans doute modifier un ou plusieurs autres paramètres « $db_* ». 2.2.2. Serveur de base de données Cette section traite de la configuration de votre serveur de base de données utilisé avec Bugzilla. Actuellement, MySQL (Section 2.2.2.2, « MySQL »), PostgreSQL (Section 2.2.2.3, « PostgreSQL »), Oracle (Section 2.2.2.4, « Oracle ») et SQLite (Section 2.2.2.5, « SQLite ») sont disponibles. 2.2.2.1. Schéma de la base de données de Bugzilla Le schéma de la base de données de Bugzilla est disponible est disponible sur Ravenbrook. Cet outil très utile peut générer une description écrite du schéma de la base de données de Bugzilla pour toute version de Bugzilla. Il peut aussi générer un diff entre deux versions pour aider quelqu'un à voir ce qui a changé. 2.2.2.2. MySQL [Attention] La configuration par défaut de MySQL est peu sécurisée. Nous vous recommandons vivement d'exécuter mysql_secure_installation sous Linux ou l'installeur de MySQL sous Windows, et de suivre les instructions. Les points importants à noter sont : 1. Assurez-vous que le compte root a son mot de passe défini. 2. Ne créez pas de compte anonyme, et s'il en existe un, dites « oui » pour le supprimer. 3. Si votre serveur Web et le serveur MySQL sont sur la même machine, vous devriez désactiver l'accès par le réseau. 2.2.2.2.1. Autoriser les gros fichiers et plusieurs commentaires Par défaut, MySQL ne vous autorisera à insérer dans la base de données, que des objets plus petits que 1 Mo. Les fichiers joints peuvent être plus gros que cela. De même, Bugzilla concatène tous les commentaires d'un bogue dans un seul champ pour la recherche plein texte, et la somme de tous les commentaires d'un bogue sera vraisemblablement supérieure à 1 Mo. Pour changer ce paramètre par défaut de MySQL, vous devez modifier votre fichier de configuration MySQL, qui est habituellement /etc/my.cnf sous Linux. Nous vous recommandons d'autoriser au moins des paquets de 4 Mo en ajoutant le paramètre max_allowed_packet dans votre fichier de configuration MySQL dans la section [mysqld], comme ceci : [mysqld] # Allow packets up to 4MB max_allowed_packet=4M 2.2.2.2.2. Autoriser les mots courts dans les index texte intégral Par défaut, les mots doivent avoir au moins quatre caractères afin d'être indéxés par les index texte intégral de MySQL. Ceci fait que beaucoup de mots clés spécifique peuvent être manqués, y compris « cc », « ftp » et « uri ». MySQL peut être configuré pour indexer ces mots en définissant le paramètre « ft_min_word_len » pour la taille minimale des mots à indexer. Ceci peut être fait en modifiant le fichier /etc/my.cnf comme l'indique 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 suivant les indications de la documentation sur http://www.mysql.com/doc/fr/Fulltext_Fine-tuning.html. 2.2.2.2.3. Ajouter un utilisateur à MySQL Vous avez besoin d'ajouter un nouvel utilisateur à MySQL pour Bugzilla. (Il n'est pas sûr de faire utiliser par Bugzilla le compte « root » de MySQL). Les instructions suivantes supposent que vous utilisez les options par défaut dans localconfig ; si vous changez celles-ci, vous devez modifier la commande SQL en conséquence. Vous aurez besoin du mot de passe $db_pass que vous avez défini dans le fichier localconfig : Section 2.2.1, « localconfig ». Nous utilisons une commande SQL GRANT pour créer un utilisateur « bugs ». Ceci limite aussi l'utilisateur « bugs » aux opérations dans la base de données appelées « bugs » et ne permet à ce compte de se connecter qu'à partir de « localhost ». Modifiez-le pour refléter votre configuration si vous voulez vous connecter à partir d'une autre machine ou avec un utilisateur différent. Exécutez le client en ligne de commande mysql et saisissez : 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; 2.2.2.2.4. Autoriser la table des fichiers joints à dépasser les 4 Go Par défaut, MySQL limitera la table à 4 Go. Cette limite est présente même si le système d'exploitation sur lequel est exécuté MySQL n'a pas cette limite. Pour définir une limite plus haute, suivez ces instructions. Après avoir terminé le reste de l'installation (ou au moins les parties concernant la configuration de la base de données), vous devez exécuter le client en ligne de commande MySQL et saisir les commandes suivantes, en remplaçant $bugs_db avec votre nom de base de données (bugs par défaut) : mysql> use $bugs_db mysql> ALTER TABLE attachments AVG_ROW_LENGTH=1000000, MAX_ROWS=20000; La commande ci-dessus changera la limite à 20 Go. Mysql devra faire une copie temporaire de toute votre table pour faire ceci. Idéalement, vous devriez faire ceci quand la table des fichiers joint est encore petite. [Note] Ceci n'affecte pas le champ « Gros fichiers », les fichiers qui sont stockés directement sur disque au lieu de la base de données. 2.2.2.3. PostgreSQL 2.2.2.3.1. Ajouter un utilisateur à PostgreSQL Vous devez ajouter un nouvel utilisateur pour PostgreSQL pour que Bugzilla accède à la base de données. Les instructions suivantes supposent que vous utilisez les options par défaut dans localconfig ; si vous changez celles-ci, vous devrez modifier les commandes en conséquence. Vous devrez utiliser le mot de passe $db_pass que vous vaez défini dans localconfig : Section 2.2.1, « localconfig ». Sur la plupart des systèmes, pour créer l'utilisateur dans PostgreSQL, vous devrez vous connecter en tant qu'utilisateur « root » et saisir la commande bash# su - postgres en tant qu'utilisateur « postgres », vous devez créer un nouvel utilisateur : bash$ createuser -U postgres -dRSP bugs Quand un mot de passe vous sera demandé, fournissez le mot de passe qui sera défini pour $db_pass dans localconfig. L'utilisateur créé ne sera pas un super utilisateur (-S) et ne pourra pas créer de nouveaux utilisateurs (-R). Il aura seulement la possibilité de créer des bases de données (-d). [Note] Si vous utilisez PostgreSQL 8.0, vous devez remplacer -dRSP par -dAP. 2.2.2.3.2. Configurer PostgreSQL Maintenant, vous devez modifier le fichier pg_hba.conf qui se trouve habituellement dans le répertoire /var/lib/pgsql/data/. Dans ce fichier, vous devez ajouter une nouvelle ligne, comme indiqué ci-dessous : host all bugs 127.0.0.1 255.255.255.255 md5 Ceci signifie pour les connexions TCP/IP (hôte), de les autoriser pour « 127.0.0.1 » pour « all » (toutes) les bases de données de ce serveur pour l'utilisateur « bugs », et d'utiliser l'authentification de mot de passe (md5) pour cet utilisateur. Maintenant, vous devez redémarrer PostgreSQL, mais vous devrez arrêter complètement le serveur et le démarrer au lieu de seulement le redémarrer à cause de la possibilité d'un changement dans le fichier postgresql.conf. Après le redémarrage du serveur, vous devrez modifier le fichier localconfig, en cherchant la variable $db_driver et en la définissant à Pg et en changeant le mot de passe dans $db_pass pour celui que vous avez choisi précédemment, lors de la création du compte. 2.2.2.4. Oracle 2.2.2.4.1. Créer un nouveau tablespace Vous pouvez utiliser un tablespace existant ou en créer un nouveau pour Bugzilla. Pour créer un nouveau tablespace, exécutez la commande suivante : CREATE TABLESPACE bugs DATAFILE '$path_to_datafile' SIZE 500M AUTOEXTEND ON NEXT 30M MAXSIZE UNLIMITED Ici, le nom du tablespace est 'bugs', mais vous pouvez choisir un autre nom. $path_to_datafile est le chemin d'accès au fichier contenant votre base de données, par exemple /u01/oradata/bugzilla.dbf. La taille initiale du fichier de base de données est défini dans cet exemple à 500 Mo, avec un incrément de 30 Mo chaque fois que la taille limite du fichier est atteinte. 2.2.2.4.2. Ajouter un utilisateur à Oracle Le nom d'utilisateur et le mot de passe doivent correspondre à ce que vous avez défini dans localconfig ($db_user et $db_pass, respectivement). Ici, nous supposons que l'utilisateur est 'bugs' et que le nom du tablespace est identique. CREATE USER bugs IDENTIFIED BY "$db_pass" DEFAULT TABLESPACE bugs TEMPORARY TABLESPACE TEMP PROFILE DEFAULT; -- GRANT/REVOKE ROLE PRIVILEGES GRANT CONNECT TO bugs; GRANT RESOURCE TO bugs; -- GRANT/REVOKE SYSTEM PRIVILEGES GRANT UNLIMITED TABLESPACE TO bugs; GRANT EXECUTE ON CTXSYS.CTX_DDL TO bugs; 2.2.2.4.3. Configurer le serveur Web Si vous utilisez Apache, ajoutez ces lignes au fichier httpd.conf pour définir les variables ORACLE_HOME et LD_LIBRARY_PATH. Par exemple : SetEnv ORACLE_HOME /u01/app/oracle/product/10.2.0/ SetEnv LD_LIBRARY_PATH /u01/app/oracle/product/10.2.0/lib/ Quand ceci est fait, redémarrez votre serveur Web. 2.2.2.5. SQLite [Attention] En raison des limitations de concurrence de SQLite, nous ne le recommandons que pour des petites installations de Bugzilla ou des installations de développement. Aucune configuration spéciale n'est requise pour exécuter Bugzilla avec SQLite. La base de données sera stockée dans data/db/$db_name, où $db_name est le nom de la base de données définie dans localconfig. 2.2.3. checksetup.pl Ensuite, ré-exécutez checksetup.pl. Il confirmera à nouveau que tous les modules sont présents et remarquera la modification du fichier localconfig, en supposant que vous l'avez modifié à votre convenance. Il compile ensuite les modèles de l'interface utilisateur, 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 crée enfin la base de données « bugs » et les tables à l'intérieur. Après cela, il demande des détails sur le compte administrateur. Bugzilla peut avoir plusieurs administrateurs - vous pouvez en créer plus plus tard - mais il en a besoin d'un pour démarrer. Saisissez l'adresse électronique d'un administrateur, son nom complet, et un mot de passe approprié pour Bugzilla. checksetup.pl se terminera alors. Vous pouvez relancer checksetup.pl à tous moments si vous le souhaitez. 2.2.4. Le serveur Web Configurer votre serveur Web selon les instructions de la section appropriée. (Si cela peut faire une différence dans votre choix, l'équipe de Bugzilla recommande Apache). Pour vérifier si votre serveur Web est correctement configuré, essayez d'accéder à la page testagent.cgi à partir de votre serveur Web. Si « OK » est affiché, alors votre configuration est correcte. Peu importe le serveur Web que vous utilisez, assurez-vous que les informations sensibles ne sont pas accessibles à distance en appliquant des contrôles d'accès corrects dans Section 4.2.1, « Désactiver l'accès à distance aux fichiers de configuration de Configuration ». Vous pouvez exécuter testserver.pl pour vérifier si votre serveur Web sert les pages de Bugzilla comme prévu. 2.2.4.1. Bugzilla utilisant Apache vous avez deux options pour exécuter Bugzilla sur Apache : mod_cgi (par défaut) et mod_perl (nouveau à partir de Bugzilla 2.23) 2.2.4.1.1. Apache httpd™ avec mod_cgi Pour configurer votre serveur Web Apache pour fonctionner avec Bugzilla en utilisant mod_cgi, suivez les instructions suivantes : 1. Ouvrez le fichier httpd.conf dans votre éditeur. Sous Fedora et Red Hat Linux, ce fichier se trouve dans /etc/httpd/conf. 2. Apache utilise des directives pour permettre des paramètrages de permissions granulaires. Ajoutez les lignes suivantes à une directive s'appliquant à l'emplacement de votre installation Bugzilla. (Si une telle section n'existait pas, vous devrez en ajouter une). Dans cet exemple, Bugzilla a été installé dans /var/www/html/bugzilla. AddHandler cgi-script .cgi Options +ExecCGI DirectoryIndex index.cgi index.html AllowOverride All Ces instructions : autorisent Apache à exécuter les fichiers « .cgi » se trouvant dans le répertoire bugzilla ; indiquent au serveur de chercher un fichier appelé index.cgi, ou s'il n'est pas trouvé, index.html, si quelqu'un saisit seulement le nom du répertoire dans le navigateur ; et autorisent les fichiers .htaccess de Bugzilla à outrepasser quelques permissions globales. [Note] Il est possible de faire ces changements globalement ou sur la directive contrôlant le répertoire parent de Bugzilla (par ex. ). De tels changements s'appliquent aussi au répertoire de Bugzilla directory… mais ils s'appliqueraient aussi à plein d'autres endroits où cela pourrait ne pas être approprié. Dans la plupart des cas, y compris celui-ci, il est mieux d'être aussi restrictif que possible lors de l'affectation de droits d'accès supplémentaires. [Note] Sous Windows, vous pourriez aussi avoir à ajouter la ligne ScriptInterpreterSource Registry-Strict, voir les notes spécifiques pour Windows. 3. checksetup.pl peut définir des permissions plus réduites sur les fichiers et répertoires de Bugzilla s'il connaît le groupe dans lequel est exécuté le serveur Web. Cherchez la ligne Group dans le fichier httpd.conf, placez la valeur trouvée ici dans la variable $webservergroup du fichier localconfig, puis, ré-exécutez checksetup.pl. 4. Optionnel : Si Bugzilla ne se trouve pas dans le répertoire de l'espace Web, mais a été lié symboliquement ici, vous devrez ajouter ce qui suit à la ligne Options de la directive de Bugzilla (la même que dans l'étape précedente) : +FollowSymLinks Sans cette directive, Apache ne suivra pas les liens symboliques aux emplacements extérieurs à sa propre structure de répertoires et vous ne pourrez pas exécuter Bugzilla. 2.2.4.1.2. Apache httpd™ avec mod_perl Une certaine configuration est requise pour faire fonctionner Bugzilla avec Apache et mod_perl 1. Ouvrez httpd.conf dans votre éditeur. sous Fedora et Red Hat Linux, ce fichier se trouve dans /etc/httpd/conf. 2. Ajoutez les informations suivantes à votre fichier httpd.conf, en substituant où cela est approprié vos propres chemins d'accès locaux. [Note] Ceci doit être utilisé au lieu du bloc indiqué plus haut. Ceci doit aussi être placé au-dessus de toute autre directive mod_perl dans le fichier httpd.conf et doit être spécifié dans l'ordre indiqué ci-dessous. [Avertissement] Vous devez aussi vous assurer que vous avez désactivé la gestion de KeepAlive dans votre installation Apache en utilisant Bugzilla avec mod_perl PerlSwitches -w -T PerlConfigRequire /var/www/html/bugzilla/mod_perl.pl 3. checksetup.pl peut définir des permissions plus réduites sur les fichiers et répertoires de Bugzilla s'il connaît le groupe dans lequel est exécuté le serveur Web. Cherchez la ligne Group dans le fichier httpd.conf, placez la valeur trouvée ici dans la variable $webservergroup du fichier localconfig, puis, ré-exécutez checksetup.pl. Au redémarrage d'Apache, Bugzilla devrait alors fonctionner en environnement mod_perl. Veuillez vous assurer d'avoir exécuté checksetup.pl pour définir les permissions avant de redémarrer Apache. [Note] Veuillez garder à l'esprit les points suivants quand vous cherchez à utiliser Bugzilla avec mod_perl : * La gestion mod_perl dans Bugzilla peut consommer ÉNORMÉMENT de RAM. Vous pouvez compter facilement 30 Mo par processus httpd enfant. En gros, vous avez seulement besoin de beaucoup de RAM. Plus vous en aurez, mieux ce sera. mod_perl utilise basiquement la mémoire pour augmenter la vitesse de traitement. Il est recommandé d'avoir au moins 2 Go de RAM pour exécuter Bugzilla sous mod_perl. * Sous mod_perl, vous devez redémarrer Apache si vous faites un chagement manuel sur tout fichier de Bugzilla. vous ne pouvez pas seulement recharger -- vous devez en fait redémarrer le serveur (être sûr qu'il soit arrêté puis démarré à nouveau) Vous pouvez modifier le fichier localconfig et le fichier des paramètres, si vous le voulez, car ceux-ci sont lus chaque fois que vous chargez une page. * Vous devez exécuter « Prefork MPM » de Apache (c'est l'option par défaut). Le « Worker MPM » peut ne pas fonctionner -- nous n'avons pas testé Bugzilla sous mod_perl avec la gestion des threads. (Et en fait, nous sommes pratiquement sûrs que cela ne fonctionnera pas.) * Bugzilla s'attend généralement à être la seule application fonctionnant sous mod_perl sur tout le serveur. Il peut ne pas fonctionner s'il y a d'autres applications fonctionnant aussi sous mod_perl. Il s'efforcera de cohabiter avec d'autres applications sous mod_perl, mais il pourra y avoir des conflits. * Il est recommandé de n'avoir qu'une seule instance de Bugzilla fonctionnant sous mod_perl sur votre serveur. Bugzilla n'a pas été testé avec plus d'une instance. 2.2.4.2. Microsoft Internet Information Services™ Si vous voulez exécuter Bugzilla sur Windows et choisir d'utiliser Microsoft Internet Information Services™ ou Personal Web Server™ vous aurez besoin de réaliser d'autres étapes de configuration comme expliqué ci-dessous. Vous pouvez aussi vous référez aux articles de la base de connaissance de Microsoft : 245225 « HOW TO: Configure and Test a PERL Script with IIS 4.0, 5.0, and 5.1 » (pour Internet Information Services™) et 231998 « HOW TO: FP2000: How to Use Perl with Microsoft Personal Web Server on Windows 95/98 » (pour Personal Web Server™). Vous devrez créer un répertoire virtuel pour l'installation de Bugzilla. Mettez les fichiers Bugzilla dans un répertoire appelé autrement que le nom que vous voulez que vos utilisateurs voient. C'est-à-dire, si vous voulez que vos utilisateurs accèdent à votre installation Bugzilla par « http:///Bugzilla », alors ne mettez pas vos fichiers Bugzilla dans un répertoire nommé « Bugzilla ». Au lieu de cela, placez les dans un emplacement différent et utilisez l'outil d'administration de IIS pour créer un répertoire virtuel nommé « Bugzilla » qui se comporte comme un alias pour l'emplacement réel des fichiers. Lors de la création du répertoire virtuel, assurez-vous d'ajouter les permissions « Exécuter les scripts ». Vous devrez aussi indiquer à IIS comment Bugzilla doit manipuler les fichiers « .cgi ». Utilisez à nouveau l'outil d'administration de IIS, ouvrez les propriétés du nouveau répertoire virtuel et sélectionnez l'option « Configuration » pour accéder à l'association de fichiers. Créez une entrée « .cgi » ainsi : \perl.exe -x -wT "%s" %s Par exemple : c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s [Note] L'installation de ActiveState a peut-être déjà créé une entrée pour les fichiers « .pl » qui est limitée à « GET,HEAD,POST ». Si c'est le cas, cette association doit être retirée car les fichiers « .pl » de Bugzilla ne sont pas conçus pour être exécutés par un serveur Web. IIS devra aussi savoir que le fichier index.cgi doit être traité comme le document par défaut. Dans l'onglet « Documents » dans la page de propriétés du répertoire virtuel, vous devez ajouter « index.cgi » comme type de document par défaut. si vous le souhaitez, vous pouvez retirer les autres types de document pour ce répertoire virtuel particulier, puisque Bugzilla ne les utilise pas. Et aussi, nous ne le dirons jamais assez, assurez-vous que les fichiers tels que localconfig et votre répertoire data sont sécurisés comme indiqué dans Section 4.2.1, « Désactiver l'accès à distance aux fichiers de configuration de Configuration ». 2.2.5. Bugzilla Votre installation de Bugzilla devrait à présent fonctionner. Accédez à la page http:/// - vous devriez voir la page d'accueil de Bugzilla. Si ce n'est pas le cas, consultez la section « Dépannage », Annexe A, Dépannage. [Note] L'URL ci-dessus peut être incorrecte si vous avez installé Bugzilla dans un sous-répertoire ou utilisé un lien symbolique depuis la racine de votre site Web vers le répertoire de Bugzilla. Connectez-vous avec le compte administrateur que vous avez défini lors du dernier lancement de checksetup.pl. Rendez-vous sur la page des paramètres et regardez s'il y a des paramètres que vous souhaitez changer. Les paramètres clés sont documentés dans Section 3.1, « Configuration de Bugzilla » ; vous devriez certainement modifier les paramètres maintainer et urlbase ; vous pourriez aussi vouloir modifier les paramètres cookiepath ou requirelogin. Bugzilla comporte plusieurs fonctionnalités optionnelles qui nécessitent une configuration supplémentaire. Vous pouvez lire cela dans Section 2.3, « Configuration optionnelle supplémentaire ». 2.3. Configuration optionnelle supplémentaire Bugzilla a beaucoup de fonctionnalités optionnelles. Cette section décrit comment les configurer ou les activer. 2.3.1. Graphiques de bogues Si vous avez installé les modules Perl nécessaires, vous pouvez commencer à collecter les statistiques pour les graphiques de Bugzilla. bash# crontab -e Ceci devrait ouvrir le fichier crontab dans votre éditeur. Ajoutez une entrée « cron » comme celle-ci pour exécuter collectstats.pl quotidiennement à minuit cinq : 5 0 * * * cd && ./collectstats.pl Après deux jours, vous pourrez consulter des graphiques de bogues à partir de la page « Rapports ». [Note] Windows ne dispose pas de l'outil « cron », mais il dispose des « Tâches programmées », qui accomplit les mêmes travaux. Il existe également des outils tiers qui peuvent être utilisés pour mettre en œuvre « cron », tel que nncron. 2.3.2. Les notifications programmées À quoi servent les bogues s'ils ne sont pas ennuyeux ? Pour qu'ils le soient plus, vous pouvez paramétrer le système de notifications automatique de Bugzilla pour rappeler aux ingénieurs leurs bogues qui sont dans l'état CONFIRMÉ et qu'ils n'ont pas triés. Ceci peut être réalisé en ajoutant la commande suivante dans le fichier crontab, de la même manière que pour les graphiques de bogue, expliqué ci-dessus. Cet exemple s'exécute quotidiennement à 12:55. 55 0 * * * cd && ./whineatnews.pl [Note] Windows ne dispose pas de l'outil « cron », mais il dispose des « Tâches programmées », qui accomplit les mêmes travaux. Il existe également des outils tiers qui peuvent être utilisés pour mettre en œuvre « cron », tel que nncron. 2.3.3. Notifications À partir de Bugzilla 2.20, les utilisateurs peuvent configurer Bugzilla pour qu'il vienne les ennuyer à intervalles réguliers en faisant exécuter à Bugzilla des recherches enregistrées à certains moments et envoyer les résultats par courriels à l'utilisateur. Ceci s'appelle les « Notifications ». La manière de les configurer est décrite dans Section 5.13, « Notifications », et pour que cela fonctionne, un script Perl doit être exécuté à intervalles réguliers. Ceci peut être réalisé en ajoutant la commande suivante dans le fichier crontab, de la même manière que pour les graphiques de bogue, expliqué ci-dessus. Cet exemple s'exécute quotidiennement toutes les 15 minutes. */15 * * * * cd && ./whine.pl [Note] Les notifications peuvent être exécutées toutes els 15 minutes, aussi, si vous spécifiez des intervalles plus longs pour l'exécution de whine.pl, certains utilisateurs peuvent ne pas être notifiés aussi souvent qu'ils le souhaiteraient. Selon les personnes, cela peut être une bonne chose ou une mauvaise chose. [Note] Windows ne dispose pas de l'outil « cron », mais il dispose des « Tâches programmées », qui accomplit les mêmes travaux. Il existe également des outils tiers qui peuvent être utilisés pour mettre en œuvre « cron », tel que nncron. 2.3.4. Servir des formats alternatifs avec le bon type MIME Certaines pages de Bugzilla ont des formats alternatifs, autre que le HTML intégral. En particulier, quelques pages de Bugzilla peuvent offrir leur contenu soit en XUL (un format spécial de Mozilla, qui ressemble à un programme GUI) ou RDF (un type de XML structuré qui peut être lu par divers programmes). Pour que vos utilisateurs voient ces pages correctement, Apache doit leur envoyer le bon type MIME. Pour faire cela, ajouter les lignes suivantes à votre fichier de configuration Apache, soit dans la section de votre Bugzilla soit dans la section de votre Bugzilla : AddType application/vnd.mozilla.xul+xml .xul AddType application/rdf+xml .rdf 2.4. Plusieurs bases de données Bugzilla dans une seule installation Les instructions précédentes se référaient à une installation standard, avec une seule base de données Bugzilla. Cependant, vous pourriez vouloir héberger plusieurs installations distinctes, sans avoir plusieurs copies du code. Ceci est possible en utilisant la variable d'environnement « PROJECT ». Quand il est accédé, Bugzilla vérifie l'existence de cette variable, et si elle est présente, utilise sa valeur pour vérifier la présence d'un fichier de configuration alternatif appelé localconfig. au même emplacement que celui par défaut (localconfig). Il vérifie aussi la présence de modèles personnalisés dans le répertoire nommé au même emplacement que celui par défaut (template/). Par défaut, c'est le répertoire template/en/default donc les modèles de « PROJECT » se trouveraient dans template/en/PROJECT. Pour définir une installation alternative, exporter la variable « PROJECT=toto » avant de lancer checksetup.pl pour la première fois. Il en résultera un fichier nommé localconfig.toto au lieu de localconfig. Modifiez ce fichier comme décrit plus haut, avec la référence à une nouvelle base de données, et relancez checksetup.pl pour la populer. C'est tout. Maintenant, vous devez paramétrer le serveur Web pour lui passer cette variable d'environnement quand il est accédé via une URL alternative, comme un hôte virtuel par exemple. Ce qui suit est un exemple de ce que vous pouvez faire avec Apache, cela peut différer pour les autres serveurs Web. ServerName toto.titi.tata SetEnv PROJECT toto Alias /bugzilla /var/www/bugzilla N'oubliez pas aussi d'exporter cette variable avant d'accéder à Bugzilla par d'autres voies, comme les tâches programmées de « cron » par exemple. 2.5. Notes d'installation spécifiques aux systèmes d'exploitation Plusieurs aspects de l'installation de Bugzilla peuvent être affectés par le système d'exploitation que vous avez choisi. C'est parfois plus facile et d'autres fois plus difficile. Cette section tentera de vous aider à commprendre les difficultés de fonctionnement sur des systèmes d'exploitation spécifiques et les utilitaires disponibles pour que ce soit plus facile. Si vous avez quelque chose à ajouter ou des notes pour un système d'exploitation non couvert par cette documentation, veuillez rapporter un bogue sur http://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzilla;component=Do cumentation. 2.5.1. Microsoft Windows Faire fonctionner Bugzilla sur Windows est plus difficile que sur Unix. Pour cette raison, nous vous recommandons encore de le faire sur un systèmecompatible Unix tel que GNU/Linux. Ceci dit, si vous voulez vraiment faire fonctionner Bugzilla sur Windows, vous devrez faire les ajustements suivants. Un guide d'installation pour Windows étape par étape est également disponible si vous avez besoin de plus d'aide pour votre installation. 2.5.1.1. Win32 Perl Perl pour Windows peut être obtenu sur ActiveState. Vous devriez pouvoir trouver un binaire compilé sur http://aspn.activestate.com/ASPN/Downloads/ActivePerl/. Les intructions suivantes supposent que vous utilisez une version 5.8.1 de ActiveState. [Note] Ces instructions sont pour des versions 32-bits de Windows. Si vous utilisez une version 64-bits de Windows, vous aurez besoin d'installer Perl 32-bits pour installer les modules 32-bit comme décrit ci-dessous. 2.5.1.2. Modules Perl sur Win32 Bugzilla sur Windows nécessite les mêmes modules Perl que sur Section 2.1.5, « Modules Perl ». La différence principale est que Windows utilise PPM au lieu de « CPAN ». ActiveState fournit une interface graphique pour gérer les modules Perl. Nous vous recommandons fortement de l'utiliser. Si vous préférez utiliser ppm en ligne de commande, saisissez : C:\perl> ppm install [Note] Le référentiel PPM stocke les modules en « paquets » qui peuvent avoir un nom légèrement différent de celui du module. Si vous récupérez les modules d'ici, vous devrez prêter attention aux informations fournies lorsque vous exécutez checksetup.pl car il vous dira quel paquet vous aurez besoin d'installer. [Astuce] Si vous êtes derrière un pare-feu, vous devrez indiquer à l'utilitaire ActiveState PPM comment le passer pour accéder aux référentiels en définissant la variable d'environnement « HTTP_proxy ». Pour plus d'informations sur la définition de cette variable, consultez la documentation de ActiveState. 2.5.1.3. Servir les pages Web Comme c'est le cas pour les systèmes compatibles Unix, tout serveur Web doit être capable de faire fonctionner Bugzilla ; cependant, l'équipe de Bugzilla recommande l'utilisation d'Apache quand on lui demande. Peu importe le serveur Web que vous avez choisi, assurez-vous de lire les recommandations de sécurité dans Section 4.2.1, « Désactiver l'accès à distance aux fichiers de configuration de Configuration ». Vous pourrez trouver des informations sur la configurations de serveurs Web spécifiques dans Section 2.2.4, « Le serveur Web ». [Note] Le serveur Web cherche /usr/bin/perl pour invoquer Perl. Si vous utilisez Apache sur Windows, vous pouvez définir la directive ScriptInterpreterSource pour qu'Apache regarde au bon endroit. Insérez la ligne ScriptInterpreterSource Registry-Strict dans votre fichier httpd.conf et créez la clé de registre HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command avec la valeur C:\Perl\bin\perl.exe -T (adaptez le chemin si nécessaire). Quand ceci est fait, redémarrez Apache. 2.5.1.4. Envoyer des courriels Pour permettre à Bugzilla d'envoyer des courriels sur Windows, le serveur sur lequel s'exécute le code de Bugzilla doit pouvoir se connecter à un serveur SMTP ou être un serveur SMTP lui-même. 2.5.2. Mac OS X™ Faire fonctionner Bugzilla sur Mac OS X nécessite les ajustements suivants. 2.5.2.1. Sendmail Sur Mac OS X 10.3 et supérieur, Postfix est utilisé en tant que serveur de courriels intégré. Postfix fournit un exécutable qui imite suffisamment sendmail pour tromper Bugzilla, tant que Bugzilla peut le trouver. Bugzilla est capable de trouver le faux exécutable sendmail sans assistance. 2.5.2.2. Bibliothèques et modules Perl Modules pour Mac OS X Apple ne fournit pas la bibliothèque GD avec Mac OS X. Bugzilla en a besoin pour les graphiques de bogues. Vous pouvez utiliser MacPorts (http://www.macports.org/) ou Fink (http://sourceforge.net/projects/fink/), qui sont de nature semblable à l'installeur CPAN, mais installent les utilitaires GNU courants. Suivez les instructions pour paramétrer MacPorts ou Fink. Une fois installée, vous voudrez utiliser une de ces applications pour installer le paquet gd2. Fink vous demandera d'installer un certain nombre de dépendances, saisissez « y » et appuyez sur la touche « Entrée » pour installer toutes les dépendances puis vérifiez que cela fonctionne. vous serez alors en mesure d'utiliser CPAN pour installer le module Perl GD. [Note] Pour emêcher la création de conflits avec les logiciels installés par défaut par Apple, Fink crée sa propre arborescence de répertoires dans /sw où il installe la plupart des logiciels qu'il installe. Ceci signifie que les bibliothèques et en-têtes se trouveront dans /sw/lib et /sw/include au lieu de /usr/lib et /usr/include. Quand le script du module de configuration Perl demande où se trouve votre fichier libgd, assurez-vous d'indiquer /sw/lib. expat est aussi disponible via MacPorts ou Fink. Après avoir installé le paquet « expat », vous pourrez installer le module « XML::Parser » en utilisant CPAN. Si vous utilisez Fink, il faut faire attention. Contrairement aux versions récentes du module GD, XML::Parser ne demande pas l'emplacement des bibliothèques requises. Lors de l'utilisation de CPAN, vous devrez utiliser la séquence de commandes suivante : # perl -MCPAN -e'look XML::Parser' # perl Makefile.PL EXPATLIBPATH=/sw/lib EXPATINCPATH=/sw/include # make; make test; make install # exit La commande look téléchargera le module et engendrera un nouveau shell avec les fichiers extraits dans le répertoire courant. La commande exit vous renverra dans le shell d'origine. Vous devrez surveiller la sortie de ces commandes make, et particulièrement « make test » car des erreurs peuvent empêcher XML::Parser de fonctionner correctement avec Bugzilla. 2.5.3. Distributions GNU Linux/BSD Beaucoup de distributions GNU Linux/BSD incluent Bugzilla et ses dépendances dans leur système de gestion de paquets natif. Installer Bugzilla avec un accès « root » sur tout système GNU Linux/BSD devrait être aussi facile que de trouver le paquet Bugzilla dans l'application de gestion de paquet et de l'installer en utilisant la syntaxe de commande normale. Plusieurs distributions réalisent automatiquement la configuration correcte du serveur Web lors de l'installation. Veuillez consulter la documentation de votre distribution Linux pour des instructions sur la façon d'installer les paquets, ou pour des instructions spécifiques pour installer Bugzilla avec les outils de gestion de paquets natifs. Il existe également la page wiki de Bugzilla pour des notes d'installation spécifiques à certaines distributions. 2.6. Notes d'installation Unix (non-root) 2.6.1. Introduction Si vous utilisez un système d'exploitation *NIX en n'étant pas « root », soit par manque d'accès (serveurs Web, par exemple) soit pour raisons de sécurité, ceci détaillera comment installer Bugzilla sur ce type de configuration. Il est recommandé de lire la partie Section 2.1, « Installation » d'abord pour avoir une idée des étapes d'installation nécessaires. (Ces notes se référeront aux étapes de ce guide.) 2.6.2. MySQL Vous avez peut-être MySQL installé en tant que « root ». Si vous définissez un compte avec un hôte Web, un compte MySQL doit être créé pour vous. De là, vous pouvez créer le compte « bugs » ou utiliser le compte qui vous a été donné. [Avertissement] Vous pouvez avoir des problèmes en définissant des permissions GRANT dans la base de données. Si vous utilisez un hôte Web, il y a des 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 sur d'autres zones), mais vous pouvez demander à votre administrateur système les paramètres de sécurité définis et/ou lui demander d'exécuter la commande GRANT pour vous. Vous pourriez aussi ne pas être en mesure de changer le mot de passe de l'utilisateur « root » de MySQL (pour des raisons évidentes), aussi, sautez cette étape. 2.6.2.1. Exécuter MySQL en n'étant pas « root » 2.6.2.1.1. La méthode de configuration personnalisée Créez un fichier .my.cnf dans votre répertoire home (/home/foo dans cet exemple) comme suit… [mysqld] datadir=/home/toto/mymysql socket=/home/toto/mymysql/thesock port=8081 [mysql] socket=/home/toto/mymysql/thesock port=8081 [mysql.server] user=mysql basedir=/var/lib [safe_mysqld] err-log=/home/toto/mymysql/the.log pid-file=/home/toto/mymysql/the.pid 2.6.2.1.2. La méthode de création personnalisée Vous pouvez installer MySQL zn n'étant pas « root », si vous en avez vraiment besoin. créez-le avec la variable « PREFIX » définié à /home/toto/mysql, ou utilisez des exécutables pré-installés en spécifiant que vous voulez mettre tous les fichiers de données dans /home/toto/mysql/data. S'il y a un autre serveur MySQL qui s'exécute sur le système qui ne vous appartient pas, utilisez l'option « -P » pour spécifier un port TCP qui n'est pas utilisé. 2.6.2.1.3. Démarrer le serveur Après avoir créé votre programme « mysqld » et votre fichier « .my.cnf », vous devez initialiser les bases de données (UNE FOIS). bash$ mysql_install_db Puis démarrez le démon avec bash$ safe_mysql & après avoir lancé « mysqld » la première fois, connectez vous en tant que « root » et donnez les permissions (GRANT) aux autres utilisateurs. (Le compte « root » de MySQL n'a rien à voir avec le compte « root » des systèmes *NIX). [Note] Vous devrez démarrer les démons vous-mêmes. Vous pouvez soit demander à votre administrateur système de les ajouter aux fichiers de démarrage du système, soit ajouter une entrée dans le fichier crontab qui exécute un script vérifiant que ces démons sont lancés et les redémarre si nécessaire. [Avertissement] Ne lancez pas de démons ou autres services sur un serveur sans avoir d'abord consulter votre administrateur système ! Les démons utilisent des ressources système et en exécuter peut être en violation des conditions de service pour toute machine sur laquelle vous êtes utilisateur ! 2.6.3. Perl Dans le cas très rare où vous n'auriez pas Perl sur la machine, vous devrez construire les sources vous mêmes. Les commandes suivantes devraient installer sur votre système votre propre version de Perl : bash$ wget http://perl.org/CPAN/src/stable.tar.gz bash$ tar zvxf stable.tar.gz bash$ cd perl-5.8.1 (ou la version de Perl que vous avez) bash$ sh Configure -de -Dprefix=/home/toto/perl bash$ make && make test && make install Dès que vous avez installé Perl dans un répertoire (probablement dans ~/perl/bin), vous devrez installer les modules Perl comme détaillé plus bas dans cette page. 2.6.4. Modules Perl Installer les modules Perl sans être utilisateur « root » est réalisé en exécutant le script install-module.pl. Pour plus de détails sur ce script, consultez la documentation de install-module.pl. 2.6.5. Le serveur HTTP Idéalement, ceci nécessite aussi d'être installé avec l'utilisateur « root » et s'exécuter sous un compte spécial pour le serveur Web. Tant que le serveur autorise l'exécution des fichiers *.cgi en dehors de cgi-bin et refuser l'accès à certains fichiers (comme le fichier .htaccess), ça devrait aller. 2.6.5.1. Exécuter Apache sans être « root » Vous pouvez exécuter Apache sans être « root », mais le port devra être supérieur à 1024. Si vous saisissez la commande httpd -V, vous obtiendrez une liste des variables que votre copie système de httpd utilise. Une de celles-ci, « HTTPD_ROOT », vous indique où cette installation va rechercher ses informations de configuration. De là, vous pouvez copier les fichiers de configuration vers votre répertoire home pour les modifier. Quand vous éditez ceux-ci et que vous utilisez l'option « -d » pour outrepasser la valeur de la variable « HTTPD_ROOT » compilée dans votre serveur Web, vous prenez le contrôle de votre propre serveur Web personnalisé. [Note] Vous devrez démarrer les démons vous-mêmes. Vous pouvez soit demander à votre administrateur système de les ajouter aux fichiers de démarrage du système, soit ajouter une entrée dans le fichier crontab qui exécute un script vérifiant que ces démons sont lancés et les redémarre si nécessaire. [Avertissement] Ne lancez pas de démons ou autres services sur un serveur sans avoir d'abord consulter votre administrateur système ! Les démons utilisent des ressources système et en exécuter peut être en violation des conditions de service pour toute machine sur laquelle vous êtes utilisateur ! 2.6.6. Bugzilla Quand vous exécutez ./checksetup.pl pour créer le fichier localconfig, il listera les modules Perl qu'il trouve. S'il en manque, revenez en arrière et revérifier l'installation du module depuis Section 2.6.4, « Modules Perl », puis supprimez le fichier localconfig et essayez à nouveau. [Avertissement] L'option dans le fichier localconfig avec laquelle vous pourriez avoir des problèmes est le groupe du serveur Web. Si vous ne pouvez pas afficher la page index.cgi (une erreur d'accès refusé par exemple), vous aurez sans doute à relâcher vos permissions et à vider le groupe du serveur Web. Bien sûr, ceci peut poser des problèmes de sécurité. Avoir un shell correctement emprisonné et/ou un accès limité aux comptes du shell peut diminuer les risques de sécurité, mais utilisez ceci à vos risques et périls. 2.6.6.1. suexec ou hébergement partagé Si vous êtes sur un système qui utilise « suexec » (la plupart des environnements d'hébergement le font), vous aurez besoin de définir la valeur de webservergroup dans le fichier localconfig pour qu'elle corresponde à votre groupe principal, plutôt que celui avec lequel le serveur Web est exécuté. Vous devrez lancer les commandes suivantes après avoir exécuté ./checksetup.pl, chaque fois que vous le lancez (ou modifiez checksetup.pl pour qu'il le fasse pour vous grâce à la commande system()). for i in docs graphs images js skins; do find $i -type d -exec chmod o+r x {} \; ; done for i in jpg gif css js png html rdf xul; do find . -name \*.$i -exec ch mod o+r {} \; ; done find . -name .htaccess -exec chmod o+r {} \; chmod o+x . data data/webdot Faites particulièrement attention au nombre de point-virgules et de points. Ils sont tous importants. Une prochaine version de Bugzilla sera, avec un peu de chance, capable de faire ceci pour vous automatiquement. 2.7. Mettre à jour vers de nouvelles versions Mettre à jour vers une nouvelle version de Bugzilla est très facile. Il y a un script checksetup.pl inclus dans Bugzilla qui fera automatiquement toute la migration de la base de données pour vous. Les sections suivantes expliquent comment mettre à jour d'une version Bugzilla à une autre. Que vous mettiez à jour d'une version corrective à une autre (comme par exemple de 4.2 à 4.2.1) ou d'une version majeure à une autre (comme par exemple de 4.0 à 4.2), les instructions sont toujours les mêmes. [Note] Les exemples des sections suivantes sont écrits pour un utilisateur faisant une mise à jour à partir d'une version 4.2.1, mais les procédures sont les mêmes quelle que soit la version. Également, dans les exemples, l'installation Bugzilla de l'utilisateur se trouve dans /var/www/html/bugzilla. Si ce n'est pas le même emplacement que pour votre installation, substituez simplement les chemins d'installation quand c'est approprié. 2.7.1. Avant de mettre à jour Avant de démarrer la mise à jour, il y a quelques étapes importantes à réaliser : 1. Lisez les Notes de version de la version vers laquelle vous allez mettre à jour, particulièrement la section « Comment migrer à partir d'une version précédente ». 2. Consultez la page de Contrôle d'intégrité (Section 3.16, « Vérifier et maintenir l'intégrité de la base de données ») de votre installation avant de mettre à jour. Essayez de corriger tous les avertissements produits sur cette page avant d'aller plus loin ou vous pourriez avoir des problèmes pendant la mise à jour. 3. Arrêter votre installation Bugzilla en ajoutant du texte ou du code HTML dans le paramètre « shutdownhtml » (voir Section 3.1, « Configuration de Bugzilla »). 4. Faites une sauvegarde de votre base de données Bugzilla. CECI EST TRÈS IMPORTANT. Si quelque chose se passe mal pendant la mise à jour, votre installation peut être corrompue et irrécupérable. Avoir une sauvegarde est une sécurité. [Avertissement] La mise à jour ne fonctionne que dans un sens. Vous ne pouvez pas « descendre » d'une version de Bugzilla. Si vous voulez revenir à l'ancienne version de Bugzilla pour quelque raison que ce soit, vous devrez restaurer votre base de données à partir de cette sauvegarde. Voici quelques exemples de commandes que vous pourriez utiliser pour sauvegarder votre base de données, en fonction du système de gestion de base de données que vous utilisez. Vous pourriez avoir à modifier ces commandes en fonction de vos paramètres d'installation. MySQL : mysqldump --opt -u bugs -p bugs > bugs.sql PostgreSQL : pg_dump --no-privileges --no-owner -h localhost -U bugs > bugs.sql 2.7.2. Obtenir la nouvelle version de Bugzilla Il existe trois moyens d'obtenir la nouvelle version de Bugzilla. Nous allons les lister brièvement ici, puis nous les expliquerons plus en détail ensuite. Bzr (Section 2.7.2.2, « Mettre à jour en utilisant Bzr ») Si bzr est installé sur votre machine et que vous avez un accès à Internet, ceci est le moyen le plus facile pour mettre à jour, en particulier si vous avez fait des modifications dans le code ou les templates de Bugzilla. Télécharger l'archive (Section 2.7.2.3, « Mettre à jour en utilisant l'archive ») Ceci est un moyen très simple de mettre à jour, et bien si vous n'avez fait que peu (ou pas) de modifications dans le code ou dans les templates de Bugzilla. Correctifs (Section 2.7.2.4, « Mettre à jour en utilisant les correctifs ») Si vous avez des modifications dans votre installation Bugzilla et que vous n'avez pas d'accès à Internet ou que vous ne voulez pas utiliser cvs, alors ceci est le meilleur moyen de mise à jour. Vous ne pouvez faire que des mises à jour mineures (comme par exemple de 4.2 à 4.2.1 ou de 4.2.1 à 4.2.2) avec les correctifs. 2.7.2.1. Si vous avez modifié votre installation Bugzilla si vous avez modifié le code ou les templates de votre installation Bugzilla, alors la mise à jour nécessite un peu plus d'effort et de réflexion. Une discussion sur les diverses méthodes de mise à jour en fonction du degré et des méthodes de personnalisation locaux se trouve dans Section 6.3.2, « Choisir une méthode de personnalisation ». Plus l'écart de version est important, plus il sera difficile de mettre à jour si vous avez fait des personnalisations locales. Une mise à jour d'une version 4.2. vers une version 4.2.1 devrait se faire sans peine, même si vous avez fortement personnalisé votre installation. Mais passer d'une version 2.18 à une version 4.2 un gros travail de ré-écriture de vos changements locaux pour utiliser les nouveaux fichiers, logique, templates, etc. Si vous n'avez pas fait de changement locaux du tout cependant, alors la mise à jour devrait représenter approximativement la même quantité de travail, quelle que soit la version que vous utilisez actuellement. 2.7.2.2. Mettre à jour en utilisant Bzr Ceci nécessite que bzr soit installé (c'est le cas pour la plupart des machines Unix), et aussi que vous puissiez accéder à bzr.mozilla.org, ce qui peut ne pas être une option si vous n'avez pas d'accès à Internet. Ci-dessous, la séquence des commandes nécessaires pour mettre à jour une installation Bugzilla par Bzr, et les résultats typiques obtenus. En supposant que Bugzilla a déjà éé installé en utilisant Bzr. [Avertissement] Si votre installation utilise encore CVS, vous devez d'abord la convertir vers Bzr. Une documentation très détaillée est disponible sur wiki.mozilla.org. bash$ cd /var/www/html/bugzilla bash$ bzr switch 4.2 (n'utilisez cette commande que si vous n'utilisez pas déjà la version 4.2) bash$ bzr up -r tag:bugzilla-4.2.1 +N extensions/MoreBugUrl/ +N extensions/MoreBugUrl/Config.pm +N extensions/MoreBugUrl/Extension.pm … M Bugzilla/Attachment.pm M Bugzilla/Attachment/PatchReader.pm M Bugzilla/Bug.pm … All changes applied successfully. [Attention] Si une ligne de résultat de bzr update mentionne un conflit, cela représente alors un fichier avec des changements locaux que Bzr n'est pas capable de fusionner correctement. Vous devez résoudre manuellement ces conflits avant que Bugzilla (ou tout au moins la portion utilisant ce fichier) ne soit utilisable. 2.7.2.3. Mettre à jour en utilisant l'archive Si vous ne pouvez (ou ne voulez) pas utiliser Bzr, une autre option est toujours disponible pour obtenir la dernière archive à partir de la Page de téléchargements pour créer une nouvelle installation de Bugzilla à partir de celle-ci. Cette séquence de commandes montre comment obtenir l'archive en ligne de commande ; il est aussi possible de la télécharger à partir du site directement dans le navigateur. Si vous procédez ainsi, enregistrez le fichier dans le répertoire /var/www/html (ou son équivalent, si vous utilisez autre chose) et passez les trois premières lignes de l'exemple. bash$ cd /var/www/html bash$ wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.2.1.tar.gz (Affichage des résultats omis) bash$ tar xzvf bugzilla-4.2.1.tar.gz bugzilla-4.2.1/ bugzilla-4.2.1/colchange.cgi (Affichage des résultats tronqué) bash$ cd bugzilla-4.2.1 bash$ cp ../bugzilla/localconfig* . bash$ cp -r ../bugzilla/data . bash$ cd .. bash$ mv bugzilla bugzilla.old bash$ mv bugzilla-4.2.1 bugzilla [Avertissement] Les commandes cp se terminent toutes deux avec un point (« . »), ce qui est un détail important (cela signifie que le répertoire de destination est le répertoire de travail courant). [Attention] Si vous avez des extensions installées, vous devrez aussi les copier dans le nouveau répertoire bugzilla. Les extensions sont situées dans bugzilla/extensions/. Ne copiez que celles que vous avez installées, pas celles gérées par l'équipe de Bugzilla. Cette méthode de mise à jour vous donnera une installation propre de Bugzilla. Ce qui est très bien si vous n'avez pas de personnalisations locales que vous voulez maintenir. Si vous avez des personnalisations, vous devrez alors les réappliquer manuellement dans les fichiers appropriés. 2.7.2.4. Mettre à jour en utilisant les correctifs Un correctif est un ensemble de corrections de bogues qui ont été faites depuis la version mineure précédente. Si vous faites une mise à jour par correctif (c'est-à-dire, où seule le dernier numéro de révsion change, comme par exemple de 4.2 à 4.2.1), alors vous pouvez obtenir et appliquer le fichier correctif à partir de la Page de téléchargements. Comme précédemment, cet exemple commence par l'obtention du fichier en ligne de commande. Si vous l'avez déjà téléchargé, vous pouvez passer les deux premières commandes. bash$ cd /var/www/html/bugzilla bash$ wget http://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-4.2-to-4.2.1 .diff.gz (Affichage des résultats omis) bash$ gunzip bugzilla-4.2-to-4.2.1.diff.gz bash$ patch -p1 < bugzilla-4.2-to-4.2.1.diff patching file Bugzilla/Constants.pm patching file enter_bug.cgi (etc.) [Avertissement] Soyez conscient que la mise à jour à partir d'un fichier correctif ne change pas les entrées dans votre répertoire .bzr. Ceci pourrait rendre plus difficile une mise à jour en utilisant Bzr (Section 2.7.2.2, « Mettre à jour en utilisant Bzr ») dans le futur. 2.7.3. Terminer la mise à jour Maintenant que vous avez le nouveau code de Bugzilla, il reste quelques étapes à accomplir pour terminer votre mise à jour. 1. Si votre nouvelle installation Bugzilla est dans un répertoire différent ou sur une machine différente de celle de votre ancienne installation Bugzilla, assurez-vous d'avoir copié le répertoire data et le fichier localconfig de votre ancienne installation Bugzilla. (Si vous avez suivi les instructions d'installation via l'archive ci-dessus, c'est déjà fait). 2. S'il s'agit d'une mise à jour majeure, vérifiez que la configuration (Section 2.2, « Configuration ») pour votre nouvelle installation de Bugzilla est à jour. Quelquefois, les prérequis de configuration changent entre une version majeure et une autre. 3. Si vous ne l'avez pas fait dans l'étape de configuration ci-dessus, vous devez maintenant exécuter checksetup.pl, qui fera tout ce qui est nécessaire pour convertir votre base de données existante et les paramètres pour la nouvelle version : bash$ cd /var/www/html/bugzilla bash$ ./checksetup.pl [Avertissement] Le point (« . ») au début de la commande ./checksetup.pl est important et ne peut pas être omis. [Attention] S'il s'agit d'une mise à jour majeure (disons de 3.6 à 4.2 ou similaire), l'exécution de checksetup.pl sur une grosse installation (75 000 bogues ou plus) peut prendre un long moment, parfois plusieurs heures. 4. Effacez tout texte ou code HTML saisi dans le paramètre « shutdownhtml » pour ré-activer Bugzilla. 5. Consultez la page (Section 3.16, « Vérifier et maintenir l'intégrité de la base de données ») Contrôle d'intégrité dans votre installation de Bugzilla mise à jour. Il est recommandé, dans la mesure du possible, de corriger immédiatement tout problème que vous voyez. Ne pas le faire peut signifier que Bugzilla ne fonctionnera pas correctement. Veuillez noter que si la page de contrôle d'intégrité contient plus d'erreurs après une mise à jour, cela ne veut pas nécessairement dire qu'il y a plus d'erreurs dans votre base de données qu'auparavant, car des tests additionnels sont ajoutés au contrôle d'intégrité avec le temps et il est possible que ces erreurs nétaient pas vérifiées dans la version précédente. 2.7.4. Notifications automatiques pour les nouvelles versions Bugzilla 3.0 a introduit la possibilité de notifier automatiquement les administrateurs lorsque de nouvelles versions sont disponibles, en fonction du paramètre upgrade_notification, voir Section 3.1, « Configuration de Bugzilla ». Les administrateurs verront ces notifications en accédant à la page index.cgi, c-à-d. généralement lors de la connexion. Bugzilla vérifie une fois par jour la présence de nouvelles versions, à moins que le paramètre soit défini à « désactivé ». Si vous êtes placé derrière un proxy, vous pourriez avoir à définir le paramètre proxy_url de façon appropriée. Si le proxy nécessite une authentification, utilisez la synatxe http://utilisateur:mot_de_passe@url_proxy/. Chapitre 3. Administrer Bugzilla Table des matières 3.1. Configuration de Bugzilla 3.1.1. Paramètres requis 3.1.2. Politiques d'administration 3.1.3. Authentification utilisateur 3.1.4. Fichiers joints 3.1.5. Politique de modification des bogues 3.1.6. Champs des bogues 3.1.7. Déplacement de bogue 3.1.8. Graphiques de dépendances 3.1.9. Restrictions de groupe 3.1.10. LDAP 3.1.11. Authentification RADIUS 3.1.12. Courriel 3.1.13. Visionneuse de correctif 3.1.14. Options par défaut des requêtes 3.1.15. Base de données esclave 3.1.16. Correspondance d'utilisateur 3.2. Administrer les utilisateurs 3.2.1. Créer l'utilisateur par défaut 3.2.2. Gérer les autres utilisateurs 3.3. Catégories 3.4. Produits 3.4.1. Créer de nouveaux produits 3.4.2. Modifier des produits 3.4.3. Ajouter ou modifier les composants, versions et jalons cibles 3.4.4. Affecter des restrictions de groupes à des produits 3.5. Composants 3.6. Versions 3.7. Jalons 3.8. Étiquettes 3.8.1. Un simple exemple 3.8.2. À propos des étiquettes 3.8.3. Utiliser les demandes d'étiquettes 3.8.4. Deux types d'étiquettes 3.8.5. Gérer les étiquettes 3.9. Keywords 3.10. Champs personnalisés 3.10.1. Ajouter des champs personnalisés 3.10.2. Modifier les champs personnalisés 3.10.3. Supprimer des champs personnalisés 3.11. Valeurs autorisées 3.11.1. Voir/Modifier les valeurs autorisées 3.11.2. Supprimer des valeurs autorisées 3.12. Worflow des états de bogue 3.13. Voter 3.14. Citations 3.15. Groupes et restrictions de groupes 3.15.1. Créer des groupes 3.15.2. Modification de groupes et affectation de restrictions 3.15.3. Affecter des utilisateurs aux groupes 3.15.4. Affecter des restrictions de groupes à des produits 3.16. Vérifier et maintenir l'intégrité de la base de données 3.1. Configuration de Bugzilla Bugzilla se configure en changeant divers paramètres accessibles à partir du lien « Paramètres » de la page Administration (la page Administration est accessible en cliquant sur le lien « Administration » dans le pied de page). Les paramètres sont divisés en plusieurs catégories, accessibles par le menu à gauche. Vous trouverez ci-dessous une description des différentes catégories et de leurs paramètres importants. 3.1.1. Paramètres requis Les paramètres principaux obligatoires pour une installation de Bugzilla sont définis ici. Ces paramètres doivent être définis avant qu'une nouvelle installation de Bugzilla soit fonctionnelle. Les administrateurs doivent revoir cette liste avant de déployer une nouvelle installation de Bugzilla. maintainer Adresse électronique de la personne responsable de la maintenance de cette installation de Bugzilla. L'adresse n'est pas nécessairement celle d'un compte Bugzilla valide. urlbase Définit le nom de domaine complet et le chemin d'accès du serveur Web de cette installation de Bugzilla. Par exemple, si la page de recherche est http://www.toto.com/bugzilla/query.cgi, « urlbase » doit être défini à http://www.toto.com/bugzilla/. docs_urlbase Définit le chemin d'accès à la documentation de Bugzilla. Cela peut-être un chemin d'accès absolu ou relatif à « urlbase ». Par exemple, si la page « Configuration de Bugzilla » de la documentation est http://www.toto.com/bugzilla/docs/html/parameters.html, définissez « docs_urlbase » à http://www.toto.com/bugzilla/docs/html/. sslbase Définit le nom de domaine complet et le chemin d'accès au serveur Web pour les connexions HTTPS (SSL) de cette installation de Bugzilla. Par exemple, si la page principale de Bugzilla est https://www.toto.com/bugzilla/index.cgi, « sslbase » doit être défini à https://www.toto.com/bugzilla/. ssl_redirect Quand ceci est activé, Bugzilla forcera des connexions HTTPS (SSL), en redirigeant automatiquement tout utilisateur essayant d'utiliserune connexion non-SSL. cookiedomain Définit le domaine pour les cookies de Bugzilla. Ceci est typiquement laissé vide. S'il y a plusieurs noms d'hôtes qui pointent vers le même serveur Web, qui nécessitent le même cookie, alors ce paramètre peut être utilisé. Par exemple, si votre site Web est https://www.toto.com/, définir ce paramètre à .toto.com/ permettra aussi à titi.toto.com/ d'accéder aux cookies de Bugzilla. cookiepath Définit un chemin, relatif à la racine du serveur Web, auquel seront restreints les cookies de Bugzilla. Par exemple, si urlbase est défini à http://www.toto.com/bugzilla/, cookiepath devrait être défini à /bugzilla/. Définir ceci à « / » permettra à tous les sites servis par ce serveur Web ou cet hôte virtuel de lire les cookies de Bugzilla. utf8 Détermine l'utilisation de l'encodage UTF-8 (Unicode) pour tout texte dans Bugzilla. Les nouvelles installations devraient définir ce paramètre à « Activé » pour éviter les problèmes d'encodage de caractères. Les bases de données existantes ne devraient définir ceci à « Activé » qu'après que les données aient été converties de l'encodage existant vers UTF-8, en utilisant le script contrib/recode.pl. [Note] Si vous passez ce paramètre de « Désactivé » à « Activé », vous devez ré-exécuter checksetup.pl immédiatement après. shutdownhtml S'il y a du texte dans ce champ, cette installation de Bugzilla sera totalement désactivée et ce texte apparaîtra à la place de toutes les pages de Bugzilla pour tous les utilisateurs, y compris les administrateurs. À utiliser dans le cadre d'une maintenance du site ou de problèmes. [Note] Bien que toute possibilité de connexion soit impossible quand shutdownhtml est activé, des garde-fous sont en place pour protéger le malachanceux administrateur qui perd sa connexion à Bugzilla. Si cela vous arrivait, allez directement dans editparams.cgi (en tapant l'URL manuellement, si nécessaire). En faisant cela vous serez invité à vous connecter, et vos nom et mot de passe seront acceptés ici (mais seulement ici). announcehtml Tout texte dans ce champ sera affiché en haut de chaque page HTML de cette installation de Bugzilla. Ce texte n'est pas encadré dans des balises. Pour de meilleurs résultats, encadrez le texte avec des balises «
». tout attribut de style de la CSS peut être appliqué. Par exemple, pour mettre le texte en vert dans une boîte rouge, ajoutez « id=message » à la balise «
». proxy_url Si cette installation de Bugzilla se trouve derrière un proxy, saisissez les informations du proxy ici pour permettre à Bugzilla d'accéder à Internet. Bugzilla nécessite un accès à Internet pour utiliser le paramètre upgrade_notification (ci-dessous). Si le proxy nécessite une authentification, utilisez la syntaxe : http://user:pass@proxy_url/. upgrade_notification Active ou désactive la notification sur la page d'accueil de cette installation de Bugzilla quand une nouvelle version de Bugzilla est disponible. Cette notification n'est visible que des administrateurs. Choisissez « disabled », pour désactiver la notification. Sinon, choisissez pour quelles versions de Bugzilla vous voulez être prévenu : « development_snapshot » est la dernière version du tronc ; « latest_stable_release » est la dernière version disponible sur la branch stable la plus récente ; « stable_branch_release » est la version la plus récente de la branche sur laquelle est basée cette installation. 3.1.2. Politiques d'administration Cette page contient les paramètres pour les fonctions administratives de base. Les options comprennent l'autorisation de la suppression de bogues et d'utilisateurs et l'autorisation pour les utilisateurs de modifier leur adresse électronique. 3.1.3. Authentification utilisateur Cette page contient les paramètres qui contrôlent la façon dont cette installation de Bugzilla fera l'authentification. Choisissez le mécanisme d'authentification à utiliser (la base de données de Bugzilla, ou une source externe comme un serveur LDAP), et définissez les paramètres de base. Par exemple, choisissez si les utilisateurs doivent s'authentifier pour parcourir les bogues, la gestion des cookies d'authentification, et les expressions régulières utilisées pour valider les adresses électroniques. Certains paramètres sont soulignés ci-dessous. emailregexp Définit l'expression régulière utilisée pour valider les adresses électroniques utilisées pour les noms de connexion. Par défaut, une correspondance totale est recherchée (par ex. « utilisateur@exemple.com ») d'une façon légèrement plus restrictive que ce sui est autorisé dans la RFC 2822. Certaines installations de Bugzilla n'autorisent que des noms d'utilisateurs locaux (par ex. « utilisateur » au lieu de « utilisateur@exemple.com »). Dans ce cas, ce paramètre doit être utilisé pour définir le domaine des adresses électroniques. emailsuffix Cette chaîne est ajoutée aux noms de connexion lors de l'envoi d'un courriel à un utilisateur. Par exemple, si emailregexp a été défini pour permettre les noms d'utilisateurs locaux, alors ce paramètre doit contenir le domaine des adresses électroniques pour tous les utilisateurs (par ex. « @exemple.com »). 3.1.4. Fichiers joints Cette page permet la définition des restrictions et d'autres paramètres concernant les fichiers joints aux bogues. Par exemple, le contrôle des limitations de taille et l'autorisation de pointer vers des fichiers externes via une URI. 3.1.5. Politique de modification des bogues Définit la politique sur le comportement par défaut des événements de modification de bogues. Par exemple, choisir l'état dans lequel mettre un bogue quand celui-ci est marqué comme doublon, et choisir d'autoriser si les rapporteurs de bogues peuvent définir la priorité ou le jalon cible. Permet aussi la configuration des changements qui nécessitent un commentaire de la part des utilisateurs, décrit ci-dessous. commenton* Tous ces champs vous permettent de définir quels changements peuvent être faits sans commentaire, et ceux qui doivent avoir un commentaire de la personne qui fait les changements. Souvent, les administrateurs autoriseront les utilisateurs à s'ajouter à la liste « Copie à », à accepter les bogues ou à modifier le Tableau blanc sans ajouter de commentaire pour justifier les changements, et demanderont que la plupart des autres changements soit justifiés. Définissez les options « commenton » selon la politique de votre site. Il est sage de demander des commentaires quand les utilisateurs résolvent, réassignent ou rouvrent des bogues, au minimum. [Note] Il est généralement bien mieux de demander un commentaire au développeur lors de la résolution des bogues. Il y a peu de choses plus ennuyeuses pour les utilisateurs d'une base de données de bogues, que d'avoir un développeur marquant un bogue « CORRIGÉ » sans commentaire sur le correctif (ou même si cela a vraiment été corrigé !) noresolveonopenblockers Cette option empêchera les utilisateurs de résoudre les bogues en CORRIGÉ s'il y a des dépendances non résolues. Seule la résolution CORRIGÉ est affectée. Les utilisateurs seront encore capables de résoudre les bogues avec des résolutions autres que CORRIGÉ s'il reste des bogues dépendants non résolus. 3.1.6. Champs des bogues Les paramètres dans cette section déterminent le choix par défaut de plusieurs champs de Bugzilla pour les nouveaux bogues et contrôlent aussi si certains champs sont utilisés ou pas. Par exemple, l'utilisation des champs « Jalon cible » ou « Tableau blanc ». useqacontact Ceci permet de définir une adresse électronique pour chaque composant, en plus de celle du responsable par défaut, à laquelle seront envoyées les copies de courriel de bogues. usestatuswhiteboard Ceci définit si vous souhaitez avoir un champ de formulaire libre et modifiable associé à chaque bogue. L'avantage de ce tableau blanc est qu'il peut être effacé ou modifié facilement, et qu'il fournit un champ de recherche facile pour indexer des bogues qui ont des traits communs. 3.1.7. Déplacement de bogue Cette page définit si certains utilisateurs de cette installation de Bugzilla sont autorisés à déplacer des bogues vers une base de données externe. Si le déplacement de bogue est activé, il y a de nombreux paramètres qui contrôlent le comportement du déplacement de bogue. Par exemple, le choix des utilisateurs autorisés à déplacer les bogues, l'emplacement de la base de données externe, et le produit et le composant par défaut pour les bogues déplacés à partir d'autres bases de données de bogues vers cette installation de Bugzilla. 3.1.8. Graphiques de dépendances Cette page a un paramètre qui définit l'emplacement d'un serveur Web Dot, ou du binaire Web Dot sur le système local, qui est utilisé pour générer des graphiques de dépendance. Web Dot est un programme CGI qui crée des images à partir des fichiers de description graphique .dot. Si aucun serveur ou binaire Web Dot n'est spécifié, alors les graphiques de dépendance seront désactivés. 3.1.9. Restrictions de groupe Bugzilla permet la création de différents groupes, avec la possibilité de restreindre la visibilité des bogues dans un groupe à un ensemble d'utilisateurs spécifiques. Des produits spécifiques peuvent aussi être associés à des groupes, et des utilisateurs restreints à ne voir les produits que dans leurs groupes. Plusieurs paramètres sont décrits plus en détail ci-dessous. La plupart de la configuration des groupes et leurs relations aux produits est faite dans les pages « Groupes » et « Produit » dans la zone « Administration ». Les options sur cette page contrôlent les comportements globaux par défaut. Pour plus d'informations sur les Groupes et les restrictions de groupes, consulter Section 3.15, « Groupes et restrictions de groupes » makeproductgroups Détermine la création automatique de groupes lors de la création de nouveaux produits. Si ce paramètre est activé, les groupes seront utilisés pour les requêtes sur les bogues. usevisibilitygroups Si ce paramètre est sélectionné, la visibilité de l'utilisateur sera restreinte aux membres des groupes, tels que sélectionnés dans les paramètres de configuration de groupe. Chaque groupe défini par utilisateur peut être autorisé à voir les membres des autres groupes sélectionnés. Pour des détails sur la configuration des groupes (y compris les restrictions de visibilité), consulter Section 3.15.2, « Modification de groupes et affectation de restrictions ». querysharegroup Le nom du groupe d'utilisateurs autorisés à partager leurs recherches enregistrées avec d'autres. Pour plus d'informations sur l'utilisation des recherches enregistrées, consulter Recherches enregistrées. 3.1.10. LDAP L'authentification LDAP est un module pour l'architecture de plugin d'authentification de Bugzilla. Cette page contient tous les paramètres nécessaires pour configurer Bugzilla en utilisant l'authentification LDAP. Le schéma d'authentification existant de Bugzilla utilise les adresses électroniques comme identifiant primaire de l'utilisateur et un mot de passe pour authentifier cet utilisateur. Tous les endroits dans Bugzilla qui nécessitent un identifiant d'utilisateur (par ex. pour assigner un bogue) utilisent l'adresse électronique. L'authentification LDAP se situe au-dessus de ce schéma et ne le remplace pas. La connexion initiale est faite avec un nom d'utilisateur et un mot de passe pour l'annuaire LDAP. Bugzilla essaie de se lier à LDAP en utilisant les crédentiels et, s'il réussit, essaie d'associer ce compte à un compte Bugzilla. Si un attribut LDAP d'adresse électronique est défini, la valeur de cet attribut est utilisé, sinon, le paramètre « emailsuffix » est ajouté au nom d'utilisateur LDAP pour former l'adresse électronique complète. Si un compte pour cette adresse existe déjà dans l'installation de Bugzilla, il se connectera avec ce compte. Si aucun compte pour cette adresse électronique n'existe, il en sera créé un au moment de la connexion. (Dans ce cas, Bugzilla essaiera d'utiliser l'attribut « displayName » ou « cn » pour déterminer le nom complet de l'utilisateur). Après l'authentification, toutes les tâches liées à l'utilisateur seront toujours manipulées par l'adresse électronique et pas par le nom d'utilisateur LDAP. Par exemple, les bogues sont encore assignés par l'adresse électronique et les utilisateurs recherchés par leur adresse électronique. [Attention] Parce qu'un compte Bugzilla n'est pas créé jusqu'à ce que l'utilisateur se connecte pour la première fois, un utilisateur qui ne s'est pas encore connecté est inconnu de Bugzilla. Ceci signifie qu'il ne peut pas être utilisé comme Responsable ou Contact QA (par défaut ou non), ajouté à la liste « Copie à » ou toute autre opération de ce type. Un contournement possible est le script bugzilla_ldapsync.rb dans le répertoire contrib. Une autre solution est de résoudre le bogue 201069. Paramètres nécessaires pour utiliser l'authentification LDAP : user_verify_class Si vous voulez lister « LDAP » ici, assurez-vous d'avoir défini les autres paramètres listés ci-dessous. À moins d'avoir d'autres méthodes d'authentification (qui fonctionnent) listées aussi, vous ne pourrez pas vous reconnecter à Bugzilla une fois déconnecté. Si cela vous arrive, vous devrez modifier manuellement data/params et définir « user_verify_class » à « DB ». LDAPserver Ce paramètre doit être défini avec le nom (et optionnellement le port) de votre serveur LDAP. Si aucun port n'est spécifié, le port LDAP par défaut 389 sera utilisé. Par exemple : « ldap.societe.com » ou « ldap.societe.com:3268 » Vous pouvez également spécifier une URI LDAP, tout comme utiliser d'autre protocoles, tels que LDAPS ou LDAPI. Si le port n'était pas spécifié dans l'URI, le défaut est 389 pour « LDAP » et 636 pour « LDAPS ». [Astuce] Afin d'utiliser SSL avec LDAP, indiquez une URI avec « ldaps:// » Ceci forcera l'utilisation de SSL sur le port 636. Par exemple, pour LDAP non sécurisé : « ldap://ldap.societe.com », pour LDAP avec SSL : « ldaps://ldap.societe.com » ou pour LDAP sur un socket de domaine Unix : « ldapi://%2fvar%2flib%2fldap_sock ». LDAPbinddn [Optionnel] Certains serveurs LDAP une liaison anonyme pour faire des recherches dans l'annuaire. Si c'est le cas pour votre configuration, vous devrez définir le paramètre « LDAPbinddn » pour le compte utilisateur que Bugzilla doit utiliser à la place de la liaison anonyme. Ex. : « cn=default,cn=utilisateur:mot_de_passe » LDAPBaseDN Le paramètre « LDAPBaseDN » doit être défini pour indiquer l'emplacement dans votre arbre LDAP où vous voulez faire la recherche des adresses électroniques. Les « uid » doivent être uniques sous le « DN » indiqué ici. Ex. : « ou=Personne,o=Societe » LDAPuidattribute Le paramètre « LDAPuidattribute » doit être défini sur l'attribut qui contient les « UID » uniques de vos utilisateurs. La valeur récupérée de cet attribut sera utilisée lors de la tentative de liaison des utilisateurs pour confirmer leur mots de passe. Ex. : « uid » LDAPmailattribute Le paramètre « LDAPmailattribute » doit être le nom de l'attribut qui contient l'adresse électronique que vos utilisateurs saisiront pour se connecter dans les boîtes de connexion de Bugzilla. Ex. : « mail » 3.1.11. Authentification RADIUS L'authentification RADIUS est un module pour l'architecture de plugin d'authentification de Bugzilla. Cette page contient tous les paramètres nécessaires pour configurer Bugzilla en utilisant l'authentification RADIUS. [Note] La plupart des avertissements concernant l'authentification LDAP s'applique aussi à l'authentification RADIUS. Consulter Section 3.1.10, « LDAP » pour des détails. Paramètres requis pour utiliser l'Authentification RADIUS : user_verify_class Si vous voulez lister « RADIUS » ici, assurez-vous d'avoir défini les autres paramètres listés ci-dessous. À moins d'avoir d'autres méthodes d'authentification (en fonction) listées aussi, vous pourriez ne pas être en mesure de vous reconnecter à Bugzilla après déconnexion. Si cela se produisait, vous devriez modifier manuellement le fichier data/params et définir le paramètre « user_verify_class » à « DB ». RADIUS_server Ce paramètre doit être renseigné avec le nom (et optionnellement le port) de votre serveur RADIUS. RADIUS_secret Ce paramètre doit être renseigné avec le secret du serveur RADIUS. RADIUS_email_suffix Bugzilla a besoin d'une adresse électronique pour chaque compte utilisateur. Par conséquent, il a besoin de déterminer l'adresse électronique correspondant à un utilisateur RADIUS. Bugzilla ne propose qu'un simple moyen de faire cela : il concatène un suffixe au nom d'utilisateur RADIUS pour le convertir en adresse électronique. Vous pouvez indiquer ce suffixe dans le paramètre « RADIUS_email_suffix ». Si cette solution ne fonctionne pas pour vous, vous devrez certainement modifier Bugzilla/Auth/Verify/RADIUS.pm pour que cela corresponde à vos besoins. 3.1.12. Courriel Cette page contient tous les paramètres pour configurer la façon dont Bugzilla traitent les notifications par courriel qu'il envoie. Voir ci-dessous pour un résumé des options importantes. mail_delivery_method Ce paramètre est utilisé pour indiquer comment sont envoyés les courriels ou s'il ne faut pas les envoyer. Il y a plusieurs options pour les différents MTA, avec deux options supplémentaires qui désactivent l'envoi de courriels. « testfile » n'envoie pas les courriels mais les enregistre dans data/mailer.testfile pour qu'ils soient consultés plus tard. « none » désactive totalement l'envoi de courriels. mailfrom C'est l'adresse électronique qui apparaîtra dans le champ « De » pour tous les courriels envoyés par cette installation de Bugzilla. Certains serveurs de messagerie nécessitent une adresse électronique valide ; par conséquent, il est recommandé de choisir une adresse électronique valide ici. smtpserver C'est l'adresse du serveur SMTP, si le paramètre « mail_delivery_method » est défini pour SMTP. Utiliser « localhost » si vous utilisez un MTA local, ou le nom du serveur SMTP distant. Ajouter « : » et le numéro de port s'il ne s'agit pas du numéro de port par défaut. smtp_username Nom d'utilisateur à utiliser pour l'authentification SASL sur le serveur SMTP. Laisser ce paramètre vide si le serveur ne nécessite pas d'authentification. smtp_password Mot de passe à utiliser pour l'authentification SASL sur le serveur SMTP. Ce paramètre sera ignoré si le paramètre « smtp_username » est laissé vide. smtp_ssl Active la gestion de SSL pour la connexion au serveur SMTP. smtp_debug Ce paramètre permet d'activer le débogage détaillé. Les messages sont indiqués dans le journal d'erreur du serveur Web. whinedays Ceci indique le nombre de jours pendant lequel les bogues sont dans l'état CONFIRMÉ avant de notifier les personnes qu'elles ont de nouveaux bogues qui n'ont pas été touchés. Si vous ne comptez pas utiliser cette focntionnalité, ne définissez pas la tâche de notification « cron » décrite dans les instructions d'installation ou définissez cette valeur à « 0 » (ne jamais notifier). globalwatcher Ceci permet de définir des utilisateurs spécifiques qui recevront une notification chaque fois qu'un nouveau bogue est saisi ou lors de changements sur un bogue existant, en fonction des permissions de l'ensemble des groupes. Cela peut-être utile pour envoyer les notifications sur une liste de diffusion par exemple. 3.1.13. Visionneuse de correctif Cette page contient les paramètres de configuration pour le serveur CVS, le serveur Bonsai et le serveur LXR que Bugzilla utilisera pour activer les fonctionnalités de la visionneuse de correctif. Bonsai est un outil qui permet de faire des requêtes sur un arbre CVS. LXR est un outil qui permet de faire des références croisées et d'indexer du code source. 3.1.14. Options par défaut des requêtes Cette page contrôle le comportement par défaut de Bugzilla concernant plusieurs aspects des requêtes sur les bogues. Les options comprennent ce que sont les options de requête par défaut, ce que renvoie la page « Mes bogues », si les utilisateurs peuvent ajouter librement des bogues à la liste de citations, et le nombre de doublons de bogues nécessaire pour ajouter un bogue à la liste des « bogues les plus fréquemment rapportés ». 3.1.15. Base de données esclave Cette page contrôle si une base de données esclave est utilisée et tous les paramètres associés à cette base de données. Les versions de Bugzilla antérieures à la version 3.2 utilisaient des types de tables MyISAM, qui ne supportent que le verrouillage en écriture au niveau de la table. Avec MyISAM, chaque fois que quelqu'un fait un changement dans un bogue, la table entière est verrouillée jusqu'à ce que l'opération d'écriture soit terminée. Le verrouillage pour l'écriture bloque aussi les lectures jusqu'à ce que l'opération d'écriture soit terminée. Le paramètre « shadowdb » a été conçu pour contourner cette limitation. Alors qu'un seul utilisateur à la fois est autorisé à écrire sur une table à un moment donné, les lectures peuvent continuer sans interruption sur une base de données esclave en lecture seule. [Note] À partir de la version 3.2, Bugzilla n'utilise plus de type de table MyISAM. À la place, il utilise InnoDB, qui peut faire des verrouillages au niveau de la transaction. Par conséquent, les limitations pour lesquelles la fonctionnalité de base de données esclave avait été conçue comme moyen de contournement, n'existent plus. 3.1.16. Correspondance d'utilisateur Les paramètres de cette page contrôlent la façon dont les utilisateurs sont sélectionnés et recherchés lors de l'ajout d'un utilisateur à un bogue. Par exemple, les utilisateurs doivent être sélectionnés lors du choix d'un responsable de bogue, de l'ajout à la liste « Copie à » ou lors de la sélection du Contact QA. Avec le paramètre « usemenuforusers », il est possible de configurer Bugzilla pour afficher une liste des utilisateurs dans les champs plutôt qu'un champ de texte vide. Ceci ne doit être utilisé que pour des installations de Bugzilla ayant un petit nombre d'utilisateurs. Si les utilisateurs sont sélectionnés via une boîte de texte, cette page contient aussi les paramètres sur la façon dont les utilisateurs sont recherchés et le mode de correspondance lors de la saisie. Un autre paramètre appelé 'ajax_user_autocompletion' permet dans certains champs d'utilisateur d'afficher une liste déroulante de noms d'utilisateurs correspondants après avoir saisi quelques caractères. Il est recommandé d'utiliser mod_perl quand 'ajax_user_autocompletion' est activé. 3.2. Administrer les utilisateurs 3.2.1. Créer l'utilisateur par défaut À la première exécution du script checksetup.pl après l'installation de Bugzilla, il vous demandera le nom de l'utilisateur d'administration (adresse électronique) et le mot de passe pour ce « super utilisateur ». Si pour une raison ou pour une autre vous supprimez le compte « super utilisateur », la ré-exécution du script checksetup.pl vous permettra d'indiquer à nouveau ce nom d'utilisateur et son mot de passe. [Astuce] Si vous souhaitez ajouter plus d'utilisateurs d'administration, ajoutez-les au groupe « admin » et optionnellement modifiez les groupes « tweakparams », « editusers », « creategroups », « editcomponents » et « editkeywords » pour y ajouter le groupe « admin » (ce qui est le cas par défaut). 3.2.2. Gérer les autres utilisateurs 3.2.2.1. Rechercher les utilisateurs existants Si vous avez le privilège « editusers » ou si vous êtes autorisé à donner des privilèges sur certains groupes, le lien « Utilisateurs » apparaîtra dans la page administration. Le premier écran que vous obtenez est un formulaire de recherche des comptes utilisateurs existants. Vous pouvez lancer des recherches basées sur le numéro, le nom réel ou le nom de connexion (c-à-d. l'adresse électronique dans la plupart des cas, ou seulement la première partie de l'adresse si le paramètre « emailsuffix » est défini). Vous pouvez faire des recherches de différentes manières à l'aide de la liste déroulante à droite de la boîte de texte. Vous pouvez faire une recherche de correspondances de sous-chaînes insensibles à la casse (par défaut), avec une expression régulière, avec l'inverse d'une expression régulière, (qui trouve chaque nom d'utilisateur qui ne correspond PAS à l'expression régulière), ou la chaîne exacte si vous savez qui vous cherchez. La recherche peut être restreinte à des utilisateurs se trouvant dans un groupe spécifique. Par défaut, la restriction est désactivée. La recherche renvoie une liste des utilisateurs correspondant à vos critères. Les propriétés de l'utilisateur peuvent être modifiées en cliquant sur le nom de connexion. L'historique du compte d'un utilisateur peut être lu en cliquant sur le lien « Afficher » dans la colonne « Journal du compte utilisateur ». Le journal du compte affiche les changements qui ont été faits sur le compte de l'utilisateur, la date et l'heure du changement et l'utilisateur qui a effectué les modifications. Par exemple, le journal du compte affichera les détails sur la suppression ou l'ajout d'un utilisateur à un groupe. 3.2.2.2. Créer de nouveaux utilisateurs 3.2.2.2.1. Auto-enregistrement Par défaut, les utilisateurs peuvent créer leur propre compte en cliquant sur le lien « Nouveau compte » au bas de chaque page (en supposant qu'ils ne soient pas déjà connectés avec un autre compte). Si vous voulez désactiver cet enregistrement automatique ou si vous voulez limiter ceux qui peuvent créer leur compte, vous devrez modifier le paramètre « createemailregexp » dans la page « Configuration », voir Section 3.1, « Configuration de Bugzilla ». 3.2.2.2.2. Comptes créés par un administrateur Les utilisateurs ayant le privilège « editusers », tels que les administrateurs, peuvent créer des comptes pour d'autres utilisateurs : 1. Après la connexion, cliquez sur le lien « Utilisateurs » dans le pied de la page de requête, puis cliquez sur « Ajouter un nouvel utilisateur ». 2. Remplissez le formulaire présenté. Cette page est explicite. Quand c'est terminé, cliquez sur « Soumettre ». [Note] Ajouter un utilisateur de cette façon n'enverra pas un courriel l'informant de son nom d'utilisateur et de son mot de passe. Alors que c'est utile pour créer des comptes génériques (des scrutateurs qui redirigent les courriels vers un autre système par exemple ou des adresses électroniques qui sont des listes de diffusion), en général, il est préférable de se déconnecter et d'utiliser le bouton « Nouveau compte » pour créer des utilisateurs car cela pré-remplira tous les champs requis et notifiera également l'utilisateur de son nom de compte et de son mot de passe. 3.2.2.3. Modifier les utilisateurs Quand vous avez trouvé votre utilisateur, vous pouvez changer les champs suivants : * Nom de connexion : Ceci est généralement l'adresse électronique complète de l'utilisateur. Cependant, si vous utilisez le paramètre « emailsuffix », ceci peut être juste le nom de connexion de l'utilisateur. Notez que les utilisateurs peuvent à présent changer leur nom de connexion eux-mêmes (pour une adresse électronique valide). * Nom réel : Le nom réel de l'utilisateur. Notez que Bugzilla n'a pas besoin de ceci pour créer un compte. * Mot de passe : Vous pouvez changer le mot de passe de l'utilisateur ici. Les utilisateurs peuvent automatiquement demander un nouveau mot de passe ; vous ne devriez donc pas avoir besoin de faire cela souvent. Si vous voulez désactiver un compte, voir « Texte de désactivation » ci-dessous. * Courriel de bogues désactivé : Cochez cette case pour déscativer les courriels de bogues et de notification totalement pour ce compte. Cette case à cocher remplace le fichier data/nomail existant dans les versions précédentes de Bugzilla. * Texte de désactivation : Si vous saisissez quoi que ce soit dans cette boîte, y compris juste une espace, l'utilisateur ne pourra pas se connecter ou faire des modifications de bogues via l'interface Web. Le code HTML que vous saisissez dans cette boîte sera affiché à l'utilisateur quand il essaiera de faire ces actions et doit expliquer pourquoi le compte a été désactivé. Les utilisateurs ayant leur compte désactivé continueront à recevoir des courriels de Bugzilla ; de plus, ils ne pourront pas se connecter eux-mêmes pour changer leurs préférences et arrêter l'envoi de courriels. Si vous voulez qu'un compte (désactivé ou activé) arrête de recevoir les courriels, cochez la case « Courriel de bogues désactivé » ci-dessus. [Note] Même les utilisateurs ayant leur compte désactivé peuvent encore soumettre des bogues par l'intermédiaire de la passerelle de courriels, si elle existe. La passerelle de courriels ne devrait pas être activée pour les installations sécurisées de Bugzilla. [Avertissement] Ne désactivez pas tous les comptes administrateurs ! * : Si vous avez créé des groupes, par ex. « securitesensible », alors des cases à cocher apparaîtront ici pour vous permettre d'ajouter ou de supprimer des utilisateurs de ces groupes. La première case à cocher donne à l'utilisateur la possibilité d'ajouter ou de supprimer d'autres utilisateurs comme membres de ce groupe. La seconde ajoute l'utilisateur lui-même en tant que membre du groupe. * canconfirm : Ce champ est seulement utilisé si vous avez activé l'état « NON CONFIRMÉ ». Si vous activez ceci pour un utilisateur, cet utilisateur peut changer les bogues dans l'état « NON CONFIRMÉ » en « CONFIRMÉ » (par ex. : état « NOUVEAU »). * creategroups : Cette option permet à un utilisateur de créer et supprimer des groupes dans Bugzilla. * editbugs : À moins qu'un utilisateur n'ait cette option définie, il ne peut que modifier que les bogues pour lesquels il est responsable ou rapporteur. Même si cette option n'est pas cochée, les utilisateurs peuvent encore ajouter des commentaires aux bogues. * editcomponents : Cette option permet aux utilisateurs de créer de nouveaux produits et composants et de modifier ou supprimer ceux pour lesquels aucun bogue n'est associé. Si un produit ou un composant a des bogues associés, ces bogues doivent être déplacés dans un produit ou un composant différent avant que Bugzilla n'autorise leur suppression. * editkeywords : Si vous utilisez la fonctionnalité des mots-clés de Bugzilla, activer ceci permet à un utilisateur de créer et supprimer des mots-clés. Comme d'habitude, les bogues existants contenant le mot-clé que l'utilisateur veut supprimer doivent être modifiés avant que Bugzilla autorise la suppression du mot-clé. * editusers : Cette option permet à un utilisateur de faire ce que vous êtes en train de faire : modifier d'autres utilisateurs. Ceci permettra à l'utilisateur ayant cette option d'ajouter ou de retirer les privilèges administrateur à d'autres utilisateurs. À activer avec précaution. * tweakparams : Cette option permet à un utilisateur de modifier les paramètres de Bugzilla (en utilisant editparams.cgi.) * : Ceci autorise un administrateur à indiquer les produits pour lesquels un utilisateur peut voir les bogues. Si vous activez le paramètre « makeproductgroups » dans le panneau « Restrictions de groupe » dans la page « Paramètres », Bugzilla crée alors un groupe par produit (au moment de la création du produit), et ce groupe a exactement le même nom que le produit. Veuillez noter que pour les produits existants, lorsque le paramètre est activé, les groupes correspondants ne seront pas créés. L'utilisateur doit encore avoir le privilège « editbugs » pour modifier les bogues dans ces produits. 3.2.2.4. Supprimer des utilisateurs Si le paramètre « allowuserdeletion » est activé, voir Section 3.1, « Configuration de Bugzilla », vous pouvez alors aussi supprimer des comptes utilisateurs. Notez que ce n'est la plupart du temps pas la meilleure chose à faire. Si seul un avertissement dans une boîte jaune est affiché, alors la suppression est sûre. Si un avertissement est également affiché dans une boîte rouge, alors vous ne devriez PAS essayer de supprimer le compte utilisateur, sinon vous rencontrerez des problèmes d'intégrité référentielle dans votre base de données, qui peuvent mener à un comportement inattendu, tels que des bogues n'apparaissant plus dans les listes de bogues ou des données ou des données incorrectement affichées. Vous avez été prévenu ! 3.2.2.5. Se substituer à des utilisateurs Il y a des fois où un administrateur veut accomplir des actions en tant qu'un autre utilisateur. La fonctionnalité sudo peut être utilisée pour faire cela. [Note] Pour utiliser la fonctionnalité « sudo », vous devez être dans le groupe bz_sudoers. Par défaut, tous les administrateurs sont dans ce groupe. Si vous voulez utiliser cette fonctionnalité, vous devez démarrer une session en allant sur la page de modification des utilisateurs, rechercher un utilisateur et cliquer sur son nom de connexion. Vous devriez voir un lien sous son nom de connexion intitulé « Prendre la place de cet utilisateur ». Cliquez sur le lien. Ceci vous amènera sur une page décrivant la fonctionnalité et les instructions pour l'utiliser. Après avoir lu le texte, saisissez le nom de connexion de l'utilisateur dont vous voulez usurper l'identité, fournissez un court message expliquant pourquoi vous faites cela, et appuyez sur le bouton. Tant que vous utiliserez cette fonctionnalité, tout ce que vous ferez sera vu comme si vous étiez connecté avec le compte utilisateur dont vous usurpez l'identité. [Avertissement] L'utilisateur dont vous usurpez l'identité ne recevra pas de compte-rendu de ce que vous faites. Si vous effectuez des actions qui engendrent l'envoi de courriels, ces courriels apparaîtront comme envoyés par l'utilisateur dont vous usurpez l'identité. Vous devez être extrêmement prudent lorsque vous utilisez cette fonctionnalité. 3.3. Catégories Les catégories sont utilisées pour regrouper plusieurs produits en une entité distincte. Le niveau « Catégories » est désactivé par défaut ; il peut être activé ou désactivé en utilisant le paramètre « useclassification », dans la section Champs de bogue dans la page de modification des paramètres. L'accès à l'administration des catégories est contrôlé par l'utilisation du groupe groupe système editclassifications, qui définit les privilèges de création, suppression et modification des catégories. Lorsqu'elles sont activées, les catégories introduisent une étape supplémentaire lors de la création des bogues (se manifestant par la sélection d'une catégorie) ; elles apparaissent aussi dans le formulaire de recherche avancée. 3.4. Produits Les Produits représentent typiquement les produits que vous délivrez réellement. Les produits peuvent être classés en Catégories. Par exemple, si une société conçoit des jeux pour ordinateur, elle pourrait avoir une catégorie « Jeux » et un produit différent pour chaque jeu. Cette société pourrait également avoir un produit « Commun » pour les unités technologiques utilisées dans plusieurs jeux, et peut-être aussi quelques produit spéciaux qui représentent des éléments ne faisant pas partie des produits (par exemple, « Site Web » ou « Administration »). Beaucoup de paramètres de Bugzilla sont configurables par produit. Le nombre de « votes » disponibles pour les utilisateurs est défini par produit, tout comme le nombre de votes requis pour faire passer automatiquement un bogue de l'état NON CONFIRMÉ à l'état CONFIRMÉ. Lors de la création ou de la modification des produits, les options suivantes sont disponibles : Produit Le nom du produit Description Une brève description du produit Jalon par défaut Sélectionner le jalon par défaut pour ce produit. Fermé pour la saisie de bogues Sélectionner cette case à cocher pour empêcher la saisie de nouveaux bogues pour ce produit. Votes maximum par personne Le nombre maximum de votes autorisé pour un utilisateur pour ce produit. Votes maximum qu'une personne peut affecter à un bogue Le nombre de votes maximum autorisé pour un utilisateur dans ce produit pour un seul bogue. Seuil de confirmation Le nombre de votes nécessaire pour passer automatiquement tout bogue dans ce produit de l'état NON CONFIRMÉ à NOUVEAU. Version Indique quelle version sera affichée pour les bogues de ce produit. Créer des graphiques pour ce produit Cocher cette case pour permettre la création de graphiques pour ce produit. Lors de la modification d'un produit, il y a également un lien pour modifier les restrictions de groupes, voir Section 3.4.4, « Affecter des restrictions de groupes à des produits ». 3.4.1. Créer de nouveaux produits Pour créer un nouveau produit : 1. Sélectionnez « Produits » dans le pied de page 2. Sélectionnez le lien « Ajouter » au bas de la page à droite 3. Saisissez le nom du produit et sa description. Le champ « Description » peut contenir du code HTML. 4. Quand le produit est créé, Bugzilla affiche un message indiquant qu'un composant doit être créé avant de pouvoir rapporter des bogues pour ce nouveau produit. Suivre le lien pour créer un nouveau composant. Voir Composants pour plus de détails. 3.4.2. Modifier des produits Pour modifier un produit existant, cliquez sur le lien « Produits » dans la page « Administration ». si le paramètre « useclassification » est activé, un tableau des catégories existantes est affiché, y compris la catégorie « Unclassified ». Le tableau indique le nombre de produits dans chaque catégorie. Cliquez sur le nom de la catégorie pour voir ses produits. Si le paramètre « useclassification » n'est pas activé, le tableau liste tous les produits directement. Le tableau du produit résume les informations sur celui-ci fournie lors de sa création. Cliquez sur le nom du produit pour modifier ses propriétés et accéder aux liens vers les autres attributs tels que les composants, les versions, les jalons et les restrictions de groupe. 3.4.3. Ajouter ou modifier les composants, versions et jalons cibles Pour modifier ou ajouter de nouveaux composants, versions ou jalons cibles à un produit, cliquez sur les liens « Modifier les composants », « Modifier les versions » ou « Modifier les jalons » dans la page « Modifier le produit ». Un tableau des composants, versions et jalons existants est affiché. Cliquez sur un nom d'élément pour modifier ses propriétés. Sous le tableau se trouvent un lien pour ajouter un nouveau composant, version ou jalon. Pour plus d'informations sur les composants, consultez Composants. Pour plus d'informations sur les versions, consultez Section 3.6, « Versions ». Pour plus d'informations sur les jalons, consultez Section 3.7, « Jalons ». 3.4.4. Affecter des restrictions de groupes à des produits Sur la page « Modifier le produit », il y a un lien appelé « Modifier les restrictions de groupes ». Les paramètres de cette page contrôlent les relations des groupes au produit édité. Les restrictions de groupe sont un aspect important de l'utilisation des groupes pour isoler et restreindre les accès aux bogues saisis pour ces produits. Pour plus d'informations sur les groupes, y compris la création, la modification, l'ajout d'utilisateurs et la modifications des permissions, consultez Section 3.15, « Groupes et restrictions de groupes ». Après avoir cliqué sur le lien « Modifier les restrictions de groupes » dans la page « Modifier le produit », un tableau contenant tous les groupes d'utilisateurs de cette installation de Bugzilla est affiché. Les groupes système qui sont créés lors de l'installation de Bugzilla is installed ne sont pas utilisables pour les restrictions de groupes. Une description de la signification de chacun de ces champs est indiquée ci-dessous. Les groupes peuvent être « applicable », « défaut », et « obligatoire ». Les groupes peuvent aussi contrôler les droits de saisie pour un produit donné ou être utilisés pour que les bogues dans le produit soient en lecture seule à moins que les restrictions de groupes ne soient remplies. La meilleure façon de comprendre ces relations est de voir des exemples. Concultez Section 3.4.4.1, « Applications courantes des restrictions de groupe » pour des exemples de relations entre produit et groupe. [Note] Les produits et les groupes ne sont pas limités à une relation un pour un. Plusieurs groupes peuvent être associés au même produit et les groupes peuvent être associés à plus d'un produit. Si un groupe a Entry sélectionné, alors le produit restreindra la saisie de bogues aux seuls utilisateurs membres de groupes ayant entry sélectionné. Si un groupe a canedit sélectionné, alors le produit sera en lecture seule pour tous les utilisateurs qui ne sont pas membres de tous les groupes ayant canedit sélectionné. Seuls les utilisateurs qui sont membres de tous les groupes ayant canedit sélectionné seront capables de modifier. C'est une restriction additionnelle qui limite encore plus ce qui peut être modifié par un utilisateur. Les paramètres suivants vous permettent de choisir les privilèges par produit. C'est un moyen pratique pour donner des privilèges à certains utilisateurs pour certains produits seulement, sans avoir à leur donner de privilèges globaux qui affecteraient tous les produits. Les groupes ayant editcomponents sélectionné permettent aux utilisateurs membres de ces groupes de modifier tous les aspects de ce produit, y compris les composants, les jalons et les versions. Les groupes ayant canconfirm sélectionné permettent aux utilisateurs membres de ces groupes de confirmer les bogues dans ce produit. Les groupes ayant editbugs sélectionné permettent aux utilisateurs membres de ces groupes de modifier tous les champs de bogue dans ce produit. Les champs MemberControl et OtherControl sont utilisés en tandem pour déterminer quels bogues seront placés dans ce groupe. Les seules combinaisons autorisées de ces deux paramètres sont listées dans un tableau dans la page « Modifier les restrictions de de groupe ». Consultez ce tableau pour des détails sur la façon d'utiliser ces champs. Des exemples de différentes utilisations sont décrits ci-dessous. 3.4.4.1. Applications courantes des restrictions de groupe L'utilisation des groupes est mieux expliquée avec des exemples illustrant des configurations utilisées couramment. Les exemples suivent une syntaxe commune : Group: Entry, MemberControl, OtherControl, CanEdit, EditComponents, CanConfirm, EditBugs. Où « Group » est le nom du groupe modifié pour ce produit. Les autres champs correspondent tous au tableau dans la page « Modifier les restrictions de groupes ». Si une de ces options n'est pas listée, cela signifie qu'elle n'a pas été cochée. Restriction produit/groupe basique Supposons qu'il y ait un produit appelé « Toto ». Le produit « Toto » ne peut contenir que des bogues saisis par les utilisateurs du groupe « Titi ». De plus, les bogues saisis pour le produit « Toto » doivent être toujours restreints aux utilisateurs du groupe « Titi ». De plus, seuls les membres du groupe « Titi » peuvent modifier les bogues saisis pour le produit « Toto », même si d'autres utilisateurs peuvent voir le bogue. Ces conditions seraient réalisées ainsi : Produit Toto: Titi: ENTRY, OBLIGATOIRE/OBLIGATOIRE, CANEDIT Peut-être que des restrictions si strictes ne sont pas nécessaires pour le produit « Toto ». Un façon moins stricte de configurer le produit « Toto » et le groupe « Titi » serait : Produit Toto: titi: ENTRY, AFFICHÉ/AFFICHÉ, EDITCOMPONENTS, CANCONFIRM, EDITBUGS Les lignes ci-dessus indiquent que, pour le produit « Toto », les membres du groupe « Titi » peuvent saisir des bogues. Toute personne ayant la permission de modifier un bogue du produit « Toto » peut mettre le bogue dans le groupe « Titi », même s'ils n'appartiennent pas eux-mêmes au groupe « Titi ». Tout utilisateur du groupe « Titi » peut modifier tous les aspects des composants du produit « Toto », peut confirmer les bogues pour le produit « Toto » et peut modifier tous les champs de tous les bogues du produit « Toto ». Accès utilisateur général avec groupe de sécurité Pour permettre à tout utilisateur de saisir un bogue pour le produit « A » et de soumettre ces bogues au groupe appelé « Security » : Produit A: Security: AFFICHÉ/AFFICHÉ Accès utilisateur général et produit Sécurité Pour permettre à tout utilisateur de saisir des bogues pour le produit « Sécurité » tout en empêchant ces bogues d'être visibles à quiconque en dehors du groupe « SecurityWorkers » (à moins qu'un membre de ce groupe n'enlève cette restriction) : Produit Sécurité: securityworkers: DÉFAUT/OBLIGATOIRE Isolation de produit avec un groupe commun Pour permettre aux utilisateurs du produit « A » d'accéder aux bogues du produit « A », aux utilisateurs du produit « B » d'accéder aux bogues du produit « B » et au personnel du support, membres du groupe « Support », d'accéder aux deux produits, trois groupes sont nécessaires : 1. Le groupe « Support » : contient les membres du personnel du support. 2. Le groupe « AccessA » : contient les utilisateurs du produit « A » et du groupe « Support ». 3. Le groupe « AccessB » : contient les utilisateurs du produit « B » et du groupe « Support ». Quand ces trois groupes ont été définis, les restrictions de groupes peuvent être définies ainsi : Produit A: AccessA: ENTRY, OBLIGATOIRE/OBLIGATOIRE Produit B: AccessB: ENTRY, OBLIGATOIRE/OBLIGATOIRE Peut-être que le groupe « Support » veut plus de droits. Par exemple, le groupe « Support » pourrait être autorisé à rendre les bogues inaccessible aux utilisateurs des groupes « AccessA » et « AccessB ». Alors, le groupe « Support » pourrait être autorisé à publier les bogues appropriés à tous les utilisateurs dans un troisième produit (appelons-le « Commun ») qui est en lecture seule pour quiconque n'appartient pas au groupe « Support ». De cette façon, le groupe « Support » pourrait contrôler les bogues qui peuvent être vus par les deux groupes à la fois. Cette configuration serait : Produit A: AccessA: ENTRY, OBLIGATOIRE/OBLIGATOIRE Support: AFFICHÉ/NON APPLICABLE Produit B: AccessB: ENTRY, OBLIGATOIRE/OBLIGATOIRE Support: AFFICHÉ/NON APPLICABLE Produit Commun: Support: ENTRY, DÉFAUT/OBLIGATOIRE, CANEDIT Mettre un produit en lecture seule Quelquefois, un produit est retiré et par conséquent, on ne devrait pas pouvoir saisir de bogues pour celui-ci (par exemple, une ancienne version d'un logiciel qui n'est plus supportée). Un produit peut être mis en lecture seule en créant un groupe appelé « LectureSeule » et en ajoutant les produits dedans quand c'est nécessaire : Produit A: LectureSeule: ENTRY, NON APPLICABLE/NON APPLICABLE, CANEDIT [Note] Pour plus d'informations sur les groupes (en dehors de leurs relations avec les produits), consultez Section 3.15, « Groupes et restrictions de groupes ». 3.5. Composants Les composants sont des sous-sections d'un produit. Par exemple, le jeu vidéo que vous concevez peut avoir les composants « UI », « API », « Système audio » et « Plugins », chacun d'eux étant supervisé par un programmeur différent. Il est souvent souhaitable de diviser les composants dans Bugzilla en fonction des divisions naturelles des responsabilités au sein de votre produit ou de votre société. Chaque composant à un responsable par défaut et, si vous l'activez dans la page des paramètres, un contact QA par défaut. Le responsable par défaut doit être la première personne qui corrige les bogues dans ce composant. Le contact QA doit être la personne qui s'assure que les bogues sont totalement corrigés. Le responsable, le contact QA et le rapporteur recevront un courriel quand de nouveaux bogues sont créés dans ce composant et quand il y a des changements sur les bogues. Les champs « Responsable par défaut » et « Contact QA par défaut » ne concernent que les assignations par défaut ; ils peuvent être changés lors de la soumission du bogue ou plus tard dans le cycle de vie du bogue. Pour créer un nouveau composant : 1. Cliquez sur le lien « Modifier les composants » dans la page « Modifier le produit » 2. Cliquez sur le lien « Ajouter » au bas de la page à droite. 3. Remplissez le champ « Composant », saisissez une courte « Description », le « Responsable par défaut », la « En copie par défaut » et le « Contact QA par défaut » (si activé). Le champ « Description du composant » peut contenir un nombre limité de balises HTML. Les champs « Composant » et « Description » peuvent contenir du code HTML ; le champ « Responsable par défaut » doit être un nom de connexion déjà existant dans la base de données de Bugzilla. 3.6. Versions Les versions sont les révisions du produit, comme par exemple, « Flinders 3.1 », « Flinders 95 » et « Flinders 2000 ». Le champ « Version » n'est pas un champ à sélections multiples ; la pratique habituelle est de sélectionner la version la plus ancienne connue ayant le bogue. Pour créer et modifier les versions : 1. Dans la page « Modifier le produit », sélectionnez « Modifier les versions » 2. Vous remarquerez que le produit a déjà la version par défaut « undefined ». Cliquez sur le lien « Ajouter » au bas de la page à droite. 3. Saisissez le nom de la version. Ce champ ne prend que du texte. Puis, cliquez sur le bouton « Ajouter ». 3.7. Jalons Les jalons sont des objectifs pour lesquels vous projetez de corriger un bogue. Par exemple, vous avez un bogue que vous prévoyez de corriger pour la version 3.0, on doit donc lui assigner le jalon 3.0. [Note] Les options de jalons n'apparaissent pour un produit que si vous avez activé le paramètre « usetargetmilestone » dans l'onglet « Champs des bogues » dans la page « Paramètres ». Pour créer de nouveaux jalons et définir des jalons par défaut : 1. Sélectionnez « Modifier les jalons » dans la page « Modifier le produit ». 2. Sélectionnez « Ajouter » dans le coin inférieur droit. 3. Saisissez le nom du jalon dans le champ « Jalon ». Vous pouvez optionnellement définir la « Position », qui est un nombre positif ou négatif (-32768 to 32767) qui définit où dans la liste apparaît ce jalon. Ceci est utile car les jalons ne suivent pas l'ordre alphanumérique. Par exemple, « Futur » devrait se trouver après « Version 1.2 ». Cliquez sur « Ajouter ». 3.8. Étiquettes Les étiquettes sont un moyen d'attacher un état spécifique à un bogue ou un fichier joint, soit « + » soit « - ». La signification de ces symboles dépend du texte de l'étiquette elle-même, mais selon le contexte, ils pourraient signifier « passé/échoué », « accepté/rejeté », « approuvé/refusé » ou un simple « oui/non ». Si votre site accepte les demandes d'étiquettes, alors un utilisateur peut définir une étiquette à « ? » pour demander à un autre utilisateur de regarder son bogue/fichier joint et de définir l'étiquette pour son état correct. 3.8.1. Un simple exemple Un développeur pourrait vouloir demander à son responsable, « Devons-nous corriger ce bogue pour la version 2.0 ? ». Ils pourraient vouloir faire cela pour beaucoup de bogues, donc il serait bien de faciliter le processus… Dans Bugzilla, cela fonctionnerait de cette façon : 1. L'administrateur de Bugzilla crée un étiquette intitulée « bloquant2.0 » qui s'affiche dans tous les bogues de votre produit. Elle s'affiche dans la page « Afficher le bogue » sous le texte « bloquant2.0 » avec une liste déroulante à côté. La liste déroulante contient quatre valeurs : une espace, « ? », « - » et « + ». 2. Le développeur définit l'étiquette à « ? ». 3. Le responsable voit l'étiquette bloquant2.0 avec la valeur « ? ». 4. Si le responsable pense que la fonctionnalité doit être intégrée avant la publication de la version 2.0, il définit l'étiquette à « + ». Sinon, à « - ». 5. Maintenant, tout utilisateur de Bugzilla qui consulte le bogue sait si le bogue doit être corrigé avant la version 2.0. 3.8.2. À propos des étiquettes 3.8.2.1. Valeurs Les étiquettes peuvent avoir trois valeurs : ? Un utilisateur demande qu'un état soit défini. (Pensez à cela comme « Une question est posée »). - L'état a été défini négativement. (La réponse est « non »). + L'état a été défini positivement. (La réponse est « oui »). Il existe en fait une quatrième valeur que peut avoir une étiquette -- « non défini » -- qui s'affiche comme une espace. Cela signifie juste que personne n'a expressément émis d'opinion (ou demandé à quelqu'un d'autre son opinion) sur le bogue ou le fichier joint. 3.8.3. Utiliser les demandes d'étiquettes Si une étiquette a été définie comme « demandé » et qu'un utilisateur a suffisamment de privilèges pour la demander (voir ci-dessous), il peut définir l'état de l'étiquette à « ? ». Cet état indique que quelqu'un (« le demandeur ») demande à quelqu'un d'autre de définir l'étiquette à « + » ou « - ». Si l'étiquette a été définie comme « sollicité », une boîte de texte apparaîtra à coté de l'étiquette dans laquelle le demandeur peut saisir un nom d'utilisateur de Bugzilla. Cette personne recevra un courriel l'informant de la requête et pointant sur le bogue/fichier joint en question. Si une étiquette n'a pas été définie comme « sollicité », alors aucune boîte de texte n'apparaîtra. Une requête pour définir cette étiquette ne peut pas être adressée à un utilisateur en particulier, mais doit être demandée « en l'air ». Le demandeur peut faire une requête « en l'air » sur toute étiquette en laissant simplement la boîte de texte vide. 3.8.4. Deux types d'étiquettes Les étiquettes peuvent être posées à deux endroits : sur un fichier joint ou sur un bogue. 3.8.4.1. Étiquettes de fichiers joints Les étiquettes de fichiers joints sont utilisées pour poser une question sur un fichier joint spécifique d'un bogue. Beaucoup d'installation de Bugzilla utilise ceci pour demander à un développeur la « revue » du code d'un autre développeur avant de le déposer dans le référentiel. Ils joingnent le code à un rapport de bogues et définissent une étiquette sur le fichier joint intitulée « revue » à revue?chef@domaine.com. « chef@domaine.com » est alors notifié par courriel qu'il doit vérifier le fichier joint et l'approuver ou le refuser. Pour un utilisateur de Bugzilla, les étiquettes de fichiers joints apparaissent dans trois endroits : 1. Sur la liste des fichiers joints dans la page « Afficher le bogue », vous pouvez voir l'état actuel de toutes les étiquettes qui ont été définies à « ? », « + » ou « - ». Vous pouvez voir qui a demandé l'étiquette et à qui elle a été demandée). 2. Quand vous modifiez un fichier joint, vous pouvez voir toutes les étiquettes qui peuvent être définies ainsi que celles qui ont déjà été définies. L'écran « Modifier le fichier joint » est l'endroit où vous définissez les valeurs « ? », « - », « + » et où vous pouvez les enlever. 3. Les requêtes sont listées dans la « File d'attente des requêtes », qui est accessible à partir du lien « Mes requêtes » (si vous êtes connecté) ou du lien « Requêtes » (si vous êtes déconnecté) visible dans le pied de page de toutes les pages. 3.8.4.2. Étiquettes de bogues Les étiquettes de bogues sont utilisées pour définir un état sur le bogue lui-même. Vous pouvez les voir dans les écrans « Afficher le bogue » et « Requêtes » comme décrit plus haut. Seuls les utilisateurs ayant suffisamment de privilèges (voir ci-dessous) peuvent définir des étiquettes sur les bogues. Ceci n'inclut pas nécessairement le responsable, le rapporteur ou les utilisateurs ayant le privilège editbugs. 3.8.5. Gérer les étiquettes Si vous avez le privilège « editcomponents », vous pouvez modifier les « Types d'étiquettes » dans la page principale d'administration. Cliquer sur le lien « Étiquettes » vous amènera sur la page « Gérer les types d'étiquettes ». Vous pouvez sélectionner ici si vous voulez créer (ou modifier) une étiquette de bogue ou de fichier joint. Peu importe ce que vous choisissez, l'interface est la même, donc nous ne l'aborderons qu'une fois. 3.8.5.1. Modifier une étiquette Pour modifier les propriétés d'une étiquette, cliquez sur le nom de l'étiquette. Cela vous mènera au même formulaire comme décrit ci-dessous (Section 3.8.5.2, « Créer une étiquette »). 3.8.5.2. Créer une étiquette Quand vous cliquez sur le lien « Créer un type d'étiquette pour … », un formulaire est affiché. Voici ce que signifie les champs dans ce formulaire : 3.8.5.2.1. Nom C'est le nom de l'étiquette. Il sera affiché aux utilisateurs de Bugzilla qui consulteront ou définiront les étiquettes. Le nom peut contenir tout caractère Unicode valide sauf les virgules et les espaces. 3.8.5.2.2. Description Explique de façon détaillée l'étiquette. Elle est visible dans une info-bulle quand le curseur de la souris passe au-dessus du nom de l'étiquette dans les pages « Afficher le bogue » et « Modifier le fichier joint ». Ce champ peut être aussi long que vous le voulez et contenir tous les caractères que vous voulez. 3.8.5.2.3. Categorie LE comportement par défaut pour une nouvelle étiquette est d'apparaître sur tous les produits et composants, c'est pourquoi « __Tous__:__Tous__ » est déjà saisi dans la boîte « Inclusions ». Si ce n'est pas ce que vous voulez, vous pouvez soit définir des exclusions (pour les produits pour lesquels vous ne voulez pas voir apparaître l'étiquette), soit supprimer « __Tous__:__Tous__ » de la boîte « Inclusions » et définir spécifiquement les produits/composants pour cette étiquette. Pour créer une inclusion, sélectionnez un produit dans la liste déroulante. Vous pouvez également sélectionner un composant spécifique dans la liste déroulante. (Définir « __Tous__ » pour « Produit » se traduit par « tous les produits dans cette installation de Bugzilla ». Sélectionner « __Tous__ » dans le champ « Composant » signifie « tous les composants du produit sélectionné. ») quand les sélections sont faites, cliquez sur « Inclure » et les paires Produit/Composant apparaîtront dans la boîte « Inclusions » à droite. Pour créer une exclusion, le processus est le même ; sélectionnez un produit dans la liste déroulante, sélectionnez un composant spécifique si vous en voulez un, et cliquez sur « Exclure ». Les paires produit/composant apparaîtront dans la boîte « Exclusions » à droite. Cette étiquette sera et pourra être définie pour tous les produits/composants apparaissant dans la boîte « Inclusions » (ou qui tombent dans la règle « __Tous__ » appropriée). Cette étiquette n'apparaîtra pas (et par conséquent ne pourra être définie) pour tout produit apparaissant dans la boîte « Exclusions ». IMPORTANT : Les exclusions surpassent les inclusions. Vous pouvez sélectionner un produit sans sélectionner de composant spécifique, mais vous ne pouvez pas sélectionner de composant sans produit ou sélectionner de composant qui n'appartienne à aucun produit. Si vous faites cela, Bugzilla affichera un message d'erreur, même si tous vos dproduits ont un composant ayant ce nom. Exemple Imaginons que vous ayez un produit intitulé « Avion » qui a des milliers de composants. Vous voulez avoir la possibilité de demander si un problème doit être corrigé pour le prochain modèle d'avion que vous fabriquez. Nous appellerons l'étiquette « corrigerProchainModèle ». Mais il y a un composant dans « Avion » intitulé « Pilote ». Cela n'a pas de sens de fabriquer un nouveau pilote, et donc vous ne voulez pas avoir cette étiquette dans ce composant. Donc vous incluez « Avion:__Tous__ » et vous excluez « Avion:Pilote ». 3.8.5.2.4. Position Les étiquettes s'affichent normalement en ordre alphabétique. Si vous voulez les afficher dans un ordre différent, vous pouvez utiliser ceci pour définir la position de chaque étiquette. Les étiquettes ayant une valeur de position faible apparaîtront avant les étiquettes ayant une valeur de position élevée. Les étiquettes ayant la même valeur de position seront classées alphabétiquement, mais seront encore placées après les étiquettes ayant une plus faible valeur de la position et avant celles ayant une valeur de poistion plus élevée. Exemple : J'ai les étiquettes « A » (Position 100), « B » (Position 10), « C » (Position 10) et « D » (Position 1). L'ordre d'affichage sera : D, B, C, A. 3.8.5.2.5. Active Parfois, vous pourriez vouloir conserver les informations sur les anciennes étiquettes dans la base de données de Bugzilla, mais empêcher les utilisateurs de continuer à les utiliser. Pour faire cela, décochez « active ». Les étiquettes désactivées continueront à apparaître dans l'interface utilisateur si elles ont les valeurs « ? », « + » ou « - » mais elles ne peuvent être qu'effacées (non définies) et ne peuvent pas prendre de nouvelle valeur. Quand une étiquette désactivée est affacée (non définie), elle disparaîtra complètement d'un bogue/fichier joint et ne pourra pas être redéfinie. 3.8.5.2.6. Demandé Les nouvelles étiquettes sont par défaut de type « demandé », ce qui veut dire qu'elles permettent aux utilisateurs de définir les options « ? », « + » et « - ». Pour supprimer l'option « ? », décochez « demandé ». 3.8.5.2.7. Sollicité Par défaut cette boîte est cochée pour les nouvelles étiquettes, ce qui veut dire que les utilisateurs peuvent faire des demandes d'étiquettes à des personnes en particulier. Décocher cette case enlèvera la boîte de texte à côté de l'étiquette ; si elle est toujours de type « demandé », alors les requêtes pourront seulement être faites « en l'air ». Enlever ceci après que des requêtes de type « sollicité » aient été faites ne supprimera pas ces requêtes ; ces informations resteront dans la base de données (bien qu'elles ne s'afficheront plus pour l'utilisateur). 3.8.5.2.8. Multiple Une étiquette de type « Multiple » (activé par défaut pour les nouvelles étiquettes) peut être définie plus d'une fois. Après avoir été définie une fois, une étiquette du même type apparaîtra au-dessous avec le mot « suppl. » (abrégé pour « supplémentaire ») devant son libellé. Il n'y a pas de limite au nombre de fois qu'une étiquette de type « multiple » puisse être définie sur le même bogue/fichier joint. 3.8.5.2.9. Liste « Copie à » Si vous voulez que certains utilisateurs soient notifiés chaque fois que cette étiquette change de valeur (« ? », « - », « + » ou vide), ajoutez-les ici. C'est une liste d'adresses électroniques séparées par des virgules qui ne sont pas nécessairement des comptes utilisateurs de Bugzilla. 3.8.5.2.10. Groupe des permissions Quand ce champ est défini avec un groupe donné, seuls les utilisateurs de ce groupe peuvent définir la valeur de l'étiquette à « + » et « - ». Ce champ n'affecte pas ceux qui peuvent demander ou effacer l'étiquette. Pour cela, voir le champ « Groupe des requêtes » ci-dessous. Si ce champ est laissé vide, tous les utilisateurs peuvent définir ou effacer cette étiquette. Ce champ est utile pour limiter les utilisateurs qui peuvent approuver ou rejeter les requêtes. 3.8.5.2.11. Groupe des requêtes Quand ce champ est défini sur un groupe donné, seuls les utilisateurs de ce groupe peuvent demander ou effacer cette étiquette. Notez que ce champ n'a aucun effet si le champ « Groupe des permissions » est vide. Vous pouvez définir la valeur de ce champ la valeur de ce champ pour un groupe différent, mais les deux champs doivent être renseignés avec un groupe pour que ce champ ait un effet. 3.8.5.3. Supprimer une étiquette Quand vous êtes sur l'écran « Gérer les types d'étiquettes », une liste des étiquettes de bogues et de fichiers joints est affichée. Pour supprimer une étiquette, cliquez sur le lien « Supprimer » à côté de la description de l'étiquette. [Avertissement] Une fois supprimée, l'étiquette n'existe plus dans Bugzilla. Toutes les données concernant cette étiquette seront supprimées. Partout où cette étiquette était définie, elle disparaîtra, et vous ne pourrez pas revenir en arrière. Si vous voulez conserver les données concernant l'étiquette, mais que personne ne continue à l'utiliser, décochez « active » dans le formulaire de modification des étiquettes. 3.9. Keywords L'administrateur peut définir des mots-clés qui peuvent être utilisés pour étiqueter et catégoriser les bogues. Par exemple, le mot-clé « régression » est utilisé couramment. Une société pourrait avoir comme politique de corriger toutes les régressions dans la version suivante ; ce mot-clé peut permettre alors de tracer ces bogues plus facilement. Les mots-clés sont globaux, plutôt que limités à un produit. Si un administrateur change un mot-clé actuellement appliqué à des bogues, le cache des mots-clés peut être reconstruit en utilisant le script Section 3.16, « Vérifier et maintenir l'intégrité de la base de données ». Actuellement, les mots-clés ne peuvent pas être marqués comme obsolètes pour empêcher une utilisation ultérieure. Les mots-clés peuvent être créés, modifiés ou supprimés en cliquant sur le lien « Mots-clés » dans la page d'administration. Il y a deux champs pour chaque mot-clé : le mot-clé lui-même et une brève description. Une fois créé, les mots-clés peuvent être sélectionnés et appliqués à chaque bogue individuellement dans la section « Détails » de chaque bogue. 3.10. Champs personnalisés Bugzilla 3.0 a introduit la possibilité de créer des champs personnalisés. Les champs personnalisés sont traités comme tout autre champ : ils peuvent être définis dans les bogues et utilisés dans les requêtes. Les administrateurs doivent garder à l'esprit qu'ajouter trop de champs peut rendre l'interface utilisateur plus compliquée et plus difficile à utiliser. Les champs personnalisés ne devraient être ajoutés que lorsqu'ils sont absolument nécessaires et en y portant une attention particulière. [Astuce] Avant d'ajouter un champ personnalisé, assurez-vous que Bugzilla ne peut pas déjà réaliser le comportement escompté. Beacoup d'options de Bugzilla ne sont pas activées par défaut, et souvent, les administrateurs trouvent qu'activer simplement certaines options existantes suffit. Les administrateurs peuvent gérer les champs personnalisés en utilisant le lien « Champs personnalisés » dans la page d'administration. La page d'administration des champs personnalisés affiche une liste de champs personnalisés, s'il y en a, et un lien « Ajouter un nouveau champ personnalisé ». 3.10.1. Ajouter des champs personnalisés Pour ajouter un nouveau champ personnalisé, cliquez sue le lien « Ajouter un nouveau champ personnalisé ». Cette page affiche plusieurs options pour le nouveau champ, comme indiqué ci-dessous. Les attributs suivants doivent être définis pour chaque nouveau champ personnalisé : * Nom : Le nom du champ utilisé dans la base de données, utilisée en interne. Ce nom DOIT commencer par « cf_ » pour éviter toute confusion avec les champs standards. Si vous omettez cette chaîne, elle sera automatiquement ajoutée au nom que vous avez saisi. * Description : Une chaîne courte qui est utilisée comme libellé pour ce champ personnalisé. C'est la chaîne que les utilisateurs verront ; elle doit donc être courte et explicite. * Type : Le type du champ à créer. Il existe différents types disponibles : ID de bogue Un champ où l'on peut saisir l'ID d'un autre bogue de la même installation Bugzilla. Pour indiquer le bogue d'une autre installation de Bugzilla, utiliser le champ « Consulter aussi ». Grande boîte de texte : Une boîte de plusieurs lignes pour saisir du texte. Texte libre : Une boîte d'une seule ligne pour saisir du texte. Boîte à sélection multiple : Une boîte de liste où plusieurs options peuvent être sélectionnées. Après la création de ce champ, vous devez le modifier pour y ajouter les options de sélection. Voir Section 3.11.1, « Voir/Modifier les valeurs autorisées » pour des informations sur la modification des valeurs autorisées. Liste déroulante : Une boîte de liste où une seule option peut-être sélectionnée. Après la création de champ, vous devez le modifier pour y ajouter les options de sélection. Voir Section 3.11.1, « Voir/Modifier les valeurs autorisées » pour des informations sur la modification des valeurs autorisées. Date/Heure : Un champ de date. Ce champ apparaît avec un widget de calendrier pour choisir une date. * Position : Un nombre entier qui détermine l'ordre dans lequel seront affichés les champs personnalisés dans l'interface utilisateur, notamment lors de la consultation d'un rapport de bogue. Les champs ayant les valeurs les plus faibles seront affichés en premier. * Description de relation réciproque : Quand le champ personnalisé est de type « ID de bogue », vous pouvez saisir du texte ici qui sera utilisé comme libellé dans le bogue référencé pour lister les bogues qui pointent vers celui-ci. Ceci permet d'avoir des relations réciproques entre deux bogues. * Peut être défini à la création du bogue : Un booléen qui détermine si ce champ peut être défini lors de la création du bogue. Si ce n'est pas le cas, vous devrez d'abord créer le bogue pour pouvoir définir ce champ. Sinon, vous pourrez définir sa valeur lors de la création du bogue, voir Section 5.6, « Rapporter des bogues » à propos de la saisie de bogues. * Affiché dans les courriels de bogue pour les nouveaux bogues : Un booléen qui détermine si la valeur définie dans ce champ doit apparaître dans les courriels de bogues quand un bogue est créé. Cet attribut n'aucun effet si le champ ne peut pas être défini lors de la création du bogue. * Est obsolète : Un booléen qui détermine si le champ doit être affiché. Les champs personnalisés obsolètes sont cachés. * Est obligatoire : Booléen déterminant si ce champ doit être défini. Pour les champs simples et multiples, ceci signifie qu'une valeur (qui n'est pas par défaut) doit être sélectionnée, et pour les champs date et texte, du texte doit être saisi. * Le champ apparaît seulement quand : Un champ personnalisé peut être rendu visible quand certains critères sont remplis. Par exemple, quand le bogue appartient à un produit donné ou quand le bogue à une certaine gravité. Si ce champ est laissé vide, alors le champ personnalisé sera toujours visible, dans tous les bogues. * Champ contrôlant les valeurs qui apparaissent dans ce champ : Quand le champ personnalisé est de type « Liste » ou « Boîte de sélection multiple », vous pouvez restreindre la disponibilité des valeurs du champ personnalisé en fonction de la valeur d'un autre champ. Ce critère est indépendant du critère utilisé dans le paramètre « Le champ apparaît seulement quand : ». Par exemple, vous pouvez décider qu'une certaine valeur « valeurY » est seulement disponible quand l'état du bogue est RÉSOLU alors que la valeur « valeurX » doit toujours être affichée. Une fois sélectionné le champ qui doit contrôler la disponibilité des valeurs de ce champ personnalisé, vous pouvez modifier les valeurs de ce champ personnalisé pour définir le critère, voir Section 3.11.1, « Voir/Modifier les valeurs autorisées ». 3.10.2. Modifier les champs personnalisés Dès qu'un champ personnalisé est créé, son nom et son type ne peuvent pas être modifiés. Si ce champ est une liste déroulanteIf , la liste de ses valeurs peut être définie comme indiqué dans Section 3.11.1, « Voir/Modifier les valeurs autorisées ». Tous les autres attributs peuvent être modifiés comme décrit ci-dessous. 3.10.3. Supprimer des champs personnalisés Seuls les champs personnalisés marqués comme obsolètes et qui n'ont jamais été utilisés peuvent ≖tre supprimés (sinon l'intégrité de l'historique du bogue pourrait être compromise). Pour les champs personnalisés marqués comme obsolètes, un lien « Supprimer » apparaîtra dans la colonne « Action ». Si le champ personnlisé a déjà été utilisé auparavant, la suppression sera rejetée. Mais marquer le champ comme obsolète suffira à le masquer totalement de l'interface utilisateur. 3.11. Valeurs autorisées Les valeurs autorisées pour le système d'exploitation, la plateforme, les priorité et gravité de bogue, les champs personnalisés de type « Liste » et « Boîte de sélection multiple » (voir Section 3.10, « Champs personnalisés »), ainsi que la liste des états et résolutions peuvent être personnalisés à partir de la même interface. Vous pouvez ajouter, modifier, désactiver et supprimer les valeurs qui peuvent être utilisées pour ces champs. 3.11.1. Voir/Modifier les valeurs autorisées Modifier les valeurs autorisées nécessite le privilège « admin ». Cliquez sur « Valeurs du champ » dans la page d'administration. Une liste de tous les champs, standards et personnalisés, pour lesquels les valeurs autorisées peuvent être modifiées, apparaît. Cliquez sur un nom de champ pour modifier ses valeurs autorisées. Il n'y a pas de limite au nombre de valeurs qu'un champ peut avoir, mais chaque valeur doit être unique pour ce champ. La position est importante pour afficher ces valeurs dans l'ordre désiré. Quand la disponibilité des valeurs d'un champ personnalisé est contrôlée par un autre champ, vous pouvez sélectionner ici quelle valeur de l'autre champ doit être définie pour que la valeur du champ personnalisé apparaisse. 3.11.2. Supprimer des valeurs autorisées Les valeurs autorisées de champs personnalisés peuvent être supprimées, mais seulement si les deux conditions suivantes sont respectées : 1. La valeur n'est pas celle utilisée par défaut par le champ. 2. Aucun bogue n'utilise cette valeur. Si une de ces conditions n'est pas respectée, la valeur ne peut pas être effacée. La seule façon de supprimer ces valeurs consiste à réassigner les bogues pour une autre valeur et de définir une autre valeur par défaut pour le champ. 3.12. Worflow des états de bogue Le workflow des états de bogues n'est plus codé en dur et peut être librement personnalisé à partir de l'interface Web. Seul un état de bogue ne peut pas être renommé ou supprimé, NON CONFIRMÉ, mais le workflow le concernant est libre. La page de configuration affiche tous les états de bogues existants deux fois, la première sur la gauche pour les états de bogue d'où l'on arrive, et la seconde pour l'état vers lequel on va. Si la case est cochée, alors la transition entre les deux états de bogues est valide, sinon, elle est interdite indépendamment de vos privilèges. L'état de bogue utilisé pour le paramètre « duplicate_or_move_bug_status » doit faire partie du workflow car c'est l'état de bogue qui sera utilisé lors du clonage ou du déplacement d'un bogue ; il doit donc être disponible pour chaque état de bogue. Quand le workflow est défini, le lien « Voir les déclencheurs » sous la table vous permet de définir quelles transitions nécessitent un commentaire de la part des utilisateurs. 3.13. Voter Le code pour le système de vote de Bugzilla a été déplacé dans une extension, appelée « Voting », dans le répertoire extensions/Voting/. Pour l'activer, vous devez supprimer le fichier disabled de ce répertoire et exécuter checksetup.pl. Le vote permet de donner aux utilisateurs un ensemble de bulletins de votes qu'ils peuvent affecter à des bogues pour indiquer qu'ils aimeraient les voir corrigés. Ceci permet aux développeurs de jauger les besoins des utilisateurs pour une amélioration ou un bogue particulier. En permettant aux bogues ayant un certain nombre de votes de passer automatiquement de l'état « NON CONFIRMÉ » à l'état « CONFIRMÉ », les utilisateurs de Bugzilla peuvent aider à ce que les bogues de haute priorité soient portés à l'attention des développeurs pour qu'ils ne restent pas longtemps dans l'attente d'un triage. Pour modifier les paramètres de vote : 1. Rendez-vous sur la page « Modifier le produit » du produit que vous souhaitez modifier 2. Votes maximum par personne : Définir ce champ à « 0 » désactive les votes. 3. Votes maximum qu'une personne peut affecter à un bogue : Cela doit être un nombre plus petit que le nombre de « Votes maximum par personne ». Ne définissez pas cd champ à « 0 » si « Votes maximum par personne » n'est pas zéro ; cela n'aurait pas de sens. 4. Nombre de votes qu'un bogue de ce produit doit obtenir pour quitter automatiquement l'état NON CONFIRMÉ : Définir ce champ à « 0 » désactive le passage automatique des bogues de l'état NON CONFIRMÉ à CONFIRMÉ. 5. Quand vous avez ajusté les valeurs comme vous le souhaitez, cliquez sur « Mettre à jour ». 3.14. Citations Les citations sont de petits messages qui peuvent être configurés pour apparaître avec les résultats de recherche. Une installation de Bugzilla peut avoir ses propres citations. Quand une citation doit être affichée, une sélection aléatoire est faite sur l'ensemble des citations déjà présentes. La soumission de citation est contrôlée par le paramètre quip_list_entry_control. Plusieurs valeurs sont possibles : open, moderated ou closed. Pour activer l'approbation de citations, vous devez définir ce paramètre à « moderated ». De cette façon, les utilisateurs seront libres de soumettre des citations mais un administrateur doit explicitement les approuver avant qu'elles ne soient effectivement utilisées. Pour voir les citations dans l'interface utilisateurs, il suffit de cliquer sur une citation lorsqu'elle est affichée avec les résultats de recherche. Ou elles peuvent être atteintes directement dans le navigateur en visitant l'URL « quips.cgi » (préfixée par l'emplacement Web habituel de votre installation Bugzilla). Quand l'interface pour les citations a été activée, il suffit de cliquer sur « Voir et modifier la liste complète des citations » pour voir la page d'administration. Une page recensant toutes les citations disponibles de la base de données sera affichée. Une case à cocher est située à côté de chaque citation, dans la colonne « Approuvée ». Les citations ayant cette case cochée sont déjà approuvées et apparaîtront avec les résultats de recherche. Celles qui n'ont pas cette case cochée sont encore dans la base de données mais n'apparaîtront pas dans les résultats de recherche. Les citations soumises par les utilisateurs n'ont pas cette case cochée. Il y a également un lien de suppression à côté de chaque citation qui peut être utilisé pour supprimer définitivement une citation. L'affichage des citations est contrôlé par la préférence utilisateur display_quips. Les valeurs possibles sont « Activé » et « Désactivé ». 3.15. Groupes et restrictions de groupes Les groupes permettent de séparer les bogues en divisions logiques. Les groupes sont typiquement utilisés pour isoler les bogues qui ne devraient être vus que par certaines personnes. Par exemple, une société pourrait créer un groupe différent pour chacun de ses clients ou de ses partenaires. Les permissions de groupe pourraient être définies de sorte que chaque partenaire ou client ne puisse accéder qu'à ses propres bogues. Ou encore, les groupes pourraient être utilisés pour créer des contrôles d'accès variables pour différents départements à l'intérieur d'une organisation. Un autre usage courant des groupes est d'associer des groupes à des produits, créant ainsi une isolation et un contrôle d'accès par produit. Les groupes et les comportements de groupe sont contrôlés dans plusieurs endroits : 1. La page de configuration des groupes. Pour voir ou modifier des groupes existants, ou pour en créer de nouveaux, cliquez sur le lien « Groupes » dans la page « Administration ». Cette section du manuel traite principalement des aspects des restrictions de groupes accédés sur cette page. 2. Paramètres de configuration globaux. Bugzilla a plusieurs paramètres qui contrôlent le comportement des groupes par défaut et les niveaux de restrictions globaux. Pour plus d'informations sur les paramètres qui contrôlent le comportement global des groupes, consultez Section 3.1.9, « Restrictions de groupe ». 3. Association de produits avec des groupes. La plupart des fonctionnalités des groupes et de leur sécurité est contrôlée au niveau du produit. Certains aspects des restrictions de groupe pour les produits sont traités dans cette section, mais pour plus de détails, consultez Section 3.4.4, « Affecter des restrictions de groupes à des produits ». 4. Contrôles d'accès aux groupes pour les utilisateurs. Consultez Section 3.15.3, « Affecter des utilisateurs aux groupes » pour des détails sur la façon d'affecter des restrictions de groupe pour les utilisateurs. Les restrictions de groupe sont tels que, que seuls les membres d'un groupe peuvent voir le bogue. Si un bogue est dans plus d'un groupe, seuls les membres de tous les groupes auxquels appartient le bogue, peuvent voir le bogue. Pour des informations pour autoriser un accès en lecture seule à certains utilisateurs et un accès en modification complet à d'autres, consultez Section 3.4.4, « Affecter des restrictions de groupes à des produits ». [Note] Par défaut, les bogues peuvent être également vus par le responsable, le rapporteur et par toutes les personnes dans la liste « Copie à », sans tenir compte des droits qu'ils auraient normalement pour l'affichage des bogues. La visibilité pour le rapporteur et les personnes de la liste « Copie à » peut être be outrepassé (bogue par bogue) en modifiant le bogue, en y cherchant la section commençant par « Les utilisateurs des rôles sélectionnés ci-dessous… » et en retirant la coche de la case située à côté de « Rapporteur » ou de « Copie à » (ou les deux). 3.15.1. Créer des groupes Pour créer un nouveau groupe, réalisez les étapes suivantes : 1. Cliquez sur le lien « Administration » dans le pied de page, puis sur le lien « Groupes » dans la page d'administration. 2. Un tableau de tous les groupes existants est affiché. Sous le tableau se trouve une description de tous les champs. Pour créer un nouveau groupe, cliquez sur le lien « Ajouter un groupe » sous le tableau des groupes existants. 3. Il y a cinq champs à remplir. Ces champs sont documentés sous le formulaire. Choisissez un nom et une description pour le groupe. Décidez ensuite si ce groupe doit être utilisé pour les bogues (selon toute vraisemblance, ceci doit être sélectionné). Vous pouvez optionnellement choisir une expression régulière qui ajoutera automatiquement les utilisateurs qui correspondent au groupe et choisir une icône qui aidera à identifier les commentaires d'utilisateurs pour le groupe. L'expression régulière peut être utile, par exemple pour ajouter automatiquement tous les utilisateurs d'une même société dans un groupe (si le groupe est destiné à un client ou un partenaire spécifique). [Note] Si le champ « Nouvelle expression régulière d'utilisateur » est rempli, tous les utilisateurs dont l'adresse électronique correspond à l'expression régulière seront automatiquement membre du groupe tant que leurs adresses correspond à l'expression régulière. Si leurs adresses changent et ne correspondent plus à l'expression régulière, ils seront retirés du groupe. Les versions 2.16 et précédentes ne retiraient pas automatiquement les utilisateurs dont l'adresse électronique ne correspondait plus à l'expressioon régulière. [Avertissement] Si vous spécifiez un domaine dans l'expression régulière, assurez-vous de terminer l'expression régulière par « $ ». Sans quoi, en autorisant l'accès à « @masociete\.com », vous autoriserez aussi l'accès à « pirate@masociete.com.cracker.net ». Vous devrez plutôt utiliser « @masociete\.com$ » comme expression régulière. 4. Après la création du groupe, vous pouvez le modifier pour définir des options supplémentaires. La page « Modification du groupe » permet de spécifier d'autres groupes qui pourraient être inclus dans celui-ci et les groupes autorisés à ajouter ou retirer des utilisateurs de ce groupe. Pour plus de détails, consultez Section 3.15.2, « Modification de groupes et affectation de restrictions ». 3.15.2. Modification de groupes et affectation de restrictions Pour accéder à la page « Modification du groupe », cliquez sur le lien « Administration » dans le pied de page puis cliquez sur le lien « Groupes » dans la page d'administration. Un tableau de tous les groupes existants est affiché. Cliquez sur le nom du groupe que vous voulez modifier. La page « Modification du groupe » contient les mêmes cinq champs présents lors de la création d'un nouveau groupe. Elle contient deux sections supplémentaires « Permissions de groupe » et « Suppression de masse ». L'option « Suppression de masse » supprime simplement tous les utilisateurs qui correspondent à l'expression régulière saisie du groupe. La section « Permissions de groupe » nécessite plus d'explications. La section « Permissions de groupe » dans la page « Modification du groupe » contient quatre ensembles de permissions qui contrôlent les relations de ce groupe aux autres groupes. Si le paramètre « usevisibilitygroups » est utilisé (voir Section 3.1, « Configuration de Bugzilla ») deux ensembles de permissions supplémentaires sont affichés. Chacun consiste en deux boîtes de sélection. Sur la gauche, une boîte de sélection avec une liste des groupes existants. Sur la droite, une boîte de sélection listant tous les groupes actuellement sélectionnés pour cette permission (cette boîte sera vide pour les nouveaux groupes). La façon dont ces permissions permettent aux groupes d'être en relation avec d'autres est appelée héritage. Chacune des six permissions est décrite ci-dessous. Groupes qui sont membres de ce groupe Les membres de tous les groupes sélectionnés ici seront automatiquement membres de ce groupe. En d'autres termes, les membres de tout groupe sélectionné hériteront de l'appartenance à ce groupe. Groupes dont ce groupe est membre Les membres de ce groupe hériteront de l'appartenance à tout groupe sélectionné ici. Par exemple, supposons que le groupe modifié est Admin. S'il y a deux produits (Produit1 et Produit2) et que chaque produit a son propre groupe (Groupe1 et Groupe2), et que le groupe Admin doit avoir accès aux deux produits, sélectionnez simplement Groupe1 et Groupe2 ici. Groupes pouvant donner l'appartenance à ce groupe Les membres de tout groupe sélectionné ici pourront ajouter des utilisateurs à ce groupe, même s'ils ne sont pas membres eux-mêmes de ce groupe. Groupes pour lesquels ce groupe peut donner l'appartenance Les membres de ce groupe peuvent ajouter des utilisateurs à tout groupe sélectionné ici, même s'ils ne sont pas membres eux-mêmes des groupes sélectionnés. Groupes pouvant voir ce groupe Les membres de tout groupe sélectionné peuvent voir les utilisateurs dans ce groupe. Ce paramètre n'est visible que si le paramètre « usevisibilitygroups » est activé dans la page de configuration de Bugzilla. Consultez Section 3.1, « Configuration de Bugzilla » pour des informations sur la configuration de Bugzilla. Groupes que ce groupe peut voir Les membres de ce groupe peuvent voir les membres de tous les groupes sélectionnés. Ce paramètre n'est visible que si le paramètre « usevisibilitygroups » est activé dans la page de configuration de Bugzilla. Consultez Section 3.1, « Configuration de Bugzilla » pour des informations sur la configuration de Bugzilla. 3.15.3. Affecter des utilisateurs aux groupes Les utilisateurs peuvent devenir membres d'un groupe de plusieurs manières : 1. L'utilisateur peut être explicitement placé dans le groupe par la modification de son profil. Ceci peut être effectué en accédant à la page « Utilisateurs » dans la page « Administration ». Utilisez le formulaire de recherche pour trouver l'utilisateur dont vous voulez modifier l'appartenance à un groupe, et cliquez sur son adresse électronique dans les résultats de recherche pour modifier son profil. La page du profil liste tous les groupes et indique si l'utilisateur est membre du groupe directement ou indirectement. Vous trouverez plus d'informations sur l'appartenance indirecte à un groupe ci-dessous. Pour plus de détails sur l'administration des utilisateur, consultez Section 3.2, « Administrer les utilisateurs ». 2. Le groupe peut inclure un autre groupe dont l'utilisateur est membre. Ceci est indiqué par des crochets autour de la case à cocher à côté du nom du groupe dans le profil de l'utilisateur. Consultez Section 3.15.2, « Modification de groupes et affectation de restrictions » pour plus de détails sur l'héritage de groupe. 3. L'adresse électronique de l'utilisateur peut correspondre à une expression régulière spécifiée dans le groupe et qui autorise automatiquement l'appartenance au groupe. Ceci est indiqué par des « * » encadrant la case à cocher à côté du nom du groupe dans le profil de l'utilisateur. Consultez Section 3.15.1, « Créer des groupes » pour des détails sur l'option d'expression régulière lors de la création de groupe. 3.15.4. Affecter des restrictions de groupes à des produits La fonctionnalité principale des groupes est dérivée des relations des groupes aux produits. Les concepts sur la ségrégation de l'accès aux bogues en utilisant les restrictions de groupes sur les produits peuvent être déroutants. Pour des détails et des exemples sur ce sujet, consultez Section 3.4.4, « Affecter des restrictions de groupes à des produits ». 3.16. Vérifier et maintenir l'intégrité de la base de données Avec le temps, il est possible que la base de données de Bugzilla se corrompe ou présente des anomalies. Cela pourrait se produire avec une utilisation normale de Bugzilla, une administration manuelle de la base de données en dehors de l'interface utilisateur de Bugzilla ou à cause d'autres événements inattendus. Bugzilla contient un script de « Vérification d'intégrité » qui peut réaliser des vérifications de bases de données basiques et réparer certains problèmes ou inconsistances. Pour exécuter le script de « Vérification d'intégrité », il faut se connecter en tant qu'administrateur et cliquer sur le lien « Check-up » dans la page d'administration. Tout problème identifié sera alors affiché en lettres rouges. Si le script est capable de corriger un problème, il affichera un lien pour lancer la correction. Si le script ne peut pas corriger le problème, il demandera une administration manuelle de la base de données ou une restauration. Le script de « Vérification d'intégrité » peut également être exécuté en ligne de commande par le script Perl sanitycheck.pl. Le script peut aussi être exécuté comme tâche planifiée. Les résultats seront alors envoyés par courriel. Une bonne pratique est d'exécuter régulièrement le script de « Vérification d'intégrité ». [Avertissement] Le script de « Vérification d'intégrité » ne remplace pas un administrateur de base de données compétent. Il est seulement conçu pour vérifier et réparer les problèmes de bases de données basiques. Chapitre 4. La sécurité dans Bugzilla Table des matières 4.1. Système d'exploitation 4.1.1. Ports TCP/IP 4.1.2. Comptes utilisateur système 4.1.3. La prison chroot 4.2. Serveur Web 4.2.1. Désactiver l'accès à distance aux fichiers de configuration de Configuration 4.3. Bugzilla 4.3.1. Prevent users injecting malicious Javascript Bien que certains des éléments dans ce chapitre soient relatifs au système d'exploitation sur lequel est exécuté Bugzilla ou sur certains logiciels de support requis pour faire fonctionner Bugzilla, tout est lié à la protection de vos données. Ceci n'est pas destiné à être un guide exhaustif de sécurisation de Linux, Apache, MySQL ou toute autre partie logicielle mentionnée. Il n'y a pas de substitut à une administration et une surveillance actives d'une machine. La clé pour une bonne sécurité tient en fait en ces trois mots : c'est vous. Bien que les programmeurs s'efforcent en général à écrire du code sûr, les accidents dpeuvent arriver et arrivent. La meilleure approche de sécurité consiste toujours à supposer que le programme sur lequel vous travaillez n'est pas sûr à 100 % et qu'il faut faut limiter son accès aux autres éléments de la machine autant que possible. 4.1. Système d'exploitation 4.1.1. Ports TCP/IP Le standard TCP/IP définit plus de 65000 ports pour l'envoi et la réception du trafic. Parmi ceux-ci, Bugzilla n'a besoin que d'un seul pour fonctionner (différentes configurations et options peuvent en nécessiter jusqu'à trois). Vous devez faire un audit sur votre serveur et vous assurez que vous n'êtes pas en train d'écouter des ports dont vous n'avez pas besoin. Il est aussi fortement recommandé que le serveur sur lequel se trouve Bugzilla, de même que toute autre machine que vous administrez, soient placés derrière un pare-feu. 4.1.2. Comptes utilisateur système Beaucoup de démons, tels que httpd d'Apache ou mysqld de MySQL fonctionnent en tant que « root » ou « nobody ». C'est encore pire sur les machines Windows où la majorité des services focntionne en tant que « SYSTEM ». L'exécution en « root » ou « SYSTEM » introduit des inquiétudes évidentes quant à la sécurité, les problèmes introduits par l'exécution de tout en tant que « nobody » peuvent ne pas être si évidents. Grossièrement, si vous exécutez tous les démons en tant que « nobody » et que l'un d'entre eux est compromis, il peut compromettre tout autre démon exécuté en tant que « nobody » sur votre machine. Pour cette raison, il est recommandé de créer un compte utilisateur par démon. [Note] Vous aurez besoin de définir l'option webservergroup dans le fichier localconfig pour le groupe avec lequel votre serveur Web s'exécute. Cela permettra au script ./checksetup.pl de définir les permissions de fichiers sur les systèmes Unix de sorte que rien ne soit accessible en écriture pour tout le monde. 4.1.3. La prison chroot Si votre système le gère, vous devriez considérer de faire fonctionner Bugzilla dans une prison chroot. Cette option fournit une sécurité sans précédent en empêchant tout ce qui s'exécute à l'intérieur de la prison d'accéder à toute information en dehors de celle-ci. Si vous souhaitez utiliser cette option, veuillez consulter la documentation livrée avec votre système. 4.2. Serveur Web 4.2.1. Désactiver l'accès à distance aux fichiers de configuration de Configuration Il y a beaucoup de fichiers placés dans le répertoire Bugzilla qui ne doivent pas être accessibles depuis le Web. À cause de la façon dont est actuellement structuré Bugzilla, la liste de ce qui doit ou ne doit pas être accessible est plutôt compliquée. Un moyen rapide est d'exécuter le script testserver.pl pour vérifier que votre serveur Web sert les pages de Bugzilla comme il le doit. Si ce n'est pas le cas, veuillez suivre les quelques étapes ci-dessous. [Astuce] Bugzilla sait créer des fichiers .htaccess qui appliquent ces règles. Les instructions pour activer ces directives dans Apache peuvent être consultées sur Section 2.2.4.1, « Bugzilla utilisant Apache » * Dans le répertoire principal de Bugzilla, vous devez : + Bloquer : *.pl, *localconfig* * Dans le répertoire data : + Bloquer tout * Dans le répertoire data/webdot : + Si vous utilisez un serveur « webdot » distant : o Bloquer tout o Mais autoriser : *.dot seulement pour le serveur « webdot » distant + Sinon, si vous utilisez un « GraphViz » local : o Bloquer tout o Mais autoriser : *.png, *.gif, *.jpg, *.map + Et si vous n'utilisez aucun serveur « webdot » : o Bloquer tout * In Bugzilla : + Bloquer tout * Le répertoire template: + Bloquer tout Assurez-vous que les données qui ne doivent pas être accédées à distance soient correctement bloquées. Accordez un intérêt particulier au fichier localconfig qui contient le mot de passe de votre base de données. Gardez à l'esprit que certains éditeurs créent des fichiers temporaires ou de sauvegarde dans le répertoire de travail et que ceux-ci ne doivent pas être accessibles non plus. Pour plus d'informations, consultez le bogue 186383 ou Bugtraq ID 6501. Pour tester, exécutez le script testserver.pl. [Astuce] Assurez-vous de consulter Section 2.2.4, « Le serveur Web » pour les intructions spécifiques au serveur Web que vous utilisez. 4.3. Bugzilla 4.3.1. Prevent users injecting malicious Javascript Si vous avez installé Bugzilla version 2.22 ou une version ultérieure pour la première fois (pas une mise à jour à partir d'une ancienne installation), alors le paramètre utf8 est activé par défaut. Ceci permet à Bugzilla de définir explicitement l'encodage de caractères, suivant ainsi la a recommandation du CERT conseillant exactement cela. Ce qui suit par conséquent ne s'adresse pas à vous ; conservez seulement le paramètre utf8 activé. Si vous avez fait une mise à jour à partir d'une ancienne version, il peut alors être possible pour un utilisateur de Bugzilla de tirer avantage del'ambiguïté de l'encodage de caractères pour injecter du code HTML dans les commentaires de Bugzilla. Ceci pourrait inclure du code malveillant. À cause des problèmes d'internationalisation, nous ne pouvons pas activer le paramètre utf8 sur des mises à jour d'installations. Activer ce paramètre manuellement empêchera ce problème de survenir. Chapitre 5. Utilisation de Bugzilla Table des matières 5.1. Introduction 5.2. Création d'un compte Bugzilla 5.3. Anatomie d'un bogue 5.4. Cycle de vie d'un bogue 5.5. Recherche de bogues 5.5.1. Tableaux booléens 5.5.2. Recherche d'un bogue spécifique 5.5.3. Sensibilité à la casse dans les recherches 5.5.4. Listes des bogues 5.5.5. Ajout/suppression de marqueurs 5.6. Rapporter des bogues 5.6.1. Rapporter un nouveau bogue 5.6.2. Clônage d'un bogue existant 5.7. Fichiers joints 5.7.1. Visionneuse de fichiers 5.8. Trucs et astuces 5.8.1. Hyperlien automatique 5.8.2. Commentaires 5.8.3. Formatage des commentaires du côté du serveur 5.8.4. Arbre de dépendance 5.9. Informations d'horodatage 5.10. Préférences utilisateur 5.10.1. Préférences générales 5.10.2. Préférences de messagerie 5.10.3. Recherches enregistrées 5.10.4. Préférences du compte 5.10.5. Permissions 5.11. Rapports et graphiques 5.11.1. Rapports 5.11.2. Graphiques 5.12. Étiquettes 5.13. Notifications 5.13.1. Évènement 5.13.2. Programmation des notifications 5.13.3. Requêtes de notifications 5.13.4. Enregistrement des modifications 5.1. Introduction Cette section contient des informations pour les utilisateurs finaux de Bugzilla. Il y a une installation de test, appelée Landfill, avec laquellle vous êtes invité à jouer (si elle est en fonction). Cependant, toutes les installations de Bugzilla n'auront pas forcément toutes les fonctionnalités activées et des installations différentes peuvent utiliser des versions différentes, aussi, toutes les indications données dans ce document ne fonctionneront pas comme décrites. La foire aux questions (FAQ) est disponible sur wiki.mozilla.org. Elle peut couvrir des questions pour lesquelles vous n'avez pas de réponse. 5.2. Création d'un compte Bugzilla Si vous voulez utiliser Bugzilla, vous devez commencer par créer un compte. Consultez l'administrateur responsable de votre installation Bugzilla pour connaître l'URL à laquelle vous connecter pour y accéder. Si vous désirez tester, utilisez cette URL : http://landfill.bugzilla.org/bugzilla-4.4-branch/. 1. Sur la page d'accueil index.cgi, cliquez sur le lien « Nouveau compte » situé en haut ou en bas de la page. Saisissez maintenant votre adresse électronique puis cliquez sur le bouton « Envoyer ». [Note] Si aucun de ces liens n'est disponible, cela signifie que l'administrateur de cette installation a désactivé la création automatique de compte. Lui seul peut créer des comptes utilisateurs. Une raison possible est que cette installation est privée. [Note] Si la création de compte est restreinte à certains utilisateurs seulement, vous pouvez voir les liens mais votre inscription pourra échouer si votre adresse électronique ne figure pas dans la liste des personnes autorisées à s'inscrire. C'est un autre moyen de restreindre l'accès et l'édition de bogue sur cette installation. 2. Dans quelques instants, et si votre enregistrement est accepté, vous devriez recevoir un courriel sur l'adresse électronique que vous avez fournie, qui contient votre nom de connexion (généralement identique à l'adresse électronique), et deux URL avec un jeton (une chaîne aléatoire générée par l'installation) pour confirmer ou annuler votre enregistrement. C'est un moyen pour empêcher les utilisateurs d'abuser avec la création de comptes, par exemple en saisissant des adresses électroniques inexistantes ou qui ne sont pas les leurs. 3. Par défaut, vous avez 3 jours pour confirmer votre inscription. Passé ce délai, le jeton est invalidé et l'inscription automatiquement annulée. Vous pouvez également annuler votre inscription en cliquant sur le lien approprié dans le courrier de confirmation que vous avez reçu. 4. Si vous confirmez votre inscription, Bugzilla vous demandera votre vrai nom (optionnel, mais recommandé) et votre mot de passe, qui devra comporter entre 3 et 16 caractères. 5. Maintenant, il vous suffit de cliquer sur le lien « Connexion » au bas de la page dans votre navigateur, de saisir l'adresse électronique et le mot de passe que vous avez choisis dans le formulaire de connexion et de cliquer sur le bouton « Se connecter ». Vous êtes maintenant connecté. Bugzilla utilise des cookies pour se souvenir que vous vous êtes connecté, donc, à moins d'avoir désactivé les cookies ou d'avoir changé d'adresse IP, vous ne devriez pas avoir à vous identifier à nouveau pendant votre session. 5.3. Anatomie d'un bogue Le cœur de Bugzilla se situe dans l'écran affiché pour un bogue en particulier. C'est un bon endroit pour expliquer quelques concepts de Bugzilla. Le Bogue 1 sur Landfill est un bon exemple. Vous remarquerez que les libellés pour la plupart des champs sont des hyperliens ; en cliquant dessus, vous ferez apparaître une aide contextuelle sur ce champ en particulier. Les champs marqués avec « * » peuvent ne pas être présents sur toutes les installations Bugzilla. 1. Produit et composant : Les bogues sont divisés par produits et composants, un produit ayant un ou plusieurs composants. Par exemple, le produit « Bugzilla » sur bugzilla.mozilla.org est composé de plusieurs composants : Administration : Administration d'une installation de Bugzilla. Bugzilla-Général : Tout ce qui ne correspond pas aux autres composants ou qui en concerne plusieurs à la fois. Création/modification de bogues : Création, modification et affichage des bogues. Documentation : La documentation de Bugzilla, y compris le guide de Bugzilla. Courriel : Tout ce qui concerne les courriels envoyés par Bugzilla. Installation : Le processus d'installation de Bugzilla. Requêtes/Liste des bogues : Tout ce qui concerne la recherche de bogues et l'affichage des listes de bogues. Rapport/Graphiques : Obtenir des rapports dans Bugzilla. Comptes utilisateurs : Tout ce qui concerne la gestion d'un compte utilisateur du point de vue de l'utilisateur. Recherches enregistrées, création de comptes, changement de mot de passe, connexion, etc. Interface Utilisateur (UI) : Problèmes généraux concernant l'interface utilisateur (pas les fonctionnalités) y compris les problèmes cosmétiques, les modèles HTML, etc. 2. État et résolution : Ceci définit l'état exact dans lequel se trouve le bogue - de l'état non confirmé comme bogue à l'état corrigé et confirmé par l'assurance qualité. Les différentes valeurs possibles pour l'état et la résolution sont documentées dans l'aide contextuelle pour ces éléments. 3. Assigné à : La personne responsable de la correction du bogue. 4. *Contact QA : La personne responsable de l'assurance qualité du bogue. 5. *URL : Une URL associée au bogue, le cas échéant. 6. Résumé : Une phrase résumant le problème. 7. *Tableau blanc : Un champ de saisie de texte libre pour ajouter de courtes notes ou des marqueurs à un bogue. 8. *Mots-clés : L'administrateur peut définir des mots-clés que vous pouvez utiliser pour marquer et catégoriser les bogues - par ex. : Le Projet Mozilla a des mots-clés comme « plantage » et et « régression ». 9. Matériel et OS : Ceci indique l'environnement dans lequel le bogue a été trouvé. 10. Version : Le champ « Version » est habituellement utilisé pour les versions d'un produit qui a été publié et est défini pour indiquer quelles versions d'un composant a le problème particulier exposé dans le bogue. 11. Priorité : Le responsable du bogue utilise ce champ pour mettre des priorités sur ses bogues. Il est de bon ton de na pas changer ceci sur les bogues d'autres personnes. 12. Gravité : Ceci indique la gravité du problème - de « blocker » (l'application est inutilisable) à « trivial » (problème cosmétique mineur). Vous pouvez aussi utiliser ce champ pour indiquer si le bogue est une demande d'amélioration. 13. *Jalon cible : Une version future pour laquelle le bogue devra être corrigé. Par exemple, les jalons du projet Bugzilla pour les futures versions de Bugzilla sont 2.18, 2.20, 3.0, etc. Les jalons ne sont pas limités à des nombres cependant : vous pouvez utiliser toute chaîne de texte, comme des dates par exemple. 14. Rapporteur La personne qui a rapporté le bogue. 15. Copie à : Une liste de gens qui reçoivent des courriels quand des changements surviennent sur le bogue. 16. *Horodatage : Ce formulaire peut être utilisé pour l'horodatage. Pour utiliser cette fonctionnalité, vosu devez avoir l'appartenance de groupe spécifié par le paramètre « timetrackinggroup ». Est. intiale Ce champ affiche l'estimation initiale du temps escompté. Est. actuelle Ce champ affiche le temps estimé actuel. Ce nombre est calculé à partir des chiffres de « Heures travaillées » et « Heures restantes ». Heures travaillées Ce champ affiche le nombre d'heures travaillées. Heures restantes Ce champ affiche le résultat de la soustraction « Est. actuelle » - « Heures travaillées ». Cette valeur + « Heures travaillées » deviendra la nouvelle « Est. actuelle ». % d'achèvement Ce champ affiche le pourcentage d'accomplissement de la tâche. Gain Ce champ affiche le nombre d'heures d'avance par rapport à l'estimation d'origine. Échéance Ce champ affiche la date d'échéance pour le bogue. 17. Fichiers joints : Vous pouvez joindre des fichiers (par exemple des jeux de test ou des correctifs) aux bogues. S'il y a des fichiers joints, ils sont listés dans cette section. Les fichiers joints sont normalement stockés dans la base de données Bugzilla, à moins qu'ils ne soient marqués « Gros fichiers » et sont alors stockés directement sur le disque. 18. *Dépend de : Si ce bogue ne peut pas être corrigé à moins que d'autres bogues ne le soient avant (« Dépend de »), ou ce bogue empêche d'autres bogues d'être corrigés (« Bloque »), leur numéro est noté ici. 19. *Votes : Indique si ce bogue a reçu des voix. 20. Commentaires supplémentaires Vous pouvez ajouter votre grain de sel à la discussion sur le bogue ici, si vous avez quelque chose à ajouter qui vaut la peine d'être mentionné. 5.4. Cycle de vie d'un bogue Le cycle de vie d'un bogue est personnalisable pour s'adapter aux besoins de votre organisation, consulter Section 3.12, « Worflow des états de bogue ». Figure 5.1, « Cycle de vie d'un bogue Bugzilla » contient une représentation graphique de ce cycle de vie, utilisant les états de bogue par défaut. Si vous voulez personnaliser cette image pour votre site, le fichier du diagramme est disponible dans le format XML natif de Dia. Figure 5.1. Cycle de vie d'un bogue Bugzilla Cycle de vie d'un bogue Bugzilla 5.5. Recherche de bogues La page de recherche de bogues de Bugzilla est l'interface où vous pouvez trouver tout rapport de bogue, commentaire ou correctif actuellement dans le système Bugzilla. Vous pouvez jouer avec ici : http://landfill.bugzilla.org/bugzilla-4.4-branch/query.cgi. La page de recherche a des contrôles pour sélectionner différentes valeurs pour tous les champs disponibles d'un bogue, comme décrit plus haut. Pour certains champs, plusieurs valeurs peuvent être sélectionnées. Dans ce cas, Bugzilla affiche les bogues dont le contenu du champ correspond à au moins une des valeurs sélectionnées. Si aucune n'est sélectionnée, alors le champ peut prendre n'importe quelle valeur. Après avoir lancé une recherche, vous pouvez l'enregistrer en tant que Reherche enregistrée, qui apparaîtra alors dans le pied de page. Si vous êtes dans le groupe défini par le paramètre « querysharegroup », vous pouvez partager vos recherches avec d'autres utilisateurs, consulter Recherches enregistrées pour plus de détails. 5.5.1. Tableaux booléens Les recherches avancées sont faites à l'aide de tableaux booléens. Les tableaux booléens affinent encore plus l'ensemble de résultats renvoyés par une requête. Il est possible de rechercher des bogues vaec des combinaisons élaborées de critères. La plus simple des recherches booléennes n'a qu'un seul terme. Ces recherches permettent au champ sélectionné à gauche d'être comparé en utilisant un opérateur ayant une valeur spécifique. En utilisant les boutons « Et », « Ou » et « Ajouter un autre tableau booléen », des termes supplémentaires peuvent être ajoutés à la requête, affinant ainsi encore la liste des bogues renvoyés par la requête. Il y a trois champs pour chaque ligne d'une recherche booléenne. * Champ : les éléments recherchés * Opérateur : l'opérateur de comparaison * Valeur : la valeur à laquelle le champ est comparé 5.5.1.1. Substitution de pronom Quelquefois, une requête a besoin de comparer un champ relatif à l'utilisateur (tel que « ReportedBy ») avec un rôle utilisateur spécifique (comme l'utilisateur exécutant la requête ou l'utilisateur à qui chaque bogue est assigné). Quand l'opérateur est « est égal à » ou « n'est pas égal à », la valeur peut être « %reporter% », « %assignee% », « %qacontact% » ou « %user% ». Le pronom d'utilisateur se réfère à l'utilisateur qui exécute la requête, ou, dans le cas des rapports de notifications, l'utilisateur qui sera destinataire du rapport. Les pronoms « reporter », « assignee » et « qacontact » se réfèrent aux champs correspondants dans le bogue. Les tableaux booléens vous permettent aussi de saisir un nom de groupe dans tout champ relatif à un utilisateur si l'opérateur est « est égal à », « n'est pas égal à » ou « contient une des chaînes ». Ceci vous permettra de faire des requêtes sur tout membre appartenant (ou pas) au groupe spécifié. Le nom du groupe doit être saisi en suivant la syntaxe « %group.toto% », où « toto » est le nom du groupe. Donc, si vous recherchez des bogues rapportés par tout utilisateur appartenant au groupe « editbugs », vous pouvez alors saisir « %group.editbugs% ». 5.5.1.2. Négation À première vue, la négation semble redondante. Plutôt que rechercher PAS (« Résumé » « contient la chaîne » « toto »), on peut rechercher (« Résumé » « ne contient pas la chaîne » « toto »). Cependant, la recherche (« Copie à » « ne contient pas la chaîne » « @mozilla.org ») trouverait tout bogue pour lequel quiconque dans la liste « Copie à » ne contient pas « @mozilla.org » alors que PAS (« Copie à » « contient la chaîne » « @mozilla.org ») trouverait tout bogue pour lequel il n'y a personne dans la liste « Copie à » qui contient la chaîne. De même, l'utilisation de la négation permet aussi la construction d'expressions complexes utilisant des termes séparés par « Ou » puis négativés. La négation permet des requêtes telles que PAS ((« Produit » « est égal à » « mise à jour ») OU (« Composant » « est égal à » « Documentation »)) pour trouver des bogues qui ne sont ni dans le produit « mise à jour », ni dans le composant « Documentation » ou PAS ((« Commentateur » « est égal à » « %assignee% ») OU (« Composant » « est égal à » « Documentation »)) pour trouver des bogues qui ne sont pas liés à la documentation et pour lesquels le responsable n'a jamais fait de commentaires. 5.5.1.3. Tableaux multiples Les termes contenus dans une seule ligne d'un tableau booléen sont tous liés à une seule information. Si vous recherchez un bogue ayant deux personnes différentes dans la liste « Copie à », vous devez alors utiliser deux tableaux booléens. Une recherche pour (« Copie à » « contient la chaîne » « toto@ ») ET (« Copie à » « contient la chaîne » « @mozilla.org ») ne renverra que les bogues avec « foo@mozilla.org » dans la liste « Copie à ». Si vous voulez les bogues pour lesquels il y a quelqu'un dans la liste « Copie à » contenant « foo@ » et un autre contenant « @mozilla.org », vous aurez alors besoin de deux tableaux booléens. Premier tableau : (« Copie à » « contient la chaîne » « toto@ ») Deuxième tableau : (« Copie à » « contient la chaîne » « @mozilla.org ») Les bogues listés seront seulement ceux pour lesquels TOUS les tableaux sont vrais. 5.5.2. Recherche d'un bogue spécifique La recherche rapide est un outil de recherche sous la forme d'une simple boîte de texte pouvant utiliser les méta-caractères pour indiquer ce que l'on cherche. Par exemple, en saisissant « toto|titi » dans la boîte de texte, cele effectuera une recherche de « toto » ou « titi » dans les champs « Résumé » et « Tableau blanc » d'un bogue ; en ajoutant « :ProduitX », la recherche s'effectuera seulement dans ce produit. Vous pouvez l'utiliser pour trouver un bogue par son numéro ou son alias aussi. La boîte de recherche rapide se trouve dans le pied des pages de Bugzilla. Sur la page d'accueil de Bugzilla, se trouve un lien Aide qui détaille son utilisation. 5.5.3. Sensibilité à la casse dans les recherches Les recherches dans Bugzilla sont insensibles à la casse et aux accents, avec l'utilisation de systèmes de gestion de bases de données MySQL ou Oracle. Cependant, lorsque Bugzilla est utilisé avec PostgreSQL, certaines recherches sont sensibles à la casse. Ceci est dû à la façon dont PostgreSQL traite la sensibilité à la casse et aux accents. 5.5.4. Listes des bogues Si vous lancez une recherche, une liste des bogues correspondant sera renvoyée. Le format de cette liste est configurable. Par exemple, elle peut être triée en cliquant sur les en-têtes de colonnes. D'autres fonctionnalités utiles peuvent être accédées en utilisant les liens au bas de la liste : Format long : Ceci donne une grande page avec les champs « Résumé » non modifiables de chaque bogue. XML : Produit la liste de bogues au format XML. CSV : Produit la liste de bogues comme des valeurs séparées par des virgules, pour l'importer par exemple dans un tableur. Flux : Produit la liste de bogues sous forme de flux Atom. Copiez ce lien dans votre lecteur de flux préféré. Si vous utilisez Firefox, vous pouvez aussi enregistrer la liste sous forme de marque-page dynamique en cliquant sur l'icône de marque-page dynamique dans la barre d'adresse. Pour limiter le nombre de bogues dans le flux, ajouter un paramètre « limit=n » à l'URL. iCalendar : Produit la liste sous forme de fichier iCalendar. Chaque bogue est représenté sous forme de tâche dans l'agenda importé. Changer les colonnes : Modifie les attributs des bogues apparaissant dans la liste. Changer plusieurs bogues à la fois : Si votre compte a suffisamment de droits et qu'il apparaît plus d'un bogue dans la liste, ce lien est affiché et vous permet d'apporter le même changement sur tous les bogues de la liste. Par exemple, changer leur responsable. Envoyer un courriel aux responsables des bogues : Si plus d'un bogue apparaît dans la liste et qu'il y a au moins deux responsables distincts, ce lien est affiché pour permettre d'envoyer facilement un courriel à tous les responsables de ola liste de bogues. Modifier la recherche : Si vous n'obtenez pas exactement les résultats que vous escomptiez, vous pouvez revenir à la page de requête par ce lien et faire des ajustements sur la requête pour obtenir de meilleurs résultats. Enregistrer sous : Vous pouvez donner un nom à la requête et l'enregistrer ; un lien apparaîtra dans votre pied de page et vous permettra d'y accéder et de l'exécuter rapidement plus tard. 5.5.5. Ajout/suppression de marqueurs Vous pouvez ajouter ou supprimer des marqueurs dans chaque bogue, qui vous permettent de les trouver et de les gérer plus facilement. Les marqueurs sont propres à un utilisateur et ne peuvent être affichés ou modifiés que par l'utilisateur qui les a créés. Vous pouvez alors lancer des requêtes en utilisant des marqueurs comme critère, en utilisant soit le formulaire de recherche avancée, soit en saisissant « tag:mon_nom_de_marqueur » dans la bo^te de recherche rapide en haut (ou en bas) de la page. Pour activer cette fonctionnalité, vous devez activer la préférence utilisateur « Activer l'utilisation des marqueurs pour les bogues », voir Section 5.10, « Préférences utilisateur ». Cette fonctionnalité est désactivée par défaut. Cette fonctionnalité est utile pour suivre plusieurs bogues mais pour des raisons différentes. Plutôt que de vous ajouter à la liste « Copie à » de tous ces bogues et de mélanger toutes ces raisons, vous pouvez maintenant les stocker dans des listes séparées, par exemple « Ne pas oublier », « Bogues intéressants » ou « Triage ». Un des gros avantages de ce moyen de gérer les bogues est que vous pouvez facilement ajouter ou enlever les marqueurs des bogues un par un. 5.6. Rapporter des bogues 5.6.1. Rapporter un nouveau bogue Des années d'expérience dans l'écriture de bogues ont été distillées pour votre satisfaction dans les recommandations d'écriture de bogue. Bien que certains des conseils soient spécifiques à Mozilla, les principes de base (reproductibilité, spécificité, isolation du produit utilisé, version du produit, le composant incriminé, la plateforme matérielle, et le système d'exploitation utilisé au moment du bogue) assurent des correctifs appropriés pour le bogue que vous avez rencontré. La procédure pour ouvrir un bogue est la suivante : 1. Cliquez sur le lien « Rapporter » disponible dans le pied des pages ou sur le lien « Rapporter un nouveau bogue » affiché sur la page d'accueil de l'installation de Bugzilla. [Note] Si vous voulez rapporter un bogue pour tester le fonctionnement de Bugzilla, vous pouvez le faire sur nos installations de test sur Landfill. 2. Vous devez d'abord sélectionner le produit dans lequel vous avez trouvé un bogue. 3. Vous voyez maintenant un formulaire où vous pouvez indiquer le composant (la partie du produit affectée par le bogue que vous avez découvert ; si vous n'en avez aucune idée, sélectionnez « Général » si un tel composant existe), la version du programme que vous utilisez, le système d'exploitation et la plateforme sur laquelle vous exécutez le programme, et la gravité du bogue (si le bogue que vous avez trouvé plante le programme, c'est probablement un bogue « major » ou « critical » ; s'il s'agit d'une coquille quelque part, c'est un bogue « minor » ; s'il s'agit de quelque chose que vous voudriez voir mis en œuvre, choisissez « enhancement »). 4. Vous devez maintenant fournir un résumé court mais descriptif du bogue que vous avez trouvé. « Mon programme plante tout le temps » est un résumé très pauvre et n'aide pas du tout les développeurs. Essayez quelque chose de plus significatif ou votre bogue sera probablement ignoré à cause du manque de précision. L'étape suivante est de donner une liste très détaillée des étapes pour reproduire le problème que vous avez rencontré. Essayez de limiter ces étapes au minimum nécessaire pour reproduire le problème. Cela facilitera la vie aux développeurs et la probabilité qu'ils traitent votre bogue dans un délai raisonnable sera beaucoup plus grande. [Note] Assurez-vous que tout ce qui se trouve dans le résumé figure aussi dans le premier commentaire. Les résumés sont souvent mis à jour et cela assurera que les informations d'origine soient facilement accessibles. 5. Lorsque vous rapportez le bogue, vous pouvez également joindre un document (un jeu de test, un correctif, ou une copie d'écran du problème). 6. Suivant l'installation de Bugzilla que vous utilisez et le produit pour lequel vous rapportez le bogue, vous pouvez aussi demander aux développeurs de considérer votre bogue de différentes manières (comme demander la revue du correctif que vous venez de joindre, demander que votre bogue bloque la prochaine version du produit et beaucoup d'autres requêtes spécifiques au produit). 7. C'est maintenant le bon moment pour relire votre rapport de bogue. Retirer toutes les fautes d'orthographe, sans quoi votre bogue pourrait ne pas être trouvé par les développeurs qui exécutent des requêtes sur des mots spécifiques, et par conséquent, votre bogue ne serait pas porté à leur attention. Assurez-vous aussi de n'avoir pas oublié d'informations importantes que les développeurs devraient savoir pour reproduire le problème et que la description du problème est suffisamment claire et explicite. Si vous pensez que votre rapport de bogue est prêt, la dernière étape est de cliquer sur le bouton « Soumettre » pour ajouter votre rapport à la base de données. vous n'avez pas besoin d'ajouter « toutes » ou des mots similaires dans le champ « URL ». S'il n'y a pas d'URL spécifique associée au bogue, laissez ce champ vide. Si vous pensez qu'un bogue que vous avez rapporté a été incorrectement marqué comme DOUBLON d'un autre, veuillez poser votre question dans votre bogue et non dans celui à cause duquel votre boque a été marqué comme doublon. Vous pouvez ajouter à la liste « Copie à » la personne qui a marqué votre bogue comme doublon, si elle n'y figure pas déjà. 5.6.2. Clônage d'un bogue existant À compter de la version 2.20, Bugzilla a une fonctionnalité qui vous permet de cloner un bogue existant. Le bogue nouvellement créé héritera de la plupart des paramètres de l'ancien bogue. Ceci vous permet de reporter plus facilement dans un nouveau bogue des problèmes similaires. Pour utiliser cette fonctionnalité, rendez-vous dans le bogue que vous voulez cloner, puis cliquer sur le lien « Cloner ce bogue » sur la page du bogue. Ceci vous amènera à la page « Rapporter un bogue » qui sera pré-remplie avec les valeurs de l'ancien bogue. Vous pouvez changer ces valeurs et/ou en ajouter d'autres si nécessaire. 5.7. Fichiers joints Vous devez utiliser des fichiers à joindre plutôt que des commentaires pour les gros volumes de texte ASCII, comme les traces, les fichiers de débogage ou les fichiers journaux. Ainsi, cela ne remplit pas inutilement le bogue pour celui qui voudrait le lire et cela évite la réception de gros courriels inutiles pour les personnes qui suivent le bogue. Vous devez ajuster les copies d'écrans. Il n'est pas nécessaire d'afficher tout l'écran pour signaler un problème sur un pixel. Bugzilla stocke et utilise un type de contenu (content-type) pour chaque fichier joint (par ex. : text/html). Pour télécharger un fichier joint avec un type de contenu différent (par ex. : application/xhtml+xml), vous pouvez outrepasser ceci en ajoutant un paramètre « content_type » à l'URL, par ex. : &content_type=text/plain. Si vous avez un fichier très gros à joindre qui ne nécessite pas d'être enregistré pour toujours (comme la plupart des fichiers joints), ou quelque chose qui est trop gros pour votre base de données, vous pouvez marquer votre fichier comme « Gros fichier », en supposant que l'administrateur de l'installation a activé cette fonctionnalité. Les « gros fichiers » sont stockés directement sur le disque plutôt que dans la base de données. La taille maximum d'un « Gros fichier » est normalement plus grande que la taille maximum d'un fichier joint normal. Quel que soit le système de stockage utilisé, un administrateur peut supprimer à tout moment ces fichiers. Néanmoins, si ces fichiers sont stockés dans la base de données, le paramètre « allow_attachment_deletion » (qui est désactivé par défaut) doit être activé pour pouvoir les supprimer. Également, vous pouvez saisir l'URL qui pointe vers le fichier plutôt que de le télécharger vers le serveur. Par exemple, ceci est utile si vous voulez pointer vers une application externe, un site Web ou un très gros fichier. Notez qu'il n'y a pas de garantie que le fichier source soit toujours disponible ni que son contenu reste inchangé. Un autre moyen de joindre des données est de coller du texte directement dans le champ texte, et Bugzilla le convertira en fichier joint. C'est très pratique quand vous faites du copier-coller et que vous ne voulez pas mettre le texte dans un fichier temporaire d'abord. 5.7.1. Visionneuse de fichiers L'affichage et la revue des correctifs dans Bugzilla sont souvent difficiles à cause du manque de contexte, d'un format incorrect et des problèmes de lisibilités inhérents que les correctifs en texte brut présentent. La visionneuse de fichiers est une amélioration de Bugzilla conçue pour corriger cela en offrant un contexte amélioré, des liens vers les sections et l'intégration à Bonsai, LXR et CVS. La visionneuse de fichiers vous permet : De voir les correctifs en couleurs, avec une vue côte-à-côte plutôt que d'essayer d'interpréter le contenu du correctif. De voir les différences entre deux correctifs. D'obtenir un contexte plus étendu dans un correctif. De réduire et de développer des sections dans un correctif pour une lecture facile. De faire un lien vers une section particulière d'un correctif pour une discussion ou une revue. D'aller dans Bonsai ou LXR pour voir plus de contexte, le responsable d'une ligne de code et les références croisées pour la partie du correctif que vous regardez. De créer un diff au format unifié à partir de n'importe quel correctif, quel que soit son format d'origine. 5.7.1.1. Affichage des correctifs dans la visionneuse de fichiers Le principal moyen d'afficher un correctif dans la visionneuse est de cliquer sur le lien « Diff » à côté du correctif dans la liste des fichiers joints d'un bogue. Vous pouvez aussi faire cela dans la fenêtre « Détails du fichier joint » en cliquant sur le bouton « Afficher le fichier joint comme un fichier diff ». 5.7.1.2. Afficher les différences entre deux correctifs Pour afficher les différences entre deux correctifs, vous devez d'abord afficher le correctif le plus récent dans la visionneuse. Puis sélectionner le correctif plus ancien dans la liste déroulante en haut de la page (« Différences entre [liste déroulante] et ce correctif ») et cliquez sur le bouotn « Diff ». Ceci affichera ce qui est nouveau ou modifié dans le nouveau correctif. 5.7.1.3. Obtenir plus de contexte dans un correctif Pour obtenir plus de contexte dans un correctif, saisissez un nombre dans la boîte de texte en haut de la visionneuse de fichiers (« Correctif / Fichier / [boîte de texte] ») et appuyez sur la touche « Entrée ». Cela vous donnera le nombre de ligne de contexte que vous avez saisi dans la boîte de texte avant et après chaque changement. Vous pouvez aussi cliquer sur le lien « Fichier » et il affichera chaque changement dans le contexte complet du fichier. Cette fonctionnalité ne fonctionne qu'avec les fichiers qui ont été générés avec la commande cvs diff. 5.7.1.4. Réduire et développer les sections d'un correctif Pour ne voir que certains fichiers dans un correctif (par exemple, si un correctif est vraiment très gros et que vous ne voulez faire la revue que d'une seule partie à la fois) vous pouvez cliquer sur les liens « (+) » et « (-) » à côté de chaque fichier (pour les développer ou les réduire). Si vous voulez réduire ou développer tous les fichiers, vous pouvez cliquer sur les liens « Tout réduire » et « Tout développer »en haut de la page. 5.7.1.5. Faire un lien vers une section d'un correctif Pour faire un lien vers une section d'un correctif (par exemple, si vous voulez être en mesure de donner à quelqu'un une URL qui montre la partie dont vous parlez), cliquez simplement sur le lien « Lier ici » dans l'en-tête de section. L'URL résultante peut alors être copiée et utilisée dans une discussion. 5.7.1.6. Se rendre dans Bonsai et LXR Pour vous rendre dans Bonsai pour savoir qui est l'auteur des lignes de code (blame) qui vous intéressent, vous pouvez cliquer sur le lien « Lignes XX-YY » dans l'en-tête de section qui vous intéresse. Ceci fonctionne même si le correctif concerne une ancienne version du fichier car Bonsai stocke toutes les versions du fichier. Pour vous rendre dans LXR, cliquez sur le nom du fichier dans l'en-tête de fichier (malheureusement, puisque LXR n'utilise que la version la plus récente, les numéros de lignes ne correspondront probablement pas). 5.7.1.7. Création d'un diff unifié Si le correctif n'est pas dans le format que vous désirez, vous pouvez le transformer en format diff unifié en cliquant sur le lien « Brut unifié » en haut de la page. 5.8. Trucs et astuces Cette section fournit des astuces et les bonnes pratiques pour Bugzilla qui ont été développées. 5.8.1. Hyperlien automatique Les commentaires dans Bugzilla sont en texte brut : saisir produira <, U, > plutôt que du texte souligné. Cependant, Bugzilla fera automatiquement des hyperliens pour certaines parties du texte des commentaires. Par exemple, le texte « http://www.bugzilla.org » sera transformé en hyperlien : http://www.bugzilla.org. D'autres chaînes peuvent être transformées en lien : bogue 12345 commentaire 7 bogue 23456, commentaire 53 attachment 4321 mailto:georges@exemple.com georges@exemple.com ftp://ftp.mozilla.org La plupart des autres types d'URL Le corollaire ici, c'est que si vous saisissez un numéro de bogue dans un commentaire, vous devez mettre le mot « bogue » devant pour qu'il soit transformé en hyperlien pour la commodité des autres. 5.8.2. Commentaires Si vous changez les champs d'un bogue, ne faites de commentaire que si vous avez quelque chose de pertinent à dire ou que Bugzilla impose que vous le fassiez. Dans le cas contraire, vous spammeriez les gens inutilement avec des courriels de bogues. Pour prendre un exemple : un utilisateur peut définir ses préférences pour filtrer les messages pour ne pas recevoir de courriel quand quelqu'un s'ajoute dans la liste « Copie à » d'un bogue (ce qui arrive souvent). Si vous vous ajouter à la liste « Copie à » et que vous ajouter un un commentaire disant « Je m'ajoute dans la liste Copie à », alors cette personne recevra un courriel sans intérêt qu'elle n'aurait pas reçu autrement. N'utilisez pas de signature dans les commentaires. Signer avec votre prénom (« Jean ») est acceptable, si vous le faites par la force de l'habitude, mais des signatures complètes de style courriel ou liste de diffusion avec quatre lignes d'« ASCII art » ne le sont pas. 5.8.3. Formatage des commentaires du côté du serveur Bugzilla stocke les commentaires sous forme non formatée et les formate lors de leur affichage. Ceci permet d'assurer un formatage correct dans tous les navigateurs. Les lignes commençant par le caractère « > » sont traitées comme des citations et ne sont pas formatées. 5.8.4. Arbre de dépendance sur la page « Arbre dedépendance » liée à partir de chaque page de bogue, vous pouvez voir les relations de dépendances du bogue sous forme de structure arborescente. Vous pouvez modifier la profondeur à afficher et vous pouvez masquer les bogues résolus dans cette page. Vous pouvez aussi réduire ou développer les dépendances pour chaque bogue dans la vue arborescente, en utilisant les boutons [-] ou [+] qui apparaissent avant son résumé. Cette option n'est pas disponible pour les bogues terminaux de l'arbre (qui n'ont pas d'autres dépendances). 5.9. Informations d'horodatage Les utilisateurs qui appartiennent au groupe spécifié par le paramèter « timetrackinggroup » ont accès aux champs relatifs au temps. Les développeurs peuvent voir les dates limites et les estimation de temps pour corriger les bogues, et peuvent fournir le temps passé sur ces bogues. À tout moment, un résumé du temps passé par les développeurs sur les bogues est accessible à partir des listes de bogues en cliquant sur le bouton « Résumé du temps passé » ou dans chaque bogue individuellement en cliquat sur le lien « Résumé du temps passé » dans le tableau d'horodatage. La page summarize_time.cgi vous permet de voir ces informations soit par développeur, soit par bogue, et peut être divisé par mois pour avoir plus de détails sur le temps passé par les développeurs. Dès qu'un bogue est marqué RÉSOLU, le temps restant estimé pour corriger le bogue est défini à zéro. Ceci permet aux personnes de l'assurance qualité de le définir à nouveau pour leur propre usage, et il sera de nouveau défini à zéro quand le bogue sera marqué FERMÉ. 5.10. Préférences utilisateur Une fois connecté, vous pouvez personnaliser différents aspects de Bugzilla en cliquant sur le lien « Préférences » dans le pied de page. Les préférences sont divisées en cinq volets : 5.10.1. Préférences générales Cet onglet vous permet de modifier plusieurs paramètres par défaut de Bugzilla. * Apparence générale de Bugzilla - Sélectionne le thème à utiliser. Bugzilla gère l'ajout de thèmes personnalisés. * Citer le commentaire associé lors du clic sur son lien de réponse - Définit le comportement du lien « répondre » dans les commentaires. Les options permettent de citer le commentaire complet, d'indiquer seulement le numéro du commentaire ou de désactiver le lien. * Langue utilisée dans les courriels - Sélectionne la langue dans laquelle les courriels envoyés seront écrits, dans la liste des langues disponibles. * Après avoir changé un bogue - Permet de contrôler quelle page est affichée après la soumission de changements sur un bogue. Les options permettent : d'afficher le bogue juste modifié, d'afficher le bogue suivant de votre liste, ou de ne rien faire du tout. * Agrandir les champs de texte lorsqu'on écrit dedans (requiert JavaScript) - Active ou désactive l'extension automatique des zones de texte quand on y saisit du texte. * Séparateur de champ dans les fichiers CSV - Permet de choisir entre une virgule ou un point-virgule pour l'export des listes de bogues en format CSV. * M'ajouter automatiquement à la liste « Copie à » des bogues que je modifie - Définit le comportement par défaut de la liste « Copie à ». Les options sont : « Toujours », « Jamais » et « Seulement si ne ne joue pas déjà un rôle ». * En visionnant un bogue, afficher les commentaires dans cet ordre - Contrôle l'ordre d'affichage des commentaires. Les options sont « Du plus ancien au plus récent », « Du plus récent au plus ancien » et « Du plus récent au plus ancien, mais après la description ». * Afficher une citation en haut de chaque liste de bogues - Définit si une citation sera affichée dans la liste de bogues. 5.10.2. Préférences de messagerie Cet onglet permet d'activer ou de désactiver la notification par courriel en fonction d'événements spécifiques. En général, les utilisateurs ont pratiquement tout contrôle sur la quantité de courriels que Bugzilla leur envoie. si vous voulez recevoir le maximum de courriels possible, cliquez sur le bouton « Activer tous les courriels ». Si vous ne voulez pas recevoir de courriels du tout de la part de Bugzilla, cliquez sur le bouton « Désactiver tous les courriels ». [Note] Un administrateur de Bugzilla peut empêcher un utilisateur de recevoir des courriels de bogues en cliquant sur la case « Envoi des courriels de bogues désactivé » lors de l'édition d'un compte utilisateur. C'est une décision drastique qui ne devrait être prise que pour les comptes désactivés, car cela outrepasse les préférences de messagerie individuelles de l'utilisateur. Il y a deux options globales : « Envoyer un courriel quand quelqu'un me demande de définir une étiquette » et « Envoyer un courriel quand quelqu'un a défini une étiquette que j'avais demandée ». Celles-ci définissent la réception de courriels en fonction des étiquettes. Leur utilisation est simple ; sélectionnez les cases à cocher si vous voulez que Bugzilla vous envoie des courriels pour l'une ou l'autre des conditions. Si vous voulez paramétrer votre courriel de bogues pour quelque chose entre « Tous les courriels » et « Aucun courriel », le tableau « Options spécifiques du champ/destinataire » vous permet de faire cela. Les lignes du tableau définissent les événements qui peuvent arriver à un bogue -- des choses comme : un fichier a été joint, de nouveaux commentaires ont été faits, la priorité à changé, etc. Les colonnes du tableau définissent votre relation avec le bogue : * Rapporteur -Où vous êtes la personne qui a initialement rapporté le bogue. Votre nom/compte apparaît dans le champ « Rapporteur : ». * Responsable - Où vous êtes la personne qui a été désignée comme responsable du bogue. Votre nom/compte apparaît dans le champ « Assigné à : » du bogue. * Contact QA - Vous êtes le contact QA désigné pour le bogue. Votre compte apparaît dans le champ « Contact QA : » du bogue. * En copie- Vous êtes dans la liste « Copie à » du bogue. votre compte apparaît dans la boîte de texte « Copie à : » du bogue. * Votant - Vous avez placé un ou plusieurs votes sur le bogue. Votre compte apparaît seulement si quelqu'un clique sur le lien « Afficher les votes pour ce bogue » dans le bogue. [Note] Certaines colonnes peuvent ne pas être visibles sur votre installation en fonction de la configuration de votre site. Pour affiner la gestion de la quantité de courriels de bogues, décidez des événements pour lesquels vous voulez recevoir des courriels de bogues ; décidez ensuite si vous voulez les recevoir tout le temps (cochez alors la case dans chaque colonne), ou seulement lorsque vous avez une certaine relation avec un bogue (cochez la case pour ces colonnes seulement). Par exemple : si vous ne voulez pas recevoir de courriel quand quelqu'un s'ajoute à la liste « Copie à », vous pouvez décocher toutes les cases dans la ligne « Le champ “Copie à :” est modifié ». Comme autre exemple, si vous ne voulez jamais recevoir de courriel sur les bogues que vous avez rapportés à moins qu'ils ne soient résolus, vous devez décocher toutes les acses de la colonne « Rapporteur » sauf celle sur la ligne « Le bogue est résolu ou rouvert ». [Note] Bugzilla ajoute l'en-tête « X-Bugzilla-Reason » à tous les courriels qu'il envoit, décrivant la relation du destinataire (Assigné à, Rapporteur, Contact QA, Copie à ou Votant) au bogue. Cet en-tête peut être utilisé pour affiner le filtrage du côté client. Bugzilla a une fonctionnalité appelée « Surveillance d'utilisateurs ». Quand vous saisissez un ou plusieurs comptes utilisateurs séparés par des virgules (généralement des adresses électroniques) dans la boîte de texte, vous recevez une copie de tous les courriels de bogues envoyés à ces utilisateurs (en fonction des paramètres de sécurité). Cette fonctionnalité puissante permet des transitions en douceur lorsque les développeurs changent de projet ou lorsque les utilisateurs partent en vacances. [Note] La possibilité de surveiller d'autres utilisateurs peut ne pas être disponible dans toutes les installations de Bugzilla. Si vous ne voyez pas cette focntionnalité et que vous en avez besoin, parlez-en à votre administrateur. Tous les utilisateurs indiqués dans le champ « Utilisateurs vous surveillant » vous ont ajoutés dans leur liste « Surveillance d'utilisateur » et peuvent obtenir des courriels de bogues en fonction de votre relation avec le bogue et leurs paramètres « Options spécifiques du champ/destinataire ». 5.10.3. Recherches enregistrées Dans ce volet, vous pouvez voir et exécuter toutes recherches enregistrées que vous avez créées, et aussi toutes autres recherches enregistrées partagées par d'autres membres du groupe défini par le paramètre « querysharegroup ». Les recherches enregistrées peuvent être ajoutées au pied de page à partir de cet écran. Si quelqu'un partage une recherche avec un groupe, il sera autorisé à y assigner des utilisateurs. La personne qui partage la recherche peut choisir de faire afficher la recherche dans le pied de page des membres directs du groupe par défaut. 5.10.4. Préférences du compte Sur cet onglet, vous pouvez changer les informations de base de votre compte, y compris votre mot de passe, votre adresse électronique et votre vrai nom. Pour des raisons de sécurité, pour modifier quelque chose sur cette page, vous devez saisir votre mot de passe actuel dans le champ « Mot de passe » au sommet de la page. Si vous tentez de modifier votre adresse électronique, un courriel de confirmation est envoyé sur l'ancienne et la nouvelle adresses, contenant un lien pour confirmer le changement. Ceci aide à empêcher le piratage de compte. 5.10.5. Permissions C'est une page purement informative qui souligne vos permissions actuelles sur cette installation de Bugzilla. Vous trouverez une liste complète des permissions ci-dessous. Seuls les utilisateurs ayant des privilèges editusers peuvent modifier les permissions d'autres utilisateurs. admin Indique que l'utilisateur est un administrateur. bz_canusewhineatothers Indique que l'utilisateur peut configurer les rapports de notifications pour d'autres utilisateurs. bz_canusewhines Indique que l'utilisateur peut configurer les rapports de notifications pour lui-même. bz_quip_moderators Indique que l'utilisateur peut modérer les citations. bz_sudoers Indique que l'utilisateur peut accomplir des actions à la place d'autres utilisateurs. bz_sudo_protect Indique d'autres utilisateurs ne peuvent pas se faire passer pour cet utilisateur. canconfirm Indique que l'utilisateur peut confirmer un bogue ou le marquer comme doublon. creategroups Indique que l'utilisateur peut créer ou détruire des groupes. editbugs Indique que l'utilisateur peut modifier tous les champs d'un bogue. editclassifications Indique que l'utilisateur peut créer, détruire et modifier des classements. editcomponents Indique que l'utilisateur peut créer, détruire et modifier des composants. editkeywords Indique que l'utilisateur peut créer, détruire et modifier des mots-clés. editusers Indique que l'utilisateur peut modifier ou désactiver des utilisateurs. tweakparams Indique que l'utilisateur peut modifier les Paramètres. [Note] Pour plus d'informations sur le fonctionnement des permissions dans Bugzilla (c-à-d. qui peut modifier quoi), consulter Section 6.4, « Personnaliser qui peut changer quoi ». 5.11. Rapports et graphiques En plus de la liste de bogues standard, Bugzilla dispose deux autres moyens pour afficher un ensemble de bogues. Ce sont les rapports (qui donnent différentes vue de l'état actuel de la base de données) et les graphiques (qui tracent les changements dans des ensembles de bogues particuliers en fonction du temps). 5.11.1. Rapports Un rapport est une vue de l'état actuel de la base de données. Vous pouvez obtenir des rapports sous forme de tableaux HTML ou sous forme graphique avec des diagrammes linéaires, circulaires ou des histogrammes. Ils ont chacun une page distincte pour leur paramètrage, mais ce sont de proches cousins. Une fois que vous avez défini et affiché un rapport, vous pouvez basculer entre les différentes vues à volonté. Les deux types de rapport sont basés sur l'idée d'une définition d'un ensemble de bogues en utilisant l'interface de recherche standard et en choisissant certains aspects de cet ensemble à tracer sur les axes horizontal et/ou vertical. Vous pouvez aussi obtenir une forme de rapport en trois dimensions en choisissant d'avoir de multiples images ou tableaux. Vous pouvez par exemple utiliser le formulaire de recherche pour choisir « Tous les bogues du produit ContrôleDuMonde » et tracer leur gravité en fonction de leur composant pour voir quel composant a eu a eu le plus grand nombre de bogues critiques rapportés. Quand vous avez défini vos paramètres et que vous cliquez sur « Générer le rapport », vous pouvez basculer entre les formats HTML, CSV, histogramme, linéaire et circulaire. (Note : les diagrammes circulaires ne sont disponibles que si vous n'avez pas défini d'axe vertical car les diagrammes circulaires n'en ont pas). Les autres contrôles s'expliquent d'eux-mêmes ; vous pouvez changer la taille de l'image si vous trouvez que les textes se superposent ou si les barres d'histogrammes sont trop fines. 5.11.2. Graphiques Un graphique est une vue de l'état de la base de données en fonction du temps. Bugzilla dispose actuellement de deux systèmes de graphiques. Les « Anciens graphiques » et les « Nouveaux graphiques ». Les anciens graphiques font partie de Bugzilla depuis longtemps ; ils tracent chaque état et résolution pour chaque produit et c'est tout. Ils sont obsolètes et vont bientôt disparaître. Nous n'en dirons pas plus à leur sujet. Les nouveaux graphiques sont le futur. Ils vous permettent de tracer tout ce que vous pouvez définir comme recherche. [Note] Les deux types de rapports nécessitent que l'administrateur définisse le script de rassemblement de données. Si vous ne pouvez pas voir les graphiques, demandez-lui s'il a exécuté le script. Une ligne individuelle sur un rapport est appelé collection. Toutes les collections sont organisées en catégories et sous-catégories. Les collections que définit automatiquement Bugzilla utilisent le nom de produit comme catégorie et les noms de composants comme sous-catégories, mais il n'est pas obligatoire pour vous de suivre cette norme de nommage avec vos rapports si vous ne le voulez pas. Les collections peuvent être publiques ou privées. Tout le monde peut voir les collections publiques dans la liste, mais les collections privées ne peuvent être vues que par leurs créateurs. Seuls les administrateurs peuvent rendre les collections publiques. Il ne peut y avoir deux collections, même privées, ayant le même ensemble de catégorie, sous-catégorie et nom. Donc, si vous créez des collections privées, une idée est d'avoir la catégorie qui s'intitule comme votre nom d'utilisateur. 5.11.2.1. Création de graphiques Vous créez un graphique en sélectionnant un nombre de collections dans la liste et en cliquant sur le bouton « Ajouter à la liste » pour chacune. Dans la liste des collections à tracer, vous pouvez définir le libellé que portera la collection dans la légende du graphique, et demander aussi à Bugzilla d'additionner un certain nombre de collections (par exemple, vous pouvez additionner les collections représentant les bogues RÉSOLUS, VÉRIFIÉS et FERMÉS dans un produit en particulier pour obtenir une collection représentant tous les bogues résolus dans un produit). Si vous avez ajouté par erreur une collection à la liste, sélectionnez-la en cochant la case et cliquez sur « Supprimer ». Quand vous avez ajouté plus d'une collection, une ligne « Grand total » apparaît automatiquement an bas de la liste. Si vous ne la voulez pas, supprimez-la comme vous supprimeriez toute autre ligne. Vous pouvez aussi choisir de créer un graphique sur une certaine période et de cumuler les résultats, c'est-à-dire de tracer chacun en utilisant le précédent comme base, de sorte que la première ligne donne la somme de toutes les collections. Il est plus facile d'essayer que de l'expliquer :-) Quand une collection est dans la liste, on peut réaliser certaines actions dessus. Par exemple, éditer les paramètres de la collection (nom, fréquence, etc.) si vous l'avez créée ou si vous êtes administrateur. Quand vous êtes satisfait, cliquez sur « Générez ce rapport » pour voir le graphique. 5.11.2.2. Création de nouvelles collections Vous pouvez aussi créer vos propres collections. Pour faire cela, cliquez sur le lien « Créer un nouveau jeux de données » sur la page de création de graphiques. Ceci vous amène sur une interface de recherche où vous pouvez définir la recherche que Bugzilla tracera. Au bas de la page, choisissez la catégorie, la sous-catégorie et le nom de votre nouvelle collection. Si vous avez les droits suffisants, vous pouvez rendre cette collection publique et augmenter la fréquence de collecte des données à moins de sept jours, qui est la valeur par défaut. 5.12. Étiquettes Une étiquette est une sorte d'état qui peut être défini sur les bogues ou les fichiers joints pour indiquer qu'ils sont dans un certain état. Chaque installation peut définir son propre ensemble d'étiquettes. Si sur votre installation est définie une étiquette, vous pouvez définir ou enlever une étiquette, et si votre administrateur a activé les requêtes d'étiquettes, vous pouvez soumettre une demande à un autre utilisateur pour qu'il définisse l'étiquette. Pour définir une étiquette, sélectionnez soit « + », soit « - » dans le menu déroulant à côté du nom de l'étiquette dans la liste « Étiquettes ». La signification de ces valeurs sont spécifiques à l'étiquette et ne peuvent par conséquent être décrites dans cette documentation. À titre d'exemple, définir une étiquette intitulée « revue » à « + » peut indiquer que le bogue ou le fichier joint a été approuvé, alors que « - » peut indiquer que le bogue ou le fichier joint a été refusé. Pour enlever une étiquette, cliquez sur le menu déroulant et sélectionnez la valeur vide. Notez que marquer un fichier joint comme obsolète annule automatiquement toutes les requêtes en attente pour le fichier joint. Si votre administrateur a activé les requêtes d'étiquettes, demandez une étiquette en sélectionnant « ? » dans le menu déroulant et saisissez le nom de l'utilisateur à qui vous demandez l'étiquette dans le champ de texte à côté du menu. Une étiquette apparaît dans les rapports de bogues et sur les pages de détails des fichiers joints avec le nom de l'utilisateur qui a défini l'étiquette abrégé. Par exemple, si Jack définit l'étiquette « revue » à « + », il apparaîtra comme « Jack: revue [ + ] » A requested flag appears with the user who requested the flag prepended to the flag name and the user who has been requested to set the flag appended to the flag name within parentheses. For example, if Jack asks Jill for review, it appears as Jack: review [ ? ] (Jill). Vous pouvez naviguer dans les requêtes en attente qui vous sont demandées ou que vous avez demandées en sélectionnant « Mes requêtes » dans le pied de page. Vous pouvez aussi y voir celles demandées par d'autres ou à d'autres, par produit, composant et nom d'étiquette dans cette page. Notez que vous pouvez utiliser « - » pour spécifier des étiquettes n'ayant pas de nom d'utilisateur dans le champ « Demandé à ». 5.13. Notifications Les notifications sont une fonctionnalité de Bugzilla qui peut venir ennuyer régulièrement les utilisateurs à des moments spécifiés. En utilisant cette fonctionnalité, les utilisateurs peuvent exécuter des recherches enregistrées à des moments spécifiques (c-à-d. le 15 du mois à minuit) ou à intervalles réguliers (c-à-d. toutes les 15 minutes le dimanche). Les résultats de la recherche sont envoyés à l'utilisateur, soit dans un seul courriel, soit un courriel par bogue, accompagné d'un texte descriptif. [Avertissement] Dans cette section, il sera supposé que tous les utilisateurs sont membres du groupe « bz_canusewhines », appartenance de groupe nécessaire pour pouvoir utiliser le système de notifications. Vous pouvez facilement rendre tous les utilisateurs membres du groupe « bz_canusewhines » en définissant l'expression régulière d'utilisateur à « .* » (sans les guillemets). Il est important aussi de mentionner le groupe « bz_canusewhineatothers ». Les membres de ce groupe peuvent créer des notifications pour tout utilisateur ou groupe dans Bugzilla en utilisant un formulaire étendu dans l'interface des notifications. Les fonctionnalités seulement disponibles pour les membres du groupe « bz_canusewhineatothers » seront notées aux endroits appropriés. [Note] Pour que les notifications fonctionnent, un script Perl spécial doit être exécuté à intervalles réguliers. Plus de détails sont disponibles dans Section 2.3.3, « Notifications ». [Note] Cette section ne couvre pas le script whineatnews.pl. Consultez Section 2.3.2, « Les notifications programmées » pour plus d'informations sur la programmation des notifications. 5.13.1. Évènement Le système de notifications définit un « événement » comme une ou plusieurs requêtes exécutées à intervalles réguliers, dont les résultats (s'il y en a) sont envoyées par courriel à l'utilisateur. Les événements sont créés en cliquant sur le bouton « Ajouter un événement ». Quand le nouvel événement est créé, la première chose à faire est de définir la « Ligne de sujet du courriel ». Le contenu de ce champ sera utilisé dans le sujet de tous les courriels générés par cet événement. En plus du paramétrage de la ligne du sujet, un emplacement est prévu pour saisir un description qui sera incluse au début de chaque message (pour indiquer pourquoi vous recevez ce courriel). L'étape suivante consiste à indiquer quand l'événement doit être exécuté (« Programmation ») et quelles recherches doivent être faites (« Requêtes »). 5.13.2. Programmation des notifications Chaque événement de notification est associé à zéro ou plus programmations. Une programmation est utilisée pour indiquer quand la requête (spécifiée dessous) doit être exécutée. Un nouvel événement est créé sans programmation (ce qui signifie qu'il ne sera jamais exécuté, car il n'est pas programmé). Pour ajouter une programmation, cliquez sur le bouton « Ajouter une nouvelle programmation ». Chaque programmation utilise un intervalle que vous utilisez pour dire à Bugzilla quand l'événement doit être exécuté. Un événement peut être exécuté certains jours de la semaine, certains jours du mois, pendant les jours ouvrables (du lundi au vendredi) ou chaque jour. [Avertissement] Faites attention si vous définissez votre événement pour qu'il soit exécuté le 29, le 30 ou le 31 du mois, car il pourrait ne pas s'exécuter exactement comme prévu. Si vous voulez que votre événement s'exécute le dernier jour du mois, sélectionnez l'intervalle « Le dernier jour du mois ». Quand vous avez spécifié le ou les jours pendant lesquels l'événement doit être exécuté, vous devez alors indiquer l'heure de l'exécution de l'événement. Vous pouvez exécuter l'événement à une certaine heure du ou des jours spécifiés, ou chaque heure, demie-heure ou quart d'heure du ou des jours spécifiés. Si une programmation ne s'exécute pas aussi souvent que vous le voudriez, vous pouvez créer une autre programmation pour le même événement. Par exemple, si vous voulez exécuter un événement les jours dont les dates sont divisible par sept, vous devrez ajouter quatre programmations à l'événement, déclenchées les 7, 14, 21 et 28 du mois (un jour par programmation) à l'heure ou à chaque intervalle de temps choisi. [Note] Si vous êtes membre du groupe « bz_canusewhineatothers », vous aurez alors une option supplémentaire : « Envoyer à ». En utilisant ceci, vous pouvez contrôler qui recevra les courriels générés par cet événement. Vous pouvez choisir d'envoyer les courriels à un seul utilisateur (identifié par l'adresse électronique) ou à un groupe (identifié par le nom du groupe). Pour envoyer les courriels à plusieurs utilisateurs ou groupes, créez une nouvelle programmation pour chaque utilisateur ou groupe supplémentaire. 5.13.3. Requêtes de notifications Chaque notification est associée à zéro ou plus requêtes. Une requête est toute recherche enregistrée à exécuter dans la programmation spécifiée (voir plus haut). Un nouvel événement est créé sans requête associée (ce qui signifie que l'événement ne sera jamais exécuté car il n'y aura jamais de résultats à renvoyer). Pour ajouter une requête, cliquez sur le bouton « Ajouter une nouvelle requête ». Le premier champ à examiner dans votre nouvelle requête ajoutée est le champ « Ordre ». Les requêtes sont exécutées et les résultats inclus dans l'ordre indiqué par le champ « Ordre ». Les requêtes ayant des valeurs faibles pour le champ « Ordre » seront exécutées avant celles ayant des valeurs élevées pour ce champ. Le champ suivant à examiner est le champ « Requête ». C'est l'endroit où vous choisissez la requête à exécuter. Plutôt que de définir les paramètre de recherche ici, il vous est demandé de choisir dans la liste des recherches enregistrées (la même liste apparaît dans le pied de chaque page de Bugzilla). Vous n'êtes autorisé à choisir que les recherches que vous avez enregistré vous-même (le recherche enregistrée par défaut, « Mes bogues » n'est pas un choix valide). Si vous n'avez pas de recherches enregistrées, profitez de cette opportunité pour en créer une (voir Section 5.5.4, « Listes des bogues »). [Note] Lors de l'exécution des requêtes, le système de notifications agit comme si vous étiez l'utilisateur exécutant la requête. Ce qui signifie que le système de notifications ignorera les bogues correspondant à votre requête pour lesquels vous n'avez pas d'accès. Quand vous avez choisi la recherche enregistrée à exécuter, donnez à la requête un titre descriptif. Ce titre apparaîtra dans le courriel, au-dessus des résultats de la requête. Si vous choisissez « Un message par bogue », le titre de la requête apparaîtra en haut de chaque courriel qui contient un bogue correspondant à votre requête. Enfin, décidez si les résultats de votre requête doivent être envoyés dans un seul courriel ou si chaque bogue doit apparaître dans son propre courriel. [Avertissement] Réfléchissez soigneusement avant de cocher la case « Un message par bogue ». Si vous créez une requête qui correspond à des milliers de bogues, vous recevrez des milliers de courriels ! 5.13.4. Enregistrement des modifications Quand vous avez terminé de définir une programmation et de créer au moins une recherche enregistrée, cliquez sur le bouton « Mettre à jour/Appliquer ». Ceci enregistrera votre événement et le rendra disponible pour une exécution immédiate. [Note] Si vous voulez supprimer un événement, vous pouvez le faire en utilisant le bouton « Supprimer l'événement » dans le coin supérieur droit de chaque événement. Vous pouvez aussi modifier un événement existant en cliquant sur le bouton « Mettre à jour/Appliquer » après avoir terminé vos modifications. Chapitre 6. Personnaliser Bugzilla Table des matières 6.1. Extensions Bugzilla 6.2. Thèmes personnalisés 6.3. Personnaliser des modèles 6.3.1. Struvture de répertoires des modèlesTemplate 6.3.2. Choisir une méthode de personnalisation 6.3.3. Comment modifier les modèles 6.3.4. Types et formats de modèles 6.3.5. Modèles particuliers 6.3.6. Configurer Bugzilla pour détecter la langue de l'utilisateur 6.4. Personnaliser qui peut changer quoi 6.5. Intégration de Bugzilla avec des outils tiers 6.1. Extensions Bugzilla Un des meilleurs moyens de personnaliser Bugzilla est d'écrire une extension Bugzilla. Les extensions Bugzilla vous permettent de modifier le code et l'interface utilisateur de façon à ce qu'elles puissent être distribuées à d'autres utilisateurs de Bugzilla et adaptées à de futures versions de Bugzilla avec un minimum d'effort. Consulter la documentation des extensions de Bugzilla pour des informations sur la manière d'écrire une extension. 6.2. Thèmes personnalisés Bugzilla permet d'avoir plusieurs thèmes. Ce sont des CSS et des images personnalisés pour Bugzilla. Pour créer un nouveau thème, vous avez deux possibilités : * Faire un seul fichier CSS et le mettre dans le répertoire skins/contrib. * Créer un répertoire qui contient les mêmes noms de fichiers de CSS que dans le répertoire skins/standard/, et mettez votre répertoire dans le répertoire skins/contrib/. Après avoir mis le fichier ou le répertoire ici, assurez-vous d'exécuter checksetup.pl pour qu'il puisse définir les permissions de fichiers correctement. Après avoir installé le nouveau thème, il apparaîtra comme une option dans les préférences générales de l'utilisateur. Si vous voulez imposer un thème particulier à tous les utilisateurs, sélectionnez-le dans les préférences par défaut et décoché « Activé » sur la préférence. 6.3. Personnaliser des modèles Les administrateurs peuvent configurer l'apparence de Bugzilla sans avoir à modifier les fichiers Perl ou faire face à des conflits massifs lors d'une future mise à jour. Les modèles permettent aussi de faire des versions localisées de Bugzilla, pour la première fois. Il est possible d'avoir la langue de l'interface de Bugzilla déterminée par le navigateur de l'utilisateur. D'autres informations sont disponibles sur Section 6.3.6, « Configurer Bugzilla pour détecter la langue de l'utilisateur ». 6.3.1. Struvture de répertoires des modèlesTemplate La structure des répertoires des modèles démarre au répertoire racine nommé template, qui contient un répertoire pour chaque langue installée. Le niveau suivant définit la langue utilisée dans les modèles. Bugzilla est livré avec les modèles en anglais, donc le répertoire s'appelle en, et nous discuterons du répertoire template/en tout au long de la documentation. Dans le répertoire template/en se trouve le répertoire default qui contient tous les modèles standards livrés avec Bugzilla. [Avertissement] Un répertoire data/templates existe aussi ; c'est l'endroit où « Template Toolkit » met les versions compilées des modèles du répertoire par défaut ou des répertoires personnalisés. Ne modifiez pas ces fichiers de ce répertoire directement, ou tous vos changements seront perdus la prochaine fois que « Template Toolkit » recompilera les modèles. 6.3.2. Choisir une méthode de personnalisation Si vous voulez modifier les modèles de Bugzilla, La première décision que vous devrez prendre est la façon dont vous voulez procéder. Il y a deux choix qui dépendent pricipalement de la portée de vos modifications et de la méthode que vous prévoyez d'utiliser pour mettre à jour Bugzilla. La première méthode de personnalisation est de modifier directement les modèles situés dans template/en/default. Ceci est probablement la meilleure méthode si vous projetez de mettre à jour Bugzilla par Bzr, car si vous exécutez une commande bzr update, tous les changements que vous avez faits seront automatiquement fusionnés avec les versions mises à jour. [Note] Si vous utilisez cette méthode et que des conflits Bzr surviennent pendant la mise à jour, les modèles en conflit (et peut-être d'autres parties de votre installation) ne fonctionneront pas jusqu'à ce que les conflits soient résolus. La seconde méthode est de copier les modèles à modifier dans structure de répertoire miroir dans template/en/custom. Les modèles dans cette structure de répertoires écrasent automatiquement ceux dont le nom et l'emplacement sont identiques dans le répertoire default. [Note] Le répertoire custom n'existe pas, vous devez le créer si vous voulez l'utiliser. La deuxième méthode doit être utilisée si vous utilisez la méthode de mise à jour qui remplace les fichiers, sinon vos changements seront perdus. Cette méthode peut être meilleure si vous utilisez la mise à jour par Bzr et que vous allez faire des changements majeurs, car il est garanti que le contenu de ce répertoire ne sera pas modifié pendant une mise à jour et vous pouvez décider alors si vous continuez à utiliser vos propres modèles ou si vous faites l'effort de fussionner vos changements dans les nouvelles versions manuellement. En utilisant cette méthode, votre installation peut ne plus fonctionner si des changements incompatibles sont faits à l'interface des modèles. De tels changements devraient être documentés dans les notes de version, pourvu que vous utilisiez une version stable de Bugzilla. Si vous utilisez une version instable, vous devrez vous débrouillez avec celle-ci vous-même, bien que, si possible, les changements seront mentionnés avant qu'ils n'arrivent dans les notes de version de la version stable précédente. [Note] Quelle que soit la méthode utilisée, il est recommandé d'exécuter le script ./checksetup.pl après la modification de modèles dans le répertoire template/en/default, et après avoir créé ou modifié des modèles dans le répertoire custom. [Avertissement] Il est nécessaire d'exécuter ./checksetup.pl après la création d'un nouveau modèle dans le répertoire custom. Ne pas le faire produira un message d'erreur incompréhensible. 6.3.3. Comment modifier les modèles [Note] Si vous réalisez des changements de modèle que vous comptez renvoyer pour les inclure dans le Bugzilla standard, vous devriez lire les sections appropriées dans le guide des développeurs. La syntaxe du langage « Template Toolkit » n'est pas couverte par ce guide. Il est relativement facile de comprendre en regardant les modèles actuels ; ou vous pouvez lire le manuel, disponible sur la page d'accueil de Template Toolkit. Une chose à laquelle vous devez prêter une attention particulière est le besoin de de filtrer correctement les données HTML qui sont passées par un modèle. Ceci signifie que si les données peuvent contenir des caractère spéciaux HTML comme « < », et que les données ne sont pas destinéees à être de l'HTML, elles doivent alors être converties sous forme d'entités, par ex. « < ». Vous utilisez le filtre « html » dans Template Toolkit pour faire cela (ou le filtre 'uri' pour encoder les caractères spéciaux dans les URLs). Si vous oubliez, vous pourriez ouvrir votre installation à des attaques de scripts de sites croisés. Modifier les modèles est un bon moyen pour personnaliser les champs sans trop d'efforts. Par exemple, si vous n'utilisez pas le « Tableau blanc », mais que vous voulez avoir un champ de saisie de texte libre pour « Identifiant de compilation », alors vous pouvez simplement modifier les modèles pour changer les libellés du champ. Il sera toujours appelé « status_whiteboard » en interne, mais vos utilisateurs n'ont pas besoin de le savoir. 6.3.4. Types et formats de modèles Certains scripts CGI ont la capacité d'utiliser plus d'un modèle. Par exemple, buglist.cgi peut faire des sorties sous forme RDF ou sous deux formats HTML (complexe et simple). Le mécanisme qui produit cette fonctionnalité est extensible. Bugzilla peut gérer différents types de sortie, qui peuvent encore avoir de multiples formats. Pour demander un certain type, vous pouvez ajouter « &ctype= » (comme rdf ou html) à l'URL .cgi. Si vous voulez récupérer un certain format, vous pouvez utiliser « &format= » (comme simple ou complexe) dans l'URL. Pour voir si un script CGI gère de multiples types et formats de sortie, faites un grep du fichier CGI pour rechercher « get_format ». S'il n'est pas présent, ajouter la gestion de multiples formats ou types n'est pas trop dur - regardez comment c'est mis en œuvre dans d'autres scripts CGI, comme par exemple config.cgi. Pour faire un nouveau modèle de format pour un script CGI qui le gère, ouvrez un modèle actuellement utilisé pour ce script CGI et regardez le commentaire « INTERFACE » (s'il existe). Ce commentaire définit quelles variables sont passées dans ce modèle. S'il n'y en a pas, il vous faudra alors lire le modèle et le code pour découvrir les informations que vous obtenez. Écrivez votre modèle avec le langage de balises ou le style de texte approprié. Vous devez maintenant décider le type de contenu que vous voulez que votre modèle serve. Les types de contenu sont définis dans le fichier Bugzilla/Constants.pm dans la constante contenttypes. Si votre type de contenu n'y est pas, ajoutez-le. Souvenez-vous du marqueur de trois ou quatre lettres affecté à votre type de contenu. Ce marqueur fera partie du nom de fichier de votre modèle. [Note] Après avoir ajouter ou modifier le type de contenu, il faut modifier le fichier Bugzilla/Constants.pm afin de refléter les changements. Et aussi, le fichier doit être maintenu à jour après une mise à jour de Bugzilla si les types de contenus ont été personnalisés auparavant. Enregistrez le modèle sous le nom -..tmpl. Essayez le modèles en invoquant le script ainsi : .cgi?format=&ctype= . 6.3.5. Modèles particuliers Il existe quelques modèles qui pourraient particulièrement vous intéresser pour personnaliser votre installation. index.html.tmpl : C'est la page d'accueil de Bugzilla global/header.html.tmpl : Ceci définit l'en-tête qui sera sur toutes les pages de Bugzilla. L'en-tête inclut la bannière, qui s'affiche pour tous les utilisateurs et que vous voudrez certainement modifier. Cependant, l'en-tête contient aussi la section « HTML HEAD », et vous pourriez par exemple y ajouter une feuille de style ou une balise « META » en modifiant l'en-tête. global/banner.html.tmpl : Ceci contient la « bannière », la partie de l'en-tête qui apparaît en haut de toutes les pages de Bugzilla. La bannière par défaut est relativement austère et vous voudrez certainement la personnaliser pour donner à votre installation distincte. il est recommandé de conserver le numéro de version de Bugzilla que vous utilisez de sorte que les utilisateurs sachent quelle documentation consulter. global/footer.html.tmpl : Ceci définit lepied de page de toutes les pages de Bugzilla. Modifier ceci est un autre moyen pour obtenir rapidement une apparence distincte pour votre installation de Bugzilla. global/variables.none.tmpl : Ceci définit la liste des termes qui peuvent être modifiés afin de mettre « à vos couleurs » l'instance Bugzilla. De cette façon, des termes comme « bogues » peuvent être remplacés par « défaut » dans toute l'installation de Bugzilla. Le nom « Bugzilla » et d'autres mots peuvent être personnalisés de la même manière. list/table.html.tmpl : Ce modèle contrôle l'apparence des listes de bogues créées par Bugzilla. Modifier ce modèle permet un contrôle par colonne de la largeur et du titre de la colonne, la longueur maximum d'affichage de chaque entrée et le comportement d'affichage des longues entrées. Pour les longues liste de bogues, Bugzilla insère une « coupure » tous les 100 bogues par défautt ; ce comportement est aussi contrôlé par ce modèle et cette valeur peut être modifiée ici. bug/create/user-message.html.tmpl : C'est le message qui apparaît près du haut de la page de rapport de bogue. En modifiant ceci, vous pouvez dire aux utilisateurs comment rapporter les bogues. bug/process/midair.html.tmpl : C'est la page utilisée i deux utilisateurs soumettent simultanément des changements pour le même bogue. La seconde personne à soumettre les changements obtiendra cette page pour lui indiquer les changements que la première personne a fait, et lui demander si elle souhaite écraser ces changements ou revenir sur la page du bogue. Le titre par défaut et l'en-tête de cette page indiquent « Collision détectée ! ». Si vous travaillez dans l'industrie aéronautique ou d'autres environnements ou ceci pourrait être perçu comme choquant (oui, nous avons des histoires vraies à ce sujet) vous voudrez changer ceci pour quelque chose de plus approprié pour votre environnement. bug/create/create.html.tmpl et bug/create/comment.txt.tmpl : Vous ne souhaitez peut-être pas faire l'effort de créer des champs personnalisés dans Bugzilla, cependant, vous voulez être sûr que chaque rapport de bogue contienne un certain nombre d'éléments d'information importants pour lesquels il n'y a pas un champ spécial. Le système de saisie de bogue a été conçu de façon extensible pour vous permettre d'ajouter des widgets HTML, tels que des listes déroulantes ou des boîtes de texte, sur la page de saisie de bogue, et leurs valeurs apparaissent formatées dans le commentaire initial. Un champ caché indiquant le format peut être ajouté dans le formulaire afin de rendre le modèle fonctionnel. Sa valeur doit être le suffixe du nom de fichier du modèle. Par exemple, si le fichier s'appelle create-cust.html.tmpl, alors doit être utilisé dans le formulaire. Un exemple de ceci est le formulaire de soumission de bogue assisté. Le code pour ceci est livré dans la distribution de Bugzilla comme exemple à copier. On peut le trouver dans les fichiers create-guided.html.tmpl et comment-guided.html.tmpl. Pour utiliser cette focntionnalité, créez un modèle personnalisé pour enter_bug.cgi. Le modèle par défaut sur lequel vous pouvez vous baser est custom/bug/create/create.html.tmpl. Nommez-le create-.html.tmpl, et dedans, ajouter les widgets pour chaque élément d'information que vous aimeriez collecter - comme l'identifiant de compilation ou un ensemble d'étapes à reproduire. Puis, créez un modèle comme custom/bug/create/comment.txt.tmpl, et appelez-le comment-.txt.tmpl. Ce modèle doit référencer les champs de formulaire que vous avez créés en utilisant la syntaxe [% form. %]. Quand un rapport de bogue sera soumis, le commentaire initial du rapport de bogue sera formaté selon ce qui est indiqué dans ce modèle. Par exemple, si votre modèle personnalisé « enter_bug » avait un champ et que votre fichier « comment.txt.tmpl » avait BuildID : [% form.buildid %] , alors quelque chose comme BuildID : 20020303 devrait apparaître dans le commentaire initial. 6.3.6. Configurer Bugzilla pour détecter la langue de l'utilisateur Bugzilla respecte l'en-tête utilisateur « Accept: HTTP ». Vous pouvez installer des modèles dans d'autres langues et Bugzilla choisira la plus appropriée selon un ordre de priorité que vous avez établi. Beaucoup de modèle de langues peuvent être obtenus sur http://www.bugzilla.org/download.html#localizations. Les instructions pour soumettre de nouvelles langues sont également disponibles à cet emplacement. 6.4. Personnaliser qui peut changer quoi [Avertissement] Cette fonctionnalité doit être considérée comme expérimentale ; le code Bugzilla que vous changerez n'est pas stable et pourrait être modifié ou déplacé entre les versions. Soyez conscients que les modifications que vous pourront être à refaire ou à porter si des modifications du code interne de Bugzilla sont faites entre les versions et que vous faites une mises à jour de Bugzilla. Les sociétés ont souvent des règles pour déterminer quels employés ou classes d'employés sont autorisés à modifier certaines choses dans le système de suivi de bogues. Par exemple, seul le contact QA désigné peut être autorisé à marquer le bogue VÉRIFIÉ. Bugzilla a été conçu pour vous faciliter la tâche d'écrire vos propres règles pour définir qui est autorisé à faire certains types de modifications. Par défaut, les responsables, les responsables QA et les utilisateurs ayant des privilèges editbugs peuvent modifier tous les champs des bogues, sauf les restrictions de groupes (à moins qu'ils ne soient membres des groupes qu'ils essaient de modifier). Les rapporteurs de bogue ont la possibilité de modifier quelques champs, mais de manière beaucoup plus restrictive. Les autres utilisateurs sans privilèges editbugs, ne peuvent pas modifier les bogues, sauf pour ajouter un commentaire ou s'ajouter à la liste « Copie à ». Pour une flexibilité maximale, personnaliser cela signifie de modifier le code Perl de Bugzilla. Ceci donne à l'administrateur le contrôle total sur ce que chacun peut faire. La méthode pour réaliser cela s'appelle check_can_change_field(), et se trouve dans le fichier Bug.pm de votre répertoire Bugzilla/. Si vous ouvrez ce fichier pour y rechercher « sub check_can_change_field », vous la trouverez. Cette méthode a été soigneusement commentée pour vous permettre de voir exactement comment elle fonctionne et vous donner une idée sur la façon de la modifier. Certaines sections identifiées ne doivent pas être modifiées - c'est le « squelette » qui permet au reste de la fonction de fonctionner. Entre ces sections, vous trouverez des morceaux de code comme : # Allow the assignee to change anything. if ($ownerid eq $whoid) { return 1; } Il est évident de savoir ce que cette partie de code fait. Alors, comment modifier cette fonction ? Certains changements simples peuvent être accomplis en supprimant quelques parties - par exemple, si vous voulez empêcher un utilisateur d'ajouter un commentaire à un bogue, supprimez les lignes marquées « Allow anyone to change comments. » Si vous ne voulez pas que le rapporteur ait des droits spéciaux sur les bogues qu'il a rapporté, supprimez toute la section concernant le rapporteur. Des personnalisations plus complexes ne sont pas beaucoup plus difficiles. En gros, vous ajoutez un point de vérification au bon endroit dans la fonction, c-à-d. après que toutes les variables que vous utilisez ont été définies. Aussi, ne cherchez pas « $ownerid » avant que cette variable n'ait été obtenue de la base de données. Vous pouvez ajouter soit un point de vérification positif, qui renvoie « 1 » (autoriser) si certaines conditions sont vérifiées, soit un point de vérification négatif, qui renvoie « 0 » (refuser). Par ex. : if ($field eq "qacontact") { if (Bugzilla->user->in_group("quality_assurance")) { return 1; } else { return 0; } } Ceci signifie que seuls les utilisateurs du groupe « quality_assurance » peuvent changer le champ « Contact QA » d'un bogue. Plus bizarre : if (($field eq "priority") && (Bugzilla->user->email =~ /.*\@exemple\.com$/)) { if ($oldvalue eq "P1") { return 1; } else { return 0; } } Ceci signifie que si l'utilisateur essaie de changer le champ « Priorité », et que son adresse électronique est « …@exemple.com », il ne peut le faire que si l'ancienne valeur du champ était « P1 ». Pas très utile, mais illustratif. [Avertissement] Si vous modifiez le fichier process_bug.cgi, ne changez pas les blocs de code marqués « DO_NOT_CHANGE ». Si vous le faites, cela compromettra la sécurité de votre installation ou provoquera empêchera votre de fonctionner. Pour une liste des noms de champs possibles, consultez la table « bugs » dans la base de données. Si vous avez besoin d'aide pour écrire des règles personnalisées pour votre organisation, demandez de l'aide sur le forum. 6.5. Intégration de Bugzilla avec des outils tiers Beaucoup d'utilitaires et d'applications peuvent s'intégrer dans Bugzilla, que ce soit du côté client ou du côté serveur. Aucun d'eux n'est maintenu par la communauté Bugzilla et ils n'ont pas été testés lors de nos tests d'assurance qualité. Par conséquent, utilisez-les à vos risques et périls. Ils sont listés sur https://wiki.mozilla.org/Bugzilla:Addons. Annexe A. Dépannage Table des matières A.1. Notice générale A.2. Le serveur Apache n'affiche pas les pages de Bugzilla A.3. J'ai installé un module Perl mais checksetup.pl dit qu'il n'est pas installé ! A.4. DBD::Sponge::db prepare failed A.5. cannot chdir(/var/spool/mqueue) A.6. Tout le monde est obligé de se reconnecter constamment A.7. index.cgi n'apparaît pas à moins de le spécifier dans l'URL A.8. « checksetup.pl » signale « Client does not support authentication protocol requested by server… » Cette section donne les solutions aux problèmes d'installation courants de Bugzilla. Si aucun des titres ne semble correspondre à votre problème, veuillez lire la notice générale. A.1. Notice générale Si vous n'arrivez pas à exécuter checksetup.pl jusqu'à son terme, il explique généralement ce qui ne va pas et comment le corriger. Si vous ne vous en sortez pas ou si l'explication de correction n'est pas indiquée, veuillez poster les erreurs dans le forum mozilla.support.bugzilla. Si vous avez effectué ce qui est indiqué dans Section 2.1, « Installation » (Installation) et Section 2.2, « Configuration » (Configuration) mais que l'accès à l'URL de Bugzilla ne fonctionne pas, la première chose à faire est de vérifier le journal des erreurs de votre serveur Web. Pour Apache, il se trouve souvent sur /etc/logs/httpd/error_log. Les messages d'erreur que vous voyez peuvent être suffisamment explicites pour vous permettre de diagnostiquer et corriger le problème. Si ce n'est pas le cas, veuillez consulter ci-dessous les erreurs communément rencontrées. Si cela ne vous aide pas, veuillez poster les erreurs dans le forum. Bugzilla peut également journaliser les erreurs utilisateur (et beaucoup d'erreurs de code) qui surviennent sans polluer le journal des erreurs du serveur Web. Pour activer la journalisation des erreurs de Bugzilla, créez un fichier dans lequel Bugzilla peut écrire nommé errorlog, dans le répertoire data de Bugzilla. Les erreurs seront consignées au fur et à mesure en indiquant le type d'erreur, l'adresse IP et le nom d'utilisateur (si disponible) de l'utilisateur qui a déclenché l'erreur et les valeurs de toutes les variables d'environnement ; si un formulaire a été soumis, les données de celui-ci seront aussi incluses. Pour désactiver la journalisation d'erreur, supprimez ou renommez le fichier errorlog. A.2. Le serveur Apache n'affiche pas les pages de Bugzilla après avoir exécuté deux fois le script checksetup.pl, exécuter la commande testserver.pl http://votresite.votredomaine/votrerurl pour confirmer que votre serveur Web est configuré correctement pour Bugzilla. bash$ ./testserver.pl http://landfill.bugzilla.org/bugzilla-tip TEST-OK Webserver is running under group id in $webservergroup. TEST-OK Got ant picture. TEST-OK Webserver is executing CGIs. TEST-OK Webserver is preventing fetch of http://landfill.bugzilla.org/bugzilla-t ip/localconfig. A.3. J'ai installé un module Perl mais checksetup.pl dit qu'il n'est pas installé ! Cela peut être dû à l'une des deux causes suivantes : 1. Vous avez deux versions de Perl sur votre machine. Vous installez les modules dans l'une et Bugzilla utilise l'autre. Ré-exécutez les commandes CPAN (ou la compilation manuelle) en utilisant le chemin d'accès complet à Perl en haut du script checksetup.pl. Ceci assurera que vous installez les modules au bon endroit. 2. Les permissions de vos répertoires de bibliothèques sont définies de manière incorrecte. Elles doivent être au moins en lecture pour l'utilisateur ou le groupe du serveur Web. Il est recommandé qu'elles soient en lecture pour tout le monde. A.4. DBD::Sponge::db prepare failed Le message d'erreur suivant peut apparaître à cause d'un bogue de DBD::mysql (sur lequel l'équipe de Bugzilla n'a pas de contrôle) : DBD::Sponge::db prepare failed: Cannot determine NUM_OF_FIELDS at D:/Perl/site/ lib/DBD/mysql.pm line 248. SV = NULL(0x0) at 0x20fc444 REFCNT = 1 FLAGS = (PADBUSY,PADMY) Pour corriger cela, rendez-vous dans /lib/DBD/sponge.pm dans votre installation de Perl et remplacez my $numFields; if ($attribs->{'NUM_OF_FIELDS'}) { $numFields = $attribs->{'NUM_OF_FIELDS'}; } elsif ($attribs->{'NAME'}) { $numFields = @{$attribs->{NAME}}; par my $numFields; if ($attribs->{'NUM_OF_FIELDS'}) { $numFields = $attribs->{'NUM_OF_FIELDS'}; } elsif ($attribs->{'NAMES'}) { $numFields = @{$attribs->{NAMES}}; (veuillez noter le S ajouté à NAME.) A.5. cannot chdir(/var/spool/mqueue) Si vous avez installé Bugzilla sur une distribution SuSE Linux ou toute autre distribution avec les options de sécurité en mode « paranoïaque », il est possible que le script checksetup.pl échoue avec l'erreur : cannot chdir(/var/spool/mqueue): Permission denied Ceci est provoqué par votre répertoire /var/spool/mqueue qui a les permissions drwx------. Saisissez la commande chmod 755 /var/spool/mqueue en tant que « root » pour corriger ce problème. Ceci permettra à tout processus s'exécutant sur votre machine de lire le répertoire /var/spool/mqueue. A.6. Tout le monde est obligé de se reconnecter constamment La cause la plus probable est que le paramètre « cookiepath » n'est pas défini correctement dans la configuration de Bugzilla. Vous pouvez changer ceci (si vous êtes un administrateur de Bugzilla) à partir de la page « editparams.cgi » dans votre navigateur Web. La valeur du paramètre « cookiepath » doit être le répertoire actuel contenant votre installation de Bugzilla, comme le voit le navigateur Web du simple utilisateur. Les barres de fraction « / » ouvrante et fermante sont obligatoires. Vous pouvez définir « cookiepath » pour n'importe quel répertoire parent de Bugzilla (comme « / », le répertoire racine). Mais vous ne pouvez pas indiquer un répertoire qui n'a pas au moins une correspondance partielle sans quoi cela ne fonctionnera pas. Vous êtes en fait en train d'empêcher le navigateur de l'utilisateur de renvoyer les cookies seulement vers ce répertoire. Comment savoir si vous voulez votre répertoire Bugzilla spécifique ou tout le site ? Si vous n'avez qu'une seule installation de Bugzilla sur le serveur et si ça vous est égal d'avoir d'autres applications sur le même serveur capables de voir les cookies (vous pourriez faire ceci volontairement si vous avez d'autres choses sur votre site qui partagent l'authentification avec Bugzilla), alors vous voudrez que « cookiepath » soit défini à « / », ou un répertoire suffisamment haut pour que toutes les applications concernées puissent voir les cookies. Exemple A.1. Exemples de paires « urlbase »/« cookiepath » partageant les cookies de connexion « urlbase » est http://bugzilla.mozilla.org/ « cookiepath » est / « urlbase » est http://outils.monsite.tld/bugzilla/ mais vous avez http://outils.monsite.tld/uneautreappli/ qui partage l'authentification avec Bugzilla « cookiepath » est / D'un autre côté, si vous avez plus d'une installation Bugzilla sur votre serveur (certains le font - nous le faisons pour landfill) vous devrea avoir le paramètre « cookiepath » suffisamment restreint pour que les différentes installations de Bugzilla ne confondent pas leurs cookies l'une et l'autre. Exemple A.2. Exemples de paires « urlbase »/« cookiepath » pour limiter les cookies de connexion « urlbase » est http://landfill.bugzilla.org/bugzilla-tip/ « cookiepath » est /bugzilla-tip/ « urlbase » est http://landfill.bugzilla.org/bugzilla-4.0-branc h/ « cookiepath » est /bugzilla-4.0-branch/ Si vous aviez « cookiepath » défini à « / » auparavant et que vous voulez le définir pour quelque chose de plus restrictif (par ex. « /bugzilla/ »), vous pouvez faire cela en toute sécurité sans demander à vos utilisateurs de supprimer leurs cookies relatifs à Bugzilla dans leur navigateur (ceci est vrai dès Bugzilla 2.18 et Bugzilla 2.16.5). A.7. index.cgi n'apparaît pas à moins de le spécifier dans l'URL Vous devrez vraisemblablement paramétrer votre serveur Web de sorte qu'il serve la page comme une page d'index. Si vous utilisez Apache, vous pouvez faire cela en ajoutant index.cgi à la fin de la ligne DirectoryIndex comme c'est indiqué dans Section 2.2.4.1, « Bugzilla utilisant Apache ». A.8. « checksetup.pl » signale « Client does not support authentication protocol requested by server… » Cette erreur survient car vous utilisez le nouveau chiffrement de mot de passe fourni avec MySQL 4.1 alors que votre module DBD::mysql a été compilé pour une version antérieure de MySQL. Si vous recompilez DBD::mysql avec les bibliothèques actuelles de MySQL (ou si vous obtenez un nouvelle version de ce module) alors l'erreur peut disparaître. Si cela ne corrige pas votre problème ou si vous ne pouvez pas recompiler le module existant (par ex. si vous utilisez Windows) et/ou que vous ne voulez pas le remplacer (par ex. vous voulez conserver une version empaquetée), alors, un moyen de contournement est disponible sur la documentation de MySQL : http://dev.mysql.com/doc/mysql/en/Old_client.html Annexe B. Contrib Table des matières B.1. Interface de recherche en ligne de commande B.2. Outil en ligne de commande « Envoyer les courriels de bogues en attente » Il existe de nombreux modules non-officiels complémentaires à Bugzilla dans le répertoire $BUGZILLA_ROOT/contrib/. Cette section les documente. B.1. Interface de recherche en ligne de commande C'est une suite d'utilitaires Unix pour faire des recherches dans Bugzilla en ligne de commande. Ils résident dans le répertoire contrib/cmdline. Il y a trois trois fichiers - query.conf, buglist et bugs. [Avertissement] Ces fichiers sont antérieurs au travail d'intégration dans les modèles commencé dans la version 2.16 et n'ont pas été mis à jour. query.conf contient la correspondance entre les options et les noms de champs et les types de comparaison. Les noms d'options entre guillemets sont « greppés » (recherchés avec la commande grep), il devrait donc être facile de modifier ce fichier. Les commentaires (#) sont sans effet ; vous devez donc vous assurer que ces lignes ne contiennent pas « option » entre guillemets. buglist est un script qui soumet une requête Bugzilla et écrit la page HTML résultante sur la sortie standard. Il accepte les options courtes , (comme « -Atoto » ou « -Rtiti ») et les options longues (comme « --assignedto=toto » ou « --reporter=titi »). Si le premier caractère d'une option n'est pas « - », elle est traitée comme si elle préfixée avec « --default= ». La colonne de liste est récupérée de la variable d'environnement COLUMNLIST. Ceci est équivalent à l'option « Modifier les colonnes » disponible quand vous listez les bogues dans buglist.cgi. Si vous avez déjà utilisé Bugzilla, faites un grep de COLUMNLIST dans vos fichiers de cookies pour voir le paramètrage actuel pour COLUMNLIST. bugs est un simple script qui appelle buglist et extrait les numéros de bogues de la sortie de ce script. Ajouter le préfixe « http://bugzilla.mozilla.org/buglist.cgi?bug_id= » transforme la liste de bogues en hyperliens si des bogues sont trouvés. Compter les bogues est facile : faites un « pipe » (« | ») des résultats avec sed -e 's/,/ /g' | wc | awk '{printf $2 "\n"}' Akkana Peck dit qu'elle a de bons résultats en faisant un « pipe » sur la sortie du script buglist avec w3m -T text/html -dump B.2. Outil en ligne de commande « Envoyer les courriels de bogues en attente » Dans le répertoire contrib se trouve un utilitaire du nom descriptif (à défaut d'être court) de sendunsentbugmail.pl. Le propos de ce script est simplement d'envoyer tout courriel relatif aux bogues qui aurait dû être envoyé, mais qui, pour une raison ou une autre, ne l'a pas été. Pour accomplir cette tâche, sendunsentbugmail.pl utilise le même mécanisme que le script sanitycheck.cgi ; il analyse toute la base de données en recherchant les bogues qui ont été modifiés plus de 30 minutes auparavant, mais pour lesquels il n'y a pas d'enregistrement pour les personnes associées à ce bogue pour lesquelles un courriel a été envoyé. Après avoir compilé une liste, il utilise alors les règles standard pour déterminer qui doit recevoir un courriel et l'envoie. Lors de son exécution, le script indique le bogue traité pour lequel il est en train d'envoyer un courriel ; quand il a terminé, il donne le nombre de courriels qui ont été envoyés et le nombre de personnes ayant été exclues des envois. (Les noms d'utilisateurs ne sont ni enregistrés, ni affichés). Si le script ne produit pas de sortie, cela signifie qu'aucun courriel en attente n'a été détecté. Utilisation : déplacez le script sendunsentbugmail.pl dans le répertoire racine, assurez-vous qu'il a les droits d'exécution, et exécutez-le en ligne de commande (ou avec une tâche programmée) sans paramètre. Annexe C. Manuel d'installation des modules Perl Table des matières C.1. Instructions C.2. Liens de téléchargement C.3. Modules optionnels C.1. Instructions Si vous devez installer des modules Perl manuellement, voici comment faire. Téléchargez le module en utilisant le lien donné dans la section suivante et invoquez cette incantation magique en tant qu'utilisateur « root » : bash# tar -xzvf .tar.gz bash# cd bash# perl Makefile.PL bash# make bash# make test bash# make install [Note] Pour compiler le code source sous Windows, vous devrez obtenir un utilitaire « make ». L'utilitaire nmake fourni avec Microsoft Visual C++ peut être utilisé. vous pouvez aussi utiliser l'utilitaire appelé dmake disponible dans CPAN qui est écrit entièrement en Perl. Comme cela est décrit dans Section C.2, « Liens de téléchargement », cependant, la plupart des paquetages existent déjà et sont disponibles à partir de ActiveState ou de theory58S. Nous vous recommandons fortement de les installer en utilisant l'interface graphique ppm disponible avec ActiveState et d'ajouter le référentiel theory58S à votre liste de référentiels. C.2. Liens de téléchargement [Note] Pour exécuter Bugzilla sous Windows, vous devez utiliser ActiveState Perl 5.8.1 ou supérieur. Si certains modules ne sont pas présents, envisagez de mettre à jour ActiveState Perl en version 5.12 minimum, qui contient tous les modules nécessaires. CGI : Page de téléchargement de CPAN : http://search.cpan.org/dist/CG I.pm/ Documentation : http://perldoc.perl.org/CGI.html Data-Dumper : Page de téléchargement de CPAN : http://search.cpan.org/dist/Da ta-Dumper/ Documentation : http://search.cpan.org/dist/Data-Dumper/Dumper. pm Date::Format (fait partie de TimeDate) : Page de téléchargement de CPAN : http://search.cpan.org/dist/Ti meDate/ Documentation : http://search.cpan.org/dist/TimeDate/lib/Date/F ormat.pm DBI : Page de téléchargement de CPAN : http://search.cpan.org/dist/DB I/ Documentation : http://dbi.perl.org/docs/ DBD::mysql : Page de téléchargement de CPAN : http://search.cpan.org/dist/DB D-mysql/ Documentation : http://search.cpan.org/dist/DBD-mysql/lib/DBD/m ysql.pm DBD::Pg : Page de téléchargement de CPAN : http://search.cpan.org/dist/DB D-Pg/ Documentation : http://search.cpan.org/dist/DBD-Pg/Pg.pm Template-Toolkit : Page de téléchargement de CPAN : http://search.cpan.org/dist/Te mplate-Toolkit/ Documentation : http://www.template-toolkit.org/docs.html GD : Page de téléchargement de CPAN : http://search.cpan.org/dist/GD / Documentation : http://search.cpan.org/dist/GD/GD.pm Template::Plugin::GD : Page de téléchargement de CPAN : http://search.cpan.org/dist/Tem plate-GD/ Documentation : http://www.template-toolkit.org/docs/aqua/Module s/index.html MIME::Parser (fait partie de MIME-tools) : Page de téléchargement de CPAN : http://search.cpan.org/dist/MI ME-tools/ Documentation : http://search.cpan.org/dist/MIME-tools/lib/MIME /Parser.pm C.3. Modules optionnels Chart::Lines : Page de téléchargement de CPAN : http://search.cpan.org/dist/Ch art/ Documentation : http://search.cpan.org/dist/Chart/Chart.pod GD::Graph : Page de téléchargement de CPAN : http://search.cpan.org/dist/GD Graph/ Documentation : http://search.cpan.org/dist/GDGraph/Graph.pm GD::Text::Align (fait partie de GD::Text::Util) : Page de téléchargement de CPAN : http://search.cpan.org/dist/GD TextUtil/ Documentation : http://search.cpan.org/dist/GDTextUtil/Text/Ali gn.pm XML::Twig : Page de téléchargement de CPAN : http://search.cpan.org/dist/XM L-Twig/ Documentation : http://standards.ieee.org/resources/spasystem/t wig/twig_stable.html PatchReader : Page de téléchargement de CPAN : http://search.cpan.org/author/ JKEISER/PatchReader/ Documentation : http://www.johnkeiser.com/mozilla/Patch_Viewer. html Annexe D. GNU Free Documentation License Table des matières D.0. Preamble D.1. Applicability and Definition D.2. Verbatim Copying D.3. Copying in Quantity D.4. Modifications D.5. Combining Documents D.6. Collections of Documents D.7. Aggregation with Independent Works D.8. Translation D.9. Termination D.10. Future Revisions of this License D.. How to use this License for your documents Version 1.1, March 2000 Copyright (C) 2000 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. D.0. Preamble The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. D.1. Applicability and Definition This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. D.2. Verbatim Copying You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. D.3. Copying in Quantity If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. D.4. Modifications You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five). C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. D.5. Combining Documents You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements." D.6. Collections of Documents You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. D.7. Aggregation with Independent Works A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate. D.8. Translation Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail. D.9. Termination You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. D.10. Future Revisions of this License The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. D.. How to use this License for your documents To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: Copyright (c) YEAR YOUR NAME. 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 the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled "GNU Free Documentation License". If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for Back-Cover Texts. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software. Glossaire 0-9, high ascii .htaccess Le serveur Web Apache, et d'autres serveurs Web compatibles NCSA, respecte la convention d'utiliser des fichiers nommés .htaccessdans les répertoires pour limiter les accès à certains fichiers. Pour Bugzilla, ils sont utilisés pour garder secret des fichiers qui dans le cas contraire pourraient compromettre votre installation - par ex. le fichier localconfig qui contient le mot de passe de votre base de données. A Apache Dans ce contexte, Apache est le serveur Web le plus utilisé pour servir les pages de Bugzilla. Contrairement à une croyance répandue, le serveur Web Apache n'a rien à voir avec l'ancienne et noble tribu native d'Amérique du Nord, mais son nom est plutôt dérivé du fait que c'était « a patchy » version of the original NCSA world-wide-web server. (NdT : cela signifie, « une version corrigée » du serveur originel NCSA. « a patchy » se prononce « eupatchy » tout comme « apache » en anglais. Directives utiles lors de la configuration de Bugzilla AddHandler Comment indiquer à Apache qu'il peut exécuter des scripts CGI. AllowOverride, Options Ces directives sont utilisées pour indiquer à Apache beaucoup de choses sur le répertoire auquel elles s'appliquent. Pour Bugzilla, nous en avons besoin pour autoriser l'exécution de scripts et l'écrasement des fichiers .htaccess. DirectoryIndex Utilisé pour indiquer à Apache les fichiers qui sont des index. Si vous ne pouvez pas ajouter index.cgi à la liste des fichiers valides, vous aurez besoin de définir $index_html à 1 dans le fichier localconfig so ./checksetup.pl créera un fichier index.html qui fera une redirection sur index.cgi. ScriptInterpreterSource Utilisé lorsque Apache est exécuté sous Windows pour ne pas changer la ligne dans chaque script de Bugzilla. Pour plus d'informations sur la manière de configurer Apache pour Bugzilla, consultez Section 2.2.4.1, « Bugzilla utilisant Apache ». B Bogue Un « bogue » dans Bugzilla se réfère à un problème saisi dans la base de données qui a un numéro, des affectations, des commentaires associés, etc. Certains parlent de « tickets » ou de « problèmes » ; dans le contexte de Bugzilla, ils sont synonymes. Numéro de bogue À chaque bogue de Bugzilla est affecté un numéro unique qui identifie ce bogue. Le bogue associé à un numéro de bogue retrouvé par l'intermédiaire d'une requête ou facilement sur la page principale en saisissant le numéro dans la boîte « Rechercher ». Bugzilla Bugzilla est le leader mondial des logiciels libres de suivi de bogues. C Common Gateway Interface CGI est l'acronyme de Common Gateway Interface (interface de passerelle commune). c'est un standard pour l'interfaçage d'application externe avec un serveur Web. Bugzilla est un exemple d'application CGI. Composant Un composant est une sous-section d'un produit. Cela peut être une catégorie restreinte, taillée pour votre organisation. Tous les produits doivent contenir au moins un composant (et par conséquent, créer un produit sans composant provoquera une erreur dans Bugzilla). Comprehensive Perl Archive Network CPAN est l'acronyme de « Comprehensive Perl Archive Network ». CPAN maintient un grand nombre de modules Perl extrêmement utiles. Ce sont des morceaux de code encapsulés pour accomplir une tâche particulière. contrib Dans le répertoire contrib sont placés les scripts de contributeurs à Bugzilla mais qui ne font pas partie de la distribution officielle. Ces scripts sont écrits par des tiers et peuvent être écrits en d'autres langages que Perl. Pour ceux écrits en Perl, il peut y avoir des modules additionnels ou d'autres prérequis que ceux de la distribution officielle. [Note] Les scripts du répertoire contrib ne sont pas officiellement supportés par l'équipe Bugzilla et peuvent ne plus fonctionner en passant d'une version à l'autre. D démon Un démon est un programme informatique qui tourne en arrière-plan. En général, la plupart des démons sont démarrés au démarrage de l'ordinateur via les scripts d'initialisation de System V ou via des scripts RC sur les systèmes basés sur BSD. mysqld, le serveur MySQL et apache, un serveur Web, sont généralement exécutés comme des démons. Attaque DOS Un DOS, ou attaque par déni de service, se produit quand un utilisateur essaie d'empêcher l'accès à un serveur Web en accédant sans cesse à une page ou en envoyant des requêtes mal formées à un serveur Web. Un D-DOS, ou attaque par déni de service distribuée, se produit quand ces requêtes proviennent de plusieurs sources en même temps. Malheureusement, il est beaucoup plus difficile de se prémunir de ces attaques. G Groupes Le mot « groupes » a une signification très spéciale dans Bugzilla. Le mécanisme principal de sécurité de Bugzilla repose sur le placement d'utilisateurs dans des groupes et l'affectation à ces groupes de certains privilèges pour voir les bogues de produits particulier dans la base de données de Bugzilla. J JavaScript JavaScript est cool, nous devrions en parler. M Message Transport Agent Un agent de transport de message est utilisé pour contrôler le flux des courriels sur un système. Le module Perl Email::Send qu'utilise Bugzilla pour envoyer des courriels, peut être configuré pour utiliser beaucoup de mises en œuvre sous-jacentes différentes pour envoyer les courriels en utilisant le paramètre mail_delivery_method. MySQL MySQL est un des RDBMS requis pour Bugzilla. MySQL peut être téléchargé sur http://www.mysql.com. Bien que vous deviez vous familiariser avec toute la documentation, quelques points importants sont : Sauvegarde Méthodes de sauvegarde de votre base de données Bugzilla. Fichiers d'option Des informations sur la façon de configurer MySQL en utilisant le fichier my.cnf. Système de privilèges Informations sur la manière de protéger votre serveur MySQL. P Perl Package Manager http://aspn.activestate.com/ASPN/Downloads/ActivePerl/PPM/ Produit Un produit est une grande catégorie de types de bogues, représentant normalement une partie d'un logiciel ou d'une entité. En général, il y a plusieurs composants dans un produit. Un produit peut définir un groupe (utilisé pour la sécurité) pour tous les bogues saisis dans ses composants. Perl First written by Larry Wall, Perl is a remarkable program language. It has the benefits of the flexibility of an interpreted scripting language (such as shell script), combined with the speed and power of a compiled language, such as C. Bugzilla is maintained in Perl. Q QA « QA », « Q/A » et « Q.A. » sont des raccourcis pour « assurance qualité ». Dans la plupart des grandes organisations de développement de logiciels, il y a une équipe dédiée pour assurer que le produit respecte un minimum de standards avant la publication. Cette équipe voudra aussi généralement suivre la progression des bogues tout au long de leur cycle de vie, d'où le besoin du champ « Contact QA » dans un bogue. R Relational DataBase Management System Un système de gestion de base de données relationnelle est un système de base de données qui stocke les informations dans des tables qui sont reliées les unes aux autres. Expression régulière Une expression régulière est une expression utilisée pour rechercher une correspondance de motif. Documentation S Service Dans un environnement Windows NT, une application fonctionnant en arrière-plan et lancée au démarrage est appelée service. Ils sont généralement géré à l'aide du panneau de configuration après s'être connecté avec un compte ayant des privilèges « Administrateur ». Pour plus d'informations, consultez votre manuel Windows,For more ou la MSKB (Microsoft Knowledge Base : base de connaissances Microsoft). SGML SGML est l'acronyme de « Standard Generalized Markup Language » (langage normalisé de balisage généralisé). Créé dans les années 1980 pour fournir un moyen extensible pour maintenir de la documentation basé sur le contenu plutôt que la présentation, SGML a résisté à l'épreuve du temps comme un langage robuste et puissant. XML est le « petit frère » de SGML ; tout dovument XML valide est, par définition, un document SGML valide. Le document que vous êtes en train de lire est écrit et maintenu en SGML, et il est également valide XML si vous modifiez la Document Type Definition (définition du type de document). T Jalon cible Les jalons cibles sont des objectifs de produit. Ils sont configurables par produit. La plupart des sociétés de développement ont un concept de « jalons » où les personnes finançant un projet attendent certaines fonctionnalités à certaines dates. Bugzilla facilite l'accession à ces jalons en donnant la possibilité de déclarer pour quel jalon un bogue sera corrigé ou une amélioration mise en œuvre. Tool Command Language TCL est un langage de script open source disponible sur Windows, Macintosh et les systèmes basés sur Unix. Bugzilla 1.0 était écrit en TCL mais jamais publié. La première version était Bugzilla was 2.0, quand il a été porté en Perl. Z Aucun bogue trouvé (NdT :en anglais le texte est « Zarro Boogs found » au lieu de « Zero bugs found »). C'est juste une manière un peu dingue de dire qu'il n'y a pas de bogues correspondant à votre requête. Quand on lui a demandé d'expliquer ce message, Terry a déclaré : On m'a demandé d'expliquer ceci … il y a longtemps, quand Netscape publiait la version 4.0 de son navigateur, nous avions fait une fête pour la sortie de la version. Naturellement, il y avait eu une grosse pression pour essayer de corriger chaque bogue connu avant la sortie de la version. Naturellement, ça n'est en fait pas arrivé. (Ce n'est pas propre à Netscape ou la version 4.0 ; la même chose est arrivée dans tous les projets que je connais). Bref, lors de cette fête il y avait des T-shirts qui disait quelque chose comme « Netscape 4.0: Zarro Boogs ». Tout comme le logiciel, le T-shirt n'avait pas de bogue connu. Uh-huh. Donc, quand vous faites une requête pour obtenir une liste de bogues, et qu'il n'y a pas de résultat, vous pouvez penser à ceci comme un rappel amical. Bien *sûr* il y a des bogues qui correspondent à votre requêtes, ils ne sont juste pas encore dans le système… --Terry Weissman