Fermer

février 8, 2023

Simplification de l’exécution du workflow dans Adobe Experience Manager

Simplification de l’exécution du workflow dans Adobe Experience Manager


Récemment, nous avons rencontré un cas d’utilisation lors de l’utilisation de flux de travail dans Adobe Experience Manager, où les auteurs de contenu devaient exécuter uniquement certains flux de travail sur les pages. La fonctionnalité prête à l’emploi affiche tous les workflows disponibles dans la liste d’actions. Du point de vue de l’expérience utilisateur, ce n’était pas souhaitable car l’auteur aurait besoin de faire défiler toute la liste pour choisir celui qui devait être exécuté.

Afin de fournir une meilleure expérience utilisateur où l’auteur n’a pas besoin de faire défiler la liste complète des flux de travail, nous avons essayé d’identifier une solution qui affiche uniquement la liste pertinente, au lieu de la totalité.

Nous avons défini l’ACL pour un groupe spécifique pour lequel les membres concernés étaient autorisés à exécuter le flux de travail. Voici les étapes nécessaires pour définir l’ACL pour un groupe pour lequel les membres sont autorisés à exécuter le flux de travail –

ÉTAPE 1: Créez un groupe pour les utilisateurs pour exécuter le workflow. C’est-à-dire workflow-user-group

ÉTAPE 2: Définissez les autorisations sous /var/workflow/models/ dossier à refuser les nœuds qui ne sont pas requis pour le workflow-user-group.

C’était assez simple comme donner les permissions à n’importe quel utilisateur, n’est-ce pas ? Maintenant, vous vous demandez peut-être en quoi c’était spécifique au flux de travail et quel est l’apprentissage de cet article. La réponse est donc – Attendez, encore, l’exigence n’est pas remplie. Néanmoins, nous pouvons voir certains des flux de travail non requis dans la liste Démarrer le flux de travail. Maintenant, nous avons les questions ci-dessous –

  • Si nous avons refusé tous les workflows auxquels l’utilisateur/groupe ne devrait pas avoir accès, pourquoi certains workflows sont-ils encore visibles ?
  • Comment masquer ces workflows de la liste.

Alors, voici la réponse –

Dans les dossiers /var/workflow/models, certains workflows sont gérés dans un sous-dossier et quelques-uns ne sont pas gérés directement dans le dossier models. Les autorisations que nous avons appliquées à partir de l’administrateur de l’utilisateur ne s’appliquent qu’aux dossiers et non aux dossiers non gérés.

Maintenant, si nous ne pouvons pas attribuer d’autorisations àe flux de travail non gérés, alors comment devrions-nous les masquer de la liste ?

En fait, nous pouvons également attribuer des autorisations à des flux de travail non gérés, mais pas à partir de l’administrateur de l’utilisateur console. Nous devons faire un travail supplémentaire pour attribuer des autorisations aux flux de travail non gérés, et voici les étapes pour la même chose :-

ÉTAPE 1: Ouvrez Crx/de.

ÉTAPE 2: Accédez au dossier /var/workflow/models.

ÉTAPE 3: Sélectionnez le nœud des modèles et ouvrez l’onglet Contrôle d’accès dans le volet inférieur droit.

ÉTAPE 4: Cliquez sur le symbole + de couleur verte.

ÉTAPE 5 : Sélectionnez votre groupe, définissez l’autorisation sur refuser et sélectionnez jcr:read.

Avons-nous fini? Pas encore – si vous cliquez sur OK ici, cela refusera l’accès à tous les flux de travail. Nous devons donc faire un réglage préalable sous le ‘avance’ section et définir la valeur pour la rep:glob propriété. Comme valeur, vous devez donner le nom du nœud de flux de travail commençant par ‘/.’

Par exemple, si vous souhaitez définir une autorisation pour le demande_d’activation nœud, alors vous devez définir

rep:glob = /request_for_activation

Il prend en charge les caractères génériques ainsi et peut être utilisé pour définir l’autorisation pour tous les nœuds commencés par demande

monde clé.

rep:glob = /demande* C’est ça; vous pouvez définir plusieurs règles pour plusieurs nœuds si cela ne peut pas être réalisé en utilisant*

.

TROUVÉ CELA UTILE ? PARTAGEZ-LE




Source link