nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Hiding a service desk on the portal

Mark Murawski

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.

Accepted answers

All comments

Jack Brickey

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.

Mark Murawski

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

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! :-)

Camille Crespeau

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

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

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

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