Hide unused add ons

[Dennis_H]

Looking at our issue screens every screen shows the various 3rd party add ons that we subscribe to. Some of the projects don't need to see various 3rd party options. Is there a way to hide add ons from various issue screens?

[Nic Brough -Adaptavist-]

No, because they might be used.

[Dennis_H]

That's a short sighted approach. We have a quoting add on that we use in our sales project. I can guarantee that nobody who is working our dev projects will ever need to use the quoting add on. There should be an ability to hide any item when creating an issue screen.

[Nic Brough -Adaptavist-]

So how is it "short sighted" to let people use functions they may need or benefit from?

I don't see how it's worth spending time coding for, and then having admins have to set up flags for "hide", when "if you don't need it, don't click it" covers the case.

[Dennis_H]

Flexibility in configuration. Why do I need teams to see functionality they will never use. I'd rather use the screen real estate for things they use.

[Nic Brough -Adaptavist-]

Or you could let them see stuff they might want to use and not have to think about having to remove it because (you may well be guessing) they don't?

[Nic Brough -Adaptavist-]

Don't get me wrong, I don't think there's anything wrong with people, or maybe the project lead being able to say "I don't want to see this", but you've then got a mass of code to write to enable that, and on top of it you also need to think about "someone else in this project has used it, so I'm now missing information".  It certainly shouldn't be up to an admin to be worrying about it, because they would then need to be talking to every project or even user to establish what the flags should be set to.

It's a lot less work to simply say "if you don't use it, don't click on it"

[Dennis_H]

Yes, but there is so much that is configurable, it's like stopping 10 ft before the finish line. I can guarantee 100% that my dev team will never need to do a quote and our sales people don't ever use the work timers. In the configuration screens I should be able to slide any thing over to hidden (with the exception of the required fields for the issue to work).

It's not available and with the backlog of things the Jira team needs to work on this will probably never be considered, but it would be a nice feature. Let us design our screens exactly how we want so they are the most efficient for the users.

[Gandalf]

I'm confronted with the same need. I've different teams from different departments with different needs. Some addons are useful for specific teams and not for others! As we're using various addons, it clutters the view on projects where they're not needed. 

Not all teams/ team members have the same affinity with tools and features.

Being able to manage addons visibility by project would help to maintain teams focused on their tasks and would greatly simplify the overall layout.

[Nic Brough -Adaptavist-]

Yes, you could code for that, but it makes the admins jobs harder and your code will need to deal with "someone else has used this", "why does my thing look different to my colleague's" and "why am I missing information"

[Gandalf]

There're many types of addons. Some are more invasive and some are more specialized than others.

Admins working with multiple teams have to try to provide the appropriated tools for each team without impacting other teams (different needs).

I understand there's a challenge for existing projects especially if the addons is already used for some time. But I assume if the addons is being used, you don't want to hide it unless you want to remove it. But this is a team's/admin's decision.

I don't think it's needed to deactivate an addon by project. Hiding the addon for a specific project would be enough and be very useful for starting teams or new projects within your organization in order to apply the KISS principle (Keep It Simple and Stupid).

[Nic Brough -Adaptavist-]

Yep, there are many that don't inject things into the display because they don't need to, they're worked differently.

App by project is a non-starter though, or at least another devilishly complex layer of code.  What happens when a board includes issues from different projects?  How do you answer the question "why does this card work differently to that one?  Why is my team working differently on different cards?"

[Wilfried Sibla]

I'm faced with the same issue, and it's seriously bothering me. Some teams are experimenting with new and different AddOns, regardless if on the same or other projects and/or project types.

On each and every issue I open, I have to scroll down to find and see the comments. This significantly reduces the efficiency of working with Jira. Even more for those who uses Jira as a more prominent tool than I do...

Why not providing there a switch like "hide permanently" and store this in kind of cookie or wherever personal settings are stored. Then, the corresponding switch of each and every AddOn section could evaluate that... should not require a redesign of jira :-)

[Nic Brough -Adaptavist-]

It's the same as the discussions we've already had above.

Before asking for vendors to build a huge pile of code to enable this, and train your admins to be able to handle all the options, and all the questions about "it works differently for me" and "I can't see something my colleague can", have a think about the real value of that over "if you don't want it, don't click it"

[Nicholas Paquette]

Nic, buddy... its not for the admins that we want to be able to hide some tools for some people. its for the people doing their job. can you even acknowledge that maybe me, creating a service call for a plumber to fix a toilet, do not need 20 software development tools cluttering my workspace? 

if you truly believe in "if you dont need it dont click it" lets just have all the buttons. All the buttons all the time on every device ever and just search through a trillion user interface elements till you find what youre looking for. LOL

[Dennis_H]

At this point it probably won't happen considering Atlassian has other more important issues they've not done anything with for years.....

Having said that, it makes perfect sense to be able to hide add ons at a project level. As I've mentioned previously my dev team using their dev project will never and I mean NEVER need to interact with the quoting add on we have for sales projects. All it does it take up screen real estate that could be used for something relevant to the dev team. Don't make it per user. Anybody going into sales project issues would see A,B and C add ons and anybody going into the dev project would see D,E and F add ons. WHY.....would a dev project user ever need to see a quoting add on? They wouldn't. They won't be creating quotes or ever looking at them and if for some reason a dev needs to see a quote it can be added to the issue as a PDF attachment.