The challenge here I guess is that if you filter by "email@example.com" you will get the token, BUT you filter out the other events that have the token but not the login info. A way of solving this would be to run this filter in a subsearch that emits all corresponding tokens for a certain login, and the outer search then grabs all events with these tokens. Finally use transaction for tying sessions with the same token value together. Assuming you have tokens extracted into a field called token:
Right, so wouldn't this be solved by actually using this search but wrapping it inside some kind of form search view that lets users enter the login without having to worry about what goes on behind the scenes?
I do something today that matches this and it works just fine. What I want is something I can put in props/transforms and allow other users to run the searches without teaching them this level of syntax.
I.e., just teach the support guy to type 'login = ??'
The system records the login ID only once, on the entry wherein the token is assigned. From that point forward, every log entry references the token only.