Les entreprises ont souvent des règles dictant quels employés, ou quelles catégories d'employés, sont autorisés à changer certaines parties dans le système de bogues. Par exemple, seul le Contact Assurance Qualité assigné au bogue devrait avoir la permission de donner à un bogue le statut VERIFY. Bugzilla a été conçu pour vous faciliter l'écriture de vos propres règles personnalisées afin de définir qui a la permission d'effectuer telle ou telle sorte de changement de valeur.

Pour une flexibilité maximale, ce type de personnalisation implique l'édition du code Perl de Bugzilla. Ceci donne à l'administrateur tout contrôle sur qui exactement est autorisé à faire quoi. La fonction appropriée s'appelle CheckCanChangeField() et se situe dans process_bug.cgi dans votre répertoire de Bugzilla. Si vous ouvrez ce fichier et que vous cherchez la chaîne « sub CheckCanChangeField », vous la trouverez.

Cette fonction est accompagnée d'un commentaire détaillé afin de vous permettre de comprendre exactement comment elle fonctionne, et vous donner une idée sur la manière d'y effectuer des changements. Certaines sections sont marquées comme ne devant pas être changées : il s'agit de la partie « tuyauterie » qui fait marcher tout le reste. Entre ces sections, vous pourrez trouver des petits bouts de code comme :

    # Permettre au propriétaire de tout changer.
    if ($ownerid eq $whoid) {
        return 1;
    }

Ce que fait ce bout de code est assez évident.

Alors, comment s'y prend-on pour changer cette fonction ? Et bien, des changements simples peuvent êtres effectués juste en supprimant des morceaux ; par exemple, si vous vouliez empêcher tout utilisateur de rajouter un commentaire à un bogue, supprimez simplement les lignes marquées « Autoriser toute personne à changer les commentaires ». Si vous ne voulez pas que le rapporteur du bogue ait des droits particuliers sur les bogues qu'elle a soumis, supprimez simplement toute la section qui le concerne.

Les personnalisations plus complexes ne sont pas beaucoup plus difficiles. En gros, vous ajoutez un test au bon endroit dans la fonction, c'est-à-dire après que toutes les variables que vous utilisez aient été initialisées. Ainsi, ne touchez pas à la variable $ownerid avant d'avoir obtenu $ownerid depuis la base de données. Vous pouvez soit ajouter un test positif, qui renvoie 1 (permission accordée) si certaines conditions sont vraies ou un test négatif, qui retourne 0 (permission refusée). Par exemple :

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

Cela fait que seuls les utilisateurs du groupe "quality_assurance" peuvent changer le champ Contact QA d'un bug.

Un exemple plus bizarre :

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

Cela fait que si l'utilisateur essaie de changer le champ priorité et que son adresse électronique est @example.com, il n'y parviendra qu'à la condition que la précédente valeur du champ ait été "P1". Pas très utile, mais démonstratif.

Pour une liste des noms de champs possibles, consultez la liste appelée @::logcolumns dans le fichier data/versioncache. Si vous avez besoin d'aide pour écrire des règles personnalisées pour votre entreprise, demandez dans le groupe de discussion.