JIRA Service Desk - Portal - Issue Permissions - help!

Question

Here's what I want to do:

I want to limit what type of issue customers can create, i.e. I want all incoming things to first be "New Issue"

The team will then vet these "New Issues" and determine what they actually are and route them appropriately.

I want the customer to be able to view the issue still and see what we changed it to.   In short I want to limit the issue type that the customer can create, but NOT limit the type they can see and comment on / get emailed / etc.

So  summary:

1. client can create only 1 issue type - "New Issue"

2. Team will change "New Issue" into "New Feature" or "Bug" or "Question"

3. Client should now see that their "New Issue" has become a "Bug" (for example)

4. Client can see/edit/comment/track this bug.

WHY DO I WANT THIS?

- 1 the customers in this case are often wrong about what kind of issue it is

- 2 having things as "new issue" gives a clear indicator of what the team has not vetted yet.   New Issue means to the team, "we haven't even looked at that yet"

CAN THIS BE DONE?

Ryan Finco · Answer

Hide all issues on portal works provided 2 things

1. there is a mapping back to JIRA software - i.e. "Customer Request Type has to have 1 and only 1 value mapped back as Issue Type.   The fact that it has to be 1 to 1 vs 1 to many kills my idea a bit.

2.  You accept the problem detailed below

the real problem that I wasn't describing properly is that the rules around "organisations" only apply to the portal.  In turn, if anyone on my side of the system creates an issue, they have to do 2 things:  1) change reporter to the one person they want to see said issue in their portal (i.e. falsify the reporter)  2) change the customer request type so it maps back to the portal.

This is the real reason why my testing wasn't showing me things in the portal -- once it's created in Jira it can only be shown (regardless of organisation rules set up on that project) to the reporter, and only the reporter.  The rules only apply to the portal.

This means that if you have a portal that is open to multiple reporters (I.e. different users in 1 company for example) people on my side creating a issue NOT through the portal, it can't be seen by anyone other than the 1 particular reporter. (if changing the things mentioned above i.e reporter falsify & issue map, are forgotten or overlooked then the customer can not see that new issue)

So either live with this limitation (for us it's not so bad, as there really is only 1 reporter most of the time)  OR  bypass this limitation and only ever create new issues through a portal that you are also assigned as authorized within that particular organisation in JIRA.

------------------------------RANT------------------------

Did JIRA actually listen to anyone when they built this thing?  there are core functions that people want and JIRA seemingly doesn't do them at all or they have over complicated everything.    People ask "remove the help desk breadcrumb or give us an option to do so as our customers shouldn't see other customers!"  - JIRAs answer, a new layer of permissions where you have to go to each customer and select "don't show my project to others not in my project"  vs a simpler default of "don't let this project see other projects" - so instead of selecting something once, I had to do it 56 times.

Jack Brickey · Answer

@Ryan Finco,

So I’m not where I can try this but if you hide all issue types other than “New Issue” then I think that should work. The customer will only be able to create New Issue but should be able to continue to see it on the portal once the agent moves to another ‘hidden’ issue type. To do this i would suggest the following:

* Create all issue types you want
* Assign the “New Issue” type to email so that customer can submit ticket via email <optional>
* Hide all issue types other than New Issue from portal
* Test

FWIW, I certainly see the “wrong” issue type being chosen by customers but that is certainly understandable. I have my agents change the issue type but that doesn’t always happen either. :-(  So, given your appproach, you may wish to enforce changing of the issue type by having it associated w/ a workflow that sort of dead ends, i.e. one that doesn’t allow it to be transitioned to any meaningful status. Just a thought.