while experimenting with the Issue Glance I’ve got a few questions regarding its functionality. Is this something that can be fixed, or is it intended to be like this?
Two requests per each interaction.
When clicking on a Glance header it issues a new request to the webpanel URL. While understandable, it creates an additional load on the add-on servers. The old webpanel just opened once when an issue opens, but now each user interaction with the Glance will issue a new request.
But what is even more surprising is that the Glance issues one more request when closed! If I click on the “back” arrow to close the Glance, I get another request to the webpanel URL (with nothing on the Jira side processing the response obviously).
Loading pause.
After a Glance has opened a webpanel and up until the webpanel receives any HTML, there is nothing on a screen, just blank space. I think the old webpanels had a spinner here with “waiting for add-on” hadn’t they? We can’t show the spinner from an add-on since no HTML is rendered in a glance’s webpanel yet, and so users are left with the blank screen for come time.
Glance status.
If I update the issue property for a Glance status, I don’t see those updates until I reload the entire issue. Glance continues to display the old status even if I open/close it.
This effectively makes statuses not-so-dynamic. When an issue is opened I can’t renew the status because the add-on will not be called until the Glance is opened. And then even when the Glance is opened and I did renew the status, I don’t see a new value on the Glance until I refresh the entire issue.
So, basically, the status is always one step behind: it gets its value when an issue is opened (i.e. from the previous interaction with the add-on), and then it won’t get a new value until the issue is closed and reopened again (i.e. all the current working session updates will not be visible until reload).
Thank you, @jmort! I really don’t see the spinner on any try I made, while the delays are quite significant. When running the add-on directly from my development environment I get more than a second delay, and still no spinner.
As for the status badge - sure, this is probably the intended behavior, but it basically means that the status always displays a value from the previous issue opening, not the current one. Frankly, I can’t see too much use cases for this “retrospective” 1 step behind report.
Heres hope that all this is what Alpha stage is for. )
Hey @k.menshov, thank you for experimenting with the glance module and bringing these topics up!
For #1: Two requests per each interaction
This is a bug. That is definitely strange on the ‘back’ arrow causing another request to fire. I will talk to our team internally about this and if it is needed. Can you think of any reason you would need this?
Our goal is to make it similar to the old webPanel and just make one request when the issue detail view is loaded.
For #2: Loading pause
This is a bug. We will look at how the async request in #1 (happening on issue detail view load) could be used to already have the iFrame available so there is very little loading time. Either way, for slow load times, we will add a loading state for these scenarios.
For #3: Glance status
This brings up a great point and something we want to work towards. We still have work to do so that the entire issue itself is ‘live’ and can update upon any piece of state changing. We are not there yet though. For the glance status, we do have some limitations with how issue props work and knowing when to re-load . This is how conditions work today as well from my understanding.
For “When an issue is opened I can’t renew the status because the add-on will not be called until the Glance is opened.” I think making the request to the add-on being called on issue load should resolve this scenario.
Hi @tpechacek! Thank you very much for your feedback.
No, I don’t think I see any reason for a request being issued on Glance closing. Even more: from my server logs I can see that nothing at the Jira side processes this response anyway (because otherwise I’d see some other activity too, but instead the server response just goes into the void).
And it is great to hear that you are looking at making the webpanel send just one async request. That would be awesome! Not only that’d allow to reduce the server load (avoiding a new request each time the Glance is opened), but also would help to improve user experience, because by the time a user would open a Glance, the webpanel content would already be there.
As for the Glance status being dynamic, well, ideally I’d think it would be great if the status could change each time the property itself has changed. I do, of course, understand that there are limitations towards that. But we do have some dynamic updates already, like with the issue “Start Progress/Stop Progress” state, assigning people for an issue, voting/watching an issue, etc. Maybe it could work somehow similar with the Glance statuses too?
Thanks for pointing out the refreshIssuePage(), I will definitely look into it. My only concern here is whether or not an entire issue “blinks” upon reloading - that would degrade the user experience somewhat.
Ok, great, we will be making the glance module send one async request and going down this path. I will post an update once this has been updated on our end.
Re: the glance status being dynamic - I have talked with my team and it seems we will be able to refresh the glance module itself (without re-loading the whole issue app) upon closing the glance detail view. This is the best outcome as any updates the user makes within the iFrame that would update the issue props, we would receive from your app, and upon closing the glance, it would be refreshed so users see the new value automatically. Also on this, I will post an update once this has been updated on our end.
Let me know if you have any other questions / comments as you continue to experiment. Thanks again for raising these issues! Cheers
I’m setting the issue key ending in :status and I still have to reload the issue for the updated info to take effect. Being able to reload just the glance would be ideal.
