Art-Break .log : Taichi Nakamura
Microsoft 365 ( Office 365 ) ・ Power Platform ・その他の情報発信ブログ
リストの列を作成する際に、列の種類を選びます。
古くからある「ユーザーまたはグループ」列は現在は「個人」という名前に変わっていますが、例えばタスク管理目的のリストなら「担当者」なんて列が欲しい場合は、手入力で人の名前を入力せずに名前やメールアドレスを少し入力すればサジェストに候補が表示されて選択できるので楽だし、正確な名前情報が表示されるし、登録されたアイテムの個人列の名前にマウスホバーさせるとそのユーザーのプロフィールが表示されるし、便利な列の種類ですよね。
“Microsoft Lists ／ SharePoint ：「個人（ユーザーまたはグループ）」列にプロフィール写真が表示できるようになった” の続きを読む
SharePoint がモダンUIを始めたのっていつ頃でしたっけね？2017年あたりでしたっけ？ブログを読み返そうと思ったけど量が多くて面倒になったのでやめました(笑)まぁそこはさほど大事な事じゃなく、まぁおよそ3・4年経過してもまだクラッシックUIを一部使っているところがありますよね。で、その一つが「日付と時刻」列のカレンダー表示でした。それがようやく僕のテナントでモダンUIに変わりました。なんか結構前に Microsoft 365 管理センターのメッセージセンターにこれについてメッセージあった気がするけど、今探しても見つからなかったです。ちょくちょく消されるんですよね。
さて、僕のテナントは対象指定リリースに設定しています。対象指定リリースと標準リリースの違いは古い記事ですが以下の記事に書いています。
ただ、標準リリースのままにしている別のテナントもあって、そっちの方はまだクラッシックUIのままだったので、比較してみます。（つまり、皆さんのテナント次第ではまだ古いUIのままの可能性もあります）
“Microsoft Lists ／ SharePoint ：「日付と時刻」列がようやくモダンUIになった” の続きを読む※結構前からあったらしいけど改めて今朝気が付きました…。
昔のバージョンに比べて今の SharePoint はビューやフォーム上でマウスで操作できる事が増えました。しかし、故にできなくなった事もあります。それの最たる例がコピーです。
例えば、ビュー上からアイテムのタイトル列をコピーしたいとします。
▼実際にビュー上からタイトル列の値を範囲選択してみようとするとできません
SharePoint のリストに新規アイテム追加をしようとしたときに比較的わかりやすい変化がありました！
▼リストのフォーム
いつの間に列の設定画面にこんな設定があったんだろう？とりあえず良く分からない設定はそっとしておいて、そのまま忘却していました。
で、おもむろに気になったのでググってみました。すると、とにかくアホでも理解できる説明が出てこないんです。「値に一意性を適用する…」一意性とか普段使わないし。とにかくよくわかりません。ただどうやら SharePoint 2010 からの機能らしい。よくわからないなら検証してみましょう。
▼カスタムリストのタイトル列の「固有の値を適用する：」を「はい」にしてみます。
▼なんかよくわからないけど「強制的」とか怖そうな文章のダイアログが表示されますが、
問答無用で「OK」をクリックしてみます。
▼とりあえず「テスト」というタイトルで投稿。問題なし。
▼もう一度投稿。今度も「テスト」というタイトルで投稿。しかし保存をクリックすると「この値は既にリストに存在しています。」というメッセージが表示され、投稿できませんでした。
なるほど。つまり、
「同じリストの同じ列に同じ値で投稿する事をできなくする」
という事ですね。
それを理解した上で「固有の値を適用する」という意味がなんとなくわかりました。
じゃ、疑問。
すでに同じ値で投稿済アイテムがある列に適用したらどうなるんだろう？
▼「タイトル」列に「テスト」で投稿したアイテムが2件あります。
▼タイトル列の「固有の値を適用する：」を「はい」にします。
▼なんと！
という事で、列に同じ値を使えなくさせたい場合は、「固有の値を適用する」を「はい」にすれば良いようです。
ちなみにサポートされていない列の種類もあるようです。
列の値における一意性の適用
https://msdn.microsoft.com/ja-jp/library/office/ee536168(v=office.14).aspx
1行テキスト・複数行テキスト・選択肢・ハイパーリンクまたは画像など、列の作成や設定に出てくる「IMEの設定」という項目があります。初期値は「コントロールなし」、他に「オン」「オフ」があります。
これはIMEの入力モードを設定する機能ですが、オンにすると日本語入力しかできないとか、オフにすると英語入力しかできないというものではなく、入力モードの初期値を設定できるというものですね。
キーボード左上の「半角／全角」キーを押さなくても良いってだけなんですよね。（Windowsの場合。他にも切り替え方法はありますが、本記事では「半角／全角」キーに統一して文章を進めます。）つまり、オフにした状態でも「半角／全角」キーを押せば日本語入力はできます。
利用用途としては、あらかじめ日本語でしか入力しない想定の列ならオンにし、あらかじめ英語でしか入力しない想定の列ならオフにすれば良いという感じです。
と、この機能は比較的 SharePoint 初心者の方も知っている機能なので改めて説明するまでもなく、親切心で、入力内容をあらかじめ想定し、IMEの設定を変更している方もいるのではと思います。
ただ、僕個人的な意見としては、ここはイジった方がかえってユーザーのストレスになる可能性が高いのではと考えます。
PCにある程度慣れているユーザーにとっては入力モードの切り替えは無意識に「半角／全角」キーを押すので、明示されているわけでもないのに、その列にカーソルを当てると入力モードが切り替わってしまっては、そこからユーザーが無意識に入力モードを切り替えてしまうので、結果として意図した入力モードの逆になってしまうトラップになり、イライラしてしまう事は想像できます。
仮に入力モードの設定をしている事を明示していたとしても、タイピングの速い人ほど、おそらく無意識に指先が反応してイライラしてしまう事かと思います。
ユーザビリティーを検討する場合はターゲットユーザー次第でもあるので、中には必要なケースもあるのかもしれませんが、親切心が余計なお世話になるケースもある事を考慮して、機能や設定の変更は検討した方が良いですね。過去の経験上、余計なお世話になってるケースは結構あったように思います。
ちなみに、複数行テキスト列は列作成時にIMEの設定項目はありません。
複数行テキスト列の場合は、テキストの種類が「書式なしテキスト」選択時にのみIMEの設定が可能です。列作成時に「書式なしテキスト」を選択して一度作成し、該当列を編集すると表示されます。
もちろんここをオンにして書式なしテキスト以外を選択しても、無効になります。
SharePoint2007時代からSharePointを触っていて、日本語訳に難がある箇所がところどころありました。
例えばアイテムの「閉じる」ボタン。ブラウザ操作で「閉じる」はウインドウもしくはタブが閉じるの意味を連想するので違和感を覚えていました。実際は1つ前のページに戻る、もしくはそのリスト・ライブラリの既定のビューに戻るんですよね。現にユーザーからもウインドウが閉じるかと思って閉じるボタンをクリックした事はなかった、なんて声も出ていました。
話を戻して…
日本語訳が微妙であまり使えなかった機能のひとつに、この記事のタイトルのとおり、選択肢列の「選択肢を追加できるようにする」の機能があります。これはつまりラジオボタンやチェックボックスなどの選択肢で、該当なしの場合に自分で記入できるいわゆる「その他」という選択肢。
これがSharePoint2007だと…
この「選択肢を追加できるようにする」を「はい」にすると…
「値を指定してください」なんて文言なんです。どうも微妙な日本語なのでよろしくないです。特にアンケートリストでアンケートをとる際に利用したいシーンが多いのですが…。
ちなみにこの文言は基本操作では変更できません。仕方ないのでJavascriptを使って変更したり、ユーザーにこういうものだと周知させてこのまま使ったりしていました。
それが！
恥ずかしながらこないだ気がついたのですが、今は文言が変わっていました。
SharePoint2013だと…
「その他 (テキストを入力してください):」
あら、問題ないじゃないですか。
いつから変わったんだろう…
SharePoint2010でも変わっていなかったと思うんだよなぁ。
SharePoint2013に関しては全く記憶がなく…。
これからは気兼ねなく使えそうです。
【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から連番が振られる。
ここまで調べて思ったこと。
この情報、そんなに必要じゃないので時間の無駄だったかも。
列には列名と裏側に内部名が存在します。列名・内部名ともにアプリ内ではユニークです。基本機能のみで利用している場合は内部名を気にする必要はありません。
列名は作成後に変更する事ができますが、内部名は変更できません。裏を返せば、Webパーツの開発などで、特定の列を参照したい場合、列名だとリストに権限さえあれば列名を変更できてしまうので、その後Webパーツが正常に動作しなくなります。
内部名なら列の作成後は変更できないので、列名を変更してもWebパーツも修正する必要なく正常に動作します。メンテナンス性を考慮すれば内部名を使った方が良いですね。
列の内部名の調べ方は、列の編集ページのURLを見ればわかります。
例えば以下は「タイトル」列のURLのサンプルです。
http://****.sharepoint.com/****/_layouts/15/FldEdit.aspx?List=*****&Field=Title
このField=より後ろが内部名です。つまり「タイトル」列の内部名は「Title」です。
例えば「商品」という列名で列を作成すると、内部名をURLから取ってくると、
_x5546__x54c1_
これが「商品」列の内部名です。なんか気持ち悪いですね。
これを回避する方法として、列の作成時に列名を英数半角で一旦作成後、列名を日本語に編集する手があります。
▼「product」という列名で列を作成すれば、内部名も同じく「product」です。
▼その後、列の編集で列名を「商品」に変更します。
▼列名は「商品」だけど、内部名は「product」のままです。
※ただし…英数半角と書きましたが、例外がチラホラあるようです。例えば、「1」という列名で作成すると内部名は「_x0031_」でした。列名の頭に半角でも数字を入れるとこうなるようです。また、「col1」という列名で作成すると内部名は「_x0063_ol1」になりました。これに関しては法則がよくわからないです。深入りしない事にします…。