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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tout texte dans ce champ sera affiché en haut de chaque page HTML de cette installation de Bugzilla. Ce texte n'est pas encadré dans des balises. Pour de meilleurs résultats, encadrez le texte avec des balises « <div> ». tout attribut de style de la CSS peut être appliqué. Par exemple, pour mettre le texte en vert dans une boîte rouge, ajoutez « id=message » à la balise « <div> ».

Si cette installation de Bugzilla se trouve derrière un proxy, saisissez les informations du proxy ici pour permettre à Bugzilla d'accéder à Internet. Bugzilla nécessite un accès à Internet pour utiliser le paramètre upgrade_notification (ci-dessous). Si le proxy nécessite une authentification, utilisez la syntaxe : http://user:pass@proxy_url/.

Active ou désactive la notification sur la page d'accueil de cette installation de Bugzilla quand une nouvelle version de Bugzilla est disponible. Cette notification n'est visible que des administrateurs. Choisissez « disabled », pour désactiver la notification. Sinon, choisissez pour quelles versions de Bugzilla vous voulez être prévenu : « development_snapshot » est la dernière version du tronc ; « latest_stable_release » est la dernière version disponible sur la branch stable la plus récente ; « stable_branch_release » est la version la plus récente de la branche sur laquelle est basée cette installation.

Définit l'expression régulière utilisée pour valider les adresses électroniques utilisées pour les noms de connexion. Par défaut, une correspondance totale est recherchée (par ex. « utilisateur@exemple.com ») d'une façon légèrement plus restrictive que ce sui est autorisé dans la RFC 2822. Certaines installations de Bugzilla n'autorisent que des noms d'utilisateurs locaux (par ex. « utilisateur » au lieu de « utilisateur@exemple.com »). Dans ce cas, ce paramètre doit être utilisé pour définir le domaine des adresses électroniques.

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

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

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

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

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

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

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

Détermine la création automatique de groupes lors de la création de nouveaux produits. Si ce paramètre est activé, les groupes seront utilisés pour les requêtes sur les bogues.

Si ce paramètre est sélectionné, la visibilité de l'utilisateur sera restreinte aux membres des groupes, tels que sélectionnés dans les paramètres de configuration de groupe. Chaque groupe défini par utilisateur peut être autorisé à voir les membres des autres groupes sélectionnés. Pour des détails sur la configuration des groupes (y compris les restrictions de visibilité), consulter Section 3.15.2, « Modification de groupes et affectation de restrictions ».

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

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

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

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

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

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

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

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

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

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

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

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

Ex. : « uid »

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

Ex. : « mail »

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

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

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

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

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

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

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

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

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

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

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

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

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

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