Règles métier classiques
Une règle métier est un script de serveur qui s'exécute lorsqu'un enregistrement est affiché, inséré, mis à jour ou supprimé, ou lorsqu'une table est interrogée.
Fonctionnement des règles métier
Pour configurer des règles métier, vous devez d’abord déterminer quand la règle métier doit s’exécuter et quelle action elle doit entreprendre.
Quand les règles métier s’exécutent
- Moment d’exécution de la règle métier par rapport à une opération de base de données.
- Opération d’enregistrement à laquelle la règle métier s’applique.
| Option | Quand la règle s’exécute |
|---|---|
| Avant | Après que l’utilisateur a soumis le formulaire, mais avant qu’une action ne soit effectuée sur l’enregistrement dans la base de données. |
| Après | Après que l’utilisateur a soumis le formulaire et après qu’une action a été effectuée sur l’enregistrement dans la base de données. |
| Async | Après que l’utilisateur a soumis le formulaire et que le planificateur a exécuté la tâche planifiée créée à partir de la règle métier. Le système crée une tâche planifiée à partir de la règle métier après que l’utilisateur a soumis le formulaire, mais avant qu’une action ne soit effectuée sur l’enregistrement dans la base de données. Remarque : Les règles métier nouvellement créées s’exécuteront lors des mises à niveau. Si plusieurs règles métier asynchrones mettent à jour le même enregistrement, les mises à jour effectuées par un script peuvent être remplacées par un autre script ou effectuées dans une séquence inattendue, car l’ordre d’exécution n’est pas garanti. Vous pouvez utiliser l’option Après pour les règles métier ou System Events comme alternative dans ces situations. |
| Affichage | Avant que le formulaire ne soit présenté à l’utilisateur, juste après la lecture des données à partir de la base de données. |
- Les règles métier asynchrones n’ont pas accès à la version précédente d’un enregistrement. Par conséquent, les méthodes GlideElementchanges(), changesTo() et changesFrom() ne fonctionnent pas avec le script de règle asynchrone. Toutefois, le créateur de condition et le champ de condition (vue avancée) prennent tous deux en charge les méthodes changes(),changesTo() et changesFrom().
- Les règles métier ne respectent pas les ACL tant que vous ne souhaitez pas qu’elles soient respectées. Pour plus d’informations, consultez Relation entre les règles métier et les règles de contrôle d’accès (ACL)
| Option | Quand la règle s’exécute |
|---|---|
| Insérer | Lorsque l’utilisateur crée un nouvel enregistrement et que le système l’insère dans la base de données. |
| Mettre à jour | Lorsque l’utilisateur modifie un enregistrement existant. |
| Requête | Lorsque l’utilisateur envoie une requête pour un enregistrement ou une liste d’enregistrements à la base de données. En règle générale, vous devez utiliser l’opération de requête avant les règles métier. |
| Supprimer | Lorsque l’utilisateur supprime un enregistrement. |
Actions de règle métier
- Modification des valeurs de champ sur un formulaire que l’utilisateur est en train de mettre à jour. Les valeurs de champ peuvent être définies sur des valeurs spécifiques disponibles pour ce champ, des valeurs copiées à partir d’autres champs et des valeurs relatives déterminées par le rôle de l’utilisateur.
- Affichage de messages d’information à l’utilisateur.
- Modification des valeurs des tâches enfants en fonction des modifications apportées aux tâches parentes.
- Empêcher les utilisateurs d’accéder à certains champs d’un formulaire ou de les modifier.
- Abandon de la transaction de base de données actuelle. Par exemple, si certaines conditions sont remplies, empêchez l’utilisateur de sauvegarder l’enregistrement dans la base de données.
Empêcher les règles métier récursives
Évitez d’utiliser current.update() dans un script de règle métier. La méthode update() déclenche l’exécution des règles métier sur la même table pour les opérations d’insertion et de mise à jour, ce qui conduit à ce qu’une règle métier s’appelle elle-même de manière répétée. Les modifications apportées avant les règles métier sont automatiquement enregistrées lorsque toutes les règles métier antérieures sont terminées et après que les règles métier sont particulièrement utilisées pour mettre à jour les objets associés, et non les objets actuels. Lorsqu’une règle métier récursive est détectée, le système l’arrête et consigne l’erreur dans le journal système. Cependant, current.update() provoque des problèmes de performances système et n’est jamais nécessaire.
Vous pouvez empêcher les règles métier récursives en utilisant la méthode setWorkflow() avec le paramètre false. La combinaison des méthodes update() et setWorkflow() n’est recommandée que dans des circonstances particulières où les directives normales avant et après mentionnées ci-dessus ne répondent pas à vos besoins.
Règles métier dans les applications incluses dans le périmètre
Chaque règle métier est affectée soit à un périmètre d’application privé, soit au périmètre global.
Règles métier sur des tables spécifiques
La plupart des règles métier s’exécutent sur une table spécifique, définie dans le champ Table . Vous pouvez créer des règles métier sur des tables du même périmètre et sur des tables qui autorisent les enregistrements de configuration à partir d’un autre périmètre de l’application.
Pour les tables qui se trouvent dans un champ d’application différent de l’enregistrement de règle métier, les types de règles sont limités.
- Vous pouvez créer une règle où Quand est asynchrone avec l’une des options suivantes :
- Opérations d’insertion, de mise à jour et de suppression de base de données. Vous ne pouvez pas sélectionner Requête.
- Définissez les valeurs de champ, les actions et les scripts (champ Script ).
- Vous pouvez créer une règle où Quand est avant à l’aide de l’une des options suivantes :
- Opérations d’insertion, de mise à jour et de suppression de base de données. Vous ne pouvez pas sélectionner Requête.
- Définissez uniquement les actions de valeurs de champ . Vous ne pouvez pas écrire de scripts et vous ne pouvez pas abandonner la transaction de base de données.
- Vous ne pouvez pas créer d’autres types de règles métier sur des tables d’un champ d’application différent.
Les règles métier présentes sur des tables spécifiques ne peuvent pas être accessibles par d’autres règles métier ou scripts.
Règles métier globales
Les règles métier globales sont des règles métier dans lesquelles le champ Table est défini sur Global. Les règles métier globales peuvent être accessibles sur plusieurs tables et à partir d’autres scripts, en fonction de leur protection de champ d’application. Pour une règle métier globale, définissez la protection du périmètre en définissant le champ Accessible depuis :
- Ce périmètre de l’application uniquement : empêche les applications d’un périmètre différent de celui de la règle métier d’appeler cette règle métier.
- Tous les périmètres de l’application : permet à n’importe quelle application d’appeler cette règle métier.Remarque :Les règles métier globales ne prennent pas en charge Domain Separation.
Scripts dans les règles métier incluses dans le champ d’application
Lorsque vous écrivez un script dans une règle métier, vous pouvez accéder aux éléments suivants :
- Tout script includes et règles métier globales dans le même périmètre que la règle métier.
- Script includes et règles métier globales qui permettent aux applications d’un périmètre différent de les appeler. Pour appeler des fonctions à partir d’un autre périmètre, vous devez spécifier le périmètre de la fonction.
- Pour les règles métier dans un champ d’application unique, vous pouvez accéder uniquement aux API système incluses dans le périmètre.
Créer une règle métier
Vous pouvez créer n’importe quel type de règle métier à exécuter lorsqu’un enregistrement est affiché, inséré, mis à jour ou supprimé, ou lorsqu’une table est interrogée.
Pourquoi et quand exécuter cette tâche
Procédure
Variables globales dans les règles métier
Les variables globales prédéfinies sont disponibles pour une utilisation dans les règles métier.
Utilisez les variables globales prédéfinies suivantes pour référencer le système dans un script de règle métier.
| Variable globale | Description |
|---|---|
| current | État actuel de l’enregistrement en cours de référencement. Reportez-vous à la section « Empêcher les exceptions de pointeur null » ci-dessous pour vérifier les valeurs nulles avant d’utiliser cette variable. |
| previous | État de l’enregistrement référencé avant toute mise à jour effectuée pendant le contexte d’exécution, où le contexte d’exécution commence par la première opération de mise à jour ou de suppression et se termine après l’exécution du script et de toutes les règles métier référencées. Si plusieurs mises à jour sont apportées à l’enregistrement dans un contexte d’exécution, le précédent conservera l’état de l’enregistrement avant la première opération de mise à jour ou de suppression. Disponible uniquement pour les opérations de mise à jour et de suppression. Cette option n’est pas disponible pour les opérations asynchrones. Reportez-vous à la section « Empêcher les exceptions de pointeur null » ci-dessous pour vérifier les valeurs nulles avant d’utiliser cette variable. |
| g_scratchpad | L’objet bloc-notes est disponible dans les règles d’affichage et est utilisé pour transmettre des informations au client afin qu’elles soient accessibles à partir des scripts clients. |
| Gs | Références aux fonctions de GlideSystem . |
Les variables actuelle, précédente et g_scratchpad sont globales sur toutes les règles métier qui s’exécutent pour une transaction.
Empêcher les exceptions de pointeur null
if (current == null) // to prevent null pointer exceptions.
return; Définir des variables
Les variables définies par l’utilisateur sont globalement incluses par défaut. Si une nouvelle variable est déclarée dans une règle métier d’ordre 100, la règle métier qui s’exécute ensuite à l’ordre 200 a également accès à la variable. Cela peut introduire un comportement inattendu.
Pour éviter un tel comportement inattendu, enveloppez toujours votre code dans une fonction. Cela protège vos variables contre les conflits avec les variables système ou les variables globales dans d’autres règles métier qui ne sont pas encapsulées dans une fonction. De plus, les variables telles que current doivent être disponibles lorsqu’une fonction est invoquée pour être utilisées.
var now_GR = new GlideRecord('incident');
now_GR.query();
while(now_GR.next()) {
//do something
}myFunction();
function myFunction() {
var now_GR = new GlideRecord('incident');
now_GR.query();
while(now_GR.next()) {
//do something
} }Utiliser des règles métier et des scripts clients pour contrôler les valeurs de champ
Implémentez à la fois des règles métier et des scripts clients pour un champ afin de permettre aux utilisateurs de définir correctement les valeurs d’enregistrement à l’aide des formulaires et des listes, et de visualiser les changements immédiats apportés aux valeurs des formulaires à mesure que des modifications sont apportées.
Le problème lié à l’utilisation d’un script client ou d’une règle métier uniquement pour contrôler les mises à jour d’un champ est que les champs peuvent être modifiés sur un formulaire ou une liste. Les scripts clients et les politiques d’interface utilisateur s’exécutent uniquement sur les formulaires (côté client) et ne s’appliquent pas à la modification des listes. Autoriser la modification de liste avec des scripts clients exécutés sur les champs d’un formulaire peut entraîner l’enregistrement de données incorrectes dans l’enregistrement. Pour les systèmes dans lesquels des scripts clients ou des politiques d’interface utilisateur s’appliquent aux formulaires, désactivez la modification des listes ou créez des règles métier ou un contrôle d’accès appropriés pour contrôler la définition des valeurs dans l’éditeur de liste. Un effet secondaire de ce phénomène est que les mesures de sécurité mises en œuvre dans les scripts clients sont faciles à contourner. L’utilisateur n’a qu’à modifier le champ dans une liste.
Les règles métier d’un formulaire ne sont pas dynamiques, l’utilisateur doit mettre à jour l’enregistrement pour afficher le changement. L’utilisation de scripts clients est donc la méthode privilégiée pour contrôler les valeurs de champ sur les formulaires.
Lors de l’utilisation d’une règle métier et d’un script client pour contrôler les valeurs de champ, le comportement de mise à jour est le même dans tout le système. Cela signifie que les valeurs mises à jour ne sont pas différentes selon qu’une liste de formulaires est utilisée ou non pour effectuer le changement. Cela signifie que la même fonctionnalité doit être implémentée deux fois, une fois dans un script client et une fois dans une règle métier ou un contrôle d’accès.
Exemple : utiliser une règle métier pour créer des adresses e-mail pendant l’importation de l’enregistrement utilisateur
Une organisation dispose d’un script client qui définit l’adresse e-mail qu’un utilisateur doit first.last@company.com. Les administrateurs peuvent ainsi consulter l’adresse e-mail immédiatement lorsqu’ils saisissent les informations de l’utilisateur. L’administrateur effectue ensuite une importation en bloc d’utilisateurs à partir d’une feuille de calcul contenant les noms et prénoms des utilisateurs. L’objectif est que l’adresse e-mail de chaque utilisateur soit définie automatiquement, comme c’est le cas lorsqu’il modifie le formulaire. Étant donné que le script client s’exécute uniquement sur le formulaire (l’interface vers l’enregistrement), il n’a aucun effet sur les données importées dans l’enregistrement en dehors de cette interface, et aucune adresse e-mail n’est créée. Pour résoudre ce problème, l’administrateur implémente une règle métier qui s’exécute lorsque l’importation a lieu et crée les adresses e-mail.
Exemple : empêcher la modification de la liste pour un champ qui n’est pas modifiable dans le formulaire
Une organisation souhaite masquer le champ Priorité sur un formulaire d’incident si le groupe d’affectation est Développement. Pour ce faire, ils créent une politique d’interface utilisateur sur le formulaire d’incident, mais leurs utilisateurs peuvent toujours voir et modifier le champ Priorité à l’aide de l’éditeur de liste. Pour remédier à cela, appliquez un contrôle d’accès pour empêcher l’accès en lecture au champ Priorité lorsque le groupe d’affectation est Développement.
Utilisation de NULL comme valeur de champ
La chaîne NULL a un rôle particulier dans les scripts et est un mot réservé.
Le mot réservé est NULL en majuscules. Un champ avec la valeur Null ou null, par exemple, est acceptable. N’utilisez NULL que pour effacer un champ particulier.
Toutes les valeurs de champ NULL obtenues à partir d’une source de données de jeu d’importation sont insérées dans la table intermédiaire en tant que valeurs de champ vides. Vous ne devez pas utiliser le terme NULL comme valeur de champ dans les cartes de transformation des jeux d’importation ou n’importe où dans les champs Prénom ou Nom . N’utilisez pas non plus NULL dans les champs de référence, car le système interprète la valeur comme une chaîne contenant le mot NULL, et non comme un mot réservé.
Afficher les règles métier
Les règles d’affichage sont traitées lorsqu’un utilisateur demande un formulaire d’enregistrement.
Les données sont lues à partir de la base de données, les règles d’affichage sont exécutées et le formulaire est présenté à l’utilisateur. L’objet actuel est disponible et représente l’enregistrement récupéré à partir de la base de données. Toute modification de champ est temporaire, car elle n’est pas encore soumise à la base de données. Pour le client, les valeurs du formulaire semblent être les valeurs de la base de données ; Rien n’indique que les valeurs ont été modifiées à partir d’une règle d’affichage. Il s’agit d’un concept similaire aux champs calculés.
L’objectif principal des règles d’affichage est d’utiliser un objet de bloc-notes partagé, g_scratchpad, qui est également envoyé au client dans le cadre du formulaire. Cela peut être utile lorsque vous devez créer des scripts clients qui nécessitent des données serveur qui ne font généralement pas partie de l’enregistrement affiché. Dans la plupart des cas, cela nécessite qu’un script client rappelle le serveur. Si les données peuvent être déterminées avant l’affichage du formulaire, il est plus efficace de fournir les données au client lors du chargement initial. L’objet bloc-notes du formulaire est un objet vide par défaut et est utilisé uniquement pour stocker des paires de données nom-valeur.
// From display business rule
g_scratchpad.someName = "someValue";
g_scratchpad.anotherName = "anotherValue";
// If you want the client to have access to record fields not being displayed on the form
g_scratchpad.created_by = current.sys_created_by;
// These are simple examples, in most cases you'll probably perform some other
// queries to test or get data// From client script
if(g_scratchpad.someName == "someValue") {
//do something special
}Règle métier Gestion des états actifs de la tâche
Cette règle métier détermine si la valeur du champ actif doit changer en fonction des modifications apportées au champ État .
La règle métier Gestion active des états des tâches est exécutée lorsque l’état d’un enregistrement de tâche est modifié. Son ordre d’exécution est 50 et il s’exécute avant la plupart des autres règles métier de tâche.
- Si l’état passe d’un état actif à un état inactif, le champ Actif est défini sur false.
- Si l’état passe d’un état inactif à un état actif, le champ Actif est défini sur vrai, ce qui réactive ou rouvre la tâche.
Il est recommandé d’exploiter l’action (current.active.changesTo([true/false]) dans votre règle métier, plutôt que de créer des règles sur chaque table de tâches qui marquent les tâches comme inactives ou actives.
Exemples de scripts de règles métier
Trouvez un exemple de script de règle métier qui vous aide à répondre à une exigence de votre organisation.
Comparer les champs de date dans une règle métier
Il est possible de comparer deux champs de date ou deux champs de date et d’heure dans une règle métier, et d’abandonner une insertion ou une mise à jour d’enregistrement s’ils ne sont pas corrects.
Par exemple, vous pouvez souhaiter qu’une date de début précède une date de fin. Voici un exemple de script :
if ((!current.u_date1.nil()) && (!current.u_date2.nil())) {
var start = current.u_date1.getGlideObject().getNumericValue();
var end = current.u_date2.getGlideObject().getNumericValue();
if (start > end) {
gs.addInfoMessage('start must be before end');
current.u_date1.setError('start must be before end') ;
current.setAbortAction(true);
} }Cet exemple a été testé dans des scripts globaux et peut nécessiter des modifications pour fonctionner dans les scripts inclus dans le périmètre. Outre le fait qu’elle peut nécessiter des modifications de l’API, la sécurité est plus stricte dans les scripts inclus dans le périmètre.
- u_date1 et u_date2 sont les noms des deux champs de date. Remplacez ces noms par vos propres noms de champ.
- La première ligne vérifie que les deux champs ont bien une valeur.
- Les deux lignes suivantes créent des variables qui ont les valeurs numériques des dates.
- Les deux lignes suivantes créent des messages d’alerte différents pour l’utilisateur final : l’un en haut du formulaire et l’autre par le champ u_date1 du formulaire.
- La dernière ligne annule l’insertion ou la mise à jour si les champs de date ne sont pas corrects.
// Enter all start and end date fields you wish to check, as well as the previous values
// Make sure that you keep the placement in the sequence the same for all pairs
var startDate = new Array(current.start_date,current.work_start);
var prevStartDate = new Array(previous.start_date,previous.work_start);
var endDate = new Array(current.end_date,current.work_end);
var prevEndDate = new Array(previous.end_date,previous.work_end);
// The text string below is added to the front of ' start must be before end'
var userAlert = new Array('Planned','Work');
// Set the number of Previous Days you want to check
var pd = 30;
// Set the number of Future Days you want to check
var fd = 365;
// You shouldn't have to modify anything below this line
var nowdt = new GlideDateTime();
nowdt.setDisplayValue(gs.nowDateTime());
var nowMs = nowdt.getNumericValue();
var pdms = nowMs;
// Subtract the product of previous days to get value in milliseconds
pdms -= pd * 24 * 60 * 60 * 1000;
var fdms = nowMs;
// Add the product of future days to get value in miliseconds
fdms += fd * 24 * 60 * 60 * 1000;
var badDate = false;
// Iterate through all start and end date / time fields
for (x = 0; x < startDate.length; x ++) {
if ((!startDate[x].nil()) && (!endDate[x].nil())) {
var start = startDate[x].getGlideObject().getNumericValue();
var end = endDate[x].getGlideObject().getNumericValue();
if (start > end) {
gs.addInfoMessage(userAlert[x] + ' start must be before end');
startDate[x].setError(userAlert[x] + ' start must be before end');
badDate = true; }
else if ((prevStartDate[x]) != (startDate[x])) {
if (start < pdms) {
gs.addInfoMessage(userAlert[x] + ' start must be fewer than ' + pd + ' days ago');
startDate[x].setError(userAlert[x] + ' start must be fewer than ' + pd + ' days ago');
badDate = true; } }
else if ((prevEndDate[x]) != (endDate[x])) {
if (end > fdms) {
gs.addInfoMessage(userAlert[x] + ' end must be fewer than ' + fd + ' days ahead');
endDate[x].setError(userAlert[x] + ' end must be fewer than ' + fd + ' days ahead');
badDate = true ;
} } } }
if (badDate == true ) {
current. setAbortAction ( true ) ; }Analyser les charges utiles XML
Les champs au format XML peuvent être analysés à l’aide de la fonction getXMLText du système.
ecc_event , peuvent être analysés à l’aide de la fonction getXMLText du système. La fonction getXMLText prend une chaîne de caractères et une expression XPATH. Par exemple :var name = gs.getXMLText("<name>joe</name>", "//name");Renvoie la chaîne 'Joe'.
var name = gs.getXMLText(current.payload, "//name");Pour plus d’informations sur XPATH, visitez w3schools.
Abandonner une action de base de données dans une règle métier Avant
Dans un script de règle métier antérieure, vous pouvez annuler ou abandonner l’action de base de données actuelle à l’aide de la méthode setAbortAction().
Par exemple, si la règle métier Avant est exécutée pendant une action d’insertion et que le script contient une condition qui appelle current.setAbortAction(true), le nouvel enregistrement stocké dans la règle métier actuelle n’est pas créé dans la base de données. La règle métier continue de s’exécuter après l’appel de setAbortAction() et toutes les règles métier suivantes s’exécuteront normalement. L’appel de cette méthode empêche uniquement l’action de base de données de se produire.
Vous pouvez utiliser la méthode isActionAborted() pour déterminer si l’action de base de données en cours (insérer, mettre à jour, supprimer) va être abandonnée. isActionAborted() est initialisé pour les nouveaux threads et la méthode next() définit explicitement sa valeur à false.
current.setAbortAction n’est pas respecté s’il est exécuté dans une règle métier définie dans un champ d’application différent.Déterminer l’opération qui a déclenché la règle métier
Vous pouvez écrire un script pour une règle métier qui est déclenchée sur plusieurs actions de base de données.
if(current.operation() == "update") {
current.updates ++; }
if(current.operation() == "insert") {
current.updates = 0; }Utiliser une condition OU dans une règle métier
Une condition OU peut être ajoutée à n’importe quelle partie de requête dans une règle métier.
var inc = new GlideRecord('incident');
var qc = inc.addQuery('priority','1');
qc.addOrCondition('priority','2');
inc.query();
while(inc.next()) {
// processing for the incident goes here
}(priorité = 1 OU priorité = 2) ET (impact = 2 OU impact = 3). Les résultats de la condition OR sont exécutés avec deux variables, qc1 et qc2. Cela vous permet de manipuler l’objet de condition de requête plus tard dans le script, par exemple à l’intérieur d’une condition IF ou d’une boucle WHILE .var inc = new GlideRecord('incident');
var qc1 = inc.addQuery('priority','1');
qc1.addOrCondition('priority','2');
var qc2 = inc.addQuery('impact','2');
qc2.addOrCondition('impact','3');
inc.query();
while(inc.next()) {
// processing for the incident goes here
}Référencer une liste Glide à partir d’une règle métier
Un champ défini comme une liste Glide est un tableau de valeurs stockées dans un seul champ.
Voici quelques exemples de traitement d’un champ glide_list lors de l’écriture de règles métier. En général, un champ glide_list contient une liste de valeurs de référence pour d’autres tables.
Exemples
Par exemple, le champ Liste de surveillance dans les tâches est une glide_list contenant des références à des enregistrements utilisateur.
Le code ci-dessous montre comment référencer le champ.
// list will contain a series of reference (sys_id) values separated by a comma
// array will be a javascript array of reference values
var list = current.watch_list.toString();
var array = list.split(",");
for (var i=0; i < array.length; i++) {
gs.print("Reference value is: " + array[i]);
}*** Script: Reference value is: 62826bf03710200044e0bfc8bcbe5df1
*** Script: Reference value is: c2826bf03710200044e0bfc8bcbe5d45
*** Script: Reference value is: 5f74e421c0a8010e01ec0d74a7ee2cc6
*** Script: Reference value is: 06826bf03710200044e0bfc8bcbe5d57Vous pouvez également obtenir les valeurs d’affichage associées aux valeurs de référence à l’aide de la méthode getDisplayValue() comme indiqué ci-dessous.
// list will contain a series of display values separated by a comma
// array will be a javascript array of display values
var list = current.watch_list.getDisplayValue();
var array = list.split(",");
for (var i=0; i < array.length; i++) {
gs.print("Display value is: " + array[i]);
}*** Script: Display value is: Abel Tuter
*** Script: Display value is: Ashley Leonesio
*** Script: Display value is: Charles Beckley
*** Script: Display value is: Cherie FuhriUtilisez indexOf(« searchString ») pour trouver une chaîne dans une liste Glide
Utilisez indexOf(« searchString ») pour renvoyer l’emplacement de la chaîne transmise à la méthode si le champ de liste Glide, tel qu’une liste de surveillance, contient au moins une valeur.
Si le champ est vide, il renvoie undefined. Pour éviter de renvoyer une valeur non définie, effectuez l’une des actions suivantes :
- Forcez le champ à utiliser une chaîne de caractères, par exemple : watch_list.toString().indexOf(« searchString »)
- Vérifiez s’il existe un champ de liste Glide vide avec une condition avant d’utiliser indexOf(), par exemple : if (watch_list.nil() || watch_list.indexOf(« searchString ») == -1)
Verrouiller les comptes utilisateurs
Vous pouvez verrouiller les comptes utilisateur si l’utilisateur n’est pas actif.
// Lock accounts if bcNetIDStatus != active in LDAP and user does not
// have self-service, itil or admin role
var rls = current.accumulated_roles.toString();
if(current.u_bcnetidstatus == 'active' && (rls.indexOf(',itil,') > 0 ||
rls.indexOf(',admin,') > 0 ||
rls.indexOf(',ess,') > 0 )) {
current.locked_out = false; }
else {
current.locked_out = true; }
var now_GR = new GlideRecord("sys_user");
now_GR.query();
while(now_GR.next()) {
now_GR.update();
gs.info("updating " + gr.getDisplayValue());
}Règle métier avant requête par défaut
Vous pouvez utiliser une règle métier de requête qui s’exécute avant qu’une requête de base de données ne soit effectuée.
- Nom : requête d’incident
- Table : Incident
- Quand : avant, requête
- Script:
if(!gs.hasRole("itil") && gs.isInteractive()) {
var u = gs.getUserID();
var qc = current.addQuery("caller_id",u).addOrCondition("opened_by",u).addOrCondition("watch_list","CONTAINS",u);
gs.print("query restricted to user: " + u); }