Art-Break Tech Blog : Taichi Nakamura

SharePointでは何をする・させるにしても権限付与の作業が必要ですよね。ユーザーに直接アクセス許可を付与したり、SharePointグループにユーザーを追加したり。ユーザーだけでなくセキュリティグループなどを追加したり。

その中の注意点は色々ありますが、今回注目する点は招待状メールの送信機能です。文字通り、権限が付与されると該当ユーザーに招待状メールが届く機能ですが、権限付与画面で送信するかしないかのチェックボックスがあります。初期値はチェックされた状態、つまり招待状メールが送信される状態です。これがなかなか怖い。

TPOで送信するかしないかをチェックボックスで選べば良いだけなのですが、使い方を間違えるとスパムメール的にもなってしまいますし、管理者に問い合わせが殺到するような事にもなりかねないです。初期値がチェックされた状態なので、ウッカリも多いです。

これ、SharePoint2007では、付与する前に目に見えるところにチェックボックスがあったんですよね（SharePoint2010もそうだったような気がしますが、記憶が…）。試した事がないのでわからないけど、「NT AUTHORITY\Authenticated Users」に権限を付与する際に、このチェックボックスがチェックされた状態で権限を付与したら…いわゆる全従業員にメールが送信されてしまうんでしょうかね。そしたら従業員数が多い会社ほど事故ですよね。怖いんでいつもこの作業をする場合は慎重にチェックが外れている事を確認して付与していました。

で、これは個人的は元に戻してもらいたいと思っているのですが、SharePoint2013ではこのチェックボックスがかなり気がつかないところにあるんですよね。というより隠されているんです。SharePoint2013に触れはじめた時は、メール招待状の機能自体がなくなったのかな？と思うくらい。でも、まだ存在するんですよね。しかもチェックされた状態は変わらず、余計事故が起きやすい状態で。

具体的には左下にひっそりと「オプションの表示」というテキストがあり、これがリンクテキストだという事すらなかなか気がつかず、これをクリックすると展開され、その中にチェックボックスがあるんですよね。

わざわざ、初期値がチェックされた状態で。これはトラップ？？と思うくらい。

さて、それではどうしたら少しでも事故やトラブルが防げるのか？ググると同じように初期値がチェックされた状態を危惧する声もあり、初期値ではチェックが外れているように設定で変更できないか？という問い合わせもあり、サイトコレクションの設定やサーバーの全体管理からは変更できず、サーバー内のとあるファイルをイジる解決方法があるのですが、Microsoftのサポート対象外になってしまうという点からも、ちょっと厳しいのではと思います。

あとは必殺「運用でカバー」ですよね。

まずは、利用者に招待状メールを周知させる方法。つまり、送信されてしまった後を考える事。そうすれば少なくともサーバー管理者への問い合わせは減るのかなと思いますが、若干ネガティブな対策です。

次に、アクセス権限を設定できるサイト管理者などへの教育・周知という方法。つまり、送信される前を考える事。ただし、サイト管理者が多いほど、ヒューマンエラーの確率が増えますね。ホント、ウッカリ失念してしまいがちなので。

次に、アクセス権限の設定はサーバー管理者が掌握する方法。つまり、権限管理自体を特定多数（不特定多数）に管理させない事。実際にアクセス権限の問題はかなり多岐に渡るトラブルや問題にもなるので、サイト管理者にアクセス権限の設定ができないアクセス許可レベルを付与している会社も、少なくはないと思います。これにより一極集中してしまったサーバー管理者の作業は大変になりますが、より把握している者が作業をすることにより、ヒューマンエラーの確率はサイト管理者にアクセス権限管理を委譲するよりは、減ると思います。

Microsoftのサポート対象外になってしまっても構わない場合は、設定レベルでチェックを初期値では外す方法が理想なのかもしれないです。（サーバーの全体管理やサイトコレクションの管理で容易に設定できれば良いのですけどね。）それ以外の場合は、各環境に合わせ、上述のようないわゆる運用でカバーをしていくしかないっぽいです。

ちなみに僕は今までおよそ何千何万回も設定をしてきましたが、一度もこれで事故やクレームはありませんでした。実際運営していると招待状メールが必要な事は全くありませんでした。例えばとある部署が自部署のサイトを公開する際には、だいたいサイト管理者か部署の部長さんあたりが自分から部内や周知したい人たちにメールをしたり、社内ポータルの掲示板に掲載したりする場合がほとんどでしたからね。

なので、とにかくチェックを外すクセを徹底的につけていました。

【1】「選択肢」で複数選択が可能なチェックボックス型で列を作成します。

【2】適当にアイテムを作ります。

【3】この「カテゴリ」という選択肢列でビューでグループ化をさせたくても、選択できません。

つまり、チェックボックスの選択肢列はグループ化ができない仕様です。

じゃ、ひねくれてこんな検証を…

【4】作成した「カテゴリ」列を編集でラジオボタンに変更します。

【5】投稿済みアイテムはすでに値は落ちているので、ラジオボタンだけど「A;B」という現象が。

【6】この状態だとラジオボタンなのでビューのグループ化で「カテゴリ」列は選択可能になります。

【7】結果

このスクショだけを見ると、チェックボックスの選択肢列はグループ化ができているように見えます。しかし、実態はすでにラジオボタンに設定変更をしているので、今後追加されるアイテムは複数選択できません。

じゃ、

【8】この状態で再度チェックボックスにすると？

【9】なんか壊れた！！！

【10】この状態でビューのグループ化を見るとグループ化されていない事になっています。

つまり、結局のところ、チェックボックスの選択肢列はグループ化ができないという結果でした。

■内部名の文字数の上限

長い列名を作成した場合でも内部名の長さは一定の長さから変わらなかったので、ちょっと検証してみました。

「内部名テスト」という列名で列を作成すると、内部名は以下のとおり。
_x5185__x90e8__x540d__x30c6__x30

内部名の場合、「_x****_」が一塊なので、

内＝_x5185_
部＝_x90e8_
名＝_x540d_
テ＝_x30c6_
ス＝_x30
ト＝

スの途中で切れているのでやはり上限があるようです。数えたところ、内部名の文字数の上限は32文字でした。ところが、厳密には違うようです。

【検証】

「test（4文字）」×8個＝32文字で上限ちょうどの列を作成します。同じリストに「test」のかたまりを更にひとつずつ追加した列を作ってみます。内部名は32文字で切られるので、このままだと同じ内部名ができあがってしまうと思いますが、内部名はユニークなのでどのような挙動になるでしょうか。

以下、
「列名」
「内部名」

testtesttesttesttesttesttesttest
testtesttesttesttesttesttesttest

testtesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest0

testtesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest1

testtesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest2

testtesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest3

testtesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest4

testtesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest5

testtesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest6

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest7

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest8

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest9

testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest
testtesttesttesttesttesttesttest10

面倒くさかったけど検証終わりました。内部名が同じになってしまうと、自動でオシリに0から数字が振られるようです。10個目はどうだろうと思ったらオシリが2桁に増えました。100個列を作るのは時間がもったいないのでやめますが、この法則だと100個目はオシリが3桁になるんでしょうかね。（列が100個とか運営上は非現実的ですが。）

まとめると、内部名は文字列としては32文字が上限。同じ内部名になると33文字目から0から連番が振られる。

ここまで調べて思ったこと。
この情報、そんなに必要じゃないので時間の無駄だったかも。

SharePointのアプリは大別するとリストとライブラリの2種類ですね。で、色々な種類のリストやライブラリがあるわけですが、リストに関しては、いわゆる通達や連絡など掲示板的な利用目的の場合、カスタムリストを使うべきか？お知らせリストを使うべきか？というところで迷う事があると思います。

僕の場合はずっとお知らせリストを使っていました。理由は受信メール機能です。

オンプレのSharePoint2007を長いこと使っていたのですが、オンプレのSharePointにはメールでアイテムを投稿できる受信メール機能があり、これはお知らせリストだけの機能でカスタムリストには加えることのできない機能でした。
この機能、メールでアイテムを投稿できると知ると結構使う人が多かったんです。例えばメーリングリストのtoの中に受信メール用アドレスを突っ込めば、メールのバックナンバーが自然に作れるような使い方とか。
後で使いたいと言われた時に即対応できるようにお知らせリストばかりを使っていて、カスタムリストはほとんど使っていませんでした。

つい最近まで知らなかったのが、この受信メール機能はオンプレだけの機能で、SharePoint Onlineでは使えないようですね。お知らせリストにこだわる理由がなくなりました。

逆にお知らせリストが微妙なのが「有効期限」列の存在があります。カスタムリストはデフォルトでタイトル列のみですが（「更新者」列などは除いて）、お知らせリストには「本文」列と「有効期限」列がリスト作成時にすでに存在します。「本文」は大抵利用する列なので問題ないとして、「有効期限」列ですよ。
この「有効期限」列は、非常に微妙なんですよね。普通に考えたらここに日付を入れたら、期限が切れたアイテムは削除されるのかな？と思うじゃないですか。でもいつまで経っても削除されないんですよね。この列はただの日付を入力する列なんですよ。特別なにかアクションがあるわけじゃないんです。どこかで聞いた話では、有効期限列は、この列を利用して、例えばビューのフィルターで非表示にするなどご自由にお使いください的な意味だとか。もちろん情報管理ポリシーで設定すれば期限切れで削除したりもできますが。

「有効期限」列の厄介なのはこの列を削除できない事。

列の編集に削除ボタンがないんですよ。有効期限列があればユーザーは有効期限があると思うし、ここに日付を追加してしまうので、この列が機能していないのに存在するのは良くないですよね。

対処法はあります。リストの詳細設定でコンテンツタイプの管理を許可して、お知らせコンテンツタイプの設定から有効期限列を「非表示」にすれば、削除はされないけど、削除されたようなものにはなります。

▼お知らせコンテンツタイプの設定から有効期限を非表示に

▼有効期限列は削除はされないけど非表示になります。投稿画面で非表示になっているということは、利用されないので削除みたいなものかと思います。

とはいえ、いちいちこんな設定をするのは面倒ですよね。

なので、オンプレで受信メール機能が利用できる環境なら、上述のメリット・デメリットを考慮して使い分ける必要がありますが、SharePoint Onlineであれば、個人的には何も考えずにカスタムリストから作る事になるかな。