Utilisez SIL au maximum

Bonjour à tous!

Dans cet article, je voudrais à nouveau parler de SIL . Nous savons tous que SIL dispose d'un grand nombre de fonctions qui facilitent grandement l'automatisation de nos actions dans Atlassian Jira et Confluence.

Nous écrivons des scripts SIL dans l'élément de menu SIL Manager et la plupart d'entre nous ne font pas attention au reste des éléments de menu. Je parle de ces éléments de menu:



dans cet article, je vais passer en revue chaque élément de menu et vous dire ce que vous pouvez obtenir de chaque élément.

Je tiens également à noter que nous parlons maintenant du moteur SIL , ce qui signifie que toutes ces fonctionnalités sont disponibles gratuitement.

Utilisation de champs personnalisés


Ce menu fournit des informations sur la façon dont chaque champ personnalisé est utilisé dans votre instance Jira. Les informations du vendeur peuvent être trouvées ici .
Vous pouvez voir tous les champs de votre Jira si vous allez dans la boîte de vitesses -> Problèmes -> Champs personnalisés.



Voici à quoi ressemble l'écran si vous accédez au menu Utilisation des champs personnalisés:



comme vous pouvez le voir, vous pouvez sélectionner n'importe quel champ personnalisé et obtenir des informations à ce sujet. Afin de filtrer les champs disponibles, commencez simplement à taper les caractères et la liste des champs personnalisés sera filtrée par ces caractères.



Après avoir vu votre champ, cliquez dessus:



Vous pouvez voir les informations suivantes sur ce champ:

  • Alias ​​Sil
  • Écrans et projets dans lesquels le champ est utilisé.
  • Numéros de ligne des scripts dans lesquels ce champ est utilisé.

Au moment de la rédaction, il existe un tel bug CADS-6237 , qui indique que les informations sur l'utilisation du champ dans les scripts ne sont pas affichées à l'écran. C'est comme ça. J'ai cette info car j'ai modifié le code.

Rediriger la configuration de la page


Cette option vous permet de gérer intelligemment la redirection vers des pages dans Jira. Vous pouvez trouver des informations auprès du fournisseur ici . Pour vous dire la vérité, il m'a fallu des heures pour comprendre pourquoi cette option était nécessaire et comment l'utiliser, je vais donc expliquer cette option avec un exemple.
Voici un exemple.

Supposons que dans notre Jira, chaque employé saisisse chaque mois une facture pour recevoir de l'argent sous forme de ticket dans le projet INV.



Comme vous pouvez le voir, Alexey Matveev a ouvert deux comptes pour mars et avril.

Mais le service du personnel ne fonctionne pas à Jira, mais dans un système externe, et ils ont une page dans ce système externe pour chaque employé avec un lien dans Jira, ce qui conduit au ticket de l'employé avec le dernier compte.

À quoi ressemblera ce lien?

Bien sûr, nous pouvons faire le lien comme çahttp: // localhost: 2990 / jira / Browse / INV-2 . Mais INV-2 sera le dernier score d'avril. En mai, il y aura un billet avec un compte différent. On pourrait changer le lien tous les mois sur la page d'un employé du service des ressources humaines, mais c'est trop compliqué. Quelque chose de plus simple est nécessaire.

Et juste rediriger la configuration de la page vient à notre aide.

Configurons.

Dans notre système de service RH, le lien ressemblera à ceci:

http://localhost:2990/jira/plugins/servlet/kredi?userName=Alexey+Matveev

Nous ne parlons pas d'un ticket, mais des plugins / servlet / kredi servlet, qui redirigeront le ticket dont nous avons besoin. Nous passerons le nom d'utilisateur complet en tant que paramètre, et sur la base de ce paramètre, notre servlet sera redirigé vers le ticket souhaité.
Nous avons fait le lien, maintenant nous devons faire la logique. Et nous faisons juste la logique dans le menu de configuration de la page de redirection. Ouvrez le menu et entrez le code suivant:

string userName = argv["userName"];

if (isNull(userName)) {
    return "/plugins/servlet/kredierror?customErrorTitle=User Not Provided&customErrorMessage=Provide user with userName parameter";
}
if (isNull(getUserByFullName(userName))) {
    return "/plugins/servlet/kredierror?customErrorTitle=User Not Found&customErrorMessage=User " + userName + " not found";
}
string [] k = selectIssues("project = INV and reporter = " + getUserByFullName(userName).username + " order by \"Invoice Date\" desc");
if (size(k) == 0) {
   return "/plugins/servlet/kredierror?customErrorTitle=Invoice Not Found&customErrorMessage=No invoices for "+ userName; 
}
return "/browse/" + k[0];

Le code effectue les opérations suivantes:

  • nous obtenons la valeur du paramètre userName, qui contient le nom complet de l'utilisateur.
  • on vérifie que le paramètre est passé, sinon passé, puis on redirige vers la page d'erreur.
  • nous vérifions que l'utilisateur portant ce nom complet est connecté à Jira. Sinon, redirigez vers la page d'erreur.
  • sélectionnez le dernier ticket avec un compte pour cet utilisateur. Si aucun ticket n'est trouvé, nous redirigeons vers la page d'erreur.
  • faire une redirection vers le ticket avec le dernier décompte.

Maintenant, vérifiez!

Nous allons d'abord créer un tel lien et cliquer dessus:

http://localhost:2990/jira/plugins/servlet/kredi?userName=Alexey+Matveev
Nous verrons un tel écran:

c'est vrai! Ceci est mon dernier décompte.
Maintenant, nous ne passerons pas l'utilisateur en tant que paramètre:

http://localhost:2990/jira/plugins/servlet/kredi

Et nous avons une page d'erreur:

c'est vrai!
Passons maintenant à un utilisateur qui n'est pas dans Jira:

http://localhost:2990/jira/plugins/servlet/kredi?userName=Super+Man

Nous avons vu une page avec une erreur:



Encore une fois, tout est vrai!

Et maintenant, nous allons transférer l'utilisateur qui n'a pas créé un seul ticket avec un compte:

http://localhost:2990/jira/plugins/servlet/kredi?userName=Tomas+Brook

Et nous avons une page avec une erreur:



tout fonctionne correctement!

Ainsi, nous avons apporté toute la logique de redirection à la bonne page dans Jira. Et c'est très pratique, donc dans ce cas, nous écrivons toute la logique dans SIL, ce qui est beaucoup plus facile que d'écrire la même logique dans un système externe.

Changer d'utilisateur


Cet élément de menu permet à l'administrateur de travailler sous n'importe quel utilisateur enregistré dans Jira sans connaître le mot de passe de cet utilisateur. Vous pouvez lire les informations du fournisseur ici .

Cela est nécessaire, par exemple, lorsqu'un utilisateur dit que Jira se comporte incorrectement et que l'administrateur ne peut pas le reproduire. Dans ce cas, l'administrateur peut se connecter à Jira en tant qu'utilisateur et voir ce qui se passe.



Afin de trouver rapidement l'utilisateur dont vous avez besoin, commencez simplement à taper les caractères qui sont dans le nom de cet utilisateur, et la liste sera filtrée par ces caractères:



Sélectionnez l'utilisateur souhaité et cliquez sur le bouton Changer! .. Vous serez connecté sous cet utilisateur.

Pour vous reconnecter sous votre utilisateur, sélectionnez l'option Revenir

à:



Configuration Sil


Ce menu vous permet de configurer SIL. Les informations du vendeur peuvent être trouvées ici .



SIL Home Directory vous permet de spécifier le répertoire dans lequel tous les scripts seront stockés. La valeur par défaut est JIRA_HOME / silprograms.

Charset vous permet de déterminer dans quel encodage vos scripts seront stockés. Il vaut mieux laisser l'encodage en UTF-8. J'ai une mauvaise idée de la raison pour laquelle ce paramètre peut être nécessaire.

S La taille du cache IL vous permet de spécifier le nombre de scripts dont le code a été converti en code octet Java et stocké dans le cache SIL.

Pourquoi avons-nous besoin d'un cache SIL?

Voici un exemple de code SIL:

string message = "My message";
runnerLog(message);

Afin d'exécuter ce code, nous devons le traduire en code octet Java. SIL contient un grand nombre de constructions: structures, fonctions, boucles, conditions, affectation, etc., donc pour traduire tout cela en code octet Java, vous avez besoin de temps, et le cache SIL vous permet simplement de gagner du temps. Le code est converti en code d'octet Java une fois et stocké dans le cache. Si ce code doit être à nouveau exécuté, le code d'octet Java prêt à l'emploi est extrait du cache SIL.

Par conséquent, si vous avez des milliers de scripts SIL, il est logique d'augmenter la taille du cache.

Source d'information


Cet élément de menu vous permet de configurer des sources de données pour les bases de données et d'utiliser ces sources dans votre code.

C'est pratique car vous n'avez pas besoin d'utiliser les paramètres d'accès à la base de données et le mot de passe utilisateur dans le code. Vous pouvez trouver des informations sur le fournisseur ici .



Configurons la source de la base de données.

Cliquez sur le bouton Ajouter une source de données et entrez les paramètres de la base de données:



J'ai un autre Jira installé sur mon ordinateur et je veux obtenir des données de la base de données de ce Jira.
Il est important de noter que SIL ne contient pas de pilotes jdbc dans sa distribution. Par conséquent, vous devez vous assurer de la disponibilité de ces pilotes à Jira. Ici, ici, vous pouvez lire comment le faire.

Maintenant, cliquez sur le bouton Enregistrer et la source de base de données appelée external_database sera créée:



Maintenant, utilisons cette source de base de données dans notre script:

string [] results = sql("external_database", "select * from cwd_group");
runnerLog(results);

J'exécute une requête dans ce script sql et j'obtiens le résultat:



Configuration de l'expéditeur du courrier


Cet élément du menu m'a fait souffrir en temps voulu. Les informations du vendeur peuvent être trouvées ici .

Vous pouvez envoyer des e-mails à l'aide de sendEmail et dans cet élément de menu, vous spécifiez les paramètres de cette fonction.



Mon répertoire de modèles vous permet de spécifier le chemin d'accès aux modèles de courrier électronique .

La langue de messagerie activée vous permet de spécifier, en fonction de l'expéditeur ou du destinataire, la langue du modèle d'e-mail. Si vous utilisez des modèles d'e-mail, vous pouvez créer le même modèle pour différentes langues. Vous pouvez en lire plus ici .

Envoyer un e-mail viavous permet de spécifier comment l'e-mail sera envoyé. Voici les options disponibles:

  • Expéditeur du conteneur - le message sera envoyé via la file d'attente de messagerie Jira standard.



De plus, vous pouvez voir des messages d'erreur et des messages de débogage lors de l'envoi d'e-mails dans le fichier atlassian-jira-outgoing-mail.log. Pour ce faire, vous devez toujours configurer la journalisation de l'envoi des e-mails à Jira. Vous pouvez en savoir plus sur la configuration de la journalisation dans Jira ici . Je préfère utiliser cette option particulière.
  • Expéditeur direct, personnalisé - vous pouvez spécifier votre propre serveur de messagerie pour l'envoi de messages:





Dans ce cas, vous ne verrez pas de messages d'erreur ou de débogage dans le fichier atlassian-jira-outgoing-mail.log, mais vous verrez des messages dans le fichier atlassian-jira.log.
  • Direct sender, default — , , Jira. atlassian-jira-outgoing-mail.log, atlassian-jira.log.
  • Null sender (log only) — atlassian-jira.log. . . com.keplerinfo ERROR, , . , , . , INFO com.keplerinfo. . :



2020-05-24 14:19:53,601+0300 pool-42-thread-8 INFO admin 859x6032x1 aizaws 0:0:0:0:0:0:0:1 /rest/keplerrominfo/refapp/latest/async-script/runScriptFromEditor [c.k.r.sil.impl.MailConfigurationAccessor] NULL MAILER (log only mail sender) : Subject: aa, From: null, To: [alex@gmail.com], CC: [alex@bk.ru], Body:
aa

Asynchronous Runner


Vous pouvez lire les informations du fournisseur ici :

Threads définit le nombre de threads pour SIL. Par défaut, le nombre de threads est de 10, ce qui signifie que seuls 10 scripts seront exécutés à la fois. Le reste restera en ligne et attendra que l'un des fils soit libre. Si vous avez un grand nombre de scripts en cours d'exécution en même temps, augmentez ce paramètre.

Time To Live (TTL) définit la durée de vie du thread. La valeur par défaut est 1 heure. Cela signifie que si le script est exécuté pendant plus d'une heure, il sera tué et les résultats du script ne seront que ceux qui ont réussi à se terminer au cours de cette heure. Si vous disposez de scripts de longue durée, augmentez ce paramètre.

Intervalle de point de contrôledétermine la fréquence à laquelle SIL vérifiera s'il existe des scripts qui s'exécutent plus longtemps que le paramètre de temps TTL. Et si de tels scripts sont trouvés, ils seront tués.

Sur cet écran, vous pouvez également voir tous les scripts en cours d'exécution.

Systèmes distants


Le menu Systèmes distants vous permet de:
  • Ajoutez des connexions à des instances Jira externes et exécutez des scripts SIL sur ces instances.
  • Définissez les autorisations pour exécuter des scripts SIL via l'API SIL REST pour les utilisateurs qui ne sont pas des administrateurs Jira.

Vous pouvez lire les informations du fournisseur ici .

Créons d'abord une connexion à distance à Jira et exécutons un script SIL dessus.
J'ai soulevé deux instances de Jira: localhost: 2990 / jira et localhost: 8080.
J'ai créé ce script sur localhost: 8080 et j'ai appelé ce script test.sil:

logPrint("ERROR", "I am called from " + argv[0]);

Ce script prend un paramètre et affiche un message avec ce paramètre dans le journal atlassian-jira.log.
Maintenant sur localhost: 2990 / jira je vais créer une connexion à distance. Je vais aller à la vitesse -> Gérer les applications -> Systèmes distants, cliquez sur le bouton Ajouter à distance et entrez les données Jira pour localhost: 8080:



Maintenant je clique sur le bouton Enregistrer bouton et sur la même instance Jira (localhost: 2990 / jira) Je vais créer un script qui appellera script avec localhost: 8080:

call("my_ext_jira", "test.sil", "localhost:2990/jira")

Le premier paramètre est la connexion distante que j'ai créée: my_ext_jira.
Le deuxième paramètre est le nom du script qui sera exécuté sur le système distant (localhost: 8080): test.sil.

Le troisième paramètre est la chaîne qui sera transmise à test.sil: localhost: 2990 / jira.

Exécutez maintenant ce script (celui sur localhost: 2990 / jira) et consultez les journaux sur le système distant (localhost: 8080). Nous verrons cette ligne:

2020-05-25 08:30:57,944+0000 pool-38-thread-2 ERROR admin 510x101x1 3sauem 172.26.0.1 /rest/keplerrominfo/refapp/latest/async-script/runScript [c.k.s.lang.routines.LogPrintRoutine] I am called from localhost:2990/jira

Cela signifie que nous avons réussi à appeler le script SIL sur le système distant localhost: 8080 avec localhost: 2990 / jira.

Examinons maintenant la section Sécurité sur l'écran que nous voyons après avoir sélectionné l'élément de menu Systèmes distants.

Supposons que nous ayons deux scripts sur localhost: 2990 / jira.
test.sil

call("my_ext_jira", "test.sil", "localhost:2990/jira")

test1.sil

runerLog("Hello World");

Et nous avons l'utilisateur user1, qui n'a pas de droits d'administrateur.

Nous voulons appeler des scripts en ligne et des scripts qui sont sur le système de fichiers par cet utilisateur.

Voici l'écran du menu Remote Systems:



nous travaillerons avec les boutons Grant execute inline, Grand read et Grant execute de la section Security.

Tout d'abord, essayez d'appeler le script en ligne en tant qu'utilisateur1. Nous appellerons le script en ligne à l'aide de cette méthode API SIL REST.

http://localhost:2990/jira/rest/keplerrominfo/refapp/1.0/async-script/runScript

Ici avec ce JSON:

{
   "source" : {
    "type": "INLINE",
    "code": "return 1;"
    }
}

Et nous obtenons une telle erreur interdite 403.

Maintenant, appuyez sur le bouton Accorder l'exécution en ligne et accordez une autorisation à user1:



Et nous obtiendrons un code de réponse 200, ce qui signifie que nous avons terminé le script en ligne avec succès.

Exécutons maintenant le script test1.sil sous user1. Cette fois, JSON ressemblera à ceci:

{
   "source": {
        "type": "FILE",
        "code": "test1.sil"
    }
}

Et encore une fois, nous obtenons cette erreur interdite 403.

Nous donnons maintenant les droits à user1 pour exécuter le script test1.sil. Cliquez sur le bouton Grant execute:



cette fois, le code de réponse est 200. Tout a fonctionné .

Configuration LDAP


Vous pouvez configurer la connexion à LDAP. Les informations du vendeur peuvent être trouvées ici .

Je démarre le serveur LDAP dans Docker à partir d'ici .

docker run -p 389:389 -p 636:636 --name my-openldap-container --env LDAP_ADMIN_PASSWORD="adminadmin" --detach osixia/openldap:1.3.0

Le serveur LDAP est en cours d'exécution.

Maintenant, cliquons sur le bouton Ajouter LDAP et configurons la connexion:



Seul Active Directory est disponible pour le champ Répertoire. Mais cela ne signifie pas que vous ne pouvez vous connecter qu'à Microsoft Active Directory. Vous pouvez vous connecter à n'importe quel serveur LDAP. Je me suis connecté pour ouvrir LDAP.

Maintenant, sélectionnons les utilisateurs de LDAP à l'aide de ldapUserList :

runnerLog(ldapUserList({"cn", "uid"}, "objectClass=*", "myldap"));

Et nous avons obtenu le résultat:



cela signifie que tout a fonctionné pour nous.

Stockage de scripts


Cet élément de menu vous permet de spécifier où vous stockerez les scripts SIL. Vous pouvez lire les informations du fournisseur ici .

Par défaut, les scripts sont stockés dans le système de fichiers (disque optionnel):



vous pouvez choisir de stocker les scripts dans la base de données (base de données optionnelle). Dans ce cas, les scripts seront stockés dans la table AO_1B54DA_TSTEXT.

À mon avis, il est préférable de stocker des scripts dans le système de fichiers. Dans ce cas, vous pouvez utiliser un système de contrôle de version, par exemple, Bitbucket.

Mappage des champs personnalisés


Dans cet élément de menu, vous pouvez spécifier le mappage des types de champs personnalisés aux types de valeurs SIL. Vous pouvez lire les informations du fournisseur ici .



Par exemple, regardez le champ Checkboxes personnalisé. La valeur de ce champ est mappée au type chaîne [], ce qui signifie que si vous souhaitez lire une valeur dans un champ de type Checkboxes, vous devez écrire ce code:

string[] value =  #{My Checkbox Field};

Et pour attribuer une valeur, voici un code comme celui-ci:

string[] value =  {"value1", "value2"};
#{My Checkbox Field} =  value;

Vous ne pouvez pas modifier le mappage de ce champ car il s'agit d'un champ standard. Et Cprime a déjà indiqué le mappage correct.

Voyons maintenant le type de grille de champ personnalisé. Nous avons obtenu ce type du plugin Table Grid Next Generation. Cprime ne fournit pas de mappage pour ce champ hors de la boîte, il lui est donc attribué un mappage par défaut. Le mappage par défaut est une chaîne. Mais vous pouvez changer le mappage par défaut en un autre:



dans certains cas, le mappage intégré n'est pas suffisant et dans ce cas, vous pouvez écrire une extension dans SIL avec votre mappage. Plus de détails sur la façon de procéder peuvent être trouvés ici .

Configuration d'intégration


Vous pouvez créer des connexions à Slack and Stride dans cet élément de menu. Le vendeur a une instruction très détaillée sur la façon de le faire ici .

Configuration des Webhooks SIL


Vous pouvez créer votre propre API REST qui appellera des scripts SIL. Vous pouvez lire ici .

Diagnostic SIL


Cet élément de menu fournit des informations de configuration SIL complètes: la



plupart de ces informations sont nécessaires pour les développeurs SIL, mais je voudrais attirer l'attention sur une caractéristique importante de cet écran.

Vous pouvez tuer les scripts SIL en cours d'exécution.

Supposons que vous ayez écrit et exécuté un script qui a créé une boucle sans fin. Sans cette option, vous devrez attendre que le script fonctionne plus longtemps que le temps dans le paramètre Time To Live (TTL) et qu'il ne soit pas tué. Mais avec cette option, vous ne pouvez pas attendre ce moment.

Cliquez simplement sur le bouton Kill:


All Articles