CLE team bulk inactive issues cleanup - if this is important then reopen or create a new issue

MAINT TEAM REVIEW: This feature request is currently unassigned and will be reviewed. In line with stated Jira practice http://confluence.sakaiproject.org/display/MGT/Sakai+Jira+Guidelines Feature requests that are not going to be implemented will be closed with a status of "wont fix". If you intend implementing this issue please ensure that its up to date and assigned correctly

I agree with Mike that this would be a useful feature. I've recently ran into the case where I'm notified of an update to site enrollment, but have no idea how the enrollment was changed. It doesn't seem reasonable to duplicate enrollment information for the purpose of comparison when such an event occurs.

I think this concept for events could be more abstract, though. Instead of recording the user id in addition to the resource reference (in the above example, the site reference), wouldn't it be more useful/reusable to somehow store an RDF-style triple (subject, predicate, object) to capture the event? For example, in the case above we'd have something like user_ref ENROLLED_IN site_ref.

For anything originating from CM, the CM data source (SIS) and/or CM itself presumably knows when the user was added to the section ID, so I don't see the value of duplicating that in Sakai events.

We have been working through a whole set of performance issues related to per-user queries that happen in large sites with provider IDs (e.g. 20K), and creating a per-user event for CM-provided site membership would seem to be a retrogressive step, not to mention the performance hit to operations that involve authz updates.

If this type of event is added, it should be a configurable option with the default turned off.

I agree user events are the ones to be interested in generally speaking. I'm not sure we wouldn't want to capture CM type membership activity.

Could we perhaps not only capture the target of the action, but the agent performing it? In the above case (perhaps a quartz job that pushes in sis info), that could be the name of the bean/job that was running.

One use case I have heard about is this: "can we determine/display when a user was added to a site". If we can answer this question, then one main objective of this enhancement will be met.