問題タブ [appointment]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
.net - SharePoint Web パーツからの Outlook の予定
カスタム SharePoint Web パーツからプログラムで Outlook に予定を作成することはできますか? VB.Net のリンクまたは例が最も役に立ちます。
ありがとう。
asp.net - 予定を作成するためのWebアプリケーションからのOutlookAutomation
ActiveXテクノロジを使用してWebアプリケーションからのOutlookを自動化することは標準的な方法ですか?これは、telerikのRadScheduler + telerikのExchangeプロバイダーのようなWebスケジューラーと比較して、Webアプリケーション自体からの予定をスケジュールするのですか?
ありがとう、
センディル
outlook - WebDAVおよびExchangeとOutlookを使用して作成されたさまざまな一意のID
WebDAVを介してExchangeで予定を作成していますが、作成されたUIdは、Outlookで予定を作成した場合と同じではありません。私が信じるUIdはGlobalObjectIdと同じであり、一意であり、変更されるべきではありません。
WebDAVを介して作成された場合のUIdは次のとおりです。
Outlookで作成した場合のUIdは次のとおりです。
OutlookでWebDAVを介して作成された予定を開き、それを再度保存すると、UIdが変更され、煩わしいものになります(UIdは04から始まる上記のものに変更されます)。
UIdの後半は、同じGUID {DD673744-28B4-C644-A0A3-59A2586E30B3}であり、変更されることはありません。ここのドキュメントhttp://msdn.microsoft.com/en-us/library/cc425490(EXCHG.80).aspxは、GlobalObjectIdがどのように構築されるかを説明しています。Outlookはこれらのルールに従っているようですが、Exchangeは準拠していません。Outlook2007とExchange2007を使用しています。
予定を識別するために使用できるIDは無数にあるようですが、時間の経過とともに予定を追跡できるように、同じままのIDを探しています。
誰かがこのUIdが変更される理由、または変更されないように作成する方法を説明するのを手伝ってくれるなら、それは大いにありがたいです。私の制限は、Exchange2003SP2とOutlook2003のサポートです。
exchangewebservices - EWS 予約リマインダー
アカウントの予定アイテムを ews で CalendarItemType オブジェクトとして取得しています...これは AppointmentState としてアイテムを取得しました。
msdn を調べたところ、(noattendees,is meeting,recieved,cancelled,forwaded 値) しかありません
しかし、リマインダー値を取得する方法(スヌーズ、却下など)と、スヌーズした場合、スヌーズ時間と予定の現在のステータス(キャンセル、削除など)を取得する
outlook-addin - icsファイルをOutlook.AppointmentItemにインポートする
特定の予定に関する属性を読み取れるように、ICSファイルをOutlook.AppointmentItemオブジェクトにインポートしようとしているOutlook2007アドインがあります。現在、ICSをメモリに読み戻すことができません。私が間違っていることについての提案。
ありがとう
javascript - JavaScript 定期的な予定ライブラリ
定期的な予定を計算できる JavaScript ライブラリを探しています。「毎週第2水曜日」みたいなことにも対応できるもの。ソリューションは、JavaScript とクライアント側のみである必要があります。カレンダーは必要ありません。定期的な予定の日付を計算できるものだけです。助言がありますか?
google-app-engine - データベース設計-GoogleAppEngine
私はGoogleAppEngineを使用しており、低レベルのJavaAPIを使用してBigTableにアクセスしています。私は4つのレイヤーでSAASアプリケーションを構築しています:
- クライアントWebブラウザ
- RESTfulリソースレイヤー
- ビジネスレイヤー
- データアクセス層
私は自分のモバイルオートディテーリング会社(およびそのような他の会社)の管理に役立つアプリケーションを構築しています。私はこれらの4つの別々の概念を表現する必要がありますが、私の現在の計画が良いものであるかどうかはわかりません。
- 予定
- ラインアイテム
- 請求書
- 支払い
アポイントメント:「アポイントメント」とは、サービスを提供するために従業員が期待される場所と時間です。
広告申込情報:「広告申込情報」とは、サービス、料金、割引、およびそれに関連する情報です。予定に入る可能性のある広告申込情報の例:
請求書:「請求書」は、顧客が支払うことを約束した1つ以上の広告申込情報の記録です。
支払い:「支払い」は、どのような支払いが行われたかを記録したものです。
このアプリケーションの以前の実装では、作業はより単純であり、これらの4つの概念すべてをSQLデータベースの1つのテーブル「予定」として扱いました。1つの「予定」には、複数の広告申込情報、複数の支払い、および1つの請求書を含めることができます。請求書は、広告申込情報と顧客レコードから作成された単なる電子メールまたは印刷物でした。
10回のうち9回、これは正常に機能しました。1人の顧客が1台または数台の車両を1回予約し、自分で支払いをしたとき、すべてが壮大でした。しかし、このシステムは多くの条件下で機能しませんでした。例えば:
- 1人の顧客が1回の予約をしたが、途中で雨が降り、詳細担当者が翌日戻ってくる必要があった場合、2回の予約が必要でしたが、1つの広告申込情報、1つの請求書、1つの支払いのみでした。
- オフィスの顧客グループ全員が割引を受けるために同じ日に車を運転することに決めたとき、私は1つの予約が必要でしたが、複数の請求書と複数の支払いが必要でした。
- 1人の顧客が1回の小切手で2回の予約を支払った場合、2回の予約が必要でしたが、請求書と支払いは1回だけでした。
物事を少し混乱させることで、これらすべての外れ値を処理することができました。たとえば、詳細担当者が翌日に戻ってくる必要がある場合、2日目に「完了」という広告申込情報を使用して別の予定を立てると、費用は$0になります。または、1人の顧客が1回の小切手で2回の予約に対して支払いを行う場合、各予約に分割支払いレコードを入れます。これに伴う問題は、データの不一致の大きな機会を生み出すことです。データの不一致は、特に、顧客が1回の小切手で2回の予約を支払った、3番目の例などの財務情報が関係する場合に深刻な問題になる可能性があります。売掛金を適切に追跡するには、支払いを提供された商品やサービスと直接照合する必要があります。
提案された構造:
以下は、このデータを整理および保存するための正規化された構造です。おそらく私の経験不足のために、データの不一致エラーを回避するための優れた方法のように思われるため、データの正規化に重点を置いています。この構造により、他のテーブルの更新を気にすることなく、1回の操作でデータの変更を行うことができます。ただし、読み取りには、データのメモリ内編成と組み合わせた複数の読み取りが必要になる場合があります。後でわかりますが、パフォーマンスの問題がある場合は、「安全な」正規化された構造をそのままに保ちながら、クエリを高速化するために、いくつかの非正規化フィールドを「予定」に追加できます。非正規化により、書き込みが遅くなる可能性があります。
テーブル:
以下は、特定の予定のリストに対して4つのエンティティ(テーブル)すべてを結び付けるために必要な一連のクエリと操作です。これには、各アポイントメントにスケジュールされたサービス、各アポイントメントの合計コスト、および各アポイントメントに対して受け取った未払いの天気に関する情報が含まれます。これは、予定のスケジューリングのためにカレンダーをロードするとき、またはマネージャーが操作の全体像を取得するときの一般的なクエリです。
- 「start_time」フィールドが指定された範囲内にある「Appointments」のリストのQUERY。
- 返された予定の各キーをリストに追加します。
- アポイントメント_キー_リストフィールドのすべての「Line_Items」のクエリには、返品アポイントメントのいずれかが含まれます
- すべてのラインアイテムの各invoice_keyをSetコレクションに追加します。
- 請求書セット内のすべての「請求書」のクエリ(これは、App Engineを使用した1回の非同期操作で実行できます)
- 返された請求書の各キーをリストに追加します
- invoice_key_listフィールドにあるすべての「支払い」のQUERYには、返された請求書のいずれかに一致するキーが含まれています
- 各予定が、予定されているline_items、合計価格、合計推定時間、および支払い済みかどうかを反映するように、メモリ内で再編成します。
...ご覧のとおり、この操作には4つのデータストアクエリとメモリ内の編成が必要です(メモリ内がかなり高速になることを願っています)
誰かがこのデザインについてコメントできますか?これは私が思いつくことができる最高のものですが、一般的に、または特にGAE(google app engine)の長所、短所、および機能の下で、より良いオプションまたは完全に異なるデザインがより適切に機能する可能性があると思います。 。
ありがとう!
使用法の明確化
ほとんどのアプリケーションは読み取りを多用し、一部のアプリケーションは書き込みを多用します。以下に、ユーザーが実行したい典型的なユースケースと内訳操作について説明します。
マネージャーは顧客から電話を受けます:
- 読み取り-マネージャーはカレンダーをロードし、利用可能な時間を探します
- 書き込み-マネージャーが顧客に情報を問い合わせます。これは、マネージャーが電話番号、名前、電子メール、住所などの各情報を入力するときの非同期読み取りの連続であると考えました。または、必要に応じて、おそらく1つクライアントアプリケーションがすべての情報を収集し、送信された後、最後に書き込みます。
- 書き込み-マネージャーは顧客のクレジットカード情報を削除し、別の操作として顧客のレコードに追加します
- 書き込み-マネージャーはクレジットカードに請求し、支払いが完了したことを確認します
マネージャーが電話をかけます。
- 読み取りマネージャーがカレンダーをロードします
- Read Managerは、電話をかけたい顧客の予定を読み込みます
- 書き込みマネージャーが[呼び出し]ボタンをクリックすると、呼び出しが開始され、新しいCallReacordエンティティが書き込まれます
- 読み取り呼び出しサーバーは呼び出し要求に応答し、CallRecordを読み取って呼び出しの処理方法を確認します
- Write Callサーバーは、更新された情報をCallRecordに書き込みます
- 呼び出しが閉じられたときに書き込み、呼び出しサーバーは、CallRecordリソースを更新するためにサーバーに別の要求を行います(注:この要求はタイムクリティカルではありません)
受け入れられた回答:: 上位2つの回答はどちらも非常に思慮深く、高く評価されました。私は、彼らの露出を可能な限り均等にするために、投票数の少ないものを受け入れました。
java - 予定と品目
私は、モバイルカーディテーリング会社 (およびできれば他の会社) の管理に役立つ管理アプリケーションを構築しています。一部のデータをモデル化する方法を理解するのに苦労しています。
この質問は、私が投稿した以前の質問に関連していますが、以下の関連情報を再現しました: データベース設計 - Google アプリ エンジン
このアプリケーションには、「予定」と「明細」という概念があります。
予定は、従業員がサービスを提供するために予定されている場所と時間です。
項目は、サービス、料金、または割引とそれに関連する情報です。予定に入る可能性のある項目の例:
このアプリケーションの以前の実装では、明細項目は 1 つの予定に含まれていました。これはほとんどの場合問題なく動作しましたが、時々問題が発生しました。たとえば、雨のために予定が途中で中断され、技術者が翌日戻ってきて仕上げなければならなかった場合などです。この状況では、同じ品目に対して 2 つの予約が必要でした。このような場合、2 番目の予定に「明細項目」を設定して「終了」などと読み上げることで、データを少しごまかすだけで、費用は 0 ドルになります。
この次のバージョンでは、次のようなテーブル構造を使用して、明細項目を複数の予定と照合できるようにすることを検討しています。
この構造の一般的な問題は、構造が複雑で、1 つの項目を複数の予定と一致させることが適切かどうかさえわからないことです。Line Items が 1 つの Appointment の一部にしかならない場合、実際には各 Appointment に Line Items のリストを入れるだけで済みます。
より具体的な問題は、Google App Engine を使用していて、一連の予定とそれに関連する項目をクエリする場合、最初に一連の予定をクエリしてから、その回線に対して 2 番目のクエリを実行する必要があることです。 IN 演算子を使用して、Line_Item の予定キーのいずれかが、前のクエリから返された一連の予定キーに該当するかどうかをテストします。クエリを分割する必要があるキーが 30 個を超える場合、2 番目のクエリは失敗します。この複雑で大規模な読み取りクエリを回避するためにデータを非正規化することもできますが、おそらくある程度非正規化する必要がありますが、必要に応じて複雑さを避けたいと思います。
私の質問は、この種の状況は通常どのようにモデル化されているのですか? ラインアイテムを複数の予定とペアにすることは適切ですか、それとも、「2 日間の仕事の前半」と「2 日間の仕事の後半」のように、ラインアイテムを単に予定ごとに別々のものに分割するのが普通ですか? ." 同様の成功したアプリケーションはどのようにこれを行いますか? この種の状況における経験則は何ですか? 問題が少ないことが判明した実装はどれですか?
ありがとう!
c# - C#を介してロータスノート8.5クライアントに予定の招待状を送信します
私はInterop.Domino.dllを使用しており、c#コードを介してロータスノート8.5ユーザーにメールを送信できます。今、私はc#コードを介してユーザーに予定の招待状を送信したいと思います。
これが私のコードです。
招待状を送信することはできますが、ロータスノートの予約フォームの誰に参加者を記入することができませんでした。これに関する助けに感謝します。実際、whoプロパティにReplaceItemValueが必要ですが、そのようには機能しませんでした。ありがとう
appointment - 終日イベントを表示する RadScheduler
ねえ、これはあなたのためのばかげた質問です。Telerik の RadScheduler で終日イベントとして表示される予定を取得するには、どうすればよいですか? この特定のレコードが終日イベントであることを RadScheduler にどのように伝えますか (開始日と終了日に関係があります)。