Hi all,
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.
Regards
No.
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.
Regards
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
I am having a similar challenge to a permission like 'is in the same group as'. Is there any solution?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, forget "is in the same group as" because it doesn't work when you've got a good "this group can log in" scheme.
The best approach is to set up your permission schemes with the right roles and use those.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.