SharePoint でビューのURLを大文字←→小文字で変更できない!あ、解決

【結論】

  • 大文字小文字の違いは違いと認識されず変更されない。
  • 法則がわかれば変更可能。

アプリ名やビュー名など表示名は気にするけど、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を確認するとちゃんと大文字に変わっています。

マニアックなところですが、実際に質問されて自分でも知らなかった事象だったので記事にしました。

SharePoint の利活用促進を本気で考えるなら閲覧者投稿者レベルでの教育が必要(だと思う)

※今回の記事は長文です。

サーバー管理者レベルでの参考書や無料セミナーなどはよくありますが、閲覧・投稿者レベルでのそれはほとんどないと思います。マイクロソフトからエンドユーザー基本操作マニュアルなるものもダウンロードできますが、あれもサイト管理者レベルなのかなと思います。(探せていないだけ?)

つまり、サーバー構築からアプリ(リスト・ライブラリなど)の作成・設定レベルはすぐに勉強できるけど、投稿方法や閲覧方法などは使いながら覚えて!的な感じです。しかしながら、SharePoint は直感的に全ての操作を把握するにはほど遠いUIでして、SharePoint に詳しい人には常識的な操作であっても、利活用の主役である閲覧・投稿者にとっては直感的に操作をするには厳しい部分もあります。

運営に長年携わっていて多かったユーザーに知られにくい機能の一例

  • ビュー内で列でソートやフィルターができる事。
    (例えばマウスオーバーしないと列名の横に「▼」が出ないなど、直感的には機能に気がつかないUI)
  • 個人ビューの存在
  • 通知機能

これを教えるだけでもSharePoint の印象が大きく変わるであろう機能も、意外と教えないと存在すら気がつかないまま何年もSharePoint を利用しているユーザーは少なくはありません。

ただ、これらSharePoint の機能紹介的な教育よりも大事であると思う事があります。

情報共有とは情報発信だけでは意味がなく、発信された情報が受信され活用されて意味を成します。つまり、発信した情報が読まれなければ意味がありません。言い換えると、投稿者は可読性を意識する事がポイントかと思います。

サーバー管理者やサイト管理者がいくらUIを気にしてデザインのカスタマイズをしたところでそれはあくまでも枠の部分。そこより大事なのは枠の中身です。その中身を作るのは投稿者。その教育が必要だとは思いませんか?
軽く例を挙げると…

  • 背景と文字とのコントラスト
  • 文章をカラフルにすれば良いというものではない
  • フォントサイズと行間の重要性
  • テキストリンクが装飾に埋もれてリンクと気づかれずクリックされない

などなど。実際アイテムの中身を見ると、受験生のようにテキストをカラフルにして、白背景に黄色文字を使ってチカチカしたり、リンク色と同じ色をつけているテキストがあって、クリックできるのかと思ったらクリックできなかったりイラっとするものもあったりします。思ってもいないような使い方をするんですよね。これはSharePoint に限らずプレゼン資料など人に見せる資料を作成する人全員に必要な教育でもあるんですけどね。

また、Webのマナーなども重要です。
例を挙げると…

  • 引用についてのマナー
  • 著作権について

こういう部分も閉ざされた空間だからといって自由であるわけではなく、社内のモラル・マナー向上においても教育は大事だと思います。

ちなみにこの記事を読んでこれらを常識だと思われている人は、すでに自身のスキルや知識に悪い意味で侵されています。非IT企業はもちろん、IT企業であっても必ずしも全従業員がITリテラシーやモラルが高いとは断定できません(従業員を信じたいですけどね。)。

また、なんでも「○○は禁止」といったネガティブな教育をすると利活用促進とは間逆の結果になりがちです。「○○はこうした方が良いですよ」的なポジティブな教育が必要ですね。利用したい・便利だと思わせる事が重要なので。

「教育」というと大きな話に聞こえてきますが、それこそSharePoint のブログ機能やSNS機能を利用して発信しても良いかなと思います。ディスカッション掲示板を利用してユーザー間で解決させる仕組みを作るのもアリかと思います。

サイトコレクションおよびサイトを管理者に渡して「はい、ご自由に」というやり方で運営をしていて、利活用されなくて困っている企業のIT管理者がいらしたら、運営・教育の重要性を少しでも感じていただければと思います。

Nintex Forms 「名前付きコントロール」と「アイテムのプロパティ」の違い

【先に結論】

「名前付きコントロール」:フォーム上でリアルタイムに反映される。
「アイテムのプロパティ」:保存して列に値が落ちた後に反映される。

※今後はなるべく結論を先に書く構成で記事を書きたいと思います。


条件を記述する時などに表示される「数式パレット」ダイアログ内のタブには、「ランタイム関数」「共通」「アイテムのプロパティ」「名前付きコントロール」があります。
その中の「アイテムのプロパティ」「名前付きコントロール」について。

「アイテムのプロパティ」は実際の列名が表示されています。

「名前付きコントロール」は「名前」欄に入力してあるコントロール名が表示されます。

ただし、名前欄を埋めていれば全てのコントロールが表示されるわけではなく、ラベルに名前を入力してもここには表示されません。しっかり検証したわけではないのですが(無責任!)、SharePoint側に列として存在するコントロールであり、名前が入力されているコントロールが条件のようです。

ここで疑問点。
列名が選べる「アイテムのプロパティ」と、列として存在し名前を入力したコントロールが選べる「名前付きコントロール」。結局、同じモノじゃないですか。

でも大きな相違点が2点ほどありました。

【相違点1】反映のリアルタイム性

両者は同じモノのようで厳密には違います。

「アイテムのプロパティ」は列の値を参照します。つまり、一度保存をしてSharePoint的に列に値が落ちないと反映されません。

「名前付きコントロール」はコントロールの値を参照します。つまり、保存をしなくてもForms上に入力もしくは選択された値がリアルタイムに反映されます。

このリアルタイム性の違いで使い分けるようですね。検証してみます。

select列の値を選択するとパネルが表示される仕組みを作りました。もちろん「名前付きコントロール」と「アイテムのプロパティ」両方。

selectでAを選択すると、「名前付きコントロール – A」パネルのみ表示されます。リアルタイムに反映されるからです。値に落ちないと反映されないアイテムのプロパティの方は、この時点では表示されません。

この状態で保存をし、アイテムを開いてみます。そうすると、「アイテムのプロパティ – A」も表示されました。値が落ちないと反映されないからです。

【相違点2】式をテキストエディタやExcel経由でコピペできる・できない

どちらも数式パレットで選択して張り付けると、数式欄には赤字で下線が引かれた状態で表示されます。
▼名前付きコントロールの「Select」を選択

▼アイテムのプロパティの「select」を選択

単なるテキストではないので手入力はできず、かならず上の列名・コントロール名をダブルクリックして式に挿入します。この式はコピーをして別のルールなどにペーストしても、赤字下線でペーストされ、しっかり列名・コントロール名として認識されます。ここまでは問題ありません。
しかし、例えばこの式をテキストエディタなどにペーストして加工した場合、更にテキストエディタからコピーして数式パレットにペーストすると、赤字下線ではなく単なるテキストとしてペーストされるだけで、列名・コントロール名を指定した事にならず、式としては無効です。
つまり式はテキストエディタなどを経由するとコピペができないんです。これ地味に厄介です。(できる方法があったら教えてください!)

ただ、「アイテムのプロパティ」を選択して作った式は、数式パレット上では同じく赤字下線ですが、その後ルールを再度見るとなんか変わっています。

{ItemProperty:select}
selectという列なので列名と内部名がイコールになっているので例としては良くなかったのですが、「テスト」という列名だと「{ItemProperty:_x30c6__x30b9__x30c8_}」となるので、やはり「{ItemProperty:列の内部名}」です。

さて、この{}で表示された「アイテムのプロパティ」は赤字下線ではないです。なので手入力もできるしテキストエディタ経由でコピペもできるんです。

Nintex FormsでYammer??

以前「Nintex FormsでDropbox??」という記事を書いて、Forms内のある場所で「Dropbox 削除」という表記があり、Dropboxと連携するのかと思ったらそういうわけでもなく、英語版の表記は「Delete」だったので日本語訳した際になんでDropboxが紛れ込んだのか意味不明と書きました。

【参照】Nintex FormsでDropbox??

同様の事が他にもあったので紹介します。

Formsでコントロールを必須項目にしたく、ルールの種類で「検証」を選択すると…

「Yammer メッセージ」??
Yammerはマイクロソフトの製品なので、Dropboxよりも連携しそうな雰囲気を醸し出しています。ただ、検証とYammerはどう連携するんだろう?Yammerに投稿される?う~む…

結論はやはり別にここでは連携しないようです。
英語版を見てみると…

「Message」

でた!Yammerなんて記載はないじゃない。またまた日本語訳した際に紛れ込んだようですね。しっかしDropboxといいYammerといい不思議ですね。

という事で、はじめてこれを見た時に混乱しますが、これは条件が合わなかった際(必須項目を設定したなら未記入だった場合)、コンテンツエリア上部に赤文字で出すテキスト文です。

こちらも、もしYammerに意味があるなどご存知の方はご一報いただければと思います。

Nintex Forms 非表示ルールを複雑に組むと並び順がおかしくなる挙動と対策

SharePointの標準ではできないFormsの様々な機能の中のよく使われそうな機能が、表示・非表示のルールかと思います。別の選択肢でAを選択するとAパネルが表示され、Bを選択するとAパネルは消えてBパネルが表示されるみたいな。非常に便利な機能ですが、クセがあります。

サンプルとしてこのようなフォームを作りました。
上部操作エリア内にある選択肢でそれぞれのパネルの表示・非表示を制御します。

■想定する挙動

  1. ABC全パネルを選択すると → 上からABC
  2. 「A-非表示」にすると → 上からBC
  3. 「A-表示」にすると → 上からABC
  4. 「B-非表示」にすると(…省略)

このように、Formsで配置した上からABCの順番は崩れずに、表示・非表示で自在に制御できるようにしたい。

■想定外な挙動

  1. 未選択 → 全て非表示
  2. 「B-表示」にすると → 上からB
  3. 「A-表示」にすると → 上からBA
    えっ??ABじゃなくてBA???

つまり、Forms上で正しく上からABCとパネルを並べても、表示させるラジオボタンをクリックするパターン次第で、配置順がABCにならなくなる。
これは例えば業務フロー順にパネルを表示・非表示させるとして、その順番が入れ替わってしまったら困りますよね。これ、半日ほど試行錯誤して原因と解決方法がわかりました。

■原因

といっても明確に原因がわかったわけではなく、想定外な挙動をするパターンが判明しただけです…。

隙間なくキレイにパネルを配置した際に起きる現象でした(なんてこった)。

■解決方法

パネルを1マスずつ空けて配置しなおします。

先ほどの想定外な挙動と同じ動作をしますと…

  1. 未選択 → 全て非表示
  2. 「B-表示」にすると → 上からB
  3. 「A-表示」にすると → 上からAB
    BAではなく、ちゃんとABになりました。他にも色々なパターンで表示・非表示を繰り返しましたが、上からABCが崩れることはありませんでした。

 

表示・非表示の際にはパネルが重なってしまっても思った挙動になりませんが、まさかキレイに配置してもこのような挙動になるとは思いませんでした。

通常はパネルとパネル、コントロールとコントロールをキレイに配置しても問題ありませんが、もしこのような挙動になる、もしくはしようとしている場合は、1マス空けて配置すると良いです。

Nintex Forms コントロールのクセと対策 その2

コントロールを作っているとたまにコントロール内にスクロールが発生する事があるかと思います。この状態でコントロールを移動させたい時に気をつけたい点があります。

スクロール部分をドラッグしてしまうと、ドロップしてもコントロールは離れません。接着剤でくっついてしまったかのごとく離れません。これ結構焦ります。

何度左クリックしても離れません(たまに離れる事もありますが…)。

右クリックをすると離れますが、掴んだコントロールや入れ子にしているパネルが瞬間移動で意図しない場所に動いたりします。

また、くっついてしまった状態で、画面外でクリックすると、コントロールが消えてしまいます。しかも高確率で元に戻すボタンを押しても戻ってきません。

つまり、コントロールの瞬間移動か失踪事件です。このようにNintex Formsは結構動作が不安定だったりします。複雑に作れば作るほど、ドキドキします。

【対策】

  • コントロールにスクロールが出た場合は絶対にスクロール部分をクリックしない。
  • マメに保存や公開をし、おかしな事になったら一旦閉じて元に戻しましょう。
  • 複数人で作業をしている場合は、他メンバーが壊してしまう可能性もあるので、マメにエクスポートをするとなお良し。

SharePoint 選択肢列の「選択肢を追加できるようにする」を「はい」にした場合の文言がわかりやすくなっていた!

SharePoint2007時代からSharePointを触っていて、日本語訳に難がある箇所がところどころありました。
例えばアイテムの「閉じる」ボタン。ブラウザ操作で「閉じる」はウインドウもしくはタブが閉じるの意味を連想するので違和感を覚えていました。実際は1つ前のページに戻る、もしくはそのリスト・ライブラリの既定のビューに戻るんですよね。現にユーザーからもウインドウが閉じるかと思って閉じるボタンをクリックした事はなかった、なんて声も出ていました。

話を戻して…
日本語訳が微妙であまり使えなかった機能のひとつに、この記事のタイトルのとおり、選択肢列の「選択肢を追加できるようにする」の機能があります。これはつまりラジオボタンやチェックボックスなどの選択肢で、該当なしの場合に自分で記入できるいわゆる「その他」という選択肢。

これがSharePoint2007だと…

この「選択肢を追加できるようにする」を「はい」にすると…

「値を指定してください」なんて文言なんです。どうも微妙な日本語なのでよろしくないです。特にアンケートリストでアンケートをとる際に利用したいシーンが多いのですが…。

ちなみにこの文言は基本操作では変更できません。仕方ないのでJavascriptを使って変更したり、ユーザーにこういうものだと周知させてこのまま使ったりしていました。

それが!

恥ずかしながらこないだ気がついたのですが、今は文言が変わっていました。

SharePoint2013だと…

「その他 (テキストを入力してください):」
あら、問題ないじゃないですか。

いつから変わったんだろう…

SharePoint2010でも変わっていなかったと思うんだよなぁ。

SharePoint2013に関しては全く記憶がなく…。

これからは気兼ねなく使えそうです。

SharePoint アプリのURLを任意のURLにしたい

SharePointに関わる多くの人が既知の事であっても、僕が初心者の頃に試行錯誤した事も念のため記録に残します。

アプリを作成する際に、気にしない人は気にしませんが、気にする人は気にするのがURLです。正しく言えば「URLの一部」ですが、とりあえず読み進めてください。

アプリを作成する際に「名前」を入力するのですが、ここに日本語のみを入力すると、
161226_2_01

できたアプリのURLはこのようになります。
161226_2_02

今回リストを例にしましたが、サイト以下のURLは「/Lists/List2」となりました。アプリのURLとはここで言う「List2」にあたる場所です。リスト系は/Lists/配下だし、ライブラリ系はサイトURL配下です。

サブサイト作成の場合は、以下のように「タイトル」のほかに「URL名」という欄があり、URLが指定できますよね。しかしアプリ作成の場合は、この欄がありません。
161226_2_09

話をアプリに戻し、名前が日本語のみで作られたリストは、それが増えるごとに以下のような法則でURLが生成されます。

/Lists/List
/Lists/List1
/Lists/List2
/Lists/List3

つまり、このリスト「List2」は日本語のみで名前を入力して作られた3個目のリストという事です。

名前に日本語と英数半角が混ざった場合は、英数半角のみを抽出してURLになります。
例えば、ちょっとアホな遊びですが、

このような名前で作成すると…
161226_2_07

このように英数半角のみ抽出してURLが作られます。
161226_2_08

で…、Lists/List2じゃなくて、/Lists/informationにしたいという要望があるかと思います。

じゃどうしたら良いかというと、以前列の内部名を任意の英数にする方法を紹介したかと思いますが、それと同じ方法で実現できます。

アプリ作成時に名前欄にURLにしたい英数半角を入力して作成します。
161226_2_03

作成後に設定画面で名前欄を表示させたいアプリ名に変更します。
161226_2_04

161226_2_05

こうすれば、アプリ名もURLも任意のものになります。例では「情報」というアプリ名で、「information」というURLです。
161226_2_06

注意すべき点は、アプリ名は後で変更できますがURLは一度作成時に確定したら変更できない点です。

例えば、アプリ名を英訳して英単語をURLにしたとします。運営開始後にアプリ名を変更したとします。そのアプリ名の日本語とURLの英語が全く別物になってしまうと、逆に違和感を覚えることになってしまうので、あえてURLは数字の連番にするなどもアリかと思います。

SharePoint でアクセス権限を付与する際に気をつけたい事 ~電子メール招待状~

SharePointでは何をする・させるにしても権限付与の作業が必要ですよね。ユーザーに直接アクセス許可を付与したり、SharePointグループにユーザーを追加したり。ユーザーだけでなくセキュリティグループなどを追加したり。

その中の注意点は色々ありますが、今回注目する点は招待状メールの送信機能です。文字通り、権限が付与されると該当ユーザーに招待状メールが届く機能ですが、権限付与画面で送信するかしないかのチェックボックスがあります。初期値はチェックされた状態、つまり招待状メールが送信される状態です。これがなかなか怖い。

TPOで送信するかしないかをチェックボックスで選べば良いだけなのですが、使い方を間違えるとスパムメール的にもなってしまいますし、管理者に問い合わせが殺到するような事にもなりかねないです。初期値がチェックされた状態なので、ウッカリも多いです。

これ、SharePoint2007では、付与する前に目に見えるところにチェックボックスがあったんですよね(SharePoint2010もそうだったような気がしますが、記憶が…)。試した事がないのでわからないけど、「NT AUTHORITY\Authenticated Users」に権限を付与する際に、このチェックボックスがチェックされた状態で権限を付与したら…いわゆる全従業員にメールが送信されてしまうんでしょうかね。そしたら従業員数が多い会社ほど事故ですよね。怖いんでいつもこの作業をする場合は慎重にチェックが外れている事を確認して付与していました。

で、これは個人的は元に戻してもらいたいと思っているのですが、SharePoint2013ではこのチェックボックスがかなり気がつかないところにあるんですよね。というより隠されているんです。SharePoint2013に触れはじめた時は、メール招待状の機能自体がなくなったのかな?と思うくらい。でも、まだ存在するんですよね。しかもチェックされた状態は変わらず、余計事故が起きやすい状態で。

161226_01
具体的には左下にひっそりと「オプションの表示」というテキストがあり、これがリンクテキストだという事すらなかなか気がつかず、これをクリックすると展開され、その中にチェックボックスがあるんですよね。

161226_02
わざわざ、初期値がチェックされた状態で。これはトラップ??と思うくらい。

さて、それではどうしたら少しでも事故やトラブルが防げるのか?ググると同じように初期値がチェックされた状態を危惧する声もあり、初期値ではチェックが外れているように設定で変更できないか?という問い合わせもあり、サイトコレクションの設定やサーバーの全体管理からは変更できず、サーバー内のとあるファイルをイジる解決方法があるのですが、Microsoftのサポート対象外になってしまうという点からも、ちょっと厳しいのではと思います。

あとは必殺「運用でカバー」ですよね。

まずは、利用者に招待状メールを周知させる方法。つまり、送信されてしまった後を考える事。そうすれば少なくともサーバー管理者への問い合わせは減るのかなと思いますが、若干ネガティブな対策です。

次に、アクセス権限を設定できるサイト管理者などへの教育・周知という方法。つまり、送信される前を考える事。ただし、サイト管理者が多いほど、ヒューマンエラーの確率が増えますね。ホント、ウッカリ失念してしまいがちなので。

次に、アクセス権限の設定はサーバー管理者が掌握する方法。つまり、権限管理自体を特定多数(不特定多数)に管理させない事。実際にアクセス権限の問題はかなり多岐に渡るトラブルや問題にもなるので、サイト管理者にアクセス権限の設定ができないアクセス許可レベルを付与している会社も、少なくはないと思います。これにより一極集中してしまったサーバー管理者の作業は大変になりますが、より把握している者が作業をすることにより、ヒューマンエラーの確率はサイト管理者にアクセス権限管理を委譲するよりは、減ると思います。

Microsoftのサポート対象外になってしまっても構わない場合は、設定レベルでチェックを初期値では外す方法が理想なのかもしれないです。(サーバーの全体管理やサイトコレクションの管理で容易に設定できれば良いのですけどね。)それ以外の場合は、各環境に合わせ、上述のようないわゆる運用でカバーをしていくしかないっぽいです。

ちなみに僕は今までおよそ何千何万回も設定をしてきましたが、一度もこれで事故やクレームはありませんでした。実際運営していると招待状メールが必要な事は全くありませんでした。例えばとある部署が自部署のサイトを公開する際には、だいたいサイト管理者か部署の部長さんあたりが自分から部内や周知したい人たちにメールをしたり、社内ポータルの掲示板に掲載したりする場合がほとんどでしたからね。

なので、とにかくチェックを外すクセを徹底的につけていました。

SharePoint 「選択肢」列とビューのグループ化の怪奇現象

【1】「選択肢」で複数選択が可能なチェックボックス型で列を作成します。
01

【2】適当にアイテムを作ります。
02

【3】この「カテゴリ」という選択肢列でビューでグループ化をさせたくても、選択できません。
03

つまり、チェックボックスの選択肢列はグループ化ができない仕様です。

じゃ、ひねくれてこんな検証を…

【4】作成した「カテゴリ」列を編集でラジオボタンに変更します。
04

【5】投稿済みアイテムはすでに値は落ちているので、ラジオボタンだけど「A;B」という現象が。
05

【6】この状態だとラジオボタンなのでビューのグループ化で「カテゴリ」列は選択可能になります。
06

【7】結果
07

このスクショだけを見ると、チェックボックスの選択肢列はグループ化ができているように見えます。しかし、実態はすでにラジオボタンに設定変更をしているので、今後追加されるアイテムは複数選択できません。

じゃ、

【8】この状態で再度チェックボックスにすると?
08

【9】なんか壊れた!!!
09

【10】この状態でビューのグループ化を見るとグループ化されていない事になっています。
10

つまり、結局のところ、チェックボックスの選択肢列はグループ化ができないという結果でした。