Bugzilla est couvert par la Mozilla Public License. Pour plus de détails, reportez-vous à http://www.mozilla.org/MPL/.

http://bugzilla.org/consulting.html contient une liste d'entreprises et de particuliers qui nous ont demandé de les faire apparaître en tant que consultants pour Bugzilla.

On trouve plusieurs inconditionnels de Bugzilla expérimentés sur la liste de diffusion ou le forum et qui sont disposés à rendre service en échange d'une généreuse indemnité. Essayez en envoyant un message à la liste de diffusion pour rechercher un volontaire.

Il existe des douzaines d'entreprises de première importance qui ont des sites publiques Bugzilla pour suivre les bogues au sein de leurs produits. Une liste assez complète est disponible sur notre site à l'adresse http://bugzilla.org/installation-list/. Si vous possédez une installation de Bugzilla et que vous souhaitez être ajouté à cette liste, que votre installation soit publique ou non, envoyez un courriel à Gerv <gerv CHEZ mozilla POINT org> (en anglais).

Un noyau dur de développeurs, dirigé par Dave Miller (<justdave CHEZ bugzilla POINT org>).

Nous n'avons pu trouver aucune étude comparative entre Bugzilla et d'autres logiciels de suivi d'anomalies. Si vous en connaissez, merci de nous contacter. Cependant, d'après l'expérience personnelle de Matthew Barnson (qui a démarré cette FAQ), Bugzilla offre des performances supérieures sur le matériel grand public, à un meilleur prix (gratuit !), plus de fonctionnalités facilitant la tâche des développeurs (comme la sauvegarde des requêtes, l'intégration du courrier électronique et l'indépendance vis-à-vis de la plate-forme), une adaptabilité améliorée, une plus grande flexibilité et une plus grande facilité d'utilisation par rapport aux logiciels de suivi de bogues commercial.

Si vous développez un système de suivi de bogues commercial et si vous souhaitez nous soumettre une liste des avantages de votre produit par rapport à Bugzilla, envoyez la tout simplement à <documentation CHEZ bugzilla POINT org>. Nous serions heureux d'inclure ce comparatif dans notre documentation.

Il se peut que le support n'ait pas encore été développé ou que vous ne l'ayez pas trouvé. Bien que Bugzilla fasse à chaque version des progrès en termes de facilité d'emploi, de personnalisation, d'adaptabilité et d'interface utilisateur, cela ne signifie pas que Bugzilla n'est pas améliorable !

Le meilleur moyen d'effectuer une demande d'amélioration est de répertorier un bogue auprès de bugzilla.mozilla.org et d'en définir le degré de gravité (SEVERITY au niveau « amélioration » (ENHANCEMENT). Votre demande d'amélioration (RFE, Request For Enhancement) sera tout d'abord à l'état NON-CONFIRMÉE, et y restera jusqu'à ce que la personne compétente pour CONFIRMER le bogue l'examine. Si cette personne pense qu'il s'agit d'une requête justifiée qui va dans le sens des objectifs de Bugzilla, son état passera à NOUVEAU ; dans le cas contraire, cette personne vous expliquera vraisemblablement pourquoi, et le bogue passera dans l'état RÉSOLU/NE SERA PAS CORRIGÉ. Si quelqu'un d'autre a soumis la même requête (ou presque) avant vous, votre requête passera dans l'état RÉSOLU/DOUBLON, et un pointeur vers la RFE antérieure sera placé.

Même si votre RFE est approuvée, cela ne signifie pas qu'elle sera prise en compte dès la version suivante; nous avons un nombre limité de développeurs et de nombreuses requêtes... dont certaines sont plutôt complexes. Si vous êtes programmeur, vous pouvez participer au projet en élaborant vous même une correction qui produit la fonctionnalité que vous désirez. Si vous n'avez jamais contribué au développement de Bugzilla auparavant, merci de bien vouloir lire le Developers' Guide (guide du développeur) et le Contributors' Guide (guide du contributeur) avant toute chose.

Au départ, MySQL a été choisi car il était gratuit, facile à installer et compatible avec le matériel sur lequel Netscape comptait le faire fonctionner.

Le travail est actuellement en cours pour faire fonctionner Bugzilla avec PostgreSQL ; vous pouvez suivre l'avancement de cette initiative dans le bogue 98304 (http://bugzilla.mozilla.org/show_bug.cgi?id=98304).

La prise en charge de Sybase a été abandonnée. Même si le développement reprenait, il est probable que cela ne fonctionnerait pas sans que l'entreprise utilisatrice y change à la main beaucoup de choses. Sybase n'est tout simplement PAS très conforme aux standards (malgré tout le battage qui a été fait) et il nous est apparu qu'il fallait modifier trop de choses pour que cela fonctionne comme par exemple transférer la moitié de la logique métier dans des procédures stockées afin d'en obtenir des performances convenables. Le bogue concerné est le bogue 173130.

Red Hat avait une version de Bugzilla fonctionnant sous Oracle, mais c'était il y a très, très longtemps. Cette version (Bugzilla 2.8) est maintenant obsolète, peu sûre et elle n'est plus du tout prise en charge. Chez Red Hat, l'actuelle version de Bugzilla (basée sur Bugzilla 2.17.1) utilise PostgreSQL, et des actions sont en cours pour introduire ces changements dans la distribution principale (voir ci-dessus). À ce jour, nous ne connaissons pas de version de Bugzilla portée pour Oracle (à notre humble avis, Bugzilla n'a aucun besoin de ce qu'Oracle apporte).

Le bogue 237862 est intéressant à lire si vous souhaitez savoir comment progresse la compatibilité générale des bases de données.

Le chemin pour Perl indiqué dans la première ligne des scripts Bugzilla était /usr/bonsaitools/bin/perl car, lorsque Terry a commencé à écrire le code pour mozilla.org, il avait besoin de contrôler complètement une version de Perl ainsi que d'autres outils. Ce chemin a été abandonné dans la version 2.18 en faveur du chemin, plus raisonnable, /usr/bin/perl. Si vous aviez installé une ancienne version de Bugzilla et créé le lien symbolique que nous suggérions alors, vous pouvez maintenant supprimer ce dernier (pourvu que vous n'ayez rien d'autre, comme par exemple Bonsai, qui en fasse usage et que vous n'envisagiez pas de réinstaller une ancienne version de Bugzilla).

Le moyen le plus simple de résoudre ce problème est de créer un lien du premier répertoire vers le second : ln -s usr/local/bin/perl /usr/bin/perl. Si ce n'est pas possible, le petit morceau de Perl suivant remplacera toutes les premières lignes des fichiers (commençant par #! et contenant le chemin) par quelque chose d'autre :

perl -pi -e 's@#\!/usr/bin/perl@#\!/usr/local/bin/perl@' *cgi *pl

Malheureusement, cette ligne de commande ne fonctionnera pas sous windows à moins que vous ayez Cygwin. Cependant, MySQL contient un exécutable nommé replace qui se charge du travail :

C:\mysql\bin\replace "#!/usr/bin/perl" "#!C:\perl\bin\perl" -- *.cgi *.pl

	Note
	Si votre chemin vers Perl est encore différent, il vous suffit de remplacer /usr/local/bin/perl par votre propre chemin vers Perl dans les exemples ci-dessus.

Si vous utilisez Apache sous Windows, vous pouvez éviter tous ces problèmes en indiquant Registry (ou, si vous utilisez Apache dans une version ultérieure à 2, Registry-Strict) comme valeur de ScriptInterpreterSource. ScriptInterpreterSource a besoin d'une entrée de la base de registres « HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command » pour associer l'exécutable Perl aux fichiers .cgi. Si celle-ci n'existe pas encore, créez-en une avec une valeur par défaut de « chemin vers perl -T », par exemple « C:\Perl\bin\perl.exe -T ».

Pas pour le moment.

Pas pour le moment. Le travail visant à supprimer les variables globales et utiliser $cgi et DBI, progresse lentement. Tout cela est nécessaire à mod_perl (et est également une bonne chose, pour d'autres raisons). Consultez le bogue 87406 pour un aperçu de la question et des progrès.

Il utilise le web et la messagerie électronique.

Oui. Cependant, modifier certains champs, notamment ceux liés aux états de progression des bogues, nécessite aussi d'ajuster la logique du programme pour compenser le changement.

Il n'existe pas actuellement d'interface utilisateur graphique pour ajouter des champs à Bugzilla. Vous pouvez suivre le développement de cette fonctionnalité dans le bogue 91037

Oui. Consultez la page http://bugzilla.mozilla.org/reports.cgi, vous y trouverez des échantillons de ce que Bugzilla sait faire en terme de génération de rapports et de graphiques. Une documentation complète est fournie dans Section 11, « Rapports et diagrammes ».

Si vous n'obtenez pas les rapports désirés à partir des scripts de rapports fournis, vous pouvez inclure un paquetage professionnel pour les rapports comme par exemple Crystal Reports qui utilise ODBC. Si vous choisissez de procéder ainsi, soyez prudent car donner un accès direct à la base de données peut avoir des effets sur la sécurité. Même si vous donnez un accès en consultation seule à la base de données, il y aura contournement des éléments de sécurité des bogues de Bugzilla.

La notification par courrier électronique est paramétrable par l'utilisateur. Par défaut, l'identifiant du bogue et un résumé de son rapport accompagnent chaque notification par courrier électronique, ainsi qu'une liste des changements effectués.

Les courriers électroniques de Bugzilla sont envoyés en texte simple, le format de courrier le plus compatible de la planète.

Note

Si vous décidez d'utiliser les caractéristiques d'intégration de bugzilla_email pour permettre à Bugzilla d'enregistrer les réponses aux courriers électroniques avec les bogues associés, vous devrez peut-être prévenir vos utilisateurs de configurer leur logiciel de courrier électronique pour répondre aux messages dans le format où ils ont été reçus. Pour des raisons de sécurité, Bugzilla ignore les balises HTML en commentaire et si un utilisateur envoie un courrier électronique en HTML à Bugzilla, le commentaire en résultant sera assez affreux.

Bugzilla peut exporter des listes de bogues en HTML (par défaut), CSV ou RDF. Le lien pour le CSV se trouve à la fin de la liste de bogues au format HTML. On peut importer ce format CSV dans MS Excel ou dans un autre gestionnaire de feuilles de calculs.

Afin d'utiliser le format RDF de la liste de bogues, il est nécessaire d'ajouter un &ctype=rdf à l'URL. Le format RDF est censé n'être compréhensible que par une machine et, de ce fait, on considère que l'URL serait générée par programmation, c'est pourquoi il n'existe pas de lien vers ce format visible pour l'utilisateur.

Actuellement le seul script livré avec Bugzilla qui peut importer des données est importxml.pl qui est destiné à l'importation de données générées par le ctype XML de show_bug.cgi associé au déplacement de bogues. Les autres utilisations sont laissées à titre d'exercice.

Il y a aussi des scripts inclus dans le répertoire contrib/ pour l'utilisation des courriers électroniques afin d'importer des données dans Bugzilla, mais ces scripts ne sont pas pris en charge actuellement et sont inclus dans un but pédagogique.

Oui. Vous trouverez plus d'informations ainsi que les traductions disponibles à l'adresse http://www.bugzilla.org/download.html#localizations. Des modèles ont été définies pour certaines interfaces d'administration (afin de faciliter la localisation) mais beaucoup ne sont encore disponibles qu'en anglais. Il peut également y avoir des problèmes si le jeu de caractères n'est pas défini. Pour plus d'informations, reportez-vous au bogue 126226.

Oui. Non. Oui (grâce au format CSV).

MySQL, la base de donnée principale de Bugzilla, permet d'effectuer des sauvegardes des données à chaud. Vous trouverez des stratégies pour traiter des problèmes de sauvegarde à l'adresse http://www.mysql.com/doc/B/a/Backup.html

Si Bugzilla est configuré correctement dès le début, les besoins pour assurer la continuité de la maintenance sont minimes et peuvent être réalisés facilement via l'interface Web.

Les logiciels de suivi de bogues commerciaux dépassent généralement les $20,000 ou plus pour un nombre de 5 à 10 licences partagées. Des conseils pour Bugzilla sont donnés par les spécialistes, membres de la liste de diffusion. On y trouve tout de suite les réponses aux questions simples.

Cela dépend complètement de ce que vous voulez y mettre. Quelqu'un avec une grande expérience de Bugzilla peut tout mettre sur pied et en état de marche en moins d'une journée, et votre installation Bugzilla peut fonctionner sans attention particulière pendant des années. Si votre stratégie Bugzilla est cruciale par rapport à votre projet d'entreprise, embauchez quelqu'un avec des compétences raisonnables en Perl, ainsi qu'une connaissance du système d'exploitation sur lequel va tourner Bugzilla, et chargez cette personne de la conduite de votre gestion de processus, la maintenance et l'adaptation au niveau régional de votre suivi de bogues.

Non. Bugzilla, Perl, le Template Toolkit, ainsi que tout autre logiciel supplémentaire nécessaire au fonctionnement de Bugzilla, peut être téléchargé gratuitement. MySQL, la base de données utilisée par Bugzilla, est également libre, mais vous propose, si vous appréciez la valeur de leur produit, de souscrire à un contrat d'assistance qui convient à vos besoins.

Oui! Depuis Bugzilla 2.18, remplacer le mot 'bogue' par n'importe quel mot employé dans votre entreprise est chose simple. Reportez-vous à la documentation concernant la personnalisation [Customization] pour de plus amples détails, en particulier à Section 1.5, « Modèles particuliers ».

Bugzilla ne verrouille pas les entrées. Il permet la détection des accès concurrentiels, ce qui signifie qu'il avertit un utilisateur lorsqu'une validation de transaction (commit) est susceptible d'entrer en conflit avec une autre venant d'être effectuée par un autre utilisateur, et offre au deuxième utilisateur le choix des options pour traiter le conflit.

Oui. Mais les validations de transaction dans la base de données doivent attendre que les tables soient débloquées. Les bases de données Bugzilla sont généralement très petites et les sauvegardes prennent systématiquement moins d'une minute. Si votre base de données est plus vaste, vous souhaiterez probablement consulter d'autres techniques de sauvegarde, comme la duplication de base de données, ou encore sauvegarder depuis un miroir en lecture seule (à ce propos, veuillez consulter les documentations de MySQL sur le site de MySQL).

Lisez également les instructions de Exemple 3.1, « Mise à niveau par le CVS ».

Pour utiliser le statut « NON-CONFIRMÉ », le paramètre usevotes doit être activé (ON). Vous devez ensuite accéder à la page editproduct.cgi et régler le « nombre de voix qu'un bogue de ce produit doit recevoir afin de sortir automatiquement du statut NON-CONFIRMÉ » (Number of votes a bug in this product needs to automatically get out of the UNCONFIRMED state) à une valeur non-nulle. (Vous devrez faire de même pour chaque produit pour lequel vous voudrez utiliser le statut NON-CONFIRMÉ). Si en fait vous ne voulez pas que les utilisateurs puissent voter pour les bogues de ce produit, laissez le « nombre maximal de voix par personne » (Maximum votes per person) à zéro.

Le découplage du statut NON-CONFIRME par rapport au paramètre usevotes pour de prochaines versions de Bugzilla est en cours. Vous pouvez suivre le débat et l'avancement de ce travail sur le bogue 162060.

Exécutez MySQL comme suit : mysqld --skip-grant-tables. N'oubliez pas que cela rend MySQL aussi sûr que de scotcher un billet de 100 euros par terre dans les toilettes d'un stade de foot pour ne pas se le faire piquer.

	Avertissement
	On n'insistera jamais assez là-dessus : on ne vous conseille pas de le faire. Veuillez consulter Section 2, « MySQL » de ce guide ainsi que la documentation de MySQL afin de trouver de meilleures solutions.

Le code de Bugzilla a subi un audit de sécurité relativement complet, et les scripts CGI de présentation pour les utilisateurs sont exécutés avec l'option taint de Perl. Cependant il est recommandé d'examiner attentivement les permissions de votre installation de Bugzilla et de suivre les recommandations en matière de sécurité dans le guide Bugzilla.

L'utilisateur peut ordonner à Bugzilla d'arrêter de lui envoyer des courriels en décochant toutes les cases de la page Edit prefs+Email settings (depuis la version 2.18, cette opération est facilitée par l'ajout d'un bouton Disable All Mail, désactiver tous les envois de courriels) Autrement, vous pouvez ajouter leur adresse électronique au fichier data/nomail (une seule adresse par ligne). Cette option passe outre leurs préférences personnelles et ils ne recevront plus jamais de courriels de Bugzilla.

Pour désactiver l'envoi de courriels, réglez le paramètre

$enableSendMail

à 0 soit dans Bugmail.pm (pour les versions 2.18 et supérieures), soit dans processmail (jusqu'à la version 2.16.x)

Note

Jusqu'à une version 2.16.x, modifier $enableSendMail affectera seulement les courriels concernant un bogue; les courriels relatifs aux changements de mot de passe, d'adresse électronique, aux importations de bogues, aux changements d'options (flags), etc. seront toujours envoyés. Depuis la sortie de la version définitive 2.18, néanmoins, l'étape expliquée ci dessus désactivera tous les envois de courriels de Bugzilla quel qu'en soit le but.

Pour que les courriels relatifs aux bogues (et seulement ceux-ci) soient redirigés vers vous en lieu et place de leurs destinataires prévus, laissez $enableSendMail tranquille ; à la place, éditez le paramètre newchangedmail comme suit :

Pour d'anciennes versions de Bugzilla, vous devriez pouvoir appliquer le correctif de Klaas Freitag pour « whineatasigned », que l'on trouve dans le bogue 6679. Remarquez que ce correctif a été réalisé en 2000, un certain travail sera vraisemblablement nécessaire afin de l'appliquer proprement sur n'importe quelle version de Bugzilla plus récente, mais vous pouvez l'utiliser comme point de départ.

Il est prévu d'inclure à Bugzilla 2.20 une version mise à jour (et plus approfondie) de cette fonctionnalité; reportez vous au bogue 185090 pour suivre le débat ou pour obtenir des correctifs plus à jour si vous ne pouvez vraiment pas attendre.

Vous trouverez un fichier README.mailif mis à jour dans le répertoire contrib/ de votre distribution Bugzilla qui vous guidera dans la configuration.

Si vous utilisez sendmail, essayez d'activer sendmailnow dans editparams.cgi. Pour des versions plus anciennes de sendmail, on peut améliorer significativement les performances de l'interface utilisateur (au prix d'un retard dans l'envoi de courriel) en réglant ce paramètre sur off. Pour les sites avec une version 8.12 (ou supérieure) de sendmail, il vaut mieux le laisser sur on, puisqu'ils ne bénéficieront alors d'aucun gain de performance.

Si vous utilisez un gestionnaire de courrier électronique (ou MTA, Mail Transfer Agent) différent, assurez-vous que les options présentes dans Bugzilla/Bugmail.pm, ainsi que dans tous les autres endroits d'où est appelé sendmail, correspondent à l'emplacement de votre MTA.

Assurez vous que vous n'avez pas désactivé les courriers électroniques dans vos préférences d'utilisateur. Vérifiez que Bugzilla est capable d'envoyer des courriers électroniques en cliquant sur le lien « Connexion » (Log In) de votre installation Bugzilla puis en cliquant sur le bouton « Envoyez moi un mot de passe par courrier électronique » (E-mail me a password) après avoir saisi votre adresse électronique.

Si vous ne recevez pas de courrier électronique de Bugzilla, il y a des chances que vous n'ayez pas sendmail dans /usr/lib/sendmail. Assurez-vous que sendmail se trouve à l'intérieur ou qu'il existe un lien symbolique pointant vers lui dans /usr/lib/sendmail.

Si vous utilisez un autre MTA que sendmail, le paramètre sendmailnow doit être réglé sur on, sinon aucun courriel ne sera envoyé.

Exécutez l'utilitaire de « bilan de santé » (sanitycheck.cgi) via votre navigateur internet pour voir ! Si il se termine sans erreur, vous n'avez probablement aucun problème. S'il ne se termine pas bien (c'est à dire avec des messages en rouge), certaines choses peuvent être réparées par Bugzilla et d'autres non. Si la réparation est impossible, j'espère pour vous que vous avez l'habitude des commandes d'administration d'une base de données mysql ou bien que vous avez installé un autre moyen d'administrer votre base de données. Le bilan de santé, bien qu'étant un bon test de base pour vérifier l'intégrité de votre base de données, ne remplace en aucun cas une administration compétente de la base de données ni n'évite la suppression de données. Il n'est pas exhaustif et a été créé pour effectuer une vérification de base sur les problèmes les plus communs dans des bases de données Bugzilla.

Il n'existe pas de moyen de faire cela dans Bugzilla lui-même. De plus ce n'est généralement pas intelligent de le faire si l'on ne sait pas exactement ce qu'on veut faire. Cependant si vous connaissez le SQL, vous pouvez utiliser mysql en ligne de commande pour insérer, supprimer et modifier les informations d'une table à la main. Des clients graphiques plus intuitifs sont également disponibles. Les favoris de l'équipe Bugzilla sont phpMyAdmin et MySQL Control Center

Gardez à l'esprit que les sauvegardes sont vos amies. Tout le monde fait des erreurs, et il est agréable d'avoir un filet de sécurité dans le cas où vous sèmeriez la pagaille quelque part. Pensez à utiliser mysqldump pour faire un double de votre base de données avant de la modifier à la main.

Essayez d'exécuter MySQL à partir de son fichier exécutable : mysqld --skip-grant-tables. Cela vous permettra de complètement contourner les permissions sur les tables qui sont la cause de votre frustration. Si dans ce cas Bugzilla est capable de se connecter, vous devez vérifier que vous avez donné les bonnes permissions au couple utilisateur-mot de passe défini dans localconfig.

	Avertissement
	Exécuter MySQL avec cette option dans la ligne de commande n'est pas sûr du tout et doit être uniquement effectué dans le cadre d'une démarche de dépannage lorsque l'on n'est pas connecté au réseau extérieur.

En fait, vous pouvez synchroniser ou déplacer les bogues. La synchronisation s'opèrera uniquement dans un sens ; vous avez la possibilité de créer une copie de la base en lecture seule sur un site et la faire mettre à jour à partir de la base de données principale à intervalles réguliers.

MySQL intègre des fonctionnalités de synchronisation dans les dernières versions. Ce serait génial si quelqu'un se penchait sur les possibilités dans ce domaine et proposait un compte rendu sur le forum expliquant comment synchroniser efficacement deux installations de Bugzilla.

Si vous avez simplement besoin de transférer des bogues d'un Bugzilla à un autre, jetez un coup d'œil au script move.pl dans la distribution de Bugzilla.

Enlevez Windows. Installez Linux. Installez Bugzilla. Le chef ne verra jamais la différence B^).

Plus sérieusement, un des objectifs majeurs de ce grand cru 2.18 était de faire fonctionner Bugzilla facilement sous Windows. Si les composants nécessaires sont présents (perl, un serveur web, un MTA, etc.), l'installation de Bugzilla sur une station Windows ne devrait pas être plus difficile que sur une autre plateforme. Comme pour toute installation, nous vous recommandons de suivre complètement et avec beaucoup d'attention les instructions d'installation de Section 4.1, « Microsoft Windows ».

Ce faisant, n'oubliez pas de consulter cet excellent guide écrit par Byron Jones intitulé Installing Bugzilla on Microsoft Windows (Comment installer Bugzilla sous Microsoft Windows). Merci, Byron !

Pas pour le moment. Bundle::Bugzilla simplifie énormément l'installation de Bugzilla sur les systèmes UNIX. Si quelqu'un se porte volontaire pour réaliser un bundle PPM ^[1] qui convient à Win32, une telle initiative sera appréciée.

En fonction du serveur web que vous utilisez, vous devez configurer celui-ci pour traiter les fichiers *.cgi comme des scripts CGI. Pour IIS, vous pouvez faire cela en ajoutant *.cgi dans la mise en correspondance des applications avec <chemin>\perl.exe %s %s comme exécutable.

Microsoft donne quelques indications à ce sujet, que voici :

Vos modules sont peut-être obsolètes ou inappropriés. Essayez ce qui suit :

Nouveau dans la version 2.16 : allez dans la section compte dans les préférences. Vous recevrez un courrier électronique aux deux adresses pour confirmation.

L'interface a été simplifiée par un concepteur d'interfaces dans la version 2.16. Les suggestions d'amélioration sont les bienvenues, mais nous ne sacrifierons pas la puissance à la simplicité.

Depuis la version 2.18, une recherche « plus simple » est également disponible. En haut de la page de recherche il y a deux liens : « Recherche avancée » (Advanced search) vous conduit à la page de recherche la plus puissante, que vous connaissez bien, mais aussi la plus complexe. Le lien « Chercher un bogue en particulier » (Find a specific Bug) vous amène sur une page très simplifiée où vous pouvez choisir un produit et un statut (ouvert OPEN, fermé CLOSED ou les deux), vous pourrez ensuite entrer les mots qui apparaissent dans le bogue que vous cherchez. Cette recherche ira fouiller les champs « Résumé » (Summary) et « Commentaires » (Comments), et renverra une liste de bogues triés, de sorte que les bogues comportant le plus de coïncidences/correspondances se trouvent en début de liste.

	Note
	Les correspondances issues du champ Summary prendront le pas sur celles du champ Comments et les bogues comportant des correspondances dans le champ Summary seront placés plus haut dans la liste de bogue, même si un bogue classé en dessous présente plus de correspondances dans le champ commentaires.

Bugzilla utilise un cookie afin de se souvenir quelle version d'une page vous avez visitée en dernier et ressortira cette page lors de votre recherche suivante. La page par défaut pour les nouveaux utilisateurs (ou après une mise à jour) est la page de recherche « simple ».

Le comportement actuel convient à bugzilla.mozilla.org ainsi qu'à la plupart des utilisateurs. Si vous désirez changer ce comportement malgré tout, vous pouvez utiliser un des correctifs suivants :

Le bogue 35195 vise à ajouter une case à cocher « ... et accepter les bogues » (... and accept the bug) à l'interface utilisateur. Deux correctifs lui sont attachés : le correctif 8029 fut créé à la base pour Bugzilla 2.12, tandis que le correctif 91372 en est une version mise à jour pour Bugzilla 2.16.

Le bogue 37613 fournit lui aussi deux correctifs (pour Bugzilla 2.12) : l'un pour ajouter une option « Admettre le bogue » (Take Bug), l'autre afin de réassigner automatiquement le bogue lorsqu'il est accepté.

Ces correctifs commencent maintenant à dater un peu et ne peuvent être appliqués directement, mais ils sont suffisamment simples pour montrer comment Bugzilla peut être personnalisé et mis à jour afin de correspondre à vos besoins.

La cause la plus probable est que vous utilisez un très vieux navigateur ou un navigateur incompatible avec le téléchargement de fichiers vers le serveur via POST. Téléchargez la dernière version de votre navigateur internet préféré pour effectuer les téléchargements vers le serveur correctement.

Dans l'interface administrateur de Bugzilla, éditez le mot-clé — vous pouvez ainsi remplacer l'ancien mot-clé par le nouveau. Cela causera un problème avec la mémoire cache des mots-clés. Exécutez sanitycheck.cgi pour le résoudre.

La réponse est simple : si, vous pouvez le faire.

Le mécanisme derrière la page vérifie chaque bogue dans la liste pour déterminer les changements d'états autorisés, et c'est seulement ensuite qu'elle vous montre les commandes permettant de réaliser les actions applicables à chaque bogue de la liste. La raison est que si vous essayez d'effectuer une action non autorisée sur un bogue, le processus entier va s'arrêter net et tous les changements effectués après celui qui a échoué vont eux aussi échouer, ce qui n'est pas satisfaisant du tout, et c'est pourquoi la page ne vous propose même pas cette option.

En français courant, cela signifie que chaque bogue de la page doit être soit déjà résolu (RESOLVED) soit déjà vérifié (VERIFIED), afin de déclarer plusieurs bogues clos (CLOSED) ; si ce n'est pas le cas, l'option permettant de fermer les bogues n'apparaîtra pas sur la page.

Ceci repose sur la logique suivante : si vous essayez de fermer un bogue qui n'a pas été vérifié, la mise à jour du bogue échouera lamentablement (et ainsi détruira tout changement suivant dans la liste pendant l'opération globale de changement), ce qui ne vous donne donc même pas le choix.

Gerv et Myk suggèrent d'utiliser une indentation de deux espaces, avec les sections de code imbriquées sur leur propre ligne, en ligne avec les balises externes.

<fred>
[% IF foo %]
  <bar>
  [% FOREACH x = barney %]
    <tr>
      <td>
        [% x %]
      </td>
    <tr>
  [% END %]
[% END %]
</fred>

Myk recommande en outre d'activer PRE_CHOMP dans l'initialisation de modèles afin d'éviter de surcharger le code HTML avec des espaces inutiles.

Veuillez noter qu'il y a de nombreux avis divergents à ce sujet, et les templates existant dans Bugzilla respectent à la fois la convention ci-dessus et la convention à 4 espaces. Les deux sont acceptables ; on préfère celle que nous présentons ici.

Consultez ce lien pour voir les bogues actuels ou les demandes d'amélioration de Bugzilla.

Vous pouvez consulter des bogues marqués pour la version 2.18.1 ici. Cette liste contient les bogues de la version 2.18.1 qui ont déjà été corrigés et consignés dans le CVS. Vous trouverez sur la page du projet Bugzilla pour des informations sur la manière de trouver les sources actuelles sur le CVS pour pouvoir récupérer ces corrections.

Ce point est bien documenté dans le bogue 49862. En fin de compte, ce n'est pas plus compliqué que d'ajouter le champ de priorité « --- » à l'endroit approprié de votre fichier localconfig, de relancer checksetup.pl, puis de changer la priorité par défaut dans votre navigateur au moyen de editparams.cgi.