I agree with Tim, since the portal isolation is done, JSD-38 / JSD-55 and JSD-40 / JSD-53 are the super important remaining items to really make service desk fully usable.

Hello,
i played a little bit with Service Desk 1.2 and yes the permission works like expected but for me due to some other issues with Service Desk you can't enable the new permission scheme:

• JSD-38 / JSD-55- This is really important, due to restrictions a user can't view this issue if it was created by a support employee. I've disabled the mail function on my testing instance so i don't know if a user get a notification. If yes, i think he can't view the issue when the support creates the issue.
• JSD-40 / JSD-53 - Reopen, close issue, escalate, ... It's not possible through Service Desk interface.

Regards,
Tim

Note: The release notes have some page restrictions

Hi everyone,

Thanks for all your feedback on this issue, which has now been resolved with the release of Service Desk 1.2.
An overview of the changes in 1.2 is available in the release notes, and there are more specific details of this feature in the updated documentation about managing users.

Cheers,
Gilmore

We have a related use-case.

We have one big JIRA with lots of users with access to lots of projects. This JIRA is also shared by our IT dept.

They'd like to use Service Desk as the front end for people to raise IT issues/requests. However all the users going about their business in JIRA would be able to circumvent that and just create issues via the standard Create Issues button.

This would avoid the request types and KB integration that Service Desk provides....

can't find it too, was an old blog post or somwthing like this.
but some reference are there
https://confluence.atlassian.com/display/JIRAKB/Using+JIRA+for+Helpdesk+or+Support

here the documentation about security schema

Thanks. I can't find the article you mention, do you have a link?

I had tried basing the security level on a custom field, but this just seemed to provide a way of doing a bulk edit to set the permission based on a value of the custom field value, so I'm obviously need to understand this better.

Thanks again for your help.

nono u can use "user fields " too.
very usefull.
check documentation for "how atlassia use jira as helpdesk service management" there were some usefull article

Thanks Fabrizio, being able to restrict to seeing only the issues the user has reported is sufficient.

I hadn't seen that you can use security levels to control visibility by (e.g.) reporter, or assignee - I thought you could only do it by groups or named user.

Hi Mark, not like this.
Security schema are based on something in touch with user/group like fields (reporter/assignee), project role (developers) custom field (fields like group selector).
For example you can set the security that issues are viewable only by reporter / developers.

Reading your example the problem could be the "drop down selection for customer". How this field is filled now? The solution mentioned by me has the limit that user can only seee their issue, so for example a coworker of that user can't see others issue of the same company.

the are some workaround for this situation too. but as i said are workaround.

Thanks Fabrizo, I've looked at using security schemes, but I didn't see how it could solve my problem - perhaps you can help me?

We have a single Jira project that our service desk use, with a custom drop-down for "Client". I want external client users to only be able to see their issues - can issue security schemes do this?

As I understand it, I would need to set up one security level per client, and assign each client user to that level (only). But we would then need to remember manually set the security level for each issue that was created, to prevent the wrong users from seeing this. This seems very fiddly and error prone, unless it can be automatically populated somehow?

Is this what you had in mind, or is there a better way to do this?