Jak utworzyć codzienne podsumowanie alertu dla każdej zmiany w witrynie SharePoint

Question

Niedawno dostałem wymóg, aby osoba otrzymywała codzienne powiadomienie podsumowujące dla każdej zmiany w witrynie SharePoint; każda witryna ma właściciela, który odpowiada za zawartość swojej witryny.

Obecny sposób, w jaki mamy działać, to automatyczne konfigurowanie alertów dla każdej listy/biblioteki w witrynie.

// 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]; 
     } 
    } 
} 

Stwarza to dwa problemy:

1. użytkownik ma wiele różnych alertów utworzonych. Idealny: tylko jeden e-mail z dziennym podsumowaniem.
2. Konieczne jest skonfigurowanie monitora w celu sprawdzenia nowych list lub bibliotek w witrynie i automatycznego skonfigurowania alertów dla użytkownika.

Pytanie: Jak mogę utworzyć codzienne podsumowanie alertu dla wszystkich zmian w witrynie?

Answer 1

Uważam, że rozwiązanie, którego szukasz, jest dostępne w ramach audytu. Audyt jest bardzo solidny w SP, niestety łatwo można go przytłoczyć przez dane wyjściowe.

Audyt jest właściwością dostępną dla właściwości SPSite, SPWeb, SPList i SPItem.

Dostosuj określone flagi kontroli (używając właściwości .Audit.AuditFlags), używając tej właściwości, aby dopasować swoje potrzeby (szczegóły będą zależeć od tego, jak zdefiniujesz "zmień", ale prawie wszystko, co możesz wymyślić jest dostępne).

Szczegóły na temat SPAudit object są dostępne na witrynie MSDN.

Po zdefiniowaniu, co/gdzie chcesz przeprowadzić audyt, musisz uzyskać te informacje z powrotem dla użytkowników.

Domyślnie SP ustawia kilka ładnych raportów dostępnych na poziomie kolekcji witryn ([URL zbioru witryn]/_ layouts/Reporting.aspx? Category = Auditing). Te mogą zaspokoić twoje potrzeby.

Twoje wstępne rozwiązanie wspomniało o alertach wysyłanych pocztą e-mail dla użytkowników. Biorąc pod uwagę, że większość użytkowników chce scentralizować swoje informacje w wiadomościach e-mail (chociaż ich MySite jest świetnym miejscem do umieszczenia linku do raportów!), Będziesz musiał wykonać trochę więcej pracy.

Można pobrać wymagane informacje z audytu za pomocą modelu obiektowego przy użyciu obiektów SPAuditQuery i SPAuditEntryCollection. Ponownie, MSDN has some information, jak korzystać z tych obiektów.

Polecam skonfigurować niestandardową definicję SPJobDefinition, która działa pod koniec dnia, wysyłając użytkownikom e-mailem raport z audytu swojej witryny. Andrew Connell ma świetne objaśnienie how to setup a custom job na swoim blogu.

Podsumowując:

• włączyć inspekcję dla SPWeb tych w pytaniu
• utworzyć raport przy użyciu SPAuditQuery i SPAuditEntryCollection dla każdego SPWeb
• utworzyć SPJobDefinition który uruchamia każdej nocy, aby wysłać raport do każdy właściciel SPWeb

Answer 2

Przed włączeniem zasady audytu w witrynie należy rozważyć, zwiększenie wydajności, które dodajesz.

Zalecam trzymanie stopy w jak najmniejszym stopniu tutaj!

Mam na myśli to, że jeśli jest to tylko określony typ treści lub lista, z której chcesz otrzymywać te informacje, pamiętaj, aby włączyć politykę informacyjną tylko na tych TK lub listach!

Również ograniczyć rejestrowanie do minimum. Np. Jeśli interesują Cię tylko widoki, a nie usuwanie lub przywracanie, rejestruj tylko te wydarzenia!

Na dużych witrynach widziałem audytowanie naprawdę wydajnych koszulek!

Pamiętaj również o pewnych zastrzeżeniach: nawet jeśli możesz włączyć inspekcję na listach (tak jak w bibliotekach dokumentów), wiele zdarzeń (na przykład zdarzenia wyświetlania) nie jest rejestrowane specjalnie dla elementów listy! Nie jest to nigdzie opisane (w rzeczywistości widziałem nawet, że Ted Pattison wspomniał o audicie na poziomie przedmiotu w artykule MSDN), ale mam go bezpośrednio od CSS i zespołu ds. Produktu, który audyt poziomu pozycji nie został zaimplementowany w SP2007 z powodu problemów z wydajnością. Zamiast tego otrzymujesz w dzienniku zdarzenie listy, określające, że lista została dotknięta.

Dokumenty są śledzone dość dobrze, ale widziałem problemy z inspekcją zdarzeń przeglądania na stronie publikowania (która w interfejsie API jest traktowana jako dokument, a nie pozycja listy) w zależności od tego, w jaki sposób i gdzie przeprowadzono inspekcję (na przykład, czy zasady kontroli zostały wdrożone z dziedzicznymi CT), więc to coś, o czym należy pamiętać.

[edit: czy niektóre badania wokół tego wczoraj i jego jeszcze gorsze: W rzeczywistości strona wydawnicze jest tylko śledzone jeśli ustawisz na stronie polityki kontroli poziomu! Jeśli ustawisz zasadę na liście lub typ zawartości (lub nawet typ zawartości dziedziczący po typie treści z zasadą), w ogóle uzyskaszSPAuditItemType.Document level events. Ustaw go na stronie, a otrzymasz zbyt wiele audytów! Na przykład. widok wywoła zdarzenia widoku x2 i to samo z aktualizacjami, więc kończy się to zbytnim rejestrowaniem. To zdecydowanie wygląda na błąd, że nic nie jest kontrolowany, gdy zasady są umieszczane na listach i CT ...]

Głównym przesłaniem tu jest: uważać, co się zalogować, ponieważ będzie to miało wpływ witryn performance test, który co spodziewać się, że log jest naprawdę zalogowany!

HTH Anders Rask

Answer 3

Cóż, to nie jest przypadek, że nie ma audytu na poziomie elementu. Audyt poziomu przedmiotu jest zaimplementowany, ale musisz go WŁĄCZYĆ dla określonego przedmiotu. Jeśli istnieje element listy, możesz pobrać jego instancję i włączyć inspekcję ON, tak jak robisz to dla list. Problem polega na tym, jak włączyć go, gdy tworzony jest ListItem. Może przepływ pracy mógłby pomóc?