Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Hiding a service desk on the portal

Mark Murawski July 19, 2017

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 votes
Camille Crespeau July 27, 2017

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

Mark Murawski July 27, 2017

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

 

 

Mark Murawski July 27, 2017

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.

Jerry Ryan Ishmael September 15, 2017

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

Mark Murawski September 16, 2017

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.

Mark Murawski September 18, 2017

Hi Jerry,

 

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

Jerry Ryan Ishmael September 18, 2017

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

Cheers!

Mark Murawski September 29, 2017

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

Mark Murawski September 29, 2017

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

 

This is the related feature request.

 

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

0 votes
Mark Murawski July 19, 2017

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 Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 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! :-)

0 votes
Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 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.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events