Pages de l'interface utilisateur

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 8 minutes de lecture
  • Les pages de l’interface utilisateur permettent de créer et d’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 des widgets sur les tableaux de bord. Pour trouver les pages de l’interface utilisateur, accédez à Interface utilisateur du système > Pages de l'interface utilisateur.

    Cette fonction 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.

    Le formulaire Page d’interface utilisateur contient les champs suivants :
    Tableau 1. Page de l'interface utilisateur
    Champ Description
    Nom Nom utilisé pour appeler la page via une URL (ne doit pas contenir d’espace).
    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 d’interface utilisateur directe [sys_ui_page]. Une page d’interface utilisateur directe n’inclut pas le langage HTML, 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 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 sur un champ ou d’autres fonctionnalités DHTML interactives après le chargement d’une page.

    Les scripts clients pour 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 conserver la facilité de gestion de Jelly et HTML.

    Script de traitement Script qui s’exécute sur le serveur lorsque la page est soumise. Cela peut être 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 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 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 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 les versions ou pour 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 d’interface utilisateur à protéger
    • Rôle : rôle d’utilisateur autorisé à accéder à l’enregistrement
    Lors de l’enregistrement d’une nouvelle page d’interface utilisateur, vous serez invité à affecter un rôle de contrôle d’accès.Sélection du rôle pour le contrôle d’accès pour une nouvelle page de l’interface utilisateur.
    Remarque :
    Une entrée portant le même nom que la page d’interface utilisateur est créée dans la table Contrôle d’accès.
    Pour plus d’informations sur la création d’une règle ACL, consultez Créer une règle ACL.

    Pages de l’interface utilisateur à risque élevé

    Les pages de l’interface utilisateur sont considérées comme présentant un risque élevé avec l’un des attributs suivants :
    • 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 entrée dans l’enregistrement sys_public .
    • Affiche un message pour indiquer la page de l’interface utilisateur à risque élevé.
    • Pour les instances avec 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 d’instance>.service-now.com/glidewindow_example.do. Si la page fait partie d’une application personnalisée appelée example_app, vous devez accéder à https://<nom d’instance>.service-now.com/x_example_app_glidewindow_example.do.

    Vous pouvez également ajouter des paramètres supplémentaires à une URL accessible dans la section HTML d’une page en tant que variables Jelly. C’est-à-dire que l’ajout d’arguments à l’URL comme suit : /my_test_page.do ?sysparm_verbose=true crée des variables Jelly appelées qui peuvent être consultées verbose comme suit :
    <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 les 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 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 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 de l’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 de l’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

    1. Élevez-vous au rôle security_admin .
    2. Accédez à la Tout > Interface utilisateur du système > Pages de l'interface utilisateur.
    3. Sélectionnez Nouveau.
    4. Renseignez le formulaire.
      Pour plus d’informations, consultez la rubrique Pages de l'interface utilisateur pour les descriptions des champs de l’interface utilisateur.
    5. Sélectionnez Soumettre ou Envoyer.
      Une fenêtre modale s’affiche vous invitant à créer un contrôle d’accès basé sur les rôles pour la page de l’interface utilisateur.Affiche la fenêtre modale de contrôle d’accès basée sur les rôles.
    6. Sélectionnez un rôle.
    7. Sélectionnez OK pour affecter le rôle.
      Vous êtes renvoyé à la liste des pages de l’interface utilisateur.
    Ajoutez, modifiez ou affichez des contrôles d’accès pour une page d’interface utilisateur existante :
    1. Ouvrez une page d’interface utilisateur à partir de la table Pages de l’interface utilisateur.
    2. Affichez les contrôles d’accès dans les listes connexes.
    3. Sélectionnez Nouveau pour créer un nouveau contrôle d’accès ou sélectionnez une entrée existante pour la modifier.
      Le formulaire de contrôle d’accès se charge. Les détails de la page de l’interface utilisateur s’affichent.
    4. Remplissez le formulaire et affectez un rôle à la page d’interface utilisateur.
      Pour plus d’informations sur le contrôle d’accès, consultez Créer une règle ACL.
    5. Sélectionnez Soumettre pour un nouveau contrôle d’accès ou Mettre à jour pour modifications.
      Remarque :
      Il peut y avoir plusieurs contrôles d’accès par page d’interface utilisateur.

    Sécuriser les pages de l’interface utilisateur

    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 à haut risque 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.

    Messages de recommandations de sécurité de la page de l’interface utilisateur.

    Le message s’affiche dans les conditions suivantes :
    • En l’absence d’une ACL (liste de contrôle d’accès)
    • Si GlideRecord/GlideDBQuery est utilisé à la place de GlideRecordSecure dans les sections HTML ou Script de traitement, exemples HTML et 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.
    Pour en savoir plus, consultez Pages de l'interface utilisateur les pages de l’interface utilisateur présentant un risque élevé.

    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 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 se trouve dans le champ d’application global .
    • Le glide.script.ui_page.customer_scoped.security_msgs_enabled est défini sur false.
    Remarque :
    Pour désactiver l’invite de création d’ACL basée sur les rôles, définissez la glide.ui_page.enable_acl_create_ux propriété sur false. La propriété est définie sur true par défaut.

    Scripts de processus de page de l’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 contient 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>
    Vous pouvez accéder au champ à l’aide de application_sys_id :
    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);
    Important :
    Le script précédent n’est utilisable qu’avec les applications globales.

    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 de 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.