Hi,
it is known that the add-on can be displayed conditionally based on some predefined platform conditions or a stored entity property value.
But in my add-on there is an inside data which decides whether the add-on should be applied in this particular case or not.
Is there a way to display (or NOT display) an add-on based on the response that Jira receives from it? I mean, for example, if the add-on returns HTTP 204, the add-on area is not displayed at all?
Thanks!
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.
That said - have you signed up for the Alpha program for the new Jira Cloud Issue view: Alpha program for the new Jira Cloud issue view - Atlassian Developer Blog ?
All of that said, since the condition of interest is a per-issue there was a new api announced in New module and REST APIs for Jira Cloud apps - Atlassian Developer Blog (they buried the lead): https://developer.atlassian.com/cloud/jira/platform/rest/#api-api-2-issue-properties-propertyKey-put - I haven’t used it so I don’t know how well it performs but you can update issues in bulk that way…
@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.
Jira Cloud actually supported the so called Remote Conditions but they were deprecated due to performance issues. You should instead set an issue property based on your app’s internal logic and display your add-on’s web panel based on that property value (or presense). You can get/set issue properties both from JavaScript via the Connect Framework or from your server-side code via Jira Cloud’s REST API, that should cover any use case.
Thanks @dmitry,
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.