Comment implémenter une approbation en plusieurs étapes avec des formulaires Web / formulaires d'entité basés sur des composants de formulaire?
Est-il possible d'appeler un workflow de soumission en plusieurs étapes en utilisant Webform ou Entityform ? Voici le scénario des workflows:
- Un employé soumet le formulaire
- Le superviseur reçoit une notification, après avoir examiné le formulaire, il l'approuve ou refuse la demande sur la même soumission.
- S'il est approuvé, une notification par e-mail est envoyée au directeur qui, à son tour, approuve ou désapprouve la même soumission.
- En cas de refus du superviseur, un e-mail est envoyé à un employé.
Ce scénario implique des soumissions par plusieurs rôles à la même demande. Je pourrais masquer les champs d'approbation au rôle d'employé, mais comment accéder au composant de champ d'approbation de formulaire Web via des règles à des fins de notification? Comment geler l'état du formulaire?
Dois-je plutôt utiliser entityforms puisque chaque composant de formulaire est exposé? En dernier recours, je pourrais implémenter ma propre solution à l'aide de forms_api. Mais je voudrais d'abord savoir s'il est possible d'utiliser un formulaire Web ou des formulaires d'entité.
La mise en œuvre de ce flux de travail est possible en utilisant une combinaison de ces modules (et des types de contenu réguliers, pas besoin de quelque chose comme des "formulaires Web"):
Reportez-vous à ma réponse dans la question sur " Comment puis-je permettre aux visiteurs anonymes de soumettre du contenu? " pour des exemples (et plus de détails) sur la façon d'utiliser ces 4 modules ensemble (cette question ici semble être une variation de cette question).
Voici quelques détails pour implémenter votre flux de travail avec une approche similaire:
Un employé soumet le formulaire
L'employé crée un nœud de type de contenu (par exemple) "Demande" (Utilisez Accès au conten pour affiner toutes sortes d'autorisations sur "quel rôle est autorisé à créer de tels types, si vous avez plusieurs types de demandes, vous venez de étendre aux types de contenu multipoints).
Le superviseur reçoit une notification, après avoir examiné le formulaire, il l'approuve ou refuse la demande sur la même soumission.
Utilisez les règles pour "envoyer un e-mail" (= action) au superviseur "Une fois le contenu de type" Demande "enregistré" (= événement). Dans l'eMail (personnalisé) pour le superviseur, incluez tous les détails pertinents sur la demande (en fonction des différentes données disponibles pour les règles). Telle qu'une URL du nœud à examiner.
Pour vous assurer que le demandeur ne peut pas modifier les données de la demande (alors que le processus de révision est en cours), ajoutez une action supplémentaire à la même règle (précédente) qui met à jour l'accès à la demande (pour la rendre en lecture seule pour le demandeur).
Utilisez le module Flag pour permettre au (x) superviseur (s) de marquer le nœud soumis avec des indicateurs tels que 'Approuvé (par le superviseur)' ou 'Refusé (par le superviseur)' (Rejeté?). L'autorisation de définir ces indicateurs est limitée au (x) superviseur (s).
S'il est approuvé, une notification par e-mail est envoyée au directeur qui, à son tour, approuve ou désapprouve la même soumission.
Utilisez les règles (à nouveau) pour que "Une fois qu'un nœud soit marqué avec 'Approuvé (par le superviseur)'" (= événement), cela provoque un "envoi d'un e-mail" (= action) similaire à Director. Dans l'e-mail (personnalisé) pour le directeur, incluez tous les détails pertinents sur la demande (en fonction des différentes données disponibles pour les règles). Telle qu'une URL du nœud à examiner.
Utilisez le module Flag (à nouveau) pour permettre au directeur de marquer le nœud soumis avec des indicateurs tels que "approuvé (par le directeur)" ou "refusé (par le directeur)". L'autorisation de définir ces drapeaux est limitée au directeur.
Utilisez les règles pour "envoyer un e-mail" (= action) au demandeur "Une fois que le contenu de type" Demande "est signalé comme refusé (par le directeur)" (= événement).
En cas de refus du superviseur, un e-mail est envoyé à un employé.
- Utilisez les règles pour "envoyer un e-mail" (= action) au demandeur "Une fois que le contenu de type" Demande "est signalé comme refusé (par le superviseur)" (= événement).
Donc, juste quelques choses de base Règles / Flag ...
Il n'inclut pas (encore) quoi que ce soit lié à Node Convert . Ce module ne doit être ajouté à ce mélange que si vous souhaitez affiner davantage ce qui précède avec des "champs" spécifiques que certains des participants au flux de travail ne devraient pas "voir" du tout (pour éviter d'avoir à utiliser des "autorisations de champ", ce qui pourrait être une alternative à cela.
Améliorations possibles
Bloc de formulaire
Je n'ai aucune expérience avec le module Form Block . Sur sa page de projet, il est indiqué " Permet la présentation des formulaires d'enregistrement des utilisateurs, de contact à l'échelle du site ou de création de nœuds dans des blocs. Ceci est particulièrement utile pour inclure des formulaires sur des panneaux.".
Il me semble que si vous utilisez des panneaux, il y a peut-être une certaine valeur ajoutée lors de l'utilisation de ce module. Cependant, je ne suis pas (encore) convaincu de la réelle valeur ajoutée de ce module.
Il y a cependant quelques choses qui me semblent être des drapeaux rouges (= j'y réfléchirais à deux fois avant d'utiliser ce module):
Où est la documentation?
En dehors de ce qu'il dit sur la page du projet, il n'y a (a) pas de documentation communautaire (du moins pas liée à la page du projet) et (b) un fichier readme.txt fourni avec le module, mais sans contenu "réel" .
Où est la version D7?
Il existe une version officielle disponible pour D6. Mais une version D7 n'existe qu'en tant qu'alfa 1, qui a plus d'un an. Et puis il y a déjà une version D8 en état bêta. Je ne sais pas ce qui arrive dans D8, mais pour D7 il semble y avoir quelque chose de mal. Y aura-t-il jamais une version officielle du D7? Néanmoins, en regardant les statistiques d'utilisation il y a beaucoup de sites D7. Près de 10 000 installations signalées pour cette version D7-alfa. Les sites 10K utilisant les modules ne peuvent pas se tromper, donc ce doit être quelque chose comme "cette version d'alfa1 est pratiquement une version officielle qui devrait être étiquetée comme ça".
Les puces ci-dessus ne sont que quelques-uns des critères que j'utilise souvent pour décider des modules contribués. Reportez-vous à la documentation de la communauté sur Maintenance Scorecards pour plus de détails. Voici l'intro à ce sujet (à partir de cette page):
... contient une liste de 23 critères (= 28-5) qui pourraient aider à évaluer la maintenance et le support des modules contribués. Ci-dessous est une tentative d'appliquer ces critères à chacun des modules de cartographie natifs ...
Évidemment, ces tableaux de bord sont liés aux "modules de cartographie", mais les mêmes critères sont applicables, à mon humble avis, lorsque vous devez décider entre plusieurs modules.
Haricot
Peut-être envisagez d'ajouter un autre module dans le domaine des blocs, en regardant le module Bean . Voici un devis sur sa page projet:
Considérez un Bean comme une méthode pour fournir de nouveaux types (par rapport au nœud, ce serait un type de contenu) qui fournit ensuite une interface d'ajout de contenu pour créer autant de blocs que vous le souhaitez (voir capture d'écran ci-dessous). Le contenu du bean peut ensuite être placé autour du site comme n'importe quel autre bloc.
Combiné avec les options disponibles pour accorder les autorisations Bean appropriées , il devrait vous donner beaucoup de flexibilité sur la façon dont vous souhaitez utiliser exactement ce (grand) module dans votre cas particulier. En prime, le module Bean fonctionne également très bien en combinaison avec les modules UUID et Intégration des fonctionnalités UUID . En plus de cela, après vous être familiarisé avec le module Bean, vous pouvez trouver d'autres cas dans votre site où vous souhaitez également utiliser le module Bean (ce qui compense en quelque sorte le fait que vous devez ajouter un autre module).
Tutoriels vidéos
Si vous n'êtes pas familier avec Rules , consultez les didacticiels vidéo Learn the Rules framework . Et/ou similaire ensemble de 8 tutoriels vidéo sur le module Flag .
Le didacticiel vidéo tutoriel du module Drupal Bean - utilisation de l'interface utilisateur d'administration Bean fournit une excellente introduction pour vraiment comprendre la puissance du module Bean , et le genre de choses que vous pouvez faire avec (en utilisant uniquement des techniques de construction de site, aucun codage personnalisé n'est impliqué). Il montre également comment le module Bean transforme les blocs Drupal en entités champables).