Lithium Community 18.7 Release Notes

SuzieH JohnD It wasn't explicitly mentioned here, but the docs say is_subscribed field was added to the API v2 user_context object in 18.7, that's why I ask here: I have the issue that this value is always false, no matter if I'm subscribed to a topic or not, could you double check that for me on one of your instances, do I need to do something "special" to make this work or could this be a bug?

Query to check:

SELECT subject, user_context FROM messages ORDER BY post_time DESC LIMIT 50

and if we're on it: another useful addition to the user_context collection (IMHO) would be a can_edit property =)!

A much bigger improvement to the user_context object could be made by providing links/urls for actions related to the information already present, e.g.  can_kudo would be accompanied by a kudo_action (which of course should change to the 'remove-kudo' version if the user has already kudoed the message!), the can_delete property would have a delete_action accompanying it, above (new) can_edit property an edit_action, the can_reply property a reply_action and the is_subscribed property a subscribe_action (changing to the unsubscribe-version if subscribed) and maybe even the read property could even have a read_action providing a link to mark the message read or unread depending on its current value.

something unrelated I noticed as well (which could be improved, e.g. forwarded to the product team): If we specify the board field in the query above, we get back the following:

      "board" : {
        "type" : "board",
        "id" : "<board.id>",
        "href" : "/boards/<board.id>",
        "view_href" : "<url>"
      }

which is mildly unhelpful as (at least for us) in most cases AT LEAST the title (mostly short_title, as it inherits the title if empty) is required information used in customizations (to generate a link to the board), I figured out that if you specify board.short_title (have to add the other required fields as well, explicitly!) that I can get this information without making a separate query to the boards collection, so there is a workaround, but wouldn't it make sense to add that field to the default response object of the field board?