Closing based on comments that this does not seem reasonably fixable in the current architecture

I am unassigning this issue as it gives the wrong impression. I dont have enough hours in the day to look at this issue at the moment and keeping it assigned to me give the reporter hope that I might be able to look at it. I am very sorry. If this issue is a real blocker for production then I would suggest you look for resource in the community to fix the problem, I am happy to respond to emails and guide. Where the code base is Rwiki or Search, I have absolutely no problem with someone else working on the code, this after all is a community.

I don't think there's an easy solution to this because the presence service works on the basis of location ids which are opaque (i.e. there's no lookup service or well-defined mapping to get from locationId to context/siteid), unless we just hard-code some assumptions, i.e. siteid-presence = siteid, or change the way locationIds are constructed to be more predictable and parseable, e.g.

/location/site/siteid

Relevant code is in presence-impl/impl/src/java/org/sakaiproject/presence/impl/BasePresenceService.java (setPresence and removePresence).

Updated Affected Versions

Presence events are logged by the presence servlet (and more recently by the portal directly), so don't have a tool placement context that can be used to get the context.

Either the REF field needs to be parseable through entity, or the presence service needs to specify the context when posting the event.