Hey marianne.lee, could you please contact our Support Engineers about this? They'll be more than happy to help.

From the looks of it, something went wrong during the Jira upgrade. Or, if you are using Jira DC and zero downtime upgrade, maybe database upgrade tasks didn't run yet. Anyhow - those are only my guesses and our Support will be able to give you more guidance.

I recently upgraded the Jira server from 8.5.3 to 8.15.0 using .tar.gz archive method. Administration > System > Filters still show "Shared Filters" in the page title, and private filters are not found in the search results.  The same applies to Administration > System > Dashboards.  I have the Jira administration rights.

Am I missing out something?

If you want to delete all your filters, you can do something like this:

 ```
curl 'https://example.atlassian.net/rest/api/2/filter' -s -u "$EMAIL:$APITOKEN" | jq '.self' > urls.txt
cat urls.txt | xargs -L 1 curl -X DELETE -u "$EMAIL:$APITOKEN"
```

Thanks Daniel.- will re-review in EAP2

As a note, further testing on EAP1 showed:

Re: Changing non-shared dashboard owners - turns out you can change the owner, but - only to a sysadmin user, which means the workflow is:

1. Find the dashboard

1. Change to sysadmin (yourself)

1. Share the dashboard

1. Change the dashboard owner to the user you wanted to originally

Ideally, steps 3 and 4 can be removed from this process

Hey craig.castlemead1, thank you for the thorough testing!

It's a bug in the previous EAP, which also contains a few missed edge case scenarios (e.g. an admin is unable to modify gadgets on dashboards that are shared with groups/roles they don't belong to).

It will be fixed in 8.11.0-EAP02 and 8.11.0. I actually thought the second EAP would have been published when I was adding my comment, but it turns out it got a little delayed. Sorry about that!

Cheers,
Daniel

Does this mean customers can reasonably expect a fix for https://jira.atlassian.com/browse/JRACLOUD-41269 in the near-term future as well? 

Testing 8.11.0 EAP and findings below:

Private Dashboards/Filters - show in the UI, but then when you try and change the owner of a private Dashboard not shared with anyone, it says you can’t change the owner of an unshared dashboard.

Why would we want to do this?

1. User X sets up a dashboard with great reporting

1. Doesn’t share it

1. Leaves

1. The business has been relying on reports/metrics from said dashboard that User X was providing

1. We want to make the Dashboard public, and managed by a current staff member

The above does not align with the statement "With this feature, admins should get full control over obsolete and incorrect filters and dashboards, and can help their users set things right."

CCM

Hi everyone,

In Jira 8.11, we’re giving Jira admins the power to edit and delete private filters and dashboards. Admins can view and search for all existing filters and dashboards from the administration area.

• To view filters, go to Administration > System > Filters.
• To view dashboards, go to Administration > System > Dashboards.

These pages already existed (Shared filters/dashboards), but until now they only included filters that were shared by their owners. Now, it will also include private filters/dashboards.

After clicking the filter/dashboard name, you can navigate to it and modify it just like its owner—improve the JQL or gadgets' settings, share permissions, and more.

With this feature, admins should get full control over obsolete and incorrect filters and dashboards, and can help their users set things right.

You can download the 8.11 EAP version here.

Preparing for Jira 8.11 will give you an overview of the changes we intend to make in Jira 8.11.

Daniel Rauf
Jira Server and Data Center developer

+1

Looking forward to see this function in production. This function is very important for all of us.

Exciting! 

yay, thank you Atlassian, hope the implementation goes smooth and trouble free.

Finally....the issue moved to "In progress" ........5.5. years after it was created.

And now we wait.....again

Given the huge layoffs that your Atlassian customers have experienced due to the virus, its critical this feature be implemented sooner. Filter Owners and Dashboard Owners have been laid off gone and Tool Admins have to deal with this situation in high numbers. 

I voted for issue because of the similar reasons mentioned by my colleagues. As an admin at https://www.kidsatvsale.com/ I can't check private filters properly. It takes forever to manage them.  

I also strongly vote for this feature to be implemented. My case was as follows:

The project lead exchanged the filter of a board to a new one. The filter was not shared at all. Result: I couldn't find the filter in the filter search and also got a "Board doesn't exist or no sufficent rights to access it" error when trying to open the board. Which I thought was very unsual as an admin.

Only by looking into the database tables and audit log and using scriptrunners "switch to other user" I was able to reconstruct what happend.

As an admin I should be able to see private filters, then it would've cost a minute to track it down instead of an hour.

yes, please!

we have so many people who left the company and left behind many dashboards and filters - 1000s of them.

as admin, i should not login as each one of these users (also need to enable them to be able to log as them which is a security concern) just to delete an unused filter/dashboard.

my team is trying now to alter the DB but that can cause different issues.....

we created a cleanup user and tried to assign all private filters and dashboard to tat user so we can access as this user and delete all the unused filters/dashboard - so far unsuccessfully... if anyone has tried something like that before and willing to share the queries that will be awesome

Please implement. Every deployment, I get false red flags in the integrity checker, because we've got private filters belonging to a deleted user that cannot be managed. I'm worried about missing actual important integrity errors because it is cluttered with false red flags.

I did find a work-around for us (since we use Active Directory) - I was able to create a new user with the same username in AD and somewhat surprisingly to me, when I logged in as that user, I was able to manage all of the other user's filters and either delete them or make them shared filters (for future deleting/re-assignment)

This should be prioritized as old private filters/boards/dashboards are a problem when migrating projects from one Atlassian instance to another plz fix so best practice no longer is the use of third party software. 

I as Admin want to have the option on the admin-GUI to filter for private filters + inactive users and one click delete button.

We use Microsoft AD with CAS WITH TWO FACTOR login that prevents any impersonation solution offered by 3rd party vendors (all that I'm aware of anyway).

Here at this huge university we have thousands of users (Student and staff) that come and go yearly. We migrate unused projects off the system resulting in thousands of Private entities that point to a NULL pointer.
Please fix this software so admins can properly admin the data.

I highly recommend having the jira systems administrators have the ability to alter private filters, subscriptions, and dashboards. Looking forward to getting this feature.

our company also has problems due to this missing feature ...

after all what could be so secret in a filter syntax that the admin can not see it 

We've got a Jira installation with 300 Projects and 4.100 users. There are thousands of filters and hidden dashboards on our environment and I as admin am not able to see them.

We had large performance issues recently as a (private) board used a filter to display 17.000 issues at once. The server performance was killed and for us it was super difficult to find the issue as we can not see these creepy filters and boards. Therefore Atlassian, please improve your product and work on that topic. Thanks a lot!!!

Please act on this issue.

I cannot agree more that a system admin should be able to see and manage ALL objects, else what is the point of being an admin?

NOTE: when I say see and manage, I do NOT mean via SQL hacking; I mean the GUI interface.

And Jason's remark that that old data should be deleted is spot on! Old searches that refer to deleted objects such as components can cause problems, especially when the user created a subscription or set a gadget to autorefresh.

The support model for Jira has just got to adapt to the concept that basic system hygiene cannot rely on server and DB access.... Customers ought to be able to accomplish these truly basic management tasks using the admin interface.

I could not agree more. Please pay attention to this, Atlassian!

Re: Jira Server...this also wholly interferes with the Configuration Manager add-on, which calls for running an Integrity Check prior to snapshots & deployment...the Integrity Check pulls up dozens of old private filters from Inactive users referencing removed objects, but I'm unable to remove/modify these filters from anywhere in the application. 

Why would Botron's Configuration Manager and Atlassian provide/support a PAID (and expensive) add-on with a key feature that basically tells me "Hey, this is broke, but nothing you can do about it, because Jira doesn't provide any option to edit/remove these forgotten, unused & irrelevant filters because they're Private"? 

It's a filter.  A search query. Why does Jira persist a blanket lock-down on private search queries, especially by Inactive users? This makes no sense, and renders Botron Configuration Manager close to useless, as I can't include Filters, subscriptions or dashboard because of old, useless data that should be deleted if it's no longer managed by the original user...not worth paying for. 

Jira CLOUD Also needs this.   Critical to keep Jira cleaned up.

The Jira admin should be able to manage all kind of filters not only the shared.

Thanks Matt & Sten for sharing your advice.

It's true that the Shared Filters page won't auto-populate the user field with inactive user names (on 7.6.10, which I'm running), but if you simply fill in the field by hand you can access the filters just fine.

Marianne, you are correct. But all those old private filters and dashboards don't seem to have affected us after 15 years and 10,000 users. So I'll clean them up if and when I have to.

Something more questionable is how all the custom fields' data is not cleaned up from the database table customfieldvalue even after you remove the plugin that created it. We have 100 million rows in that table now

While the new feature «Share edit rights for filters and dashboards» has been released in Jira 7.12.3, I hope that Atlassian will enhance this to include private filters and boards of inactive users. To allow change of owners as well as deletion, in selective & bulk mode.

Our list of inactive users and their private filters & boards are growing.

Hi Greg, Matt, If the private filters and boards belonging to inactive users are inaccesible by admins, does that mean that they can be left & ignored in the system? Won’t there be a growing list? Will it affect system performance or configuration integrity?

I think this will work: https://marketplace.atlassian.com/apps/1216249/sharedmanager

And I think you'll like the price

Yeah, just tested and confirmed that you cannot log in as users who are inactive, their name doesn't auto-populate into the list of users. Not surprising. But the workaround for that is to get their account re-activated temporarily.

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.

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.

This breaks Configuration Manager for JIRA where a user has filters referring to projects that have since been deleted. The user is in LDAP, so therefore we have no access to his account.

EDIT: I stand corrected! The User Switcher plugin worked perfectly well, despite the fact that all our users are in LDAP. This may be because we have LDAP set to use local groups, therefore the remote user accounts are synced to local JIRA accounts for authorisation (but not for authentication). Where it definitely won't work is if the user account isn't licensed to use JIRA (i.e. not present in jira-users group).

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.