<?xml version="1.0" encoding="UTF-8"?>
<!-- <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> -->
<chapter id="administration">
<title>Administrer Bugzilla</title>
<section id="parameters">
<title>Configuration de Bugzilla</title>
<para>
Pour configurer Bugzilla, il faut changer différents paramètres
accessibles à partir du lien <quote>Edit parameters</quote> au bas
de la page. Voici quelques-uns des paramètres importants de cette
page. Il faut parcourir cette liste et les remplir correctement
après l'installation de Bugzilla.
</para>
<indexterm>
<primary>checklist</primary>
</indexterm>
<procedure>
<step>
<para>
<command>maintainer</command> :
Le paramètre <quote>maintainer</quote> est l'adresse électronique de la personne
chargée de maintenir cette installation Bugzilla.
Il n'est pas nécessaire que l'adresse soit celle d'un compte Bugzilla valide.
</para>
</step>
<step>
<para>
<command>urlbase</command> :
Ce paramètre indique à votre installation Bugzilla le nom de
domaine entier et le chemin du serveur web.
</para>
<para>
Par exemple, si votre page de requête Bugzilla est
<literal>http://www.foo.com/bugzilla/query.cgi</literal>,
fixez votre paramètre <quote>urlbase</quote> à
<literal>http://www.foo.com/bugzilla/</literal>.
</para>
</step>
<step>
<para>
<command>makeproductgroups</command> :
permet de créer automatiquement ou pas des groupes
quand des produits nouveaux sont créés.
</para>
</step>
<step>
<para>
<command>useentrygroupdefault</command> :
Les produits de Bugzilla peuvent avoir un groupe associé, si bien que certains
utilisateurs ne voient des bogues que dans certains produits. Quand ce
paramètre a pour valeur <quote>on</quote>, cela peut provoquer
le fait que les commandes du groupe initial sur les produits fraîchement créés
placent immédiatement tous les bogues fraîchement générés dans le groupe
ayant le même nom que le produit.
Après la création initiale d'un produit, les commandes du groupe
peuvent être réglées plus précisément sans interférence
avec le mécanisme.
</para>
</step>
<step>
<para>
<command>shadowdb</command> :
Un problème intéressant se pose quand Bugzilla atteint un
niveau élevé d'activité en continu. MySQL supporte uniquement le verrouillage en
écriture au niveau des tables. Cela signifie que, si quelqu'un doit apporter une
modification à un bogue, il devra verrouiller la table tout entière jusqu'à la
fin de l'opération. Le verrouillage en écriture bloque également la lecture jusqu'à
ce que l'écriture soit terminée. Notez que des versions plus récentes de mysql acceptent
le verrouillage des lignes en utilisant différents types de tables. Ces types sont plus lents que
le type standard, et Bugzilla ne bénéficie pas encore des fonctionnalités
comme les transactions qui justifieraient une diminution de la vitesse. L'équipe
Bugzilla espère bien avoir des informations sur toute expérience relative au
verrouillage des lignes et à Bugzilla.
</para>
<para>
Le paramètre <quote>shadowdb</quote> a été conçu pour contourner
cette limitation. Alors qu'un seul utilisateur est autorisé à écrire dans
la table à un moment donné, la lecture peut continuer sans difficulté sur une
copie fantôme en lecture seule de la base de donnée. Bien que votre base de données
sera deux fois plus volumineuse, une base de donnée fantôme peut apporter une énorme
amélioration des performances quand elle est implémentée sur des bases de données
Bugzilla à gros trafics.
</para>
<para>
À titre indicatif, sur du matériel relativement ancien,
mozilla.org n'a pas eu besoin de <quote>shadowdb</quote> avant
d'arriver à environ 40000 utilisateurs de Bugzilla avec
plusieurs centaines de modifications et de commentaires sur
les bogues de Bugzilla par jour.
</para>
<para>
La valeur du paramètre définit le nom de la base de données fantôme
contenant les bogues. Vous aurez besoin de configurer les paramètres de l'hôte et du port
depuis la page paramètres, et de configurer une copie sur votre serveur de base de données
de manière à ce que les mises à jour atteignent le miroir en lecture seul. Consultez la
documentation de votre base de données pour plus d'informations.
</para>
</step>
<step>
<para>
<command>shutdownhtml</command> :
Si vous devez éteindre Bugzilla pour des tâches d'administration, tapez
un texte descriptif (en langage HTML imbriqué, si vous voulez)
dans ce champ. Chaque personne qui essayera d'utiliser Bugzilla (y compris les administrateurs)
recevra une page affichant ce texte. Les utilisateurs ne peuvent ni se connecter
ni se déconnecter tant que shutdownhtml est activé.
</para>
<note>
<para>
Bien que les possibilités habituelles de connexion soient désactivées tant que 'shutdownhtml'
est activé, des protections sont mises en place pour protéger l'administrateur
malchanceux qui perd sa connexion à Bugzilla. Si cela vous arrive,
allez directement à <filename>editparams.cgi</filename> (en tapant le lien
manuellement si nécessaire). Vous serez alors invité à vous
connecter, et là (mais nulle part ailleurs) votre nom d'utilisateur/mot de passe
seront acceptés.
</para>
</note>
</step>
<step>
<para>
<command>passwordmail</command> :
Chaque fois qu'un utilisateur crée un compte, le contenu de ce paramètre
(avec des adaptations) ainsi que son mot de passe lui est envoyé.
</para>
<para>
Ajoutez le texte que vous souhaitez dans le champ du paramètre
<quote>passwordmail</quote>. Par exemple, beaucoup de
personnes utilisent ce champ pour donner de rapides
indications sur la façon d'utiliser Bugzilla sur leur site.
</para>
</step>
<step>
<para>
<command>movebugs</command> :
Cette option est une fonctionnalité non documentée permettant de déplacer les bogues
entre des installations Bugzilla distinctes. Vous aurez besoin de comprendre
le code source pour utiliser cette fonctionnalité. Veuillez consulter
<filename>movebugs.pl</filename> dans votre arborescence de fichiers Bugzilla pour
davantage d'informations, comme il se doit.
</para>
</step>
<step>
<para>
<command>useqacontact</command> :
Permet de définir une adresse électronique pour chaque composant,
en plus de celle du propriétaire par défaut, à laquelle seront envoyées
des copies des nouveaux bogues.
</para>
</step>
<step>
<para>
<command>usestatuswhiteboard</command> :
Ce paramètre indique si vous souhaitez un champ réinscriptible de forme libre
associé à chaque bogue. L'avantage du <quote>Status Whiteboard</quote> est qu'il peut être
supprimé ou modifié aisément, et qu'il fournit un champ interrogeable facilement
pour l'indexation des bogues qui ont des traits en commun.
</para>
</step>
<step>
<para>
<command>whinedays</command> :
Fixez ce paramètre au nombre de jours que vous souhaitez
laisser les bogues à l'état <quote>NEW</quote> ou
<quote>REOPENED</quote> avant de signaler aux personnes
concernées qu'elles ont des bogues non traités. Si vous ne
pensez pas utiliser cette fonctionnalité, il suffit tout
simplement de ne pas installer la fonction cron de rappel
(<quote>whining cron</quote>) comme cela est décrit dans les
instructions d'installation, ou de fixer la valeur à
<quote>0</quote> (aucun rappel).
</para>
</step>
<step>
<para>
<command>commenton*</command> :
Tous ces champs vous permettent de signaler quelles modifications ne nécessitent pas
de commentaires et celles qui doivent être commentées par leur auteur. Souvent,
les administrateurs autorisent les utilisateurs à s'ajouter eux-mêmes à la liste
des copies, à accepter des bogues, ou à changer le <quote>Status Whiteboard</quote> sans ajouter
de commentaires sur les raisons du changement, et exigent cependant que la plupart
des autres changements soient accompagnés d'une explication.
</para>
<para>
Remplissez les options <quote>commenton</quote> conformément à la politique de votre site.
Au minimum, il est bon de demander des commentaires quand les utilisateurs résolvent,
réassignent ou rouvrent des bogues.
</para>
<note>
<para>
Il est généralement préférable de demander le commentaire du développeur
quand il résout un bogue. Il n'y pas grand chose de plus agaçant pour les
utilisateurs de base de données de bogues que de rencontrer un bogue marqué
comme <quote>fixed</quote> par un développeur sans aucun commentaire sur la nature de
la réparation (ou même pour indiquer qu'il a vraiment été réparé !).
</para>
</note>
</step>
<step>
<para>
<command>supportwatchers</command> :
Activer cette option permet aux utilisateurs de demander à recevoir
des copies de tous les messages électroniques concernant un bogue
particulier d'un autre utilisateur. Observer un utilisateur avec des
permissions de groupe différentes ne permet pas pour autant de
'contourner' le système; les messages copiés restent toujours soumis
aux permissions de groupe normales sur un bogue, et les
<quote>observateurs</quote> seront seulement en copie sur des courriels
provenant de bogues qu'ils seraient normalement autorisés à voir.
</para>
</step>
<step>
<para>
<command>noresolveonopenblockers</command> :
Cette option évitera aux utilisateurs de résoudre des bogues considérés
comme RESOLVED [FIXED] s'ils ont des dépendances non résolues. Seule la
résolution FIXED est affectée. Les utilisateurs seront toujours en mesure
de passer les bogues à une résolution autre que CORRIGES s'ils ont des
bogues de dépendances non résolues.
</para>
</step>
</procedure>
</section>
<section id="useradmin">
<title>Administration des utilisateurs</title>
<section id="defaultuser">
<title>Créer l'utilisateur par défaut</title>
<para>
Quand vous lancez pour la première fois checksetup.pl après
l'installation de Bugzilla, on vous demandera le nom de
l'administrateur (adresse électronique) et le mot de passe de ce
<quote>super utilisateur</quote>. Si, pour une raison quelconque,
vous supprimez ce compte, relancez checksetup.pl et on vous
redemandera le nom d'utilisateur et le mot de passe de
l'administrateur.
</para>
<tip>
<para>
Si vous souhaitez ajouter plus d'administrateurs, ajouter les au
groupe <quote>admin</quote> et, éventuellement, éditez les
groupes tweakparams, editusers, creategroups, editcomponents et
editkeywords pour ajouter le groupe entier d'administrateurs à
ces groupes.
</para>
</tip>
</section>
<section id="manageusers">
<title>Gérer les autres utilisateurs</title>
<section id="createnewusers">
<title>Créer de nouveaux utilisateurs</title>
<para>
Vos utilisateurs peuvent créer leurs propres comptes utilisateur
en cliquant sur le lien <quote>Nouveau compte</quote> situé en
bas de chaque page (en supposant qu'ils n'aient pas déjà ouvert
une autre session sous un autre nom). Toutefois, si vous
souhaitez créer les comptes utilisateur à l'avance, voici
comment faire.
</para>
<orderedlist>
<listitem>
<para>
Après avoir ouvert votre session, cliquez sur le lien
<quote>Users</quote> situé en bas de la page de requête,
puis sur le lien <quote>Add a new user</quote>.
</para>
</listitem>
<listitem>
<para>
Remplissez le formulaire. Cette page est toute simple. Une
fois que cela est fait, cliquez sur <quote>Submit</quote>.
</para>
<note>
<para>
En ajoutant un utilisateur de cette façon,
<emphasis>aucun</emphasis> message électronique ne lui sera
envoyé pour l'informer de son nom d'utilisateur et de son
mot de passe. Bien que cela soit utile pour créer des
comptes factices (par exemple, des observateurs qui
transmettent et reçoivent des messages électroniques à un
autre système, ou des adresses électroniques qui font partie
d'une liste de diffusion), il est, en général, préférable de
fermer sa session et d'utiliser le bouton <quote>New
account</quote> pour créer des utilisateurs, car tous les
champs obligatoires seront remplis à l'avance et
l'utilisateur sera également informé du nom de son compte et
de son mot de passe.
</para>
</note>
</listitem>
</orderedlist>
</section>
<section id="modifyusers">
<title>Modifier les utilisateurs</title>
<para>
Pour voir un utilisateur particulier, recherchez-le en tapant
son nom d'utilisateur dans la case prévue sur la page
<quote>Edit Users</quote>. Pour voir tous les utilisateurs,
laissez la case vide.
</para>
<para>
Vous pouvez effectuer des recherches de différentes façons grâce
à la liste déroulante située à droite de la zone de texte. Vous
pouvez rechercher à partir d'une sous-chaîne (par défaut sans
tenir compte de la casse), d'une expression rationnelle ou d'une
expression rationnelle <emphasis>inverse</emphasis>, qui trouve
tous les utilisateurs qui ne correspondent pas à l'expression
rationnelle (Veuillez vous reporter au manuel issu de la commande
<command>man regexp</command> pour des informations sur la
syntaxe des expressions rationnelles).
</para>
<para>
Une fois que vous avez trouvé votre utilisateur, vous pouvez
changer les champs suivants :
</para>
<itemizedlist>
<listitem>
<para>
<emphasis>Login Name</emphasis> : en général, c'est
l'adresse électronique entière de l'utilisateur. Toutefois,
si vous utilisez le paramètre <quote>emailsuffix</quote>, ce
champ peut contenir uniquement le nom d'utilisateur. On peut
noter que les utilisateurs peuvent désormais changer leur
nom d'utilisateur eux-mêmes (en le remplaçant par une
adresse électronique valide).
</para>
</listitem>
<listitem>
<para>
<emphasis>Real Name</emphasis> : c'est le nom réel de
l'utilisateur. On peut noter que Bugzilla n'exige pas cette
information pour créer un compte.
</para>
</listitem>
<listitem>
<para>
<emphasis>Password</emphasis> : vous pouvez changer le
mot de passe utilisateur ici. Les utilisateurs peuvent
demander un nouveau mot de passe automatiquement, vous ne
devriez donc pas avoir à le faire souvent. Si vous voulez
désactiver un compte, reportez-vous à la description de
<quote>Disable Text</quote> ci-dessous.
</para>
</listitem>
<listitem>
<para>
<emphasis>Disable Text</emphasis> : si vous entrez
quelque chose dans cette case, ne serait-ce qu'un espace,
vous empêchez l'utilisateur d'ouvrir sa session, ou
d'apporter des modifications à des bogues via l'interface
Internet. Le code HTML que vous tapez dans cette case est
affiché à l'utilisateur quand il essaye d'effectuer une de
ces actions. Il est conseillé d'y expliquer pourquoi le
compte a été désactivé.
</para>
<para>
Les utilisateurs ayant un compte désactivé continueront de
recevoir des courriels de Bugzilla; en outre, ils seront
incapables de se connecter eux-mêmes pour modifier leur
propres préférences et l'arrêter. Si vous voulez qu'un
compte (désactivé ou activé) arrête de recevoir des
courriels, ajoutez le nom du compte (un compte par ligne)
au fichier <filename>data/nomail</filename>.
</para>
<note>
<para>
Même les utilisateurs dont le compte a été désactivé
peuvent quand même transmettre des bogues via le portail
de messagerie électronique, si il en existe une. Pour la
sécurité des installations de Bugzilla, le portail de
messagerie électronique ne doit <emphasis>pas</emphasis>
être activé.
</para>
</note>
<warning>
<para>
Ne désactivez pas tous les comptes administrateurs !
</para>
</warning>
</listitem>
<listitem>
<para>
<emphasis><groupname></emphasis> : si vous avez
créé des groupes, comme <quote>securitysensitive</quote>,
des cases apparaîtront ici pour vous permettre d'ajouter ou
de supprimer des utilisateurs à ces groupes.
</para>
</listitem>
<listitem>
<para>
<emphasis>canconfirm</emphasis> : ce champ n'est
utilisé que si vous avez autorisé l'état
<quote>unconfirmed</quote>. Si vous activez ce champ pour un
utilisateur, celui-ci pourra passer des bogues de l'état
<quote>Unconfirmed</quote> à un état
<quote>Confirmed</quote> (par exemple : l'état
<quote>New</quote>).</para>
</listitem>
<listitem>
<para>
<emphasis>creategroups</emphasis> : cette option permet
à un utilisateur de créer et détruire des groupes dans
Bugzilla.
</para>
</listitem>
<listitem>
<para>
<emphasis>editbugs</emphasis> : les utilisateurs
peuvent seulement éditer les bogues dont ils sont
responsables ou qu'ils ont signalés, sauf si ce champ est
activé. Même si l'option n'est pas sélectionnée, les
utilisateurs peuvent tout de même ajouter des commentaires à
des bogues.
</para>
</listitem>
<listitem>
<para>
<emphasis>editcomponents</emphasis> : cette option
permet à un utilisateur de créer de nouveaux produits et
composants, ainsi que de modifier et supprimer ceux auxquels
aucun bogue n'est associé. Si un produit ou un composant a
des bogues qui lui sont associés, ces bogues doivent être
affectés à un autre produit ou composant pour que Bugzilla
permette sa suppression.
</para>
</listitem>
<listitem>
<para>
<emphasis>editkeywords</emphasis> : si vous utilisez la
fonctionnalité de mot-clé de Bugzilla, en activant cette
option vous permettrez à un utilisateur de créer et détruire
des mots-clé. Comme toujours, les mots-clé pour des bogues
existants qui contiennent le mot-clé que l'utilisateur veut
détruire doivent être modifiés pour que Bugzilla autorise sa
suppression.
</para>
</listitem>
<listitem>
<para>
<emphasis>editusers</emphasis> : cette option permet à
un utilisateur de faire ce que vous faîtes en ce
moment : éditer d'autres utilisateurs. Cela permettra à
ceux qui ont le droit de le faire de supprimer les droits
administrateur d'autres utilisateurs ou de se les accorder.
À activer avec précaution.
</para>
</listitem>
<listitem>
<para>
<emphasis>tweakparams</emphasis> : cette option permet
à un utilisateur de changer les paramètres de Bugzilla (en
utilisant <filename>editparams.cgi</filename>).
</para>
</listitem>
<listitem>
<para>
<emphasis><productname></emphasis> : ceci permet
à un administrateur de spécifier les produits au sein
desquels un utilisateur pourra voir des bogues.
L'utilisateur devra quand même avoir le droit
<quote>editbugs</quote> pour éditer les bogues dans ces
produits.
</para>
</listitem>
</itemizedlist>
</section>
</section>
</section>
<section id="products">
<title>Produits</title>
<para>
Les <glossterm linkend="gloss-product"
baseform="product">produits</glossterm> constituent la catégorie la
plus importante dans Bugzilla, et représentent quasiment les
produits réels embarqués. Par exemple, si votre entreprise conçoit
des jeux vidéo, vous devriez avoir un produit par jeu, peut-être un
produit <quote>commun</quote> pour les technologies utilisées dans
de nombreux jeux, et peut-être quelques produits spéciaux (Site
Internet, Administration, ...)
</para>
<para>
Une grande partie des réglages de Bugzilla est paramétrable pour un
produit donné. Le nombre de <quote>votes</quote> disponibles par
utilisateur est fixé pour un produit donné, tout comme le nombre de
votes nécessaire pour faire passer un bogue automatiquement de
l'état UNCONFIRMED à l'état NEW.
</para>
<para>Pour créer un nouveau produit :</para>
<orderedlist>
<listitem>
<para>Sélectionnez <quote>Produits</quote> en bas de page</para>
</listitem>
<listitem>
<para>Sélectionnez le lien <quote>Add</quote> en bas à droite</para>
</listitem>
<listitem>
<para>Entrez le nom du produit et une description. Il est possible
de remplir le champ Description en HTML.</para>
</listitem>
</orderedlist>
<para>
Ne vous souciez pas des options <quote>Closed for bug entry</quote>,
<quote>Maximum Votes per person</quote>, <quote>Maximum votes a
person can put on a single bug</quote>, <quote>Number of votes a bug
in this Product needs to automatically get out of the UNCOMFIRMED
state</quote>, et <quote>Version</quote> pour le moment. Nous allons
les aborder dans quelques instants.
</para>
</section>
<section id="components">
<title>Composants</title>
<para>
Les composants sont des sous-sections des produits. Par exemple, le
jeu vidéo que vous développez peut avoir un composant IHM, un
composant <quote>API</quote>, un composant <quote>Sound
System</quote> et un composant <quote>Plugins</quote>, chacun étant
surveillé par un programmeur différent. Il est souvent pratique de
séparer les composants dans Bugzilla suivant la répartition
naturelle des responsabilités au sein du produit ou de votre
entreprise.
</para>
<para>
Chaque composant a un propriétaire et un contact QA (si vous
l'activez dans les paramètres). Il est préférable que le
propriétaire d'un composant soit la première personne à réparer les
bogues dans ce composant. Il est conseillé que ce soit le contact QA
qui s'assurera que ces bogues sont complètement réparés. Le
propriétaire, le contact QA et celui qui a signalé le bogue
recevront un message électronique quand de nouveaux bogues seront
créés dans ce composant et quand ces bogues seront modifiés. Les
champs Default Owner et QA contact indique seulement les
<emphasis>affectations par défaut</emphasis>; celles-ci peuvent être
modifiées lors de la soumission d'un bogue, ou à n'importe quel
moment de la vie du bogue.
</para>
<para>Pour créer un nouveau composant :</para>
<orderedlist>
<listitem>
<para>
Sélectionnez le lien <quote>Edit components</quote> dans la page
<quote>Edit product</quote>.
</para>
</listitem>
<listitem>
<para>Sélectionnez le lien <quote>Add</quote> en bas à droite.</para>
</listitem>
<listitem>
<para>
Remplissez le champ <quote>Component</quote>, une courte
<quote>Description</quote>, les champs <quote>Initial
Owner</quote> et <quote>Initial QA Contact</quote> (s'ils sont
activés). Il est possible de remplir les champs Component et
Description en HTML. Vous devez remplir le champ <quote>Initial
Owner</quote> avec un nom d'utilisateur déjà présent dans la
base de données.
</para>
</listitem>
</orderedlist>
</section>
<section id="versions">
<title>Versions</title>
<para>
Les versions sont les révisions d'un produit, comme <quote>Flinders
3.1</quote>, <quote>Flinders 95</quote>, et <quote>Flinders
2000</quote>. La version n'est pas un champ à plusieurs choix; en
général, on choisit la version la plus récente dont on sait qu'elle
contient le bogue.
</para>
<para>Pour créer et éditer des versions :</para>
<orderedlist>
<listitem>
<para>
Sélectionnez le lien <quote>Edit Versions</quote> à partir de la
page <quote>Edit product</quote>.
</para>
</listitem>
<listitem>
<para>
Vous pourrez remarquer que le produit a déjà par défaut la
version <quote>undefined</quote>. Cliquez sur le lien
<quote>Add</quote> en bas à droite.
</para>
</listitem>
<listitem>
<para>
Entrez le nom de la version. Ce champ ne peut contenir que du texte.
Ensuite, cliquez sur le bouton <quote>Add</quote>.
</para>
</listitem>
</orderedlist>
</section>
<section id="milestones">
<title>Cibles Jalon</title>
<para>
Les cibles jalons sont des <quote>cibles</quote> qui représentent la
version pour laquelle vous prévoyez de réparer un bogue. Par
exemple, si vous prévoyez de réparer un bogue pour la version 3.0,
vous lui affecterez le jalon 3.0.
</para>
<note>
<para>
Les options des cibles jalons n'apparaissent pour un produit que
si vous activez le paramètre <quote>usetargetmilestone</quote>
dans la page <quote>Edit Parameters</quote>.
</para>
</note>
<para>
Pour créer de nouveaux jalons, définir les jalons par défaut et
fixer l'URL des jalons :
</para>
<orderedlist>
<listitem>
<para>
Sélectionnez <quote>Edit milestones</quote> dans la page
<quote>Edit product</quote>.
</para>
</listitem>
<listitem>
<para>
Sélectionnez <quote>Add</quote> dans le coin inférieur droit.
</para>
</listitem>
<listitem>
<para>
Entrez le nom du jalon dans le champ <quote>Milestone</quote>.
En option, vous pouvez fixer le <quote>sortkey</quote>, qui est
un nombre positif ou négatif (-255 à 255) qui définit où ce
point clé apparaîtra dans la liste. En effet, les jalons ne se
présentent pas souvent dans l'ordre alphanumérique. Par exemple,
on peut trouver <quote>Future</quote> après <quote>Release
1.2</quote>. Sélectionnez <quote>Add</quote>.
</para>
</listitem>
<listitem>
<para>
Dans la page Edit product, vous pouvez entrer l'URL d'une page
qui donne des informations sur vos jalons et ce qu'ils
signifient.
</para>
</listitem>
</orderedlist>
</section>
<section id="flags-overview">
<title>Fanions</title>
<para>
Les fanions permettent d'attribuer un statut spécifique à un bogue
ou une pièce jointe, aussi bien <quote>+</quote> que
<quote>-</quote>. La signification de ces symboles dépend du texte
du fanion lui-même, mais selon le contexte ils peuvent signifier
passe/échoue, accepter/refuser, approuvé/refusé, ou même un simple
oui/non. Si votre site autorise les fanions de requêtes, les
utilisateurs peuvent attribuer au fanion la valeur <quote>?</quote>
de manière à en faire une requête auprès d'un autre utilisateur
pour pouvoir regarder le bogue/pièce jointe, et donner au fanion
son statut correct.
</para>
<section id="flags-simpleexample">
<title>Exemple simple</title>
<para>
Un développeur peut avoir envie de demander à sa hiérarchie :
<quote>Devrions nous corriger ce bogue avant de sortir la version
2.0 ?</quote>. Ils peuvent avoir envie de le faire pour de
<emphasis>nombreux</emphasis> bogues, et donc ce serait bien de
rationaliser le procédé...
</para>
<para>
Avec Bugzilla, cela marcherait ainsi :
<orderedlist>
<listitem>
<para>
L'administrateur de Bugzilla crée un type de fanion appelé
<quote>blocking2.0</quote> qui révèle tous les bogues de
votre produit.
</para>
<para>
Sur l'écran <quote>Trouver bug</quote>, ce fanion affiche
le texte <quote>blocking2.0</quote> avec une zone
déroulante à côté. La zone déroulante contient 4
valeurs : un espace vide, <quote>?</quote>,
<quote>-</quote>, et <quote>+</quote>.
</para>
</listitem>
<listitem>
<para>Le développeur attribue au fanion la valeur <quote>?</quote>.</para>
</listitem>
<listitem>
<para>
Le directeur voit le fanion
<computeroutput>blocking2.0</computeroutput> à la valeur
<quote>?</quote> value.
</para>
</listitem>
<listitem>
<para>
Si le directeur pense que le dispositif devrait être inclus
dans le produit avant la sortie de la version 2.0, il
attribue au fanion la valeur <quote>+</quote>. Sinon il lui
attribue <quote>-</quote>.
</para>
</listitem>
<listitem>
<para>
Maintenant, chaque utilisateur de Bugzilla qui voit le
bogue sait si le bogue a besoin ou pas d'être corrigé avant
la sortie de la version 2.0.
</para>
</listitem>
</orderedlist>
</para>
</section>
<section id="flags-about">
<title>À propos des fanions</title>
<section id="flag-values">
<title>Valeurs</title>
<para>
Les fanions peuvent prendre 3 valeurs :
<variablelist>
<varlistentry>
<term><computeroutput>?</computeroutput></term>
<listitem><simpara>
Un utilisateur demande qu'un statut soit donné
(considérez le comme <quote>une question est
posée</quote>).
</simpara></listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>-</computeroutput></term>
<listitem><simpara>
Le statut donné est négatif (on a répondu
<quote>non</quote> à la question).
</simpara></listitem>
</varlistentry>
<varlistentry>
<term><computeroutput>+</computeroutput></term>
<listitem><simpara>
Le statut donné est positif (on a répondu
<quote>oui</quote> à la question).
</simpara></listitem>
</varlistentry>
</variablelist>
</para>
<para>
En fait, il existe une quatrième valeur possible du
fanion : <quote>aucun statut</quote> ; celle-ci est
représentée par un espace vide. Cela veut juste dire que
personne n'a exprimé d'opinion (ou demandé à quelqu'un d'autre
d'exprimer une opinion) à propos de ce bogue ou de la requête
par pièce jointe.
</para>
</section>
</section>
<section id="flag-askto">
<title>Utilisation des requêtes par fanions</title>
<para>
Si un fanion a été déclaré comme étant fanion <quote>de
requête</quote>, les utilisateurs sont autorisés à attribuer au
fanion le statut <quote>?</quote>. Ce statut indique que
quelqu'un (alias <quote>le demandeur</quote>) demande à quelqu'un
d'autre d'attribuer <quote>+</quote> ou <quote>-</quote>.
</para>
<para>
Si un fanion a été défini comme <quote>fanion de requête
particulière</quote>, une zone de texte apparaîtra à côté du
fanion dans laquelle le demandeur peut entrer un nom
d'utilisateur Bugzilla. La personne mentionnée (alias <quote>le
demandé</quote>) recevra un courriel l'avertissant de la requête
et renvoyant celle-ci vers le bogue ou la pièce jointe en
question.
</para>
<para>
Si un fanion n'a <emphasis>pas</emphasis> été défini
<quote>fanion de requête particulière</quote>, aucune zone de ce
genre n'apparaîtra. Une requête pour marquer ce fanion ne peut
pas être faite à une personne en particulier, mais doit être
demandée <quote>à la cantonade</quote>. Un demandeur peut
<quote>demander à la cantonade</quote> pour n'importe quel fanion
simplement en laissant la zone de texte vide.
</para>
</section>
<section id="flag-types">
<title>Deux types de fanions</title>
<para>
Les fanions peuvent se mettre à deux endroits : dans une
pièce jointe, ou dans un bogue.
</para>
<section id="flag-type-attachment">
<title>Fanions de pièce jointe</title>
<para>
Les fanions de pièce jointe sont utilisés pour poser une
question sur une pièce jointe particulière à un bogue.
</para>
<para>
Plusieurs installations Bugzilla s'en servent pour demander à
un développeur <quote>d'examiner</quote>
[<quote>review</quote>] le code d'un autre développeur avant de
le valider. Ils joignent le code à un rapport de bogue, puis
lui attribue un fanion nommé <quote>review</quote> à
<literal>review?boss@domain.com</literal>. boss@domain.com est
alors averti par courriel qu'il doit vérifier la pièce jointe
et l'approuver ou la refuser.
</para>
<para>
Pour un utilisateur Bugzilla, les fanions de pièce jointe
apparaissent à deux endroits :
<orderedlist>
<listitem>
<para>
Sur la liste des pièces jointes sur l'écran
<quote>montrer un bogue</quote> [<quote>Show
bug</quote>], on peut voir l'état actuel de tous les
fanions affectés de ?, +, ou -. On peut voir qui a
demandé le fanion (le demandeur), et qui a été sollicité
(le demandé).
</para>
</listitem>
<listitem>
<para>
Quand vous <quote>modifiez</quote> une pièce jointe, on
peut voir les fanions qui n'ont pas encore de valeur,
ainsi que ceux qui en ont déjà une. C'est sur l'écran
<quote>éditer une pièce jointe</quote> que l'on met ou que
l'on enlève ?, -, +.
</para>
</listitem>
</orderedlist>
</para>
</section>
<section id="flag-type-bug">
<title>Fanions de bogue</title>
<para>
Les fanions de bogue sont utilisés pour attribuer un statut au
bogue lui-même. On peut voir les fanions de bogue sur l'écran
<quote>Show Bug</quote> (<filename>editbug.cgi</filename>).
</para>
<para>
Seuls les utilisateurs ayant le droit d'éditer le bogue peuvent
attribuer des valeurs aux fanions qui sont sur des bogues. Cela
inclut le propriétaire, celui qui signale les bogues, et tout
utilisateur ayant la permission
<computeroutput>editbugs</computeroutput>.
</para>
</section>
</section>
<section id="flags-admin">
<title>Administration des fanions</title>
<para>
Si vous avez le privilège <quote>editcomponents</quote>, vous
aurez <quote>Edit: ... | Flags | ...</quote> en bas de page. En
cliquant sur ce lien vous pourrez accéder à la page
<quote>Administrer des types de fanions</quote>. Ici, vous pouvez
choisir si vous voulez créer (ou éditer) un fanion de bogue, ou
un fanion de pièce jointe.
</para>
<para>
Peu importe celui que vous choisissez, l'interface est la même,
donc nous ne l'aborderons qu'une fois.
</para>
<section id="flags-create">
<title>Créer un fanion</title>
<para>
Quand vous cliquez sur le lien <quote>Create a Flag Type
for...</quote>, il vous sera présenté un formulaire. Voici la
signification des champs du formulaire :
</para>
<section id="flags-create-field-name">
<title>Nom</title>
<para>
C'est le nom du fanion. Il s'affichera pour les utilisateurs
Bugzilla qui sont en train de regarder ou de configurer un
fanion. Le nom peut contenir n'importe quel caractère
Unicode valide.
</para>
</section>
<section id="flags-create-field-description">
<title>Description</title>
<para>
Donne plus de précisions sur le fanion. Pour le moment, cela
n'a pas l'air d'être très utile; idéalement, ce serait bien
que ce soit affiché comme aide. Ce champ peut être aussi
long que vous le désirez, et peut contenir autant de
caractères que vous voulez.
</para>
</section>
<section id="flags-create-field-category">
<title>Catégorie</title>
<para>
Le comportement par défaut pour un fanion fraîchement créé
est d'apparaître sur les produits et tous les composants,
c'est pourquoi <quote>__Any__:__Any__</quote> est déjà
présent dans le champ <quote>Inclusions</quote>. Si ce n'est
pas ce comportement que vous souhaitez, vous pouvez
également configurer des exclusions (pour les produits sur
lesquels vous ne voulez pas que le fanion apparaisse), ou
bien vous devez enlever <quote>__Any__:__Any__</quote> du
champ Inclusion et définir les produits/composants
spécialement pour ce fanion.
</para>
<para>
Pour créer une Inclusion, sélectionnez un produit à partir
du menu déroulant du haut. Vous pourrez également
sélectionner un composant donné à partir de ce menu
déroulant. (La configuration <quote>__Any__</quote> pour les
produits se traduit par <quote>tous les produits de ce
Bugzilla</quote>. Choisir <quote>__Any__</quote> dans le
champ Composants veut dire <quote>tous les composants du
produit sélectionné</quote>.) Une fois les sélections
faites, appuyer sur <quote>Include</quote>, et l'appariement
de votre produit/composant sera visible dans le champ
<quote>Inclusions</quote> sur la droite.
</para>
<para>
Pour créer une Exclusion, la procédure est la même;
choisissez un produit à partir du menu déroulant du haut,
choisissez un composant donné si vous en voulez un, et
appuyez sur <quote>Exclude</quote>. L'appariement de votre
produit/composant sera visible dans le champ
<quote>Exclusions</quote> sur la droite.
</para>
<para>
Ce fanion <emphasis>devra</emphasis> et
<emphasis>peut</emphasis> être configuré pour n'importe quel
produit/composant apparaissant dans le champ
<quote>Inclusions</quote> (ou qui dépend du
<quote>__Any__</quote> approprié). Ce fanion n'apparaîtra
(et donc ne pourra être configuré) sur
<emphasis>aucun</emphasis> des produits apparaissant dans le
champ <quote>Exclusions</quote>. <emphasis>IMPORTANT :
les Exclusions prévalent sur les Inclusions.</emphasis>
</para>
<para>
Vous pouvez choisir un produit sans sélectionner un
composant particulier, mais choisir un composant sans
produit est contraire à la règle, de même que choisir un
composant qui n'appartient pas au produit évoqué. Si vous le
faites, vous obtiendrez une erreur, comme on l'indique dans
ce texte (2.18rc3)... même si tous vos produits possèdent un
composant du même nom.
</para>
<para>
<emphasis>Exemple :</emphasis> disons que vous avez un
produit appelé <quote>Avion</quote> qui contient des
centaines de composants. Vous voulez avoir la possibilité de
demander si un problème sera corrigé dans le prochain modèle
d'avion que vous sortirez. Nous appellerons ce fanion
<quote>corrigerDansSuivant</quote>. Cependant, il y a un
composant dans <quote>Jet</quote>, appelé
<quote>Pilote</quote>. Il ne vous sert à rien de sortir un
nouveau pilote, donc vous ne voulez pas que le fanion soit
visible pour ce composant. Donc, vous incluez
<quote>Jet :__Any__</quote> et vous excluez
<quote>Jet :Pilote</quote>.
</para>
</section>
<section id="flags-create-field-sortkey">
<title>Clé de tri</title>
<para>
Les fanions sont normalement visibles dans l'ordre alphabétique. Si vous voulez les
afficher dans un ordre différent vous pouvez utiliser ce champ pour configurer l'ordre sur chaque fanion.
Les fanions ayant une clé de tri inférieur apparaîtront avant les fanions à
clés de tris supérieur. Les fanions ayant le même critère seront rangés alphabétiquement
mais ils seront toujours après les fanions à clés de tri inférieur et avant ceux
à clés supérieur.
</para>
<para>
<emphasis>Exemple :</emphasis> j'ai AFanion (critère de tri 100), BFanion (critère de tri 10),
CFanion (critère de tri 10), et DFanion (critère de tri 1). Ceux-ci s'affichent dans
cet ordre : DFanion, CFanion, BFanion, AFanion.
</para>
</section>
<section id="flags-create-field-active">
<title>Actif</title>
<para>
Il vous arrivera de vouloir conserver les informations de l'ancien fanion dans la
base de données Bugzilla, tout en empêchant les utilisateurs d'initialiser de nouveaux
fanions de ce genre. Pour ce faire, dé-sélectionnez <quote>active</quote>. Les fanions
désactivés seront toujours visibles dans l'interface s'ils sont ?, +, ou -, mais ils
peuvent seulement être effacés (non initialisés), et ne peuvent pas avoir de nouvelles valeurs.
Une fois que le fanion désactivé est supprimé, il disparaîtra complètement du
bogue/pièce jointe, et ne pourra plus être reconfiguré.
</para>
</section>
<section id="flags-create-field-requestable">
<title>Fanions de requête</title>
<para>
Les nouveaux fanions sont, par défaut, des fanions <quote>de requête</quote>, ce qui signifie qu'ils
offrent aux utilisateurs l'option <quote>?</quote>, ainsi que <quote>+</quote>
et <quote>-</quote>.
Pour supprimer l'option ? , dé-sélectionnez <quote>requestable</quote>.
</para>
</section>
<section id="flags-create-field-cclist">
<title>Liste CC</title>
<para>
Si vous voulez que certains utilisateurs soient avertis à chaque fois qu'un fanion est
initialisé à ?,-,+, ou non initialisé, ajoutez les ici. Il s'agit d'une liste d'adresses
électroniques, séparées par des virgules, qu'il n'est pas nécessaire de restreindre aux
noms d'utilisateurs Bugzilla.
</para>
</section>
<section id="flags-create-field-specific">
<title>Fanions de requêtes spécifiques</title>
<para>
Par défaut cette case est cochée pour les nouveaux fanions, ce qui signifie que chaque utilisateur peut
faire des requêtes de fanions destinées à des personnes en particulier. Décocher cette boîte supprimera le
champ de texte à côté du fanion; s'il demeure fanion de requête, les demandes ne peuvent être faites
qu' <quote>à la cantonnade</quote>. Le supprimer après que des demandes
spécifiques aient été faites ne supprimera pas ces demandes; ces données vont
rester dans la base de données (bien que cela n'apparaîtra plus aux utilisateurs).
</para>
</section>
<section id="flags-create-field-multiplicable">
<title>Multipliable</title>
<para>
Tout fanion initialisé sur <quote>Multipliable</quote> (par défaut pour les nouveaux fanions)
peut être configuré plus d'une fois. Après avoir été initialisé une fois, un fanion non initialisé
du même type apparaîtra en dessous de lui avec <quote>addl.</quote> (abréviation de
<quote>additional</quote>) sous son nom. Il n'y a pas de limite au nombre de
fois qu'un fanion Multipliable peut être initialisé sur le même bogue/pièce jointe.
</para>
</section>
</section> <!-- flags-create -->
<section id="flags-delete">
<title>Supprimer un fanion</title>
<para>
Sur le boîte de dialogue <quote>Administrer les types de fanions</quote>,
vous verrez une liste de fanions de bogues et une liste de fanions de
pièces jointes.
</para>
<para>
Pour supprimer un fanion, cliquez sur le lien <quote>Delete</quote> à côté de
la description du fanion.
</para>
<warning>
<para>
Une fois que vous avez supprimé un fanion, il n'est <emphasis>plus</emphasis> dans
votre Bugzilla. Toutes les données de ce fanion seront supprimées.
Il disparaîtra de tous les endroits où il était installé,
et vous ne pourrez pas récupérer les données. Si vous voulez garder les données d'un fanion,
mais ne voulez pas que n'importe qui configure de nouveaux fanions ou modifie les fanions courants,
dé-sélectionnez <quote>active</quote> dans le formulaire d'édition des fanions.
</para>
</warning>
</section>
<section id="flags-edit">
<title>Éditer un fanion</title>
<para>
Pour éditer les propriétés d'un fanion, il suffit de cliquer sur le lien <quote>Edit</quote>
à côté de la description du fanion. Cela vous ramènera au formulaire décrit
dans la partie <quote>Créer un fanion</quote>.
</para>
</section>
</section> <!-- flags-admin -->
<!-- XXX We should add a "Uses of Flags" section, here, with examples. -->
</section> <!-- flags -->
<section id="voting">
<title>Le vote</title>
<para>
Le vote permet aux utilisateurs de disposer d'un certain nombre de
voix qu'ils peuvent affecter à des bogues, pour indiquer qu'ils
souhaitent que ces bogues soient réparés. Cela permet aux
développeurs d'évaluer les besoins utilisateurs pour une
amélioration ou une réparation particulière. En permettant que les
bogues ayant un certain nombre de voix puissent passer
automatiquement de <quote>UNCONFIRMED</quote> à <quote>NEW</quote>,
les utilisateurs du système de bogues peuvent attirer l'attention
sur les bogues de priorité élevée de façon à ce qu'ils ne restent
pas trop longtemps à en attente de triage.
</para>
<para>Pour modifier les paramètres de vote :</para>
<orderedlist>
<listitem>
<para>
Allez jusqu'à la page <quote>Edit product</quote> du produit que
vous voulez modifier.
</para>
</listitem>
<listitem>
<para>
<emphasis>Nombre de voix par personne</emphasis> : en
mettant ce champ à 0, on désactive le vote.
</para>
</listitem>
<listitem>
<para>
<emphasis>Nombre de voix maximum qu'une personne peut donner à
un seul bogue</emphasis> : à l'évidence, cela doit être un
nombre inférieur au nombre inscrit dans le champ <quote>Nombre
de voix par personne</quote>. Ne mettez pas ce champ à 0 si
<quote>Nombre de voix par personne</quote> n'est pas à 0; cela
n'a pas de sens.
</para>
</listitem>
<listitem>
<para>
<emphasis>Nombre de voix nécessaires pour qu'un bogue de ce
produit sorte automatiquement de l'état
UNCONFRIMED.</emphasis> : En mettant ce champ à
<quote>0</quote>, on désactive le passage automatique des bogues
de UNCONFIRMED à NEW.
</para>
</listitem>
<listitem>
<para>
Une fois que vous avez ajusté les valeurs selon vos préférences,
cliquez sur <quote>Update</quote>.
</para>
</listitem>
</orderedlist>
</section>
<section id="quips">
<title>Les mots d'esprit</title>
<para>
Les mots d'esprit sont des messages texte courts qui peuvent être
configurés pour apparaître à côté des résultats d'une recherche.
Une installation Bugzilla peut avoir ses propres mots d'esprit
bien spécifiques. Quel que soit le moment où le mot d'esprit a
besoin d'être affiché, une sélection aléatoire est faite sur
l'ensemble des mots d'esprits déjà existants.
</para>
<para>
Les mots d'esprit sont gérés par le paramètre
<emphasis>enablequips</emphasis>. Il a plusieurs valeurs
possibles : actif, approuvé, gelé ou éteint. Pour permettre
l'approbation de mots d'esprit, il vous faut initialiser ce
paramètre à <quote>approved</quote>. De cette manière, les
utilisateurs sont libres de proposer des mots d'esprits en plus
mais un administrateur doit les approuver explicitement avant
qu'ils puissent être en fait utilisés.
</para>
<para>
Pour voir l'interface utilisateur pour les mots d'esprits, il
suffit de cliquer sur l'un d'entre eux quand il est affiché avec
les résultats de la recherche. On peut aussi le voir directement
dans le navigateur en allant sur le lien quips.cgi (préfixé de
l'adresse WEB habituelle de l'installation Bugzilla). Dès que
l'interface des mots d'esprit s'affiche, il suffit de cliquer sur
<quote>voir et modifier la liste complète des mots
d'esprit</quote> afin de voir la page d'administration. Une page
avec tous les mots d'esprits disponibles dans la base de données
s'affichera.
</para>
<para>
À côté de chaque mot d'esprit, il y a une case à cocher, dans la
colonne <quote>approved</quote>. Les mots d'esprits qui ont leur
case cochée sont déjà approuvés et apparaîtront après chaque
résultat de recherche. Ceux dont la case est non cochée sont
toujours présents dans la base de données mais n'apparaîtront pas
sur les pages de résultats de recherche. Pour les mots d'esprit
proposés par les utilisateurs, cette case est, au départ, non
cochée.
</para>
<para>
Il y a également un lien de suppression à côté de chaque mot
d'esprit, lequel peut être utilisé pour supprimer définitivement
un mot d'esprit.
</para>
</section>
<section id="groups">
<title>Groupes et sécurité des groupes</title>
<para>
Les groupes permettent à l'administrateur d'isoler des bogues ou
produits qui ne devraient être vus que par certaines personnes.
L'association entre les produits et les groupes est gérée à partir
de la page d'édition du produit sous <quote>éditer les commandes des
groupes</quote>.
</para>
<para>
Si le paramètre makeproductgroups est activé, un nouveau groupe sera
automatiquement créé pour chaque nouveau produit. Il est
principalement disponible pour la compatibilité descendante avec des
sites plus anciens.
</para>
<para>
Notez que les permissions de groupes sont telles que vous devez
être membre de <emphasis>tous</emphasis> les groupes où se trouve
un bogue, quelle qu'en soit la raison, pour voir ce bogue. De
même, vous devez être membre de <emphasis>tous</emphasis> les
groupes d'entrée d'un produit pour ajouter des bogues à un produit
et vous devez être membre de <emphasis>tous</emphasis> les groupes
<quote>canedit</quote> (<quote>peut modifier</quote>) d'un produit
pour faire <emphasis>toute</emphasis> modification de bogues dans
ce produit.
</para>
<note>
<para>
Par défaut, les bogues peuvent également être vus par le
propriétaire du bogue, le rapporteur et par toutes les personnes
de la liste CC, quel que soit leur statut par rapport à leur
accès normal au bogue. La visibilité pour le rapporteur et pour
la liste CC peut être annulée (pour un bogue à la fois) en
ressortant ce bogue, puis en allant à la section qui commence
par <quote>Utilisateurs dans les rôles sélectionnés
ci-dessous...</quote> et en décochant la case à côté de
<quote>rapporteur</quote> ou <quote>Liste CC</quote> (ou les
deux).
</para>
</note>
<section>
<title>Création des groupes</title>
<para>Pour créer des groupes :</para>
<orderedlist>
<listitem>
<para>Sélectionnez le lien <quote>groups</quote>
dans le bas de page.</para>
</listitem>
<listitem>
<para>
Lisez attentivement les instructions sur l'écran <quote>Edit
Groups</quote>, puis sélectionnez le lien <quote>Add
Groups</quote>.
</para>
</listitem>
<listitem>
<para>
Remplissez les champs <quote>Group</quote>,
<quote>Description</quote>, et <quote>User RegExp</quote>.
<quote>User RegExp</quote> vous permet de placer
automatiquement tous les utilisateurs qui remplissent les
conditions de l'expression rationnelle dans le nouveau groupe.
Quand vous avez fini, cliquez sur <quote>Add</quote>.</para>
<para>Les utilisateurs dont les adresses électroniques
correspondent à l'expression rationnelle seront automatiquement
membres du groupe tant que leurs adresses électroniques
continueront de correspondre à l'expression rationnelle.
</para>
<note>
<para>
C'est une modification du 2.16 où l'expression rationnelle
avait pour résultat l'adhésion permanente à un groupe pour
un utilisateur. Pour supprimer un utilisateur d'un groupe
dans lequel il était à cause d'une expression rationnelle,
dans la version 2.16 ou précédemment, l'utilisateur doit
être supprimé explicitement du groupe.
</para>
</note>
<warning>
<para>
Si vous spécifiez un domaine dans le regexp, assurez vous
que vous avez bien terminé l'expression rationnelle avec un
<quote>$</quote>. Sinon quand vous autoriserez l'accès à
<literal>@monentreprise\.com</literal>, vous autoriserez
l'accès à
<literal>mauvaisepersonne@monentreprise.com.cracker.net</literal>.
Il vous faut utiliser
<literal>@monentreprise\.com$</literal> comme expression
rationnelle.
</para>
</warning>
</listitem>
<listitem>
<para>
Si vous décidez d'utiliser ce groupe pour contrôler
directement l'accès aux bogues, cochez la case <quote>use for
bugs</quote> . Les groupes non utilisés pour des bogues
restent utiles car les autres groupes peuvent inclure le
groupe entier.
</para>
</listitem>
<listitem>
<para>
Après avoir ajouté votre nouveau groupe, éditez le nouveau
groupe. Sur la page d'édition, vous pouvez spécifier d'autres
groupes qui devraient être inclus dans ce groupe et quels
groupes devraient être autorisés à ajouter ou à supprimer des
utilisateurs à partir de ce groupe.
</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Affecter des utilisateurs aux groupes</title>
<para>Les utilisateurs peuvent devenir membres d'un groupe de plusieurs façons.</para>
<orderedlist>
<listitem>
<para>L'utilisateur peut être explicitement placé dans le groupe en éditant
le propre profil de l'utilisateur.</para>
</listitem>
<listitem>
<para>Le groupe peut contenir un autre groupe auquel l' utilisateur
appartient.</para>
</listitem>
<listitem>
<para>L'adresse électronique de l'utilisateur peut correspondre à une expression rationnelle
que le groupe définit pour attribuer automatiquement le statut
du membre.</para>
</listitem>
</orderedlist>
</section>
<section>
<title>Affecter les commandes de groupe aux produits</title>
<para>
Sur la page d'édition du produit, il y a une page pour éditer le
<quote>Group Controls</quote>
d'un produit. Cela vous permet de
paramétrer le lien qui existe entre un groupe et un produit.
Les groupes peuvent être applicables, par défaut
et obligatoires ainsi qu'être utilisés pour contrôler qui a le droit d'entrer un rapport de bogue
ou pour limiter à un groupe particulier le droit de modifier les rapports de bogue.
</para>
<para>
Pour chaque groupe, il est possible de spécifier si être membre de ce
groupe...
</para>
<orderedlist>
<listitem>
<para>
est nécessaire pour entrer un bogue (Entry).
</para>
</listitem>
<listitem>
<para>
est sans objet pour ce produit (NA),
est une restriction que les membres de ce groupe peuvent ajouter à ce produit (Shown),
est une restriction par défaut lorsque les membres
de ce groupe ajoutent un bogue à ce produit (Default),
ou est une restriction obligatoire à placer sur les bogues
de ce produit (Mandatory).
</para>
</listitem>
<listitem>
<para>
est sans objet pour ce produit pour les non membres (NA),
est une restriction que les non membres de ce
groupe peuvent ajouter à ce produit (Shown),
est une restriction par défaut lorsque les non membres de ce
groupe ajoutent un bogue à ce produit (Default),
ou est une restriction obligatoire à placer sur les bogues
de ce produit lorsqu'ils sont entrés par des non membres (Mandatory).
</para>
</listitem>
<listitem>
<para>
est nécessaire pour faire <emphasis>toute</emphasis> modification
sur les bogues de ce produit <emphasis>y compris des commentaires</emphasis>.
</para>
</listitem>
</orderedlist>
<para>
Ces paramètres sont souvent indiqués dans cet ordre. Par exemple,
pour un produit qui demande, pour entrer un bogue, qu'un
utilisateur soit membre du groupe <quote>foo</quote> et demande
ensuite que le bogue reste en permanence restreint au groupe
<quote>foo</quote> et enfin que seuls les membres du groupe
<quote>foo</quote> puissent modifier ce bogue, bien que celui-ci
puisse être visible pour d'autres, le paramétrage du groupe serait
résumé ainsi :
</para>
<programlisting>
foo: ENTRY, MANDATORY/MANDATORY, CANEDIT
</programlisting>
</section>
<section>
<title>Applications courantes des commandes de groupe</title>
<section>
<title>Accès utilisateur général avec le groupe Securité</title>
<para>
Pour laisser tout utilisateur soumettre des bogues dans chaque
produit (A, B, C...) et laisser tout utilisateur soumettre ces
bogues dans un groupe de sécurité...
</para>
<programlisting>
Produit A...
security: SHOWN/SHOWN
Produit B...
security: SHOWN/SHOWN
Produit C...
security: SHOWN/SHOWN
</programlisting>
</section>
<section>
<title>Accès utilisateur général avec un produit Security</title>
<para>
Pour laisser tout utilisateur soumettre des bogues dans un produit
de sécurité tout en gardant ces bogues invisibles à toute personne
étrangère au groupe securityworkers à moins qu'un membre du groupe
securityworkers enlève cette restriction...
</para>
<programlisting>
Product Security...
securityworkers: DEFAULT/MANDATORY
</programlisting>
</section>
<section>
<title>Isolation du produit avec un groupe commun</title>
<para>Pour laisser les utilisateurs du produit A accéder aux bogues du
produit A, les utilisateurs du produit B à accéder au produit B et l'équipe du
support à accéder aux deux, 3 groupes sont nécessaires</para>
<orderedlist>
<listitem>
<para>Support : contient les membres de l'équipe de support.</para>
</listitem>
<listitem>
<para>AccessA : contient les utilisateurs du produit A et le groupe Support.</para>
</listitem>
<listitem>
<para>AccessB : contient les utilisateurs du produit B et le groupe Support.</para>
</listitem>
</orderedlist>
<para>
Une fois ces 3 groupes définis les commandes de groupe des
produits peuvent être fixées à...
</para>
<programlisting>
Product A...
AccessA: ENTRY, MANDATORY/MANDATORY
Product B...
AccessB: ENTRY, MANDATORY/MANDATORY
</programlisting>
<para>
Si on le souhaitait, le groupe Support pourrait être autorisé à rendre
les bogues inaccessibles aux utilisateurs et pourrait être autorisé à publier
les bogues concernant tous les utilisateurs dans un produit courant qui est en
lecture seule pour toute personne extérieure au groupe de soutien. Cette configuration
pourrait être...
</para>
<programlisting>
Product A...
AccessA: ENTRY, MANDATORY/MANDATORY
Support: SHOWN/NA
Product B...
AccessB: ENTRY, MANDATORY/MANDATORY
Support: SHOWN/NA
Product Common...
Support: ENTRY, DEFAULT/MANDATORY, CANEDIT
</programlisting>
</section>
</section>
</section>
<section id="upgrading">
<title>Mise à niveau aux nouvelles versions</title>
<warning>
<para>Mettre à niveau est une opération à sens unique. Il est conseillé de faire une copie de sauvegarde
de votre base de données et répertoire courant Bugzilla avant de tenter une mise à niveau. Si vous souhaitez
repasser à la version précédente pour une raison quelconque, vous devrez
restaurer à partir de ces copies de sauvegarde.
</para>
</warning>
<para>Mettre à niveau Bugzilla est une chose que nous voulons tous faire de temps en temps,
que ce soit pour récupérer de nouvelles fonctionnalités ou les dernières failles de sécurité. La facilité
à télécharger dépend de quelques facteurs :
</para>
<itemizedlist>
<listitem>
<para>Si la nouvelle version est une révision ou version intermédiaire</para>
</listitem>
<listitem>
<para>Le nombre de modifications en local (s'il y en a) qui ont été faites</para>
</listitem>
</itemizedlist>
<para>Il existe trois manières différentes de mettre à jour votre installation.
</para>
<orderedlist>
<listitem>
<para>En utilisant un CVS (<xref linkend="upgrade-cvs"/>)</para>
</listitem>
<listitem>
<para>En téléchargeant une nouvelle archive (<xref linkend="upgrade-tarball"/>)</para>
</listitem>
<listitem>
<para>En appliquant les programmes de correction appropriés (<xref linkend="upgrade-patches"/>)</para>
</listitem>
</orderedlist>
<para>Chacune de ces options a ses propres avantages et inconvénients; celle qui vous correspond
dépend du temps écoulé depuis la dernière fois que vous avez fait une installation et/ou
de votre configuration réseau.
</para>
<para>Les révisions sont normalement officialisées seulement lorsque des points faibles
au niveau sécurité sont en cause; ils se distinguent par une augmentation du troisième chiffre.
Par exemple, lorsque 2.16.6 est sorti, c'était une amélioration de la 2.16.5.
</para>
<para>Les versions intermédiaires sont généralement émises lorsque l'équipe de développement
Bugzilla estime que suffisamment de progrès a été fait globalement. Elles sont souvent obtenus par une
période de stabilisation et de ***release candidates***, par contre, l'utilisation des
versions de développement et de ***release candidates*** échappe à la portée de ce
document. Les versions intermédiaires se distinguent par une augmentation dans le
deuxième numéro, celui de version mineure. Par exemple, 2.18.0 est une version intermédiaire
plus récente que 2.16.5.
</para>
<para>Les exemples des chapitres suivants sont rédigés comme si l'utilisateur passait
à la version 2.18.1, mais les procédures sont les mêmes que l'on passe à une nouvelle
version intermédiaire ou que l'on essaie simplement de récupérer une nouvelle version
bugfix. Par contre, le risque d'avoir des problèmes est plus grand lorsque 'on passe
à une version intermédiaire, surtout si des modifications locales ont été effectuées.
</para>
<para>Dans ces exemples, l'installation Bugzilla de l'utilisateur se trouve à
<filename>/var/www/html/bugzilla</filename>. Si ce n'est pas le même emplacement pour
votre installation Bugzilla, vous n'avez qu'à remplacer par les chemins qui
conviennent là où c'est nécessaire.
</para>
<example id="upgrade-cvs">
<title>Mise à niveau par le CVS</title>
<para>Chaque version de Bugzilla, que ce soit une version intermédiaire ou un
bugfix, est marquée dans le CVS. Ainsi, chaque tarball qui a été distribué
depuis la version 2.12 a été créé de telle sorte qu'il peut être utilisé avec
le CVS une fois dépaqueté. Une telle manière de procéder exige cependant que
vous puissiez accéder à cvs-mirror.mozilla.org sur le port 2401.
<tip>
<para>Si vous en avez la possibilité, la mise à jour par le CVS est probablement
la méthode la moins pénible, particulièrement si vous avez beaucoup de modifications locales.
</para>
</tip>
</para>
<programlisting>
bash$ <command>cd /var/www/html/bugzilla</command>
bash$ <command>cvs login</command>
Logging in to :pserver:anonymous@cvs-mirror.mozilla.org:2401/cvsroot
CVS password: <command>anonymous</command>
bash$ <command>cvs -q update -r BUGZILLA-2_18_1 -dP</command>
P checksetup.pl
P collectstats.pl
P globals.pl
P docs/rel_notes.txt
P template/en/default/list/quips.html.tmpl
</programlisting>
<para>
<caution>
<para>Si une ligne en sortie de <command>cvs update</command>
commence avec un <computeroutput>C</computeroutput>, cela indique un
fichier avec des modifications locales que le CVS a été incapable d'intégrer. Vous
avez besoin de résoudre ces conflits manuellement avant que Bugzilla (ou au
moins la partie utilisant ce fichier) devienne utilisable.
</para>
</caution>
<note>
<para>vous aurez besoin d'exécuter <command>./checksetup.pl</command>
avant que votre mise à niveau de Bugzilla soit achevée.
</para>
</note>
</para>
</example>
<example id="upgrade-tarball">
<title>Mettre à niveau avec le tarball</title>
<para>Si vous être dans l'incapacité ou n'avez pas envie d'utiliser le CVS, une autre option
toujours possible est d'obtenir la dernière archive tar. Ceci est la plus
difficiles des options à utiliser, surtout si vous avez des modifications locales.
</para>
<programlisting>
bash$ <command>cd /var/www/html</command>
bash$ <command>wget ftp://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.18.1.tar.gz</command>
<emphasis>Affichage omis</emphasis>
bash$ <command>tar xzvf bugzilla-2.18.1.tar.gz</command>
bugzilla-2.18.1/
bugzilla-2.18.1/.cvsignore
bugzilla-2.18.1/1x1.gif
<emphasis>Affichage tronqué</emphasis>
bash$ <command>cd bugzilla-2.18.1</command>
bash$ <command>cp ../bugzilla/localconfig* .</command>
bash$ <command>cp -r ../bugzilla/data .</command>
bash$ <command>cd ..</command>
bash$ <command>mv bugzilla bugzilla.old</command>
bash$ <command>mv bugzilla-2.18.1 bugzilla</command>
bash$ <command>cd bugzilla</command>
bash$ <command>./checksetup.pl</command>
<emphasis>Affichage omis</emphasis>
</programlisting>
<para>
<warning>
<para>
Si les commandes <command>cp</command> terminent toutes les
deux par un point, ce qui est un détail important, cela
indique à la console que le répertoire de destination est le
répertoire de travail courant. De la même façon, le point au
début de la commande <command>./checksetup.pl</command> est
important et ne doit pas être omis.
</para>
</warning>
<note>
<para>
Vous devrez rétablir à la main toute modification locale que
vous avez faite.
</para>
</note>
</para>
</example>
<example id="upgrade-patches">
<title>Mise à niveau avec les correctifs</title>
<para>L'équipe de développement Bugzilla rend généralement disponible un correctif pour
aller d'une révision donnée à la nouvelle. Vous pouvez
aussi lire les release notes et utiliser les correctifs attachés aux
bogues décrits mais il est plus simple de prendre le correctif publié car
les correctifs sont quelques fois modifiés avant d'être intégré.
Il est aussi théoriquement possible de
parcourir la liste des bogues corrigés et de choisir les correctifs d'une
révision qu'on veut appliquer mais ceci n'est pas recommandé non plus car
on obtient un Bugzilla qui ne correspond a aucune version officielle.
Ceci rend les mises à niveau futures plus compliqués.
</para>
<programlisting>
bash$ <command>cd /var/www/html/bugzilla</command>
bash$ <command>wget ftp://ftp.mozilla.org/pub/mozilla.org/webtools/bugzilla-2.18.0-to-2.18.1.diff.gz</command>
<emphasis>Affichage omis</emphasis>
bash$ <command>gunzip bugzilla-2.18.0-to-2.18.1.diff.gz</command>
bash$ <command>patch -p1 < bugzilla-2.18.0-to-2.18.1.diff</command>
patching file checksetup.pl
patching file collectstats.pl
patching file globals.pl
</programlisting>
<para>
<caution>
<para>N'oubliez pas que mettre à jour à partir d'un fichier correctif ne modifie pas les entrées de
votre répertoire <filename id="dir">CVS</filename>. Cela peut rendre plus difficile une future mise
à niveau par le CVS (<xref linkend="upgrade-cvs"/>).
</para>
</caution>
</para>
</example>
</section>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-always-quote-attributes:t
sgml-auto-insert-required-elements:t
sgml-balanced-tag-edit:t
sgml-exposed-tags:nil
sgml-general-insert-case:lower
sgml-indent-data:t
sgml-indent-step:2
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
sgml-minimize-attributes:nil
sgml-namecase-general:t
sgml-omittag:t
sgml-parent-document:("Bugzilla-Guide.xml" "book" "chapter")
sgml-shorttag:t
sgml-tag-region-if-active:t
End:
-->
