タイムライン

Timelineコンポーネントは複数のテーブルの行を一つのリストとして表示し、最新が順に表示されます。デフォルトではレコードのノート、ポータル通信、その他のアクティビティです。RecordContextに入れると、そのレコードに関する行が表示されます:誰がいつ書きましたか?リッチテキストの本文は数行に切り替わり、「さらに表示」と「ダウンロード用の添付ファイル」です。ページを1ページずつ読み、残りは「Load more」、再読用にはリフレッシュで読みます。検索はグリッド形式で動作します。テキストは主題やテキストの冒頭、またはリード*の後の任意の場所から一致し、1日または1年前に>、<、>=、<=の前でその日の行を見つけます。複数のテーブルがある場合は、検索の横にあるメニューでどの行を表示するか選びます。

どのノートやアクティビティが示されていますか

ノートはテキストが *WEB*で始まる場合にのみポータルに届くため、スタッフは顧客が見た記録の内部メモを保持できます。電話、タスク、その他の活動も説明文で同じルールに従いますが、フィルターなしのタイプ(デフォルトはポータル通信)は例外です。サーバーはこのルールをすべてのクエリ、グリッド、結合に適用するため、どのテーブルアクセスルールも拡大できません。ポータルはプレフィックスを表示せず、ポータルを通じて作成されたノートやアクティビティに追加します。タイトルで作成者が Note created on … by Name [contact:id] と名付けられたメモは、その連絡先によって書かれたものとして表示されます。 SecurityOptions.PortalVisibility.Prefix を別のプレフィックスを使うか、すべてのメモやアクティビティを表示する null に設定し、すべてのアクティビティを表示するために UnfilteredActivities にテーブルを追加してください。ポータルに本人としてサインインしたスタッフは例外で、セキュリティロールで読めるすべてのノートやアクティビティをDynamicsのようにテキストが保存されている状態で確認するため、ポータル用のノートにプレフィックスを自分で追加します。

メールにはプレフィックスを付けることはできません。メールの本文は送信したメールクライアントがHTMLドキュメントとして書き込むため、プレフィックスが最初のテキストになることはなく、どのメールもプレフィックスでポータルに届くことはありません。UnfilteredActivitiesにemailを追加するのがメールを表示する唯一の方法であり、ユーザーが読めるすべてのメール(内部メールも含む)をレコードに表示します。

ポータル通信

ポータル通信(ppp_portalcommunication)は、Power Portals Proソリューションにおける、ポータルユーザーとスタッフ間のメッセージの活動です。これはポータル用なので、接頭辞は必要ありません。「 It From 」には、誰が書いたかが記載されています:ポータルユーザーの連絡先か、または返信したスタッフで、 連絡先はToに記載されています。メッセージはリッチテキストで、1つの添付ファイルを搭載できます。

アクセス

タイムラインはユーザーが読むことができるものだけをリストアップしており、テーブル上で読むべき項目の種類はそれぞれで、どちらも読めないユーザーはタイムラインを全く見られません。ノートは objectid を通じてその記録を指し示し、ポータルは regardingobjectidを通じて通信するため、通常のルールではユーザーがアクセス可能なレコードについての項目を RowsViaParentで読むことができます。その検索は読む可能性のある列の中に残し、タイムラインはその記録に関する項目をタイムラインを通じて求め、ユーザーが読んではいけない列の条件を解除し、アクセスしたすべてのレコードの項目をリストアップします。

ポータルのアプリケーションユーザーもDataverse内の両方のテーブルで読み取る必要があります。NoteはNoteテーブルで読み取る必要があります。Dataverseはすべてのアクティビティタイプを一つの権限セットで付与しているため、ポータル通信はPower Portals Proアプリケーションユーザーの役割が既に保持しているアクティビティのリードオンでカバーされます。ユーザーがノートやメッセージを変更または削除するには、Noteテーブル上でWrite and Delete、アクティビティに対してDeleteが必要ですが、この役割は保持していません。

メッセージの書き方

ポータル通信を作成できるユーザーは、タイムラインが載っているレコードに関する新しいメッセージ、主題、リッチテキストメッセージ、添付ファイル1つを受け取り、ノートを作成できるユーザーには新しいノートが付与されます。CreatableTables新しい行を書けるテーブルの名前、デフォルトでノートとポータル通信の名前が割り当てられます。メモやメッセージはその場に書き込まれ、別のテーブルの行はサイドパネルに表示されます。これは独自の形態であり、周囲のページとは別に保存されます。サーバーはリクエスト内容に関わらずユーザーからメッセージを送信するため、あるユーザーが別のユーザーとして書き込むことはできません。テーブルアクセスを付与する:OwnedBy("from")は作成者から新しいメッセージを送信し、RowsOwnedByContact("from")RowsForWritingではユーザーが送信したもののみを変更・削除できます。書き込みと削除を省略すると、メッセージは送信されたままのままです。タイムラインは各行で編集と削除をユーザーに許可し、サーバーは変更が届いたときに再度判断します。FormLocation(React: formLocation)は、他のテーブルのフォームがどこで開くかを示します:デフォルトで右側のサイドパネル、左側、中央のダイアログ、またはInline — メモやメッセージが書かれる間にタイムラインの位置にあります。

スタッフは PortalCommunicationOptionsを通じて新しいメッセージを受信します。デフォルトでは、その所有者がユーザーの場合、その所有者宛てはその記録の所有者宛てです。代わりに、ポータルのアプリケーションユーザーがアクセスが必要なキューにアイテムを追加したり、誰にも追加しなくても、レコードのタイムライン上に残ることもあります。

表

ノートやすべてのアクティビティテーブルはサーバー上でタイムラインやカレンダーとして登録されており、それぞれフォームの要求に応じて日付が付けられています。例えば、開始時は予定、締め切りはタスクや電話、メールやメッセージは作成日時です。タイムラインにはユーザーが読むことができる登録済みテーブルが一覧化されています。 Tablesで表示されるものの名前を挙げます。レコードには、その記録に関する行や、送信者、受信者、参加者として参加するアクティビティが記載されます。サーバーはポータル用のノートやアクティビティのみを表示します。テキストが *WEB*で始まるもの、またはある UnfilteredActivitiesのタイプすべてです。メールは接頭辞を持たないため、リストに email がある場合にのみ表示されます。

自分 AddMultiTableSource専用のテーブルを登録します。タイトル、テキスト、所有者や受信者、行が対象となるレコードのルックアップなど、表示されるものを記載します。次に、そのコントロールに必要な列名を付けます。 ForTimelines 、行の ForCalendars 順序が日付、開始カラム、もし順にならば終了カラムと終日カラム ForSearch、緯度と経度 ForMaps 。これらのカラムは、ビューのクエリ名が何であれ常に読み込まれます。テーブルにないカラム名や、異なるタイプのカラム名を付ける登録は、起動時にポータルを停止し、問題点を教えます。ノートやアクティビティテーブルを登録しても、登録名だけが変わります。登録はアクセス権を得ません。各テーブルは他のテーブルと同様に読み取りアクセスが必要です。

今後のローズ

タイムラインは、まず新しい行をリストアップし、今から遡ります。 Upcoming (React: upcoming)はその先の先から表示されるため、次に表示されるものが自分の見出しで最初に表示され、 Ascending (React: ascending)はこれから先の行を最初にリストアップします: 「Upcoming Items」を参照してください。テーブルの行を自分なりに描いたり、自分で書く場合は 「Custom Rendering」をご覧ください。

見解

グリッドのように、Dataverse独自の「My Phone Calls」や「All Activities」などのタイムラインビュー、ViewIdsMultiTableViewIdsの複数のテーブルのビュー、CustomViewDefinitionsの自分のビュー、DefaultViewId表示の先に表示するビューを選べるようにします。2つ以上のビューセレクターがある場合は、見出しの代わりにビューセレクターが置かれます。DataverseのViewactivitypointer登録済みアクティビティテーブルを一覧表示し、レコードにはそのレコードを通過させる行を表示します。AllowSavedViews(React: allowSavedViews)では、サインインしたユーザーはタイムラインに表示されたテーブルを自分のビューとして保存し、自分のビューの隣に提供し、デフォルトのビューを選択して使わないものをフィルターメニューから非表示にできます(「保存済みビュー」参照)。

自分のビューは1つ以上のテーブルの行を一覧にします。テーブルにFetchXMLクエリを与え、そのフィルターと結合がどの行を表示するかを決めます。これにより、ビューはアカウントの連絡先との電話通話など他のレコードに対してファイルされた行にアクセスできます。 FilterByRecord を false に設定し、ビューのクエリが自動的に決定できるようにします。タイムラインは自分の列を独自の順序で読み取るため、クエリの列や順序は問題になりません。ユーザーはフィルターがテストする各列を読める必要があります。ユーザーが読んではいけない列の条件は削除されます。