Cette fonctionnalité doit être considérée comme expérimentale ; le code Bugzilla que vous changerez n'est pas stable et pourrait être modifié ou déplacé entre les versions. Soyez conscients que les modifications que vous pourront être à refaire ou à porter si des modifications du code interne de Bugzilla sont faites entre les versions et que vous faites une mises à jour de Bugzilla.

Les sociétés ont souvent des règles pour déterminer quels employés ou classes d'employés sont autorisés à modifier certaines choses dans le système de suivi de bogues. Par exemple, seul le contact QA désigné peut être autorisé à marquer le bogue VÉRIFIÉ. Bugzilla a été conçu pour vous faciliter la tâche d'écrire vos propres règles pour définir qui est autorisé à faire certains types de modifications.

Par défaut, les responsables, les responsables QA et les utilisateurs ayant des privilèges editbugs peuvent modifier tous les champs des bogues, sauf les restrictions de groupes (à moins qu'ils ne soient membres des groupes qu'ils essaient de modifier). Les rapporteurs de bogue ont la possibilité de modifier quelques champs, mais de manière beaucoup plus restrictive. Les autres utilisateurs sans privilèges editbugs, ne peuvent pas modifier les bogues, sauf pour ajouter un commentaire ou s'ajouter à la liste « Copie à ».

Pour une flexibilité maximale, personnaliser cela signifie de modifier le code Perl de Bugzilla. Ceci donne à l'administrateur le contrôle total sur ce que chacun peut faire. La méthode pour réaliser cela s'appelle check_can_change_field(), et se trouve dans le fichier Bug.pm de votre répertoire Bugzilla/. Si vous ouvrez ce fichier pour y rechercher « sub check_can_change_field », vous la trouverez.

Cette méthode a été soigneusement commentée pour vous permettre de voir exactement comment elle fonctionne et vous donner une idée sur la façon de la modifier. Certaines sections identifiées ne doivent pas être modifiées - c'est le « squelette » qui permet au reste de la fonction de fonctionner. Entre ces sections, vous trouverez des morceaux de code comme :

    # Allow the assignee to change anything.
    if ($ownerid eq $whoid) {
        return 1;
    }

Il est évident de savoir ce que cette partie de code fait.

Alors, comment modifier cette fonction ? Certains changements simples peuvent être accomplis en supprimant quelques parties - par exemple, si vous voulez empêcher un utilisateur d'ajouter un commentaire à un bogue, supprimez les lignes marquées « Allow anyone to change comments. » Si vous ne voulez pas que le rapporteur ait des droits spéciaux sur les bogues qu'il a rapporté, supprimez toute la section concernant le rapporteur.

Des personnalisations plus complexes ne sont pas beaucoup plus difficiles. En gros, vous ajoutez un point de vérification au bon endroit dans la fonction, c-à-d. après que toutes les variables que vous utilisez ont été définies. Aussi, ne cherchez pas « $ownerid » avant que cette variable n'ait été obtenue de la base de données. Vous pouvez ajouter soit un point de vérification positif, qui renvoie « 1 » (autoriser) si certaines conditions sont vérifiées, soit un point de vérification négatif, qui renvoie « 0 » (refuser). Par ex. :

    if ($field eq "qacontact") {
        if (Bugzilla->user->in_group("quality_assurance")) {
            return 1;
        } 
        else {
            return 0;
        }
    }

Ceci signifie que seuls les utilisateurs du groupe « quality_assurance » peuvent changer le champ « Contact QA » d'un bogue.

Plus bizarre :

    if (($field eq "priority") &&
        (Bugzilla->user->email =~ /.*\@exemple\.com$/))
    {
        if ($oldvalue eq "P1") {
            return 1;
        } 
        else {
            return 0;
        }
    }

Ceci signifie que si l'utilisateur essaie de changer le champ « Priorité », et que son adresse électronique est « …@exemple.com », il ne peut le faire que si l'ancienne valeur du champ était « P1 ». Pas très utile, mais illustratif.

	Si vous modifiez le fichier process_bug.cgi, ne changez pas les blocs de code marqués « DO_NOT_CHANGE ». Si vous le faites, cela compromettra la sécurité de votre installation ou provoquera empêchera votre de fonctionner.

Pour une liste des noms de champs possibles, consultez la table « bugs » dans la base de données. Si vous avez besoin d'aide pour écrire des règles personnalisées pour votre organisation, demandez de l'aide sur le forum.