Art-Break .log : Taichi Nakamura
Microsoft 365 ( Office 365 ) ・ Power Platform ・その他の情報発信ブログ
SharePoint のリストやライブラリにおいて、ビューの設定は必ずと言っていいほどすると思います。良くあるのは既定では並び替えはID列の昇順に設定されているけど、最新投稿順や最新更新順で見たいから登録日時や更新日時で降順の設定に変更したり、表示されていない列を表示させたり。
クラッシックUIの頃はビューの設定は設定ページで行いました。これに慣れている人にとっては慣れてしまっているので気にならないと思うけど、作業を試行錯誤したい場合、ビューと設定ページをイチイチ行き来するのはダルいです（ページが切り替わる速度も速いわけじゃないので）。一方、モダンUIになると、もちろん旧来のクラッシックな設定ページにも行けるけど、ビューページの中でビューの設定をする事ができ、リアルタイムで設定が反映されるので、UXが非常に向上したと思います。
ただ、それが故にビューの設定を行った後にやりがちなミスが出てしまいます。それが「設定したビューを保存し忘れる」です。僕も定期的にそのミスをしがちです(笑)どういう事かと言うと…
“SharePoint ：モダンUIのビューの設定でやりがちなミス” の続きを読む※超重要なお知らせですが、本日3/8は僕の誕生日です！プレゼントは今日から365日間受け付けております！
は、置いといて…
リスト・ライブラリのクラシックUIのビューでは、ビューの設定の「集計」で、列ごとに合計値や平均値を表示できる機能がありました。
▼ビューの設定の「集計」の設定項目
この設定をすると、クラシックUIの場合、ビューの各列の上部に太字で合計値や平均値や最大値などが表示されます。
▼この赤枠内に集計が表示されています
場合によっては便利な機能で昔からちょくちょく使っていました。
しかし、この集計機能はモダンUIは対応していなかったんですよね。ただ、対応するというアナウンスは出ていたので待っていたのですが、どうやら気が付いたら対応されていました。
では、確認しましょう。
“SharePoint ：モダンUIでもビューの集計に対応したぞ！” の続きを読むこれは個人的な考えですが、SharePoint で情報共有目的でフォルダー管理するのはあまり好きではありません。他に SharePoint ならではの整理する手段があるからです。そこらへんの話をすると冒頭から話が大脱線してしまうので、また別の機会にします。
僕の好き嫌いは置いといて、一般的には SharePoint のライブラリでもフォルダーでファイル管理をしているケースは多いと思います。でもフォルダー関係なくライブラリ内の全てのファイルの新着情報や更新状況を知りたい場合もあると思います。
例えば…
Aさん「Bさん！○○ファイルをライブラリにアップしといたよ！」
Bさん「ん？○○ファイルってどのフォルダーでしたっけ？」
Aさん「えっと、まってね…Aフォルダー内のA-bフォルダー内のA-b-01フォルダー内！」
Bさん「早い早い！Aフォルダー内の？？」
Aさん「A-bフォルダー内の…」
わずらわしいやりとりですよね。
この場合、SharePoint にはフォルダー階層を無視したビューを作成する事が可能です。この設定をはじめて知った時に SharePoint って便利だなぁと思ったし、他ユーザーに教えるとだいたい良い反応いただきます。 SharePoint に詳しい人にとってはよく知られている機能だけど、利用ユーザー全体で考えるとおそらく知らないユーザーの方が多いのかなと思いますので紹介します。
▼フォルダー階層のライブラリがあります。
フォルダーの更新日時はフォルダー内のファイルの更新日時ではなく、フォルダー自体の更新日時です。（この情報あまり必要ないですよね…。）なので、このビューだけではこのライブラリ内の各ファイルの更新状況は把握できません。
そこでフォルダー階層を無視するビューを作ってみましょう。
▼ビューの新規作成画面です。キモの部分は「フォルダー」。
ここで「フォルダーなしですべてのアイテムを表示する」にします。
▼ほかに「並べ替え」を更新日時で降順にします。
するとフォルダー階層を無視したライブラリ内の更新状況が把握できるビューが完成です。
▼このようにフォルダー階層を無視し全て並列でファイルが表示されます。
サイトのトップページにこのビューを配置し、ライブラリの新着情報にする…なんて使われ方が多いのかなと思います。
先ほどのわずらわしい例えだと…
Aさん「Bさん！○○ファイルをライブラリにアップしといたよ！」
Bさん「承知しました！」
（ライブラリの新着情報を見れば今Aさんがアップしたファイルが表示されている。）
こんな感じになります。
注意点があります。5000件問題です。ビューのしきい値の5000件問題はフォルダーにすれば回避できますが、この設定はそのフォルダーを無視する設定なので、ライブラリ内に5000件以上のファイルがある場合は、このビューは5000件問題に該当してしまいます。その場合は、フィルターを利用してビューの表示対象となるファイル数を制御しましょう。例えば更新日時が今日から7日前分しか表示させないような。
さて、この記事の「投稿・閲覧ユーザー」に喜ばれるというタイトルですが、「え？サイト管理者などリストの作成者が喜ぶんじゃなくて？投稿・閲覧権限ではビューは作成できないよ？」って思われる方もいるかもしれないです。それはおそらく「個人用ビュー」という存在を知らない人かもしれないです。「個人用ビュー」に関しては僕の経験則でも知らない人が多いです。また改めて紹介します。（宿題がたまるー）
SharePoint に詳しい方々なら知っていて当たり前のような機能でも、初心にかえって思い起こせば、その機能を知った時に「おっ、便利じゃん！」って思った機能があるかと思います。特にIT部門の担当者さんなんかはその感覚を忘れずに、利活用促進のためにユーザーに教えてあげれば良いと思いますね！
前回の記事では、クラシック表示のビューのスタイルを「既定」以外にすると、ビューのフィルターで複数の値でフィルターをかける事ができないという事を書きました。
SharePoint ビューのスタイルを変更すると機能落ちする
ところで「既定」スタイルのビュー、つまりリストやライブラリを作成したデフォルトのビューでは、マウスホバー時にはその行の背景色が変わるので1行を読みやすいですが、マウスホバーをしないとテキストばかりになってしまい、読みにくいです。そういう意味もあって網掛けにしたい要望は少なくはありません。
それではビューの機能落ちなく網掛けにするには？CSSでカンタンに解決します。既定スタイルのビューでは、上から偶数行のtrに「.ms-alternating」というclassがあります。ビューで「ページの編集」をし、スクリプト エディター Webパーツなどに以下を記載すれば網掛けになります。（色は好きな色で。）
<style type=”text/css”> <!– .ms-alternating { background-color: #e7e7e7; } –> </style>
▼こうなります。
ただし、実はこれも一点デメリットが。
これはSharePoint 2010 からの問題なのですが、ビューを編集するとリボンタブが「参照」以外表示されなくなるんですよね。
▼本来なら「参照」の右に「アイテム」「リスト」タブが表示されるハズが。
ビュー内のアイテムなどをクリックするとすぐ復活するのでユーザーに周知されれば大きな問題ではないのですが、これは未だに直っていない問題です。
さて、このデメリットも回避しつつ網掛けにする方法もあるにはあります。
ビューに直接CSSを記述するのではなく、CSSファイルに記述し、代替CSSでそのCSSファイルを設定する方法です。これならビューを編集せずにCSSを適用させられるので、リボンタブが消えてしまう問題は解消されます。
ただし！そうです…これにも一点デメリットが。代替CSSで設定すると影響範囲はサイト全体です。つまり他のビューや他のリスト・ライブラリも網掛けになってしまいます。
代替CSSでも適用させたいリストを特定させる方法もなくはないのですが、色々面倒なのでないと言ったほうが良いかもしれないです。
結果として、標準機能とCSSカスタマイズではデメリットのない方法は見つからないのですが、網掛けをするのに標準機能の設定では1パターンしかなかったのが、CSSにより3パターンにまで増えました。それぞれのデメリットを考慮し、別にデメリットには感じないものがあったとしたら、そのパターンで実装すれば良いと思います。
以上です。複数の値でフィルターをかけられなくても良いのなら【1】で問題ないし、リボンタブをユーザーが利用しない、もしくは解決方法を周知させられるのなら【2】で問題ないし、サイト全体のビューが網掛けになってしまうのはむしろ大歓迎の場合は【3】で問題ないし、そもそも網掛けを諦めるというカードもありますよね。
要望が実現できないと業務に多大な影響があるかどうか？影響がないなら要望を諦める選択肢も十分あって良いと思います。
本当ならデメリットが一つもない方法を提示できればスッキリしたんですけどね。もちろんもっと他の方法でカスタマイズすれば良いのですが、CSS程度のライトカスタマイズにこだわりました。
※クラシック表示の場合です。
これはSharePoint 2007 にはできなかったことですが、ビューでフィルターをかける際にフィルターの値を複数選択できなかったんですよね。今のビューは複数選択できますよね。
例えば以下の場合だと、カテゴリ列でAとBでフィルターをかけたい場合は、AとBの左のチェックボックスをチェックすればできますよね。
▼カテゴリ列にはA・B・Cの値が入っています。
▼カテゴリ列をフィルターのドロップダウンから「A」「B」のチェックボックスをチェック
▼「A」「B」でフィルターがかかりました。
ただ、ビューのスタイルを変更すると、この複数選択ができなくなってしまうんです。
▼例えば…網掛けにしてみました。フラットでシンプルなデザインのSharePoint において、特にビューは網掛けの方が見やすいのでニーズは結構ありますよね。
▼網掛けにしてフィルターをかけようとすると値の左にチェックボックスがありません。つまりこの時点で複数選択はできません。
▼一度Aだけでフィルターをかけた後にもう一度フィルターのドロップダウンを開くと、さっきは表示されていなかった値の左のチェックボックスが、Aにチェックされているチェックボックスが表示されます。では、この状態でチェックボックスは表示されていないので「B（テキスト部分）」をクリックしてみます。
▼するとBだけしかフィルターされませんでした。つまり複数選択はできないようです。
▼また、この状態でフィルターを解除したくBのチェックボックスのチェックを外してみてもフィルターは解除されませんでした。つまり、このチェックボックスは見た目だけで機能していないようです。
▼あくまでもSharePoint 2007 の頃と同じで、「カテゴリのフィルターをクリア」をクリックしないと解除されません。
おそらく…「既定」以外のスタイルは、とりあえず旧バージョンからそのまま持ってきたので、フィルターの機能もSharePoint 2013 以降の機能は使えず、古いバージョンの機能と同等になってしまっているのかもしれません。
フィルターを複数選択するニーズはあると思うので、例えば読みやすいように網掛けにしたい場合でも、ビューのスタイルを変更する場合にはこのようなデメリットもある事は頭の片隅に入れておいても良いかもしれません。
既定ビューでもCSSで網掛けにするのはそんなに難しくはないです。その方法の紹介は、また今度できたらと思います。
以前、お知らせリストの有効期限列について以下の記事を書きました。
SharePointの「お知らせ」リストの「有効期限」列の利用および非表示方法
この記事で、利用方法の一例として、ビューのフィルターを活用して有効期限切れのアイテムをビュー上に表示させない方法も紹介しました。この方法は参考書などにも紹介されている方法なのでメジャーな使い方かと思います。ただし、この活用方法には落とし穴があり、実際にSharePoint運営に携わっていた頃にもトラブルがありました。以下、架空の設定ですが実際起きうるトラブルとして紹介いたします。
閲覧ユーザーが、お知らせリストに掲載されていた情報を元にお客様用に資料を作成し提出したが、その情報が古かったらしく怒られてしまった。その掲載物の投稿者に問い合わせてみたところ、古い情報は有効期限が切れており、新しい情報は別途掲載して表示した、とのこと。
ビューのフィルターをかけるだけでは有効期限切れのアイテムはビュー上から非表示になるだけで、実際に削除されたわけではありません。すべてのアイテムを表示させるビューがなかったとしても、検索すれば検索結果に表示されてしまいます。このトラブルも検索結果から古いアイテムを表示した事が原因でした。
お知らせリストの利用用途として検索対象外にする事はあまり好ましくありません。この方法を継続していれば同じトラブルは起きる可能性は高いです。このようなリスクを考慮して有効期限にどの機能を加えて活用するかを検討しないといけないです。
あくまでも参考としてください。
まずトラブルを避けるには有効期限切れのアイテムは表示されないように配慮する必要があります。やはり情報管理ポリシーの保持を利用し、有効期限が切れたらアイテムを削除するのも一つの手です。ただし、この方法はこのトラブルが解決できても別のトラブルが出る場合があります。これも運営に携わっていた頃によくあった問い合わせなのですが、「過去に投稿したアイテムを再利用したいけど有効期限が切れたらしく見当たらないので復活してほしい。」という問い合わせ。運営側からすると「いやいやあなた…自分で設定した有効期限が切れたならあきらめなさいよ…」と思うでしょうが、実際この手の問い合わせは結構多かったんです。で、ごみ箱から復元できる場合は復元してあげるのですが、ごみ箱からも削除されていたらもうあきらめてもらうわけです。この場合は、運営上そういうものだとユーザーに啓蒙していくしかありませんが、別の方法としては、有効期限が切れたら別のリストに移動するように設定し、移動先のリストのアクセス権限をサイト管理者以外閲覧できないように設定すれば、検索でも古い情報がひっかからず、復元の依頼があっても対応できるのかなと思います。また、SharePoint Designerなどのワークフローを利用して、有効期限の直前に投稿者にメールで通知してから有効期限で移動や削除なんて事も可能かと思います。
そこまでしてフロー情報をストックしておく必要があるかどうかは別として。
そうなんです。そもそも運営の仕方（サイト作成の仕方）がユーザーのニーズと乖離しているところも検討するところです。色々な角度から検討する必要がありますが、例えば、そこで発信する情報の種類が最低限フロー情報なのかストック情報なのかを考えて、サイト作成をしていく必要があります。
極端に言えば、例えば規程集のようなストック情報に有効期限を付ける必要はありませんよね。例えば鮮度が命の情報のようなフロー情報を半永久的に保存しておく必要はありませんよね。これらフロー情報とストック情報は性質が全く異なるので、それを同じ管理方法で運営している事自体を再検討しないといけない、などです。
運営部門の会議などで「有効期限列を活用する方法があります。」と言って説明をすると、すぐに「じゃ、全てに実装しよう！」なんて考えも出てきます。気をつけたいところですね。
アプリ名やビュー名など表示名は気にするけど、URLまでは気にしない場合はどうでも良い記事です。
列の内部名やアプリのURL（ディレクトリ名？）は作成後に変更はできませんが、ビューに関してはビュー名の他に「このビューのWebアドレス」という欄で、URLの変更が可能です。URLにこだわる場合、大文字小文字も含めて一貫した規則性に従って作成すると思います。複合語の場合は、キャメルケースだの色々な命名規則がありますが、例えば頭文字を小文字で書いていたら、後から大文字に直せと言われた場合。
例として「viewName」を「ViewName」に変更する際に事象が確認できます。
▼「このビューのWebアドレス」が「viewName」になっています。
▼「このビューのWebアドレス」を「ViewName」と先頭を大文字Vに修正します。
▼ところがブラウザのURLを確認すると修正されていません（小文字のまま）。
▼再度ビューの編集ページを開いても「viewName」に戻ってしまっていました。
検証してみた結果なのですが、ビューの編集ページの「このビューのWebアドレス」欄では、大文字から小文字、小文字から大文字の修正は、内部的には大文字小文字の違いは認識されず、変更がない項目としてスルーされてしまうようです。
変更されない理由がわかれば対策は簡単です。一旦別の文字列に置き換えて再度変更すれば良いだけです。例の場合だと…
▼「このビューのWebアドレス」からvを削除し「iewName」で修正します。（一旦他の文字列にしたいだけなので、極端な話「a」で修正してもOK）
▼ブラウザのURLを確認すると当然「iewName」に変わっています。
▼再度ビューの編集を開くと「iewName」になっているので、「ViewName」に修正します。
▼ブラウザのURLを確認するとちゃんと大文字に変わっています。
マニアックなところですが、実際に質問されて自分でも知らなかった事象だったので記事にしました。