see related JSD-3907

We're working on implementing this right now, however there seem to be a few blockers, for example, we need to be able to create comments but stop events firing (JSD-3897). The Component API doesn't support that feature, so we can't actually use it.

I notice that the public component API's are not published on the Atlassian maven repo {{ https://maven.atlassian.com/content/groups/public/com/atlassian/servicedesk/jira-servicedesk-api/ }} Is this to be done at some point? I'm currently breaking open the JSD jar and manually installing the jira-servicedesk-api-3.1x.jar. Related to that, the JIRA Service Desk Development Guide seems to be just a copy of the standard JIRA page, it makes no reference to JSD specific dependencies (the instructions don't result in a skeleton with required JSD imports). I would have logged feedback on that page but the feedback form only allows Name/Email no content, and submit breaks with some random JSON issue.

Nice! for cloud, we'll certainly be able to sue that. Regarding P2, is the creation of strictly public or private issues via the IssueService ever going to be possible? Using the JSD API for this would resolve this particular problem but have a very restrictive outcome for us. nm, I think we can roll this in!

Hi! I have some good news on this:

Atlassian Connect add-ons can new use the Service Desk REST API to create both public and internal comments (specified by the 'public' field in the request body). See the REST documentation for more info.

Additionally, P2 add-ons can make use of ServiceDeskCommentService to create both public and internal comments:

final ServiceDeskCommentCreateParameters publicComment =
    serviceDeskCommentService.newCreateBuilder()
                             .author(user)
                             .issue(customerRequest.getIssue())
                             .publicComment(true)
                             .body("This is a public comment")
                             .build();
serviceDeskCommentService.createServiceDeskComment(user, publicComment);

final ServiceDeskCommentCreateParameters internalComment =
    serviceDeskCommentService.newCreateBuilder()
                             .author(user)
                             .issue(customerRequest.getIssue())
                             .publicComment(false)
                             .body("This is an internal comment")
                             .build();
serviceDeskCommentService.createServiceDeskComment(user, internalComment);

Please note that, for both these methods, setting comment visibility depends on the calling user's permissions. For example, Agents can create either public or internal comments, Unlicensed users can only create internal comments, and Customers can only create public comments.

Cheers,
Trey Brisbane
JIRA Service Desk team

This feature is actually added as of jira 7.1, right?

https://docs.atlassian.com/jira-servicedesk/REST/latest/#servicedeskapi/request/{issueIdOrKey}/comment

Thanks for the update Brad, this is hurting a lot , FYI, its still an issue in JIRA Service Desk 3.x

I don't know how you aren't getting the comment tagged as internal, I just revalidated the scenario with JIRA 6.4.11 and JSD 2.5.6 also. Comments are 'public' as I create it and step through, but JSD comes in and stomps the comment private, despite the user making the comment being in the Service Desk Customers role.

I just noticed JSD-2347 as well.

If JSD doesn't update the property at all, all good, use the code above to set the property to Private, if JSD overwrites (whatever it is) it to Public, that's a flip in behaviour and is going to cause problems that the code above can't fix, and I guess means the inverse problem would then be the case (I want to make some comments private and some not, rather than all public, or all private).

Have you tried the code above to set private, what outcome? Meantime, I'll revalidate this with current vers.

Hi Andy, Francis,

Our addon creates comments using com.atlassian.jira.issue.comments.CommentManager.create:

/**
 * Creates a comment and associates it with the given issue. Using this method the comment will be created
 * with a createdDate of the current date/time and with no visibility restrictions.
 *
 * @param issue         the issue to associate the comment with.
 * @param author        the key of the user who has created this comment.
 * @param body          the text of the comment.
 * @param dispatchEvent if true then an event of type {@link com.atlassian.jira.event.type.EventType#ISSUE_COMMENTED_ID}
 *                      will be dispatched and any notifications listening for that event will be triggered.
 *                      If false no event will be dispatched.
 * @return the object representation of the newly created comment.
 * @throws com.atlassian.jira.exception.CommentBodyCharacterLimitExceededException when comment body exceeds the jira character limit
*/
public Comment create(Issue issue, ApplicationUser author, String body, boolean dispatchEvent)

We do set "dispatchEvent" to true, but our comments are visible in the service desk portal, so that seems to contradict this issue. Maybe the behavior changed in recent versions of JIRA/SD.

We tested on JIRA 6.4.7 and Service Desk 2.5.6.

Hi Francis, what versions of JSD was that with? I wonder, did you 'just' create the comment (not resulting in any events) or did you do so with a resulting ISSUE_COMMENTED event being fired? Last time I stepped through, JSD is overwriting the property (code in description), making it private in that case during its handling of that event.

If you happen to be creating a comment without firing events, you can do that with the code above, you just need to call it

		PropertyInput sd_comment_property = null;
		if (usePublic)
		{
			sd_comment_property = new PropertyInput("{\"internal\":false}", "sd.public.comment");
		}
		else //private
		{
			sd_comment_property = new PropertyInput("{\"internal\":true}", "sd.public.comment");
		}
		setCommentProperty(sd_comment_property, user, comment);

We just tested this - added a comment through the JAVA Api (CommentManager.create...)
This creates a comment with public visibility. What should the behavior be (we want the internal by default) ?

Francis

Hi Matt,

A JSD specific API, whether REST (insert numerous authentication/authorization issues here when driven from a p2 plugin) or Service oriented (insert p2 addon optional dependency pain here) could help, but if JSD did more here everything could just work fine, in this case; i.e. specifically (this issue) to look at the comment property its expecting and not just reset the value! this then gives addons the opportunity to feed JSD enabled projects, rather than addons being unable to interact effectively with JSD projects.

Putting off resolution to a core API project issue just means this wont happen any time soon, logged in 2013, there is no commitment to feature or timeline, just an indication of intrigue, which doesn't help customers now.

I don't yet see how doing this checking would be bad or detrimental in any way, and would solve what seems a really common JSD integration problem now.

Hi andy11

A current update on this issue, is that the behaviour you are seeing is expected.

The inner workings of the internal vs external commenting is quite complex, and at a low level, as you have discovered.

We understand that this can be frustrating. However, the real solution here is along the lines of JSD-107, and having JIRA Service Desk provide documented public API's for this functionality and more.

While I can provide no approximate timelines, this is something that we are aware off, and intend to address.

Regards
Matt
JIRA Service Desk developer

Hi guys, its been 8 weeks, any idea of timeline to at least 'check' comment entity property existence before setting it, customers asking...

Given this is sprinted for 2.2.x, and 2.4.1 has been released, can this be brought back to life for a future sprint?

Great to see this sprinted, so for resolution, if JSD only set entity properties appropriate for a comment entered via UI (only public when Public is selected, only internal when Internal is selected), then external comment creation would be free to not set (interpreted as public) or set (and JSD could interpret as whatever it was).

Questions:

1) As I need to set entity properties in a P2 addon, I'd appreciate any feedback on the hack above which seems to be the only way to 'set' the required entity property with the entity_name to be 'sd.comment.property' ?

2) I'm not sure its possible to set Entity Properties with arbitrary db-entity-names remotely via AC, or REST (at all? It seems not supported during comment creation)

Ha, just had a really helpful user point out that the JSD Comment field can actually be disabled, enabling standard comment visibility features, module is:

• service-desk-comment-field

I had thought I could work around this by setting the property directly on the comment. Unfortunately, that is not possible through the CommentPropertyService as the entity_name becomes (for that service) "CommentProperty" rather than "sd.comment.property".

I'm thinking there could be a hack possible to make non JSD created comments not appear as internal comments with a modified CommentPropertyHelper with keys overriding what JSD is using.

Hacky POC (look away now)

Yes, Im sure something is not right with the keys, If JSD source code was available, I'd look it up...

	private static void setCommentProperty(PropertyInput propertyInput, ApplicationUser user, Comment comment)
	{
		CommentPropertyHelper commentHelper=new CommentPropertyHelper(ComponentAccessor.getComponent(CommentPermissionManager.class),
				ComponentAccessor.getComponent(CommentSearchManager.class),
				ComponentAccessor.getI18nHelperFactory().getInstance(Locale.getDefault())) {
		    @Override
		    public EntityPropertyType getEntityPropertyType()
		    {
		    	String dbEntityName="sd.comment.property";
		    	String i18nKeyForEntityName="sd.comment.property";
		    	String indexPrefix="sd.comment.property";
		    	String jqlName="sd.comment.property";
		        return new EntityPropertyType(dbEntityName, i18nKeyForEntityName, indexPrefix, jqlName);
		    }
		};
		CommentPropertyService cps=new DefaultCommentPropertyService(ComponentAccessor.getComponent(JsonEntityPropertyManager.class),
				ComponentAccessor.getI18nHelperFactory().getInstance(Locale.getDefault()),
				ComponentAccessor.getComponent(EventPublisher.class),
				commentHelper);
		
		SetPropertyValidationResult propValidationResult = cps.validateSetProperty(user, comment.getId(), propertyInput);
		if (propValidationResult.isValid())
		{
			PropertyResult result = cps.setProperty(user, propValidationResult);
		}
}  

This worked well, during debug it was able to set the right entity_name which was the important bit, with the correct json_value indicating: internal:false.

Unfortunately, it looks like JSD is not checking for pre-existence of this property and neatly overwrites my hard work with a new value: internal:true. At which point, I fold.