Résolution des incohérences de disponibilité du menu de workflow pour les pages verrouillées dans AEMaaCS
Cet article explique comment résoudre la disponibilité incohérente du menu de workflow pour les pages verrouillées entre la console Sites et l’éditeur de page dans Adobe Experience Manager as a Cloud Service (AEMaaCS) et fournit des solutions de contournement jusqu’à ce qu’une mise à jour du produit soit disponible.
Description description
Dans Adobe Experience Manager as a Cloud Service (AEMaaCS), lorsqu’une page est verrouillée (soit en étant dans un workflow, soit en étant explicitement verrouillée par un utilisateur ou une utilisatrice), la console Sites masque l’option de démarrage d’un nouveau workflow sur cette page. Cependant, l’éditeur de page affiche toujours l’option permettant de démarrer un workflow, même si la page est déjà verrouillée. Toute tentative de démarrage d’un workflow à partir de l’éditeur de page dans cet état échoue silencieusement, sans fournir de commentaires à l’utilisateur ou à l’utilisatrice. Cette incohérence peut prêter à confusion et entraîner des échecs de workflow, car les utilisateurs et les utilisatrices peuvent croire qu’un workflow a démarré alors qu’il ne l’a pas encore été.
Environnement
- Adobe Experience Manager as a Cloud Service (toutes versions)
Symptômes
- Créer → Workflow n’est pas disponible pour les pages verrouillées dans la console Sites.
- Informations sur la page → Démarrer le workflow est disponible pour la même page verrouillée dans l’éditeur de page.
- Toute tentative de démarrage d’un workflow à partir de l’éditeur de page sur une page verrouillée échoue sans erreur ni commentaire.
Cause
L’éditeur de page n’applique pas actuellement la même disponibilité de workflow et les mêmes vérifications de verrouillage que la console Sites, ce qui entraîne un comportement incohérent de l’interface utilisateur.
Résolution resolution
Suivez les étapes ci-dessous pour résoudre le problème :
-
Gardez à l’esprit qu’il s’agit d’une limitation de produit connue qui devrait être traitée dans une prochaine version d’AEM as a Cloud Service. Surveillez les notes de mise à jour d’AEM Cloud Service pour obtenir des mises à jour sur ce problème.
-
(Facultatif) Personnalisez l’interface utilisateur de l’éditeur de page :
-
L’équipe de développement peut personnaliser l’éditeur de page pour masquer l’option Démarrer le workflow lorsque la page est verrouillée et que l’utilisateur actuel n’est pas le propriétaire du verrouillage.
-
Cela peut être implémenté en ajoutant une condition de rendu Granite à l’action derrière Informations sur la page → Démarrer le workflow qui vérifie l’état de verrouillage et le propriétaire de la page. Pour plus d’informations sur la personnalisation des actions de l’interface utilisateur, consultez la documentation d’AEM sur la Personnalisation de l’interface utilisateur de la console.
-
-
(Facultatif) Ajoutez un verrouillage dans les modèles de workflow :
-
Ajoutez une étape de processus initiale dans vos modèles de workflow pour examiner le statut et le propriétaire de la ou des pages de payload.
-
Si une page est verrouillée par un autre utilisateur ou une autre utilisatrice, arrêtez immédiatement le workflow ou dirigez-vous vers un chemin d’accès contenu verrouillé.
-
Envoyez des commentaires clairs à l’utilisateur (par exemple : en définissant un commentaire ou une notification de workflow) indiquant que le workflow ne peut pas démarrer, car la page est verrouillée par un autre utilisateur.
-
-
Après avoir appliqué ces solutions de contournement, vérifiez les points suivants :
-
L’option Démarrer le workflow est masquée pour les pages verrouillées dans l’éditeur de page pour les propriétaires non verrouillés.
-
Toute tentative de démarrage d’un workflow sur une page verrouillée fournit immédiatement des commentaires clairs à l’utilisateur ou à l’utilisatrice.
-