Forum Discussion

b_poplin's avatar
b_poplin
Expert
11 years ago

restadmin threads potential bug

Before opening a case, wanted to run this by community.  I am getting different results regarding post timestamp from the API call and the same api call made via restadmin in an endpoint.

This has to do with the "relative dates" setting Admin/System/[checkbox] Use Relative dates (three hours ago).

I have found that checking this box and using the following API call:

http://[server]/restapi/vc/threads/id/[id]?restapi.response_style=view

returns with a post_time node formatted with a view_friendly_date attribute :

<post_time type="date_time" view_date="04-02-2014" view_time="11:50 AM" view_friendly_date="yesterday">2014-04-02T18:50:34+00:00</post_time>

unchecking the setting the api returns without the attribute, as expected:

<post_time type="date_time" view_date="04-02-2014" view_time="11:50 AM">2014-04-02T18:50:34+00:00</post_time>

***Heres the key point, the API call respects category and node level settings, and always works as expected***

 

When I use the API call via restadmin in an enpoint, the information returned by api call works as expected for the community level setting:

<#assign thread = restadmin("/threads/id/${id}").thread />
<#assign topic = thread.messages.topic />

Unfortunately, the category/node level setting IS NOT respected.  So changing the category level setting to something other than the community setting makes no change in what is returned.  This acts differently than the normal API call.

Is this a bug?  If not, then what is the best way to obtain the view_friendly_date (respecting category settings) in an endpoint

 

  • Ted answered my support case question:

    Using restadmin, you override scoped permissions and instead take the root community permissions instead, providing the behavior that you had reported. Compare this behavior with the standard "rest" context object, and it should, in theory, work the way you expected.

  • Ted answered my support case question:

    Using restadmin, you override scoped permissions and instead take the root community permissions instead, providing the behavior that you had reported. Compare this behavior with the standard "rest" context object, and it should, in theory, work the way you expected.