Beheben von inkonsistenter Workflow-Menüverfügbarkeit für gesperrte Seiten in AEMaaCS
In diesem Artikel wird erläutert, wie sich inkonsistente Workflow-Menüverfügbarkeit für gesperrte Seiten zwischen der Sites-Konsole und dem Seiteneditor in Adobe Experience Manager as a Cloud Service (AEMaaCS) beheben lässt, und es werden Problemumgehungen bereitgestellt, bis ein Produktaktualisierungs-Tool verfügbar ist.
Beschreibung description
Wenn eine Seite in Adobe Experience Manager as a Cloud Service (AEMaaCS) gesperrt wird - entweder durch Betreten eines Workflows oder durch explizite Sperrung durch einen Benutzer -, blendet die Sites-Konsole die Option zum Starten eines neuen Workflows auf dieser Seite aus. Im Seiten-Editor wird jedoch weiterhin die Option zum Starten eines Workflows angezeigt, obwohl die Seite bereits gesperrt ist. In diesem Zustand schlägt der Versuch, einen Workflow über den Seiteneditor zu starten, leise fehl und gibt dem Benutzer kein Feedback. Diese Inkonsistenz kann zu Verwirrung und potenziellen Workflow-Fehlern führen, da Benutzende möglicherweise glauben, dass ein Workflow gestartet wurde, obwohl er noch nicht gestartet wurde.
Umgebung
- Adobe Experience Manager as a Cloud Service (alle Versionen)
Symptome
- Erstellen → Workflow ist nicht für gesperrte Seiten in der Sites-Konsole verfügbar.
- Seiteninformationen → Workflow starten ist im Seiteneditor für dieselbe gesperrte Seite verfügbar.
- Der Versuch, einen Workflow über den Seiteneditor auf einer gesperrten Seite zu starten, schlägt ohne Fehler oder Feedback fehl.
Ursache
Der Seiteneditor erzwingt derzeit nicht dieselbe Workflow-Verfügbarkeit und Sperrprüfungen wie die Sites-Konsole, was zu einem inkonsistenten Verhalten der Benutzeroberfläche führt.
Lösung resolution
Gehen Sie wie folgt vor, um das Problem zu beheben:
-
Beachten Sie, dass es sich hierbei um eine bekannte Produktbeschränkung handelt und dass dies in einer zukünftigen AEM as a Cloud Service-Version behoben werden soll. Überwachen Sie die Versionshinweise zu AEM Cloud Service auf Aktualisierungen zu diesem Problem.
-
(Optional) Passen Sie die Benutzeroberfläche des Seiteneditors an:
-
Entwickler können den Seiteneditor anpassen, um die Option Workflow starten auszublenden, wenn die Seite gesperrt ist und der aktuelle Benutzer nicht der Sperreigentümer ist.
-
Dies kann durch Hinzufügen einer Granite-Render-Bedingung zur Aktion hinter Seiteninformationen → Workflow starten implementiert werden, die den Sperrstatus und -besitzer der Seite überprüft. Weitere Informationen zum Anpassen von Benutzeroberflächenaktionen finden Sie in der AEM-Dokumentation zum Anpassen der Konsolenbenutzeroberfläche.
-
-
(Optional) Fügen Sie eine Sperrprüfung in Workflow-Modellen hinzu:
-
Fügen Sie einen ersten Prozessschritt in Ihren Workflow-Modellen hinzu, um die Payload-Seite(n) auf den Sperrstatus und den Inhaber zu überprüfen.
-
Wenn eine Seite von einem anderen Benutzer gesperrt wird, stoppen Sie den Workflow oder leiten Sie ihn zu einem Pfad gesperrter Inhalt weiter.
-
Geben Sie dem Benutzer ein klares Feedback (z. B. durch Festlegen eines Workflow-Kommentars oder einer Benachrichtigung), das angibt, dass der Workflow nicht gestartet werden kann, da die Seite von einem anderen Benutzer gesperrt ist.
-
-
Nachdem Sie diese Problemumgehungen angewendet haben, überprüfen Sie Folgendes:
-
Die Option Workflow starten ist für gesperrte Seiten im Seiteneditor für nicht gesperrte Besitzer ausgeblendet.
-
Der Versuch, einen Workflow auf einer gesperrten Seite zu starten, liefert dem Benutzer sofortiges und klares Feedback.
-