タグ: SharePoint

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は設定どころか閲覧すらできない。

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

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

SharePoint において、サイト管理者にサイトコレクションを渡しても、いつまで経っても構築されずに放置、または、サイト管理者のテストページが作成された痕跡があるだけ、いつしか全く利用されずにゴーストタウン化…なんて事がありがちかと思いますし、そのような現場を数多く見てきました。

なぜ利活用が促進されないか？色々原因はあるとは思いますが、単純にユーザーが使い方がよくわからなく、便利だと感じるまでに到達しないからだと思います。ネットワーク上の情報共有はメールで行うのが昔から定着されてきた方法で、この根強い牙城を崩すことはこんな世の中でもなかなか困難です。メールにはない便利さを多大に感じてもらわなければ、わざわざ慣れたメール文化から「しぇ？しぇあぽいんと？なにそれ？」から積極的な利活用には持っていくことは厳しいです。
逆を言えば、ある程度使い方を教えて便利だと感じてもらえれば利活用促進の第一歩かと思います。第一歩ですが大きな一歩です。

過去にたくさんの SharePoint 初心者と関わらせていただきました。ここで示す初心者とは「サイトを作成・運営」する立場の人達です。時にはマニュアルやガイドを作成したり、時には社内セミナーや勉強会を開きました。長年運営に携わりリアルガチな生の声もたくさん聞いてきました。そこで様々な SharePoint 独特のわかりづらい点があり、教えるのに苦労した事もあったり、よく質問をもらったりしました。そこでそういう点を過去の経験を基に紹介しようと思います。

それぞれの環境により正解は異なるのでここでは特に正解は書きませんが、何かの気付きになっていただければうれしいです。

---

そもそも「アプリ」「アプリパーツ」という用語がフワっとしちゃっていますが…。

Office 365 内の「アプリ」という言葉の定義がフワッとしている…

今回の記事の「アプリ」とは、いわゆるリスト・ライブラリの事です。「アプリパーツ」とは、リスト・ライブラリ Webパーツの事です。

SharePoint は良くも悪くもクセのある製品だと思います。SharePoint をはじめて触った人がサイトを構築しようとして困惑するのが、このアプリとアプリパーツの関係性と作成の操作性・操作手順でした。

例えば「トップページにライブラリを追加しよう」という単純な目的があるとします。初心者の方が困惑するのは、だいたい以下の操作をイメージするからです。

▼このページにライブラリを追加したい！なにやら右上に「編集」があるぞ。

▼おっ！編集できそうだ。ライブラリはどう追加するんだろう？リボンのタブに「挿入」があるぞ！（ここに気がつくまでにも時間がかかりますよね…）

▼おっ！「アプリパーツ」ってこれじゃん！

▼ん？どこからライブラリを作るの？意味わからん！

で詰まってしまうようです。

• ページにアプリパーツを追加したい。
• ページを編集してアプリを追加する。

SharePoint について知らない場合は、そういう考えになってしまいますよね。

SharePoint を知っている人なら以下の手順で作成すると思います。

• アプリ（ライブラリ）を作成
• ページにアプリパーツ（作成済のライブラリ）を追加

でも、この概念をUIから直感的に理解する事は今の SharePoint では困難なんですよね。まずはアプリを作成してからパーツとしてアプリを配置するという事に。

で、行き詰ってしまって諦めて使われなく…。

なので、サイトコレクションを渡す際に、キモとなる部分は最低限教えてあげる必要がありますね。これはその一つなのではと思います。