I'm not sure you can log in using the ScriptRunner built-in script when the user is inactive. I generally reason that if the filter wasn't worth sharing, then nobody but the inactive user cared about it. If boards and filters were used by other people than the inactive user, then you will be able to change them as Greg said

Ah yes, it is explicitly "Shared filters" that you can access.

If you have script runner, it is possible to log-in as any other user temporarily, so you could log-in as the defunct user, make the filters globally shared, and then via admin you can change ownership to yourself etc.

Scriptrunner however is no longer free, so this workaround may not be an option for you.

Greg - I cannot see how to do this with private filters of inactive users, even as admin.

Admins can change the ownership of filters to themselves and then edit from there.

+1 - We are using LDAP sync, so users who leave the company are made inactive.
I am then not able to switch to their account to share or remove private filters.
Especially frustrating when people who need to step into the departed person's role cannot use the filters/boards.

Just going to +1 on the other comments here –

Yes, I can head to https://CUSTOMER.atlassian.net/secure/admin/ViewUserDefaultSettings.jspa as an admin user and change the default.

This stops the problem from becoming worse (eg. no new public filters will be created accidentally) – but doesn't solve the problem I have (many filters that should not be public are, and there is no way to remove them short of getting the owner of each of the filters to login and delete their filters via https://CUSTOMER.atlassian.net/secure/ManageFilters.jspa)

To step back a bit – what I'd really like is a simple way to prevent non-logged in users from accessing any Jira page – https://CUSTOMER.atlassian.net/secure/admin/ViewUserDefaultSettings.jspa being just one example.

To change all existing filters, I don't know of any bulk interface.

In our instance, I did this:

1. I went to our.jira.net/secure/admin/ViewUserDefaultSettings.jspa and changed the default there to Private
2. I audited the filter shares in SQL to determine which needed to change
3. I have ScriptRunner, so I can use the built-in script to impersonate users as needed to change filter shares (it does have a bulk change for owner)

Without ScriptRunner, I don't think this can be managed in Jira. You'd have to try some sort of SQL hack, which probably isn't a good idea.

Perhaps you can get a trial of ScriptRunner?

Hi, But still it won't solve the problem. As an admin, I want to change the privacy setting of all  filters/dashboard made by different users from public to private. What is the quick way to do this. 

john248, in Jira Cloud admins can change the default for sharing filters and dashboards in User Default Settings screen. Public and private options are available.

This suggestion is for Jira Server and in Server users can set their preferences in their profile and admins can do that per instance in User Default Settings. Admin section can be easily accessed using 'gg' keyboard shortcut.

Katarzyna Derenda
Product manager, Jira Server

Hey Jira super friends,

For reasons I do not understand, at some point, filters defaulted to sharing with the public.

This means I can navigate to https://CUSTOMER.atlassian.net/secure/ManageFilters.jspa and see a list all filters where folks didn't bother changing the default privacy.

This is a bummer, as I'd assume 99.9% of non-open source projects wouldn't want the names of these exposed.

There appears to be no easy way to fix or resolve this outside of using the API... so, as an adminstrator, I tried to do it via this API:

https://docs.atlassian.com/DAC/rest/jira/6.1.html#d2e4277

And then wham:

{"errorMessages":["You may only create, modify or delete filters that you own."],"errors":}

It would be great if ... admins could edit the permissions of these so they wouldn't be exposed.

Thanks

Hi guys

What's the status regarding this 'feature request'. In my eyes this really should have been implemented since long. We really really would appreciate it, if you force this request and please please please get it realized in the next month - may until end of 2018? ..  THX!!

Any date Jira team has set to get it done and push to all the users?

It should also be possible to edit a broken filter, i.e. one that returns a 500 error if you try to edit it even as the owner.

 As long as it's not going to be another 5+ years in the "Under Consideration" state... 

An old request, please proceed. This is needed. It is not a big work to implement this, why not even consider ?

So, no progress on this? I think it is ludicrous to not be able to delete filters for non active users. Stupid beyond words. And no I do not have script runner neither should I need to. And the worst thing .... this is an easy fix. But I assume Atlassian rather have their devs adding new feature so they can get new customers instead of servicing their old customers. 

@adrien, I actually very much agree with you. There seem to be a lot of obvious features missing from Jira in general, and one of my first realizations in the Atlassian world was that this conversation is basically the party line, to the point of being a panacea:

New guy: Can I do ____ in Jira?

Experienced guy: No, but here's a plugin that can...

The community surrounding Atlassian's products is incredible, and the marketplace model is excellent. But Atlassian relies on it far too much to "fill in the gaps".

Thanks, @Aaron. I realized after I hit the comment button that I should have posted in the Cloud Jira, not server. Unfortunately, none of the workarounds listed here: https://confluence.atlassian.com/jirakb/deleting-other-users-private-filters-and-subscriptions-296913389.html work for Cloud.

@Aaron I do agree, but we spent the last three months building tools to cleanup our instance with scriptrunner, every time you are done building one, you find that there is yet another admin feature missing.

changing ownership of a filter works, but then you also need to change the subscription owner etc.. etc..

(I know that particular one is built in script runner samples)

The problem lately is that everytime an admin feature comes up as missing, someone suggests using script runner to patch.

IMO admins are not coders, and while some are very capable, it can also results in huge messes without proper procedures etc.

Bottom line, there are workaround for many missing features, but that is what they are, workarounds.

same for integrity check, Config Manager has a much better one highlighting all components / projects etc... used and not available anymore, but then again this should be part of Jira Core tools. When the common answer from Atlassian is to use Data Center, most of the time the real answer is to have proper cleanup tools

This may have already been mentioned, but it is worth repeating. For those who have ScriptRunner, there is a built-in script that allows an admin to transfer ownership of scripts and dashboards from one user to another (it even allows you to update multiple at once). You do not have to impersonate the owning user to use this script.

I agree this should be part of the core functionality, but the ScriptRunner feature does fill the gap nicely.

Our Jira instance is getting long in the tooth and we now have many filters created by departed employees that need to be culled. Please consider adding this capability.

Hi,

I even add up to this the new data protection rules which will be enforced by the end of May.

Not being able to do this, can have some serious implications on companies and who knows if it won't be pushed back to Atlassian in that regards.

this truly shows the lack of consideration for admins, especially on growing instances.

if you are under SAML single sign on, then neither SU or SR allow you to switch user (which is good security wise anyway, impersonating a user to do actions is bad, period)

Admins should have tools to manage all simple Jira objects, and that includes the brick and mortar that are filters (and additionally subscriptions)

We recently ran into a situation where filter subscriptions were running for users that no longer existed at the company. Because of this it was failing multiple times per hour. It would be great if filter subscriptions automatically stopped for inactive users. However in the spirit of this ticket an option would be a way to identify and remove them without needing to run database queries. This feature would allow the functionality. 

As the System Administrator, I recently encountered a situation where a board administrator changed the filter share for the board and some of the users of the board could no longer see the backlog or the current sprint.  Even as System Admin, I could not see the backlog or current sprint. 

I really think that the System Administrator role should have the permissions to access these types of things so we can correct them when a board administrator makes a change that they shouldn't have.

Thanks for the tips. Some observations:

• I had previously performed a reindex when changing searchrequest.username but found it only worked on Private filters. If the original user shared the filter then the new owner never gets the Edit/Delete options under Manage Filters.
• The extra effort to share the filter is too tedious and risky.
• Deleting filters via sharing is encumbered by dashboard and board linkages. This becomes an incomplete solution.
• Agree the User Switcher is most accommodating; best "free" solution. Note that if users were removed (using Crowd) then this is not a solution. I've always favored disabling over removing accounts given these unexpected issues.
• Script Runner may be the most efficient but it became cost prohibitive when its capability exceeded our utility. If I were managing 1000's of users then this is a no-brainer. My condolences for you large user-base administrators.

I maintain that this request is part of standard User Management for which Atlassian has incompletely provided. All the systems that I've delivered were required to comprehensively remove user-related records when users were removed. The developer should best know object relationships to preserve database integrity. Atlassian ignored CRUD requirements in their haste to add features; the longer this is deferred then the more difficult it is to implement.

I totally agree, Corey.   My company has about a dozen JIRA instances, each with thousands of users so believe me, I understand the pain this issue causes.   My vote and watch on this issue remains, but Atlassian hasn't really shown much interest in fixing any of Jira's longstanding problems for several years now.   As a result, my hopes for fix from Atlassian are rather low.   Regardless, I happy that we at least have this place to document different approaches for the benefit of other admins, even though none of these approaches are truly satisfactory.

These workarounds are fine if you have a small number of users and control over your server environment. In our enterprise, we have seven different JIRA instances with different teams dedicated to application and database maintenance. While this database suggestion may work perfectly in most instances, it is also very risky (hence the disclaimer) to update the JIRA database directly. As an Admin, I have the ability to maintain security and manage users, I don't understand why this permission is not available as part of the JIRA System>Shared items section. Keep voting on this issue to keep it moving forward. 

Another plugin to login as another user is [User Switcher for JIRA|https://marketplace.atlassian.com/plugins/com.tngtech.jira.plugins.schizophrenia/server/overview,] already mentioned in some previous comment. It's free and it works. I recommend to do it from a different browser (not tab, and not window: different browser, like: if you normally use Chrome, do it from Firefox), or at least from an Incognito/Private session, because when you switch user, it will switch it in all your tabs in that browser, which can be confusing, and it's better to isolate it.
 

That said, if you really want to play with the DB, this is what I had understood before discovering that plugin:

All the sharings are saved into the "sharepermissions" table. To find all the filters that are not shared, you must find all those that are not in that table, that is,

select ID, filtername from searchrequest where id not in (select entityid from sharepermissions where entitytype='SearchRequest');

Now, for a given filter (let's say the ID is 45281), if you want to share it you must add it to the table, and to do it you must find an unused ID in sharepermissions. Let's say the last one is 52612, then you could expect that choosing 52613 would work, but be careful here: if the ID 52613 has never been used before, I'm not sure you can just take it. The next time someone shares something I'm afraid JIRA could decide to pick that ID, not knowing that you have already used it, and this would give an error (it's the primary key, there can't be duplicates). So I think it's safer to reuse an ID that has already been taken and then left, that is: share a filter, see what ID is used for that in sharepermissions, then remove the sharing. Now you are sure JIRA won't try to use that again, and you can safely use it. So, let's say 52613 is fine. Then, to share filter 45281 globally, you have to use

INSERT INTO sharepermissions VALUES ('52613', '45281', 'SearchRequest', 'global', NULL, NULL);

If you test this with a private filter that you own, you can refresh the page, and see... That nothing changed, it's still private. Clearly, JIRA has an internal cache. Probably, restarting JIRA clears the cache and solves the problem, but I haven't tried it. Instead, I tried reindexing, and then refreshing the page, and this worked. By the way, Greg, you tried to modify the owner directly, and it didn't work. Maybe the reason is that you have to restart JIRA or reindex.

This means you can find all the private filters and share them. Then, from the normal web interface, you can change the owner, delete them, and so on.

Disclaimer: I take no responsibility for the consequences of using these commands. Make sure you test everything properly before you run them in a production environment!

Greg, changing ownership through database is complicated – I used Script Runner plugin with its
Switch to a different user script that allows JIRA administrator to become another user temporarily and manage filters, including sharing it. And than you can change owner of shared filter as described in this manual – https://confluence.atlassian.com/adminjiraserver071/managing-shared-filters-802593150.html

+1 to Dave's idea. We follow a similar process. It's cumbersome, but effective.

The best way I've found to deal with this is to impersonate the user.   At my company, we're using the ScriptRunner plugin, which offers "switch to a different user" as a built-in script.   There are a variety of other plugins that offer some kind of web sudo ability as well.   Short of that, you should be able to manipulate the user directories to log in with someone eles's account.   If you're using LDAP, for example, you could have JIRA use an internal directory first and create an account in the internal directory with the same ID of the LDAP user you need to manipulate.  Once you've assumed the user's identity, you can disable or modify any filters or subscriptions you want.  You can also share the filters, which then allows you to use the out-of-the-box facility to change ownership.

We used to do this kind of thing for Bamboo all the time because it would continue to spew out notification emails even for inactive users.    The process I describe here is very cumbersome and painful, but it gets the job done without resorting to mucking around in the database.  Good luck!

Petr,

Changing searchrequest.authorname and searchrequest.username to another user had no effect. There must be another table relationship that is essential for changing ownership of a filter.

select * from searchrequest s where (s.reqcontent like '%<field_name>%' or s.reqcontent like '%cf[<field_id>]%');

This will show all filters with <field_name> or <field_id> in it's text. Then you can update corresponding records (don't know about deletion).

Is there a SQL workaround?

A DBA with proper SQL instructions should be able to manually remove the records or change the owner to another person.  This request is a basic administrative function; requiring an add-on purchase to remove junk records is unreasonable.

This JIRA weakness is a security vulnerability where a disgruntled employee can create subscriptions that degrades or cripples server performance. Imagine a large filter result with a per minute subscription to many/all users!

+1. We need a special administrative tool for editing private filters of absent / fired / left employees (and ideally – for search for filters by field name and filterId).

I'm having the same issues.  I need to be able to delete filters, dashboards, etc., for users who are no longer with the company.

We are having similar issues. Our Managers create these filters for reporting to upper management and then want to destroy all the filters once the project is done. Currently, they need to manually delete all of them. They (and us Admins) would like to see a functionality within Administration section to be able to delete Private filters. 

Site admins should have permission to see anything in the system. We can impersonate the user with script runner, but that should not be necessary. This is a surprising limitation to what site admins can do.

We also need this. We would need some way to give one user permission to see ALL boards. This would be useful for some automation that we're doing.

We run into almost all of the issues cited above. These issues need to be fixed. It is very difficult to administer an application with these deficiencies. Please fix all of these issues.

Acro Jance's comment explains perfectly one of our big problems. We have to manually turn of all email functionality in our test environment for this reason, which also prevents us from manually testing the email functionality.

We also have problems after a user leaves the company - even though they are inactive, JIRA keeps trying to email them subscriptions, which then create lots of bounces.

The subscriptions are causing problems in our test-enviroment. On occasion we 'update' the test enviroment with production data for a fresh start. Subscriptions cause real problems. We have to block all emails. But for some development options (for instance new workflows with custom emails) we do need the outgoing mail to be enabled. If we do so, al subscriptions generate non actual results.

We have the dame problem. Lots of shared pobjects witout the possibility to manage the restrictions on them...

poor for an software like JIRA that there is only a hint to a expensive Plugin which will allow an SU in the relevant Account. I'd like to change the restrictions via bulk change.

And by the way: PLEASE do not make objects shared with "anyone" visible for the whole world! Anyone should mean only in the jirainstance knwon users.

regards Julius

The Workarounds are not feasible since, in my case, user status is derived from Active Directory; and logging in as them does not provide application access, i.e. access to their filters and dashboards. Reactivating the userid is also not an option, since it breaks compliance rules and will result in compliance audit failure.

not being able to manage individuals subscriptions on filters, as admin, or filter creator is also a bit absurd. (or at least I haven't managed to find a way to do it)

Thanks Philip and Edmond! Ii need to delete shared and private filters for invalid users and projects.

I plan on using the API to complete a bulk deletion of the unwanted filters on each instance. Unfortunately a JIRA Admin does not have the ability to delete private filters using the API, you must authenticate as the owner of the private filter. However, you can delete shared filters via the API when authenticating as an admin.

For the private filters that need to be deleted, I plan on changing the author and user in the searchrequest table. My understanding is that there are no dependencies to other tables for these fields (author and user) as long as the filter is private. After updating the author and user to the admin id, I am going to delete the filters via the API. When using the API to delete filters all references to the filter (dashboards, rapidboards, scrum and kanban boards, etc) should be deleted.

Going to finish up my testing today to see if it works. Will let you know!

@Philip,

The only restriction is outside of SQL queries, but more on dependencies with JIRA: Dashboards and Rapidboards for instance depend on the filters. I've had those items disappear on me when the filter that it was using was removed. So I guess you would need to append the query to take into account dashboards at a minimum.

Also, the user may not be deleted, but deactivated however.

Hi Sheri,

You could do this via SQL without damage (I think – somebody speak up here and make sure I'm not leading her down the wrong path).

Try this SQL:

SELECT * FROM `searchrequest` WHERE searchrequest.authorname not in (select lower_user_name from cwd_user)

 
If that comes with an appropriate list, then change it to:

Delete FROM `searchrequest` WHERE searchrequest.authorname not in (select lower_user_name from cwd_user)

Is this in the queue to be resolved anytime soon? I cant believe that this was first reported 10 years ago and the ability for a jira admin to manage private filters has not yet been resolved. We are in the process of splitting JIRA into 6 different instances and not being able to delete the invalid filters from instances where the projects and/or creator of the filter will not exist is a show stopper for us.

With that being said, has anyone been able to come up with a valid workaround for deleting private filters owned by other users? We have over 20,000 filters to delete from 6 different instances of JIRA.

I am blocked from using the workaround because the user is LDAP there is no migration feature for a specific user which is another problem that needs to be fixed.

There should be special filter type for dashboards. When employees leave we need away to manage the dashboards. Since they are "private" filters we are stuck and the only choice is to create new boards. Admins need to have the rights to change owner ship of dashboards.

Our setup uses an LDAP directory directly, not through Atlassian Crowd - testing showed that I was not able to switch to any of our LDAP-managed accounts, only to accounts that were in the JIRA internal directory.

Anyway, our situation has already now been resolved by getting the original owner to reshare the filters, but the fact that administrators currently cannot resolve this is ridiculous - hence my vote for fixing this ticket.

Thomas Pike, are you sure? Our setup is using Atlassian Crowd to another System which is using LDAP and User Switching is working fine.

Unfortunately the User Switcher for JIRA workaround does not work if the user accounts are managed through an LDAP directory.

Hello,

there is workaround:

• login with credentials of former admin/user/employee and purge restrictions
• on JIRA Server instances there is plugin User Switcher for JIRA

Anyway, as Mr. Kevin Turner said system administrator role should have ability to manage private filters and dashboards.

Scenario that just occurred here:

1. Project admin created agile boards for a project.
2. - Much time passes -
3. Project admin no longer works on this project.
4. Now-former project admin removes sharing from the filters that the agile boards depend on.

Result:

1. No-one, not even our JIRA administrators, or the other agile board admins, can access the agile boards that depend on these filters.
2. No-one can reconfigure the boards to use a different filter.
3. Our JIRA administrators cannot take ownership of the filters to fix the sharing.
4. The only person who can restore access to the agile boards is the owner of the filters.

This is absurd.

There is a requirement for this functionality. Administrators should be able to see and manage private filters.

I think too that this is a very important option to provide to clean some mess users do frequently

+1
Seems a nice addition, so an Administrator has FULL controle over te JIRA instance he/she is responsible for...

It boggles the mind that a user who is a JIRA Global Administrator cannot review Private Dashboards and Filters!

This functionality is absolutely needed. Seems a bit odd that it is not already there by default for a JIRA administrator. How could an administrator role not be given permission to view other people's filters in their own JIRA server instance? This is a bit of an antithesis.

Agree a better solution is needed. We've run an integrity checker and there's ~ 300 filters that are referencing stale objects and without DB hacking, there's no existing way to resolve the issues

Some form of distributed administration is needed here. I routinely see shared objects (dashboards/filters) that are copied and re-shared whenever an owner has abandoned them. This can happen for reasons other than a user becoming inactive - for example, the user moved to a different team, or different entity, or changed roles within the same company/entity.

As others have mentioned, a lot of difficult to eradicate cruft is left behind, including active subscriptions. If the project admin(s) could somehow own the objects - or better yet, if each object, when shared, could have ownership/admin specified and changed - then the 'collaboration' would hopefully lead to self-maintaining shared objects.

If you have access to the JIRA DB, this query gives you a list of Private Filters:

select * from searchrequest where id not in (select entityid from sharepermissions where entitytype='SearchRequest')

At least, you can see what private filters exist, their name, their owner and their JQL (column reqcontent).
I suppose you can update the filter's JQL here, but of course, watch out what you do if you do DB manipulations, use at own risk

tired of waiting for a solution, we either switch the users email to a dummy address or use this addon to hijack the filter owner's account:
User Switcher for JIRA

Big issue for us as well, as filter subscriptions are being sent out from our Test JIRA instance.
Disabling the SMTP server is not an option as this is required for testing our JIRA instance.

The administrator should have the ability to disable subscriptions per user. Assigned test users should still be able to receive mails from the subscriptions.

Any Updates here? We need better filter management.

Here's another example that just happened to me and why this is needed.

After upgrading Jira and subsequently Jira Agile, the ranking fields name was changed and broke every filter as they were ordering by this field. The way to fix this was to edit the query to remove the reference, save it, and add ranking back.

Most of our filters can't be fixed this way because so many are privately owned by ex-employees.

Here is an example of broken filters, which can be reported using third-party extension but there is no way to edit or delete them from Jira.

Is this really so hard to render the filter edit as if it would be owner by the user when the current user is a jira administrators. I guess not, probably could be implemented by changing one or two lines of code only.

any updates?

People can use filters 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 due to JIRA changes.

As jira-administrators are supposed to also manage the data integrity, they should be able to perform any kind of modifications to filters, dashboards and so on, so they would be able to perform repairs.

Considering that this issue is less than a day old and already has 11 votes, I would assume that there is high number of people that faces the same kind of issue.

The biggest pain point for us is subscriptions: A user will create a filter and set up a subscription to email the results to his team. When he leaves the company, there's no way for anyone else to assume control of this. We can't modify the filter or subscription and we can't give ownership to anyone else.