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.
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.
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.
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 malchanceux 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).
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.
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.
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.
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.
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é !)
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.
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.
Cette page contient 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 les graphes de dépendances. Web Dot est un programme CGI qui crée des images à partir de fichiers de description graphiques .dot. Si aucun serveur Web Dot ou binaire n'est spécifié, les graphes de dépendances seront désactivés.
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 Groupes et restrictions de groupes
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 :
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.
Note
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.
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 LDAP pour des détails.
Paramètres requis pour utiliser l'Authentification RADIUS :
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.
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.
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.
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.
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é.
À 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.
Note
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).
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.
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 Configuration de Bugzilla.
Les utilisateurs ayant le privilège editusers, tels que les administrateurs, peuvent créer des comptes pour d'autres utilisateurs :
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.
Remplissez le formulaire présenté. Cette page est explicite. Quand c'est terminé, cliquez sur Soumettre.
Note
Ajouter un utilisateur de cette façon n'enverra pas un courriel l'informant de son nom d'utilisateur et de son mot de passe. Alors que c'est utile pour créer des comptes génériques (des scrutateurs qui redirigent les courriels vers un autre système par exemple ou des adresses électroniques qui sont des listes de diffusion), en général, il est préférable de se déconnecter et d'utiliser le bouton Nouveau compte pour créer des utilisateurs car cela pré-remplira tous les champs requis et notifiera également l'utilisateur de son nom de compte et de son mot de passe.
Quand vous avez trouvé votre utilisateur, vous pouvez changer les champs suivants :
Nom de connexion : Ceci est généralement l'adresse électronique complète de l'utilisateur. Cependant, si vous utilisez le paramètre emailsuffix, ceci peut être juste le nom de connexion de l'utilisateur. Notez que les utilisateurs peuvent à présent changer leur nom de connexion eux-mêmes (pour une adresse électronique valide).
Nom réel : Le nom réel de l'utilisateur. Notez que Bugzilla n'a pas besoin de ceci pour créer un compte.
Mot de passe : Vous pouvez changer le mot de passe de l'utilisateur ici. Les utilisateurs peuvent automatiquement demander un nouveau mot de passe ; vous ne devriez donc pas avoir besoin de faire cela souvent. Si vous voulez désactiver un compte, voir Texte de désactivation ci-dessous.
Courriel de bogues désactivé : Cochez cette case pour déscativer les courriels de bogues et de notification totalement pour ce compte. Cette case à cocher remplace le fichier data/nomail existant dans les versions précédentes de Bugzilla.
Texte de désactivation : Si vous saisissez quoi que ce soit dans cette boîte, y compris juste une espace, l'utilisateur ne pourra pas se connecter ou faire des modifications de bogues via l'interface Web. Le code HTML que vous saisissez dans cette boîte sera affiché à l'utilisateur quand il essaiera de faire ces actions et doit expliquer pourquoi le compte a été désactivé. Les utilisateurs ayant leur compte désactivé continueront à recevoir des courriels de Bugzilla ; de plus, ils ne pourront pas se connecter eux-mêmes pour changer leurs préférences et arrêter l'envoi de courriels. Si vous voulez qu'un compte (désactivé ou activé) arrête de recevoir les courriels, cochez la case Courriel de bogues désactivé ci-dessus.
Note
Même les utilisateurs ayant leur compte désactivé peuvent encore soumettre des bogues par l'intermédiaire de la passerelle de courriels, si elle existe. La passerelle de courriels ne devrait pas être activée pour les installations sécurisées de Bugzilla.
Attention
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.
Si le paramètre allowuserdeletion est activé, voir 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 !
Il y a des fois où un administrateur veut accomplir des actions en tant qu'un autre utilisateur. La fonctionnalité sudo peut être utilisée pour faire cela.
Note
Pour utiliser la fonctionnalité sudo, vous devez être dans le groupe bz_sudoers. Par défaut, tous les administrateurs sont dans ce groupe.
Si vous voulez utiliser cette fonctionnalité, vous devez démarrer une session en allant sur la page de modification des utilisateurs, rechercher un utilisateur et cliquer sur son nom de connexion. Vous devriez voir un lien sous son nom de connexion intitulé Prendre la place de cet utilisateur. Cliquez sur le lien. Ceci vous amènera sur une page décrivant la fonctionnalité et les instructions pour l'utiliser. Après avoir lu le texte, saisissez le nom de connexion de l'utilisateur dont vous voulez usurper l'identité, fournissez un court message expliquant pourquoi vous faites cela, et appuyez sur le bouton.
Tant que vous utiliserez cette fonctionnalité, tout ce que vous ferez sera vu comme si vous étiez connecté avec le compte utilisateur dont vous usurpez l'identité.
Attention
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é.
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.
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 :
Lors de la modification d'un produit, il y a également un lien pour modifier les restrictions de groupes, voir Affecter des restrictions de groupes à des produits.
Pour créer un nouveau produit :
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.
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 Versions.
Pour plus d'informations sur les jalons, consultez Jalons.
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 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 Applications courantes des restrictions de groupe pour des exemples de relations entre produit et groupe.
Note
Les produits et les groupes ne sont pas limités à une relation un pour un. Plusieurs groupes peuvent être associés au même produit et les groupes peuvent être associés à plus d'un produit.
Si un groupe a Entry sélectionné, alors le produit restreindra la saisie de bogues aux seuls utilisateurs membres de groupes ayant entry sélectionné.
Si un groupe a canedit sélectionné, alors le produit sera en lecture seule pour tous les utilisateurs qui ne sont pas membres de tous les groupes ayant canedit sélectionné. Seuls les utilisateurs qui sont membres de tous les groupes ayant canedit sélectionné seront capables de modifier. C'est une restriction additionnelle qui limite encore plus ce qui peut être modifié par un utilisateur.
Les paramètres suivants vous permettent de choisir les privilèges par produit. C'est un moyen pratique pour donner des privilèges à certains utilisateurs pour certains produits seulement, sans avoir à leur donner de privilèges globaux qui affecteraient tous les produits.
Les groupes ayant editcomponents sélectionné permettent aux utilisateurs membres de ces groupes de modifier tous les aspects de ce produit, y compris les composants, les jalons et les versions.
Les groupes ayant canconfirm sélectionné permettent aux utilisateurs membres de ces groupes de confirmer les bogues dans ce produit.
Les groupes ayant editbugs sélectionné permettent aux utilisateurs membres de ces groupes de modifier tous les champs de bogue dans ce produit.
Les champs MemberControl et OtherControl sont utilisés en tandem pour déterminer quels bogues seront placés dans ce groupe. Les seules combinaisons autorisées de ces deux paramètres sont listées dans un tableau dans la page Modifier les restrictions de de groupe. Consultez ce tableau pour des détails sur la façon d'utiliser ces champs. Des exemples de différentes utilisations sont décrits ci-dessous.
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.
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É
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
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 :
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
Quelquefois, un produit est retiré et par conséquent, on ne devrait pas pouvoir saisir de bogues pour celui-ci (par exemple, une ancienne version d'un logiciel qui n'est plus supportée). Un produit peut être mis en lecture seule en créant un groupe appelé LectureSeule et en ajoutant les produits dedans quand c'est nécessaire :
Produit A:
LectureSeule: ENTRY, NON APPLICABLE/NON APPLICABLE, CANEDIT
Note
Pour plus d'informations sur les groupes (en dehors de leurs relations avec les produits), consultez Groupes et restrictions de groupes.
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 :
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 :
Les jalons sont des objectifs pour lesquels vous projetez de corriger un bogue. Par exemple, vous avez un bogue que vous prévoyez de corriger pour la version 3.0, on doit donc lui assigner le jalon 3.0.
Note
Les options de jalons n'apparaissent pour un produit que si vous avez activé le paramètre usetargetmilestone dans l'onglet Champs des bogues dans la page Paramètres.
Pour créer de nouveaux jalons et définir des jalons par défaut :
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.
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 :
Les étiquettes peuvent avoir trois valeurs :
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.
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.
Les étiquettes peuvent être posées à deux endroits : sur un fichier joint ou sur un bogue.
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 :
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.
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.
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 (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 :
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.
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.
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.
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.
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.
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é.
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).
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.
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.
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.
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.
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.
Attention
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.
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 Vérifier et maintenir l'intégrité de la base de données. Actuellement, les mots-clés ne peuvent pas être marqués comme obsolètes pour empêcher une utilisation ultérieure.
Les mots-clés peuvent être créés, modifiés ou supprimés en cliquant sur le lien Mots-clés dans la page d'administration. Il y a deux champs pour chaque mot-clé : le mot-clé lui-même et une brève description. Une fois créé, les mots-clés peuvent être sélectionnés et appliqués à chaque bogue individuellement dans la section Détails de chaque bogue.
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.
Note
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é.
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 :
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.
Une boîte de plusieurs lignes pour saisir du texte.
Une boîte d'une seule ligne pour saisir du texte.
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 Voir/Modifier les valeurs autorisées pour des informations sur la modification des valeurs autorisées.
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 Voir/Modifier les valeurs autorisées pour des informations sur la modification des valeurs autorisées.
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 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 Voir/Modifier les valeurs autorisées.
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 Voir/Modifier les valeurs autorisées. Tous les autres attributs peuvent être modifiés comme décrit ci-dessous.
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.
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 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.
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.
Les valeurs autorisées de champs personnalisés peuvent être supprimées, mais seulement si les deux conditions suivantes sont respectées :
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.
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.
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 :
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é.
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 :
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 Affecter des restrictions de groupes à des produits.
Note
Par défaut, les bogues peuvent être également vus par le responsable, le rapporteur et par toutes les personnes dans la liste Copie à, sans tenir compte des droits qu'ils auraient normalement pour l'affichage des bogues. La visibilité pour le rapporteur et les personnes de la liste Copie à peut être be outrepassé (bogue par bogue) en modifiant le bogue, en y cherchant la section commençant par Les utilisateurs des rôles sélectionnés ci-dessous… et en retirant la coche de la case située à côté de Rapporteur ou de Copie à (ou les deux).
Pour créer un nouveau groupe, réalisez les étapes suivantes :
Cliquez sur le lien Administration dans le pied de page, puis sur le lien Groupes dans la page d'administration.
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.
Il y a cinq champs à remplir. Ces champs sont documentés sous le formulaire. Choisissez un nom et une description pour le groupe. Décidez ensuite si ce groupe doit être utilisé pour les bogues (selon toute vraisemblance, ceci doit être sélectionné). Vous pouvez optionnellement choisir une expression régulière qui ajoutera automatiquement les utilisateurs qui correspondent au groupe et choisir une icône qui aidera à identifier les commentaires d'utilisateurs pour le groupe. L'expression régulière peut être utile, par exemple pour ajouter automatiquement tous les utilisateurs d'une même société dans un groupe (si le groupe est destiné à un client ou un partenaire spécifique).
Note
Si le champ Nouvelle expression régulière d'utilisateur est rempli, tous les utilisateurs dont l'adresse électronique correspond à l'expression régulière seront automatiquement membre du groupe tant que leurs adresses correspond à l'expression régulière. Si leurs adresses changent et ne correspondent plus à l'expression régulière, ils seront retirés du groupe. Les versions 2.16 et précédentes ne retiraient pas automatiquement les utilisateurs dont l'adresse électronique ne correspondait plus à l'expressioon régulière.
Attention
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.
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 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 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.
Les utilisateurs peuvent devenir membres d'un groupe de plusieurs manières :
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 Affecter des restrictions de groupes à des produits.
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é.
Attention
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.