ツリー式ディスカッション掲示板を Infopath でつくってみた ver1

SharePoint には、標準でスレッド式の「ディスカッション掲示板」が用意されています。しかし、残念ながら、ウチのユーザにはいまいち不評なのです。

長年ノーツを利用してきたせいでしょうか？
より「ノーツライク」なツリー構造の掲示板をユーザから要望されます。

そもそも、ウチの会社には「イントラネット上で討議する」という文化があまりありません。
ノーツの階層表示も「ディスカッション」というよりも、むしろ、元情報に対する関連性を示す手段、として利用されていました。そういう意味でも、スレッド式よりツリー式が合理的なのでしょう。

また、更にそもそもですが、SharePoint には未読既読を区別する機能がありません。
これもユーザに不評なポイントです。

まあ、大抵のケースでは、ユーザに SharePoint の機能制約を説明して、「ごめんなさい」で標準機能の枠内で留めてもらっているのですが…。
中には「業務上絶対に必要な要件」として、この「ツリー式」と「既読未読」を求められる場合もあります。
そう言われると、システム部門的には、なんとかせざるを得ません。
システム部門の立場は弱いのです（苦笑）

しかし、その都度、専用システム化していたのでは、予算がいくらあっても足りません。
そこで、この要件を Infopath を使って実現してみました。
…かなり無理矢理ですけどね（汗）

※あ、いけね。作成日列を入れ忘れた…

サンプルフォームはこちら：
Tree Discussion Using Infopath By SharepointMANIACS

使い方は以下の通りです。

1.フォームを適当な MOSS サイトに発行してください。

2.デザインモードで、3つのデータ接続の接続先 URL を書換えてください。
　GetNo → 発行したライブラリの URL
　GetUserProfileByName → http://server/_vti_bin/userprofileservice.asmx?WSDL
　Save → 発行したライブラリの URL

3.デザインモードで、Bunrui フィールドの選択肢を適当に設定して下さい。
　個人的には、同じサイト内にカスタムリストを作成して、それをマスタにすることをお勧めします。

4.ライブラリに列 Sum を作成します。
　集計値（数値）で [No]+[No2]+[No3]+[No4]+[No5]+[No6]
　ビューに表示させる必要はありません。

5.既定のビューを編集します。
　表示する列は「種類」「作成日」「名前（編集メニュー…）」「分類」のみ。
　並べ替え：最優先する列：No の降順
　並べ替え：2番目に優先する列：Sum の昇順
　表示件数は多め（500件程度）に設定します。
　※これは、データ接続 GetNo の取得範囲が、デフォルトビューの影響を受けるためです。
　※レスポンス的に不安でしたら、別に件数の少ないビューを作成して、Webパーツからそのビューにリンクさせるとよいと思います。

6.新規ビューを作成します。
　名前：「一覧表示」※任意
　表示する列は「種類」「作成日時」「件名（一覧表示用）」「作成者」
　並べ替え：最優先する列：作成日時の降順
　※このステップは省略してもかまいません。

7.ワークフローを作成します。
　SharePoint Designer で、このライブラリにワークフローを設定します。
　設定内容は以下の通りです。
　・新規/更新時に起動
　・条件 Del=1 アクション 削除
　・条件 Sendmail=1 アクション メール送信
　メールの宛先は、SharePointGroup にメールアドレスを設定して宛先にすると良いと思います。
　同じ SPG をアクセス権設定にも利用すれば、利用者全員＝宛先になります。
　本文には「エンコードされた絶対URL」を追加しておくと良いでしょう。

なお、このフォームは名前と所属を取得するのに、MOSS 標準の Web サービスを利用しています。
このため、WSS では動作しません。
しかし、この部分の設計を削除して、ユーザ名と所属を手入力にすれば WSS でも使える筈です。

設計的には、以前ご紹介した簡易自動採番を応用しています。
データ接続で No の値を取得し、その最大値に +n しています。
親文書は No を +1
子文書は No2 を +0.01
孫文書は No3 を +0.001 …
という具合に、数値を加算し、それを合計してソート順にしています。

このフォームでは最大5階層までしか用意していませんが、上記の要領で設計を変更すれば何階層にでも増やせます。
また、数値を二桁とびにしているため、同じ文書につけられる子文書は 99 文書までです。100 文書目は正しい位置に表示されません。これも設計を三桁とびにすれば 999 文書まで対応できます。

保存時は タイトル＋ユーザ名＋作成日時秒 で一意のファイル名を生成しています。
このため、後からタイトルを変更すると別ファイルとして保存されてしまいます。
そこで、保存時にタイトルに変更があったかどうかを判定し、変更があった場合、以前のファイルには削除フラグに 1 を立て、ワークフローに削除させています。

既読未読については、ブラウザのリンク色で判断できます。
ただ、SharePoint デフォルトのリンク色は非常～に判りづらいです。
CSS を編集してもいいかもしれません。
こちらのスタイルシート も参考にしてみてください。
ただ、そもそもメールに送っているので、既読未読はそちらで管理してもらう仕様です。

とりあえずこれで Ver1 は完成！
こうした方が便利だよ～等、ご意見ご感想がありましたら、ぜひコメントにお寄せ頂けると嬉しいです。

SharePoint フォームライブラリと連動した Infopath による自動採番（簡易）