You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I'm having a bit of trouble finding the permissions configurations for SRES saved filters. Although once you save & sync a SRES filter to a proper jira filter, that proper jira filter has the bells and whistles to set view and edit access, what I'm lacking to find is the permission configuration on the SRES filters themselves. Having edit access to the proper jira filter doesn't help much, as we don't want anyone actually updating those filters manually as they are updated every X minutes from the SRES filters and not only would changes be blown away on the next sync update (I assume) but the jira proper filter also doesn't allow you to update/augment the issueFunction style dynamic calls, as they are updated and replace with hard-coded key in (...) every X minutes for those calls. Essentially, I have a team of people that helps to keep our saved SRES filters up to date and maintained, and I would like to enable that group of people to have access to each others SRES filters to and have the whole team help maintain them with no barriers to access.
Is this a feature that is not in place yet, or am I just missing the exposed GUI element somewhere to augment the SRES permissions?
If the feature is not available at this time, the only work-around I can think of is to create a jira cloud service account for my team that is used for creating and maintaining these filters. Is there a better workaround that anyone else has come across, as we're trying to move away from service accounts in our jira instance for obvious best-practice security concerns.