We are using JIRA to intake requests to manage an editorial calendar.
1. A submitter through Service Desk should be able to see ONLY their own issues.
2. Ideally I'd like to create a group that several submitters can be a part of. Any submitter that is part of this group can see the issues of anyone else in that group. They must not be able to see issues for any other group or submitter that is not part of this group.
Role = Submitter
Groups = CompanyA, CompanyB, etc.
Can this functionality be accomplished in out of the box JIRA/SD?
3. A user that is part of ServiceDesk can still login to the normal JIRA interface. Is there a way to prevent or limit this?
Are there plugins that may help address this better? This would be a major decision point that would push us from OnDemand into OnPremise.
Albeit 1.0, SD is a step up from using an Issue Collector. If we are unable to prevent users from seeing each other's posts it's a security risk and SD is a non-starter.
Any insight is helpful, thanks in advance.
Hi Steve,
For the first two questions, what you are talking about can be accomplished with Issue-level Security in JIRA itself. If you set a default security set that is secured to the Reporter and/or a group then that should secure it like you need it.
For the third question, keep in mind that Service Desk is just a JIRA plugin, so it relies on a user having a license and some sort of access to at least create issues, attatchments, comment on and see their own issues. At a minimum they will need access to the project that the service desk is connected to. It's just a matter of securing you JIRA projects so that if a user happens to stumble into JIRA they don't see anything they shouldn't. See my reply to this question for steps to configure this. I know that there is an issue open with Atlassian about this, and perhaps in a future version they might provide more separation.
I hope that helps,
E.L.
Hi All,
I found this thread and we are experiencing the same issue right now. We want to give our customers access to the service desk so they can see queues, reports etc but we don't want them to be able to see SLAs. Right now viewing SLA's is grouped with the browse projects role. We'd like to give them access to everything but the SLAS. We are finding that the customer portal doesn't show enough and the service desk project shows too much!
Thanks,
Scott
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey Rick,
Sorry, I just noticed your question. (I think the system emailed Steve and not me.) The only way I know of to provide that kind of report is to auto-label your issues when they are generated from service desk and then come up with a filter that shows open issues in that project that were created from a particular form (i.e. have that label). The user would need to have JIRA project access to see this filter, which might defeat the purpose of what your going for.
E.L.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'd say there is still a gap in SD functionality.
I'm just providing some text here so the system will stop emailing me. :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi E.L.
I know with Service Desk 1.2 the issues of preventing customers from seeing the back end has been resolved. However, I'm still curious if you have an answer for the first question. Right now it appears that anyone (including super admin) can only see their own requests when viewing the customer portal at https://COMPANY-NAME.atlassian.net/servicedesk/customer/CUSTOMER-NAME. The request we're getting is to have an "All requests" button so that all submitters can see all open requests submitted through the service desk interface so the number of duplicates is minimized.
Is that something that can be easily added? I've looked at the permission schema and there is nothing that jumps out at me.
-Rick
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.