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 < aravi...@thoughtworks.com> 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 <morte...@gmail.com> > 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 <morte...@gmail.com> >> 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 < >>> mahen...@thoughtworks.com> 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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dhis2-devs > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp