Hi all,
We are wanting to use a Liql Query like 'Select * from messages where user_context.read = false and board.id='boardid''
Essentially what we want to do is be able to list only unread messages for the user in a give board but I cant find a way to do that, any suggestions?
Hi Allen,
We don't currently have a way via the API to do look up messages that have been read by the current user in a given board. We do have a way in REST V1 to get a count of read messages for a given board (see the /boards/id/[id]/messages/read/count call), but no way in REST V2 or REST V1 to get only the unread messages in a board.
To list only the unread messages for a given user in a custom component or endpoints, you would need to get the first set of messages for the given board and then check if the message has not already been read (by checking the user_context.read property). You'd need to keep track of how many unread messages have been processed and then make another call to get the next set, until the target number of messages you want to display has been met.
-Doug
DougS This would be a very useful feature for either version of the API. We often have requests to build custom components based on unread messages in topics, often for super users who want to keep track of new comments in topics they are participating (at least that's what we know, the other users might use it as well). Unfortunately it is very (very) bad for performance to fetch entire sets of messages, looping over them just to see if they are already read, fetching another set to get more in case the desired amount is not reached yet etc. etc., caching can help a bit, but still the entire use case is very inefficient to implement. Maybe something for the backlog (on top please =D)?
I did a search in the Li Product Ideas board and found this thread:
It looks like it was archived due to not getting enough kudos to make it onto the product roadmap. I'd like to see this make it onto our roadmap, but unfortunately it is not my call. I'd recommend either lobbying to re-open this idea, or add a new idea for this (and maybe link to the old one) and getting some users to kudo it.
I agree that it's not ideal to have to code something to keep retrieving more messages when not enough unread messages are retrieved, and that seems like it gives us some more weight to implement this.
So this user_context.read, which is returned when you make a call to the API, it doesn't have a value stored some where but is calculated on the fly? is that the problem?
I am beginning to think a) wait for aurora and b) if I was going to do this I would be better to do it in and endpoint so the performance hit was on the server side.
