如何针对 SharePoint 网站中的任何更改创建每日摘要警报
我最近收到一个要求,要求某人接收有关 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];
}
}
}
这会产生两个问题:
- 用户创建了许多不同的警报。 理想:只有一封电子邮件包含每日摘要。
- 必须设置某种监视器来检查站点中的新列表或库,并自动为用户设置警报。
问:如何为网站中的所有更改创建每日摘要警报?
I recently got the requirement for a person to receive a daily summary alert for any change within a SharePoint site; each site has an owner who is in charge of the content on their site.
The current way we have something working is to automatically set up alerts for every list/library within the site.
// 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];
}
}
}
This creates two problems:
- The user has a lot of different alerts created. Ideal: Only ONE email with the daily summary.
- Some sort of monitor would have to be set up to check for new lists or libraries in the site and automatically set up alerts for the user.
Q: How can I create a daily summary alert for all changes in a site?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我相信您正在寻找的解决方案可以通过审核框架获得。 SP 中的审核非常强大,不幸的是它很容易被输出淹没。
Audit 是 SPSite、SPWeb、SPList 和 SPItem 属性上可用的属性。
使用此属性调整特定的审核标志(使用 .Audit.AuditFlags 属性)以满足您的需求(具体细节取决于您如何定义“更改”,但几乎任何您能想到的都可用)。
有关 SPAudit 对象 的详细信息可在 MSDN 上找到。
一旦您定义了要审核的内容/位置,您就必须将该信息返回给您的用户。
默认情况下,SP 设置一些可在网站集级别使用的精美报告([网站集的 url]/_layouts/Reporting.aspx?Category=Auditing)。 这些可能会满足您的需求。
您最初的解决方案提到通过电子邮件向用户发出警报。 鉴于大多数用户希望将他们的信息集中在电子邮件中(尽管他们的 MySite 是放置报告链接的好地方!),您还有更多工作要做。
您可以使用 SPAuditQuery 和 SPAuditEntryCollection 对象通过对象模型提取所需的审核信息。 同样,MSDN 有一些关于如何使用这些对象的信息。
我建议设置一个在一天结束时运行的自定义 SPJobDefinition,通过电子邮件向用户发送其站点的审核报告。 Andrew Connell 在他的博客上对如何设置自定义作业进行了精彩的解释。
总结:
I believe the solution you're looking for is available through the auditing framework. Auditing is very robust in SP, unfortunately it's easy to get overwhelmed by the output.
The Audit is a property available on the SPSite, SPWeb, SPList, and SPItem properties.
Adjust the specific audit flags (using the .Audit.AuditFlags properties) using this property to suite your needs (the specifics will depend on how you define "change" but almost anything you can think of is available).
Details about the SPAudit object are available on MSDN.
Once you've defined what/where you want to audit, you'll have to get that information back to your users.
By default, SP sets up some nice reports that available at the site collection level ([url of site collection]/_layouts/Reporting.aspx?Category=Auditing). These may meet your needs.
Your initial solution mentioned alerts via email for the users. Given that most users want to centralize their information in email (though their MySite is great place to put a link to the reports!) you'll have a little more work to do.
You can pull the required audit information through the object model using the SPAuditQuery and SPAuditEntryCollection objects. Again, MSDN has some information on how to use these objects.
I would recommend setting up a custom SPJobDefinition that runs at the end of the day to email the users the audit report for their site. Andrew Connell has a great explaination of how to setup a custom job on his blog.
To summarize:
在站点上启用审核策略之前需要考虑的一件事是您添加的性能开销。
我建议在这里尽可能少地留下足迹!
我的意思是,如果您只需要某种内容类型或某个列表来获取此信息,请务必仅在这些 CT 或列表上启用信息策略!
还要将日志记录保持在最低限度。 例如,如果您只对视图感兴趣,而不是删除或恢复,则仅记录这些事件!
在大型网站上,我见过审核非常垃圾的性能!
另请注意此处的一些注意事项:即使您可以在列表上启用审核(如在非文档库中),许多事件(例如查看事件)不会专门针对列表项进行记录! 这在任何地方都没有描述(事实上,我什至在 MSDN 文章中看到 Ted Pattison 提到过项目级审计),但我直接从 CSS 和产品团队得知,由于性能问题,SP2007 中没有实施项目级审计。 相反,您只是在日志中获取一个列表事件,指定该列表已被触及。
文档的跟踪相当不错,但我看到了审核发布页面上的视图事件的问题(在 API 中被视为文档而不是列表项),具体取决于审核的设置方式和位置(例如,如果审核策略是通过继承实现的) CT)所以这是需要注意的事情。
[编辑:昨天对此进行了一些测试,情况更糟:事实上,如果您设置了网站级别审核策略,发布页面就会仅被跟踪! 如果您在列表或内容类型(甚至是从具有策略的内容类型继承的内容类型)上设置策略,您将根本不会收到 SPAuditItemType.Document 级别事件。 将其设置在网站上,您将收到太多审核! 例如。 视图将触发 x2 视图事件,更新也是如此,因此您最终会记录太多内容。 它看起来确实像一个错误,当策略被放入列表和 CT 时,没有任何内容被审核...]
这里的主要信息是:
小心您记录的内容,因为它会影响您网站的性能
测试您期望记录的内容是否确实被记录!
哈
安德斯·拉斯克
A thing to consider before enabling auditing policy on a site, is the performance overhead you add.
I would recommend keeping the footprint as little as possible here!
By that i mean if its only a certain content type or a certain list that you want this information from, be sure to only enable the information policy on these CT's or lists!
Also keep the logging to a minimum. Eg if you are only interested in views, not deletion or restore, only log these events!
On large sites i have seen auditing really trash performance!
Also be aware of some caveats here: even though you can enable auditing on lists (as in not document libraries), alot of events (for example view events) is not logged specifically for list items! This is not described anywhere (in fact i have even seen Ted Pattison mention item level audit in an MSDN article) but i have it directly from CSS and product team that item level audit is not implemented in SP2007 because of performance issues. Instead you just get a list event in the log specifying that the list has been touched.
Documents is tracked fairly ok, but i have seen problems with auditing view events on publishing page (which in the API is considered a document not a list item) depending on how and where auditing was set (for example if audit policies were implemented with inherited CT's) so thats something to be aware of.
[edit: did some testing around this yesterday and its even worse: In fact publishing pages is only tracked if you set on site level audit policy! If you set a policy on a list or a content type (or even a content type that inherits from a content type with a policy) you will get no SPAuditItemType.Document level events at all. Set it on a site and you will get too many audits! Eg. a view will trigger x2 view events, and same with updates, so you end up with too much being logged. It definetely looks like a bug that nothing is audited when policies are put on lists and CT's...]
The main message here is:
careful what you log, since it will affect your sites performance
TEST that what you expect to log is really logged!
hth
Anders Rask
嗯,并不是没有项目级别的审核。 已实施项目级别审核,但您必须针对特定项目将其打开。 如果列表项存在,您可以获取其实例并打开审核,就像对列表执行此操作一样。 问题是如何在创建 ListItem 时将其打开。 也许工作流程可以提供帮助?
Well, it is not a case that there is no item level auditing. The item level auditing is implemented but you have to turn it ON for specific item. If list item exists you can get its instance and turn ON auditing the same as you do this to lists. The problem is that how to turn it ON when the ListItem is created. Maybe workflow could help?