部署単位の記事発行ワークフローの実現可能性を検証した

Drupal8のCore機能とGroupモジュールを利用して部署単位の記事発行ワークフローの実現可能性を検証した。

背景

コンテンツの執筆、編集・承認、発行を部署単位で行いたいというニーズはしばしばある。

部署単位のコンテンツ管理のためにはGroupモジュールがある。Groupモジュールはユーザーやコンテンツを取りまとめるためのContributionモジュールで、執筆時点での最新版は2018年2月5日のgroup 8.x-1.0-rc2である。最後にrc2とあるようにまだ安定版ではないが、既に多くの実運用サイトでも採用されている。現実世界では、例えば記事の執筆者は移動や退職でいなくなることは珍しくないから、執筆者は執筆者として管理するとしても、記事の管理は部署で責任を持つのが合理的な事はままある。本格的な記事運用を考えると組織をどうモデル化するかは極めて重要なテーマになる。逆から見れば、Groupモジュールの出来が対応可能なモデルの範囲を決めてしまうとも言える。当然難易度は高く2017年6月にrc1が出ているのに1年経過してもまだ正式版になっていない。アクセス権に関わるモジュールだけに検証も難しい。

ワークフローは現在のDrupalのリリース8.5.4では、workflowsとContent Moderationが標準で組み込まれていて、オンにすれば追加モジュールなく実装できる。

Drupal7では、ContributionモジュールのWorkbench Moderationが定番モジュールとして利用されていたが、そのプロジェクトページを見ると、Drupal8で新たに取り組むなら、Workbench Moderationを使わずにCoreモジュールのContent Moderationモジュールを使うべきと注記されている。このContent ModerationがStableになったのは2018年3月リリースの8.5である（執筆時点の最新版は2018年6月7日リリースの8.5.4）。

Drupal8では、Content Moderationに先立ち、2017年10月リリースの8.4でWorkflow(workflows)がStableになって基盤は整っていた。複数のworkflow関連モジュールをCoreで支えようという挑戦で、前述のWorkbench ModerationモジュールもD8ではworkflowsのアプリケーションになっている。Workflowが対象にするのはContentだけではなく、ユーザー等も対象になる。D8の立ち上がりはまだまだだが、環境が整うにつれて強力なプラットホームになりつつある。

検証のシナリオ

部署が２つ。部署A、部署B。

従業員の職位は執筆者と編集者。部署Aには執筆者2名（memberA1,memberA2）、編集者2名(managerA1,managerA2)、部署Bにはそれぞれ1名(memberB1,managerB1)

記事（Articleコンテンツタイプ）は、部署毎に執筆者または編集者がDraftを作成し、編集者が公開（Publish）、公開終了(Archive)操作を行えることとする。

執筆者、編集者は自部署の記事を公開状態のまま改定案Draftを作成できる事とする。

他部署の執筆者はDraftの内容を見る事ができない。

他部署の編集者は公開、公開終了操作を行えない。

確認手順

1. memberA1がDraftを作成
2. 公開されていない事を非ログイン状態で確認
3. managerA1がDraftを公開
4. 記事が公開されている事を確認
5. memberA2が公開されている記事に追記（自コンテンツでないものの編集可能性確認）
6. 公開されている記事が変更されていない事を非ログイン状態で確認
7. managerB1が追記したDraftを編集できない事を確認

実際のテストでは、もっと細かくチェックするべきであるが、コンセプトの確認のため上記のチェックで一旦良しとする事とする。

検証環境

今回検証に用いた環境は、メモリ1Gでディスク20Gの環境下でDrupal 8.5.4/PHP 7.2.5で動かしている。contributionモジュールとしては、admin_toolbar, content_moderation_scheduled_updates ×, inline_entity_form ×, smtp, content_moderation_edit_notify ×, group, scheduled_updates ×をcomposerを導入（×は有効にしていない）。ちなみに、Drupal自身の導入には、

composer create-project drupal-composer/drupal-project:8.x-dev XXXX --stability dev --no-interaction

を用いた。もちろん、coreのContent Moderationは有効化している。

検証環境の設定

プレーンインストールの状況で、新たなロールを2つ作成、原稿を執筆する権限と編集・公開を司る役割である。通常権限の設定は、コンテンツの編集権を規定するものであるが、今回のモデルでは、コンテンツの編集権はGroupモジュールに任せるため、この権限設定はワークフローを機能させるためのものとなる。

管理者以外のユーザー登録は6名、部署がAとBの2部署、部署Aには執筆者2名、編集者2名、部署Bには執筆者1名、編集者1名を登録した。

次いで、group typeを定義する。キャプチャは定義後になっている。定義時には作成者に管理者権限を与えておく。これらの設定は、サイトの管理者権限（今回はhagi）で実行する。

部署ごとのRole（部署内権限）は管理者、執筆者、編集者とした。管理者は、部署へのユーザー登録、部署内権限を設定できる。編集者は記事の編集権はあるが、ユーザーを組織に所属させるような管理権限は有しない。

次に、管理の対象となるコンテンツタイプを設定する。当初は基本ページと同じように「未インストール」となっているので、インストールボタンを押してグループの管理対象として登録する。なお、簡略化のために「Use 2-step wizard when creating a new コンテンツ entity within a 組織 group」はoffにした。実装上、コンテンツそのものと、Groupエンティティの間に関連付けEntityが作成され、そこに属性を持たせることができるが、検証のためには不要と考えた。

次に、組織内権限を設定する。ここがGroup設定の肝である。

記事コンテンツに対して、執筆者が新しいコンテンツを作れるようにして、自分のコンテンツは削除できるようにし、組織内の任意のコンテンツを修正可能にする。ワークフローとの絡みで、執筆者にも「View unpublished コンテンツ」権限を与えなければいけない。「View コンテンツ」を匿名までオンにする事で一般公開ができ、Outsiderまでで留めれば、部署外の社員までの公開設定を意味することになる。

次はワークフローの設定。Content Moderationがオンになっていると、ワークフローの設定画面が現れ「このワークフローの適用先」を設定できるようになる。最初は「なし」になっているので、「記事」を選択する。

最後の設定は、ユーザーの権限である。執筆者と編集者にワークフローの適当な権限を与える。

これで、準備完了である。一点注意したいのは、上記の「Requires the "View any unpublished content" or "View own unpublished content" permission」で、ワークフローで公開前の最新バージョンを表示できないと、同僚が書いた記事を修正することができない。一方で、これを有効にすると、他部署の発行前のリビジョンが読めてしまうケースがある。groupモジュールでどう扱うかがDrupal.orgで話題となっている。

検証作業

memberA1がDraftを作成

memberA1でログインすると、何もないサイトが上がる。コンテンツを追加リンクもない。通常のユーザー権限で編集者にも執筆者にもどのコンテンツの追加権限も与えていないので当然である。しかしながら、

/group/1/content/create/group_node%3Aarticle

を踏むと記事を作ることができる。memberA1は組織Aのメンバーで、組織Aの記事作成権限があるからである。

これに適当な値を与えて、保存することはできるが、執筆者権限ではDraftしか選べない。

これで保存すると以下のようにunpublishedのピンク色の記事が作成される。

 

managerA1がDraftを公開

ログアウトすると、まだ記事は作成されていない（公開されていない事を非ログイン状態で確認）。次いでmanagerA1でログインしても、フロントページに変化はない。しかしながら、記事自身は作成されているので、node番号を指定して

/node/2

アクセスすると記事がUnpublishedで存在しているのが分かる。

ワークフローの設定で、Moderation stateがあるので、Applyボタンを押下すると記事が公開される。再びログアウトして見ると記事ができているのが確認できる。

memberA2が公開されている記事に追記（自コンテンツでないものの編集可能性確認）

次いで、部署Aの別メンバーmemberA2でログインしてみる。その上で、最初の投稿を選択すると編集タブがあるので、記事に追記して保存する。

保存後はunpublishの背景がでる。

ログアウトすると、記事は編集前のままである。

managerB1が追記したDraftを編集できない事を確認

次いで、部署Bの編集者(managerB1)でログインして、最初の投稿を選択するとリビジョンタブがあるので選択する。

現在のリビジョンは公開済みの記事になっているのが分かり、その後memberA2が修正しているが、また公開されていない事が分かる。しかし、部署が異なるので編集はできない。

これで複数部署でワークフローが予想通りに機能しているのが確認できた。

おわりに

今回の検証を実施していて、Groupモジュールとは何かを改めて考えさせられた。

Groupモジュールの無い実装では、ユーザー権限は全体で一種類しか設定できないので、例えば同様のコンテンツタイプを作成し、ユーザー権限も部署ごとに類似のものを作成して管理単位を分けるといった回避策を取る必要があった。しかし、一度そういう回避策を取ると、当該のコンテンツタイプにフィールドを追加するような場合に複製した分だけ作業を繰り返す必要が出る等様々な不具合が出てサイトの品質低下を招いてしまう。

Groupのある実装の場合は、同じコンテンツタイプを複数の組織単位で管理できるようになるので事前に管理モデルを作ればすっきりとした管理が可能になる。ニュースリリースのようなコンテンツタイプは、基本的に全社で一様で、最後の公開権限を広報部に集約するかしないかなど組織のポリシーに従って実装すれば良い。

一方、ワークフローのContent Moderationは、まだGroupに対応していないので、全体のユーザー権限で、執筆者権限、編集者権限を定義しなければならなかった。ワークフローの状態変更権限は、できれば部門管理者に委譲したい管理機能なので、Group対応できればその方が良いだろう。ワークフロー＋Content ModerationもGroupもコンテンツに対するアクセス権制御なので結構難しそうだ。

今のGroupモジュールがそのまま育つかどうかは分からないが、やがて汎用的なアクセス制御コンポーネントとしてCoreに取り込まれていくのが良さそうに見える。

最初は、Publish属性のオン、オフで公開を制御するのが合理的だったとしても、複雑なビジネスシーンに対応するためにはステータス制御に進化せざるを得ない。workflowに関しては、一山を乗り越えたように思うが、次はGroupとRulesの成熟に期待したい。まだまだ、これからの成長が楽しみなプラットホームだと改めて感じた次第である。