Request Types Groups Permissions?

Hello,

I have the need to have different permissions/views in the portal. I have external customers that need to see certain request types groups/actions and then my internal staff have other needs.

I do not want two separate projects as a lot of the SLAs, workflows, etc.. are the same. That also creates a lot of issues when we have to move external clients issues into our internal change management, problems, incidents, etc....

So I basically want to have:

Permissions of user groups to be able to see certain request types within the portal
OR
A secondary view (or portal itself) within a project

Thanks

Brandt Winchell

5 answers

1 accepted

1 vote

Answer accepted

Hi Brandt,

It's currently not possible to add in different permissions within a single service desk. This can be done by an add-on for Server version but I see you are on Cloud.

I would highly recommend you have two different service desks. The SLAs can be copied to the new service desk and a single workflow can be shared among more than one project.

Hope that helps

Susan

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

I guess it was the answer I was afraid it would be.

Thanks

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Like • Charlie Misonne likes this

So after spending the day building a new project, I have run into a major issue due to the fact I cannot restrict the portal tasks based on roles.

If I have to have two separate projects just due to this fact, it will complicate things drastically for my team and cause duplicated work. I would have to duplicate a lot of the tasks, SLAs, configure request types & workflows. But most of all, the organization/customer records. I would need to maintain both projects with the exact same customer records. This is not feasible.

Is there a way to automatically transfer an issue created in the external project to my internal project? This way the external project is strictly only used to facilitate the initial request and all further transactions would be from our internal project.

Second thought, this would still be problematic. As the customer would still need access to the portal to see ticket updates, etc....

Not happy. This might be a deal breaker for this product.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi Brandt,

Via the automation you can create linked issues form new requests. See this blog:

https://confluence.atlassian.com/servicedeskcloud/blog/2017/12/automatically-create-linked-issues-from-new-requests

You can also update issues based on a linked issue update via automation.

Hope that helps

Susan

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

The custom rule seems to resolve the issue of the initial ticket being created and and to duplicate into the internal ITSM. The big issue are still:

How to update the external corresponding ticket with any updates
Organization and customer creations to be kept in sync

This seems to be a lot of customization for something that should be inherent into the portal. Since the system already understands different actions (create, close, update, assign, etc....) it would have made sense to add the portal security settings too. 99% of ITSM systems have the ability to expose specific catalog items to different groups.

It is like painting the walls in your house but you don't want to get paint on your ceiling when you do the cut work. So the solution is to remove the drywall, paint them, and then put the walls back. Just does not make sense.

I will have to submit a CR to Atlassian. I doubt it would be implemented before my POC is over with JSD. I will have to make the decision based on what I have today.

Thanks for the assistance though.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

1. Can be done with automations.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

1 vote

Why is this basic functionality missing in Jira? The ability to limit request type by group is pretty standard in this realm. JSD does not seem to be a mature product but they charge more than many full-featured Service desks.

Does Jira have an ETA on these basics being implemented? It would be nice to see the list so customers know if they need to look elsewhere.