モデル駆動型アプリのフォームに関する問題のトラブルシューティング
フォームの読み込み、スクリプトの実行、イベントの操作、またはデータの保存時に発生するフォームを操作する場合は、統一インターフェイスの問題のトラブルシューティングが不可欠です。
この記事は、モデル駆動型アプリ フォームの操作中に発生する可能性のある一般的な問題のいくつかを修正するのに役立ちます。
重要
- この記事で説明するツールは、トラブルシューティングを目的として設計されています。これらは、運用展開での問題のトラブルシューティングに使用できますが、毎日の運用展開シナリオで使用するためのものではありません。
- これらのトラブルシューティング ツールは、特に明記されていない限り (たとえば、ブラウザー タブがモデル駆動型アプリにアクセスする場合)、現在のユーザー セッションにのみ影響します。 システムのカスタマイズを変更したり、他のユーザーやセッションに影響を与えたりすることはありません。 現在のセッションが閉じられると、効果は適用されなくなります。
- ほとんどのツールは、すべての運用環境で使用できます。 記事で言及されているいくつかのツールは、まだ組織に展開されていない可能性があります。新しいツールは定期的に追加されます。
- この記事に一覧表示されているツールは、シナリオに沿って書かれています。 それらを個別に使用して、さまざまなタイプの問題のトラブルシューティングを実行できます。
- URL パラメーターを使用して、さまざまなフォーム コンポーネントを無効にするおよびモニターで登録済みフォームのイベント ハンドラーとライブラリを表示するは、多くのシナリオのトラブルシューティングに頻繁に使用する重要かつ基本的なツールです。
- モニターの使用方法の詳細については、モニターを使用して、モデル駆動型アプリフォームの動作のトラブルシューティングをするを参照してください
URL パラメーターを使用して、さまざまなフォーム コンポーネントを無効にする
フォームに関する問題のトラブルシューティングを実行する場合、問題の原因となった特定のコンポーネントを特定するために、URL パラメーターを使用してコンポーネントを無効にする必要があります。 問題の原因を絞り込むために、フラグを 1 つずつ使用することをお勧めします。 次の URL パラメーターを使用できます。
DisableFormCommandbar
フォームのコマンド バーを無効にします。 フォーム ページのコマンド バーを無効にするだけで、リスト (グリッド)、ダッシュボードなどには対応していません。
https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableCommandbar=trueDisableFormHandlers
すべてのフォーム ハンドラーを無効にします。 DisableFormHandlers=true フラグを使用する場合、次のイベント ハンドラーが無効になります: OnLoad、OnSave、ビジネス ルール、OnChange、TabStateChange。
きめ細かいコントロールのイベントまたはライブラリ インデックスの取得方法の詳細については、モニターで登録済みフォームのイベント ハンドラーとライブラリを表示するを参照してください。
https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormHandlers=true&flags=DisableFormHandlers=eventName
イベント名を指定してフォーム ハンドラーを無効にします (例: **DisableFormHandlers=onload)。
https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormHandlers=true&flags=DisableFormHandlers=eventName_index
サポートされている任意のイベント名に対して、指定されたインデックスのイベント ハンドラーを無効にします。 例えば、
DisableFormHandlers=true_0はインデックス 0 のすべてのイベント ハンドラーを無効にします。DisableFormHandlers=onload_2はインデックス 2 の OnLoad イベント ハンドラーを無効にします。&flags=DisableFormHandlers=eventName_startIndex_endIndex
startIndexおよびendIndex値 (両方が含まれる) を指定して、指定された範囲内のすべてのイベント ハンドラーを無効にします。 例えば、DisableFormHandlers=true_0_2はインデックス 0、1、2 のすべてのイベント ハンドラーを無効にします。DisableFormHandlers=onload_2_5はインデックス 2、3、4、5 の OnLoad イベント ハンドラーを無効にします。 イベント ハンドラーが多い場合は、このアプローチを使用して、問題のあるハンドラーをすばやく絞り込むことができます。
注意
ビジネス ルールはビジネス ルール デザイナーで作成され、クライアント側のスクリプトにコンパイルされ、
OnLoad、OnSave、およびOnChangeなどの複数のフォーム イベントに登録されます。 ビジネス ルールを無効にする方法は、他のフォーム イベントと非常に似ています。 ただし、以下のような重要な違いがあります:DisableFormHandlers=true、businessrule、businessrule_*index*、またはbusinessrule_*startIndex_endIndex*を使用すると、登録されているすべてのフォーム イベントでビジネス ルールが無効になります。- たとえば、次の画像は、バックエンドでビジネス ルールを更新する手順を示しています。 組織内で 1 度だけ実行する必要があり、トラブルシューティング後に変更を戻すことができます。

- 上記のアクションを実行してフォームを更新すると、以下に示すように、追加情報を含む別のメッセージが表示されます:

DisableFormLibraries
フォーム ライブラリを無効にして、ライブラリが読み込まれないようにします。 きめ細かいコントロールのイベントまたはライブラリ インデックスの取得方法の詳細については、モニターで登録済みフォームのイベント ハンドラーとライブラリを表示するを参照してください。 使用方法は
DisableFormHandlersに似ていますが、値としてイベント名を指定しない点が異なります。- &flags=DisableFormLibraries=true: すべてのフォーム ライブラリを無効にします。
- &flags=DisableFormLibraries= index**: 指定されたインデックスでフォーム ライブラリを無効にします。
- &flags=DisableFormLibraries= startIndex_endIndex**: startIndex および endIndex (両方を含む) の範囲でフォーム ライブラリを無効にします。
DisableWebResourceControls
フォーム上のすべての Web リソース コントロールを無効にします。
https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableWebResourceControls=true
DisableFormControl
フォーム コントロールを無効にします。 コントロールを無効にするには、コントロール名を指定します。 &flags=DisableWebResourceControls=true で問題が解決でき、フォームに複数の Web リソース コントロールがある場合、このフラグを使用して、問題の原因となっているコントロールをさらに特定できます。
https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormControl=controlnameDisableBusinessProcessFlow
フォームですべての業務プロセス フローを無効にします。
https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableBusinessProcessFlow=truenavbar これは flag パラメーターではありません。むしろ、URL で navbar=off を使用します。
カンマで区切って複数の URL パラメーターを追加することもできます (,)。
https://myorg.crm.dynamics.crm/main.aspx?appid=00000000-0000-0000-0000-000000000000&pagetype=entityrecord&id=00000000-0000-0000-0000-000000000000**&flags=DisableFormHandlers=true,DisableWebResourceControls=true,DisableFormCommandbar=true,DisableBusinessProcessFlow=true&navbar=off
注意
DisableFormHandlers および DisableFormLibraries の違いは次の通りです:
- DisableFormHandlers フラグは、含まれているフォーム ライブラリに関係なく、フォーム ハンドラーを無効にします。 一方、DisableFormLibraries フラグは、ライブラリに含まれている関数 (イベント ハンドラー) に関係なく、フォーム ライブラリ (Web リソース) を無効にします。 簡単に言えば、DisableFormLibraries は指定された JavaScript Web リソース ファイルが読み込まれていないことを確認します。
- DisableFormHandlers フラグは、含まれているフォーム ライブラリが読み込まれるのを妨げることはありません。 したがって、ライブラリに存在しながらイベント ハンドラーとして登録されていない JavaScript コードの実行を停止することはありません。 たとえば、フォーム ライブラリ
new_myscript.jsが次のように書かれている場合 (推奨される方法ではありません): - DisableFormHandlers から始めて問題が解決するかどうかを確認し、解決しない場合は DisableFormLibraries を試してみてください。 任意のスクリプトを無効にすると、フォーム シナリオが壊れる可能性があるというリスクが常に伴います。 ただし、後者は JavaScript ファイル全体が無効になるため、より多くの副作用が発生する傾向があります。

myOnloadHandlerがOnLoadイベント ハンドラーとして登録されているとすると、DisableFormHandlers=trueフラグは 2 番目の通知のみを防ぎ、DisableFormLibraries=trueフラグは両方の通知を防ぎます。
モニターで登録済みフォームのイベント ハンドラーとライブラリを表示する
登録済みのフォーム イベント ハンドルとライブラリを表示するには、モニターで FormEvents 操作を表示できます。

DisableFormHandlers または DisableFormLibraries URL フラグを使用するときは、eventIndex パラメーター値と libraryIndex パラメーター値が必要になります。 イベントまたはライブラリを無効にすると、FormEvents 操作 (すべてのイベントの登録済みイベント ハンドラーの全体図)、および FormEvents.eventName 操作 (特定のイベントが発生したときにログに記録される詳細) の両方でイベントが有効になっている状態が確認できます。

フォームをロードするときの予期しない動作
イシュー
モデル駆動型アプリ フォームの読み込み時に予期しない動作を引き起こす可能性のある一般的な問題は次のとおりです。
列またはコントロールには、期待する値がありません。
コントロールが無効になっていないか、有効になっていません。
コントロールは表示されないか、非表示になっていません。
トラブルシューティング方法
フォームを開いたときに予期しない動作が発生する理由は複数あります。 最も一般的なものの一つは、同期または非同期で実行され、列とコントロールの動作を変更する OnLoad スクリプトです。 スクリプトが問題の原因であるかどうかを判断するには、アプリ URL の末尾に &flags=DisableFormHandlers=true を追加してフォーム ハンドラーを無効にします。
フォーム ハンドラーを無効にした後に予期しない動作が発生しなくなった場合は、特定のフォーム ハンドラーがこの動作を引き起こしていることを強く示しています。 この動作を引き起こしている問題のあるスクリプトを特定した場合は、スクリプト所有者に連絡を取り、この問題のトラブルシューティングを進めてください。
保存の進行中のエラー メッセージ
イシュー
フォームを保存すると、保存の進行中 のエラーメッセージが表示されます。
このエラーは、フォーム OnSave イベントが前の OnSave イベントが完了する前にトリガーされた場合に発生します。 この動作はサポートされていません。エラーは設計上表示されます。前の OnSave イベントが完了する前に OnSave イベントを呼び出すと、意図しない結果を伴う再帰的な保存ループが発生するためです。
このエラーの一般的な原因は、OnSave イベント ハンドラで save() メソッドを呼び出すスクリプトです。 別の考えられる原因は setTimeout() メソッドにおける save() の同時呼び出しである可能性があります。別の save() 呼び出しが行われる前に前の save() 呼び出しが完了したかどうかに応じて、エラーが断続的に表示される可能性があります。
トラブルシューティング方法
モニター では、FormEvents.onsave 操作により、エラーの原因となっているすべての詳細が提供されます (呼び出しスタックはデモ用に変更されています)。 呼び出しスタックでは、このエラーの原因となった正確な Web リソース、関数、行番号、列番号がわかります。 問題を再現できない場合、フォーム チェッカーはエラーを検出できません。

スクリプト所有者に連絡を取り、問題のトラブルシューティングを進めてください。
断続的なフォーム エラー
イシュー
断続的またはランダムなフォーム エラーの最も一般的な原因は、サポートされていないクライアント API メソッド フォームの使用です。 これらのエラーには、次の特性があります。
これらは、特定のレコード、ユーザー、リージョン、またはブラウザーに対してのみ、またはネットワークまたはサービスの負荷が高い期間中にのみ発生します。
サポート インスタンスで発生することはめったにありません。
これらはコンピュータで 1 回発生する可能性があり、ブラウザのキャッシュをクリアした後に同じエラーが再度発生する可能性があります。
formContext.getControl または formContext.getControl(arg).getAttribute() は、有効なコントロールまたは列に対してランダムに null を返します。
サポートされていないクライアント API メソッドを作成する方法はたくさんあり、それらはすべて共通のパターンを共有しています。それらは、フォーム ロード パイプラインで競合状態を引き起こします。 これらは競合状態を引き起こすため、この問題は、クライアント API を介してフォームに完全にアクセスできるようになる前にカスタム スクリプトが実行された場合にのみ発生します。 これは多くの要因に依存する可能性があります。
JavaScript Web リソースでは、フォームにアクセスできるようになるのを待つことなく Web リソース ファイルが読み込まれるとすぐに実行されるグローバル スコープにコードが配置されます。 コードが、OnLoad ハンドラーなど、次のような有効なフォーム ハンドラー内で実行されていることを確認してください。

Power Apps component framework コンポーネント スクリプト ファイルでは、クライアント API メソッドは init または updateView 関数の内部でアクセスされます。
init()およびupdateView()関数は、フォームにすぐにアクセスできるようになるのを待たずに、コンポーネントがロードされるとすぐに実行されます。 サポートされていないクライアント API メソッドを Power Apps component framework コンポーネントで使用することはできません。
クライアント API は、Web リソース ファイルの window.setTimeout() 関数の中でアクセスされます。 ページの状態は、setTimeout() メソッドがラップされた関数を実行するときには予測ができません。 タイマー機能の性質上、実行が発生すると、ページが遷移状態 (ページの読み込み中または保存中) になり、クライアント API から簡単にアクセスできない場合があります。
トラブルシューティング方法
モニターを使用すると、サポートされていないクライアント アクセスがいつ発生したか、および競合状態が原因でアクセスが間違った時間に発生したかを判断するのに役立つ情報にアクセスできます。 ただし、サポートされていないコードが問題を引き起こさない適切なタイミングで実行された場合、フォーム チェッカーはそのようなサポートされていないクライアント アクセスを報告しません。

注意
説明のために、コール スタックが変更されました。 呼び出しスタックには、Web リソース、関数、エラーの原因となっている行などの詳細が表示されます。
スクリプト所有者に連絡を取り、問題のトラブルシューティングを進めてください。
フォームを保存しようとすると、フォームまたはレコードが保存されない
イシュー
一般的な原因は、executionContext.getEventArgs().preventDefault() メソッドを呼び出す OnSave イベント ハンドラーが保存操作をキャンセルすることによるものです。
トラブルシューティング方法
モニターでは、FormEvents.onsave 操作により、保存イベントがキャンセルされた理由のすべての詳細が、フォーム UI 自体から利用可能なものより詳細に提供されます。

スクリプト所有者に連絡を取り、問題のトラブルシューティングを進めてください。
フォームがフリーズする、読み込みが遅い、または原因不明のエラーがスローされる
イシュー
フォームがフリーズしたり、読み込みが遅くなったり、または「Web リソース メソッドが存在しません」というスクリプト エラーや一般的なスクリプト エラーではないエラーがスローされる理由はたくさんあります。 考えられる理由には次のものがあります。
不正な
OnLoadスクリプト。Web リソース コントロール。
リボン ボタンのスクリプトとルール。
同期ネットワーク要求。
カスタム プラグイン。
ビジネス プロセス フローのエラー。
トラブルシューティング方法
フォームを介さずに問題が再現されるかどうかを判断します。 もし再現されるなら、フォームのコンテキストから調査されるべきより広範な問題があります。 問題の実際所有権は、ケースバイケースで詳細が異なります。
- この問題がフォームでのみ発生すると思われる場合は、URL パラメーターを使用して異なるフォーム コンポーネントを無効にするを参照して、問題の原因となっているコンポーネントを絞り込みます。
- 問題の原因が特定のフォーム ライブラリ/スクリプト ファイルであることが分かった場合は、これらのカスタマイズを行った所有者に連絡を取り、問題の根本原因を特定してください。
- DisableWebResourceControls フラグを使用して Web リソース コントロールが問題を引き起こしていると特定した場合、問題が再現されなくなるまで、
DisableFormControlフラグを使用して 1 つずつ無効にできます。 問題を再現しない最後の無効化されたコントロールが、問題の原因となっているコントロールです。 コントロールの所有者に連絡を取り、問題のトラブルシューティングを進めてください。 - DisableFormCommandbar フラグを使用して問題の原因がコマンド バー/リボンであることを特定した場合、これはフォームの問題ではなく、コマンド バーの問題であることを意味します。 コマンド チェッカーを使用して、個々のコマンドのトラブルシューティングを行い、問題の原因となっているコマンドを特定します。
ビジネス ルールまたはカスタム スクリプトが機能していない
イシュー
この問題は、従来の Web クライアントで機能していたビジネス ルールまたはカスタム スクリプトが統一インターフェイスで機能しなくなった場合に発生します。 このエラーが発生する主な理由の 1 つは、ビジネス ルールまたは統一インターフェイスのスクリプトが、統一インターフェイスで使用できないコントロールを参照していることです。
トラブルシューティング方法
ビジネス ルールまたはスクリプトが統一インターフェイスで機能しない理由の 1 つは、それらの一部であるコントロールが統一インターフェイスに存在しないことです。
複合コントロールは Web クライアントに存在しますが、統一インターフェイスでは、複合コントロールはパーツに分割され、異なる方法で保存されます。 たとえば、列 fullname がビジネス ルールまたはカスタム スクリプトの一部である場合、列 firstname、middlename、また lastname が代わりに使用される必要があります。
フォーム チェッカーを起動すると、CompositeControl 操作で、問題の原因となっている複合コントロール、代わりにビジネス ルールまたはカスタム スクリプトで使用できる列、および完全な呼び出しスタック (呼び出しスタックはデモ用に変更されています) を含む、より詳細な情報を確認できます。

ビジネス ルール またはカスタム スクリプトに対応する所有者に連絡を取り、フォーム チェッカーによって提案されたコントロールを変更します。
[関連] メニュー/[関連] タブ
イシュー
関連するメニュー項目が 関連 タブに表示されなかったり、間違ったラベルが表示される理由はたくさんあります。
トラブルシューティング方法
次の例では、role テーブルが統一インターフェイスで使用できないため、関連テーブル role (セキュリティ ロール) は team フォームに表示されません。

モニターでは、RelatedMenu 操作は、問題の原因となっているすべての詳細を提供します。
レコードを 関連 メニュー タブのオプションとして含めることができるソースもいくつかあります。次の例には、アカウント フォームの 関連 メニューのラベル Activities が、関連するテーブルの複数形の表示名に由来することを示す詳細が含まれています。

関連するメニュー項目の対応する所有者に連絡を取ってください。
コントロールが無効/有効または表示/非表示の理由
イシュー
フォームの読み込み時にコントロールが無効になったり非表示になったりする理由はたくさん考えられます。
トラブルシューティング方法
モニターを使用して、フォームの読み込み時の初期コントロール状態に関するすべての詳細を含む FormControls 操作を表示できます。

チェックする別の箇所は ControlStateChange.visible または ControlStateChange.disabled 操作で、そこではフォーム上でコントロールの無効化または表示状態がいつでも変更される理由を説明しています。 この操作では、変更前のコントロールの状態、成功する場合と成功しない場合がある意図された状態の変更、および変更後の状態について説明します。 すべてのコントロール状態変更の試行が成功するわけではありません。 フォーム XML によって無効にされたコントロールの場合、クライアント API を介して OnLoad イベント ハンドラーで有効にできます。 ただし、セキュリティ上の理由でコントロールが無効になっている場合、クライアント API を介してコントロールを有効にしようとしても、状態が正常に変更される可能性はほとんどありません。

次のルールの一覧を順番に使用すると、コントロールを無効にできます。 ルールを満たしている場合、次のルールは無視されます。 コントロールを無効にするかどうかを変更する場合は、結果に使用されるルールまたはリストの前のルールへの入力を変更する必要があります。
- フラグ
DisableWebResourceControls=trueまたはDisableFormControl=<control name>が渡され、コントロールがこれらのフラグの影響を受けると、コントロールは無効になります。 - テーブル定義の統一インターフェイスで所有テーブルが読み取り専用の場合、コントロールは無効になります。
- テーブルがオフライン モードで使用できない場合、コントロールは無効になります。
- 現在のユーザーがレコードに対する書き込み権限を持っていない場合、コントロールは無効になります。
- 列定義で
IsValidforCreateが false に設定されると、コントロールは無効になります。 - 列定義で
IsValidforUpdateが false に設定されると、コントロールは無効になります。 - 現在のユーザーに
Assign to権限がない場合、所有者列は無効になります。 - ユーザーにフィールド レベルのセキュリティで定義された列に対する書き込み権限がない場合、コントロールは無効になります。
- クライアント API スクリプトによってコントロールが無効または有効になっている場合、コントロールが無効な状態ではその設定が尊重されます。
- フォーム デザイナーでコントロールが無効になっている場合、コントロールは無効になっています。
- ユーザーに検索コントロール テーブルに対する
Append To権限、または現在のレコード テーブルに対するAppend権限がない場合、検索コントロールは無効になります
最後に、コントロールが上記のすべてのチェックに合格した場合、レコードの状態によって、コントロールが無効になっているかどうかが判断されます。 コントロールは、アクティブなレコードではデフォルトで有効になっており、非アクティブなレコードでは無効になっています。
注意
FormControls と ControlStateChange の違いは、FormControls 操作ではフォームの読み込み時の初期コントロール状態を反映するのに対して、ControlStateChange 操作では、フォームの読み込み中、フォームが読み込まれた後の OnChange イベントまたは OnSave イベントなど、フォームの状態の変化をいつでも反映します。
重要
コントロールの無効状態と非表示状態は、フォームが最初に読み込まれたときに複数回変更される場合があります。 コントロールが非表示または無効になっている理由を知るには、モニターに記録された 最後 の操作を確認してください。 たとえば、調査対象のコントロールに ControlStateChange.visible/ControlStateChange.hidden の操作がない場合、値と理由は FormControls の操作になります。 それ以外の場合は、最後 の ControlStateChange.visible/ControlStateChange.hidden 操作での値と理由になります。 ログをタイムスタンプで並び替えて、最後の操作を検索することができます。
コントロールがフォームの読み込みで特定の値を持つ理由
イシュー
コントロールは、ユーザーが期待するような特定の値をフォームの読み込み時に持つこともあれば、持たないこともあります。
トラブルシューティング方法
フォームの読み込み時にコントロールが値を持つ理由は多数考えられます。 ControlDefaultValue の操作モニターでは、既定値のソースについて説明しています。

コントロールの値に複数の更新が発生している場合、Update Sequence は最終値を示します。 たとえば、これは既定値のコントロールであり、クライアント API スクリプトで渡された値で上書きされます。 提供されたコール スタックがあります。

関連付けの列マッピングに基づいて列にデータが入力されるシナリオがありますが、その場合、イベントはそれを示します。

値がどこから来ているかを確認し、以下の表に基づいてアクションを実行します:
| Source | 修正方法 |
|---|---|
| クライアント API スクリプト | スクリプトの所有者に連絡してください。 |
| 既定値 | コントロールの構成を確認してください。 |
| 関連付けの列マッピング | 関連付け構成を確認し、列マッピングを更新します。 |
| URL を介して渡されるページ入力データによって渡される値 | 問題のある特定のフォームを開く API を確認してください。値が渡されています。 |
タブまたはセクションが表示または非表示になる理由
イシュー
タブまたはセクションが非表示または表示になる理由はたくさん考えられます。
トラブルシューティング方法
モニターの TabStateChange または SectionStateChange 操作は、次の図に示すように、表示状態の変化を説明します。 スクリプトが原因である場合、呼び出しスタックはこの動作の原因となった Web リソース ファイル、行番号、および関数名を表示します。

状態理由、または Web リソース/ビジネス ルールの所有者の提案に従ってフォローアップし、動作を変更または修正してください。
予期しないダイアログまたはナビゲーション
イシュー
ダイアログが表示されたり、ナビゲーションが予期せず発生したりする理由は数多く考えられます。 一般的な原因の 1 つは、Xrm.Navigation API メソッドが、カスタム スクリプトによってレコードまたはフォームを開くために呼び出されることです。 たとえば、フォームを開くと、次の図に示すように、アラートが表示されます。

トラブルシューティング方法
モニターの XrmNavigation 操作には、予期しない動作を引き起こしているスクリプトを特定するのに役立つ呼び出しスタックが含まれます。

Web リソースの所有者と連絡を取って、動作を変更または修正してください。
クイック作成フォームの代わりに別のフォームを開く
イシュー
ルックアップまたはグリッドからクイック作成フォームを開くと、クイック作成フォームの代わりに別のフォーム (編集またはメイン フォーム) が開く場合があります。 これが発生する理由はいくつかあります。
- メイン フォーム ダイアログの強制フラグが設定されている。
- クイック作成フォームを利用できない。
トラブルシューティング方法
モニターを使用して、クイック作成フォームが開かないすべての理由を含む FormType 操作を表示できます。

テーブル定義 (メタデータ) によるクイック作成を無効にしたテーブル所有者に連絡を取る必要があります。
テーブルが簡易作成メニューのポップアップに表示されない
イシュー
グローバル簡易作成メニューのポップアップを開いても、すべてのテーブルが使用できるわけではありません。 このリストでテーブルがフィルターされる理由はいくつかあります:
- テーブルで使用できる簡易作成フォームがない。
- テーブルが簡易作成フォームに対して有効になっていない。
- テーブルが新しい統一インターフェイスに対して有効になっていない。
- テーブルが統一インターフェイスで読み取り専用である。
- テーブルのモバイル クライアントの可視性が変更できない。
- テーブルがアプリ モジュールの一部ではない。
- ユーザーには、テーブルに対する作成権限がない。
- テーブルの作成権限がサポートされていない。
トラブルシューティング方法
モニターを使用して QuickCreateMenu 操作を表示できます。これには、すべてのテーブルと、それらが簡易作成メニューのポップアップからフィルター処理される理由が含まれます。
フィルタリングの理由を理解するには、以下の例を参照してください。 説明に基づいて、当事者に連絡するか、適切な変更を加えます。



予期しない未保存の変更メッセージ
イシュー
フォームで作業する際、現在のフォームから移動したとき、またはフォームが変更なしで保存されると、フォーム フッターに 未保存の変更 メッセージが表示されます。
トラブルシューティング方法
未保存の変更 エラーは、フォームに変更を加えても、変更が保存されなかった場合に表示されます。 手動で変更を加えていない場合は、JavaScript、プラグイン、またはビジネス ルールから変更されている可能性があります。 モニターを使用して、変更のソースを見つけるのに役立つ UnsavedChanges 操作を表示できます。 OperationType UnsavedChanges でフィルタリングできます。
all attributes modified セクションには、未保存の変更エラーの原因となっている列の概要とその値が含まれています。 unsaved changes セクションでは、列に何が起こったかを詳細に示します。 すべての列について、変更を引き起こす可能性のあるコントロールのリストが提供されます。 値の変更 (previousValue、newValue)、および呼び出しスタックも表示されます。
以下のスクリーンショットは、問題の根本的な原因を示しています。 変更が OnLoad スクリプトから来ていることがわかります。

注意
ユーザーがフォームに手動で変更を加えた場合、呼び出しスタックは提供されません。
変更がどこからのものか、およびそれが期待される動作であるかどうかを確認します。 スクリプトによって変更が発生した場合は、元の Web リソースを呼び出しスタックでさかのぼることができます。 ほとんどの場合、それはスクリプトのいずれかになります。 Web リソース自体に基づいて電話をかけます。
ビジネス必須の列検証が期待どおりに動作しない
イシュー
ビジネス必須の列は、値が空の場合、既定でフォーム保存操作をブロックします。 ただし、多くの設計上のシナリオでは、ビジネス必須の列は、値が空の場合は保存操作をブロックしないか、必要がないと思われる場合は保存をブロックしない場合があります。
トラブルシューティング方法
保存が成功したかどうかに関係なく、保存が試行されると RequiredFieldValidation 操作がログに記録されます。 この操作は、ビジネス必須の各列が保存操作をブロックする理由またはブロックしない理由を説明します。
この操作の例を次に示します。 メッセージは、必須の各列の詳細レポートの読み取る方法を説明しています。 この例では、fax 列は 1 つのコントロールにバインドされており、同じ名前のコントロールは読み取り専用であるため、必須の列の検証はトリガーされません。

以下は別の例です。jobtitle はビジネス プロセス フローにあってフォームにはないビジネス必須の列ですが、列は変更されません。 したがって、空の場合でも保存操作がブロックされることはありません。

フォローアップ
ほとんどの場合、動作は設計上のものであり、RequiredFieldValidation 操作は、この列がフォーム保存操作の特定の方法で動作する理由を説明します。 最初の例で示したように、コントロールが無効または非表示であるために必須の列の検証が列でスキップされた場合は、フォーム チェッカーの提案を参照してさらに分析してください。
これにより、コントロールが無効/有効または表示/非表示である理由など、別のトラブルシューティング シナリオが発生する可能性があります。
一部の列が結合ダイアログに表示されない
イシュー
結合ダイアログは、テーブルの既定のメイン フォーム定義を使用し、ダイアログ内のすべての列ではなく、ほとんどの列を選択的にレンダリングします。 このフォーム チェッカー操作では、メイン フォームに表示されている場合でも、一部の列が結合ダイアログに表示されない理由を説明します。
トラブルシューティング方法
以下の MergeDialog.load 操作では、一部の列が表示されない理由を説明します。
この例では、問い合わせフォームの parentcustomerid 列が結合ダイアログでサポートされていません。 含まれているセクションがメインフォームの XML 定義で非表示になっているため、名刺の列は表示されません。 クライアント API を介してメイン フォームに所有セクションを表示することは可能ですが、結合ダイアログではイベント ハンドラーがサポートされていないため、結合ダイアログではフォームの XML 構成が考慮されます。

注意
ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)
この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。
フィードバック
フィードバックの送信と表示