After an extensive search i have found ways to enable the reporter browse function and although untested as of yet, from what i have read it seems to let the user only view issues related to the group they are in and not others.. a bit like issue security.
Is there a way i'm missing to actually let specific users only see issues/tickets from their own groups?
for example - user a from group 1 can only see see their issues and other users inside of group 1, without a user from group 2 being able to see them?
Any help appreciated.
There's a huge logical flaw here, because if you were to code for this (which is messy and will impact performance), it won't work. Everyone will be able to see everyone else's stuff automatically. Because all your users are in a group that says "this person can log in".
You can restructure this out of your system if you want, but it makes user maintenance a nightmare. Also, the general advice for user maintenance is to avoid groups, and use roles, which already get you a lot closer to this and are easier to maintain.
Hi Nic, thanks for the speedy reply.
I see your point about groups and it being a nightmare... but the way our company uses JIRA is like this.. Multiple teams in house will have multiple JIRA projects. Each of those projects were only ever intended to be used internally until the service desk (helpdesk) section was created and now it's opening to the public.
We can use permission schemes to stop users from seeing what they shouldn't (or don't need to) when they first join in terms of other projects, but within the service desk project we would like to have multiple clients (utilised by groups) with multiple members inside, that are only able to see the relevant issues that other members of their group has created.
It's kind of a must.. so whether it's a straight forward JIRA process or a hacky process i have to get it done, and to be honest when it's laid out the way we are looking at it the maintenance side of it really isn't that hard because if each group could only see what we wanted - any issues in-between could be resolved with a simple migration from one group to another.
Could you provide more explanation of how i could achieve this with roles? So far they have only been good for letting people view projects or gain customer portal access, so if there's a way i'm missing then you'd be helping me alot.
It's not just a "hacky process" - you can only achieve this by rewriting the way Jira handles permissions. There is zero support for "is in the same group as" in the permissions. I suspect you need to revise your access schemes. Start with a look at a permission scheme and have a think about who REALLY needs to see any given issue and why, then come up with some rules (other than a generic "is in the same group as someone else") around permissions and who can do what.
Thanks for the replies guys, i've been away from a computer all weekend. I'll have a deeper look at this an see if there are any alternative methods. It just seems a bit off to be that there isnt an easier option but perhaps that's more a problem of ours rather than the program. Thanks for your help.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs