So, this might not be necessary.  If the course_id is integrated into the URL like: /courses/edx/E101/2013_SOND/do_something, then our middleware will annotate *all* events emitted during the request processing for that URL with the course_id and user_id.  The primary reason I created the method in CourseEnrollment was because it is triggered by an ajax request to /change_enrollment with the course_id being passed in via a POST parameter.  This meant that I had to create a special context that overrode the default (empty) course_id with the one that was passed in.  If these calls are also made under similar ajax-y circumstances, then this method is definitely necessary.

If it is necessary then I would prefer we put it somewhere both CourseEnrollment and the shopping cart stuff can access, so that we don't have to duplicate the logic.

If it is not necessary, then you can simply call "server_track" directly where you need it, without the `with` block or the context or any of that stuff.  In fact you probably won't need crum either since they look like they are being emitted from views (which already have a reference to the request).