Le guide de Bugzilla - version 4.4.7
L'équipe Bugzilla
2015-01-21
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.
1.2.
1.3.
1.4.
1.5.
Information sur le copyright
Avis de non-responsabilité
Nouvelles versions
Contributeurs
Conventions du document
1.1. Information sur le copyright
Ce document est sous copyright © 2000-2015 de ses divers contributeurs Bugzilla
qui l'ont écrit.
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.7 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
<mbarnson@sisna.com>
pour la tâche herculéenne de rassemblement des documents du guide Bugzilla
et pour l'avoir mené à sa version 2.14.
Terry Weissman
<terry@mozilla.org>
pour avoir initialement écrit Bugzilla et créer le fichier README sur lequel la
documentation d'installation Unix est largement basée.
Tara Hernandez
<tara@tequilarists.org>
pour avoir maintenu le rythme de développement après le départ de Terry de
mozilla.org et pour maintenir landfill.
Dave Lawrence
<dkl@redhat.com>
pour avoir fourni son expertise sur les différences essentielles avec la version
personnalisée de Bugzilla de Red Hat.
Dawn Endico
<endico@mozilla.org>
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
<jake@bugzilla.org>
pour s'être occupé de la documentation pendant la période de développement
de la version 2.17.
Dave Miller
<justdave@bugzilla.org>
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 :
Ceci est une mise en garde. Assurez-vous de lire ceci pour ne pas avoir de
problèmes !
Ceci est une astuce, généralement sur des paramètres de
configuration.
Ceci est une note, pour votre information.
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
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.
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.
Beaucoup de versions bianires 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://<votre-machine>/
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=Documentation.
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.
La distribution par défaut de Bugzilla n'est PAS conçue pour être placée dans un
répertoire
ScriptAlias
cgi-bin. Ceci inclut tout répertoire configué en utilisant la directive
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
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.
checksetup.pl
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 installmodule.pl est exécuté ainsi :
bash# perl install-module.pl <modulename>
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.
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
<nom_paquet>-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.
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
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
--check-modules.
checksetup.pl
à nouveau, cette fois sans l'argument
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'.
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.
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
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 packets 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.
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).
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
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.
se terminera alors. Vous pouvez relancer
si vous le souhaitez.
checksetup.pl
checksetup.pl
à tous moments
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 <Directory> 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.
<Directory /var/www/html/bugzilla>
AddHandler cgi-script .cgi
Options +ExecCGI
DirectoryIndex index.cgi index.html
AllowOverride Limit FileInfo Indexes Options
</Directory>
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.
Il est possible de faire ces changements globalement ou sur la directive
contrôlant le répertoire parent de Bugzilla (par ex. <Directory
/var/www/html/>). 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.
Sous Windows, vous pourriez aussi avoir à ajouter la ligne
ScriptInterpreterSource Registry-Strict, voir les notes spécifiques pour
Windows.
3.
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
checksetup.pl
trouvée ici dans la variable
exécutez checksetup.pl.
$webservergroup
du fichier
localconfig,
puis, ré-
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 <Directory> 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.
Ceci doit être utilisé au lieu du bloc <Directory> 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.
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.
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.
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.
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://<votre_nom_de_domaine>/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 :
<chemin d'accès complet à perl.exe >\perl.exe -x<chemin d'accès complet à Bugzilla> -wT "%s"
%s
Par exemple :
c:\perl\bin\perl.exe -xc:\bugzilla -wT "%s" %s
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://<votre-serveur-bugzilla>/ - 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.
L'URL ci-dessus peut être incorrecte si vous avez installé Bugzilla dans un sousré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 <votre-repertoire-bugzilla> && ./collectstats.pl
Après deux jours, vous pourrez consulter des graphiques de bogues à partir de la
page « Rapports ».
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 <votre-repertoire-bugzilla> && ./whineatnews.pl
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 <votre-repertoire-bugzilla> && ./whine.pl
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.
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 <VirtualHost> de votre Bugzilla soit dans la
section <Directory> 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.<PROJECT> 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é
<PROJECT> au même emplacement que celui par défaut (template/<langcode>). 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.
<VirtualHost 212.85.153.228:80>
ServerName toto.titi.tata
SetEnv PROJECT toto
Alias /bugzilla /var/www/bugzilla
</VirtualHost>
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=Documentation.
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.
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 <nom_du_module>
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.
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 ».
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.
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.
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 :
expat
# 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é.
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
comme suit…
.my.cnf
dans votre répertoire
home (/home/foo
dans cet exemple)
[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).
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.
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é.
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.
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.
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+rx {} \; ;
done
for i in jpg gif css js png html rdf xul; do find . -name \*.$i -exec chmod 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.
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é.
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.
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.
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
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).
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.)
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
Le point (« . ») au début de la commande ./checksetup.pl est important
et ne peut pas être omis.
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.
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.
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 « <div> ». 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 « <div> ».
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 cidessous.
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.
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.
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 ».
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.
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.
À 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.
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 ».
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.
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.
Ne désactivez pas tous les comptes administrateurs !
 <nomgroupe> : 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.)
 <nomproduit> : 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.
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é.
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.
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
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.
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.
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 motclé : 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.
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 ».
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).
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.
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 cidessous. 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é ».
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.
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.
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 :
 Bloquer tout
 Mais autoriser :
*.dot
seulement pour le serveur « webdot » distant
 Sinon, si vous utilisez un « GraphViz » local :
 Bloquer tout
 Mais autoriser :
*.png, *.gif, *.jpg, *.map
 Et si vous n'utilisez aucun serveur « webdot » :
 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.
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.
5.2.
5.3.
5.4.
5.5.
Introduction
Création d'un compte Bugzilla
Anatomie d'un bogue
Cycle de vie d'un bogue
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 ».
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.
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
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.4branch/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 marquepage 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.
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.
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 <U> 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 ».
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.
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 ».
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.
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.
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.
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.
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.
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 ».
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.
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.
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 »).
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.
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.
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
pour qu'il puisse définir les permissions de fichiers correctement.
checksetup.pl
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.
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.
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.
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.
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.
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
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=<contenttype> » (comme rdf ou html) à l'URL <cginame>.cgi. Si vous voulez
récupérer un certain format, vous pouvez utiliser « &format=<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.
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 <stubname>-<formatname>.<contenttypetag>.tmpl.
Essayez le modèles en invoquant le script ainsi : <cginame>.cgi?
format=<formatname>&ctype=<type> .
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
<input type="hidden" name="format" value="cust">
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-<formatname>.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<formatname>.txt.tmpl. Ce modèle doit référencer les champs de formulaire que vous
avez créés en utilisant la syntaxe [% form.<fieldname> %]. 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
<input type="text" name="buildid" size="30">
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
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.
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/bugzillatip/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
installation de Perl et remplacez
<chemin-vers-perl>/lib/DBD/sponge.pm
dans votre
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 partag
e
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-branch/
« 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
query.conf, buglist et bugs.
contrib/cmdline.
Il y a trois trois fichiers -
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.
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.
query.conf
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= ».
buglist
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.
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"}'
bugs
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, assurezvous 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#
bash#
bash#
bash#
bash#
bash#
tar -xzvf <module>.tar.gz
cd <module>
perl Makefile.PL
make
make test
make install
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
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/CGI.pm/
Documentation : http://perldoc.perl.org/CGI.html
Data-Dumper :
Page de téléchargement de CPAN : http://search.cpan.org/dist/Data-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/TimeDate/
Documentation : http://search.cpan.org/dist/TimeDate/lib/Date/Format.pm
DBI :
Page de téléchargement de CPAN : http://search.cpan.org/dist/DBI/
Documentation : http://dbi.perl.org/docs/
DBD::mysql :
Page de téléchargement de CPAN : http://search.cpan.org/dist/DBD-mysql/
Documentation : http://search.cpan.org/dist/DBD-mysql/lib/DBD/mysql.pm
DBD::Pg :
Page de téléchargement de CPAN : http://search.cpan.org/dist/DBD-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/TemplateToolkit/
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/Template-GD/
Documentation : http://www.template-toolkit.org/docs/aqua/Modules/index.html
MIME::Parser (fait partie de MIME-tools) :
Page de téléchargement de CPAN : http://search.cpan.org/dist/MIME-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/Chart/
Documentation : http://search.cpan.org/dist/Chart/Chart.pod
GD::Graph :
Page de téléchargement de CPAN : http://search.cpan.org/dist/GDGraph/
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/GDTextUtil/
Documentation : http://search.cpan.org/dist/GDTextUtil/Text/Align.pm
XML::Twig :
Page de téléchargement de CPAN : http://search.cpan.org/dist/XML-Twig/
Documentation : http://standards.ieee.org/resources/spasystem/twig/twig_stabl
e.html
PatchReader :
Page de téléchargement de CPAN : http://search.cpan.org/author/JKEISER/Patch
Reader/
Documentation : http://www.johnkeiser.com/mozilla/Patch_Viewer.html
Annexe D. GNU Free Documentation License
Table des matières
D.0.
D.1.
D.2.
D.3.
Preamble
Applicability and Definition
Verbatim Copying
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 machinegenerated 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 computernetwork 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 FrontCover 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.
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èreplan 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

600 Or - Grepolis

votre site web avec bailador

• Ensuite, sur le dépôt https://mega.co.nz/#F

TP1 : environnement Unix - LISIC - Université du Littoral Côte d`Opale

Nouvelles technologies informatiques, synthèse

Faire léviter de l`eau et autres expériences ébouriffantes

GLPI OCS Inventory 1. Prérequis Installer un serveur LAMP : apt

Cours ISN Documentation

télécharger le répertoire des associations