Hiding a service desk on the portal

We're in the process of making a private service desk for internal issues, where certain personelle and some external users can submit issues to this service desk via direct email.

 

We do not want this service desk to be visible when users log in to the support portal unless they've been specifically added to this service desk.

 

For example.. we allow public signup for our main helpdesk in a project called ISSUES.  We also allow public signup for our internal helpdesk called II (for Internal Issues).

 

If someone is added to the system via ISSUES, they should *not* be allowed to see the Internal Issues support desk.

Screen Shot 2017-07-19 at 9.41.35 AM.png

 

 

This is my test login to a user that was automatically added by emailing to our ISSUES customer channel.  They should not have access to the Internal Issues service desk.

3 answers

0 vote
Jack Brickey Community Champion Jul 19, 2017

Mark,

you make projects visable to customers by controlling the customer list for the project. only share the email channel for the project with the customers you want. each project can have its own channel. So in the case of internal project I would create an Organization and add the internal employees to the organization. Note the Organization piece is optional and you could just add the employees to the project w/o placing in org.

Hi Jack,

 

Thanks for the input, but I'm looking for something a bit different.

 

Yes, visibility is controlled by the customer list, I get that.  But when customers are automatically added via emailing a customer channel, they are automatically given access to all customer channels.

 

I do not want this automatic part to happen for all customer channels, just for the channel that they emailed.

 

I also don't want to manually add emails to the customer channels, because they could come from a variety of sources especially for internal issues, such as from automatically generated from addresses from system monitoring.

 

So the ideal solution for me, is that when people email issues@company.org, they are given access to *only* the issues helpdesk.  When people email internal@company.org, they are *only* given access to internal@company.org.

 

Right now, when someone has an automatic email account generated via emailing issues@company.org, they *also* automatically gain access to the internal helpdesk.  This is a big blocker for our purposes.

Jack Brickey Community Champion Jul 19, 2017

Mark, thanks for the info. I haven't hit this issue and it has been awhile since i set up my project and new users coming on so I need to investigate when i have a moment. That said, all of my JSD projects are internal and use a unique custom email, e.g. IT@company.com, facilities@company.com, staffing@company.com. I have public sign up on and these emails are shared with the desired 'customers' so that when they send in a request they are added. If memory serves they do not see the other projects. But again, i need to research this to refresh my knowledge.

In the meantime I expect other will chime in here! :-)

Hello,

In "Customer Permissions">"Who can raise requests", check "Anyone can email the service desk or raise a request on this portal" if your desk is opened to external people or "Customers who have an account on this JIRA site" if your project is internal. If all your employees have access to JIRA and / or Confluence, they will be able to raise issues - no need to have access to JIRA Service Desk. 

 

That's what I did when I faced the same use case as you: create desks for my internal team + create desks for my customers.

 

Cheers

Hi Camille,

 

The main issue is I think the 'anyone can email the service desk or raise a request on this portal'.

 

I want two *different* service desks to have completely independent users, and both be in the 'anyone can email this' category.

 

If someone emails service desk A and is added as a user, they should not be automaticlly added to service desk B

 

 

I think perhaps I need some sort of pre-process email hook.  If I can write some code that'll run prior to Jira processing the message, then I can add the user to the service desk, set the permission to only that service desk.

Did this work? I am building out something similar and running into the same situations. 

Hi Jerry,

 

No this does not work.  By default when someone is automatically added by emailing a service desk, they have access to all service desks.

 

This is a major show stopper for implementing a new service desk that we need.

Hi Jerry,

 

I'm currently working with support.  It sounds like this is a bug.

Great, keep me updated or send me the ticket # so that I can keep watch. 

Cheers!

Hi Jerry,

 

They are classifying this as a new feature instead of a bug :(

 

In my view this is most certainly a bug and should be treated as such.  It's a massive problem to have people given access to all service desks when emailing into one.

 

Here's the issue:

https://jira.atlassian.com/browse/JRASERVER-3821

Er, I had the wrong link in my paste buffer.

 

This is the related feature request.

 

https://jira.atlassian.com/browse/JSDSERVER-5290

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Bridget Sauer
Published Mar 09, 2018 in Jira Service Desk

E.L. Fridge's take on education, Jira Service Desk, and creative Jira use cases

...word of mouth, so by 2016, we were working with several other entities on campus to implement Jira Service Desk . The Atlassian motto of “for every team” has really come true for us in this case. We...

960 views 2 14
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