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

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

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

これがSharePoint2007だと…

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

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

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

それが!

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

SharePoint2013だと…

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

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

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

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

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

Nintex FormsでDropbox??

Nintex Formsでフォームを作成すると、添付ファイルのところに「Dropbox 削除」って出てくるんです。

▼編集画面の添付ファイルコントロール

▼添付ファイルをアップした後の表示

「え?Dropbox??Dropboxと連携でもするの??デフォルトで??」

って思っちゃうじゃないですか。「Dropbox」って言ったらオンラインストレージサービスのDropboxが有名じゃないですか。

これややこしいですね。Dropboxと連携する機能はNintex Workflowにはあるようですが(詳しくないです)、ここに関しては別に連携しているわけではないんですよね。ただのリストの添付ファイルなんですよね。

添付ファイルの他にも出てきます。Formsの編集画面でコントロールを選択した際のリボンを見ると…

出た!Dropbox 削除!
これは結局、コントロールを削除するメニューなんですよね。

ちなみに英語版はどうなっているのかな?とググってみると…「添付ファイルを追加」は「Add Attachment」、「Dropbox 削除」は「Delete」でした。

添付ファイルの削除だけでなく、コントロールの削除にもDropboxが出てくるところを見ると、Deleteを日本語訳した際に「Dropbox 削除」になったんでしょうかね。

Dropboxはいったいどこから出てきたんだ…、謎です。ややこしいので正直「Dropbox」という表記は表示させたくないですね。Formsの編集画面のリボンの方はイイとしても、添付ファイルの部分に関してはユーザーが見る部分なので。JSで消せそうだし、CSSでも消せそうなので、そのうちやってみようと思います。

今回はとりあえず問題提起。もしDropboxに意味があるなどご存知の方はご一報いただければと思います。

チーム内での意思疎通を図るには用語統一は大事

SharePointに限らず共同作業をする際にチーム内で意思疎通を図るには、用語を統一させる事は非常に大事な要素のひとつだと思います。

IT業界で一般的に使うであろう汎用用語はSharePoint内では別の言い方があったりして、それをチーム内で同じモノを指すのに別々の言葉を使っていたらやはり認識齟齬が生じる可能性が高くなります。例えば「オブジェクト」という言葉は汎用的ですが抽象的です。これを多様するとどの粒度であったりそもそも何を指しているかが伝わりづらいです。

過去に2件記事にしたのですが、SharePoint内でも表記が揺れている事もありますので、この場合は、よりメジャーである方の言葉を選び、チーム内で統一させると良いと思います。

この用語統一を図るにはチーム内で用語集を作ると良いかと思います。それこそSharePointのリストなりWikiページなりを活用して。
用語集を作り上げる過程でも、チームメンバーの知識の再確認にもなりますし、間違いや勘違いなどの洗い出しにもつながりますね。

同じくこのようなブログにおいても、表記揺れがあると読者の混乱の元にもなりかねないので、気をつけたいと思います。

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

Nintex FormsはGUIでグリグリ操作できるのは便利ですが、クセがすごい!(千鳥のマネじゃないです)。でも、クセを把握した上でコツさえ掴めば大丈夫です。

その1として、コントロールをキレイに配置した後に、コントロールの大きさを調整したい場合、該当コントロールを選択し、ドラッグしてマウスを動かすと、なぜか隣のコントロールの大きさが変わってしまう事がある件について。

これはコントロールの重なり順に関係してくるようです。コントロールは一応レイヤーの概念があり、PowerPointの「オブジェクトの順序」みたいなもので、コントロールの配置順に重なっていくイメージです。(厄介なのは最前面と最背面しかない事ですが。)

▼コントロールがキレイに配置されている場合。
▼コントロールを全て選択すると重なり具合がわかります。

隣接されたコントロールが重なると、この上になっている方を優先して掴むようです。(というより掴める範囲が上になっている方が広いという表現の方が正しいです。)

今置いてるカーソルの位置で掴んだらどちらのコントロールが掴めるかの判定は、カーソルを置いて1秒程度で表示されるコントロールの説明ダイアログで判定してください。

厄介なのは一旦操作したいコントロールを選択した上で、サイズを変える□を掴んだとしても、やはり上になっている隣のコントロールを掴んでしまうんです。

▼「body」というラベルを左寄せのまま横幅を狭めたい場合、ラベルを選択し、右の□を掴もうとします。(すでに説明ダイアログには「複数行テキストボックス」と表示されてしまっていますので、この後の挙動は推測できてしまいますが…)

▼案の定、右隣の複数行テキストボックスコントロールが左に広がってしまい、意図した操作ができません。

じゃ、どうしたら良いのか?
1px単位の細かさでマウスを動かして良さげな場所で掴めば意図したコントロールの□を掴めますが、正直ダルいです。

▼ブラウザを200%くらいに拡大すると、ギリギリの場所を掴むのに少しは楽になります。

▼他の方法としては、コントロールを選択して、下矢印キー(↓)などで少しズラす。そうすると隣のコントロールの□と重ならないので掴めます。リサイズした後に元の場所に戻せばOKです。

こんな感じで結構イラっとくる事が多いのですが、挙動を把握した上で、コツさえ掴めば楽しくデザインできます。たぶん…

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

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

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

Nintex Forms divパズルの仕様をもう少し掘り下げてみる

Nintexの中でもFormsは若干マニアックなようなので、果たしてFormsの記事のニーズはあるかどうか疑問ではありますが、実際自分で試行錯誤している中でググっても特に日本語の情報が薄いので、同様に困っている後発の方々のお役に少しでも立てたらと思います。

前回、コントロールがdivでパズル状態であるという説明をしましたが、もう少しその仕様を掘り下げてみます。

まず、カスタムリストに何も手を加えずにFormsを起動し、タイトル列のラベルとコントロールのみを残し、他を全て削除してみます。
161221_01

これで一番シンプルな構成になったので解析開始。
161221_02

とりあえずIEの開発者ツールを見ます(個人的にはFireFoxのFirebugの方が好きなのですが…)。SharePointあるあるですが、シンプルなデザインなのに中身は超入れ子状態のdivを展開しながら色々観察すると、nf-ではじまるclassがあり、なんとなくここからNintexのターンだなと感じてきます。そこから更に入れ子が激しいのですが、把握するためにも1つずつ展開させていき、最終的にtdが1つしかないtableに出会います。

161221_03
↑このtdの次のdiv class=”nf-outer ms-formbody”がFormsの大枠にあたり、インラインでposition:relative;が記述されています。なので、この左上の位置がコントロールの基点ですね。

161221_04
↑次にラベルです。このスクショでは見切れてしまっていますが、このコントロールの枠のdivにはclass「.nf-filler-control」があって、これにposition:absolute;が記述されています。で、インラインでtopとleftが指定されており、このラベルは基点に置いてあるのでtop:0;left:0;です。

161221_05↑次にタイトル列のコントロール。ここに先ほど見切れていた「.nf-filler-control」の記述がありましたね。position:absolute;が記述されています。で、基点からの位置でtop:0px;left:200px;が指定されています。ラベルではwidth:200px;が記述されていたので、キレイに並ぶという感じです。

こういう仕組みで基点からtopとleftで位置を指定して、パズルが組みあがるという仕様です。

ちなみにコントロールの枠のdivから実際のinputタグの間に更に3個ものdivがありました。
見た目はシンプルなように見えても、中身は複雑で読み解くのが面倒ですね。
161221_06

しかし、SharePoint自体のデザインカスタマイズでもそうですが、この見た目シンプルでも中身は複雑である事は逆手にとることもでき、CSSのみのデザインカスタマイズをおこなう際に、セレクタを駆使すれば難易度は高いけど自由度が意外と高くなったりしますね。ほら、僕はゴリゴリのカスタマイズや開発は基本的には反対派なので。

Nintex Forms 簡単そうで簡単じゃないフォームのデザイン

Nintex FormsはGUIでコントロールを配置できるので非常に使いやすい!デザイン面では最初はそう思っていました…。

Formsを特に教わったこともなく使い始めてGUIを見た時に、作業手順としては、とりあえずまずはキレイにコントロールを配置して、後からCSSを記述しようと考えたんです。これは結果的に間違いでした。
デザイン面でのFormsの特徴やクセや配慮する点を把握し、まずはモックを作って確認したり、設計を先にしないと、後々苦労する作業手順です。

まずデフォルト状態で仕様を確認します。Formsを起動すると、すでに追加済みの列は勝手にキレイに配置してくれます。
01

ソースを見るとコントロールってdivをパズルのように配置しているんですよね。コントロールの自由度が高いのもtableレイアウトじゃ無理ですもんね。
大枠がposition:relativeになっていて、配置するコントロールがposition:absoluteでtopとleftで基点を指定する感じ。(パネルを入れ子にすると…という話はここではとりあえずしません。)

次にFormsのデフォルトのデザインです。
02Formsのデフォルトのデザインの行区切りのボーダーに関しては、各コントロールであるdivに.nf-sectionというclassが設定されていて、これのborder-topが指定されている感じ。
余談ですが、ここにmargin-top:-1px;が記述されているのですが、後々Formsの仕様を把握すればこの記述は納得するのですが、この話はまた別の機会に。

さて、Formsを使用する際に、このデフォルトのデザインでは上下(厳密には上のみ)のボーダーのみですが、デザイン面でのカスタマイズとして、フォームをTableのように表組みしたいニーズは多いと思います。Table的にth部分とtd部分の背景色を変えたり、枠線を上だけでなく上下左右全てつけたり。

冒頭の手順の通りに、GUIでコントロールをキレイに配置をしたら、後はCSSで.nf-sectionに背景とボーダーを指定すれば完成!楽!と思いきや…

むむむむむ…
03
選択肢列のラベルが縮んでる!よく見ると数箇所でボーダーがズレていたりする!1px程度の誤差ですが、仕事としてはダメですよね。

設定画面に戻ると、とりあえず選択肢列に関してはコントロール自体が縮んでいました。
01
デフォルトで配置される選択肢列(ラジオボタン・チェックボックス)は修正が必要です。

04
選択肢列のラベルとコントロールを縦に広げて直しました。

だいぶよくなったけどボーダーのズレは気持ち悪いです。
05
更に、「添付ファイルを追加」をクリックすると…添付ファイルのコントロールに左のラベルのサイズは追随せず、かなり段が崩れて、これまた気持ち悪くなります。

つまりそう簡単にはキレイなテーブルにはならないんです。

残念ながら本記事ではここまでです。これをどう解決してキレイなテーブルにできるのか?これは僕もかなり苦労したところですが、コツがたくさんあって結構重い内容なので、問題提起だけして放置するのも申し訳ないですが、今後の記事にご期待ください。

予告としてFormsで大事な要素は

  • パネルがキモだよ
  • 並べ順も大事だよ
  • ボーダーは下線が問題
  • かなり変則的な工夫が必要だよ
  • コントロールによってはclassが二重になっている事もあるよ

こんな感じでしょうか。仕事もプライベートも色々と多忙なので更新頻度が低くなってしまいますが、気長に情報発信していこうと思います。

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

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

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

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

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

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

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

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

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

【7】結果
07

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

じゃ、

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

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

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

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

SharePoint 列の内部名 Part2

■内部名の文字数の上限

長い列名を作成した場合でも内部名の長さは一定の長さから変わらなかったので、ちょっと検証してみました。

「内部名テスト」という列名で列を作成すると、内部名は以下のとおり。
_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から連番が振られる。

ここまで調べて思ったこと。
この情報、そんなに必要じゃないので時間の無駄だったかも。