Écriture de scripts de projet avancés

Cette section décrit les situations dans lesquelles vous devez utiliser des scripts de projet avancés ainsi que la procédure à suivre.

Dans cette rubrique :

Présentation des scripts de projet avancés
Scénarios d’utilisation de scripts de projet avancés
Préalablement à l’écriture de scripts de projet avancés
Écriture de scripts de projet avancés

Présentation des scripts de projet avancés

Définissez des scripts de projet avancés afin de traiter les données du projet sur le serveur principal. Ils vous permettent de traiter les autorisations des utilisateurs du projet qui sont adaptées aux besoins spécifiques de votre projet en matière de création, de mise à jour et de suppression d’entités. En outre, ils garantissent l’intégrité des données et la cohérence du comportement entre les applications qui utilisent l’API REST ALM.

Déclenchement de scripts de projet avancés

Les scripts de projet avancés sont déclenchés par des demandes envoyées à la base de données lorsqu’un utilisateur a terminé une action dans l’interface utilisateur du Client Web.

Les scripts de projet avancés prennent effet après les scripts de projet déclenchés par des événements. Ils servent de mécanisme supplémentaire pour garantir que tout fonctionne comme prévu.

Par exemple, lorsqu’un utilisateur clique sur Nouvelle anomalie dans l’interface utilisateur du Client Web, l’événement Bug_New est déclenché. ALM écoute les scripts de projet écrits dans l’événement Bug_New et la boîte de dialogue Nouvelle anomalie est personnalisée en conséquence. Une fois que l’utilisateur a envoyé l’anomalie, une demande de création d’anomalie est envoyée en arrière-plan et la demande Bug_Create est déclenchée. ALM gère les données relatives aux anomalies en fonction des scripts écrits dans la demande Bug_Create.

Application des scripts de projet avancés

Par défaut, les scripts de projet avancés s’appliquent uniquement au client Web. Si vous souhaitez les appliquer à toutes vos applications utilisant l’API REST ALM, définissez le paramètre de site CLIENT_TYPES_BYPASS_REST_WF sur Aucun. Pour plus d’informations sur ce paramètre, voir Paramètres du site ALM.

Retour en haut

Scénarios d’utilisation de scripts de projet avancés

Voici quelques scénarios d’utilisation dans lesquels les scripts de projet avancés peuvent s’avérer utiles.

Scénario d’utilisation n°1 : Validation cohérente entre les applications

Supposons que vous définissiez des scripts de projet afin de rendre obligatoire le champ Détecté dans la release (BG_DETECTED_IN_REL) pour tous les groupes d’utilisateurs lorsqu’un utilisateur crée une anomalie.

Copy code

function SetFieldApp(fieldName, Req){
    var bugfield = Bug_Fields(fieldName);
    bugfield.IsRequired = Req;
       console.log("SetFieldApp");
}

function FieldCust_AddDefect()
{
    for (var i= 0; i<= Bug_Fields.Count -1; i++)
    {
        SetFieldApp(Bug_Fields.FieldById(i).FieldName, false, false, 100, 0);
    }
    SetFieldApp("BG_DETECTED_IN_REL", true);
}

Les scripts ci-dessus fonctionnent correctement lorsque l’utilisateur crée une anomalie à partir de l’interface utilisateur du Client Web.

Toutefois, si un utilisateur crée une anomalie à partir d’une autre application qui utilise l’API REST ALM, par exemple à partir du complément Excel, l’anomalie peut être envoyée même lorsque le champ Détecté dans la release n’est pas rempli. Pour vous assurer que le champ Détecté dans la release est toujours rempli pour les nouvelles anomalies, quelle que soit la façon dont elles sont créées, vous devez écrire des scripts de projet avancés afin d’étendre la validation.

Vos scripts de flux de travail avancés peuvent ressembler à ce qui suit :

Copy code

function setFieldProperties(fieldName, Req){
    var bugfield = Bug_Fields(fieldName);
    bugfield.IsRequired = Req;
}

function Bug_Create(){
    setFieldProperties("BG_DETECTED_IN_REL", true);
}

Scénario d’utilisation n°2 : Gestion des autorisations des utilisateurs sur mesure

Supposons que vous définissiez des scripts de projet comme suit pour remplir automatiquement le champ Priorité d’une anomalie avec la valeur Urgent lorsque la valeur du champ Gravité est définie sur Élevée, Très élevée ou Urgente :

Copy code

function Bug_FieldChange(fieldName){
     if(fieldName === 'BG_SEVERITY'){
        var severity = Bug_Fields("BG_SEVERITY").Value ;
        if(severity === '3-High'||severity === '4-Very High'||severity === '5-Urgent'){
            Bug_Fields("BG_PRIORITY").Value = '5-Urgent';
        }
    }
}

Les scripts ci-dessus fonctionnent correctement pour les utilisateurs autorisés à modifier le champ Priorité.

Cependant, si un groupe d’utilisateurs n’a pas l’autorisation de modifier le champ Priorité, celui-ci ne peut pas être rempli automatiquement lorsqu’un utilisateur du groupe définit le champ Gravité sur Élevée, Très élevée ou Urgente. Par conséquent, vous devez écrire des scripts de projet avancés si vous souhaitez obtenir les deux résultats suivants :

Toujours interdire au groupe d’utilisateurs de modifier le champ Priorité dans le Client Web.
Vous assurer que le champ Priorité est mis à jour en conséquence tant que le champ Gravité est défini sur une valeur spécifique, quelle que soit l’autorisation de modification de l’utilisateur sur le champ Priorité.

Vos scripts de projet avancés peuvent ressembler à ce qui suit :

Copy code

function Bug_Update(){
    var severity = Bug_Fields("BG_SEVERITY").Value ;
    if(severity === '3-High'||severity === '4-Very High'||severity === '5-Urgent'){
        Bug_Fields("BG_PRIORITY").Value = '5-Urgent';
    }
}

Retour en haut

Préalablement à l’écriture de scripts de projet avancés

Avant d’écrire des scripts de projet avancés, vous devez vous familiariser avec les demandes et les objets.

Demandes de scripts de projet avancés

Placez votre code dans la demande appropriée afin qu’il soit invoqué lorsqu’une demande est envoyée à la base de données.

Le tableau suivant décrit le moment où chaque demande est déclenchée et les opérations que vous pouvez réaliser en modifiant la demande :

Demande	Description
<entity>_Create	Cette demande est déclenchée lorsqu’une entité est ajoutée à la base de données ALM. Par exemple, la demande Req_Create est déclenchée lorsqu’une nouvelle exigence doit être ajoutée à la base de données. La demande Bug_Create est déclenchée lorsqu’une nouvelle anomalie doit être ajoutée à la base de données.
<entity>_Update	Cette demande est déclenchée lors de la mise à jour d’une entité dans la base de données ALM. Par exemple, la demande Req_Update est déclenchée lorsque les mises à jour d’une exigence existante doivent être ajoutées à la base de données ALM. La demande Bug_Update est déclenchée lorsque des mises à jour d’une anomalie existante doivent être ajoutées à la base de données ALM.
<entity>_Delete	Cette demande est déclenchée lorsqu’une entité est supprimée de la base de données ALM. Par exemple, la demande Req_Delete est déclenchée lorsqu’une exigence existante doit être supprimée de la base de données ALM. La demande Bug_Delete est déclenchée lorsqu’une anomalie existante doit être supprimée de la base de données ALM.
Fonction partagée	Écrivez du code qui peut être utilisé par plusieurs demandes dans la fonction partagée.

Objets pour les scripts de projet avancés

Votre script effectue des personnalisations en se basant sur les informations obtenues à partir des objets pertinents, par exemple sur les informations relatives aux champs et aux utilisateurs.

Pour plus d’informations, voir Objets.

Retour en haut