Resolved in trunk: r47466:47469 (event, search, memory, reference)

And 47471,47472 (entitybroker, content)

removing the 2.5.x merge status as branch managers discussion determined this a fairly substantial change in functionality and thus, didn't meet the criteria for 2.5.x

From sakai-dev:

>>> "Stephen Marquard" <stephen.marquard@uct.ac.za> 9/2/2009 8:42 PM >>>
There are 3 ways in which the CONTEXT can be set:

1. The entity code for the event reference has a parser which will return the context for the reference concerned, e.g. in references like /content/group/53450fdc-643a-4bf9-a860-adca9c72bbaf/, the context is embedded in the reference.

2. If the reference itself doesn't yield a context from the reference's service, then the tool context in which the request thread is executing is used as the context. This means that events posted by a tool placed in a site in response to a user action will get the context of that site.

3. A tool or service may explicitly pass the context when it posts events using an extra parameter.

In some of your examples:

Creating a new site - you do so from your My Workspace, so the context is your workspace's site id, except for some events where the context is derived from the ref.

alias.add events may come from new site creation, or may come from the site itself (e.g. adding Email Archive in Site Info vs configuring it in My Workspace when creating a site).

As you've noted, the CONTEXT is not completely consistent but it is a progressive improvement on 2-5-x as it allows many more events to be reliably associated with sites (viz. for those tools which use event REFs that don't include a site id).

Feel free to add JIRAs for cases that you think are truly inconsistent. It's possible some of those inconsistencies could be straightened out by getting the tools/services to explicitly set the context to whatever is most appropriate.

Cheers
Stephen

>>> Steve Lonn <slonn@umich.edu> 9/2/2009 8:20 PM >>>
Please forgive a very non-technical question...

I am just beginning to get familiar with the way Sakai 2.6 logs
events, particularly with regard to a new column in the table "context"
It appears that the goal of this field is to grab the site_id that is
associated with this event, which is very helpful.
However, it appears that sometimes this field is not grabbing the
site_id at all, resulting in a (null). Othertimes, it seems to grab
the user's ID or the ID of their My Workspace instead of the site they
are using.

If someone can please explain what's going on, where the known gaps
are, etc. I would greatly appreciate it, particularly since this
information does not appear to be captured in the relevant JIRA
entries (SAK-10801, SAK-13809)

Thanks! Steve

Issue verified (should have been closed earlier).