-
Bug
-
Resolution: Unresolved
-
Medium
-
None
-
3.1.1
-
3
-
Severity 2 - Major
-
1
-
There seem to be two symptoms with a common cause:
Converting a Private comment to Public
As an Agent, I hit the Share With Customer button to convert a Private comment to a Public comment. The Comment_Edited event is fired, which is correct, however, it seems that the Event Declaring this change fires before JSD sets the entity properties of the comment that indicate the comments public nature. This means that Event Listeners would be unable to differentiate between a JSD Private comment and a JSD Private comment that was just Shared, meaning end-users will not be notified about such public features.
Adding a Private comment
We've found that with no other changes, as an Event Listener we receive comments that (a) have no entity properties defined (we see the entity property showing none()) , or (b) have entity properties defined. One possible explanation is that JSD is updating entity properties in an Event Listener callback, and the Set of Event Listeners notified is not a repeatable sequence:
- If the JSD Event Listener is registered before ours, then the comment entity properties are set and treated as private (b)
- If our Event Listener is registered first, then no properties are found and the comment is treated as public (a)
It would be a race condition driven by the use of Event Listeners to set entity properties. With no deterministic way to detect JSD private comments in addons, addons will leak private information.
The entity property identifying the comment as public must be set before the event is fired to ANY Event Listener. JSD should create the comment, without firing an event, setup its properties, then fire the event.
[JSDSERVER-3533] Comment entities not set before COMMENT_CREATED fired, causes Race Condition for addons and event listeners
Its implemented in the next JIRA version, you'll need an upgrade; feel free to continue this off issue through support@thepluginpeople.com
@andy brook, yes, we're on JIRA 7.1.1 server edition - 1.9.62 is the latest version of JEMH that shows in the marketplace for us, and I have no outstanding upgrades available (we are still under maintenance coverage).
Michael? Are you referring to JEMH v1.9.62 (as I don't see that listed as a JSD version)? JEMH v2.0.9 (JIRA7) worked around this issue with some compromises, and required further work to retain the event nature in notifications, fixed in v2.1.13+
Still a bug for us, on v 1.9.6.2. Found out the "hard way" this was happening. Licensed users are Service Desk Team, placing internal comments onto non-JIRA user created tickets. Those customers are receiving notifications that include the internal comment via email.
Jaap Klaver
added a comment - Same here, I'm still getting questions from my team about when we can finally add internal comments to servicedesk tickets without worrying about the input being sent to the customer as a result of this bug.
We're using the same scenario as written above, with JEMH.
Jaap Klaver
added a comment - Same here, I'm still getting questions from my team about when we can finally add internal comments to servicedesk tickets without worrying about the input being sent to the customer as a result of this bug.
We're using the same scenario as written above, with JEMH. Is there any indication of when this bug will be fixed?
We are also using an event listener that is driven by the JEMH plugin to obtain the property of comments. Since this is failing, it is causing our internal comments to be sent out via email to customers. This is unacceptable as internal comments are addressed to other helpdesk agents and contain sensitive data such as police reports and bank details that cannot be sent to the customers.
Kindly set the priority to URGENT as we are unable to use the helpdesk ticket system with this bug.
So JEMH implemented a dark magic in their addon to workaround this issue, but all other addons listening to comments are probably still affected. A Jira instance with JSD installed most likely has tons of other addons as well. This is a data privacy security breach. Cannot understand why this isn't fixed yet in JSD itself ...