message level kudos enabled setting
We are currently using the following to determine if kudos is enabled at node level: <#assign kudosEnabled = restadmin("/boards/id/${nodeId}/settings/name/config.enable_kudos").value /> The prob...
Forum Discussion
Hi,
I think this is what you're looking for: http://community.lithium.com/t5/Community-API/bd-p/developers-rest-api?leaf-id=Message.kudos.give.allowed#Message.kudos.give.allowed
Hmm... We are already making that call to see if the message belongs to the member logged in, the api call returning permission denied is being used to check whether the member has already submitted a kudos for the message because the API call you suggest has the note:
"Note that this ignores whether the user has already kudoed the message, in which a kudo can be given again but will have no effect."
So our logic is a combination of the 2 API's to enable/disable the button. I guess I will have to make the call to "/kudos/for/users/self/count" conditional based upon "kudos/give/allowed", meaning, if "kudos/give/allowed" is false, then don't make the API call that is crashing due to permission denied.
The problem is that "/kudos/give/allowed" returns false for the members own message, but in this case I still want to display the kudos count on the message with the kudos button grayed out.
I believe that I need access to the actual setting to correctly determine:
1. Are kudos / like enabled, if so then show the kudos button (got community and board settings accounted for, but not the article level ***missing)
2. does this message belong to me, if so then disable the kudos button but show counts (/kudos/give/allowed)
3. have I already given this message that doesn't belong to me kudoes, if so disable, if not allow to give kudos (/kudos/for/users/self/count)
Moving "/kudos/for/users/self/count" into a condition based upon "/kudos/give/allowed" does prevent the permission denied error bombing the endpoint, but it doesn't tell me whether the counts should be shown for my own message.
