like FFS over 1000 votes get your head out of your rears guys. 

After many years, this is still an open issue.  This feature is probably one of the big ones that most people will need to be able to do their jobs efficiently.  I hope it will get worked soon.

Having the ability to assign a JIRA/Crowd group of users as an owner of kanban board/dashboard would allow us to have a group of expert business level users to maintain boards and dashboards without the need of an admin. Let's help our users become owners.

Can we get this feature please.

We have the same problem in the company. At the moment when an owner of a board filter or dashboard is not available, the entire team is stuck. 

We need this too!

Here's the link you asked for, to save clicking: https://marketplace.atlassian.com/plugins/com.qotilabs.jira.shared-ownership-for-dashboards-and-filters

@kelly

I do not like to post links but you can easily find them on the "find new add ons"

Shared Ownership for Dashboards/Filters by Qotilabs

Can you provide the link to the plug in?

Better late than never...

Currently we are using a paid add on that adds a button to take ownership so they can make changes when needed which happens frequently because we added an area for notes, kind of like a group post it area... 

When working in a team, information and reports are shared. The current configuration when filters and dashboards can only be edited by one person, makes that person become a constraint on the entire team. It would make much more sense to allow a group of people to edit filters and dashboard, making the work more collaborative.

One of my issues as an administrator is that I am unable to determine easily which filters are used in which gadgets on which dashboards. With over 100 dashboards, as an administrator I have no way to know which filters I can delete when cleaning up the system. I have only found that I have to visit each dashboard that is no longer used, write down the names of the filters used on that dashboard, then return to the filters management area to delete those filters, and hope that they are not used  by someone else or on another dashboard. This is way too time consuming, resulting in filters being retained that may no longer be needed. In the "manage filters" area, I need to be able to see which gadgets and dashboards are using a particular filter. Has anyone else run into this problem? How have you handled it? Am I missing something?

Thanks, that will be a step forward towards using features such as dashboards (largely populated through usage of filters) as a team and not as an individual (as it should be when developing in an agile manner).

Hi everyone,

Thanks for participating in this issue, either by voting, commenting or watching. We value your feedback in all forms and suggestions in Jira.atlassian.com is no different. I know it's been a while since we last commented on this suggestion and we are sorry to have kept you so long without a clear answer.

Your feedback has really helped us better understand the varied challenges you face without an ability to edit shared filters or dashboards. Despite our lack of communication, this problem has actually been an area that we continue to explore. As one of the results of the exploration, we've decided to prioritise this challenge on our roadmap.

Our next steps are to explore options for solving problems associated, validate them with you, our customers, and prioritize the most impactful changes for development.

Thank you again for all your feedback on this suggestion and we look forward to providing you with more updates as we work to improve filters and dashboards configurability.

Thanks,
Jakub Lazinski
Product Manager, Jira Server

As a user, I have been frustrated by the filter management features as well.

I believe there are a number of characteristics of Filters that make things difficult that will need to be addressed if such a change is implemented. I mean that if you approach sharing 'management' of filters, you will need to consider all aspects of the 'filter infrastructure'. Most of these aspects are endemic to the style of coding and UI 'theory' utilized throughout Jira and the Atlassian products.

Jira segregates the complete set of functionality for managing a 'domain of activity' into forms that funnel the user into UI contexts where the available functions only enable them to perform only the operations allowed by their permissions. This eliminates overall infrastructure development concerns such as granular permission-gated user controls and visibility management of controls and features by permission.

The filter permissions domain reveals this as the four levels of filters that show up under 'Manage Filters' on the Issues Menu: Favorite, My, Popular, and Search. The management capabilities (operations) provided in each of these sub-forms are distinctly different. Only 'My' allows editing and deleting. And the 'editing' consist only of assigning 'shared visibility scopes': allowing the filter to be 'shown to' others according to group, all groups, administrators, or projects.

However, changing those visibility settings 'by user' is the real bottleneck. Each user can enable filters under their control to be viewed and applied by other users, but the 'editable options' within Filter Management a limited to this one function: sharing filters. Editing the actual 'filter statement' does not happen within the context provided by Filter Management. Again, this is a design decision that favors the interests of the platform developers interests rather than the users' interests.

When 'editing' filters, you are allowed to place the filter statement on the JQL editing repl in the Search screen. However, the Save, Save As, and Discard options in that repl do not enable a smooth 'edit/update cycle' with the Filter Management. I frequently find conflicts on the JQL repl which prevent me from 'editing' a filter, but require me to delete a filter and then use the repl to re-create one in my desired formulation. And that again is limited by the 'who created it' problem. This single hiccup will play havoc with the plan to solve the 'editable by a single user' problem with a 'simple' solution.

This concern is primarily the result of the primitive behavior of the 'save as' operation. What is missing is an 'overwrite' operation. And that again requires attention to the relationship between the filter permission scopes and the JQL repl operations. Again this is a design decision that favors implementation resources over user resources. 

The primary problem with Jira usability is their heavy-handed decisions to segregate functionality across forms to simplify the maintenance of the feature set. In nearly every operation, a user must visit several far-flung areas of the application, traversing a number of UI paradigms to find switches and configurations, each of which have little contextual relationship with the user's focus on, for example, 'filter management'. 

So to manage a single filter, a user will likely have to visit each of the four filter management scopes to determine (remember) where the editable operations are exposed, attempt to discover whether the filter can be edited by them using the JQL repl, try to imagine how these permissions are logically related, visit the 'applications area' to see which widget on the system dashboard is using which filter, return to view the dashboard to remind themselves of their goal, return to the repl to test the result of the filter, go to their profile to change the semi-global setting to expose all their filters as 'public/shared', la-de-da-de-da...

And then they must return and repeat in a variety of sequences that depend on several consequences of how things were initially established before the users ever discovered the full scope of the infrastructure features they have to deal with. Most of which was certainly done before they understand how each of those features provides only a very strange sub-selection of the entire range of operations necessary to perform any of the functions of the many overlapping features this filter infrastructure touches.

The primary characteristic we should be asking Atlassian for is that they stop this crazy splattering of functionality across the wild terrain of their application and immediately pledge to consolidate all aspects of each of their features into a single, closely related component/module/feature where users can see and manage functionality in a single feature context that makes sense and provides enough flexibility to support a small but sufficient range of workflows and user goals.

They obviously just started developing in several places at once, and have grown their application into a system that communicates between the several infrastructure elements that grew up around each of those starting points. In many ways, this has contributed to the ease of use, but in each of those areas, what is missing is the refinement of the UI that results from exposing those disparate functional areas in organized contexts suitable for logical and reasonable user operations performed in a single 'place and time'.

Among these, my favorite peeve is that sprints are an attribute of a board, and not a first class citizen that can be managed in a fully operational crud manner like every other primary development domain. The board interface is another similarly disjointed and dispersed, context-less experience!

Thanks Greg!

JIRA admins can already change ownership of a filter. Only the owner can edit it though, so as a JIRA admin if you're asked to fix a filter that someone else owns ('cause they're sick/on leave/can't do it themselves) then you have to do an annoying ownership dance of transferring to you and then back again, but at least you can do it.

One of the top google results, should have instructions for you: https://community.atlassian.com/t5/Jira-questions/Unable-to-change-the-owner-of-a-filter/qaq-p/187087

Allowing a group to own a filter would ideal. At the very least, please allow JIRA Administrators to change the owner of a filter and/or edit any filter.

Why should I have to pay $400 and then $200 annually for something that should be part of core Jira? Atlassian already put their prices up by 10% precisely so they could do "more support".

Never, go get a marketplace add on.

There is one I am using called shared ownership by quotilabs

@azad3

Can we have an ETA for this feature? This is a much needed thing. 

+1 to allow shared Dashboard in a group to be available for editing by users within same group.

@Robert @Gianni how is it relevant to talk about that on this ticket?

@Robert, FYI, we are currently workarounding the same issue JRASERVER-3821 by using the [Extended Schemes Plugin |https://marketplace.atlassian.com/plugins/com.develocenter.jira.links-scheme/server/overview.]

I think Atlassian's product are the best in the business, that is why we use them.    This would be a nice fix but there are many more that I would prefer first, such as 

Just my two cents.

What's stopping Atlassian is that they don't care about their customers. They've now put their prices up for the second time in about 2 years, ostensibly so they can afford to put more resources into improving Jira. Which is funny, because when we purchased JIRA 4 years ago initially, there was never any suggestion that we wouldn't be receiving on-going feature improvements as part of our maintenance contract. I can count on 1 hand the number of actual useful feature improvements they've delivered over that time (Agile is a different story - that's been worth its maintenance contract), meanwhile there's been dozens of other 'improvements' that mostly boil down to UI enhancements that confuse my users and 'fix' what isn't broken.

But hey, you don't get to buy $70M dollar mansions in New South Wales without some business savvy, so maybe I just don't understand Atlassian's strategy.

We have also found out that we require this feature. Teams here share dashboards among all members and is quite silly that only one person can edit it, whoever created it initially. We tend to end up with multiples copies of the same dashboards because of the lack of editing capabilities, defeating the purpose of having a "shared" dashboard to start with.

To be honest I don't understand what is the problem here. It should be relatively easy to implement, and the feature has almost a thousand votes, what is stopping Atlassian here? I would appreciate some comment.

Absolutely need this! I created (and shared) a dashboard with a group of people who have it bookmarked/in documentation and now I am the only person who can update it! This is foolish!

I stopped watching this issue still I am getting notifications for this. 

Can someone have a look ?

yea join the club

this was open since 2015

maybe in JIRA 8.0 they will add commonly requested features, until then an add on / gadget solving your problem is the status quo (because it is developed by someone else)

I require this functionality.

the defacto answer to all your problems is to look for a 3rd party addon/plugin

[arewold1111142294] Not as surprised as I am after waiting 8 years for a fix

Frankly surprised that this functionality is missing.

We need this ! Working in a big company with many developers, this is very painful when one guy of the team is sharing a dashboard or a filter and we cannot  modify. So currently, we duplicate a huge amount of these.

Is there already a Suggestion that tracks the ability to pass ownership a dashboard to someone else without being a JIRA admin?
surely I'm not the only one who desperately need this?

only problem is if someone makes that plugin and then they incorp it into a new feature release... 

Would be funny if someone started making JIRA Bug fix / update packs and charge for it as a marketplace add ons

Let see.

1- Spend  money to fix usability issues that do not break the application and which won't make a user quick for another product.

2- Do nothing, wait until someone create a plug-in as a workaround and cash on market place royalties.

As a JIRA administrator for our company, the huge number of administrative issues that make administrating JIRA a burden make me believe Atlassian prefer option 2

+1 (corporation)

Opened 8 years ago, not uncommon

@Atlassian why do you not listen to your users? Why not do even 1 long requested feature every release? Hire someone specifically to do that, then you will burn through them before you know it and keep us happy!

This issue is voted #9 in the list of issues open 5 years or more with more than 500 votes. The top issue is open 13 years and has 2381 votes.

project = JRASERVER AND issuetype = Suggestion AND status != closed AND votes > 500 AND created < StartOfYear(-5) ORDER BY votes

The requested feature is so helpful. Please implement this.

come on Atlassian how hard would this be to fix, i just had somebody leave the company and i have 52 filters to fix and 12 dashboards to update 

Why bother?

Atlassian don't read and don't act on comment on this issue or our problems like this.

They don't care about us

Yeah, Phillippe, the GUI is deficient in this regard. I often think the folks designing it have never imagined an environment where the JIRA admin is not also a SQL admin

If you have SQL access, you can try:

select ID,filtername,authorname,reqcontent from jirauser.searchrequest where authorname = 'joeuser'

--find filter shares for user
USE Jira
SELECT sp.entityid, sp.sharetype, sp.PARAM1, s.filtername, s.authorname
FROM jirauser.searchrequest s LEFT JOIN jirauser.sharepermissions sp ON sp.entityid = s.ID
WHERE sp.entitytype = 'SearchRequest' and s.ID in (select ID from  jirauser.searchrequest where authorname = 'joeuser')--AND sp.sharetype != 'global'
Order by s.authorname

--find filters a user has not shared (ScriptRunner will let me impersonate this user, to share or delete these as needed)
USE Jira
select ID,filtername,authorname,username,groupname,projectid,reqcontent from jirauser.searchrequest
where authorname = 'joeuser'
and ID NOT in (SELECT sp.entityid
FROM jirauser.searchrequest s LEFT JOIN jirauser.sharepermissions sp ON sp.entityid = s.ID
WHERE sp.entitytype = 'SearchRequest')

I concur and share your pain.

I am trying to rename some groups, which require to change the shared with features of the filters and dashboards.

Worse thing is, as an admin, you can't SEARCH for a filter which you're not part of. We have over 1200 filters, and we have to iterate through every single one of them.

Honestly, I feel like Atlassian is more interested in seeing some 3rd parties create a plug-in to circumvent their limitations rather than fix the problem in the first place.  After all, when a user whole issue database is in Jira, it's easier to bait new clients than help the current ones that are already chained.

Daniel, I feel your pain. I'm cleaning up a pretty hefty pile today myself.

One thing that really helps with this is ScriptRunner.

It has a function to change filter ownership in bulk. Truly, it is an administrative Godsend!

Ugh this has been painful with the recent departure of my partner admin who was the owner of 50+ filters. Please consider this one, Atlassian!

Adding my vote to this issue. A big team shouldn't rely on one person to change everything that a team might want changed!

They should replace this crappy access control system they have with one that works decently. One that can handle nested groups properly, where an owner of a filter does not have to be a member of every group he wants to share the filter with, where you can rename groups, where groups can be a owner of objects ... and so on.

Why take a half measure by having a way to see filters owned by a particular person? Atlassian should just do a proper job and fix this issue properly by allowing group ownership.

@Ulrich Hobelmann: Thanks for your feedback. Your proposal is a solution, but for sure not the best one, as the central admins should not be bothered by tasks like this. I strongly hope, that Atlassian will provide a more appropriate solution.

Nothing that hundreds of paying customers care about is considered "high priority" by Atlassian. You can tell this is true by the way they have ignored this, and other requests, for 5+ years.

(in)Actions speak louder than words. Atlassian don't seem to realise this.

1+ years since the last comment from Atlassian. 

In 2017 this needs to be considered a high priority bug, not a feature request.

@Oliver, it's not self-service, but your JIRA admin can go to System->Shared Dashboards and transfer ownership of the dashboard to someone else. Same for filters.

We would like to transfer the responsibility for existing dashboards from a leaving employee to a new one regarding the maintenance. It seems, there is no other possiblity than to copy them, right? This will change the widely known URL for the starting dashboard for all users. This is very annoying regarding the user experience.

Just want to agree with @Kenneth MacArthur here and say that this is yet another issue which shows how JIRA was built for top-down management. Please just fix this.

This functionality became useful when you have a board with multiple projects and more than one PO.
Because sometime the team works in more than one project the POs should be free to add projects and then issues in backlog

It would be great to have this feature natively. The issue has been opened for a while and it's probably hard to predict when/if will be natively offered. I wanted to let you know that at least for the server instances we provide this functionality through our add-on: Shared Ownership for Dashboards/Filters. You can share ownership of dashboards and filters with other users so that more than one person can make updates. Hopefully you'll find it useful  we're looking forward for your feedback.

There are a lot of features you can live without (especially in the formatting department), but this isn't one of them.

Atlassian's raison d'être is supposed to be creating products for teams, so it is utterly broken that you can't share ownership of filter queries at the team level. It creates so many pointless debates and usage anti-patterns - you end up having to either centralise control of all filter queries in, say, a department with one person for consistency and ease of updating lots of JQL at the same time, or you end up with everyone creating their own filter queries and a huge spaghetti mess which becomes more or less impossible to ever clean up.

The fact that Atlassian considers this feature to be optional is certainly instructive.

Update filter & dashboard permissions to allow more than one person (owner) to update.

When Person A creates dept filters & dashboard and then leaves the company, maintenance is limited. Usually what happens is Person B (their replacement) re-creates the same filters & dashboards so they update them moving forward.

Consequently it means more filters and dashboards that are stale and should be deleted but aren't. Enabling a group and/or role (within JIRA) to update the filters & dashboard would be effective.

We typically have a central Admin person creating most of the filters & dashboards but it takes the control away from the client on their reporting.

Voting for this to be fixed in the next release.

...Kelly

Hi JIRA team,

The cooperation in a team do need the owner of shared objects has the ability to share the editing permission to groups/users as in confluence. Surely version control and change logs should be also in place.

Our team require JIRA admin to set up the sharing, currently the walking-around I can think about is giving them the admin role or create a shared user account, both are bad ideas. Anyone have better dirty solutions?

Tiger

Hi Atlassian JRA team, I would make good use of this feature as it is originally requested:

Certain reporting-type filters, used by project management or other groups, may have multiple users managing them. It would be great to have the ability to specify group-ownership of a filter, allowing anyone in the group to edit the filter, so the same filter remains in use, rather than saving as ... and having to notify all consumers of the original filter of the new filter.

Hello Atlassian,

We need this functionality in our JIRA 7.1.4.

Regards

What April said!!!

Even thou this is not critical for the jira system to run it is critical for the management of the system.

And on that note, all the security system in jira is bizarre.
I mean why do I, as a creator/owner of a filter, need to be a member of every group I want to share that filter with? That is one bizarre and uncomfortable thing.
Atlassian probably needs to completely replace all the security structure to fix this. But believe me, that would be one of the best thing they could do to the system.

The problem is that this state of affairs conflicts with the way enterprises expect to manage projects. If Manager A has 10 boards, and is the owner of the 10 related search filters, it is not a simple matter to get these reassigned when Manager A leaves. Teams might change; be split among multiple managers, etc. It is not uncommon for some reorg to go on when such a person departs.

However, I as a Jira admin cannot simply disable the account and worry about this later, because the second I do that, the board disappears from the interface entirely!

This means I have to endlessly explain to new managers and to security auditors why accounts are still showing as active, plus send piles of emails and sit on conference calls trying to get who should be the new owner, all because boards which are used by a group cannot be owned by that group.

That is on top of the endless emails over which saved searches should have ownership reassigned, which can be deleted, which dashboards are really team dashboards, and on and on it goes.

I find it very hard to believe that a large and growing company like Atlassian does not itself find this process painful and bizarre, and I hope that at least for the Agile board case, some improvement can be made. It would go a very long way to making Jira more enterprise-friendly.

Thanks!

Atlassian clearly don't take customer feedback into consideration for their development plans, as much as they claim that they do.

This suggestion was created in 2009 and has about 700 votes and JIRA feels its a good idea (one of the comments by JIRA).  Will this ever be implemented our are we all wasting of time tracking this issue? 

Please We need This feature.

Agree with last comment big pain, need team to manage dashboard not an individual.

This is a huge pain for DEV/Ops teams that are rapidly iterating and managed worldwide. We have multiple PMs in various locations that need to modify management and engineering views into a single dashboard across multiple projects to get to a unified engineering and mgmt view (ie dashboards with PIE charts and details)..

We can't seem to do this so we are really getting slowed down in our delivery.

Please put this on the near term road map. Even a work around with directions would be appreciated.

Thanks
G

Hm, that's a but gullible if you look at Atlassians most voted for long term issues list, the official statement at this issue, the comment history and the resolution status...

this issue was raised long back, so though we would have something by now.

@nidhi-b.sharma (somehow mention doesn't work correctly here... ), what in the world would make you think it could be?

Is it resolved in JIRA version 6.4.13?

+1 - This is a big pain point for us, as we use our dashboards as part of our sprint retrospective. We have to manually update some of the filters that drive the dashboards, and currently, we can only have one person own all those filters/dashboards. This is a big problem when that person is unavailable or forgets to update something. We really want the filters/dashboards to be a Team asset and have anyone on the Team be able to update/improve on them. As it stands now, we have pick a single person as the bottleneck, which is highly undesirable.

Wanted to raise this as an issue as a security concern that an administrator can't utilize the filter API to autocorrect when users accidentally utilize the Global share permission (Everyone). The corrective action through the API would have been.

GET /rest/api/2/filter/:id/permission
DELETE /rest/api/2/filter/:id/permission/:permission_id where type==Global
POST /rest/api/2/filter/:id/permission

However because an administrator or better a limited group containing a service account can't edit the filter the DELETE/POST requests would 400 and the owner would have to correct this or the user or an admin in the cloud version would have chown the filter, change it and chown the filter back to the original owner. Automatic correction of this relies upon this feature and would be necessary when over 500 users are regularly creating and sharing filters.

This may or may not be a security concern depending on what is contained in the filter name. However, if the filter is shared withe everyone, a user can run curl https://site.atlassian.net/rest/api/2/filter/:id and actually get the JQL filter. While this doesn't necessarily contain sensitive information, it may include labels, projects, etc that could contain sensitive information.

Please see Kerrod's message from December regarding the current status of this request. As stated above, please ping him directly if you have any questions.
As i mentioned in Stockholm, this issue and others were being discussed internally, but there had yet to be any commitment to prioritizing this on the roadmap.
More information on how the JIRA team prioritizes requests can be found here.

Pity that we get updates on their roadmap via hearsay instead of official updates.

On the https://riada.se/enterpriseday/ in Stockholm Atlassian representative Neal Riley (https://www.linkedin.com/in/nealriley), Amsterdam office, told the audience that this feature was on it's way. The big issue (problem) is that a lot of the Jira-core has to be changed to handle this.

When you next have a retrospective, one of your impediments can be "Jira doesn't support this feature and Atlassian have no interest in adding it". Your scrum master can then work out what alternative software has this functionality, and your company can leave Jira behind as a promising, but ultimately flawed, implementation of an agile software management tool.

It is hilarious that shared filters even have that name when they can't be shared.

What is the workflow that Atlassian recommends when multiple people need to be able to edit a filter (or when someone leaves a team or organisation)?

In 'agile', which Atlassian is one of the world's most vocal proponents of, the unit of delivery is the team. How is the team supposed to deliver together if they can't all edit the team's technical artefacts?

Would Atlassian also advocate only one person on a team being able to make commits to the team's code in their SCM repository?

We are using dozens of dashboards and need to share the edit mode between team members. What is the target version to implement this feature? We need this urgently too.

We need this functionality in my organization urgently!

This would be very useful for our teams. Hopefully this will be added in future.

Until enough of us cut support, they're not going to "get the memo" that customer retention/satisfaction is as important as customer acquisition. With them being public now, I think we can expect a lot more of this line of thinking from product management, unfortunately. It's along the same lines as never patching something that a plugin vendor is selling, since they cash in on licenses sold through the marketplace.

I think we will have better luck asking Santa Claus, The Easter Bunny and Tooth Fairy to implement this.

I believe that this voting system is a ridiculous aspect to JIRA in the first place especially when its own developers do not take into consideration the amount of votes, watchers and time in status. We spend well over $65,000 in annual support on our Atlassian products, why can't this be done? Sounds like I need to start instructing my users to vote on this issue as well... not that it will help.

For a company that makes a product that is all about promoting transparency the process used to decided what gets onto a road map of future fixes is completely non-transparent. There is no dashboard of issues planned to be fixed, or list of any type letting the community know what to expect. Instead there is just this black hole of vote for the issue and hope it might be addressed some day which becomes a wall rejection to those on the outside.

This lack of transparency makes for a complete alienating customer experience and is the main reason my company decided not to renew its support contact for Jira. While we use and mostly like the product, Atlassian makes it very hard for managers like myself to present a case justifying the value the company would obtain from paying for the support of a product when there is no release road map to show what the money is going towards and requests for changes are just dropped into a bucket to sit.

It would be such a basic program management and customer friendly item to have a Jira dashboard showing the releases planned for the coming year and the list of voted items that will be addressed in each of them. It would probably take a few hours of work to put together something so customer friendly. The only reason Atlassian is lacking a process as transparent as this is either they haven't thought of it (reflecting their lack of customer focus), or they just don't care enough to bother spending the time to setup such a simple and transparent process.

Atlassian likes to believe is has created an open market place to fill in the gaps (they would consider it expand) of their product, but the reality is they are forcing us to spend the money on third party products to address the bugs in their product. Yes, you can debate whether it is a bug or a feature, but let's go with the guideline that if it was a feature Atlassian would have addressed it, since they could have used it as a selling point, so it is a bug, because some developer didn't put it in (mostly likely due to time constrains) and Atlassian has never gone back to address it because they don't consider it as a feature, so from a customer point of view they treat like a bug they don't plan to fix.

Anyway, the lack of transparency creates other missed opportunities for Atlassian, since people like us feel our requests are being ignored, the natural response it so stop submitting requests, which results in less and less ideas being feed into their pipeline. Of course this would assume Atlassian cares about the communities thoughts on how its product could be used, which they fail to show by their lack of community facing dashboards showing anyone outside of Atlassian any kind of transparency as to what is coming.

I would love to give my company's money to Atlassian, but until they provide the basis business support to show what the money will be used for, like a road map and a more transparent process they make it impossible to give it to them. I don't think basic business fundamentals are unreasonable to ask for like I will give you money in exchange for such and such, instead of I will throw money at you in the hopes I might see something I like someday model that Atlassian currently uses.

The strength of Atlassian is it creates a product that creates transparency, which builds better business models, let's hope they learn to use their own product to create customer transparency as well, so they can build a better business as well.

Ok, i put that on my wish list for Santa Claus now, maybe it helps

I think the question for many of us is how to we get things onto Atlassian's roadmap? We want this feature, it has lots of votes. It's important for current customers, and it's going to be important for future customers too. Atlassian has a great reputation, a great team, great visions. We want to see excellent engagement with customer issues being pro-actively modelled here in JAC

@Atlassian: I fully agree with RZO's comment, it's one of the most requested features.
Why should we vote if it has no effect?

You managed to add multiple owners for a dashboard, it's non-sense not to allow the same capability for filters, since dashboards base on a filter.

Kenneth,
You hit the nail on the head!

Atlassian are far more interested in ticking boxes for stuff their software does than in making the functionality usable for costomers who are already locked in.

Julian

Hi Kerrod,

Thanks for the update.

Can you perhaps shed some more light on how you came to this decision?

Is it per chance because you don't see implementation of this feature generating any incremental revenue, and that you assume existing customers will just muddle through?

Kenneth

23rd December 2015
Hi all,
Thanks for participating in this issue, either by voting, commented or just watching. We highly value your feedback in all forms, and through suggestions in jira.atlassian.com is not different. We use this channel often to learn the best we can with how customers use JIRA and how we can continue to improve the experience for as many users as possible.
We have revisited this issue again recently and wanted to reiterate that there are still currently no plans to implement this suggestion, and it is not currently on any JIRA team’s roadmap at this stage.
Please remember that jira.atlassian.com is one of many inputs for the JIRA roadmap. You can learn more about our process here.
I understand that our decision may be disappointing. Please don't hesitate to contact me if you have any questions.
Regards,
Kerrod Williams
Kerrod (dot) Williams (at) atlassian (dot) com
Product Manager, JIRA

Hi Kerrod
Thank you for the update and for sharing your decisions.
However I doubt that you are considering the issues voted in this JRA project at all. Having a look at the top voted (>500 votes) issues, there are 17 of them, only 2 of them have been closed/fixed, the other 15 are still in status open. It is also remarkable that all those top voted issues are older than 5 years. (https://jira.atlassian.com/issues/?jql=project%20%3D%20JRA%20%20AND%20votes%20%3E%20500%20ORDER%20BY%20votes%20DESC)
Regards,
RZO

I just had a problem with a shared dashboard, because the dashboard owner at a certain point was not a member of both groups sharing the dashboard. At least the dashboard owner should always be able to manage the dashboard.

I can simply not believe that this has been open for more than 6 years now...

@Atlassian, please remember your company values and put this back on the table!

There are several hundred votes for this feature. I manage a 10k user system and get asked about this at least 2x a day. Now, with our AT&T merger this is likely to grow exponentially. Having the ability to allow dev teams and WBS groups to edit shared filters and dashboards is a vital to our business process. Not to mention it free's up the time of the admin's to do other more important things that reassigning a filter or dashboard after a person leaves. Which in a company our size, it happens daily.

All Atlassian Marketing people have to do to justify adding this is just dedicate the next major release of Jira to fixing the top 10 outstanding feature requests. All existing customers will thank them for it.

I guess there must be non-trivial engineering effort involved in implementing this (or it would have been done already).

I further guess that Atlassian Product Management don't see a compelling way to market this feature (compared to feature X that they would otherwise develop), which is why it isn't being prioritised - but I challenge them to brainstorm and come up with one. Something around the synergies that will come from multiple-user collaboration perhaps?

The lack of this feature continues to create unnecessary friction in our teams, because someone has to be the 'god' of every filter. It really leaves a bad taste in the mouth every day for anyone who is a power user of JIRA.

Just voted to have this feature prioritized.

In large organizations working worldwide, it's a must to be able to have multiple owners for the same filter.
It can easily happen that someone indirectly breaks a filter by renaming a component, deleting a sub-filter, etc.

Boards now can have mutliple owners, why shouldn't it be the case for filters?

This is great detail and it helps our product owners understand the value of proposed features. Comment activity also helps gauge interest in features.

Thanks for taking the time!

Cheers,
Morgan Knicely
Atlassian Premier Support