@david2 We are still discussing internally. I should have a recommendation for you this week.
However, couple of points
For this, we are working so that the new Issue Content module loads automatically on every issue view, so you have immediate access to use javascript code. However, it comes with a quick add button item, which you don’t want because it will just display nothing…perhaps we could turn this into a ‘headless Issue Content’. It loads automatically and has no quick add icon and no iframe to show. We may make this a seperate module though specific to this ‘headless panel’ use case. Just FYI for 1.2) You can use AP.issueRefresh() function to re-load the new issue view (it’s react now so it doesn’t do a full page refresh. It will update the web panel)
Same thing as above, you need like a headless panel option. That is an interesting use case. Right now, we only replace the glance w/ right.context and issue content module with left.context location, they don’t really cross over. I think we can solve this differently though and not go down this route.
Yes, you understand that correctly. “Anyway, if so, we could keep the old web panel module for the legacy issue view and use the issue content module for the new issue view, and they wouldn’t conflict with each other.” Yes, that was our intention.
I am leaning towards us just building a headless module for this type of use case. Maybe going down taking the Issue Content module and just passing in options to not show quick add icon or iframe and always load (which we are doing soon anyways).
Regarding 1.2, I think you’re missing the point: we need the Issue Content Module content to be reloaded (or else an event to be dispatched) when the issue is transitioned - and only then will we call refreshIssuePage(), when necessary, to refresh the rest of the issue view.
Anyway, I agree that a headless module would be the ideal solution. It would always be loaded on the new issue view, not be visible, and it would be able to listen to an event triggered when the new issue view is refreshed (such as when the issue is transitioned). Note that this event (which doesn’t currently exist) is essential, otherwise our headless module’s JavaScript wouldn’t know when to run.
However, where would you load that headless module (essentially a JavaScript file)? I’d love to have the equivalent of Jira Server’s Web Resource with a “new issue view” context, but I doubt you will find this acceptable as the JavaScript would be loaded into the main page…
Or would you actually make the headless module a normal Content Module (html) loaded inside an iframe, but just make the iframe invisible (“display:none”) and without a quick add button to make it visible?
Bottom line, I think a good feature would be the existing new issue Content Module with the following extra options:
autoload when the new issue view opens
hide the Content Module’s IFrame by default
hide the Quick Add button
and a new event dispatched by the New Issue View to Content Modules to notify that the issue has been refreshed (ideally, the event should pass along a “reason” such as ISSUE_TRANSITIONED, ISSUE_EDITED, ISSUE_DISPLAYED, etc.)
A good thing with this event is that it would be very useful to a lot of Content Modules, not just ours. It would allow content modules to do partial refreshes too instead of reloading the whole iframe content every time.
Regarding 1.2, I think you’re missing the point: we need the Issue Content Module content to be reloaded (or else an event to be dispatched) when the issue is transitioned - and only then will we call refreshIssuePage(), when necessary, to refresh the rest of the issue view.
On this, I was assuming the issue would refresh itself on the transition event…I agree that is weird it doesn’t do that. So you are saying you have no idea when to call the refreshIssuePage() function because nothing is broadcasted (assumes you already have the module loaded).
On that same note, the event idea is really interesting to share when the issue has been refreshed, I do like that approach and gives a lot of flexibility to you. So, I think we will be advocating for both
We should be refreshing the issue upon issue transitions (and any other time when an issue state changes). This would cause all the modules to reload as well.
We broadcast an event when that happens and give a few pieces of additional data, definitely a reason to start.
I am catching up with a few people on our team to talk about this whole topic so will include this in our discussion. I will share our proposal to you and get your feedback before we start building it.
Thanks @tpechacek for hearing me out
One additional remark: if you implement the event, you might also want to add an option to the Content Module to let it indicate that it does not want to be reloaded when then issue is updated (if it instead relies on the event). Or it could be simply a response to the event to indicate it has handled the event and doesn’t want to be reloaded. Otherwise, the event could be lost in the reload.
@david2 unfortunately this has been delayed quite a bit due to other higher priority items. However, it is still on our roadmap and should be completed within the 2-3 months.
See [ACJIRA-1600] - Ecosystem Jira for the issue. Your feedback will be going into how we implement this, but essentially our goal is to give ecosystem partners control on when to show/hide the iFrame related on the Issue Content module (and related quick add action tied to that module).
I will provide an update once we are getting ready to implement it so you have visibility on how/when you can start to test it as soon as we can enable it for specific dev instances. This way you can test before public release.
I like the approach of an event based solution. It gives us the ability to react in any way we see fit to changes. As I mentioned on ACJIRA-1600 it would be good to have a Javascript API that would allow us to close a panel (including glances). This supports workflows (probably taskk oriented) where an action is complete and content no longer needs to be shown.
Am I right in that contentPresentConditions provides zero control over the display of an issue panel? Like other conditionals I assumed if I set this one to false then the panel would not display. I always want the quick-add to display, but I want to control whether a panel is displayed. That doesn’t seem to be possible with these conditionals.
I’d like to show the quick-add button but if they click it and contentPresentConditions is false, then the panel should remain hidden. That doesn’t seem to be possible?
unfortunately this has been delayed quite a bit due to other higher priority items. However, it is still on our roadmap and should be completed within the 2-3 months.