Hello,

I had the same need to manage the state of the comments in JSD after importing issues via CSV during the migration to JIRA. What I managed to investigate is the following class below which can update any comment's visibility state. It works both ways: public->internal, internal->public, just specify true or false in the property.

Hope this can be useful for comments creation as well.

public class CommentVisibilitySetter {

    private CommentService commentService;

    private final String SD_COMMENT_VISIBILITY_PROPERTY = "sd.public.comment";
    private final String SD_COMMENT_VISIBILITY_INTERNAL = "{\"internal\": true}";
    private final JiraAuthenticationContext authContext;
    private final Logger log = LoggerFactory.getLogger(CommentVisibilitySetter.class);

    public CommentVisibilitySetter(JiraAuthenticationContext authContext, CommentService commentService) {
        this.authContext = authContext;
        this.commentService = commentService;
    }

    public boolean setInternal(Comment comment) {

        Map<String, JSONObject> props = Maps.newHashMap();
        try {
            props.put(SD_COMMENT_VISIBILITY_PROPERTY, new JSONObject(SD_COMMENT_VISIBILITY_INTERNAL));
        } catch (JSONException e) {
        }

        final CommentService.CommentParameters commentParameters = CommentService.CommentParameters.builder()
                .author(comment.getAuthorApplicationUser())
                .body(comment.getBody())
                .commentProperties(props)
                .groupLevel(comment.getGroupLevel())
                .issue(comment.getIssue())
                .roleLevelId(comment.getRoleLevelId())
                .build();

        final CommentService.CommentUpdateValidationResult commentValidationResult = commentService.validateCommentUpdate(authContext.getLoggedInUser(), comment.getId(), commentParameters);
        if (!commentValidationResult.isValid()) {
            log.warn("Error validating comment update, issue={}, user={}, date={}", comment.getIssue().getKey(), comment.getAuthorApplicationUser().getName(), comment.getCreated());
            log.warn(commentValidationResult.getErrorCollection().getErrorMessages().toString());
            return false;
        }
        commentService.update(authContext.getLoggedInUser(), commentValidationResult, true);
        return true;
   }
}

Hi andy11

Have you tried adding a comment as a customer or agent on the customer portal, and then inspecting the issue properties?

Matt

> JSD is not deliberately stomping on every issue property, but rather looking for existence of certain keys and values, and if they don't exist, then it assumes the comment should be internal.
Can you elaborate, I'm not seeing anything stored as an entity property other than the key/value I already know about?

Public Comment

{"keys":[{"self":"http://localhost:8080/rest/api/2/comment/10700/properties/sd.public.comment","key":"sd.public.comment"}]}

Accessing the entity property http://localhost:8080/rest/api/2/comment/10700/properties/sd.public.comment gives:

{"key":"sd.public.comment","value":{"internal":false}}

Private Comment

{"keys":[{"self":"http://localhost:8080/rest/api/2/comment/10701/properties/sd.public.comment","key":"sd.public.comment"}]}

Accessing the entity property http://localhost:8080/rest/api/2/comment/10701/properties/sd.public.comment gives:

{"key":"sd.public.comment","value":{"internal":true}}

If I create a comment and do not broadcast the event, setup entity properties as shown above (for internal or not), then broadcast the event, JSD sets the above to internal:true, I'm not then able to manipulate the comment through the JIRA UI to change the comments visibiltiy, what is the nature of the additional keys/values that JSD is requiring to see, that would enable possibly the solution for JSD-1505, and this? I'm facing a block box problem, insight appreciated!

Hi Matt,
Awesome info, thanks, I'll poke around in the db directly. The JSD API issue is beyond a year old, I can't sit on my hands for this kind of integration issue, getting a resolution now is my aim, I can always refactor later.

Hi,

Yes, P2 API is also something that we aware of the need for, however to get the ball rolling it seems the REST API will be first to become available.

In terms of the specific magic combination of issue properties, I can't go into details of the internals, as they are open to change at any time, and are definitely not supported in existing state. However, if you are already looking into the issue properties stored by Service Desk in the database, you might notice 2 distinct keys used by Service Desk, for when a comment is made in the portal vs in Jira.

JSD is not deliberately stomping on every issue property, but rather looking for existence of certain keys and values, and if they don't exist, then it assumes the comment should be internal.

I would still recommend waiting for the actual APIs to be made available and fully supported.

Matt

Hi Matt,
Yes, there must be even more stuff going on in the JSD black box than I thought! As I mention on JSD-1505, the problem is not the Comment Manager being aware JSD is present (I think that's wrong) its JSD not looking to see if properties are already set before it decides to stamp the entity property marking it internal (I'm assuming it triggers this entity setting when events fire?).

Regarding this issue, can you give me some explanation as to what needs to be done now (I say this a lot!) to make JSD comments be correctly initialised, it may be I can work around this now rather than wait for future API improvements?

I hear REST APIs proposed as 'the' solution to many things in JIRA, please also remember that there are still P2 developers out here running as JIRA services, REST API aside, all I'd want to use is the same Manager that a future REST API calls, that is what I'm after in JSD-1505.

Hi andy11

Thank you for your findings. Using the JIRA CommentManager should work, but due to it not being aware of the issue property magic that is happening behind the scenes in Service Desk, it is unable to fulfill all the requirements.

Again, the real solution here is that Service Desk needs to provide a public REST API (JSD-107) that plugin developers can then leverage and build upon the offering.

I can not give any exact details at this moment, but it is something we are currently treating as a priority.

Regards
Matt
JIRA Service Desk developer