Task Search REST API returns mix of accountIds & userKeys

Hi there,

it looks like the Confluence Task Search REST API is giving us a mix of accountIds and userKeys which makes it very hard for us to process the task body. It seems that if you mention more than one user in a Task, the first mention is rendered as accountId and subsequent mentions are rendered as userKey.

Let me give an example which should be easy to reproduce. I have created a page with a task that contains 2 user mentions and a due date.


This is the storage format of the page:

<p>This is a test for the Task Search REST API</p>
<ac:task-list>
  <ac:task>
    <ac:task-id>4</ac:task-id>
    <ac:task-status>incomplete</ac:task-status>
    <ac:task-body>
      <span class="placeholder-inline-tasks">
        <ac:link>
          <ri:user ri:userkey="USERKEY_A" />
        </ac:link>
        do something until <time datetime="2020-03-31" />  and talk to 
        <ac:link>
          <ri:user ri:userkey="USERKEY_B" />
        </ac:link>
        afterwards 
      </span>
    </ac:task-body>
  </ac:task>
</ac:task-list>
<p>Lorem Ipsum</p>
<p />

As you can see both mentions contain a valid userKey. (I have replaced the ri:userkey values with USERKEY_A and USERKEY_B)

Now, when I call the Task Search REST API this is the JSON it returns for the task:

{
	"globalId": 251,
	"id": 4,
	"contentId": 311230465,
	"status": "incomplete",
	"body": "...see below...",
	"creator": "ACCOUNT_ID_A",
	"assignee": "ACCOUNT_ID_A",
	"createDate": 1585382570211,
	"dueDate": 1585605600000
}

It correctly returns the accountId of user A for creator and assignee. But here is the task body:

<span class="placeholder-inline-tasks">
  <ac:link>
    <ri:user ri:userkey="ACCOUNT_ID_A" />
  </ac:link>
  do something until <time datetime="2020-03-31" />  and talk to 
  <ac:link>
    <ri:user ri:userkey="USER_KEY_B" />
  </ac:link>
  afterwards 
</span>

As you can see, the first user mention contains the accountId of user A in the ri:userkey attribute. But the second mention contains the userKey of user B in the ri:userkey attribute.

We absolutely want to avoid expensive roundtrips to the Convert Content Body REST API and are therefore resolving accountIds to displayNames ourselves from a cache. This of course only works for the first user mention that contains an actual accountId.

As far as we understand, if you want to render Task bodies correctly right now you have to:

  • Resolve the first user mention yourself.
  • Send all other user mentions to the Convert Content Body REST API for rendering.
  • Stitch everything back together.

This cannot be how we are supposed to use this API. But it looks like this is the only way to do it right now. Or are we missing something?

We think it would make the most sense if the Task Search REST API would always return the following format:

<ac:link>
  <ri:user ri:accountId="<accountId>" ri:username="<accountId>" />
</ac:link>

This can successfully be rendered by the Convert Content Body REST API and would still allow us to avoid round trips and render mentions ourselves. Also it doesn’t give out userKeys which can’t really be used by apps anymore as far as I’m aware.

Cheers,
Sven

(This is a follow-up of this thread)

1 Like