-
Suggestion
-
Resolution: Duplicate
-
515
-
9
-
NOTE: This suggestion is for JIRA Service Desk Cloud. Using JIRA Service Desk Server? See the corresponding suggestion.
Experienced Behavior
JIRA users are able to view Service Desk requests when granted "Browse Project" permission. These users are automatically able to view internal comments.
Expected Behavior:
JIRA users are able to view Service Desk request when granted "Browse Project" permission but are not able to view internal comments unless they are a part of the Service Desk Team.
Suggested Resolution:
Use project roles to determine if internal comments should be shown to users. A user who has "Browse Project" permission but no project roles should be able to view the request but not any internal comments. Users with "Browse Project" permission should be able to view internal comments when added to a project role such as "Service Desk Team" "Administrators" or "Developers"
Closing as this is a duplicate ticket. Please see https://jira.atlassian.com/browse/JSDCLOUD-829
- is related to
-
JSDCLOUD-829 Adding Comments - more comment visibility options instead of just being restricted to 2 options
- Closed
-
JSDSERVER-3392 Restrict internal comments to only users listed in project roles
- Gathering Interest
- resolves
-
ACE-4787 Loading...
Form Name |
---|
Hi rcrossman@atlassian.com
This feature isn't duplicating the
JSDCLOUD-829at all.There's some major differences in the 2 requests.
JSDCLOUD-829isn't helpfull at all to me, as i cannot realistically expect my internal service desk team to manually set a restriction level on each individual comment they're setting internally. i cannot block non-agents from setting internal comments as well, which is a vital part.This specific ticket requests a PROJECT LEVEL PERMISSION that will set project role based behaviour about the visibility and permissions of internal comments.
in my project i need to make sure the following is set:
While in my Customer service desk project:
I hope you see why these tickets you marked as duplicate are actually very different from each other.
you cannot possibly expect users to constantly be setting permissions on issue level for everything they're doing, that logic just can't stand!