Forum Discussion

sullysnack's avatar
sullysnack
Khoros Alumni (Retired)
9 years ago

Thread-based Unread / Read flag via APIv2 messages query

 

Hi Lithium Developers,

 

With APIv2 LiQL, say for example we have queried for 12 message results and all of them are thread starters (original posts). In each message result item there's a user_context.read flag which is either true or false. If the current authenticated user has already read the particular individual post, the user_context.read flag is true.

 

We are looking for another piece of information in each LiQL message result:

user_context.conversation.read

which would tell us whether or not the authenticated user has already read all of the posts in the thread which the result post started.

 

We've found an alternate way to query this information, but it involves multiple additional API queries per result item.  Since we query for 12+ results those extra queries slow down the page load. In some cases we moved the extra queries to an endpoint so that the data can be retrieved via ajax. Definitely not fool proof. Timing issues, maybe issues with heavy-use communities and horizontal scaling. We'd prefer to get this data in the original set of LiQL results.

 

We see out of the box Lithium components which show lists of threads display thread-based unread / read information with no palpable degradation in page load performance. Any way for us to do so via API?

 

Thank you,

Dave

 

  • Even if this is an older post, this problem still persists.
    There are so many possibilities nowadays to create custom message lists via api.

    But in case of read-tracking on thread level, we have just two possibilities:

    • get read/unread threads by looking for their last post with horrible performance impact especially if you have lots of threads to show
    • just do not use readtracking 

    This means: if you create custom message lists via api, you loose the main feature of a forum/community.

  • This is an older message, but if you are looking for the same information, our TAM told me about an (until then) undocumented option on the conversation object:

    There is an API object for the unread count for threads, it’s called unread_reply_count and it’s called as part of the conversation collection.
     
    e.g.: select conversation.unread_reply_count from messages where id = '1111'.
     
    It returns 0 for threads with no replies, so you still need to use  user_context.read in some way.
     
    Hope this helps the next person searching for an answer to how to do unread counts on threads in message lists.