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.
Lorsque des règles métier s’exécutent
- Moment d’exécution de la règle métier dans le cadre d’une opération de base de données.
- Opération d’enregistrement à laquelle la règle métier s’applique.
| Option | Lorsque la règle s’exécute |
|---|---|
| Avant | Une fois que l’utilisateur a soumis le formulaire, mais avant toute action sur l’enregistrement dans la base de données. |
| Après | Une fois 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 | Une fois 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 entreprise 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 un enregistrement possède une règle métier asynchrone qui prend des décisions en fonction des données contenues dans l’enregistrement, plusieurs mises à jour successives de l’enregistrement peuvent entraîner une exécution désordonnée ou incorrecte de la règle métier. Si plusieurs règles métier asynchrones mettent à jour le même enregistrement, les mises à jour effectuées par un script peuvent être écrasées par un autre script ou effectuées dans un ordre inattendu, 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 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 générateur de conditions 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 n’honorent pas les ACL tant que vous ne souhaitez pas qu’elles soient respectées. Pour plus d’informations, voir Relation entre les règles métier et les règles de contrôle d’accès (ACL)
| Option | Lorsque 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 pour les règles métier avant. |
| Supprimer | Lorsque l’utilisateur supprime un enregistrement. |
Actions de règle métier
- Modification des valeurs de champ dans un formulaire que l’utilisateur met à 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.
- Afficher des messages d’information à l’utilisateur.
- Modification des valeurs des tâches enfants en fonction des changements apportés aux tâches parentes.
- Empêcher les utilisateurs d’accéder ou de modifier certains champs d’un formulaire.
- Abandon de la transaction de base de données actuelle. Par exemple, si certaines conditions sont remplies, empêchez l’utilisateur d’enregistrer 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 de règles métier sur la même table pour les opérations d’insertion et de mise à jour, ce qui conduit à une règle métier qui s’appelle encore et encore. Les changements apportés avant les règles métier sont automatiquement enregistrés lorsque toutes les règles métier avant sont terminées et après que les règles métier sont mieux utilisées pour mettre à jour les objets connexes et non 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() cause 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, qui est 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 provenant d’un autre périmètre de l’application.
Pour les tables dont le champ d’application est différent de celui de l’enregistrement de la règle métier, les types de règles sont limités.
- Vous pouvez créer une règle où When 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 des valeurs de champ , des actions et des scripts (le champ Script ).
- Vous pouvez créer une règle où Quand est avant 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éfinir des actions de valeurs de champ uniquement. 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 périmètre différent.
Les règles métier sur des tables spécifiques ne sont pas 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 champ d’application. Pour une règle métier globale, définissez la protection du champ d’application 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 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 Séparation de domaine.
Scripts dans les règles métier incluses dans le périmètre
Lorsque vous écrivez un script dans une règle métier, vous pouvez accéder à :
- Tout script includes et règles métier globales dans le même champ d’application que la règle métier.
- Includes de script 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 périmètre unique, vous ne pouvez accéder qu’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
Des variables globales prédéfinies peuvent être utilisées 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. Consultez « Empêcher les exceptions de pointeur Null » ci-dessous pour vérifier les valeurs Null 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 , l’état précédent continue de détenir l’état de l’enregistrement avant la première mise à jour ou opération de suppression. Disponible uniquement pour les opérations de mise à jour et de suppression. Non disponible sur les opérations asynchrones. Consultez « Empêcher les exceptions de pointeur Null » ci-dessous pour vérifier les valeurs Null avant d’utiliser cette variable. |
| g_scratchpad | L’objet bloc-notes est disponible sur 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 GlideSystem . |
Les variables actuelles, précédentes et g_scratchpad sont globales dans 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 incluses dans le périmètre global 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, intégrez toujours votre code dans une fonction. Vos variables sont ainsi protégées contre les conflits avec les variables système ou les variables globales d’autres règles métier qui ne sont pas encapsulées dans une fonction. De plus, des 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 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 d’afficher les changements immédiats apportés aux valeurs dans les formulaires dès que des modifications sont apportées.
Le problème avec l’utilisation d’un script client ou d’une règle métier pour contrôler les mises à jour d’un champ est que les champs peuvent être modifiés dans 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 de liste. Autoriser la modification de liste avec des scripts clients s’exécutant sur les champs d’un formulaire peut entraîner l’enregistrement de données incorrectes. Pour les systèmes dans lesquels des scripts clients ou des politiques d’interface utilisateur s’appliquent aux formulaires, désactivez la modification de liste ou créez des règles métier appropriées ou un contrôle d’accès pour contrôler la définition des valeurs dans l’éditeur de liste. Un effet secondaire de cela est que les mesures de sécurité implémentées dans les scripts clients sont faciles à contourner. L’utilisateur doit uniquement modifier le champ dans une liste.
Les règles métier sur un formulaire ne sont pas dynamiques, l’utilisateur doit mettre à jour l’enregistrement pour que le changement soit visible. L’utilisation de scripts clients devient ainsi 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 la modification. 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 d’un enregistrement utilisateur
Une organisation a un script client qui définit l’adresse e-mail d’un utilisateur à first.last@company.com. Les administrateurs le font afin de pouvoir voir 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’adresse e-mail de chaque utilisateur est définie automatiquement, comme c’est le cas lorsqu’il modifie le formulaire. Étant donné que le script client ne s’exécute que sur le formulaire (l’interface de l’enregistrement), il n’a aucun effet sur les données importées dans l’enregistrement depuis l’extérieur 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 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. Ils créent une politique d’interface utilisateur sur le formulaire d’incident pour ce faire, mais leurs utilisateurs peuvent toujours voir et modifier le champ Priorité à l’aide de l’éditeur de liste. Pour corriger 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 sur 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. Utilisez NULL uniquement 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 de jeu d’importation ou ailleurs dans les champs Prénom ou Nom de famille . De plus, n’utilisez pas 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é dans la base de données. Toute modification de champ est temporaire puisqu’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 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écessiterait 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 de la forme est un objet vide par défaut et n’est utilisé que pour stocker des paires nom-valeur de données.
// 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 will 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 changements apportés au champ État .
La règle métier Gestion des états actifs de la tâche est exécutée lorsque l’état est modifié pour un enregistrement de tâche. 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 faux.
- Si l’état passe d’un état inactif à un état actif, le champ Actif est défini sur true, ce qui réactive ou rouvre efficacement la tâche.
Il est recommandé d’exploiter l’action (current.active.changesTo([true/false]) dans votre règle métier au lieu de créer sur chaque table de tâches des règles qui marquent les tâches comme inactives ou actives.
Exemples de scripts de règles métier
Recherchez un exemple de script de règle métier qui vous aide à répondre à un besoin 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 si elles ne sont pas correctes.
Par exemple, vous pouvez souhaiter qu’une date de début soit antérieure à 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 des scripts inclus dans le champ d’application. En plus d’avoir éventuellement besoin de 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 champs.
- La première ligne vérifie que les deux champs ont réellement 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 : un en haut du formulaire et un près du champ u_date1 du formulaire.
- La dernière ligne abandonne 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 avec la fonction getXMLText du système.
ecc_event , peuvent être analysés avec la fonction getXMLText du système. La fonction getXMLText prend une chaîne 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 avant règle métier, 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 before est exécutée lors d’une action d’insertion et que le script comporte une condition qui appelle current.setAbortAction(true), le nouvel enregistrement stocké dans current 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 sur l’objet actuel de se produire.
Vous pouvez utiliser la méthode isActionAborted() pour déterminer si l’action de base de données actuelle (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 sur false.
current.setAbortAction n’est pas respecté si elle est exécutée dans une règle métier définie dans un autre champ d’application.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 d’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. Généralement, un champ glide_list contient une liste de valeurs de référence à 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 dans 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 non défini. Pour éviter de renvoyer une valeur indéfinie, effectuez l’une des opérations suivantes :
- Forcer le champ à former une chaîne, par exemple : watch_list.toString().indexOf(« searchString »)
- Vérifiez s’il y a 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 d’utilisateurs
Vous pouvez verrouiller les comptes d’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); }