フォームコンポーネントに基づいてwebforms / entityformsでマルチステップ承認を実装する方法は？
Webform または Entityform のいずれかを使用してマルチステップ送信ワークフローを呼び出すことは可能ですか？ワークフローのシナリオは次のとおりです。
- 従業員がフォームを送信します
- 監督者は通知を受け取り、フォームを確認した後、フォームを承認するか、同じ提出の要求を拒否します。
- 承認されると、電子メール通知がDirectorに送信され、Directorが同じ提出を承認または不承認にします。
- 上司によって拒否された場合、メールが従業員に送信されます。
このシナリオには、同じリクエストに対する複数の役割による提出が含まれます。承認フィールドを従業員ロールに非表示にすることはできますが、通知目的のルールを介してWebフォーム承認フィールドコンポーネントにどのようにアクセスしますか？フォームの状態をどのようにフリーズしますか？
すべてのフォームコンポーネントが公開されているため、エンティティフォームを使用する必要がありますか？最後の手段として、forms_apiを使用して独自のソリューションを実装する場合があります。しかし、webformまたはentityformsを使用して可能かどうかを最初に知りたいと思います。
このワークフローの実装は、これらのモジュールの組み合わせ（および通常のコンテンツタイプ、「Webフォーム」のようなものは不要）を使用することで可能です。
これらの4つのモジュールを一緒に使用する方法の例（および詳細）については、「 匿名の訪問者にコンテンツの送信を許可するにはどうすればよいですか？ 」に関する質問の私の回答を参照してください（この質問はバリエーションのようです）その質問の）。
以下は、同様のアプローチでワークフローを実装するための詳細です。
従業員がフォームを送信します
従業員は、コンテンツタイプ（たとえば）のノードを作成し、「リクエスト」（ コンテンツアクセス を使用して、「このようなタイプの作成を許可されているロールに、あらゆるタイプのリクエストがある場合、複数のコンテンツタイプに拡張されます）。
スーパーバイザーは通知を受け取り、フォームを確認した後、フォームを承認するか、同じ送信の要求を拒否します。
ルールを使用して、「タイプ「リクエスト」のコンテンツが保存された後」（=イベント）にスーパーバイザーに「電子メールを送信する」（=アクション）。スーパーバイザー用の（カスタム）電子メールに、リクエストに関連するすべての詳細を含めます（ルールで使用できるさまざまなデータに応じて）。確認するノードのURLなど。
リクエスタがリクエストデータを変更できないようにするには（レビュープロセスが未処理の場合）、同じ（前の）ルールに追加のアクションを追加して、リクエストへのアクセスを更新します（リクエスタに対してのみ読み取りを行うようにします）。
Flag モジュールを使用して、スーパーバイザーが「承認済み（スーパーバイザーによる）」または「拒否された（スーパーバイザーによる）」（拒否？）などのフラグで送信済みノードをマークできるようにします。これらのフラグを設定する許可は、スーパーバイザーに制限されています。
承認されると、電子メール通知がDirectorに送信され、Directorが同じ提出を承認または不承認にします。
ルールを（再度）使用して、「ノードに「承認済み（スーパーバイザ）」のフラグが付けられた後」（=イベント）になると、同様の「電子メールの送信」（=アクション）がDirectorに発生します。ディレクターの（カスタム）電子メールに、リクエストに関連するすべての詳細を含めます（ルールで使用できるさまざまなデータによって異なります）。確認するノードのURLなど。
Flag モジュールを（再度）使用して、送信されたノードに「承認済み（Directorによる）」または「拒否された（Directorによる）」などのフラグを付けてノードをマークできるようにします。これらのフラグを設定する権限は、ディレクターに制限されています。
ルールを使用してリクエスタに「電子メールを送信する」（=アクション）「タイプ「リクエスト」のコンテンツが拒否された（フラグによって）フラグが付けられた後」（=イベント）。
上司によって拒否された場合、メールが従業員に送信されます。
- ルールを使用してリクエスタに「電子メールを送信する」（=アクション）「タイプ「リクエスト」のコンテンツが拒否された（スーパーバイザによって）フラグが付けられた後」（=イベント）。
したがって、いくつかの基本的な ルール / フラグ もの...
Node Convert に関連するものは（まだ）含まれていません。このモジュールをこのミックスに追加する必要があるのは、ワークフローの参加者の一部がまったく「見る」べきではない特定の「フィールド」で上記をさらに細かくしたい場合のみです（「フィールド権限」を使用する必要がないようにするため、それに代わるものかもしれません。
可能な拡張
フォームブロック
Form Block モジュールの経験はありません。そのプロジェクトページには、「ユーザー登録、サイト全体の連絡先、またはノード作成フォームをブロックで表示できるようにします。これは、パネルにフォームを含める場合に特に便利です。」。
パネルを使用している場合、このモジュールを使用すると、おそらく付加価値が生じるようです。ただし、このモジュールの真の付加価値について（まだ）確信はありません。
レッドフラグのように思える点がいくつかあります（=そのモジュールを使用する前に2回考えます）。
ドキュメントはどこにありますか？
プロジェクトページでの説明とは別に、（a）コミュニティのドキュメント（少なくともプロジェクトページからリンクされていない）と（b）モジュールに付属するreadme.txtはありますが、「実際の」コンテンツはありません。
D7リリースはどこにありますか？
D6の公式リリースがあります。しかし、D7バージョンは1年以上前のアルファ1としてのみ存在します。そして、すでにベータ版のD8バージョンがあります。 D8で何が起きるかはわかりませんが、D7には何か問題があるようです。 D7の公式バージョンはありますか？それでも、 使用統計 を見ると、D7サイトがたくさんあります。そのD7-アルファバージョンの1万件近くのインストールが報告されています。モジュールを使用する10Kサイトは間違いないので、「そのalfa1バージョンは事実上、このようにタグ付けする必要がある公式リリースです」のようなものでなければなりません。
上記の箇条書きは、寄稿されたモジュールを決定するために私がよく使用する基準のほんの一部です。詳細については、コミュニティのドキュメントで Maintenance Scorecards を参照してください。これについて（そのページから）の紹介です：
...提供されたモジュールの保守とサポートの評価に役立つ23の基準（= 28-5）のリストが含まれています。以下は、これらの基準を各ネイティブチャートモジュールに適用する試みです...
もちろん、これらのスコアカードは「チャーティングモジュール」に関連していますが、複数のモジュール間で決定する必要がある場合でも、同じ基準が適用されます。
豆
Bean モジュールを見て、ブロックの領域に別のモジュールを追加することを検討してください。ここにそのプロジェクトページについての引用があります：
Beanを新しいタイプを提供するメソッドと考えてください（ノードと比較すると、これはコンテンツタイプになります）。必要な数のブロックを作成するための追加コンテンツインターフェースを提供します（下のスクリーンショットを参照）。 Beanのコンテンツは、他のブロックと同じようにサイトの周りに配置できます。
適切なBeanパーミッションを付与するために利用可能なオプションと組み合わせると、この（素晴らしい）モジュールをどのように使用したいかについて、多くの柔軟性が得られますあなたの特定のケースでは。おまけとして、Beanモジュールは [〜＃〜] uuid [〜＃〜] および ID Features Integration モジュールと組み合わせて使用することもできます。その上、Beanモジュールに慣れると、サイトでBeanモジュールも使用したい場合があるかもしれません（別のモジュールを追加する必要があるという事実を何らかの形で補償します）。
ビデオチュートリアル
ルール に慣れていない場合は、ビデオチュートリアル ルールフレームワークを学ぶ を確認してください。または同様の 8ビデオチュートリアルのセットFlag モジュールについて。
ビデオチュートリアル Drupal Beanモジュールチュートリアル-Bean管理UIの使用 は、 Bean モジュールの能力と、それを使用してできることの種類を実際に理解するための優れた入門書を提供します（サイト構築手法のみを使用し、カスタムコーディングは不要）。また、BeanモジュールがDrupalブロックをフィールド化可能なエンティティに変換する方法も示しています。