Fix as part of implementation o

Dashboard operates based on event processing. Discarding how computational intensive the update would be, you couldn't do any updates at login for users without making dashboard depend on the api's of every existing and future tool in Sakai.

This seems like it would effectively change it from what it is (an simple stand-alone event processor) into something like a all-in-one synoptic tool? How else would you do this update that way?

I can see a process like.
If there a enrollment event for a site.

• Copy all of the public dashboard events that have been tracked on a "dummy site" into this newly enrolled user.

It would miss the case if someone was added into a group after it was created (and assignments or something was previously in a group) but would be pretty good?

The getSites not taking a user parameter looks to be a old legacy decision deep in the site service (DbSiteService->getSitesFields) which isn't going to be an easy one to change. Probably it expected with to be called returning all the sites or just filtering on SelectionType.ACCESS/JOINABLE. . .

One possible approach is to do the bookkeeping whenever a user logs in - there is a user.login event thrown, and by that time, the user's sites are already up to date.

So I wanted to implement a Event process for this in Dashboard tool, and get all sites that user has access to and then tidy-up the dashboard sites for him.

However, the problem is this: SiteService.getSites() only works for current session user. Dashboard thread is run based on "admin" user. So it need to become the session user of the "user.login" event, get the user's sites, and become back the admin user. I do not like the approach since I am not sure whether switching users would be problem for other dashboard event processors...

The bottom line is: why SiteService.getSites() does not take in a user param?

The way dashboard is implemented, I don't see this getting fixed. I'm pretty sure dashboard processes the events (like for new assignment) real time and creates links directly to enrolled students. Even if you did have something to reprocess previous events in the course on a roster add, the events table at most places is wiped out daily. It seems like to do this you'd need some generic "person" to represent the class and then copy links from that person on a roster add? This sounds like it would take some time to implement.