Pages de l'interface utilisateur
Les pages de l’interface utilisateur peuvent être utilisées pour créer et afficher des formulaires, des boîtes de dialogue, des listes et d’autres composants de l’interface utilisateur.
Utilisez les pages de l’interface utilisateur comme widgets sur les tableaux de bord. Pour trouver les pages de l’interface utilisateur, accédez à .
Cette fonctionnalité nécessite une connaissance de HTML ou de Jelly. Vous pouvez également créer des applications AngularJS simples à l’aide des pages de l’interface utilisateur.
| Champ | Description |
|---|---|
| Nom | Nom utilisé pour appeler la page via une URL (ne doit pas contenir d’espaces). |
| Application | Affiche le périmètre de l’application actuel. |
| Description | La description de la page d’interface utilisateur et son utilisation. |
| Direct | Cochez cette case pour une page directe de l’interface utilisateur [sys_ui_page]. Une page d’interface utilisateur directe n’inclut pas le HTML, le CSS et les scripts courants. Ce paramètre nécessite l’ajout d’un CSS et d’un JavaScript personnalisés à utiliser dans la page. |
| HTML | Composant principal de la page dans lequel vous définissez ce qui est rendu lorsque la page est affichée. Il peut contenir du XHTML statique, du contenu généré dynamiquement défini comme Jelly, ou des script includes d’appel et des macros d’interface utilisateur. Remarque : Si GlideRecord/GlideDBQuery est utilisé au lieu de GlideRecordSecure, un message de recommandation de sécurité s’affiche. |
| Script client | Incluez le JavaScript côté client qui s’exécute dans le navigateur, comme les fonctions appelées par des boutons. Il est destiné à gérer tous les traitements côté client nécessaires, comme la mise au point d’un champ ou d’autres fonctionnalités DHTML interactives après le chargement d’une page. Les scripts clients de la page d’interface utilisateur sont déployés sur le navigateur au sein d’une <script/> balise, de sorte que le contenu peut être défini de la même manière dans le champ HTML. Le champ Script client peut être utilisé à la place pour définir ces scripts de manière concise afin de maintenir la facilité de gestion Jelly et HTML. |
| Script de traitement | Script qui s’exécute sur le serveur lorsque la page est soumise. Ceci est utile si votre page a un formulaire défini avec les balises <g :ui_form/> ou <g :form/>. Remarque : Si GlideRecord/GlideDBQuery est utilisé au lieu de GlideRecordSecure, un message de recommandation de sécurité s’affiche. |
| processeurs personnalisés obsolètes | Remarque : Cette fonctionnalité est obsolète. Bien que les processeurs personnalisés existants continuent d’être pris en charge, la création de nouveaux processeurs personnalisés a été déconseillée. Au lieu de cela, utilisez le Scripted REST APIsfichier . |
| Listes connexes dans la vue de formulaire : | |
| Contrôles des accès | Affichez et configurez les contrôles d’accès pour la page d’interface utilisateur. Consultez Use access controls on UI pages pour plus d'informations. |
| Versions | Affiche toutes les versions de la page d’interface utilisateur. Utilisez cette liste pour comparer des versions ou revenir à une version précédente. |
Contrôle d'accès
Une page d’interface utilisateur peut être sécurisée en créant une ACL avec les paramètres suivants :
- Type : ui_page
- Opération : lecture
- Nom : nom de la page de l’interface utilisateur à protéger
- Rôle : rôle de l’utilisateur autorisé à accéder à l’enregistrement
Pages de l’interface utilisateur présentant un risque élevé
- Utilise GlideRecord ou GlideDBQuery au lieu de GlideRecordSecure.Remarque :Cela s’applique aux champs HTML et Script de traitement et non aux scripts clients .
- n’a pas d’ACL correspondante configurée.
- Indique qu’il s’agit d’une page d’interface utilisateur publique et est saisie dans l’enregistrement sys_public .
- Affiche un message pour indiquer la page de l’interface utilisateur à risque élevé.
- Pour les instances où glide.installation.developer est défini sur vrai.
- Si la ressource est un contenu personnalisé pour une instance client.
Accès à la page de l’interface utilisateur
Chaque page de l’interface utilisateur a une URL calculée à partir du périmètre de l’application, du nom de la page et de l’extension de fichier .do .
Par exemple, pour afficher la page appelée glidewindow_example sur le système de démonstration, vous devez accéder à https://<nom de l’instance>.service-now.com/glidewindow_example.do. Si la page faisait partie d’une application personnalisée appelée example_app, vous accéderez plutôt à https://<nom de l’instance>.service-now.com/x_example_app_glidewindow_example.do.
<j2:if test="$[!empty(sysparm_verbose)]"> <span>show extra stuff </span> </j2:if >Un exemple pratique courant de ceci pourrait être la récupération d’un enregistrement de base de données pour l’affichage. Pour créer une liste des rôles d’un utilisateur, transmettez un paramètre avec l’sys_id de l’utilisateur. Appelez la page d’interface utilisateur suivante pour afficher une liste de rôles pour cet utilisateur avec le code Jelly :
role_select.do ?sysparm_user=5137153cc611227c000bbd1bd8cd2007 <j:set var = "jvar_user_id" value = "${sysparm_user}" />
<g:evaluate> var userRoles = new GlideRecord('sys_user_has_role');
userRoles.addQuery('user','${jvar_user_id}');
userRoles.query();
</g:evaluate>
<select id='select_role'>
<j:while test = "${userRoles.next()}">
<option value = "${userRoles.sys_id}"> ${userRoles.role.name} </option>
</j:while>
</select>Une exception à prendre en compte, cependant, est le nom de variable réservé sys_id. Cette variable contient toujours l’ID de la page de l’interface utilisateur elle-même, indépendamment de ce qui est spécifié dans l’URL. Un nom de variable de substitution courant est sysparm_id.
N’utilisez pas de paramètres d’URL pour charger des scripts clients dans les pages de l’interface utilisateur. Le système n’évalue plus les scripts transmis par paramètre URL. Si votre implémentation dépend de ce comportement, vous pouvez ajouter la propriété système [glide.security.disable_ui_pages_sysparm_client_script] et la définir sur false pour permettre temporairement l’évaluation des paramètres d’URL transmettant des scripts dans les pages de l’interface utilisateur.
Utiliser les contrôles d’accès sur les pages de l’interface utilisateur
Consultez les contrôles d’accès directement à partir du formulaire de page d’interface utilisateur et ajoutez un contrôle d’accès basé sur les rôles lors de la création ou de la modification d’un enregistrement de page d’interface utilisateur.
Avant de commencer
Les contrôles d’accès qui ont été ajoutés à une page d’interface utilisateur existante peuvent être consultés et modifiés en ouvrant l’enregistrement de la page d’interface utilisateur sous les liens connexes.
Rôle requis : security_admin et admin
Procédure
-
Sélectionnez Soumettre ou Envoyer.
Une fenêtre modale s’affiche et vous invite à créer un contrôle d’accès basé sur les rôles pour la page de l’interface utilisateur.
Sécuriser les pages d’interface utilisateur
Les contrôles d’accès et les messages de sécurité associés sont intégrés sur les pages d’interface utilisateur à risque élevé pour une sécurité accrue.
Un message d’information s’affiche sur les pages d’interface utilisateur à risque élevé pour informer le client d’ajouter un contrôle d’accès basé sur les rôles à la page d’interface utilisateur.
- Si une ACL (liste de contrôle d’accès) est manquante
- Si GlideRecord/GlideDBQuery est utilisé au lieu de GlideRecordSecure dans les sections HTML ou Script de traitement
- Si la page d’interface utilisateur est configurée comme publique dans sys_public Remarque :Interface utilisateur publique : les pages qui sont publiques ou qui utilisent GlideRecord n’affichent pas d’avertissement ACL manquant.
Conditions qui affichent le message des recommandations de sécurité
Le message s’affiche dans les conditions suivantes :
- Toutes les instances internes eclipse/IJ où glide.installation.developer=true.
- Toutes les ressources de page d’interface utilisateur dans le champ d’application du client.
- Toute page d’interface utilisateur personnalisée lorsque la glide.script.ui_page.customer_scoped.security_msgs_enabled propriété est définie sur vrai. (La valeur par défaut est true).
Conditions qui n’affichent pas le message des recommandations de sécurité
Le message ne s’affichera pas dans les conditions suivantes :
- La page de l’interface utilisateur est publique.
- La page de l’interface utilisateur se trouve dans le champ d’application global .
- La glide.script.ui_page.customer_scoped.security_msgs_enabled valeur est définie sur false.
Scripts de processus de page d’interface utilisateur
Si votre page d’interface utilisateur contient un formulaire (utilise la balise <g :form> ;), vous pouvez soumettre le formulaire et faire exécuter le script de processus.
Le script de traitement peut naturellement accéder aux champs du formulaire. Par exemple, si votre formulaire contenait le champ application_sys_id :
<g:ui_form>
<p>Click OK to run the processing script.</p>
<g:dialog_buttons_ok_cancel ok="return true" />
<input type="hidden" name="application_sys_id" value="499836460a0a0b1700003e7ad950b5da" />
</g:ui_form>var application = new GlideRecord('hr_application');
application.get(application_sys_id);
application.status = "Rejected";
application.update();
var urlOnStack = GlideSession.get().getStack().bottom();
response.sendRedirect(urlOnStack);Si vous utilisez la page d’interface utilisateur pour une boîte de dialogue, vous pouvez également référencer l’URL la plus récente sur la pile à l’aide du code ci-dessus, puis envoyer la réponse à cet emplacement. Ceci est utile si vous souhaitez que le script de traitement de la boîte de dialogue mette à jour quelque chose, puis réaffiche l’écran qui a fait apparaître la boîte de dialogue.