<?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>&nbsp;:

          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>&nbsp;:

          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>&nbsp;:

          permet de créer automatiquement ou pas des groupes
          quand des produits nouveaux sont créés.
 
        </para>
      </step>

      <step>
        <para>
          <command>useentrygroupdefault</command>&nbsp;:

          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>&nbsp;:

          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>&nbsp;:

          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>&nbsp;:

          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>&nbsp;:

          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>&nbsp;:

          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>&nbsp;:

          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>&nbsp;:

          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>&nbsp;:

          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é&nbsp;!).
          </para>
        </note>
      </step>

      <step>
        <para>
          <command>supportwatchers</command>&nbsp;:

          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>&nbsp;:

          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&nbsp;:
        
        </para>

        <itemizedlist>
          <listitem>
            <para>

            <emphasis>Login Name</emphasis>&nbsp;: 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>&nbsp;: 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>&nbsp;: 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>&nbsp;: 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&nbsp;!
              </para>
            </warning>
          </listitem>

          <listitem>
            <para>

            <emphasis>&lt;groupname&gt;</emphasis>&nbsp;: 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>&nbsp;: 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&nbsp;: l'état 
            <quote>New</quote>).</para>

          </listitem>

          <listitem>
            <para>
            
            <emphasis>creategroups</emphasis>&nbsp;: cette option permet 
            à un utilisateur de créer et détruire des groupes dans 
            Bugzilla.
            
            </para>
          </listitem>

          <listitem>
            <para>
            
            <emphasis>editbugs</emphasis>&nbsp;: 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>&nbsp;: 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>&nbsp;: 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>&nbsp;: cette option permet à 
            un utilisateur de faire ce que vous faîtes en ce 
            moment&nbsp;: é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>&nbsp;: cette option permet 
            à un utilisateur de changer les paramètres de Bugzilla (en 
            utilisant <filename>editparams.cgi</filename>).
            
            </para>
          </listitem>

          <listitem>
            <para>
            
            <emphasis>&lt;productname&gt;</emphasis>&nbsp;: 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&nbsp;:</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&nbsp;:</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&nbsp;:</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&nbsp;:
    
    </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&nbsp;: 
       <quote>Devrions nous corriger ce bogue avant de sortir la version 
       2.0&nbsp;?</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&nbsp;:
       <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&nbsp;: 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&nbsp;:
         <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&nbsp;: <quote>aucun statut</quote>&nbsp;; 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&nbsp;: 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&nbsp;:

         <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&nbsp;:

        </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&nbsp;: 
            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&nbsp;:</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&nbsp;:__Any__</quote> et vous excluez 
            <quote>Jet&nbsp;: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&nbsp;:</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&nbsp;:  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&nbsp;:</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>&nbsp;: 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>&nbsp;: à 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>&nbsp;: 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&nbsp;: 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&nbsp;:</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&nbsp;:
      
      </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&nbsp;: contient les membres de l'équipe de support.</para>
        </listitem>
        <listitem>
          <para>AccessA&nbsp;: contient les utilisateurs du produit A et le groupe Support.</para>
        </listitem>
        <listitem>
          <para>AccessB&nbsp;: 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&nbsp;:
    </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 &lt; 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:
-->
Heberge par Ikoula