dhis2-devs team mailing list archive

[Morten Olav Hansen <mortenoh@xxxxxxxxx>]

Yes,

This is by design, :all merely means "give me all property on current
level". It will by default render idObjects with just idObject properties,
and Collections of idObject as a collection of idObject properties.

I know this breaks things, but we were really not happy with the current
use of viewClasses (@JsonView), I hope it won't be too difficult to
implement.

We do support recursive expansion of the fields properties, so you can do
?fields=a,b,c[a,b,c[a,b]],d[:all] etc, but yes.. this requires changes to
your code (most of this is supported in 2.15, but you will to use include=
instead)

--
Morten


On Wed, Jun 11, 2014 at 11:40 AM, Aravind Muralikrishnan <
aravindm@xxxxxxxxxxxxxxxx> wrote:

> Hello Morten,
>
> Thank you for the quick fix!
>
> We were trying the new api and it works. We also looked at the code a
> little bit, and we saw that if we don't give any query params, we are
> defaulting it to ":all". However this retrieves fields only at the first
> level and does not retrieve fields for the nested entities.
>
> Ex: When we get user object using say */api/users/OYLGMiazHtW.json *it
> just gets the user object and does not get all the fields of the
> userCredentials object.
>
> This might break backwards compatibility of the api, as the older api was
> giving out all the fields by default including nested objects. Is this the
> expected behaviour?
>
>
> Thanks,
> Aravind
>
>
> On Wed, Jun 11, 2014 at 1:19 PM, Morten Olav Hansen <mortenoh@xxxxxxxxx>
> wrote:
>
>> Hi
>>
>> This should now be working in rev 15615.
>> /api/users/OYLGMiazHtW.json?fields=:all,userCredentials[:all]
>>
>> Please try it out and report any issues back
>>
>> --
>> Morten
>>
>>
>> On Tue, Jun 10, 2014 at 1:33 PM, Morten Olav Hansen <mortenoh@xxxxxxxxx>
>> wrote:
>>
>>> Hi
>>>
>>> All our endpoint have now been switched our to using the new field
>>> filtering (similar to the old inclusion/exclusion), so the data you want is
>>> probably there, but you have to tell the system you want to have it. I do
>>> see that there is a bug in the UserCredentials class, I will fix that
>>> tomorrow.
>>>
>>> Please see the documentation here:
>>> http://www.dhis2.org/doc/snapshot/en/user/html/ch30s07.html
>>>
>>> Regarding the the custom serializers, we needed a bit more custom
>>> control over the output, we still use Jackson (ObjectMapper, but not
>>> data-binding) in the backend, together with xml (StAX).
>>>
>>> --
>>> Morten
>>>
>>>
>>> On Tue, Jun 10, 2014 at 1:02 PM, Mahendra Kariya <
>>> mahendrk@xxxxxxxxxxxxxxxx> wrote:
>>>
>>>> Hello Morten,
>>>>
>>>> We're facing some issues due to some recent changes to UserController.
>>>>
>>>> The serialized 'User' json has some issues.
>>>>
>>>>  The 'usercredentials' field is now being serialized as
>>>> 'org.hisp.dhis.user.UserCredentials' and also some of the properties of
>>>> UserCredentials (like userAuthorityGroup ) is not being serialized.
>>>>
>>>> One of our application is breaking due to these contract changes. We
>>>> tried fixing it, but soon got lost in the custom serialization code.
>>>>
>>>> Can you please have a look at this.
>>>>
>>>> ( Also on a side note, is there any specific reason we are going for
>>>> custom serialization instead of going for standard serializers like
>>>> Jackson? )
>>>>
>>>>
>>>> Regards
>>>>
>>>> Mahendra/Kiran
>>>>
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>
>