3.1. Configuration de Bugzilla

Bugzilla se configure en changeant divers paramètres accessibles à partir du lien « Paramètres » de la page Administration (la page Administration est accessible en cliquant sur le lien « Administration » dans le pied de page). Les paramètres sont divisés en plusieurs catégories, accessibles par le menu à gauche. Vous trouverez ci-dessous une description des différentes catégories et de leurs paramètres importants.

3.1.1. Paramètres requis

Les paramètres principaux obligatoires pour une installation de Bugzilla sont définis ici. Ces paramètres doivent être définis avant qu'une nouvelle installation de Bugzilla soit fonctionnelle. Les administrateurs doivent revoir cette liste avant de déployer une nouvelle installation de Bugzilla.

maintainer

Adresse électronique de la personne responsable de la maintenance de cette installation de Bugzilla. L'adresse n'est pas nécessairement celle d'un compte Bugzilla valide.

urlbase

Définit le nom de domaine complet et le chemin d'accès du serveur Web de cette installation de Bugzilla.

Par exemple, si la page de recherche est http://www.toto.com/bugzilla/query.cgi, « urlbase » doit être défini à http://www.toto.com/bugzilla/.

docs_urlbase

Définit le chemin d'accès à la documentation de Bugzilla. Cela peut-être un chemin d'accès absolu ou relatif à « urlbase ».

Par exemple, si la page « Configuration de Bugzilla » de la documentation est http://www.toto.com/bugzilla/docs/html/parameters.html, définissez « docs_urlbase » à http://www.toto.com/bugzilla/docs/html/.

sslbase

Définit le nom de domaine complet et le chemin d'accès au serveur Web pour les connexions HTTPS (SSL) de cette installation de Bugzilla.

Par exemple, si la page principale de Bugzilla est https://www.toto.com/bugzilla/index.cgi, « sslbase » doit être défini à https://www.toto.com/bugzilla/.

ssl_redirect

Quand ceci est activé, Bugzilla forcera des connexions HTTPS (SSL), en redirigeant automatiquement tout utilisateur essayant d'utiliserune connexion non-SSL.

cookiedomain

Définit le domaine pour les cookies de Bugzilla. Ceci est typiquement laissé vide. S'il y a plusieurs noms d'hôtes qui pointent vers le même serveur Web, qui nécessitent le même cookie, alors ce paramètre peut être utilisé. Par exemple, si votre site Web est https://www.toto.com/, définir ce paramètre à .toto.com/ permettra aussi à titi.toto.com/ d'accéder aux cookies de Bugzilla.

cookiepath

Définit un chemin, relatif à la racine du serveur Web, auquel seront restreints les cookies de Bugzilla. Par exemple, si urlbase est défini à http://www.toto.com/bugzilla/, cookiepath devrait être défini à /bugzilla/. Définir ceci à « / » permettra à tous les sites servis par ce serveur Web ou cet hôte virtuel de lire les cookies de Bugzilla.

utf8

Détermine l'utilisation de l'encodage UTF-8 (Unicode) pour tout texte dans Bugzilla. Les nouvelles installations devraient définir ce paramètre à « Activé » pour éviter les problèmes d'encodage de caractères. Les bases de données existantes ne devraient définir ceci à « Activé » qu'après que les données aient été converties de l'encodage existant vers UTF-8, en utilisant le script contrib/recode.pl.

Note

Si vous passez ce paramètre de « Désactivé » à « Activé », vous devez ré-exécuter checksetup.pl immédiatement après.

shutdownhtml

S'il y a du texte dans ce champ, cette installation de Bugzilla sera totalement désactivée et ce texte apparaîtra à la place de toutes les pages de Bugzilla pour tous les utilisateurs, y compris les administrateurs. À utiliser dans le cadre d'une maintenance du site ou de problèmes.

Note

Bien que toute possibilité de connexion soit impossible quand shutdownhtml est activé, des garde-fous sont en place pour protéger le malachanceux administrateur qui perd sa connexion à Bugzilla. Si cela vous arrivait, allez directement dans editparams.cgi (en tapant l'URL manuellement, si nécessaire). En faisant cela vous serez invité à vous connecter, et vos nom et mot de passe seront acceptés ici (mais seulement ici).

announcehtml

Tout texte dans ce champ sera affiché en haut de chaque page HTML de cette installation de Bugzilla. Ce texte n'est pas encadré dans des balises. Pour de meilleurs résultats, encadrez le texte avec des balises « <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 »). Certaines installations de Bugzilla n'autorisent que des noms d'utilisateurs locaux (par ex. « utilisateur » au lieu de « utilisateur@exemple.com »). Dans ce cas, le paramètre emailsuffix doit être utilisé pour définir le domaine des adresses électroniques.

emailsuffix

Cette chaîne est ajoutée aux noms de connexion lors de l'envoi d'un courriel à un utilisateur. Par exemple, si emailregexp a été défini pour permettre les noms d'utilisateurs locaux, alors ce paramètre doit contenir le domaine des adresses électroniques pour tous les utilisateurs (par ex. « @exemple.com »).

3.1.4. Fichiers joints

Cette page permet la définition des restrictions et d'autres paramètres concernant les fichiers joints aux bogues. Par exemple, le contrôle des limitations de taille et l'autorisation de pointer vers des fichiers externes via une URI.

3.1.5. Politique de modification des bogues

Définit la politique sur le comportement par défaut des événements de modification de bogues. Par exemple, choisir l'état dans lequel mettre un bogue quand celui-ci est marqué comme doublon, et choisir d'autoriser si les rapporteurs de bogues peuvent définir la priorité ou le jalon cible. Permet aussi la configuration des changements qui nécessitent un commentaire de la part des utilisateurs, décrit ci-dessous.

commenton*

Tous ces champs vous permettent de définir quels changements peuvent être faits sans commentaire, et ceux qui doivent avoir un commentaire de la personne qui fait les changements. Souvent, les administrateurs autoriseront les utilisateurs à s'ajouter à la liste « Copie à », à accepter les bogues ou à modifier le Tableau blanc sans ajouter de commentaire pour justifier les changements, et demanderont que la plupart des autres changements soit justifiés.

Définissez les options « commenton » selon la politique de votre site. Il est sage de demander des commentaires quand les utilisateurs résolvent, réassignent ou rouvrent des bogues, au minimum.

Note

Il est généralement bien mieux de demander un commentaire au développeur lors de la résolution des bogues. Il y a peu de choses plus ennuyeuses pour les utilisateurs d'une base de données de bogues, que d'avoir un développeur marquant un bogue « CORRIGÉ » sans commentaire sur le correctif (ou même si cela a vraiment été corrigé !)

noresolveonopenblockers

Cette option empêchera les utilisateurs de résoudre les bogues en CORRIGÉ s'il y a des dépendances non résolues. Seule la résolution CORRIGÉ est affectée. Les utilisateurs seront encore capables de résoudre les bogues avec des résolutions autres que CORRIGÉ s'il reste des bogues dépendants non résolus.

3.1.6. Champs des bogues

Les paramètres dans cette section déterminent le choix par défaut de plusieurs champs de Bugzilla pour les nouveaux bogues et contrôlent aussi si certains champs sont utilisés ou pas. Par exemple, l'utilisation des champs « Jalon cible » ou « Tableau blanc ».

useqacontact

Ceci permet de définir une adresse électronique pour chaque composant, en plus de celle du responsable par défaut, à laquelle seront envoyées les copies de courriel de bogues.

usestatuswhiteboard

Ceci définit si vous souhaitez avoir un champ de formulaire libre et modifiable associé à chaque bogue. L'avantage de ce tableau blanc est qu'il peut être effacé ou modifié facilement, et qu'il fournit un champ de recherche facile pour indexer des bogues qui ont des traits communs.

3.1.7. Déplacement de bogue

Cette page définit si certains utilisateurs de cette installation de Bugzilla sont autorisés à déplacer des bogues vers une base de données externe. Si le déplacement de bogue est activé, il y a de nombreux paramètres qui contrôlent le comportement du déplacement de bogue. Par exemple, le choix des utilisateurs autorisés à déplacer les bogues, l'emplacement de la base de données externe, et le produit et le composant par défaut pour les bogues déplacés à partir d'autres bases de données de bogues vers cette installation de Bugzilla.

3.1.8. Graphiques de dépendances

Cette page a un paramètre qui définit l'emplacement d'un serveur Web Dot, ou du binaire Web Dot sur le système local, qui est utilisé pour générer des graphiques de dépendance. Web Dot est un programme CGI qui crée des images à partir des fichiers de description graphique .dot. Si aucun serveur ou binaire Web Dot n'est spécifié, alors les graphiques de dépendance seront désactivés.

3.1.9. Restrictions de groupe

Bugzilla permet la création de différents groupes, avec la possibilité de restreindre la visibilité des bogues dans un groupe à un ensemble d'utilisateurs spécifiques. Des produits spécifiques peuvent aussi être associés à des groupes, et des utilisateurs restreints à ne voir les produits que dans leurs groupes. Plusieurs paramètres sont décrits plus en détail ci-dessous. La plupart de la configuration des groupes et leurs relations aux produits est faite dans les pages « Groupes » et « Produit » dans la zone « Administration ». Les options sur cette page contrôlent les comportements globaux par défaut. Pour plus d'informations sur les Groupes et les restrictions de groupes, consulter Section 3.15

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.

querysharegroup

Le nom du groupe d'utilisateurs autorisés à partager leurs recherches enregistrées avec d'autres. Pour plus d'informations sur l'utilisation des recherches enregistrées, consulter Recherches enregistrées.

3.1.10. LDAP

L'authentification LDAP est un module pour l'architecture de plugin d'authentification de Bugzilla. Cette page contient tous les paramètres nécessaires pour configurer Bugzilla en utilisant l'authentification LDAP.

Le schéma d'authentification existant de Bugzilla utilise les adresses électroniques comme identifiant primaire de l'utilisateur et un mot de passe pour authentifier cet utilisateur. Tous les endroits dans Bugzilla qui nécessitent un identifiant d'utilisateur (par ex. pour assigner un bogue) utilisent l'adresse électronique. L'authentification LDAP se situe au-dessus de ce schéma et ne le remplace pas. La connexion initiale est faite avec un nom d'utilisateur et un mot de passe pour l'annuaire LDAP. Bugzilla essaie de se lier à LDAP en utilisant les crédentiels et, s'il réussit, essaie d'associer ce compte à un compte Bugzilla. Si un attribut LDAP d'adresse électronique est défini, la valeur de cet attribut est utilisé, sinon, le paramètre « emailsuffix » est ajouté au nom d'utilisateur LDAP pour former l'adresse électronique complète. Si un compte pour cette adresse existe déjà dans l'installation de Bugzilla, il se connectera avec ce compte. Si aucun compte pour cette adresse électronique n'existe, il en sera créé un au moment de la connexion. (Dans ce cas, Bugzilla essaiera d'utiliser l'attribut « displayName » ou « cn » pour déterminer le nom complet de l'utilisateur). Après l'authentification, toutes les tâches liées à l'utilisateur seront toujours manipulées par l'adresse électronique et pas par le nom d'utilisateur LDAP. Par exemple, les bogues sont encore assignés par l'adresse électronique et les utilisateurs recherchés par leur adresse électronique.

Attention

Parce qu'un compte Bugzilla n'est pas créé jusqu'à ce que l'utilisateur se connecte pour la première fois, un utilisateur qui ne s'est pas encore connecté est inconnu de Bugzilla. Ceci signifie qu'il ne peut pas être utilisé comme Responsable ou Contact QA (par défaut ou non), ajouté à la liste « Copie à » ou toute autre opération de ce type. Un contournement possible est le script bugzilla_ldapsync.rb dans le répertoire contrib. Une autre solution est de résoudre le bogue 201069.

Paramètres nécessaires pour utiliser l'authentification LDAP :

user_verify_class

Si vous voulez lister « LDAP » ici, assurez-vous d'avoir défini les autres paramètres listés ci-dessous. À moins d'avoir d'autres méthodes d'authentification (qui fonctionnent) listées aussi, vous ne pourrez pas vous reconnecter à Bugzilla une fois déconnecté. Si cela vous arrive, vous devrez modifier manuellement data/params et définir « user_verify_class » à « DB ».

LDAPserver

Ce paramètre doit être défini avec le nom (et optionnellement le port) de votre serveur LDAP. Si aucun port n'est spécifié, le port LDAP par défaut 389 sera utilisé.

Par exemple : « ldap.societe.com » ou « ldap.societe.com:3268 »

Vous pouvez également spécifier une URI LDAP, tout comme utiliser d'autre protocoles, tels que LDAPS ou LDAPI. Si le port n'était pas spécifié dans l'URI, le défaut est 389 pour « LDAP » et 636 pour « LDAPS ».

Astuce

Afin d'utiliser SSL avec LDAP, indiquez une URI avec « ldaps:// » Ceci forcera l'utilisation de SSL sur le port 636.

Par exemple, pour LDAP non sécurisé : « ldap://ldap.societe.com », pour LDAP avec SSL : « ldaps://ldap.societe.com » ou pour LDAP sur un socket de domaine Unix : « ldapi://%2fvar%2flib%2fldap_sock ».

LDAPbinddn [Optionnel]

Certains serveurs LDAP une liaison anonyme pour faire des recherches dans l'annuaire. Si c'est le cas pour votre configuration, vous devrez définir le paramètre « LDAPbinddn » pour le compte utilisateur que Bugzilla doit utiliser à la place de la liaison anonyme.

Ex. : « cn=default,cn=utilisateur:mot_de_passe »

LDAPBaseDN

Le paramètre « LDAPBaseDN » doit être défini pour indiquer l'emplacement dans votre arbre LDAP où vous voulez faire la recherche des adresses électroniques. Les « uid » doivent être uniques sous le « DN » indiqué ici.

Ex. : « ou=Personne,o=Societe »

LDAPuidattribute

Le paramètre « LDAPuidattribute » doit être défini sur l'attribut qui contient les « UID » uniques de vos utilisateurs. La valeur récupérée de cet attribut sera utilisée lors de la tentative de liaison des utilisateurs pour confirmer leur mots de passe.

Ex. : « uid »

LDAPmailattribute

Le paramètre « LDAPmailattribute » doit être le nom de l'attribut qui contient l'adresse électronique que vos utilisateurs saisiront pour se connecter dans les boîtes de connexion de Bugzilla.

Ex. : « mail »

3.1.11. Authentification RADIUS

L'authentification RADIUS est un module pour l'architecture de plugin d'authentification de Bugzilla. Cette page contient tous les paramètres nécessaires pour configurer Bugzilla en utilisant l'authentification RADIUS.

Note

La plupart des avertissements concernant l'authentification LDAP s'applique aussi à l'authentification RADIUS. Consulter Section 3.1.10 pour des détails.

Paramètres requis pour utiliser l'Authentification RADIUS :

user_verify_class

Si vous voulez lister « RADIUS » ici, assurez-vous d'avoir défini les autres paramètres listés ci-dessous. À moins d'avoir d'autres méthodes d'authentification (en fonction) listées aussi, vous pourriez ne pas être en mesure de vous reconnecter à Bugzilla après déconnexion. Si cela se produisait, vous devriez modifier manuellement le fichier data/params et définir le paramètre « user_verify_class » à « DB ».

RADIUS_server

Ce paramètre doit être renseigné avec le nom (et optionnellement le port) de votre serveur RADIUS.

RADIUS_secret

Ce paramètre doit être renseigné avec le secret du serveur RADIUS.

RADIUS_email_suffix

Bugzilla a besoin d'une adresse électronique pour chaque compte utilisateur. Par conséquent, il a besoin de déterminer l'adresse électronique correspondant à un utilisateur RADIUS. Bugzilla ne propose qu'un simple moyen de faire cela : il concatène un suffixe au nom d'utilisateur RADIUS pour le convertir en adresse électronique. Vous pouvez indiquer ce suffixe dans le paramètre « RADIUS_email_suffix ».

Si cette solution ne fonctionne pas pour vous, vous devrez certainement modifier Bugzilla/Auth/Verify/RADIUS.pm pour que cela corresponde à vos besoins.

3.1.12. Courriel

Cette page contient tous les paramètres pour configurer la façon dont Bugzilla traitent les notifications par courriel qu'il envoie. Voir ci-dessous pour un résumé des options importantes.

mail_delivery_method

Ce paramètre est utilisé pour indiquer comment sont envoyés les courriels ou s'il ne faut pas les envoyer. Il y a plusieurs options pour les différents MTA, avec deux options supplémentaires qui désactivent l'envoi de courriels. « testfile » n'envoie pas les courriels mais les enregistre dans data/mailer.testfile pour qu'ils soient consultés plus tard. « none » désactive totalement l'envoi de courriels.

mailfrom

C'est l'adresse électronique qui apparaîtra dans le champ « De » pour tous les courriels envoyés par cette installation de Bugzilla. Certains serveurs de messagerie nécessitent une adresse électronique valide ; par conséquent, il est recommandé de choisir une adresse électronique valide ici.

smtpserver

C'est l'adresse du serveur SMTP, si le paramètre « mail_delivery_method » est défini pour SMTP. Utiliser « localhost » si vous utilisez un MTA local, ou le nom du serveur SMTP distant. Ajouter « : » et le numéro de port s'il ne s'agit pas du numéro de port par défaut.

smtp_username

Nom d'utilisateur à utiliser pour l'authentification SASL sur le serveur SMTP. Laisser ce paramètre vide si le serveur ne nécessite pas d'authentification.

smtp_password

Mot de passe à utiliser pour l'authentification SASL sur le serveur SMTP. Ce paramètre sera ignoré si le paramètre « smtp_username » est laissé vide.

smtp_ssl

Active la gestion de SSL pour la connexion au serveur SMTP.

smtp_debug

Ce paramètre permet d'activer le débogage détaillé. Les messages sont indiqués dans le journal d'erreur du serveur Web.

whinedays

Ceci indique le nombre de jours pendant lequel les bogues sont dans l'état CONFIRMÉ avant de notifier les personnes qu'elles ont de nouveaux bogues qui n'ont pas été touchés. Si vous ne comptez pas utiliser cette focntionnalité, ne définissez pas la tâche de notification « cron » décrite dans les instructions d'installation ou définissez cette valeur à « 0 » (ne jamais notifier).

globalwatcher

Ceci permet de définir des utilisateurs spécifiques qui recevront une notification chaque fois qu'un nouveau bogue est saisi ou lors de changements sur un bogue existant, en fonction des permissions de l'ensemble des groupes. Cela peut-être utile pour envoyer les notifications sur une liste de diffusion par exemple.

3.1.13. Visionneuse de correctif

Cette page contient les paramètres de configuration pour le serveur CVS, le serveur Bonsai et le serveur LXR que Bugzilla utilisera pour activer les fonctionnalités de la visionneuse de correctif. Bonsai est un outil qui permet de faire des requêtes sur un arbre CVS. LXR est un outil qui permet de faire des références croisées et d'indexer du code source.

3.1.14. Options par défaut des requêtes

Cette page contrôle le comportement par défaut de Bugzilla concernant plusieurs aspects des requêtes sur les bogues. Les options comprennent ce que sont les options de requête par défaut, ce que renvoie la page « Mes bogues », si les utilisateurs peuvent ajouter librement des bogues à la liste de citations, et le nombre de doublons de bogues nécessaire pour ajouter un bogue à la liste des « bogues les plus fréquemment rapportés ».

3.1.15. Base de données esclave

Cette page contrôle si une base de données esclave est utilisée et tous les paramètres associés à cette base de données. Les versions de Bugzilla antérieures à la version 3.2 utilisaient des types de tables MyISAM, qui ne supportent que le verrouillage en écriture au niveau de la table. Avec MyISAM, chaque fois que quelqu'un fait un changement dans un bogue, la table entière est verrouillée jusqu'à ce que l'opération d'écriture soit terminée. Le verrouillage pour l'écriture bloque aussi les lectures jusqu'à ce que l'opération d'écriture soit terminée.

Le paramètre « shadowdb » a été conçu pour contourner cette limitation. Alors qu'un seul utilisateur à la fois est autorisé à écrire sur une table à un moment donné, les lectures peuvent continuer sans interruption sur une base de données esclave en lecture seule.

Note

À partir de la version 3.2, Bugzilla n'utilise plus de type de table MyISAM. À la place, il utilise InnoDB, qui peut faire des verrouillages au niveau de la transaction. Par conséquent, les limitations pour lesquelles la fonctionnalité de base de données esclave avait été conçue comme moyen de contournement, n'existent plus.

3.1.16. Correspondance d'utilisateur

Les paramètres de cette page contrôlent la façon dont les utilisateurs sont sélectionnés et recherchés lors de l'ajout d'un utilisateur à un bogue. Par exemple, les utilisateurs doivent être sélectionnés lors du choix d'un responsable de bogue, de l'ajout à la liste « Copie à » ou lors de la sélection du Contact QA. Avec le paramètre « usemenuforusers », il est possible de configurer Bugzilla pour afficher une liste des utilisateurs dans les champs plutôt qu'un champ de texte vide. Ceci ne doit être utilisé que pour des installations de Bugzilla ayant un petit nombre d'utilisateurs. Si les utilisateurs sont sélectionnés via une boîte de texte, cette page contient aussi les paramètres sur la façon dont les utilisateurs sont recherchés et le mode de correspondance lors de la saisie.

Un autre paramètre appelé 'ajax_user_autocompletion' permet dans certains champs d'utilisateur d'afficher une liste déroulante de noms d'utilisateurs correspondants après avoir saisi quelques caractères. Il est recommandé d'utiliser mod_perl quand 'ajax_user_autocompletion' est activé.