JIRA plugin: notification banner (pop-up)

[Viacheslav KIM]

It seems like we need to use this code in our javascript to show notification to user: JIRA.Messages.showSuccessMsg("TA DA!")

The question is: where should we put this javascript code and how we can call it?

Basically we want this banner to appear on ISSUE_UPDATED event. What should be the code in our EventListener to call this banner to appear?

[Nic Brough -Adaptavist-]

No.  Don't ever try to do this.

If I was trying to use a JIRA that popped up a banner on every issue_updated event, I would attempt to kill my JIRA administrator for doing it.  I don't want a constant stream of these, it's an unmitigated disaster in terms of usability.  

Fortunately, it's also quite hard - listeners don't have hooks into the interface because they don't have anything to do with the UI, so they can't execute javascript.  You'd need to go deeper into the guts of JIRA to make it able to do that.  I think the closest you can get is to have something that changes the system banner, which would appear on the next refresh or page display for every user (and as it would probably have the results of many changes, it will render JIRA unusable)

Please, stick messages into Hipchat or something.  Don't try this in JIRA, you'll break your users.

[adam-roth]

This is a silly answer.  The OP didn't ask for a critique of his use-case, he asked a very simple and straightforward question, which is "where does the JavaScript code go".  And the answer to that is that the JavaScript code goes inside of any Velocity Template or JSP file that you can deploy into the JIRA UI.  

If the goal is to trigger some notifications whenever changes are made to an issue, my guess is that you could use something like this tutorial to add a (preferably invisible) component to the issue-details page, and then inside of your Velocity Template implement the necessary JavaScript code to 1) poll for updates to the relevant issue, and 2) display notification messages on the page as appropriate/desired.  

Whether or not it's wise to do such a thing isn't something the OP asked for an opinion on.

[Nic Brough -Adaptavist-]

It's not a silly answer.  Would you answer "how do I shoot myself in the foot?" without suggesting that the questioner probably does not want to do it?

Yes, your code should go into an add-on, and the rest of your answer is technically correct.  Here's how you load the gun and pull the trigger.

But it's still a very bad thing to do, and you don't offer the number to call for the ambulance later.

We find in these forums patterns of bad practice - people asking questions on "how do we do <technical thing>" without the actual reason for doing it.  When they get simple "here's how" answers, we find them coming back quite quickly with "I broke something".  I've even been engaged to undo the mess made by people who have not been questioned about their (well intentioned) bad ideas here on Answers.  Hence, I try to prevent people making this sort of mistake.

[Viacheslav KIM]

screenshot.png

Thank you for your answer, Nic,

I just want to show a user some pop-up notification as you see on the screenshot. And I want to call it as post-back event after some issue was updated. Idea is to show it only when some conditions are satisfied, not all the time when issue_updated event shoots. 

And the original questions is: https://answers.atlassian.com/questions/17434488

So we are close to finish some not very good implementation for managing size limits for attachments based on user's role in the project. And this implementation requires sending notifications to user on-fly.

[Nic Brough -Adaptavist-]

As I already said, you can't do it with a listener, they don't have access to the UI. The popup you are seeing is called from the create-issue interface, which does have access to the UI. You'd need to hack the core of JIRA to implement a "annoy the user" function. (Please don't. For the sake of your users, stick with email or hipchat notifications)

[Nic Brough -Adaptavist-]

Oh, and a listener is too late to deal with that, it's totally the wrong approach. By the time your listener picks up "file is too big", the user will have uploaded it and it will be on the system. That means your listener will then need to delete it, despite the fact your user now thinks it has been successfully attached, and I'm pretty sure you'll have them screaming for deleting what they've successfully uploaded. Don't do this either, it's really bad.