Can vendors hide and the web panel opened by a quick-add button?

Jira Development Jira Cloud
#1

Hear ye, hear ye! In times past, conditions could be used to hide or display a web panel. In cases where users cancel adding content, we are dismayed at our empty web panel (Alas! We vendors should avoid frustrated customers seeing a bunch of empty web panels that were not relevant :wink:

Is there a way to programmatically hide the panel opened by the quick-add if there is no content to display?

I’m concerned about the following case:
A user clicks the quick-add button to attach a diagram. An attach diagram dialog opens. The user clicks cancel to close the dialog resulting in an empty open web panel.

3 Likes
All issue content panels become collapsed after the add-on reinstall
Feature suggestion: Allow developers to indicate that an issue contains non empty issue content panel
#2

+1 for the question.

However, I would be also interested in an opposite case, i.e. how to programmatically show a panel for which content has been added in some other way (through REST API in our case).

3 Likes
#3

+1 for both questions. I also touched the same points here - Feature suggestion: Allow developers to indicate that an issue contains non empty issue content panel

#4

I have looked deeper into the case, and it seems even more worrying than I initially thought.

When a user decides to open app panel through quick-add “
” button, the following HTTP call goes to Jira:

/rest/api/2/issue/DEMO-2/properties/com.gebsun.plugins.jira.issuechecklist_issue-checklist-content-5482932789235993727

It consists of app key and the “magic” number that is somehow related to plugin installation (or URL).

The problem is that when I move the plugin to different URL and then install it again in Jira, the “magic” number is changed and all content panels opened previously for all issues disappear (they must be open back).

I haven’t tested that in production yet, but if I’m right then, we won’t be able to change URL for the production instance of the app without affecting our customer severely (plugin panel will disappear for all of them, even though there is content available). It is a serious problem.

My questions are:

  • What is the “magic” number for? Why isn’t the plugin key enough?

  • Is there (planned) a property that could be accessed/altered by a plugin and tell “the content is already there”? This would allow Jira to show/hide the panel without user interaction?

Can anyone from the Atlassian Connect team shed some light on this?

Thanks,
Jack

1 Like
#5

@rmassaioli, @dmeyer, any input on this?

We receive complaints from the customers that the panel is not visible while it should.

We are also worried about changing production URL.
It is required to install the app on a new URL when we change the scope inside - admin needs to agree on a new version in that case. It means that all currently visible panels will disappear according to our investigation.

Thanks,
Jack

#6

Hi @jack,

I need to talk about this in more detail with the team, but wanted to let you know we are looking into this. Your points raised in the post above are valid and agree they are concerning.

Our initial stance on this with the new modules and issue detail view were that content areas (using issueContent module) would be scoped to the left-hand side and would require the user to add that content. One of the usability problems we were looking to address was the overwhelming number of empty iframes that took up a lot of space on the issue detail in the old view.

To follow up and gain a bit more insight as to this use case. When changing the production URL, you are expecting the Jira admin to re-install or install a new app entirely?

I will get back to you later this week on this topic and identify a path forward.

#7

Hi @tpechacek,

Thank you for the heads-up.

When comes to changing production URL I was thinking about re-install (update) of the app.
We exercised that few times in the past (e.g., when scoped changed in a descriptor, or when OpenShift was shutting down their old infrastructure, and we had to migrate).
If you don’t allow changing the URL, it will bite add-on vendors rarely but painfully in various situation.
If possible, the implementation/algorithm should recognize the add-on by its key (which is unique as far as I know) instead of the (add-on key, magic number) pair as it is now:

/rest/api/2/issue/DEMO-2/properties/com.gebsun.plugins.jira.issuechecklist_issue-checklist-content-5482932789235993727

I understand the rationale behind keeping new issue view clean and fast (and a decision to display content only when users add it). Nevertheless, in our case, and I believe in the case of some other add-ons, it is possible to add the content from the outside of UI, through REST API.
Maybe it would be justifiable not to display “content” panels by default, but allow vendors to enable them with REST API in various situation.

I’m looking forward to hearing from you.

Thanks,
Jack

#8

Hello @tpechacek,

is there any news to share?

We have made risky decision to move our panel from the right (Glance) to the left (Content) as it provides real content to issues.

Nevertheless, we are terrified of possible side effects and extremely confused customers if at any point we decide to change our app URL.

Thanks,
Jack

#9

Hello @tpechacek,

I just noticed on my dev instance that Content panel is now being enabled through the request to the URL that consists plugin key followed by a module key (without the magic number used previously).

Is this a planned and final change? If so, then I’m super happy as it solves all the issues with locating the panel on the left.

BTW. The another not tested problem with the former “magic-number” solution was that all the Content panels could disappear after migrating Jira from one instance to another one.

Thank you,
Jack

1 Like
#10

Hi @jdawson, @jack, @nnmatveev, apologies for not being as responsive with updates and answering your questions as quickly as I would like. I am going to be working on this moving forward, but please know that we are reading these and very much appreciate your feedback & comments!

And now for the update

A fix was made to production about a week ago that resolves the problem around the magic number and Jira users losing all the previously opened content panels for any given Jira issue. We are saving the module’s descriptor module key and dropping the random numeric part. This should persist the user preferences on which content panels are displayed when updating the descriptor for your app.

So, you should be able to freely update your descriptor without any negative affects on the Issue Content module and the display of iFrames below.

What we are working on now

We are working on being able to allow vendors to programmatically show/hide the iframe that is tied to the new Issue Content module.

  • We were hesitant of allowing this in the beginning, because we had a lot of user feedback about the overwhelming use of empty iFrames being drawn across the old issue detail view. We wanted to address this as part of the new issue view.
  • However, there are many use cases where you will be adding content to an issue programmatically (not in Jira) that we need to accommodate for. Also, the source of this data originates with the marketplace app vendor, so any end state ends up with giving control to vendors on whether to show iFrames or not (ideally, based on content being there or not as a best practice).

The way this will work is that we will allow you to specify the issue entity property to look at, which will be tied to the Issue Content module. You will define this up front in the descriptor. Then, our logic is simple: If the entity property exists at all (even if null value), we will show the iFrame, if not we will hide it. It’s up to you the vendor to then manage this lifecycle.

This should tie in nicely with the ACJS event that fires when the quick add icon is clicked by a user, opening up the attach diagram in your example, and then if there is content added and the modal is closed, we will show the iFrame below. If they cancel out of that modal and no content is added, then no iFrame will be displayed.

More details on this will be published on a seperate thread under tag ‘new-issue-view’.

Cheers!

4 Likes
#11

That is awesome news! Thank you, guys!

To make your day even busier there is another fly in the ointment though. Here is the feedback we got from one of the customers: New issue view "honest" feedback from "real" customer

Hopefully, it is something that you guys can consider too.

Cheers,
Jack

1 Like
#12

Thanks @jack I did see that one. Will have a response there soon!

#13

@tpechacek Awesome! Thank you!

#14

@tpechacek is there JRACLOUD ticket we can watch for that?

#15

@david2, I created this one to keep track of it. https://ecosystem.atlassian.net/browse/ACJIRA-1600

The new issue view has a lot of surface area, and we are always trying to address the next most important item that will help our customers based on our feedback loops. The team is still working through this.

Cheers

#16

Thanks @tpechacek.

There are a few things that are not clear to me related to the Issue Content module:

  1. The Issue Content Module’s target is a web panel, but not one you describe in the Web Panels section. Therefore, it doesn’t have any of the Web Panel’s attributes, like layout and weight. Is that normal?
  2. For compatibility with the legacy issue view, we must keep a real Web Panel with the “atl.jira.view.issue.left.context” location. But then that leads to two web panels if the user adds the Content Module by clicking on the button. How can we avoid that?
  3. In the Issue Content Module documentation, there’s an example for the ISSUE_QUICK_ADD_CLICKED event. But from where can we listen to that event? Is the target web panel of the Issue Content Module always loaded when the new issue view is displayed, and just hidden away, so is that where we can put JavaScript code that will listen to the event?
  4. Is the Issue Content Module’s target web panel reloaded when the issue is modified? Transitioned? And when the API.jira.refreshIssuePage() is called? Or is there at least an event that’s triggered in these cases?
#17

Hi @tpechacek, any update on my questions above?
Thanks,
David

#18

@david2 I am sorry for the delay here, myself or someone else on my team will be more responsive on these threads moving forward!

To your questions

Question #1

  • That is correct, they are not the same. We will look at updating the documentation to make this less confusing. It does not have a height/width or weight value. The iFrame will be whatever height you specify using the AP.resize or AP.sizeToParent (see https://developer.atlassian.com/cloud/jira/platform/jsapi/ap/). The width is just 100% and should be built to be responsive at any size. Please note the maximum height limit is 1500px. Lastly, the weight property is no longer applied. It is based on when the user installs the app and in the future we will look at showing the content modules based on when the user adds content/displays the iFrame below to account for the weight.
  • The “target” attribute for the Issue Content module only has the option for ‘web_panel’ today which is just to denote an iFrame will be loaded below. It is not the same as the seperate Web Panel module. At some point we will want to look at giving other options when you click on the quick-add icon, like showing a modal for example, but that is not coming soon.
  • This pattern also exists on the Issue Glance module where you specify the target with the only acceptable value today being ‘web_panel’. We are looking in the near future for the Issue Glance module to display as a modal as an option (like the development panel --> commits detail can open in a modal as an example).

Question #2

  • Yes, you must keep the original Web Panel with location = "atl.jira.view.issue.left.context” for support of your Connect app on the old issue view. Once you add the new Issue Content module to your descriptor, we will handle when to show either one. If you are on the new issue view, we only look at Issue Content modules and render those. The old issue view only looks at Web Panel with location = “atl.jira.view.issue.left.context”.
  • Once a user clicks the button, it should not be showing the existing Web Panel with location = "atl.jira.view.issue.left.context”
if it is, that is a bug and we should fix ASAP. I would love to get a few screenshots / video and discuss more if this is the case.

Question #3

  • So, we are just broadcasting that event as a custom event (See https://developer.atlassian.com/cloud/jira/platform/jsapi/events/). So you can use AP.events.on(‘ISSUE_QUICK_ADD_CLICKED’) to listen to that and do something (ideally open a modal and let users add content).
  • The Issue Content module does not load on every issue detail view load, unless it is visible then it does. However, whenever a user clicks the quick-add icon to add that iFrame below, we load your iFrame below and broadcast out that event, which you will be able to receive (it comes over after the iFrame is loaded and therefore you can listen via the ACJS bridge).

Question #4

  • Yes, it is reloaded (it’s all react now, so will re-render specific areas that need to be re-rendered) on issue modified, transitioned, any edits, etc. Also, when you call refreshIssuePage() it will re-render the issue view, but only re-render the any individual components, like your content or glance so it feels fast. it is no longer a full page reload which is really nice. Also, refreshIssuePage() will reload content modules as well.

I hope this helps. Please let me know if you have any further questions.

New Issue View max-height causing multiple scroll bars on long iframes
#19

Thanks @tpechacek for your very thorough reply.
Unfortunately, this does not solve our problem. Would you have any pointers for us?

Here’s what we do on the legacy issue view:

  • we have a small JavaScript code that we embed in an otherwise empty web panel html page
  • the web panel is in the "atl.jira.view.issue.left.context” location
  • the web panel doesn’t have any title, so it is essentially invisible (even though it does create a small blank bar about 20px high)
  • when loaded, the JavaScript code will poll the server during about 12 seconds for a particular issue property, and if present, will trigger a browser action (such as calling AP.jira.refreshIssuePage() to refresh the whole issue view).
  • when the issue is transitioned, our web panel is automatically reloaded, so the polling resumes for another 12 seconds

On the new issue view, we have looked at multiple options:

  1. Keeping the existing atl.jira.view.issue.left.context web panel. This doesn’t work for two reasons:
    1.1. the web panel is automatically preloaded only on “old” issues. On new issues, the user needs to click on the quick add button, which obviously doesn’t work for us
    1.2. even when displayed, the web panel isn’t reloaded when the issue is transitioned (unless it changed recently - we didn’t retest)
  2. Using an Issue Glance. Apparently, the web page behind the glance is loaded as soon as the new issue view is loaded, so our JavaScript can start immediately. However, it presents two problems:
    1.1. the Issue Glance is visible, but we have no information to display
    1.2. our atl.jira.view.issue.left.context web panel is also loaded in the new issue view (at least for old issues), which leads to double polling and actions. Is there a way to disable our web panel just on the new issue view?
  3. Using an issue content module. If I understand correctly, when at least one such module is found in the descriptor, it automatically disables all existing atl.jira.view.issue.left.context modules in the new issue view. Is that true? It feels odd if you had more than one web panel. 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. However, it still doesn’t work for us because we need our JavaScript (and therefore our web panel html) to be loaded on all issues, without the user having to click on the quick add button. Essentially, we need https://ecosystem.atlassian.net/browse/ACJIRA-1600

Any suggestion?

Thanks in advance,
David

#20

@tpechacek any update?
Thanks
David