FormsはGUIでグリグリ操作できるのは便利ですが、クセがすごい!(千鳥のマネじゃないです)。クセを把握した上でコツさえ掴めば大丈夫です。その1として、コントロールをキレイに配置した後に、コントロールの大きさを調整したい場合、該当コントロールを選択し、ドラッグしてマウスを動かすと、なぜか隣のコントロールの大きさが変わってしまう事がある件について。これはコントロールの重なり順に関係してくるようです。コントロールは一応レイヤーの概念があり、PowerPointの「オブジェクトの順序」みたいなもので、コントロールの配置順に重なっていくイメージです。(厄介なのは最前面と最背面しかない事ですが。)▼コントロールがキレイに配置されている場合。▼コントロールを全て選択すると重なり具合がわかります。隣接されたコントロールが重なると、この上になっている方を優先して掴むようです。(というより掴める範囲が上になっている方が広いという表現の方が正しいです。)今置いてるカーソルの位置で掴んだらどちらのコントロールが掴めるかの判定は、カーソルを置いて1秒程度で表示されるコントロールの説明ダイアログで判定してください。厄介なのは一旦操作したいコントロールを選択した上で、サイズを変える□を掴んだとしても、やはり上になっている隣のコントロールを掴んでしまうんです。▼「body」というラベルを左寄せのまま横幅を狭めたい場合、ラベルを選択し、右の□を掴もうとします。(すでに説明ダイアログには「複数行テキストボックス」と表示されてしまっていますので、この後の挙動は推測できてしまいますが...)▼案の定、右隣の複数行テキストボックスコントロールが左に広がってしまい、意図した操作ができません。したら良いのか?1px単位の細かさでマウスを動かして良さげな場所で掴めば意図したコントロールの□を掴めますが、正直ダルいです。▼ブラウザを200%くらいに拡大すると、ギリギリの場所を掴むのに少しは楽になります。▼他の方法としては、コントロールを選択して、下矢印キー(↓)などで少しズラす。すると隣のコントロールの□と重ならないので掴めます。リサイズした後に元の場所に戻せばOKです。こんな感じで結構イラっとくる事が多いのですが、挙動を把握した上で、コツさえ掴めば楽しくデザインできます。アプリのURLを任意のURLにしたいSharePointに関わる多くの人が既知の事であっても、僕が初心者の頃に試行錯誤した事も念のため記録に残します。アプリを作成する際に、気にしない人は気にしませんが、気にする人は気にするのがURLです。正しく言えば「URLの一部」ですが、とりあえず読み進めてください。アプリを作成する際に「名前」を入力するのですが、ここに日本語のみを入力すると、できたアプリのURLはこのようになります。今回リストを例にしましたが、サイト以下のURLは「/Lists/List2」となりました。アプリのURLとはここで言う「List2」にあたる場所です。リスト系は/Lists/配下だし、ライブラリ系はサイトURL配下です。サブサイト作成の場合は、以下のように「タイトル」のほかに「URL名」という欄があり、URLが指定できますよね。アプリ作成の場合は、この欄がありません。話をアプリに戻し、名前が日本語のみで作られたリストは、それが増えるごとに以下のような法則でURLが生成されます。/Lists/List/Lists/List1/Lists/List2/Lists/List3...つまり、このリスト「List2」は日本語のみで名前を入力して作られた3個目のリストという事です。名前に日本語と英数半角が混ざった場合は、英数半角のみを抽出してURLになります。アホな遊びですが、このような名前で作成すると...このように英数半角のみ抽出してURLが作られます。...、Lists/List2じゃなくて、/Lists/informationにしたいという要望があるかと思います。したら良いかというと、以前列の内部名を任意の英数にする方法を紹介したかと思いますが、それと同じ方法で実現できます。アプリ作成時に名前欄にURLにしたい英数半角を入力して作成します。作成後に設定画面で名前欄を表示させたいアプリ名に変更します。↓こうすれば、アプリ名もURLも任意のものになります。例では「情報」というアプリ名で、「information」というURLです。注意すべき点は、アプリ名は後で変更できますがURLは一度作成時に確定したら変更できない点です。アプリ名を英訳して英単語をURLにしたとします。運営開始後にアプリ名を変更したとします。そのアプリ名の日本語とURLの英語が全く別物になってしまうと、逆に違和感を覚えることになってしまうので、あえてURLは数字の連番にするなどもアリかと思います。~電子メール招待状~SharePointでは何をする・させるにしても権限付与の作業が必要ですよね。ユーザーに直接アクセス許可を付与したり、SharePointグループにユーザーを追加したり。ユーザーだけでなくセキュリティグループなどを追加したり。その中の注意点は色々ありますが、今回注目する点は招待状メールの送信機能です。文字通り、権限が付与されると該当ユーザーに招待状メールが届く機能ですが、権限付与画面で送信するかしないかのチェックボックスがあります。初期値はチェックされた状態、つまり招待状メールが送信される状態です。TPOで送信するかしないかをチェックボックスで選べば良いだけなのですが、使い方を間違えるとスパムメール的にもなってしまいますし、管理者に問い合わせが殺到するような事にもなりかねないです。初期値がチェックされた状態なので、ウッカリも多いです。これ、SharePoint2007では、付与する前に目に見えるところにチェックボックスがあったんですよね(SharePoint2010もそうだったような気がしますが、記憶が...)。Users」に権限を付与する際に、このチェックボックスがチェックされた状態で権限を付与したら...いわゆる全従業員にメールが送信されてしまうんでしょうかね。したら従業員数が多い会社ほど事故ですよね。怖いんでいつもこの作業をする場合は慎重にチェックが外れている事を確認して付与していました。これは個人的は元に戻してもらいたいと思っているのですが、SharePoint2013ではこのチェックボックスがかなり気がつかないところにあるんですよね。いうより隠されているんです。SharePoint2013に触れはじめた時は、メール招待状の機能自体がなくなったのかな?と思うくらい。チェックされた状態は変わらず、余計事故が起きやすい状態で。具体的には左下にひっそりと「オプションの表示」というテキストがあり、これがリンクテキストだという事すらなかなか気がつかず、これをクリックすると展開され、その中にチェックボックスがあるんですよね。初期値がチェックされた状態で。これはトラップ??と思うくらい。それではどうしたら少しでも事故やトラブルが防げるのか?ググると同じように初期値がチェックされた状態を危惧する声もあり、初期値ではチェックが外れているように設定で変更できないか?という問い合わせもあり、サイトコレクションの設定やサーバーの全体管理からは変更できず、サーバー内のとあるファイルをイジる解決方法があるのですが、Microsoftのサポート対象外になってしまうという点からも、ちょっと厳しいのではと思います。あとは必殺「運用でカバー」ですよね。利用者に招待状メールを周知させる方法。送信されてしまった後を考える事。すれば少なくともサーバー管理者への問い合わせは減るのかなと思いますが、若干ネガティブな対策です。次に、アクセス権限を設定できるサイト管理者などへの教育・周知という方法。送信される前を考える事。サイト管理者が多いほど、ヒューマンエラーの確率が増えますね。ホント、ウッカリ失念してしまいがちなので。次に、アクセス権限の設定はサーバー管理者が掌握する方法。権限管理自体を特定多数(不特定多数)に管理させない事。実際にアクセス権限の問題はかなり多岐に渡るトラブルや問題にもなるので、サイト管理者にアクセス権限の設定ができないアクセス許可レベルを付与している会社も、少なくはないと思います。これにより一極集中してしまったサーバー管理者の作業は大変になりますが、より把握している者が作業をすることにより、ヒューマンエラーの確率はサイト管理者にアクセス権限管理を委譲するよりは、減ると思います。Microsoftのサポート対象外になってしまっても構わない場合は、設定レベルでチェックを初期値では外す方法が理想なのかもしれないです。(サーバーの全体管理やサイトコレクションの管理で容易に設定できれば良いのですけどね。)それ以外の場合は、各環境に合わせ、上述のようないわゆる運用でカバーをしていくしかないっぽいです。ちなみに僕は今までおよそ何千何万回も設定をしてきましたが、一度もこれで事故やクレームはありませんでした。実際運営していると招待状メールが必要な事は全くありませんでした。とある部署が自部署のサイトを公開する際には、だいたいサイト管理者か部署の部長さんあたりが自分から部内や周知したい人たちにメールをしたり、社内ポータルの掲示板に掲載したりする場合がほとんどでしたからね。チェックを外すクセを徹底的につけていました。divパズルの仕様をもう少し掘り下げてみるNintexの中でもFormsは若干マニアックなようなので、果たしてFormsの記事のニーズはあるかどうか疑問ではありますが、実際自分で試行錯誤している中でググっても特に日本語の情報が薄いので、同様に困っている後発の方々のお役に少しでも立てたらと思います。前回、コントロールがdivでパズル状態であるという説明をしましたが、もう少しその仕様を掘り下げてみます。カスタムリストに何も手を加えずにFormsを起動し、タイトル列のラベルとコントロールのみを残し、他を全て削除してみます。これで一番シンプルな構成になったので解析開始。IEの開発者ツールを見ます(個人的にはFireFoxのFirebugの方が好きなのですが...)。SharePointあるあるですが、シンプルなデザインなのに中身は超入れ子状態のdivを展開しながら色々観察すると、nf-ではじまるclassがあり、なんとなくここからNintexのターンだなと感じてきます。そこから更に入れ子が激しいのですが、把握するためにも1つずつ展開させていき、最終的にtdが1つしかないtableに出会います。ms-formbody”がFormsの大枠にあたり、インラインでposition:relative;が記述されています。この左上の位置がコントロールの基点ですね。このスクショでは見切れてしまっていますが、このコントロールの枠のdivにはclass「.nf-filler-control」があって、これにposition:absolute;が記述されています。インラインでtopとleftが指定されており、このラベルは基点に置いてあるのでtop:0;left:0;です。↑次にタイトル列のコントロール。ここに先ほど見切れていた「.nf-filler-control」の記述がありましたね。position:absolute;が記述されています。基点からの位置でtop:0px;left:200px;が指定されています。ラベルではwidth:200px;が記述されていたので、キレイに並ぶという感じです。いう仕組みで基点からtopとleftで位置を指定して、パズルが組みあがるという仕様です。ちなみにコントロールの枠のdivから実際のinputタグの間に更に3個ものdivがありました。見た目はシンプルなように見えても、中身は複雑で読み解くのが面倒ですね。SharePoint自体のデザインカスタマイズでもそうですが、この見た目シンプルでも中身は複雑である事は逆手にとることもでき、CSSのみのデザインカスタマイズをおこなう際に、セレクタを駆使すれば難易度は高いけど自由度が意外と高くなったりしますね。ほら、僕はゴリゴリのカスタマイズや開発は基本的には反対派なので。FormsはGUIでコントロールを配置できるので非常に使いやすい!デザイン面では最初はそう思っていました...。Formsを特に教わったこともなく使い始めてGUIを見た時に、作業手順としては、とりあえずまずはキレイにコントロールを配置して、後からCSSを記述しようと考えたんです。これは結果的に間違いでした。デザイン面でのFormsの特徴やクセや配慮する点を把握し、まずはモックを作って確認したり、設計を先にしないと、後々苦労する作業手順です。デフォルト状態で仕様を確認します。Formsを起動すると、すでに追加済みの列は勝手にキレイに配置してくれます。ソースを見るとコントロールってdivをパズルのように配置しているんですよね。コントロールの自由度が高いのもtableレイアウトじゃ無理ですもんね。大枠がposition:relativeになっていて、配置するコントロールがposition:absoluteでtopとleftで基点を指定する感じ。(パネルを入れ子にすると...という話はここではとりあえずしません。)次にFormsのデフォルトのデザインです。Formsのデフォルトのデザインの行区切りのボーダーに関しては、各コントロールであるdivに.nf-sectionというclassが設定されていて、これのborder-topが指定されている感じ。余談ですが、ここにmargin-top:-1px;が記述されているのですが、後々Formsの仕様を把握すればこの記述は納得するのですが、この話はまた別の機会に。Formsを使用する際に、このデフォルトのデザインでは上下(厳密には上のみ)のボーダーのみですが、デザイン面でのカスタマイズとして、フォームをTableのように表組みしたいニーズは多いと思います。Table的にth部分とtd部分の背景色を変えたり、枠線を上だけでなく上下左右全てつけたり。冒頭の手順の通りに、GUIでコントロールをキレイに配置をしたら、後はCSSで.nf-sectionに背景とボーダーを指定すれば完成!楽!と思いきや...むむむむむ...選択肢列のラベルが縮んでる!よく見ると数箇所でボーダーがズレていたりする!1px程度の誤差ですが、仕事としてはダメですよね。設定画面に戻ると、とりあえず選択肢列に関してはコントロール自体が縮んでいました。デフォルトで配置される選択肢列(ラジオボタン・チェックボックス)は修正が必要です。選択肢列のラベルとコントロールを縦に広げて直しました。よくなったけどボーダーのズレは気持ち悪いです。「添付ファイルを追加」をクリックすると...添付ファイルのコントロールに左のラベルのサイズは追随せず、かなり段が崩れて、これまた気持ち悪くなります。簡単にはキレイなテーブルにはならないんです。残念ながら本記事ではここまでです。これをどう解決してキレイなテーブルにできるのか?これは僕もかなり苦労したところですが、コツがたくさんあって結構重い内容なので、問題提起だけして放置するのも申し訳ないですが、今後の記事にご期待ください。予告としてFormsで大事な要素はパネルがキモだよ並べ順も大事だよボーダーは下線が問題かなり変則的な工夫が必要だよコントロールによってはclassが二重になっている事もあるよこんな感じでしょうか。仕事もプライベートも色々と多忙なので更新頻度が低くなってしまいますが、気長に情報発信していこうと思います。【1】「選択肢」で複数選択が可能なチェックボックス型で列を作成します。【2】適当にアイテムを作ります。【3】この「カテゴリ」という選択肢列でビューでグループ化をさせたくても、選択できません。チェックボックスの選択肢列はグループ化ができない仕様です。ひねくれてこんな検証を...【4】作成した「カテゴリ」列を編集でラジオボタンに変更します。【5】投稿済みアイテムはすでに値は落ちているので、ラジオボタンだけど「A;B」という現象が。【6】この状態だとラジオボタンなのでビューのグループ化で「カテゴリ」列は選択可能になります。【7】結果このスクショだけを見ると、チェックボックスの選択肢列はグループ化ができているように見えます。実態はすでにラジオボタンに設定変更をしているので、今後追加されるアイテムは複数選択できません。【8】この状態で再度チェックボックスにすると?【9】なんか壊れた!!!【10】この状態でビューのグループ化を見るとグループ化されていない事になっています。結局のところ、チェックボックスの選択肢列はグループ化ができないという結果でした。長い列名を作成した場合でも内部名の長さは一定の長さから変わらなかったので、ちょっと検証してみました。「内部名テスト」という列名で列を作成すると、内部名は以下のとおり。内=_x5185_部=_x90e8_名=_x540d_テ=_x30c6_ス=_x30ト=スの途中で切れているのでやはり上限があるようです。数えたところ、内部名の文字数の上限は32文字でした。ところが、厳密には違うようです。「test(4文字)」×8個=32文字で上限ちょうどの列を作成します。同じリストに「test」のかたまりを更にひとつずつ追加した列を作ってみます。testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest0testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest1testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest2testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest3testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest4testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest5testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest6testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest7testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest8testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest9testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest10面倒くさかったけど検証終わりました。内部名が同じになってしまうと、自動でオシリに0から数字が振られるようです。10個目はどうだろうと思ったらオシリが2桁に増えました。100個列を作るのは時間がもったいないのでやめますが、この法則だと100個目はオシリが3桁になるんでしょうかね。(列が100個とか運営上は非現実的ですが。)まとめると、内部名は文字列としては32文字が上限。同じ内部名になると33文字目から0から連番が振られる。ここまで調べて思ったこと。この情報、そんなに必要じゃないので時間の無駄だったかも。カスタムリストorお知らせリストSharePointのアプリは大別するとリストとライブラリの2種類ですね。色々な種類のリストやライブラリがあるわけですが、リストに関しては、いわゆる通達や連絡など掲示板的な利用目的の場合、カスタムリストを使うべきか?お知らせリストを使うべきか?というところで迷う事があると思います。僕の場合はずっとお知らせリストを使っていました。理由は受信メール機能です。オンプレのSharePoint2007を長いこと使っていたのですが、オンプレのSharePointにはメールでアイテムを投稿できる受信メール機能があり、これはお知らせリストだけの機能でカスタムリストには加えることのできない機能でした。この機能、メールでアイテムを投稿できると知ると結構使う人が多かったんです。メーリングリストのtoの中に受信メール用アドレスを突っ込めば、メールのバックナンバーが自然に作れるような使い方とか。後で使いたいと言われた時に即対応できるようにお知らせリストばかりを使っていて、カスタムリストはほとんど使っていませんでした。Onlineでは使えないようですね。お知らせリストにこだわる理由がなくなりました。逆にお知らせリストが微妙なのが「有効期限」列の存在があります。カスタムリストはデフォルトでタイトル列のみですが(「更新者」列などは除いて)、お知らせリストには「本文」列と「有効期限」列がリスト作成時にすでに存在します。「本文」は大抵利用する列なので問題ないとして、「有効期限」列ですよ。この「有効期限」列は、非常に微妙なんですよね。普通に考えたらここに日付を入れたら、期限が切れたアイテムは削除されるのかな?と思うじゃないですか。いつまで経っても削除されないんですよね。この列はただの日付を入力する列なんですよ。特別なにかアクションがあるわけじゃないんです。どこかで聞いた話では、有効期限列は、この列を利用して、例えばビューのフィルターで非表示にするなどご自由にお使いください的な意味だとか。情報管理ポリシーで設定すれば期限切れで削除したりもできますが。「有効期限」列の厄介なのはこの列を削除できない事。列の編集に削除ボタンがないんですよ。有効期限列があればユーザーは有効期限があると思うし、ここに日付を追加してしまうので、この列が機能していないのに存在するのは良くないですよね。リストの詳細設定でコンテンツタイプの管理を許可して、お知らせコンテンツタイプの設定から有効期限列を「非表示」にすれば、削除はされないけど、削除されたようなものにはなります。▼お知らせコンテンツタイプの設定から有効期限を非表示に▼有効期限列は削除はされないけど非表示になります。投稿画面で非表示になっているということは、利用されないので削除みたいなものかと思います。いえ、いちいちこんな設定をするのは面倒ですよね。Onlineであれば、個人的には何も考えずにカスタムリストから作る事になるかな。JSリンクとURLトークンとかいうトラップ※すでにこの手の記事はググれば出てきますが、自分への備忘録です。早めにググればよかったのですが...ハマりました。アプリパーツの編集でJSリンクを適用する欄があり、まぁ普通に考えればどこかにアップロードしたJSファイルのURLを指定すれば良いと思うけど、こんなところにトラップを仕掛けているんですよね。普通のURLでは適用されません。URLトークンなるものがあるんです。トー君?誰?って感じですよ。トークンhttps://msdn.microsoft.com/ja-jp/library/ms431831.aspx↑のページの真ん中くらいに表があります。「~sitecollection」か「~site」あたりを使う感じですね。JSリンクを使う人にはトラップです。僕がSharePointをはじめた7年前は、ググっても日本語の情報が少なかったです。英語が苦手なので数少ない情報源の方々には感謝してもしきれません。今はだいぶ情報を掲載されている日本人も増えてきましたので、ハマったら即ググった方が良いですね。■内部名について列には列名と裏側に内部名が存在します。列名・内部名ともにアプリ内ではユニークです。基本機能のみで利用している場合は内部名を気にする必要はありません。列名は作成後に変更する事ができますが、内部名は変更できません。裏を返せば、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」になりました。これに関しては法則がよくわからないです。深入りしない事にします...。2007/2010/2013の運営・サイト構築を担当。仕事でも登壇活動などをしています。契約し、家庭内活用しています。楽しさを多くの方に伝えられたら、と思っています。当ブログは完全に個人の趣味で運営しています。しているので、正確性に欠けている場合があります。日々変更のあるサービスをネタとして扱っているため、特に古い記事についてはご自身でも調査・検証を行ってください。2019-2020受賞しました。当ブログに掲載されている情報は、必ずしも正確性や安全性を保証するものではありません。掲載された内容によって生じた損害等の一切の責任を負いかねます。当ブログに掲載されている情報は個人の見解であり、所属する団体・組織は一切関係ありません。