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 dans les tableaux de bord. Pour trouver les pages de l’interface utilisateur, accédez à .
Cette fonctionnalité nécessite des connaissances en HTML ou en Jelly. Vous pouvez également créer des applications AngularJS simples à l’aide de pages de l’interface utilisateur.
| Champ | Description |
|---|---|
| Nom | Nom utilisé pour appeler la page via une URL (ne doit pas contenir d’espaces). |
| Demande | Affiche le périmètre de l’application actuel. |
| Description | La description de la page d’interface utilisateur et son utilité. |
| Direct | Cochez cette case pour une page d’interface utilisateur directe [sys_ui_page]. Une page d’interface utilisateur directe n’inclut pas le HTML, CSS et les scripts courants. Ce paramètre nécessite l’ajout de CSS et de JavaScript personnalisés à utiliser dans la page. |
| HTML | Composant principal de la page dans lequel vous définissez ce qui est affiché lorsque la page est affichée. Il peut contenir du XHTML statique, du contenu généré dynamiquement défini comme Jelly, ou des includes de script 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 tout traitement côté client nécessaire, 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 dans 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 hérités continuent d’être pris en charge, la création de nouveaux processeurs personnalisés est déconseillée. Utilisez plutôt le API REST basées sur un scriptfichier . |
| Listes connexes sur 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 Utiliser des contrôles d’accès sur les pages de l’interface utilisateur pour plus d'informations. |
| Versions | Affiche toutes les versions de la page d’interface utilisateur. Utilisez cette liste pour comparer les versions ou pour revenir à une version précédente. |
Contrôle d'accès
Vous pouvez sécuriser une page d’interface utilisateur en créant une ACL avec les paramètres suivants :
- Type : ui_page
- Opération : lecture
- Nom : nom de la page d’interface utilisateur à protéger
- Rôle : rôle d’utilisateur autorisé à accéder à l’enregistrement
Pages de l’interface utilisateur à risque élevé
- Utilise GlideRecord ou GlideDBQuery au lieu de GlideRecordSecure.Remarque :Cela s’applique aux champs HTML et de 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 qu’elle est saisie dans l’enregistrement sys_public .
- Affiche un message pour indiquer la page d’interface utilisateur à risque élevé.
- Pour les instances avec glide.installation.developer est défini sur vrai.
- Si la ressource est du contenu personnalisé pour une instance cliente.
Accès à la page de l’interface utilisateur
Chaque page de l’interface utilisateur possède 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, accédez à https://<nom d’instance>.service-now.com/glidewindow_example.do. Si la page faisait partie d’une application personnalisée appelée example_app, vous navigueriez plutôt vers https://<nom d’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 cela 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 le sys_id de l’utilisateur. Appelez la page d’interface utilisateur suivante pour afficher une liste de rôles pour cet utilisateur avec du 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 d’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 le 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 en passant des scripts dans les pages de l’interface utilisateur.
Utiliser des 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 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 d’interface utilisateur.
Pages de l’interface utilisateur sécurisée
Les contrôles d’accès et les messages de sécurité associés sont intégrés sur les pages de l’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é à la place 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 :Les pages de l’interface utilisateur publique qui sont publiques ou qui utilisent GlideRecord n’affichent pas d’avertissement d’ACL manquant.
Conditions qui affichent le message de 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 de l’interface utilisateur incluses dans le champ d’application du client.
- N’importe quelle page de l’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 vrai).
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 est dans le champ d’application Global .
- Le glide.script.ui_page.customer_scoped.security_msgs_enabled paramètre est défini sur faux.
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 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 de l’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.