If you send an HTTP 204, you’ll get a spinner and an App not responding message, like below. I would recommend just sending a 200 with an empty body response.
But if you’re wondering if you can send some type of response from your app that will make the component not render at all (i.e. do not show the empty web panel with title), I don’t think so. Anyone else know of a way?
Depending on the location if you send an html document with the all.js included in it - the page will resize to the height of the body(if it’s empty then that’s 0px). The gotcha to this is the issue panel
If you know ahead of time that the user/issue should be seen later then you can use issue/user properties and conditions. See Storing data with entity properties for more details.
Thank you, Neil, for your reply. Yes, I was wondering about the elements outside of the iframe (like div.mod-header for example), but haven’t found anything suitable in the docs. Anyway, 204 will not be an option then, got it, thanks! )
Hi Daniel. Yep, unfortunately this is the issue panel exactly. ) And the condition of interest is per-issue, so I would probably be not able to scan all existing issues ahead of time setting a corresponding property to each of them. I guess then the header stays anyway, and I will just manipulate the HTML inside of the iframe. Thank you!
There’s a bug in about the headless param not being respected. I can dig that up if you need it, but I doubt that will get fixed any time soon (or if at all) - it’s in the ACJIRA project on ecosystem.atlassian.net.
@nmansilla, Wouldn’t that be a very effective way of showing/hiding a panel besides storing properties and conditional logic? A no content (204) says it all, nothing to show otherwise it would be a 200 with some data like you mentioned.
Bulk update is great, it will be useful in so many ways! As for the task at hand, I think I will actually be able to solve it with the entity_property_contains_context if connect-descriptor supports nested conditions.
I think that hiding the add-on on a 204 return code when Jira calls the add-on is a great idea. As such, there’s currently a Atlassian Connect feature request for those who would be interested to vote and/or track it.
We thought about that too but the problem is that that visibility of the panel can change at any time, including after it was hidden. If we were to set an issue property (from the server side) before sending the html for the web panel, it would work until it’s required for the panel to be visible again. When hidden, Atlassian Connect doesn’t call the server anymore to get the HTML. So it would be impossible for us to reset the issue property to tell that the panel is now visible. The panel would therefore always remain hidden.