Développer des projets dans AEM

Commencez par créer un dossier dans /apps/<your-app-folder> nommé projects. Créez un autre dossier sous le précédent nommé templates.

/apps/aem-guides/projects-tasks/
                    + projects (nt:folder)
                             + templates (nt:folder)

Pour faciliter les choses, nous allons démarrer notre modèle personnalisé à partir du modèle de projet simple existant.

1. Copiez et collez le nœud /libs/cq/core/content/projects/templates/default sous le dossier templates créé à l’étape 1.

/apps/aem-guides/projects-tasks/
             + templates (nt:folder)
                  + default (cq:Template)

Vous devriez maintenant avoir un chemin qui ressemble à /apps/aem-guides/projects-tasks/projects/templates/authoring-project.

1. Remplacez les propriétés jcr:title et jcr:description du nœud author-project par des valeurs de titre et de description personnalisées.

   1. Laissez la propriété wizard pointer vers les propriétés par défaut du projet.

/apps/aem-guides/projects-tasks/projects/
         + templates (nt:folder)
              + authoring-project (cq:Template)
                   - jcr:title = "Authoring Project"
                   - jcr:description = "A project to manage approval and publish process for AEM Sites or Assets"
                   - wizard = "/libs/cq/core/content/projects/wizard/steps/defaultproject.html"

Pour ce modèle de projet, nous voulons utiliser des tâches.

1. Ajouter un nouveau nœud nt:unstructured sous authoring-project/gadgets nommé tasks.
2. Ajoutez des propriétés de chaîne au nœud tasks pour cardWeight = "100", jcr:title = "Tasks" et sling:resourceType = "cq/gui/components/projects/admin/pod/taskpod".

Désormais, la mosaïque des tâches s’affiche par défaut lors de la création d’un projet.

../projects/templates/authoring-project
    + gadgets (nt:unstructured)
         + team (nt:unstructured)
         + asset (nt:unstructured)
         + work (nt:unstructured)
         + experiences (nt:unstructured)
         + projectinfo (nt:unstructured)
         ..
         + tasks (nt:unstructured)
              - cardWeight = "100"
              - jcr:title = "Tasks"
              - sling:resourceType = "cq/gui/components/projects/admin/pod/taskpod"

Nous ajouterons un rôle Approbateur personnalisé à notre modèle de projet.

1. Sous le nœud de modèle de projet (authoring-project), ajoutez un nouveau nœud nt:unstructured étiqueté roles.

2. Ajoutez un autre nœud nt:unstructured étiqueté « approvers » en tant qu’enfant du nœud roles.

3. Ajoutez des propriétés de chaîne jcr:title = "Approvers", roleclass = "owner", roleid = "approvers".

   1. Le nom du nœud des approbateurs et approbatrices, ainsi que jcr:title et roleid, peuvent être n’importe quelle valeur de chaîne (tant que roleid est unique).
   2. roleclass détermine les autorisations appliquées à ce rôle en fonction des trois rôles prêts à l’emploi : personne propriétaire, éditeur ou éditrice, et observateur ou observatrice.
   3. En général, si le rôle personnalisé est davantage un rôle de gestion, la roleclass peut être propriétaire  ; s’il s’agit d’un rôle de création plus spécifique comme photographe ou designer, la roleclass éditeur devrait suffire. La grande différence entre les rôles propriétaire et éditeur est que les personnes propriétaires d’un projet peuvent mettre à jour les propriétés du projet et ajouter de nouveaux utilisateurs et utilisatrices au projet.

../projects/templates/authoring-project
    + gadgets (nt:unstructured)
    + roles (nt:unstructured)
        + approvers (nt:unstructured)
             - jcr:title = "Approvers"
             - roleclass = "owner"
             - roleid = "approver"

En copiant le modèle Projet simple, quatre workflows prêts à l’emploi seront configurés. Chaque nœud sous workflows/models pointe vers un workflow spécifique et un assistant de démarrage de boîte de dialogue pour ce workflow. Plus loin dans ce tutoriel, nous allons créer un workflow personnalisé pour ce projet. Pour l’instant, supprimez les nœuds sous workflow/models :

../projects/templates/authoring-project
    + gadgets (nt:unstructured)
    + roles (nt:unstructured)
    + workflows (nt:unstructured)
         + models (nt:unstructured)
            - (remove ootb models)

Afin que les créateurs et créatrices de contenu puissent facilement identifier le modèle de projet, vous pouvez ajouter une miniature personnalisée. La taille recommandée est de 319x319 pixels.

1. Dans CRXDE Lite, créez un fichier en tant qu’objet apparenté aux gadgets, aux rôles et aux nœuds de workflows nommé thumbnail.png.
2. Enregistrez, puis accédez au nœud jcr:content et double-cliquez sur la propriété jcr:data (évitez de cliquer sur « afficher »).
   1. Cela devrait vous inviter à modifier la boîte de dialogue de fichier jcr:data et vous pouvez alors charger une miniature personnalisée.

../projects/templates/authoring-project
    + gadgets (nt:unstructured)
    + roles (nt:unstructured)
    + workflows (nt:unstructured)
    + thumbnail.png (nt:file)

Vous devriez voir le modèle personnalisé comme l’une des options de création d’un projet.

Après avoir sélectionné le modèle personnalisé, cliquez sur « Suivant » et notez que lorsque vous renseignez les personnes membres du projet, vous pouvez les ajouter avec le rôle Approbateur ou approbatrice.

Cliquez sur « Créer » pour terminer la création du projet à partir du modèle personnalisé. Vous remarquerez sur le tableau de bord du projet que la mosaïque Tâches et les autres mosaïques configurées sous les gadgets apparaissent automatiquement.

Dans le menu Démarrage d’AEM, accédez à Outils > Workflow > Modèles. Cliquez sur « Créer » dans le coin supérieur droit pour créer un modèle de workflow.

Attribuez un titre au nouveau modèle : « Processus d’approbation du contenu » et un nom d’URL : « content-approval-workflow ».

Vous trouverez plus d’informations sur la création de workflows ici.

Il est recommandé de regrouper les workflows personnalisés dans leur propre dossier sous /etc/workflow/models. Dans CRXDE Lite, créez un dossier «  nt:folder  » sous /etc/workflow/models nommé «  aem-guides  ». L’ajout d’un sous-dossier permet de s’assurer que les workflows personnalisés ne sont pas écrasés accidentellement lors des mises à niveau ou des installations de packs de services.

*Notez qu’il est important de ne jamais placer le dossier ou les workflows personnalisés dans des sous-dossiers prêts à l’emploi tels que /etc/workflow/models/dam ou /etc/workflow/models/projects, car le sous-dossier entier peut également être écrasé par des mises à niveau ou des packs de services.

Emplacement du modèle de workflow dans la version 6.3

Si vous utilisez AEM version 6.4 ou ultérieure, le modèle de workflow est créé sous /conf/global/settings/workflow/models. Répétez les étapes ci-dessus avec le répertoire /conf et ajoutez un sous-dossier nommé aem-guides et déplacez le content-approval-workflow sous celui-ci.

Emplacement du modèle de workflow dans la version 6.4 et ultérieure

La possibilité d’ajouter des étapes de processus à un workflow donné est introduite dans AEM 6.3. Les étapes s’affichent pour l’utilisateur ou l’utilisatrice à partir de la boîte de réception dans l’onglet Informations sur le workflow. Elle montre à l’utilisateur ou l’utilisatrice l’étape actuelle du workflow ainsi que les étapes précédentes et suivantes.

Pour configurer les étapes, ouvrez la boîte de dialogue Propriétés de la page dans le sidekick. Le quatrième onglet est intitulé « Étapes ». Ajoutez les valeurs suivantes pour paramétrer les trois étapes de ce workflow :

1. Modifier le contenu
2. Approbation
3. Publier

Configurez les étapes de workflow dans la boîte de dialogue Propriétés de la page.

La barre de progression du workflow telle qu’elle s’affiche dans la boîte de réception AEM.

Vous pouvez éventuellement charger une image dans les Propriétés de page qui servira de miniature du workflow lorsque les utilisateurs et utilisatrices le sélectionnent. Les dimensions de l’image doivent être de 319x319 pixels. L’ajout d’une Description aux Propriétés de page apparaîtra également lorsqu’un utilisateur ou une utilisatrice sélectionne le workflow.

Le processus de workflow Créer une tâche de projet est conçu pour créer une tâche en tant qu’étape dans le workflow. Ce n’est qu’après avoir terminé la tâche que le workflow progresse. L’étape Créer une tâche de projet présente un aspect intéressant : elle peut lire les valeurs de métadonnées de workflow et les utiliser pour créer la tâche de manière dynamique.

Commencez par supprimer l’étape de participant ou participante créée par défaut. Dans le menu Composants du sidekick, développez le sous en-tête Projets et faites glisser et déposez l’étape « Créer une tâche de projet » sur le modèle.

Double-cliquez sur l’étape Créer une tâche de projet pour ouvrir la boîte de dialogue du workflow. Configurez les propriétés suivantes :

Cet onglet est commun à toutes les étapes du processus de workflow et nous définirons le Titre et la Description (ceux-ci ne seront pas visibles par la personne finale). La propriété importante que nous définirons est l’étape du workflow sur « Modifier le contenu » dans le menu déroulant.

Common Tab
-----------------
    Title = "Start Task Creation"
    Description = "This the first task in the Workflow"
    Workflow Stage = "Edit Content"

Le processus de workflow Créer une tâche de projet est conçu pour créer une tâche en tant qu’étape dans le workflow. L’onglet Tâche permet de définir toutes les valeurs de la tâche. Dans notre cas, nous voulons que la personne désignée soit dynamique, nous la laissons donc vide. Le reste des valeurs de propriété :

Task Tab
-----------------
    Name* = "Edit Content"
    Task Priority = "Medium"
    Description = "Edit the content and finalize for approval. Once finished submit for approval."
    Due In - Days = "2"

L’onglet Routage est une boîte de dialogue facultative qui peut spécifier les actions disponibles pour l’utilisateur ou l’utilisatrice qui effectue la tâche. Ces actions ne sont que des valeurs de chaîne et sont enregistrées dans les métadonnées du workflow. Ces valeurs peuvent être lues par des scripts et/ou des étapes de processus plus tard dans le workflow pour « acheminer » dynamiquement le workflow. Selon les objectifs du workflow, nous ajoutons trois actions à cet onglet :

Routing Tab
-----------------
    Actions =
        "Normal Approval"
        "Rush Approval"
        "Bypass Approval"

Cet onglet nous permet de configurer un script de création préalable de tâche dans lequel nous pouvons choisir par programmation différentes valeurs de la tâche avant qu’elle ne soit créée. Nous avons la possibilité de pointer le script vers un fichier externe ou d’incorporer un script court directement dans la boîte de dialogue. Dans notre cas, nous pointons le script de création préalable de tâche vers un fichier externe. À l’étape 5, nous allons créer ce script.

Advanced Settings Tab
-----------------
   Pre-Create Task Script = "/apps/aem-guides/projects/scripts/start-task-config.ecma"

À l’étape précédente, nous avons référencé un script de création préalable de tâche. Nous allons créer ce script dans lequel nous définirons la personne désignée de la tâche en fonction de la valeur d’une valeur de métadonnées de workflow «  assignee  ». La valeur assignee est définie au déclenchement du workflow. Nous allons également lire les métadonnées de workflow pour choisir dynamiquement la priorité de la tâche en lisant la valeur taskPriority des métadonnées du workflow, ainsi que la taskdueDate (date d’échéance de la tâche) pour définir dynamiquement le moment où la première tâche doit être effectuée.

À des fins d’organisation, nous avons créé un dossier sous notre dossier d’application destiné à contenir tous les scripts liés au projet : /apps/aem-guides/projects-tasks/projects/scripts. Créez un fichier sous ce dossier nommé «  start-task-config.ecma  ». *Notez que le chemin d’accès à votre fichier start-task-config.ecma correspond au chemin d’accès défini dans l’onglet Paramètres avancés de l’étape 4.

Ajoutez les éléments suivants comme contenu du fichier :

// start-task-config.ecma
// Populate the task using values stored as workflow metadata originally posted by the start workflow wizard

// set the assignee based on start workflow wizard
var assignee = workflowData.getMetaDataMap().get("assignee", Packages.java.lang.String);
task.setCurrentAssignee(assignee);

//Set the due date for the initial task based on start workflow wizard
var dueDate = workflowData.getMetaDataMap().get("taskDueDate", Packages.java.util.Date);
if (dueDate != null) {
    task.setProperty("taskDueDate", dueDate);
}

//Set the priority based on start workflow wizard
var taskPriority = workflowData.getMetaDataMap().get("taskPriority", "Medium");
task.setProperty("taskPriority", taskPriority);

Revenez au workflow d’approbation du contenu. Faites glisser et déposez le composant Division OU (situé dans le Sidekick sous la catégorie « Workflow ») sous l’étape Démarrer la tâche. Dans la boîte de dialogue commune, sélectionnez le bouton radio correspondant à 3 branches. La Division OU lit la valeur des métadonnées du workflow «  lastTaskAction  » pour déterminer l’itinéraire du workflow. La propriété «  lastTaskAction  » est définie sur l’une des valeurs de l’onglet Routage configuré à l’étape 4. Pour chacun des onglets Branche, renseignez la zone de texte Script avec les valeurs suivantes :

function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Normal Approval") {
    return true;
}

return false;
}

function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Rush Approval") {
    return true;
}

return false;
}

function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Bypass Approval") {
    return true;
}

return false;
}

*Notez que nous effectuons une correspondance de chaîne directe pour déterminer l’itinéraire. Il est donc important que les valeurs définies dans les scripts Branch correspondent aux valeurs d’itinéraire définies à l’étape 4.

Faites glisser et déposez une autre étape Créer une tâche de projet sur le modèle le plus à gauche (Branch 1) sous la Division OU. Renseignez la boîte de dialogue avec les propriétés suivantes :

Common Tab
-----------------
    Title = "Approval Task Creation"
    Description = "Create a an approval task for Project Approvers. Priority is Medium."
    Workflow Stage = "Approval"

Task Tab
------------
    Name* = "Approve Content for Publish"
    Task Priority = "Medium"
    Description = "Approve this content for publication."
    Days = "5"

Routing Tab - Actions
----------------------------
    "Approve and Publish"
    "Send Back for Revision"

Puisqu’il s’agit de l’itinéraire de validation normal, la priorité de la tâche est définie sur Moyenne. De plus, nous donnons au groupe d’approbation 5 jours pour terminer la tâche. La personne désignée reste vide dans l’onglet Tâche, car nous l’affecterons de manière dynamique dans l’onglet Paramètres avancés. Nous donnons au groupe d’approbation deux itinéraires possibles lors de l’exécution de cette tâche : « Approuver et publier » si les personnes du groupe approuvent le contenu et qu’il peut être publié et « Envoyer pour révision » si des problèmes doivent être corrigés par l’éditeur ou éditrice d’origine. La personne chargée de l’approbation peut laisser des commentaires que l’éditeur ou éditrice d’origine verra si le workflow lui est renvoyé.

Faites glisser et déposez une autre étape Créer une tâche de projet sur le modèle à la branche centrale (Branch 2) sous la Division OU. Renseignez la boîte de dialogue avec les propriétés suivantes :

Common Tab
-----------------
    Title = "Rush Approval Task Creation"
    Description = "Create a an approval task for Project Approvers. Priority is High."
    Workflow Stage = "Approval"

Task Tab
------------
    Name* = "Rush Approve Content for Publish"
    Task Priority = "High"
    Description = "Rush approve this content for publication."
    Days = "1"

Routing Tab - Actions
----------------------------
    "Approve and Publish"
    "Send Back for Revision"

Puisqu’il s’agit de l’itinéraire d’approbation rapide, la priorité de la tâche est définie sur Élevée. De plus, nous ne donnons au groupe d’approbation qu’un seul jour pour terminer la tâche. La personne désignée reste vide dans l’onglet Tâche, car nous l’affecterons de manière dynamique dans l’onglet Paramètres avancés.

Nous pouvons réutiliser le même fragment de script qu’à l’étape 7 pour renseigner la zone de texte Script dans l’onglet Paramètres avancés. Copiez et collez le code ci-dessous :

var projectApproverGrp = workflowData.getMetaDataMap().get("project.group.approvers","administrators");

task.setCurrentAssignee(projectApproverGrp);

Faites glisser et déposez un composant Aucune opération vers la branche la plus à droite (Branch 3). Le composant Aucune opération n’effectue aucune action et progresse immédiatement, ce qui représente la volonté de l’éditeur ou éditrice d’origine de contourner l’étape d’approbation. Techniquement, nous pourrions laisser cette branche sans aucune étape de workflow, mais nous allons ajouter une étape Aucune opération en tant que bonne pratique. Cela permet aux autres développeurs et développeuses de déterminer l’objectif de la Branch 3.

Double-cliquez sur l’étape du workflow et configurez le Titre et la Description :

Common Tab
-----------------
    Title = "Bypass Approval"
    Description = "Placeholder step to indicate that the original editor decided to bypass the approver group."

Le modèle de workflow doit ressembler à ceci une fois que les trois branches de la Division OU ont été configurées.

Puisque le groupe d’approbation a la possibilité de renvoyer le workflow à l’éditeur ou l’éditrice d’origine pour d’autres révisions, l’étape Atteindre est nécessaire pour lire la dernière action effectuée et acheminer le workflow vers le début ou le laisser continuer.

Faites glisser et déposez le composant Étape Atteindre (situé dans le Sidekick, sous Workflow) sous la Division OU où il se joint à nouveau. Double-cliquez et configurez les propriétés suivantes dans la boîte de dialogue :

Common Tab
----------------
    Title = "Goto Step"
    Description = "Based on the Approver groups action route the workflow to the beginning or continue and publish the payload."

Process Tab
---------------
    The step to go to. = "Start Task Creation"

Le dernier élément que nous allons configurer est le script, qui fait partie de l’étape du processus Atteindre. La valeur du Script peut être incorporée via la boîte de dialogue ou configurée pour renvoyer vers un fichier externe. Le script Atteindre doit contenir une fonction check() et renvoyer la valeur « true » si le workflow doit atteindre l’étape spécifiée. Le renvoi de résultats « false » fait avancer le workflow.

Si le groupe d’approbation choisit l’action Renvoyer pour révision (configurée aux étapes 7 et 8), le workflow doit retourner à l’étape Commencer la création de la tâche.

Sous l’onglet Processus, ajoutez le fragment de code suivant à la zone de texte Script :

function check() {
var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

if(lastAction == "Send Back for Revision") {
    return true;
}

return false;
}

Pour publier la payload, nous utiliserons l’étape du processus Activer la page/ressource prête à l’emploi. Cette étape de processus nécessite peu de configuration et ajoute la payload du workflow à la file d’attente de réplication pour activation. Nous allons ajouter l’étape sous l’étape Atteindre. Elle ne sera ainsi atteinte que si le groupe d’approbation a approuvé le contenu à publier ou si l’éditeur ou l’éditrice d’origine a choisi l’itinéraire Contourner l’approbation.

Faites glisser l’étape de processus Activer la page/ressource (qui se trouve dans le Sidekick, sous le workflow de gestion de contenu web) dans l’étape Atteindre du modèle.

.

Le modèle de workflow doit ressembler à ceci après l’ajout des étapes Atteindre et Activer la page/ressource.

Si le groupe d’approbation renvoie le contenu pour révision, la personne éditrice d’origine doit en être informée. Pour ce faire, nous pouvons modifier dynamiquement les propriétés de création de tâche. Nous modifierons la valeur de la propriété lastActionTaken de Renvoyer pour révision. Si cette valeur est présente, nous modifierons le titre et la description afin d’indiquer que cette tâche est le résultat du contenu renvoyé pour révision. Nous définirons également la priorité sur Élevée, afin que l’éditeur ou l’éditrice s’attelle à cette tâche en priorité. Enfin, nous définirons la date d’échéance de la tâche à « un jour » à partir du moment où le workflow a été renvoyé pour révision.

Remplacez le script de démarrage start-task-config.ecma (créé à l’étape 5) par les éléments suivants :

// start-task-config.ecma
// Populate the task using values stored as workflow metadata originally posted by the start workflow wizard

// set the assignee based on start workflow wizard
var assignee = workflowData.getMetaDataMap().get("assignee", Packages.java.lang.String);
task.setCurrentAssignee(assignee);

//Set the due date for the initial task based on start workflow wizard
var dueDate = workflowData.getMetaDataMap().get("taskDueDate", Packages.java.util.Date);
if (dueDate != null) {
    task.setProperty("taskDueDate", dueDate);
}

//Set the priority based on start workflow wizard
var taskPriority = workflowData.getMetaDataMap().get("taskPriority", "Medium");
task.setProperty("taskPriority", taskPriority);

var lastAction = workflowData.getMetaDataMap().get("lastTaskAction","");

//change the title and priority if the approver group sent back the content
if(lastAction == "Send Back for Revision") {
  var taskName = "Review and Revise Content";

  //since the content was rejected we will set the priority to High for the revison task
  task.setProperty("taskPriority", "High");

  //set the Task name (displayed as the task title in the Inbox)
  task.setProperty("name", taskName);
  task.setProperty("nameHierarchy", taskName);

  //set the due date of this task 1 day from current date
  var calDueDate = Packages.java.util.Calendar.getInstance();
  calDueDate.add(Packages.java.util.Calendar.DATE, 1);
  task.setProperty("taskDueDate", calDueDate.getTime());

}

Dans CRXDE-Lite, nous allons créer un sous-dossier dans le dossier /apps/aem-guides/projects-tasks/projects appelé « wizards » (assistants). Copiez l’assistant par défaut à partir de : /libs/cq/core/content/projects/workflowwizards/default_workflow sous le dossier « wizards » nouvellement créé et renommez-le en content-approval-start. Le chemin complet est le suivant : /apps/aem-guides/projects-tasks/projects/wizards/content-approval-start.

L’assistant par défaut est un assistant à 2 colonnes. La première colonne indique le titre, la description et la miniature du modèle de workflow sélectionné. La deuxième colonne comprend des champs pour le titre du workflow, les commentaires de démarrage et le chemin d’accès à la payload. L’assistant est un formulaire d’interface utilisateur tactile standard et utilise les Composants de formulaire de l’IU Granite pour renseigner les champs.

.

Nous ajouterons un champ supplémentaire à l’assistant qui est utilisé pour définir la personne désignée de la première tâche dans le workflow (consultez l’étape 5 de la section Créer un modèle de workflow).

Sous ../content-approval-start/jcr:content/items/column2/items, créez un nœud de type nt:unstructured et nommez-le « assign ». Nous utiliserons le composant Sélecteur d’utilisateur ou d’utilisatrice de projets (basé sur le Composant de sélecteur d’utilisateur ou d’utilisatrice Granite). Ce champ de formulaire permet de limiter la sélection des utilisateurs et utilisatrices et des groupes à ceux qui appartiennent au projet en cours.

Vous trouverez ci-dessous la représentation XML du nœud assign  :

<assign
    granite:class="js-cq-project-user-picker"
    jcr:primaryType="nt:unstructured"
    sling:resourceType="cq/gui/components/projects/admin/userpicker"
    fieldLabel="Assign To"
    hideServiceUsers="{Boolean}true"
    impersonatesOnly="{Boolean}true"
    showOnlyProjectMembers="{Boolean}true"
    name="assignee"
    projectPath="${param.project}"
    required="{Boolean}true"/>

Nous ajouterons également un champ de sélection des priorités qui déterminera la priorité de la première tâche du workflow (consultez l’étape 5 de la section Créer un modèle de workflow).

Sous /content-approval-start/jcr:content/items/column2/items, créez un nœud de type nt:unstructured et nommez-le priority. Nous utiliserons le composant Sélection de l’IU Granite pour remplir le champ de formulaire.

Sous le nœud priority, nous allons ajouter un nœud items de nt:unstructured. Sous le nœud items, ajoutez 3 nœuds supplémentaires pour remplir les options de sélection pour High, Medium et Low (Élevé, Moyen et Faible). Chaque nœud est de type nt:unstructured et doit avoir une propriété text et value. Les valeurs de ces 2 propriétés doivent être identiques :

1. Élevée
2. Moyenne
3. Faible

Pour le nœud Medium, ajoutez une propriété booléenne supplémentaire nommée «  selected » et définissez la valeur suivante : true. Cela permet de s’assurer que Medium est la valeur par défaut dans le champ de sélection.

Vous trouverez ci-dessous une représentation XML de la structure et des propriétés du nœud :

<priority
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/select"
    fieldLabel="Task Priority"
    name="taskPriority">
        <items jcr:primaryType="nt:unstructured">
            <high
                jcr:primaryType="nt:unstructured"
                text="High"
                value="High"/>
            <medium
                jcr:primaryType="nt:unstructured"
                selected="{Boolean}true"
                text="Medium"
                value="Medium"/>
            <low
                jcr:primaryType="nt:unstructured"
                text="Low"
                value="Low"/>
            </items>
</priority>

Nous autorisons à présent la personne à l’origine du workflow à définir la date d’échéance de la tâche initiale. Le champ de formulaire Sélecteur de date de l’IU Granite permet de capturer cette entrée. Le champ masqué TypeHint est ajouté pour s’assurer que l’entrée est stockée en tant que propriété de type Date dans JCR.

Ajoutez deux nœuds nt:unstructured avec les propriétés suivantes représentées ci-dessous en code XML :

<duedate
    granite:rel="project-duedate"
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/datepicker"
    displayedFormat="YYYY-MM-DD HH:mm"
    fieldLabel="Due Date"
    minDate="today"
    name="taskDueDate"
    type="datetime"/>
<duedatetypehint
    jcr:primaryType="nt:unstructured"
    sling:resourceType="granite/ui/components/coral/foundation/form/hidden"
    name="taskDueDate@TypeHint"
    type="datetime"
    value="Calendar"/>

Pour consulter le code complet de la boîte de dialogue de l’assistant de démarrage, rendez-vous ici.

Dans CRXDE-Lite, accédez au modèle de projet de création créé précédemment dans /apps/aem-guides/projects-tasks/projects/templates/authoring-project/workflows/models.

Sous le nœud models, ajoutez un nouveau nœud nommé contentapproval avec le type de nœud nt:unstructured. Ajoutez les propriétés suivantes au nœud :

<contentapproval
    jcr:primaryType="nt:unstructured"
    modelId="/etc/workflow/models/aem-guides/content-approval-workflow/jcr:content/model"
    wizard="/apps/aem-guides/projects-tasks/projects/wizards/content-approval-start.html"
/>

<contentapproval
    jcr:primaryType="nt:unstructured"
    modelId="/var/workflow/models/aem-guides/content-approval-workflow"
    wizard="/apps/aem-guides/projects-tasks/projects/wizards/content-approval-start.html"
/>

Une fois que le workflow d’approbation de contenu a été ajouté au modèle de projet, il doit pouvoir être lancé à partir de la mosaïque Workflow du projet. Après l’effort, le réconfort. Lancez-vous et essayez les différents itinéraires que nous avons créés.