カテゴリー: SharePoint

開発・カスタマイズに利用する画像・CSS・JSファイルなどの格納先を「サイトのリソース ファイル」ライブラリに指定される事がよくあります。このライブラリはサイトを作成すると自動で作成されているのですが、「リソース」とは日本語で「資源・資産」なんて訳せると思うので、サイトのカスタマイズに利用する資源の格納先に選んでしまいがちでしょうか。

しかし、過去にも少し取り上げましたが、「サイトのリソース ファイル」ライブラリのそもそもの利用方法があり、それを考えるとカスタマイズファイルの格納先には向いていないのでは？と思います。

SharePoint 複数行テキスト列で画像・ビデオ・ファイルを挿入する際の「宛先ライブラリ」の初期値変更

「サイトのリソース ファイル」ライブラリとは、概ねページやアイテムに画像などを表示させる際のアップロード先と思って頂いて良いと思います。

SharePoint 2007 の頃はアイテムの複数行テキスト列に画像を表示したい場合は、先にどこかのライブラリに画像をアップロードし、URLを控えて、それを複数行テキスト列に指定して表示させていました。SharePoint 2010 からこの手間が楽になり、複数行テキスト列のリッチテキストエディタ内で、画像をアップロードしつつ表示させる事ができるようになりました。このアップロード先はサイト内のライブラリを指定できるのですが、その初期値で指定されているライブラリが「サイトのリソース ファイル」です。同じくビデオを表示させる際のアップロード先もそうです。

▼複数行テキスト列でコンピューターから画像を挿入すると

▼宛先ライブラリの初期値が「サイトのリソース ファイル」になっています。

▼新しい表示（モダンUI）のニュースページのヘッダー画像の追加も

▼アップロードする先は「サイトのリソース ファイル」になっています。

※しかも、新しい表示（モダンUI）のニュースページでは、宛先ライブラリの指定はできず「サイトのリソース ファイル」で固定のようです。

つまり、ここに開発・カスタマイズファイルを格納してしまうと、サイト運営開始してから上述のような方法で利用される画像・ビデオファイルと混在してしまいます。

「別に混在してもいいよ」って場合も、更に注意点としてアクセス権限があります。「サイトのリソース ファイル」ライブラリはデフォルトでは親となるサイトの権限を継承しています。つまりサイトに投稿権限以上あれば、ライブラリ内のフォルダーやファイルは編集・削除も可能です。それがなぜ注意点かというと…サイトの開発・カスタマイズに利用しているファイルを、特定多数の人達が編集・削除できてしまうという事です。

もちろんアクセス権限はフォルダー単位でも独立させて設定できますが、そこまでしてもサイトの開発・カスタマイズに利用しているファイルを「サイトのリソース ファイル」ライブラリに格納しなければいけない理由って逆にないと思います。

だとしたら、ゴチャゴチャしていなく権限も安全なライブラリに格納した方が良いのかなと思います。

• 専用のライブラリを作成する
• マスターページギャラリーやスタイルライブラリに格納する
• 専用のサイト（コレクション）を作成する
• 別のサーバーに格納する

などなど。それぞれの環境に合わせたやり方は色々ありますね。

もちろん、その上で「サイトのリソース ファイル」ライブラリを利用したい場合は、それもまた不正解ではなく正解なんだと思います。

SharePoint 2007 から何かとお世話になることの多い「コンテンツ エディター」Webパーツ。ただし、僕個人的にはこのWebパーツを本来の使い方である「リッチテキストコンテンツ…」として利用した事はあまりありません。SharePoint 2010 からはWikiページになって、コンテンツ エディター Webパーツを使わなくても、コンテンツエリア内に直接リッチテキストを作成する事ができてしまいますからね。（コチラの方がコンテンツ エディター Webパーツよりも色々制約がありますが…）

コンテンツ エディター Webパーツの利用の大半は、そのページに適用したいCSSファイルやJSファイルのリンクを埋め込む事。これで結構重宝しました。SharePoint 2013 からはこの役割を「スクリプト エディター」Webパーツも行えるので、コンテンツ エディター Webパーツの利用頻度は減ってきたような気がします。

その他で僕がコンテンツ エディター Webパーツを利用してきた中で、本題の「コンテンツへのリンク」をよく使っていました。これはライブラリにアップロードしたテキストファイルのURLを指定すると、テキストファイル内のテキストが表示される機能です。

▼このようなテキストファイルを作成します。文字コードはUTF-8で保存しましょう。

▼アクセス権限だけ気にしてどこでも良いのでライブラリにアップロードします。URLを控えましょう。

▼表示させたいページにコンテンツ エディター Webパーツを配置し、「コンテンツへのリンク」にURLを指定。

▼コンテンツ エディター Webパーツには、テキストファイル内のテキストが表示されます。

【注意】
▼文字コードはUTF-8にしてください。文字化けします。

う～ん、テキストファイルなのでプレーンテキストを表示するだけでしょ？コンテンツ エディター Webパーツの中に直接リッチテキストコンテンツとして入力した方が装飾できるので、今のところ特に「コンテンツへのリンク」のメリットがない。

直接コンテンツ エディター Webパーツの中にリッチテキストコンテンツとしてテキストを入力するのと何が違うかというと、サイトコレクション内で使いまわせてコンテンツが一元管理できる点です。（サイト内ではなくサイトコレクション内です。ただ、別サイトコレクションは指定するとエラーになってしまいます…残念。）

つまり、複数ページに同じテキストを表示させ、更新などの管理を全ページで一括で行いたい場合、「コンテンツへのリンク」を使えば、指定したテキストファイル内のテキストを変更すれば、一括で全ページが更新されるというわけです。

若干メリットが出てきました。

で、テキストファイルなのでプレーンテキストだけしか対応しないと思うじゃないですか。でも実はこのテキストファイル内にHTMLを記述すれば、コンテンツ エディター Webパーツにはソースが表示させるのではなく、ちゃんとレンダリングされて表示されます。

▼さっきのテキストファイル内をこんな感じでHTMLを記述して更新します。

▼このようにソースが表示されずに、ちゃんとレンダリングされます。

夢が広がってきました。

過去にこれを使った例としては、トップリンクバーやサイドリンクバーは利用せずに、複数ページのコンテンツエリア内に独自のナビゲーションを配置させるのに利用しました。

▼軽くナビゲーションを作ったテキストファイルです。CSSも対応されます。

上で紹介した同じ方法でライブラリにアップロードし、表示させたいページにコンテンツ エディター Webパーツを追加し、「コンテンツへのリンク」にURLを設定します。

▼このようにテキストファイルに記述したナビゲーションが表示されました。

4ページ作成し、同じ位置に同じ設定をします。（1ページ作成し、 SharePoint Designer でコピーしても可ですね。）

▼このように4ページに全て同じナビゲーションが表示されます。

これで、この4ページはこのナビゲーションで自由に遷移する事が可能です。更に一括管理できるメリットを試してみます。この状態でテキストファイルを更新してみましょう。

▼テキストファイルを更新しました。

▼テキストファイルを上書きアップロードすれば、同時に全てのページで更新が適用されます。

今回はデモなので4ページのみですが、ページの量が増えるほど、一括管理できるメリットが活きるのかなと思います。

こういう機能があるんだという事を知っておくと、何かの時に役立つかもしれないですね。

「サイトコレクションの管理者なのに、サイトの設定画面に表示されていないメニューがある！」

という問い合わせを過去に数回受けた事がありました。この場合、ほぼ100%このユーザーは「サイトコレクションの管理者」ではない事が原因です。

上長からの任命などで「このサイトコレクションの管理者になった」という役割名の意味の「サイトコレクションの管理者」と、SharePoint の設定上の「サイトコレクションの管理者」に追加されたユーザーでは大きく異なります。つまり、問い合わせしてきたユーザーの「サイトコレクションの管理者」とは、前者のただの役割名の意味だったという事です。

会社によって SharePoint の運営方針は異なりますが、中には「サイトコレクションの管理者」はIT部門以外のユーザーは追加しない方針もあるかと思います。この場合、いわゆるサイト管理者にはトップレベルサイトに対してフルコントロール権限を付与する形が多いかと思います。（もしくはオリジナルのアクセス許可レベル。）

トップレベルサイトに対してフルコントロール権限があれば、トップレベルサイトの様々な設定が可能で、更にサブサイトを作成する事も可能なので、サイトコレクション全体にフルコントロール権限が付与されたと思いますし、言葉通りとればそれは事実です。
そもそもアクセス権限（アクセス許可レベル）とは別に「サイトコレクションの管理者」という設定というか存在が SharePoint 上にあるという認識は、実際にサイトコレクションの管理者にならないとなかなか知る由もない事です。

▼このメニューは実際にサイトコレクションの管理者じゃないと表示されないので。

▼そしてサイトコレクションの管理者じゃないと表示されないサイトの設定のメニューはたくさんあります。

トップレベルサイトにフルコントロール権限が付与されているだけなのに、説明では「サイトコレクションにフルコントロール権限を付与しました」という若干曖昧な言い方をしてサイトコレクションを提供してしまうと、もらった方は最高権限をもらったと思ってしまい、その後ネットで検索した情報を元に設定しようと思ったらメニューがなかった…なんてストーリーがあり、冒頭の問い合わせにつながります。

わかりやすいかは置いといて（置いとくなって感じですが…）イメージ図を作ってみました。

▼サイトコレクションの管理者の設定範囲

• サイトコレクション内の全ての設定が可能です。
• サイトコレクションの管理者は、各サイトの権限設定に影響されません。

通常、ユーザーに何の権限を付与しないとURLからアクセスしてもエラーで閲覧すらできませんが、「サイトコレクションの管理者」に追加されたユーザーは、各サイトのアクセス権限を一切付与していなくても、全ての操作が行えます。

▼トップレベルサイトにフルコントロール権限を付与されたユーザーの設定範囲

画像右下の前提条件があった場合、

• サイトコレクションの設定は一切できません。
• トップレベルサイトの設定はできます。
• サブサイトBの設定もできます。
• 各サイトの権限設定に影響されるので、この例ではサブサイトAは設定どころか閲覧すらできない。

このように大きな違いがあります。

以上の事を考慮すると…
立場上の概念的な名称として、そのサイトコレクションを管理する人の事を「サイトコレクションの管理者」と呼ぶ事は非常に紛らわしく、例えば「サイトコレクションオーナー」とか設定上の名称と概念的な名称は差別化した方が、今後の様々な意思疎通を行う上で齟齬や認識違いが発生しないのかなと思います。