-
Bug
-
Resolution: Fixed
-
High
-
2.3.2
Summary
If an issue's reporter is an agent, then internal comments are displayed as public comments. This means that any customers who are participants can see all internal comments. Changing the reporter to a customer will cause all the internal comments to no longer be visible to customers. While the reporter is an agent, any customer participants will also receive notifications for the internal comments, which are presented only as public comments.
Steps to Reproduce
- Create a Service Desk Issue with a reporter who is an agent
- Attempt to set the comment internal
- Post the comment
Expected Results
The comment is posted as internal.
Actual Results
The comment appears like it is a public comment. Internally the restriction exists, so changing the reporter to a customer will again hide the comments.
Workaround
Ensure the Raising requests on behalf of customers approach to creating issues is followed. If not, changing the reporter through JIRA to be the appropriate user will allow that agent to create internal comments on the issue, and it will also restrict any comments which were created as internal.
- is duplicated by
-
-
- Closed
-
- mentioned in
-
Page Failed to load
-
Page
Failed to load
-
Page
Failed to load
-
Page
Failed to load
-
Page Loading...
-
-
- was cloned as
-
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-1604] When a reporter is an agent, internal comments are not restricted
Jeremy
added a comment - I've dialogued with the Service Desk team about this quite extensively already - Your support techs are very helpful, and I'm grateful for their thoroughness and responsiveness.
To summarise: The issue described above invalidates the use of the 'Request Participant' (RP) field whenever an agent is the reporter. In terms of workflow, this would happen if you raise a ticket in the Service Desk using the 'create' button rather than using the Customer Portal 'raise on behalf of' method. Once the ticket is raised, the agent = reporter, and the customer = RP. Once this condition is set, the RP gains access to internal comments. The internal comments are displayed in both the Support Portal, and through email comms. The default notification scheme usually only notifies the RP on resolution of the ticket, and this means that the 'ticket resolved' email shows the RP the last few internal comments that were made prior to resolution. These last few comments in a ticket, clearly visible in the 'resolved' email, are usually the most sensitive, detailed, or most likely to contain controversial or private information.
For our business, this issue represents a major security and privacy flaw. I do hope that this is resolved in the next release.
Jeremy
added a comment - I've dialogued with the Service Desk team about this quite extensively already - Your support techs are very helpful, and I'm grateful for their thoroughness and responsiveness.
To summarise: The issue described above invalidates the use of the 'Request Participant' (RP) field whenever an agent is the reporter. In terms of workflow, this would happen if you raise a ticket in the Service Desk using the 'create' button rather than using the Customer Portal 'raise on behalf of' method. Once the ticket is raised, the agent = reporter, and the customer = RP. Once this condition is set, the RP gains access to internal comments. The internal comments are displayed in both the Support Portal, and through email comms. The default notification scheme usually only notifies the RP on resolution of the ticket, and this means that the 'ticket resolved' email shows the RP the last few internal comments that were made prior to resolution. These last few comments in a ticket, clearly visible in the 'resolved' email, are usually the most sensitive, detailed, or most likely to contain controversial or private information.
For our business, this issue represents a major security and privacy flaw. I do hope that this is resolved in the next release.
Thanks for fixing this bug chaps - We really appreciate it!
Jono