5

私は最近、SharePoint サイト内の変更に関するサマリー アラートを毎日受信する必要があるという要件を受け取りました。各サイトには、サイトのコンテンツを担当する所有者がいます。

私たちが何かを機能させている現在の方法は、サイト内のすべてのリスト/ライブラリに対してアラートを自動的に設定することです.

// Get the Lists on this Site
SPListCollection siteLists = currentSite.Lists;
foreach (SPList list in siteLists)
{
    if (!list.ToString().Equals("Master Page Gallery"))
    {
        if (list.ReadSecurity == 1) // user has read access to all items
        {
            // Create an Alert for this List
            Guid alertID = currentUser.Alerts.Add(list, SPEventType.All, SPAlertFrequency.Daily);

            // Set any additional properties
            SPAlert newAlert = currentUser.Alerts[alertID];
        }
    }
}

これにより、次の 2 つの問題が発生します。

  1. ユーザーには、さまざまなアラートが多数作成されています。理想: 1 日の概要を含む 1 つの電子メールのみ。
  2. サイト内の新しいリストまたはライブラリをチェックし、ユーザーへのアラートを自動的に設定するには、何らかのモニターを設定する必要があります。

Q: サイト内のすべての変更について、毎日のサマリー アラートを作成するにはどうすればよいですか?

4

3 に答える 3

6

お探しのソリューションは、監査フレームワークを通じて利用できると思います。SP の監査は非常に堅牢ですが、残念ながら、出力に圧倒されがちです。

Audit は、SPSite、SPWeb、SPList、および SPItem プロパティで使用できるプロパティです。

このプロパティを使用して、特定の監査フラグを (.Audit.AuditFlags プロパティを使用して) ニーズに合わせて調整します (詳細は、「変更」の定義方法によって異なりますが、考えられるほとんどすべてが利用可能です)。

SPAudit オブジェクトの詳細については、MSDN を参照してください。

何を/どこで監査するかを定義したら、その情報をユーザーに返す必要があります。

既定では、SP は、サイト コレクション レベル ([サイト コレクションの URL]/_layouts/Reporting.aspx?Category=Auditing) で使用できるいくつかの優れたレポートをセットアップします。これらはあなたのニーズを満たすかもしれません。

最初のソリューションでは、ユーザーへの電子メールによるアラートに言及していました。ほとんどのユーザーが自分の情報を電子メールで一元管理したいと考えていることを考えると (ただし、レポートへのリンクを配置するには MySite が最適です)、もう少し作業が必要です。

SPAuditQuery および SPAuditEntryCollection オブジェクトを使用して、オブジェクト モデルから必要な監査情報を引き出すことができます。繰り返しますが、MSDN には、これらのオブジェクトの使用方法に関する情報がいくつかあります。

サイトの監査レポートをユーザーに電子メールで送信するために、1 日の終わりに実行されるカスタム SPJobDefinition を設定することをお勧めします。Andrew Connell は、彼のブログでカスタム ジョブをセットアップする方法を詳しく説明しています。

要約する：

  • 問題の SPWeb の監査を有効にする
  • SPWeb ごとに SPAuditQuery と SPAuditEntryCollection を使用してレポートを作成する
  • 各 SPWeb 所有者にレポートを電子メールで送信するために毎晩実行される SPJobDefinition を作成します。
于 2009-06-11T14:31:02.630 に答える
2

サイトで監査ポリシーを有効にする前に考慮すべきことは、追加するパフォーマンス オーバーヘッドです。

ここではフットプリントをできるだけ小さくすることをお勧めします。

つまり、この情報が必要な特定のコンテンツ タイプまたは特定のリストのみである場合は、これらの CT またはリストでのみ情報ポリシーを有効にしてください。

また、ロギングを最小限に抑えます。たとえば、ビューのみに関心があり、削除や復元には関心がない場合は、これらのイベントのみをログに記録してください。

大規模なサイトでは、監査が実際にパフォーマンスを台無しにするのを見てきました!

また、ここでいくつかの注意点に注意してください。リスト (ドキュメント ライブラリではなく) の監査を有効にできますが、多くのイベント (ビュー イベントなど) は、リスト アイテムに対しては特にログに記録されません。これについてはどこにも説明されていません (実際、Ted Pattison が MSDN の記事でアイテム レベルの監査について言及しているのを見たことがあります) が、CSS および製品チームから、パフォーマンスの問題のためにアイテム レベルの監査が SP2007 に実装されていないことを直接聞きました。代わりに、リストが変更されたことを示すリスト イベントをログに記録するだけです。

ドキュメントはかなり問題なく追跡されますが、監査が設定された方法と場所 (たとえば、監査ポリシーが継承されて実装されている場合) に応じて、発行ページ (API ではリスト アイテムではなくドキュメントと見なされます) でのビュー イベントの監査に問題があることがわかりました。 CTの）ので、注意が必要です。

[編集: 昨日、これに関するいくつかのテストを行いましたが、さらに悪いことに、サイト レベルの監査ポリシーを設定した場合にのみ、公開ページが追跡されます! リストまたはコンテンツ タイプ (またはポリシーを持つコンテンツ タイプから継承するコンテンツ タイプ) にポリシーを設定すると、 SPAuditItemType.Document レベルのイベントはまったく発生しません。サイトに設定すると、監査が多すぎます。例えば。ビューは x2 ビュー イベントをトリガーし、更新と同じであるため、ログに記録されすぎてしまいます。ポリシーがリストと CT に置かれると、何も監査されないのは明らかにバグのように見えます...]

ここでの主なメッセージは次のとおりです。サイトのパフォーマンスに影響するので、ログに注意してください。

アンダース・ラスク

于 2009-11-12T09:55:43.247 に答える
0

まあ、項目レベルの監査がないわけではありません。アイテム レベルの監査が実装されていますが、特定のアイテムに対してオンにする必要があります。リスト項目が存在する場合は、そのインスタンスを取得して、リストに対して行うのと同じように監査をオンにすることができます。問題は、ListItem の作成時にどのように ON にするかです。たぶんワークフローが役立つでしょうか？

于 2012-03-13T09:47:22.743 に答える