Feature Request: Live View Of Who's Looking At Ticket

A user asked me today if RT could display the names of other RT users who are currently looking at the same ticket they are. For teams of folks working on the same tickets, I can see this being a big help. This would help inform the user if another team member might be about to take or reply to a given ticket. Some visual indicator at the top of the ticket view screen would suffice.

RT is designed to be displayed as web pages. These are stateless. Once displayed, you do not know if they navigated away from the page unless some form of ‘on leave’ tracking is done, and I don’t think that happens in RT.

Best I think you can do is see who has accessed the page in the last N minutes kind of check.


If it were 2005, I’d agree…but real-time updates on web pages is pretty common these days.

RT treats us pretty well… but it being stuck in 2005 is the root cause of nearly all my complaints.

Josh, could you cite specific examples of things we could improve? I hope 4.4 was a step in the right direction for you. 4.6 will be even better :slight_smile:


Tim, reading you reply again, I think you are forgetting that the real-time update is based on a refresh of the web page. Basically asking it to show once again. This resets the time since last pulled.
HTTP is stateless. Any stateless system cannot be used to determine if someone is still watching. There is no keep-alive or other method to determine if someone is still at the same place or if they left for another.


I’m not forgetting that HTTP is stateless. I’m a web engineer with 20 years experience.

Do you use GMail? Twitter? Facebook? Or really any other modern web site? ITR, one of RT’s primary competitors, provides this feature as well. All of those have real-time updates through either WebSocket connections, or long polling, or some other mechanism.

You are forgetting the consequence of being stateless: being unable to determine if someone is viewing the ticket or not.
In order to achieve this, a method of imposing state must be placed on top of the web page.
One method is to assume a successful page view means the ticket is being looked at for an assumed small amount of time (presumably the auto refresh is less that this amount).
Another is to request a lock of some type on the ticket. But that can lead to locks that must be cleared in some manner if not manually cleared by the requester. How long before the auto clear happens?

What if someone views a page than goes to lunch with the page displayed. Are they really viewing it the whole time they are at lunch?

What if someone views the page, then crashes the machine? Any tracking of locks now fails, since the system cannot unlock the ticket based on the session that locked it.

I have used systems that shows other web users (google docs), but that requires a constant refresh cycle to manage the list. Basically telling the server “I’m on this page” every second they are on. Then others look every second to see who is claiming to be there. The granularity might be other than a second, but that is a reasonable value for simulating real-time detection.

Without some constant back and forth with the server, you will not have a real time view of state on a stateless system.


I disagree with your assessment of what is necessary to provide live updates, and I also disagree that locking is necessary. I didn’t ask for locking; I just asked to know who else was looking at a ticket at the present time.

In your scenario, if someone goes to lunch, is it better to lose all their unsaved updates because someone else updated the ticket out from under them?

XmlHttpRequest-style live-updates are commonplace. Yes, you would need to implement some sort of state table to track who’s looking at what.

I love RT, and much prefer it over other vendor’s software, but RT’s developers have a history responding to very reasonable requests with “it’s too hard” or “that’s not the way we do it”. I got a similarly disappointing response to my request about changing the date formatting on tickets. I was basically told that I had to implement a new Perl module that created the date format that I want, and then install that into my RT server. Do you know how I make such a change in Drupal? I go to the “Date Format” administration web page, and I type: “m/d/Y” into a text box and click “Save”.

Web 2.0 is not a passing fad. If you want RT to remain competitive you need to embrace that.