Hi david.molloy,

This should be because the filter is not owned by you. You need to change the owner before you can update it. Refer to Managing shared filters for more info

We have a Board Filter owned by an Admin, set as "Shared with logged-in users". However, as an Admin, I do not have the option of updating it. "You can save a copy of this filter but you cannot modify the original."

Hi guys,

It helps you manage users subscriptions - https://marketplace.atlassian.com/plugins/ru.teamlead.jira.plugins.subscriptions-for-jira/server/overview.

@Dave (as mortals are not allowed to use username auto-completion). the new ticket is supposed to fix it. Still, I was arguing that creating a new ticket just in order to keep an old bug closed as resolved is not necessarily the best idea. If someone checks the history of the bug they will find that the original request was covering both private and shared filters, is just the fix that was incomplete. Why I see it as wrong: simply because keeping it as fixed suggests that those ~420 votes were solved, also suggesting that there are only ~40 votes for the part that was not fixed.

The bare truth is the JIRA product management ignored the administration of JIRA instance for too long, probably because this was not a very marketable feature. Instead we how have an product marketed enterprise ready that is very hard to manage and where is something normal to have to fix things directly in the database.

Should I give few additional examples?

• when you click on a user in the admin users, you get an URL with an ATL token, not a permalink. We should never see the ATL token in the URL in the first place.
• when you search a user by name, the search string is sent by POST instead of GET so the URL does not contain the query
• user searcher has 3 fields: username, fullname and email address but if you copy the email address you cannot paste it to perform a search because it would look like: "aaa bbb <aaa.bbb@company.com>" which Jira does not know how to parse (same applies for the user picker and multi-user picker).
• the use-case where people do leave, or being replaced is totally ignored and we all know that IT industry has a turnover of ~15% per year, so any jira instance over 100 users will be hit hard.
• and I would end-up with the introduction of clustered versions which are supposed to bring enterprise reliability and HA to a product that was not designed to scale. In the end the number of things fixed by the clustered version is very small, you are not still able to upgrade one node while the other one is us, which would #1 requirement for a HA solution. It's hilarious how often we do see the maintenance screens on the Atlassian sites and I would be quite reluctant on going for any up-sell for TAM deal when I keep seeing those downtimes.

@Dave - the only thing not covered is the small matter of 380 379 missing votes.

Hi intersol, is there anything that you are requesting that is not covered by JRA-41269?

Dave, I bet that 50% of the votes here not addressed by the current partial fix, the title was more than clear. We have hundreds of broken filters which we cannot address.

any updates?

+1 for Citrix Devops comment.

after a while the owner leaves the company and you end-up with a filter that cannot be edited by anyone, sometimes even becoming broken.

I think that the mistake on this ticket is of Atlassian failing to see the lifecycle of these filters and to provide a meaningful way to deal with them.

If Atlassian would just allow any filters to be edited or removed by a jira-administrators this problem would be solved for good.

Does this leave us to manipulate database itself for removing filters? Please, reopen this issue and allow jira-admins to remove obsolete filters.

If we are following the description and people comments, we do realise that is not really related to shared filters.

The text from description "We have a lot of users who share filters" – does not necessarily mean sharing using the JIRA filter sharing feature: people can share filters with others by using them in Agile boards, Dashboards, Confluence web pages and other places,... after a while the owner leaves the company and you end-up with a filter that cannot be edited by anyone, sometimes even becoming broken.

I think that the mistake on this ticket is of Atlassian failing to see the lifecycle of these filters and to provide a meaningful way to deal with them.

If Atlassian would just allow any filters to be edited or removed by a jira-administrators this problem would be solved for good.

Thanks for the elaborations skarp@lattice-engines.com et al.

we are currently working on some big improvements to the admin experience and also some changes to the filters. Although we are not fundamentally changing the way this will work, we believe we are going to improve the overall experience for users. As it happens with a big product like JIRA and a massive user base, some issues take priority over others. Right now we do not have plans to implement support for admins to change private filters, but believe that for your overall JIRA experience - from setup over onboarding users to building successful products - the changes we are working on will deliver a lot more value.

That is to say, keep giving us feedback, use cases and explanations of how it affects your business for everything you think is wrong with JIRA - we do read it and think about customer feedback all the time while building and improving products

Best regards

Ben

It doesn't sound like your listening to the original complaint and thinking about JIRA as an application used by teams and not just individuals. We have teams that share filters and use them on a daily basis. If the person who created the original shared filter leaves the company or is not available then there is no way to change the filter's settings.

Take this as an example:
My boss creates a filter for our support group called Open Support tickets, shared with the group Support. This filter covers the project Support and the support team uses this filter to manage their queue (project=SUPPORT AND resolution = Unresolved ORDER BY updatedDate DESC). Later my boss leaves the company and I'm left in charge of the team. We now have a new project called we need to cover called CustomerSupport so I need to change the filter to project in (SUPPORT,CustomerSupport) AND resolution = Unresolved ORDER BY updatedDate DESC to cover this new use case.

There is no way to do this as my boss left the company and created the original filter and I cannot edit a shared filter. I do not want to have to change my team's workflow and use a filter that I now need to setup, I want to use the existing one and just change the JQL.

I don't understand why there is so much push back on a simple feature that should be included with the product. JIRA does not take into account employees working as a team. I don't want to clutter up the filters by having to add new filters all the time. This could lead to confusion by users selecting the wrong filter.

Hi guys,

I personally think that this Suggestion has been implemented properly as per the original description, which is about SHARED filters.

According to recent feedback, it seems that admin control over private filters is also needed, so/but it should be treated as a different Suggestion.

cc. ohernandez@atlassian.com,

There're suggestions that allowing admin to control private filters is reasonable, as an admin can indeed own a shared filter and make it private to himself. This is to say that admin should be able to manage all private filters. However, as this has something to do with user's privacy, I'm not sure if we're going to implement it. It would be great if you can share your opinion here.

There're some related Suggestions, but not totally about the ability to manage private filters explicitly:

• Administrators should be able to delete ALL filters
• As an Administrator I would like to manage private filter subscriptions
• Disable all user filter subscriptions when user account is de-activated.

Cheers.

This is important for Jira administrator to able to manage user private filter from the GUI.

I faced the issue whereby filter subscriptions are being sent out from our Jira Test instance. and we as administrator cant get into the filter to disable the subscription, edit the filter, etc

I don't want to delete a filter owned by another user, I want to be able to change it and manage it. This is not the same as JRA-6561. This should be re-opened, as a lot of appear to want this feature and it still has not been implemented correctly.

Clearly there is something that is not working well here, obviously if so many people are not able to figure out how to manage these, it means that the feature was not implemented properly.

Admins and filter-owners should be able to change filter ownership from the filter screen.

Please note that the duplicate issue JRA-6561 refers to the release notes of JIRA 4.4.1, where you can find an explanation of the implemented feature. The issue is fixed. However, you need to administer filters and dashboards from the global administration:

• (SERVER)/secure/admin/filters/ViewSharedFilters.jspa
• (SERVER)/secure/admin/dashboards/ViewSharedDashboards.jspa

Provided that you have admin rights, you can change ownership of or delete both filters and dashboards created by third users. I agree however, that the documentation and communication of this feature was rather unfortunate.

I verified this feature with JIRA 6.2.

This is not a duplicate. Administrators should be able to manage filters owned by other users that are unshared. Definitely not fixed.

Closing this bug as fixed is just are really bad joke from Atlassian.

anyway it is NOT resolved fixed, but rather a closed duplicate, isn't it?

Hi intersol angelos.devletoglou,

The feature request for editing a shared filter is at JRA-17783. Please feel free to add your comments/votes on that issue.

Regards,

Oswaldo Hernández.
JIRA Bugmaster.
[Atlassian].

+1 I agree that this needs to be re-opened - it's pretty lame that filters have a hard reference to a project name that could change. And when it changes we need to be able to edit someone else's filter, if we are JIRA admins.

Can we reopen this? Clearly and admin cannot edit a filter, changing ownership is not easy or desired.

I agree, this is not fixed. Given we are using Jira to fulfill audit requirements it looks fishy to take ownership of things, make changes, and then give ownership back.

What we have now is better than nothing, but does not fulfill the ticket here as written.

Maybe this ticket should be split in two, taking all the history, votes, and watchers along. This way Atlassian can get credit for completing part of the request and the rest of us can continue to track progress on the remainder of the request.

Thanks

Oh, wait. I thought Mike was an Atlassian person. Mike, sorry, my bad. I got kinda grumpy when I read your comment and thought you were from Atlassian saying this was fixed. I'm a dork.

Mike - A work-around is NOT a fix. "Assign to self, edit, assign back" is as much of a pain in the ass for shared filters as the current "log out, log in to shared account, edit filters, log out, log back in to my account" workflow we are forced into today.

This ticket should be re-opened. Only a small part of the request that "Administrators can manage filters" has been done.

Valentijn et al: As Jeff noted about the HP-developed plugin, if an admin can change the filter owner to themselves, they can edit the filter and then change ownership back. It's a work-around, but it should work, no?

Next to that the reporter of this issue also specified the ability to "change" filters

The best one to vote for is the linked issue JRA-17783.

Is there another JIRA reported for

Next to that the reporter of this issue also specified the ability to "change" filters, so purists (like me) would say this issue is only partly resolved.

as this is something that we would benefit from in terms of project reporting and co-ordination.

In 4.4.1 an administrator can change the owner of any filters, or delete any filter.

The administrator however can still not edit any filter.

This means that JRA-14504 (which is resolved as duplicate of this issue) is incorrectly marked as resolved now.
Next to that the reporter of this issue also specified the ability to "change" filters, so purists (like me) would say this issue is only partly resolved.

Thanks Atlassian for bringing this important feature in 4.4

To all those interested in the administration of filters you can now do this in JIRA!

Read all about it at our 4.4.1 release notes.

The Jira SU Plugin doesn´t work with users in Active Directory and on crowd. The fact that you can´t undo user mistakes in the create filter option is terrible. Guys lets fix this. This is an issue. A real one.

The HP/Palm Jira Search Plugin has a Change Owner feature that allows an administrator to change the owner of any filter or dashboard. And, for example, by changing ownership to themself, they can then delete or modify a filter and then change the owner back to the original owner.

,,, bump

To be fair, the JIRA SU Plugin works fine for allowing administrators to delete or modify all user's filters or dashboards. Transferring filters and dashboards to a new user when an employee leaves the company remains a painful unsolved problem, however.

Unbeleivable that this hasn't been resolved even with tickets dating back to 5 years ago!!

I guess I'll just have to disable the filter/dashboard sharing permission for EVERYBODY, ridiculous. I wish I'd known about this before we invested in JIRA, it's just not something I thought of looking into when we evaluated the product, I assumed it was a given that admins would be able to delete/modify shared filters :'(

Another alternative is to create a test instance and then change the user's password to log in:

update userbase set password_hash='uQieO/1CGMUIXXftw3ynrsaYLShI+GTcPS4LdUGWbIusFvHPfUzD7CZvms6yMMvA8I7FViHVEqr6Mj4pCLKAFQ==' where username='XXXX';

That will make the password 'sphere'. It requires a restart.

FYI, I created JRA-21829 regarding the problem uncovered in the previous comment.

Hi, my two cents:

The setup: My user married and changed her last name. We implement that as a new user login, but the old login's email was updated before being hobbled (password changed - removal from most groups).

She was still getting a subscription email from her old login. So I went in and did the admin two-step (change the old user password to a know value, go in as them and remove subscriptions, etc) Found two subscriptions and deleted them. re-hobbled the user.

Hmm. It didn't work.

I hadn't noticed the name of the filters I found, did NOT include the filter she was getting every monday morning. Turns out that over time, her access to various projects had changed. After giving her old user developer access to all projects, I saw the one filter subscription that was the problem and could then delete it.

So that's just an FYI for those people using the strategy of "login as that user" to administer filters/subscriptions - you might not be seeing them all. If over time, the dev has changed from project to project, they will have 'hidden' filter subscriptions for projects they don't have 'current' access for.

But now this brings up a new question - why was she getting the email, if even as logged in as her, I couldn't see the filter anymore? This seems like a security bug. (using: 3.12.1-#299)

are we getting this feature in JIRA 4.x version

For people impatient for a solution to this the Jira SU plugin by Andy Brook is a good workaround. Link:

https://plugins.atlassian.com/plugin/details/5043

Find all users with filter subscriptions

If you want to find out all filters users subscribed to and their schedules, use the following (Oracle) queries

select t1.filter_i_d, t1.username, t2.trigger_name, t3.cronexperssion
from filtersubscription t1, qrtz_triggers t2, qrtz_cron_triggers t3
where t2.trigger_name = CONCAT('SUBSCRIPTION_',t1.id)
and t2.id = t3.trigger_id
order by t1.username

Sample results in cronexpression column and their meanings:
0 0/15 * ? * * <- every 15 mins
0 0 */1 ? * * <- every hour
0 0/30 * ? * 2,3,4,5,6 <- Each Monday, Tuesday, Wednesday, Thursday and Friday every 30 minutes
0 0 8-15/3 ? * * <- Daily every 3 hours from 8:00 am to 4:00 pm

This is such a good idea. It has been around too long without movement. Is there not some way to get it prioritized for action.

Perhaps somebody from Atlassian could comment on where this fits into the roadmap. This would help dispel the feeling that Atlassian don't see this as a significant issue and have no plans to fix it.

And still 4 years is not the longest wait for a fix They probably have a reason and plan why things are not done.

//Michael

But there are a bunch of workarounds in the comments above.

If it were most other companies, you wouldn't know it was 4 years because the bug database wouldn't be public. And if it was public they wouldn't let you and I write snarky comments in it!

What an amazing accomplishment.

4 Years, still haven't fix this. Truly amazing company

Hello,

We encounter the same problem, it's a real limitation of the tool.
This prevents us from deploying JIRA on our various worldwide production sites.

It is very important for us to resovle this issue as soon as possible.

Thanks,

Hi Stafford Vaughan, thanks for the write up.

What I did back in May 09 was to avoid the delete at the database level (thus avoiding integrity issues); instead I change the ownership of the filters to myself, then you can both change or remove the filters via the JIRA gui (Manage Filters).

To do this I edited the SEARCHREQUEST record and changed both AUTHORNAME and USERNAME to my own user id

This is just a workaround, I agree it should be completely handled via the JIRA gui

Note:
My FILTERSUBSCRIPTION table is empty
I am using Oracle

Hi,

To do this at the database level is not a good solution, because you must keep database integrity by yourself.
If this fonctionnality is done by JIRA, it will be validate to keep database integrity.
And it will be usable by someone without knowledge in SQL...

So, I think that doing this at database level is a temporary solution (thanks for the how-to guide), but it's not THE solution.
Please vote it

Best Regards
Laurent

I've created a how-to guide at http://www.customware.net/repository/x/B4DDAw with some instructions to do this at the database level.

Raymond,

I'm not sure what happened to Jamie's site looks like it's been down for a while, but there is another plugin, JIRA SU Plugin that looks like it does the same thing. It's listed on our plugin exchange at https://plugins.atlassian.com/plugin/details/5043.
I haven't tried this particular version of it, but I suspect it's probably worth a look as well.

Regards,

Adam Saint-Prix
Atlassian Support - JIRA

When implementing this feature it might be a good idea to consider the management of shared dashboards as well.

I'm interested in trying out the above mentioned plugin, but I cannot access the website mentioned that contains the "impersonate another user" plugin. Is there another location where this can be downloaded?

Jamie Echlin's impersonate another user plug-in seems to help address this issue by allowing jira-administrators or jira-system-administrators (not sure of the group) to login to JIRA as another user. If you are not keen on editing the user in the database directly this plug-in is probably worth a look.

While I don't know specifically what versions this works for, nor can I say whether it will work in all situations or for all customers, I can say that I have seen it work very well for many of our customers on 3.13+.

In those cases where one might be reluctant to edit the database directly (as you should be) this could be a good alternative. I'm posting this here as we do get this question from time to time in Support and because this issue has quite a lot of activity. I'm hoping this will be helpful to some of you now, or for our customers that may run into this problem in the future.

Best,

Adam Saint-Prix
Atlassian Support - JIRA

Would be a very helpful feature.