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.
Yeah its probably taken everyone longer to type the replies here than to implement this.
Given the field already exists in the message collection it would just simply be allowing it to be a constraint in a Liql query.
Unfortunately it's not quite that easy to implement, since what messages are read/unread are different for each user.
DougS is exactly right, the implementation is actually quite ugly and prone to errors and strange behaviour, especially when combined with some sort of caching (component cache, usercache), it can be done, but it's definitely not pretty. If I find time I'll try to resurrect the idea, thanks for the link!
If I already have DougS on the "line" =): I was recently digging trough the docs and community because I though I had read (once upon a time, but couldn't find it...) that the Lithium REST API's internally cache requests (e.g. outside of appcache, usercache, component cache). Is that a) the case and b) for how long and c) if it is the case, can that value be adjusted by support or is it global?
It shouldn't be that difficult to sort this,
we want to call the API for the currently authenticated user so we aren't asking for global 'unread' setting.. we literally want to query that value in the message collection for the CURRENT user.
