SharePoint :リストのアイテムに画像を挿入させるもう一つの方法(宛先ライブラリの権限が不足している場合)

SharePoint で組織の通達・連絡をお知らせリストなどリストを利用している場合、中には画像を本文内に表示させたい場合もよく出てくると思います。その場合、通常の方法ならリッチテキストエディタ内で画像の挿入を行うのですが、場合によってそれができない環境もあります。その場合のもう一つの方法の紹介をします。

まずは通常の画像の挿入方法のおさらい。

▼リッチテキストエディタのリボンタブ「挿入」→「画像」→「コンピューターから」

▼ダイアログで画像ファイルを選択

参考までに、宛先ライブラリはデフォルトで「サイトのリソース ファイル」が選択されていますが、ここは変更が可能です。 過去記事を以下に紹介します。

SharePoint : サイトの開発・カスタマイズ用ファイルを「サイトのリソース ファイル」ライブラリに保管するのは微妙かも

▼リストのアイテム内に画像が挿入されます

▼リッチテキストエディタの編集を終えるとアイテム編集パネルへ。表示されています。

このようにしてリストのアイテムの本文に画像を表示することができますが、この挿入方法は(ユーザーは意識をせずに)内部的には以下の操作がされています。

  1. 宛先ライブラリで指定したライブラリ(サイトのリソース ライブラリ)に画像をアップロード。
  2. アップロードされた画像のURLを指定してリストのアイテムの本文に画像を挿入。

▼なのでこのように「サイトのリソース ライブラリ」に画像がアップロードされています。

過去、SharePoint 2007 ではリッチテキストエディタからこのように画像をアップロードできなかったので、わざわざ先にライブラリに画像をアップロードした後に、画像ファイルのURLをコピーして、リッチテキストエディタに貼り付けたものです。 SharePoint 2010 からは、このようにそれを意識せずにリストのリッチテキストエディタ内で操作が完結できるようになって便利だなと思ったものです。

ただし、上述の通り宛先ライブラリに画像をアップロードするという操作が内部的にあるが故に、この方法では画像を挿入できない場合があります。その原因はライブラリのアクセス権限です。

特に社内ポータルサイトとなるとアクセス権限が厳しく設定されている場合が多いです。サイト管理者以外は基本的に閲覧のみで、投稿が必要なリストのみ必要なユーザーに投稿権限を付与する、など。

その場合、サイト全体は閲覧権限で、通達・連絡用リストのみ投稿権限が付与されたユーザーで、上述の通常の画像挿入方法を試してみると、できない事がわかります。

▼リッチテキストエディタのリボンタブ「挿入」→「画像」→「コンピューターから」をクリックすると、このようにダイアログ内でエラーが。

「予期しないエラーが発生しました。」と記載がありますが、つまりこれはこのサイト内でアップロードできる権限のあるライブラリが一つもないという事です。

過去にこのような事例は経験してきました。「サイトのリソース ライブラリ」にも投稿権限を付与してあげれば良いのですが、環境によってはルールでNGとしている場合もあります。 画像の挿入はあきらめてもらっているか、なんと別途イントラサイト内にサーバーを立てて、その中に画像をアップしているケースも!

そんな場合に、もう一つの画像表示方法があります。特に目新しい方法でもなくカスタマイズも必要ないです。「添付ファイル」を利用する方法です。

▼まず添付ファイルに表示させたい画像を追加して、投稿してしまいます。

※この時点で本文は画像挿入以外の文章入力などを済ませ、その他の列の設定も済ませた状態がベストです。

▼投稿後に添付ファイルを表示し、URLをコピーします。

▼対象のアイテムを編集し、リッチテキストエディタの「挿入」タブ→「画像」→「アドレスから」

▼ダイアログのアドレスに先ほどコピーしたURLをペースト

▼すると画像が挿入されます。

▼リッチテキストエディタを閉じてもこの通り、本文に表示されます。

つまり、画像のアップロード先を宛先ライブラリではなく自らの添付ファイルにしただけです。

注意点としては、リストのアイテムは下書きができず投稿したら即公開です。添付ファイルは一度投稿をしないとURLは取得できないので、投稿してから編集して画像を貼る間は、画像がない状態で公開されてしまいます。そういう意味で上述の※の通り他の入力は済ませた方がベストという事です。

このようにサイトに対して投稿したいリスト以外に投稿権限以上のアクセス権限が付与されていない場合には、画像を表示する時は添付ファイルを利用すると良いですよ、という話でした。 また、事情があってそのような仕様にしなければいけないサイト管理者は、投稿者に添付ファイルを利用する方法を案内すると良いですね。


オマケ

このスクショを撮っている時に気が付いた小さな事です。

▼クラシックUIでリストのビューで本文を表示すると、2通りの方法で表示した画像は同じように表示されます。

▼しかし、モダンUIの場合は、通常挿入方法の画像はグラデがかかって省略表示されるのに対して、添付ファイルの方法で表示させた方は、グラデがかからず省略表示されます。

特に操作に違和感はないから表示上での相違点だけなのですが、不思議ですね。

SharePoint : チームサイトやコミュニケーションサイトではライブラリにアップロードした.aspxファイルはクリックすると表示されずにダウンロードされてしまう

SharePoint Online の場合、HTMLファイルをライブラリにアップロードしても、ファイルをクリックすると表示されずにダウンロードされてしまいます。この場合の対策として、単に拡張子を.aspxに変更するだけで解決し、以下の太田さんの記事が参考になります。

静的 HTML ファイルを SharePoint にアップロードして公開する | idea.toString();
http://idea.tostring.jp/?p=1717

この方法でHTMLファイルを SharePoint Online のライブラリに保管して表示したりできるのですが、コミュニケーションサイトで同じ事をしたら、.aspxファイルをクリックすると表示ではなくダウンロードされてしまいました。まずは現象を再現してみます。

■再現

まず、拡張子を.aspxにしたファイルを用意します。(ソースはHTMLです。)

▼検証用途なので非常に簡単なHTMLです。作成後、拡張子を.aspxに変更します。

▼まずは SharePoint 管理センターから作成したサイトのライブラリにアップします。

▼sample.aspxをクリックするとブラウザ内に表示されます。(もっとわかりやすくサンプルがよかったですね…ゴメンナサイ。)

ここまでは想定の動作です。次はコミュニケーション サイトでやってみます。

▼コミュニケーション サイトを作成します。

▼作成されました。

▼ドキュメント ライブラリに移動し、先程と同じsample.aspxをアップロードします。そしてクリックすると…

▼クリックすると表示されずにダウンロードとなってしまいます。

■原因

正直言うと急いで解決したかったので人に聞いて回りました。そこで疑われたのが「カスタムスクリプト が禁止になっているのでは?」との事。

カスタム スクリプトを許可または禁止する – Office サポート
https://support.office.com/ja-jp/article/1f2c515f-5d7e-448a-9fd7-835da935584f

ではやってみましょう。

■対策

結局これも以前コミュニケーション サイトで外部ユーザーを招待できなかった際の対策と同じく、僕の苦手な PowerShell で対応します。

▼SharePoint Online Management Shell をダウンロードしてインストールします。

Download SharePoint Online Management Shell from Official Microsoft Download Center
https://www.microsoft.com/ja-jp/download/details.aspx?id=35588

▼SharePoint Online Management Shell を起動します。

SharePoint 管理センターに接続する以下のコマンドを実行します。

<<hogehoge1>>:自分の環境に合わせて変更してください。
<<hogehoge2@hogehoge.com>>:管理者のアカウントのメールアドレス

▼サインインを促されるのでサインインしてください。

カスタム スクリプトを許可する以下のコマンドを実行します。(上述で紹介した Office サポートのページ内に記載されていたのを利用します。)

<SiteURL>:サイトのURL

 

実行すると相変わらず特に反応はなくスンっと終わります。

さて、これで.aspxファイルをクリックするとダウンロードじゃなくブラウザ内で表示されれば解決です!

▼おいおい、クリックしてもダウンロードされるぞ!

カスタム スクリプトの禁止が原因ではなかった!?と思いましたが、一応試してみようと思ったのが、.aspxファイルをアップロードし直す!

▼すでにアップロードしているファイルを一旦削除します。

▼再び同じsample.aspxファイルをアップロードします。そしてクリック!

▼やった!ダウンロードされずにブラウザ内で表示された!

って事でライブラリにアップロードした.aspxファイルがクリックすると表示されずにダウンロードされてしまう場合は、

  1. PowerShell でカスタム スクリプトを許可する。
  2. すでにアップロードしているファイルは再アップロードする。

という大きく2つの手順で解決できました。

PowerShell に慣れていない人はいろいろと怖いので検証用サイトコレクションを作ってテストしてみると良いですね。また、そもそもカスタム スクリプトを禁止から許可に変更した際の影響範囲なども考えないとですね。

SharePoint :リストを削除しようとしたけど関連リストがあるとかなんとかで削除できない場合

リストを削除しようとしたら、ダイアログが表示されて削除できない場合があります。

▼リストの設定画面で「このリストの削除」をクリックするとこんな感じでダイアログが

▼ダイアログの中身はこんな感じ

「関連リスト」ってなんだろう?

これは参照列を利用していて、その参照元のリストの事を指します。

▼削除できないリストには参照列があります

ただ、参照列があるだけならリストを削除する事はできます。できない原因は…

▼参照列の設定で「リレーションシップの動作を実行する」にチェックされている時

この時にリストを削除できなくなります。この場合、参照元のリストも同じく削除できません。削除したい場合は、このチェックを外せば削除可能です。

SharePoint : コミュニケーションサイトでは外部ユーザーの招待ができない


全体的な管理は以下の設定になっているとします。

▼ Office 365 管理センター > セキュリティとプライバシー > 共有

「オン」

▼そこからのリンク「サイトの設定」

「オン」
「新規と既存の外部ユーザー」

▼ SharePoint 管理センター > 共有

組織外との共有
「ユーザーに認証済み外部ユーザーの招待および共有を許可する」

この設定で通常は SharePoint に外部ユーザーを招待できます。しかし、コミュニケーションサイトで外部ユーザーを招待しようとしたところ、できませんでした。

▼このようにコミュニケーションサイトを作成

▼作成完了。共有します。

▼外部ユーザーのメールアドレスを入力するとエラーが

エラー内容
「このユーザーとの共有が組織で許可されていません。 Office 365 管理センターの外部共有に移動して、共有を有効にしてください。」

エラー内容を見る限り、その設定はすでに有効化しているんですよね。設定をいろいろ見直したのですがこのエラーが消える事はありませんでした。

他のサイトコレクションのサイトでは外部ユーザーを招待できることから、このサイトレクション固有の問題であるという原因の切り分けができます。このコミュニケーションサイトは今作ったばかりなので、つまりコミュニケーションサイトはデフォルトでは外部ユーザーの招待はできない設定になっているのでは?と推測ができます。

実際に管理センターで全体的に有効化していても、個々のサイトコレクションで外部ユーザーの招待の有効/無効は設定可能なんですよね。

▼ SharePoint 管理センターで該当サイトコレクションを選択し、「共有」

▼サイトコレクション単位でも設定が可能になっています。

では、コミュニケーションサイトもこの方法で設定を有効にすれば解決!!ではないんですよね…。

現時点での SharePoint 管理センターでは、Teams のチーム作成や Office 365 グループ のグループ作成などで自動で作成されるサイトコレクションは管理できません。そしてコミュニケーションサイトも管理できません。 SharePoint 管理センターのサイトコレクション一覧に表示されないんですよね。なので、コミュニケーションサイトの外部ユーザー招待機能を有効化はできないんです。

ここであきらめても良いのですが、僕の苦手な(苦手はたくさんありますが) PowerShell を使えば解決します。

▼SharePoint Online Management Shell をダウンロードしてインストールします。

Download SharePoint Online Management Shell from Official Microsoft Download Center
https://www.microsoft.com/ja-jp/download/details.aspx?id=35588

▼SharePoint Online Management Shell を起動します。(この画面見ただけで僕はしんどいです。)

SharePoint 管理センターに接続する以下のコマンドを実行します。

<<hogehoge1>>:自分の環境に合わせて変更してください。
<<hogehoge2@hogehoge.com>>:管理者のアカウントのメールアドレス

▼サインインを促されるのでサインインしてください。

外部ユーザーの招待を有効にする以下のコマンドを実行します。

<<hogehoge3>>:サイトのURL
ExternalUserSharingOnly :他にも設定の選択肢はありますが割愛。

このサイトのURLは少し注意が必要です。例えば以下はブラウザでサイトを開いた時のURLをそのままコピった場合ですが、これではダメです。
https://hogehoge.sharepoint.com/sites/comtest01/SitePages/Home.aspx

SitePages以下を削除したのですが、これでもダメです。最後のスラッシュが不要でエラーになりました。
https://hogehoge.sharepoint.com/sites/comtest01/

これでイケます。
https://hogehoge.sharepoint.com/sites/comtest01

▼コマンドに問題があるとエラーになり、問題がないと特に「成功!」的な反応はなく、スン…と次の行が現れます。

↑赤いエラーがたくさん出ていますが、 PowerShell 苦手なので、試行錯誤した痕跡です。お恥ずかしい…。

これでたぶん PowerShell にて設定が変更されたハズ!

▼先ほど招待できなかった同じメールアドレスで外部ユーザーを招待したところ、問題なく招待できました。

とはいえ、やはりただ外部ユーザーを招待したいだけなのに PowerShell には抵抗感ありますよね…。

現在、 SharePoint 管理センターは新しくなろうとしています。(もうすぐ対象指定リリースで使えるとの事。)この新しい SharePoint 管理センターでは、これらの現時点で表示されないサイトコレクションも管理できるとの事なので、期待します!

SharePoint :(古くから SharePoint を利用している人ほど)既定で存在する SharePoint グループで注意すべき点

サイトが作成されると既定で存在する SharePoint グループ があります。代表されるのが「所有者」「メンバ(メンバー)」「閲覧者」の3グループ。これをバージョンごとに羅列してみました。

※SharePoint 2010 以前の環境が手元にないので、画像検索して調べました。


■SharePoint 2007

・(サイト名) の所有者 :フル コントロール
・(サイト名) のメンバ :投稿
・(サイト名) の閲覧者 :閲覧

■SharePoint 2010

・(サイト名) の所有者 :フル コントロール
・(サイト名) のメンバー:投稿
・(サイト名) の閲覧者 :閲覧

■SharePoint 2013 ~

・(サイト名) の所有者 :フル コントロール
・(サイト名) のメンバー:編集
・(サイト名) の閲覧者 :閲覧


細かな相違点として、 SharePoint 2007 では「メンバ」だったのが、 SharePoint 2010 からは「メンバー」になっています。これは2008年頃に Microsoft が外来語カタカナ用語の表記ルールを変更した事による影響ですね。

また、今ちょっと見た限りだと、コミュニケーションサイトやチームサイトなどのモダンUIのサイトでは、「(サイト名)所有者」のように「の」がなくなっている場合もありました。

さて、本題です。

ここで見逃してはいけない大きな変更点が SharePoint 2013 からあります。メンバーグループの付与されているアクセス許可レベルが「投稿」から「編集」に変わっている点です。この違いは結構大きいです。

▼アクセス許可レベルの説明

細かい違いについてはそれぞれのアクセス許可レベルの設定内容を確認してもらうとして、つまりリスト・ライブラリ自体を作成・編集(設定)・削除ができたりします。

企業によってはIT部門がサイトの作成からリスト・ライブラリの作成まで行い、各部門のユーザーには投稿か閲覧のみにしている場合が結構あると思います。または、それぞれにサイト管理者を任命し、サイト管理者にのみフルコントロールを与え、それ以外のユーザーにはやはり投稿か閲覧のみ。つまり、不必要にリスト・ライブラリの作成や設定をできるユーザーを増やさないポリシーの企業は特に日本では多いと思います。(あくまでも僕の経験則と聞いた話の結果ですが。)

そういう企業の場合、 SharePoint 2007 や 2010 から 2013 以降や SharePoint Online に移行した際に、この変化に気がつかずに、ポリシーと実設定がズレてしまう事があります。

これも僕の経験則ですが、教育を行っていないユーザーに権限を付与すると、色々とトラブルも起きます。例えばリストごと削除してしまったとか、ビューの設定をメチャクチャにしてしまったとか。リストごと削除の場合は復元すれば良いけど、ビューや列などは復元できないのでちょっと怖いですね。
僕の個人的な思いとしては、トラブルを怖がって機能を制限するよりも、ユーザーに教育を行って解決させた方がポジティブで建設的だと思いますが、なかなかそうはいかないのが現状です。

という事で、「メンバー」グループのアクセス許可レベルについては、気をつけてみてくださいね、という話でした。

SharePoint :今は新しい表示(モダンUI)ではページからサイトの設定へのリンクがない

クラシックUIの場合、

▼ページの歯車メニュー内に「サイトの設定」があります

▼モダンUIでは歯車メニュー内に「サイトの設定」がない!

以前はあったんですけどねぇ…

じゃ、どこから行けるの?と困っている方がいらしたらのために、記事を書きました。

■サイト 情報 経由で移動

▼歯車メニュー内にある「サイト 情報」をクリック

▼右からパネルが出てきます。

▼拡大してみるとこんな感じ。

非常に目立たないというかテキストリンクだとわかりづらいけど、この「すべてのサイト設定を表示」をクリックすると、サイトの設定に遷移します。

■サイト コンテンツ 経由で移動

▼同じく歯車メニュー内の「サイト コンテンツ」をクリック(サイドリンクバー内にもリンクあります)

▼赤矢印の部分に「サイト設定」のリンクがあります。

▼サイト コンテンツ ページにこのリンクがあるのは SharePoint 2013 からなので、クラシックUIにもリンクはあります。

古くは SharePoint 2007 は右上に「サイトの操作」メニューがあり、 SharePoint 2010 ではそのサイトの操作メニューが左上に移動し、 SharePoint 2013 では歯車アイコンとして右上に戻るという変遷はあったものの、いずれのバージョンでもその中に「サイトの設定」のリンクはあったので、モダンUIの場合いずれの方法も2クリックしなければいけないのは若干ダルいです。

モダンUIはリスト・ライブラリも設定画面に行かずに、ビュー内で列の管理やビューの管理ができるようになり、極力設定画面を経由させない事で簡単に管理ができるように!という想いがあるのかもしれないです。同じくサイトの設定画面もなるべく経由させないように考えており、その表れとしてサイトの設定画面やリスト・ライブラリの設定画面にモダンUIがないのかなと思いました。そう考えると今後更に設定画面を経由しないUIになっていくのかもしれないですね。あくまでも僕の浅い考えの予想ですが…。ただ、過渡期である今はうまくモダンUIとクラシックUIを使いこなさないとですね。

SharePoint :用語セットの並び順は変えられる!

用語セットの並び順は昇順です。

▼作成時は作成した順番に並びます。ここまででは追加した順番通りに表示されると思ってしまいます。

▼しかし一度設定ページを終了してもう一度設定を見ると昇順に並び変わっています。

▼この用語セットを使った管理されたメタデータ列はアイテム作成時も昇順に並び変わっています。

▼なので任意の順序に並べ替えたい場合は、以前は用語の頭に連番を振って対応したりしていました。

でも、実は目立たないところに並び順を変更できる設定があるんですよね。結構気がついていない方も少なくなかったので記事にしました。

▼用語セットを選択すると上に目立たないタブがあり「ユーザー設定の並べ替え」なんてタブが!

▼「ユーザー設定の並べ替え順序を使用する」にチェックをすると並べ替えができます。

▼このように順番が任意の順番になりました。

▼ちなみに、設定を変更した後に、用語を追加すると…(F、Dの順番で追加)

▼追加分に関してはまた昇順で追加されるので、毎回並べ替え順序を変更する必要があります。(F、Dの順で追加したのに順番はDが4、Fが5になっています。)

これを知っていると知らないとでは大違いですね。連番で管理するのは大変だし余計な文字が増えて邪魔ですからね。

SharePoint :ページの表示速度が遅い場合に簡単にできる一度疑ってみるとイイ事(透明人間が悪さをしている場合が!)

SharePoint に限らずページの表示速度が遅い事はユーザーの利活用促進を阻みます。オッサンになって更に記憶力が悪くなったので正確な情報ではありませんが、たしか通常のWebサイトではページの表示が2秒だか3秒以上かかると、ユーザーの離脱率がグンと上がるようです。なので、パフォーマンスについての対策は検討すべきかと思います。

パフォーマンスについては様々な原因があるのですが、ここではページを編集できる権限レベルでも調査できる、ページの表示速度が遅い原因を紹介します。

▼対象のページを表示します。(デモでは極端にWebパーツをゼロにしました)

▼編集モードにして、表示されているWebパーツの数を正確に数えます。(ゼロ個)

▼編集モードを終えて、URLの末尾に「?contents=1」を入力します。

▼このページが持っているWebパーツの一覧画面が表示されます。

ここで先ほど数えたWebパーツ数とここの一覧の数が一致しているかを確認してください。(表示上はゼロ個だったのに対し、こちらでは4個あります。)

以上です。

ここまでは過去に類似した記事を投稿済みです。

SharePoint :ページにWebパーツを追加すると1つしか表示していないのにWebパーツのタイトルに[1]が表示される

ただ、この時では気がついていなかったのですが、この一覧で「ページで開く」が「はい」になっているWebパーツは、実は表示上は消えているけど裏で生きている透明人間のような存在で、なんとソース上ではレンダリングされているんです。
この透明人間Webパーツが、表示速度が遅い原因である場合があるんです。

例えば…

▼このような「lib001」というライブラリがあるとします。事前に「search_test01」がある事を確認してください。

▼先ほどの見た目はWebパーツが1つもないページ

▼ただしこのように透明人間Webパーツが多々あり、この中に「lib001」ライブラリも含まれています。

さて、この状態で該当ページのソースから「search_test01」を検索します。

▼このようにソース上ではレンダリングされているんです。

この透明人間Webパーツが単体動作する軽量なWebパーツなら良いですが、数千アイテムあるアプリをフィルターかけていない状態でアプリパーツとして配置している場合、しかもそれが数個あった場合は、パフォーマンスに影響はあると考えます。

なので、上述の調査で数が一致しなかった場合は、透明人間Webパーツを削除してみましょう。

実際に、表示速度が遅い悩みのあるページで、上述の方法で調査した結果、透明人間Webパーツが大量にあり、一覧ページから完全抹殺したところ、劇的に表示速度が速くなった例もあります。

もちろんこれは原因のほんの1つなのですが、調べ方は簡単なので調査する価値はあるのかなと思います。

SharePoint: コンテンツ エディター Webパーツの「コンテンツへのリンク」の活用例

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ページのみですが、ページの量が増えるほど、一括管理できるメリットが活きるのかなと思います。

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

SharePoint 「サイトコレクションの管理者」と「トップレベルサイトのフルコントロール権限」は全然違う

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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