Top Bar App Access To Current Ticket

Hi there! So you were on the right path in the last paragraph, with respect to running a hidden sidebar app to pass the data up to the top_bar location. We do have a sample app that covers this topic, specifically this part of the app. The code is pretty clearly commented, but it doesn't give full instructions on how to do it, so if you run into any issues seeing how we handle instances and pass the data around, let me know and I'll be glad to help.

@greg29 Thank you!

I was able to get handlers to sidebar instances from my top_bar app using the example code you provided me with.

I have another concern that I would like to get your assistance with if possible.

In case of the user refreshing the app after already having three different ticket tabs open, when I run client.get("instances") I get an array of different side_bar instances that are already opened, but I'm trying to figure out if I can determine who is the currently active one.

I noticed that if I hard reset + clear cache from the browser, I will only get the current active instance.

Any ideas on how I can workaround this issue?

Thanks!

I would like to add that this seems intermittent, such that most of the times this is OK.

When I try to replicate a scenario that a user with multiple ticket tabs will refresh their page, client.get("instances") only returns the active ticket side_bar instance.

But still, if there is a way that I can verify while iterating over the instance list who is the actual active instance, I will be happy to know how to do that.

Yeah, so that is definitely a side-effect that exists when you've got and I have not solved myself, nor have I seen an example of it being solved. The reason that you're seeing different behavior after a hard refresh is because the apps in the other tickets tabs have not yet been registered/activated after a refresh, so you will only get the data for that currently open ticket tab. Since "tabs" in the Zendesk agent interface don't function the same way that tabs do in a browser...specifically in that they are not separate windows, along with all of the cascading bits of the DOM tree...they won't work as you might expect. The ticket "tabs" all live within one browser window, so parsing out the different instances of the app in different tickets is basically a nightmare.

All of that being said, we do recommend using local storage to juggle this around and you can read about that here. You could use the ticket_id as the key/value pair in local storage and then look at that to match the current active ticket to the appropriate installation_id. Which is probably not exactly what you're looking for and it's also a little (read: a lotta) bit janky, but it may give some ideas for how you can accomplish this.

It's a lot of words to say there isn't a great answer, but if the above gets you moving in the right direction, please share that with us, we'd love to get ideas coming back to us!

@greg29 bit of a delay, but I can share how I solved it already case it will help someone.

What I do is run an additional background app instance which I know will be app.registered on window load.

Than, I find the top_bar instance (which is not registered yet) but iterating over client.get('instances')

Once I get a handler to the top_bar instance, I invoke a (popover, show) immediately followed by a (popover, hide) in order to make sure it is also registered ASAP

now that the top_bar is registered, I can listen to instance.created events and catch side_bar instances upon registration and follow them reliably in order to get the active one.

that way I don't have to deal with figuring out who is the active ticket based on existing ones.