It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

JIRA Service Desk - Portal - Issue Permissions - help!

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.


- 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"


1 answer

3 votes
Jack Brickey Community Leader Oct 18, 2017

@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.

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.


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.     


Suggest an answer

Log in or Sign up to answer
This widget could not be displayed.
This widget could not be displayed.
Community showcase
Published Apr 08, 2019 in Jira Service Desk

What's new in Jira Service Desk Server: A stylish new portal in 4.1 - April 2019

Hello Atlassian Community!  I'm Teresa, the Product Marketing Manager   for Jira Service Desk Server at Atlassian. Curious about the latest updates in the Jira Service Desk Server...

325 views 0 3
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you