Inline comment on both V.1 and V.2 doesn't provide enough data to recreate the inline comment using POST

Confluence Development Confluence Cloud
, ,
1

It seems like V.2 has the same problem as V.1:- missing out on certain important fields when you make a GET inline comment call.

To recreate/restore an inline comment, Atlassian requires API users to pass the following data which is not provided and is deduced by making guesswork.

{
  "inlineCommentProperties": { 
                                "textSelection": "<string>",
                                "textSelectionMatchCount": 113,
                                "textSelectionMatchIndex": 238
                              }
}
1 Like
2

Hi Parth!

The difference between data in the GET and POST for inline comments is intentional. Those 3 fields you specified are used to find the text to highlight on the current version of the page. The POST will create a tag using those fields with a marker-ref and put it around the highlighted text in the page’s body. The marker-ref is supposed to be the source of truth for what text is highlighted on the page. Data about the text matches/index is not persisted as the page’s body may be changed, which would change these values.

In the context of recreating/restoring a comment, can you elaborate a bit further on your use case? If you’re intending to highlight the same text as before (assuming it’s still there on the page), you’ll need to rerun your pattern matching that gave you those parameters when the comment was first created.

3

If you dig into the Confluence code you can find the text-matching functionality that is used to get these values - the name of the key function is “convertSelectionToLegacyFormat”.

However, the functionality relies on accessing the DOM, specifically requiring a ‘content container’ passed in, which should be the top-level element of the document, for example the ‘.ak-renderer-document’ element. If you try to use it from within a macro body, you can only give it the DOM element you have access to from within the macro iframe, and the values it yields can cause the ‘create comment’ API call to fail in cases where the ‘textSelectionMatchCount’ equals the number of matches in the macro body but not the number of matches on the page. So, it looks like a custom text-matching implementation is needed.

4

sadly for my use case I won’t have access to page’s data to create this info. Even if we did this would be a computationally taxing option to go thorough each comment and calculate these fields.

Is it not possible to return these fields or improve the logic to make creating/updating inline comment a bit easier?